數據科學家成長指南(中)

《 數據科學家成長指南(上) 》中已經介紹了基礎原理、統計學、編程能力和機器學習的要點大綱,今天更新後續的第5、6、七條線路:天然語言處理、數據可視化、大數據。前端

Clipboard Image.png

準備好在新的一年,學習成爲將來五年最性感的職位麼。程序員

——————算法

Text Mining / NLP數據庫

文本挖掘,天然語言處理。這是一個橫跨人類學、語言學的交叉領域。中文的天然語言處理更有難度,這是漢語語法特性決定的,英文是一詞單詞爲最小元素,有空格區分,中文則是字,且是連續的。這就須要中文在分詞的基礎上再進行天然語言處理。中文分詞質量決定了後續好壞。編程

Corpuscanvas

語料庫數組

它指大規模的電子文本庫,它是天然語言的基礎。語料庫沒有固定的類型,文獻、小說、新聞均可以是語料,主要取決於目的。語料庫應該考慮多個文體間的平衡,即新聞應該包含各題材新聞。緩存

語料庫是須要加工的,不是隨便網上下載個txt就是語料庫,它必須處理,包含語言學標註,詞性標註、命名實體、句法結構等。英文語料庫比較成熟,中文語料還在發展中。前端框架

NLTK-Data服務器

天然語言工具包

NLTK創立於2001年,經過不斷髮展,已經成爲最好的英語語言工具包之一。內含多個重要模塊和豐富的語料庫,好比nltk.corpus 和 nltk.utilities。Python的NLTK和R的TM是主流的英文工具包,它們也能用於中文,必須先分詞。中文也有很多處理包:TextRank、Jieba、HanLP、FudanNLP、NLPIR等。

Named Entity Recognition

命名實體識別

它是確切的名詞短語,如組織、人、時間,地區等等。命名實體識別則是識別全部文字中的命名實體,是天然語言處理領域的重要基礎工具。

命名實體有兩個須要完成的步驟,一是肯定命名實體的邊界,二是肯定類型。漢字的實體識別比較困難,好比南京市長江大橋,會產生南京 | 市長 | 江大橋 、南京市 |  長江大橋 兩種結果,這就是分詞的任務。肯定類型則是明確這個實體是地區、時間、或者其餘。能夠理解成文字版的數據類型。

命名實體主要有兩類方法,基於規則和詞典的方法,以及基於機器學習的方法。規則主要以詞典正確切分出實體,機器學習主要以隱馬爾可夫模型、最大熵模型和條件隨機域爲主。

Text Analysis

文本分析

這是一個比較大的交叉領域。以語言學研究的角度看,文本分析包括語法分析和語義分析,後者現階段進展比較緩慢。語法分析以正確構建出動詞、名詞、介詞等組成的語法樹爲主要目的。

Clipboard Image.png

若是不深刻研究領域、則有文本類似度、預測單詞、困惑值等分析,這是比較成熟的應用。

UIMA

UIMA 是一個用於分析非結構化內容(好比文本、視頻和音頻)的組件架構和軟件框架實現。這個框架的目的是爲非結構化分析提供一個通用的平臺,從而提供可以減小重複開發的可重用分析組件。

Term Document Matrix

詞-文檔矩陣

它是一個二維矩陣,行是詞,列是文檔,它記錄的是因此單詞在全部文檔中出現頻率。因此它是一個高維且稀疏的矩陣。

Clipboard Image.png

這個矩陣是TF-IDF(term frequency–inverse document frequency)算法的基礎。TF指代的詞在文檔中出現的頻率,描述的是詞語在該文檔的重要數,IDF是逆向文件頻率,描述的是單詞在全部文檔中的重要數。咱們認爲,在全部文檔中都出現的詞確定是的、你好、是否是這類經常使用詞,重要性不高,而越稀少的詞越重要。故由總文檔數除以包含該詞的文檔數,而後取對數得到。

詞-文檔矩陣能夠用矩陣的方法快速計算TF-IDF。

它的變種形式是Document Term Matrix,行列顛倒。

Term Frequency & Weight

詞頻和權重

詞頻即詞語在文檔中出現的次數,這裏的文檔能夠認爲是一篇新聞、一份文本,甚至是一段對話。詞頻表示了詞語的重要程度,通常這個詞出現的越多,咱們能夠認爲它越重要,但也有可能遇到不少無用詞,好比的、地、得等。這些是停用詞,應該刪除。另一部分是平常用語,你好,謝謝,對文本分析沒有幫助,爲了區分出它們,咱們再加入權重。

權重表明了詞語的重要程度,像你好、謝謝這種,咱們認爲它的權重是很低,幾乎沒有任何價值。權重既能人工打分,也能經過計算得到。一般,專業類詞彙咱們會給予更高的權重,經常使用詞則低權重。

經過詞頻和權重,咱們能提取出表明這份文本的特徵詞,經典算法爲TF-IDF。

Support Vector Machines

支持向量機

它是一種二類分類模型,有別於感知機,它是求間隔最大的線性分類。當使用核函數時,它也能夠做爲非線性分類器。

它能夠細分爲線性可分支持向量機、線性支持向量機,非線性支持向量機。

非線性問題不太好求解,圖左就是將非線性的特徵空間映射到新空間,將其轉換成線性分類。說的通俗點,就是利用核函數將左圖特徵空間(歐式或離散集合)的超曲面轉換成右圖特徵空間(希爾伯特空間)中的的超平面。

Clipboard Image.png

經常使用核函數有多項式核函數,高斯核函數,字符串核函數。

字符串核函數用於文本分類、信息檢索等,SVM在高維的文本分類中表現較好,這也是出如今天然語言處理路徑上的緣由。

Association Rules

關聯規則

它用來挖掘數據背後存在的信息,最知名的例子就是啤酒與尿布了,雖然它是虛構的。但咱們能夠理解它蘊含的意思:買了尿布的人更有可能購買啤酒。

它是形如X→Y的蘊涵式,是一種單向的規則,即買了尿布的人更有可能購買啤酒,可是買了啤酒的人未必會買尿布。咱們在規則中引入了支持度和置信度來解釋這種單向。支持度代表這條規則的在總體中發生的可能性大小,若是買尿布啤酒的人少,那麼支持度就小。置信度表示從X推導Y的可信度大小,便是否真的買了尿布的人會買啤酒。

關聯規則的核心就是找出頻繁項目集,Apriori算法就是其中的典型。頻繁項目集是經過遍歷迭代求解的,時間複雜度很高,大型數據集的表現很差。

關聯規則和協同過濾同樣,都是類似性的求解,區分是協同過濾找的是類似的人,將人劃分羣體作個性化推薦,而關聯規則沒有過濾的概念,是針對總體的,與我的偏好無關,計算出的結果是針對全部人。

Market Based Analysis

購物籃分析,實際是Market Basket Analysis,做者筆誤。

傳統零售業中,購物籃指的是消費者一次性購買的商品,收營條上的單子數據都會被記錄下來以供分析。更優秀的購物籃分析,還會用紅外射頻記錄商品的擺放,顧客在超市的移動,人流量等數據。

關聯規則是購物籃分析的主要應用,但還包括促銷打折對銷售量的影響、會員制度積分制度的分析、回頭客和新客的分析。

Feature Extraction

特徵提取

它是特徵工程的重要概念。數據和特徵決定了機器學習的上限,而模型和算法只是逼近這個上限而已。而不少模型都會遇到維數災難,即維度太多,這對性能瓶頸形成了考驗。常見文本、圖像、聲音這些領域。

爲了解決這一問題,咱們須要進行特徵提取,將原始特徵轉換成最有重要性的特徵。像指紋識別、筆跡識別,這些都是有實體有跡可循的,而表情識別等則是比較抽象的概念。這也是特徵提取的挑戰。

不一樣模式下的特徵提取方法不同,文本的特徵提取有TF-IDF、信息增益等,線性特徵提取包括PCA、LDA,非線性特徵提取包括核Kernel。

Using Mahout

使用Mahout

Mahout是Hadoop中的機器學習分佈式框架,中文名驅象人。

Mahout包含了三個主題:推薦系統、聚類和分類。分別對應不一樣的場景。

Mahout在Hadoop平臺上,藉助MR計算框架,能夠簡便化的處理很多數據挖掘任務。實際Mahout已經再也不維護新的MR,仍是投向了Spark,與Mlib互爲補充。

Using Weka

Weka是一款免費的,基於JAVA環境下開源的機器學習以及數據挖掘軟件。

Using NLTK

使用天然語言工具包

Classify Text

文本分類

將文本集進行分類,與其餘分類算法沒有本質區別。假如如今要將商品的評論進行正負情感分類,首先分詞後要將文本特徵化,由於文本必然是高維,咱們不可能選擇全部的詞語做爲特徵,而是應該以最能表明該文本的詞做爲特徵,例如只在正情感中出現的詞:特別棒,很好,完美。計算出卡方檢驗值或信息增益值,用排名靠前的單詞做爲特徵。

因此評論的文本特徵就是[word11,word12,……],[word21,word22,……],轉換成高維的稀疏矩陣,以後則是選取最適合的算法了。

垃圾郵件、反黃鑑別、文章分類等都屬於這個應用。

Vocabulary Mapping

詞彙映射

NLP有一個重要的概念,本體和實體,本體是一個類,實體是一個實例。好比手機就是本體、iPhone和小米是實體,它們共同構成了知識庫。不少文字是一詞多意或者多詞一意,好比蘋果既能夠是手機也能夠是水果,iPhone則同時有水果機、蘋果機、iPhone34567的諸多叫法。計算機是沒法理解這麼複雜的含義。詞彙映射就是將幾個概念相近的詞彙統一成一個,讓計算機和人的認知沒有區別。

——————

Visualization數據可視化

這是難度較低的環節,統計學或者大數據,都是不斷髮展演變,是屬於終身學習的知識,而可視化只要瞭解掌握,能夠受用不少年。這裏並不包括可視化的編程環節。

Uni, Bi & Multivariate Viz

單/雙/多 變量

在數據可視化中,咱們經過不一樣的變量/維度組合,能夠做出不一樣的可視化成果。單變量、雙變量和多變量有不一樣做圖方式。

ggplot2

R語言的一個經典可視化包

ggoplot2的核心邏輯是按圖層做圖,每個語句都表明了一個圖層。以此將各繪圖元素分離。

ggplot(...) +

  geom(...) + 

  stat(...) +

  annotate(...) +

  scale(...) 

上圖就是典型的ggplot2函數風格。plot是總體圖表,geom是繪圖函數,stat是統計函數,annotate是註釋函數,scale是標尺函數。ggplot的繪圖風格是灰底白格。

ggplot2的缺點是繪圖比較緩慢,畢竟是以圖層的方式,可是瑕不掩瑜,它依舊是不少人使用R的理由。

Histogram & Pie(Uni)

直方圖和餅圖(單變量)

直方圖已經介紹過了,這裏就放張圖。

Clipboard Image.png

餅圖不是經常使用的圖形,若變量之間的差異不大,如35%和40%,在餅圖的面積比例靠肉眼是分辨不出來。

Tree & Tree Map

樹圖和矩形樹圖

樹圖表明的是一種結構。層次聚類的實例圖就屬於樹圖。

當維度的變量多大,又須要對比時,可使用矩形樹圖。經過面積表示變量的大小,顏色表示類目。

Clipboard Image.png

Scatter Plot (Bi) 

散點圖(雙變量)

散點圖在數據探索中常常用到,用以分析兩個變量之間的關係,也能夠用於迴歸、分類的探索。

Clipboard Image.png

利用散點圖矩陣,則能將雙變量拓展爲多變量。

Clipboard Image.png

Line Charts (Bi)

折線圖(雙變量)

它經常使用於描繪趨勢和變化,和時間維度是好基友,如影隨形。

Clipboard Image.png

Spatial Charts

空間圖,應該就是地圖的意思

一切涉及到空間屬性的數據都能使用地理圖。地理圖須要表示座標的數據,能夠是經緯度、也能夠是地理實體,好比上海市北京市。經緯度的數據,經常和POI掛鉤。

Clipboard Image.png

Survey Plot

不知道具體的含義,粗略翻譯圖形探索

plot是R中最經常使用的函數,經過plot(x,y),咱們能夠設定不一樣的參數,決定使用那種圖形。

Timeline

時間軸

當數據涉及到時間,或者存在前後順序,咱們可使用時間軸。很多可視化框架,也支持以時間播放的形式描述數據的變化。

Clipboard Image.png

Decision Tree

決策樹

這裏的決策樹不是算法,而是基於解釋性好的一個應用。

Clipboard Image.png

當數據遇到是否,或者選擇的邏輯判斷時,決策樹不失爲一種可視化思路。

D3.js

知名的數據可視化前端框架

d3能夠製做複雜的圖形,像直方圖散點圖這類,用其餘框架完成比較好,學習成本比前者低。

d3是基於svg的,當數據量變大運算複雜後,d3性能會變差。而canvas的性能會好很多,國內的echarts基於後者。有中文文檔,屬於比較友好的框架。

R語言中有一個叫d3NetWork的包,Python則有d3py的包,固然直接搭建環境也行。

IBM ManyEyes

Many Eyes是IBM公司的一款在線可視化處理工具。該工具能夠對數字,文本等進行可視化處理。應該是免費的。圖網上隨便找的。

Clipboard Image.png

Tableau

國外知名的商用BI,分爲Desktop和Server,前者是數據分析單機版,後者支持私有化部署。加起來得幾千美金,挺貴的。圖網上隨便找的。

Clipboard Image.png

——————

Big Data 大數據

愈來愈火爆的技術概念,Hadoop尚未興起幾年,第二代Spark已經後來居上。 由於做者寫的比較早,如今的新技術沒有過多涉及。部分工具我不熟悉,就略過了。

Map Reduce Fundamentals

MapReduce框架

它是Hadoop核心概念。它經過將計算任務分割成多個處理單元分散到各個服務器進行。

MapReduce有一個很棒的解釋,若是你要計算一副牌的數量,傳統的處理方法是找一我的數。而MapReduce則是找來一羣人,每一個人數其中的一部分,最終將結果彙總。分配給每一個人數的過程是Map,處理彙總結果的過程是Reduce。

Hadoop Components

Hadoop組件

Hadoo號稱生態,它就是由無數組建拼接起來的。

Clipboard Image.png

各種組件包括HDFS、MapReduce、Hive、HBase、Zookeeper、Sqoop、Pig、Mahout、Flume等。最核心的就是HDFS和MapReduce了。

HDFS

Hadoop的分佈式文件系統

HDFS的設計思路是一次讀取,屢次訪問,屬於流式數據訪問。HDFS的數據塊默認64MB(Hadoop 2.X 變成了128MB),而且以64MB爲單位分割,塊的大小遵循摩爾定理。它和MR息息相關,一般來講,Map Task的數量就是塊的數量。64MB的文件爲1個Map,65MB(64MB+1MB)爲2個Map。

Data Replication Principles

數據複製原理

數據複製屬於分佈式計算的範疇,它並不只僅侷限於數據庫。

Hadoop和單個數據庫系統的差異在於原子性和一致性。在原子性方面,要求分佈式系統的全部操做在全部相關副本上要麼提交, 要麼回滾, 即除了保證原有的局部事務的原子性,還須要控制全局事務的原子性; 在一致性方面,多副本之間須要保證單一副本一致性。

Hadoop數據塊將會被複制到多態服務器上以確保數據不會丟失。

Setup Hadoop (IBM/Cloudera/HortonWorks)

安裝Hadoop

包括社區版、商業發行版、以及各類雲。

Name & Data Nodes

名稱和數據節點

HDFS通訊分爲兩部分,Client和NameNode & DataNode。

Clipboard Image.png

NameNode:管理HDFS的名稱空間和數據塊映射信息,處理client。NameNode有一個助手叫Secondary NameNode,負責鏡像備份和日誌合併,負擔工做負載、提升容錯性,誤刪數據的話這裏也能恢復,固然更建議加trash。

DataNode:真正的數據節點,存儲實際的數據。會和NameNode之間維持心跳。

Job & Task Tracker

任務跟蹤

JobTracker負責管理全部做業,講做業分隔成一系列任務,然而講任務指派給TaskTracker。你能夠把它想象成經理。

TaskTracker負責運行Map任務和Reduce任務,當接收到JobTracker任務後幹活、執行、以後彙報任務狀態。你能夠把它想象成員工。一臺服務器就是一個員工。

M/R Programming

Map/Reduce編程

MR的編程依賴JobTracker和TaskTracker。TaskTracker管理着Map和Reduce兩個類。咱們能夠把它想象成兩個函數。

MapTask引擎會將數據輸入給程序員編寫好的Map( )函數,以後輸出數據寫入內存/磁盤,ReduceTask引擎將Map( )函數的輸出數據合併排序後做爲本身的輸入數據,傳遞給reduce( ),轉換成新的輸出。而後得到結果。

網絡上不少案例都經過統計詞頻解釋MR編程:

Clipboard Image.png

原始數據集分割後,Map函數對數據集的元素進行操做,生成鍵-值對形式中間結果,這裏就是{「word」,counts},Reduce函數對鍵-值對形式進行計算,獲得最終的結果。

Hadoop的核心思想是MapReduce,MapReduce的核心思想是shuffle。shuffle在中間起了什麼做用呢?shuffle的意思是洗牌,在MR框架中,它表明的是把一組無規則的數據儘可能轉換成一組具備必定規則的數據。

Clipboard Image.png

前面說過,map函數會將結果寫入到內存,若是集羣的任務有不少,損耗會很是厲害,shuffle就是減小這種損耗的。圖例中咱們看到,map輸出告終果,此時放在緩存中,若是緩存不夠,會寫入到磁盤成爲溢寫文件,爲了性能考慮,系統會把多個key合併在一塊兒,相似merge/group,圖例的合併就是{"Bear",[1,1]},{"Car",[1,1,1]},而後求和,等Map任務執行完成,Reduce任務就直接讀取文件了。

另外,它也是形成數據傾斜的緣由,就是某一個key的數量特別多,致使任務計算耗時過長。

Sqoop: Loading Data in HDFS

Sqoop是一個工具,用來將傳統數據庫中的數據導入到Hadoop中。雖然Hadoop支持各類各樣的數據,但它依舊須要和外部數據進行交互。

Sqoop支持關係型數據庫,MySQL和PostgreSQL通過了優化。若是要連其餘數據庫例如NoSQL,須要另外下載鏈接器。導入時須要注意數據一致性。

Sqoop也支持導出,可是SQL有多種數據類型,例如String對應的CHAR(64)和VARCHAR(200)等,必須肯定這個類型可不可使用。

Flue, Scribe: For Unstruct Data

2種日誌相關的系統,爲了處理非結構化數據。

SQL with Pig

利用Pig語言來進行SQL操做。

Pig是一種探索大規模數據集的腳本語言,Pig是接近腳本方式去描述MapReduce。它和Hive的區別是,Pig用腳本語言解釋MR,Hive用SQL解釋MR。

它支持咱們對加載出來的數據進行排序、過濾、求和、分組(group by)、關聯(Joining)。而且支持自定義函數(UDF),它比Hive最大的優點在於靈活和速度。當查詢邏輯很是複雜的時候,Hive的速度會很慢,甚至沒法寫出來,那麼Pig就有用武之地了。

DWH with Hive

利用Hive來實現數據倉庫

Hive提供了一種查詢語言,由於傳統數據庫的SQL用戶遷移到Hadoop,讓他們學習底層的MR API是不可能的,因此Hive出現了,幫助SQL用戶們完成查詢任務。

Hive很適合作數據倉庫,它的特性適用於靜態,SQL中的Insert、Update、Del等記錄操做不適用於Hive。

它還有一個缺點,Hive查詢有延時,由於它得啓動MR,這個時間消耗很多。傳統SQL數據庫簡單查詢幾秒內就能完成,Hive可能會花費一分鐘。只有數據集足夠大,那麼啓動耗費的時間就忽略不計。

故Hive適用的場景是天天凌晨跑當天數據等等。它是類SQL語言,數據分析師能直接用,產品經理能直接用,拎出一個大學生培訓幾天也能用。效率快。

能夠將Hive做通用查詢,而用Pig定製UDF,作各類複雜分析。Hive和MySQL語法最接近。

Scribe, Chukwa For Weblog

Scribe是Facebook開源的日誌收集系統,在Facebook內部已經獲得的應用。

Chukwa是一個開源的用於監控大型分佈式系統的數據收集系統。

Using Mahout

已經介紹過了

Zookeeper Avro

Zookeeper,是Hadoop的一個重要組件,它被設計用來作協調服務的。主要是用來解決分佈式應用中常常遇到的一些數據管理問題,如:統一命名服務、狀態同步服務、集羣管理、分佈式應用配置項的管理等。

Avro是Hadoop中的一個子項目,它是一個基於二進制數據傳輸高性能的中間件。除外還有Kryo、protobuf等。

Storm: Hadoop Realtime

Storm是最新的一個開源框架

目的是大數據流的實時處理。它的特色是流,Hadoop的數據查詢,優化的再好,也要基於HDFS進行MR查詢,有沒有更快的方法呢?是有的。就是在數據產生時就去監控日誌,而後立刻進行計算。好比頁面訪問,有人點擊一下,我計算就+1,再有人點,+1。那麼這個頁面的UV我也就能實時知道了。

Hadoop擅長批處理,而Storm則是流式處理,吞吐確定是Hadoop優,而時延確定是Storm好。

Rhadoop, RHipe

將R和hadoop結合起來2種架構。

RHadoop包含三個包(rmr,rhdfs,rhbase),分別對應MapReduce,HDFS,HBase三個部分。

Spark還有個叫SparkR的。

rmr

RHadoop的一個包,和hadoop的MapReduce相關。

另外Hadoop的刪除命令也叫rmr,不知道做者是否是指代的這個……

Classandra

一種流行的NoSql數據庫

咱們經常說Cassandra是一個面向列(Column-Oriented)的數據庫,其實這不徹底對——數據是以鬆散結構的多維哈希表存儲在數據庫中;所謂鬆散結構,是指每行數據能夠有不一樣的列結構,而在關係型數據中,同一張表的全部行必須有相同的列。在Cassandra中可使用一個惟一識別號訪問行,因此咱們能夠更好理解爲,Cassandra是一個帶索引的,面向行的存儲。

Clipboard Image.png

Cassandra只須要你定義一個邏輯上的容器(Keyspaces)裝載列族(Column Families)。

Cassandra適合快速開發、靈活部署及拓展、支持高IO。它和HBase互爲競爭對手,Cassandra+Spark vs HBase+Hadoop,Cassandra強調AP ,Hbase強調CP。

MongoDB, Neo4j

MongoDB是文檔型NoSQL數據庫。

MongoDB若是不涉及Join,會很是靈活和優點。舉一個咱們最多見的電子商務網站做例子,不一樣的產品類目,產品規範、說明和介紹都不同,電子產品尿布零食手機卡等等,在關係型數據庫中設計表結構是災難,可是在MongoDB中就能自定義拓展。

再放一張和關係型數據庫對比的哲學圖吧:

Clipboard Image.png

Neo4j是最流行的圖形數據庫。

圖形數據庫如其名字,容許數據以節點的形式,應用圖形理論存儲實體之間的關係信息。

最多見的場景是社交關係鏈、凡是業務邏輯和關係帶點邊的都能用圖形數據庫。

Clipboard Image.png

跟關係數據庫相比,圖形數據庫最主要的優勢是解決了圖計算(業務邏輯)在關係數據庫上大量的join操做,好比讓你查詢:你媽媽的姐姐的舅舅的女兒的妹妹是誰?這得寫幾個Join啊。但凡關係,join操做的代價是巨大的,而GraphDB能很快地給出結果。

 

——————

我的水平通常,內容解讀不算好,可能部份內容有錯誤,歡迎指正。

本文寫的是文本挖掘、數據可視化和大數據。後續還只有一篇了。秦路.png

相關文章
相關標籤/搜索