數據雜談

數據

什麼是數據？

最近有一本很火的書叫《精益數據分析》，其核心的一個觀點就是：須要用數據驅動產品和公司的發展，而不能靠直覺或者拍腦殼。可見，數據是多麼的重要。在一個產品的生命週期中，會產生不少數據：用戶信息、用戶行爲信息、ugc數據等等。這些數據表現形式能夠爲文字、圖片、日誌、視頻、音頻等等。

從技術角度來說，數據通常分爲結構化數據、半結構化數據和非結構化數據。

• 結構化數據：指的是行數據庫能夠存儲的，數據具備相同的字段，以及相同的存儲大小,能夠用二維表的邏輯結構來表達實現。
• 半結構化數據：半結構化數據，指的總體上是結構化數據形式，但字段數目不定，數據結構和內容混雜在一塊兒。
• 非結構化數據：不方便用二維表描述的數據，如各類文檔、圖片、音/視頻等。

能用來幹什麼?-數據挖掘

說到數據的做用，不得不提數據分析師這個職位。此職位通常來講傾向的是數學相關專業人士，使用數據來指導產品、運營、市場等工做，是公司中使用數據最多的人。在公司中，市場運營銷售這幾個部門也都是和數據關係很密切的。市場須要參考數據分析哪個渠道推廣效果更好，運營部門須要根據數據分析什麼內容更能提升產品的活躍度，銷售部門則須要數據反映公司的收入狀況。固然，除了這些，數據挖掘就是另外一個很重要的使用數據的方面了，可使用數據對用戶進行行爲分析，從而挖掘用戶的興趣，最終達到精準推薦、精準營銷的目的。

歸納來看，數據的做用就是數據挖掘，就是試圖從海量數據中找出有用的知識，也能夠稱爲「知識發現」。數據挖掘的支撐技術主要包含統計學以及機器學習兩方面。從這個角度來看，數據主要有如下兩點做用：

• 數據統計：經過對數據的統計計算出一些和產品、用戶相關的指標，從而指導產品、市場、運營、銷售工做。
• 機器學習：使用相關技術讓機器經過已有的數據學習到新的有用的知識。好比：從已有的用戶行爲數據分析獲得用戶的興趣、愛好等信息，從而進一步實現用戶個性化推薦。個性化推薦也是機器學習目前使用數據最爲普遍的一點。

數據庫&&數據倉庫

有了數據，就須要有存放數據的地方。數據庫和數據倉庫即存放數據庫的兩種形式。二者在本質上沒有區別，都是爲了存儲數據。

• 數據庫：面向業務設計，通常針對的是在線業務，存儲的是在線業務數據。如：Oracle、DB二、MySQL、Sybase、MS SQL Server等。能夠分爲：關係型數據庫和NoSql數據庫，其中後者又可分爲KV數據庫、文檔型數據庫、列數據庫。

• 數據倉庫：是數據庫概念的升級，面向分析，存儲的是歷史數據。從數據量來講，數據倉庫要比數據庫更龐大得多。主要用於數據挖掘和數據分析，表明軟件爲Hive。

ETL: 數據倉庫不少時候是須要從其餘地方傳輸數據到數據倉庫，這個過程就是ETL：extract-抽取、transform-轉換、load-加載。

數據的生命週期

不管是歷史數據仍是線上數據，都是有生命週期的。好比，對於一個產品的用戶活躍度統計業務，最近半年的數據是熱點數據，訪問較頻繁；而隨着時間的推移，慢慢的這些數據再也不被頻繁關注，變爲了通常數據；再隨着時間的推移，總有一天這些數據再也不會被關注就成爲了冷數據。

熱點數據→通常數據→冷數據，這就是數據的一個生命週期，對於不一樣的生命週期，所須要的技術選型也應該不同。

數據系統

無論是數據統計仍是數據挖掘，構建一個數據系統都是作好這些的前提。通常來講，構建一個完備的數據系統有如下幾點：

1. 數據採集

   不管是移動端仍是web上，要作好數據採集集最重要的一點就是埋點。也就是要在你須要採集數據的地方作一個標記，向服務端發起一個日誌請求。固然，對於服務端可以經過業務邏輯獲取的內容，原則上不要打點。好比，統計某一篇新聞的閱讀數目、點贊數，這些行爲其實在用戶打開此新聞、點贊時已經發起了服務端請求，不須要再埋一個點；此外，統計用戶數目這種，在用戶數據庫中就能夠計算出來，也不須要埋點。埋點主要針對的是經過產品的業務邏輯沒法獲取到的一些數據，如一個站點中某一個模塊的pv、uv等。

   埋點後向服務端發起日誌請求，這些請求在用戶量規模並不很大的架構設計中直接實時計算數據入庫便可，可是在用戶請求量很大的狀況下，這種設計是有問題的，會增長業務請求的壓力，從而影響線上服務，所以好的設計應該是數據請求只造成一條日誌（通常經過nginx日誌實現）。所以，這裏很關鍵的一點就是如何將這些日誌收集起來進行處理。目前經常使用的技術有flume、Scribe、Chukwa等。其中，flume是目前比較成熟且應用比較普遍的方案。

   因爲從數據源到來的數據並不必定是咱們處理須要的數據或者數據格式，所以這裏還有數據的清洗過程，包括分析，驗證，清洗，轉換，去重，

2. 數據隊列

   數據採集以後須要經過數據隊列傳輸，這裏的隊列主要起的是緩衝做用以及其餘非採集數據源的輸入(好比某一業務邏輯產生了一條統計報文，能夠直接寫入隊列中)，能夠採起本地隊列或者分佈式隊列。目前，比較成熟的隊列有kafka、rabbitMQ等。其中，在數據統計領域kafka是應用比較普遍的。

3. 數據處理

   對於採集到的數據，不少是須要計算才能獲得須要的統計結果的。這時候就牽扯到了計算模型。這裏分爲離線計算和實時計算兩種模型。離線計算針對實時來說，就是非實時的，能夠定時調度進行計算的，通常來講是耗時比較長，對結果需求沒那麼實時的業務場景，適合非線上業務；實時計算則是須要在數據一到達就開始進行計算、處理的，適合對實時性要求高的一些業務場景，好比廣告的實時結算等。

4. 數據存儲

   服務端在數據統計中一個關鍵的功能是對採集到的內容進行存儲。對於中小規模的數據，使用mysql等傳統數據庫便可應對，大一點規模採用分表、分庫也能應對。再大一點的那就只能祭出大數據數據庫了。此外，數據的存儲結構也須要慎重考慮，尤爲是在應對多維度查詢的時候，不合理的數據結構設計會致使低下的查詢效率和冗餘的存儲空間。

5. 數據可視化

   數據存儲的下一步是要把數據展現出來，也就是數據可視化。一般狀況下，導出excel表格是一種形式，此外，web端/移動端甚至pc端也須要展現數據的話，就引出了數據可視化技術，尤爲是在大數據量狀況下如何更加高效快速地展現數據。

數據採集+數據隊列+數據處理+數據存儲+數據可視化即組成了一個完整的數據系統。而從本質上來看，數據系統=數據+查詢，萬變不離其宗。

對於通常規模的產品，數據其實遠遠沒有達到須要使用大數據技術的地步。使用傳統的收集數據→定時調度程序計算，存儲到mysql中便可解決。若是有大的併發請求，那麼使用數據隊列作緩衝。當數據規模大到必定規模時，例如mysql數據庫在分表分庫的狀況下，單表數據量仍是達到了千萬的規模、單機存儲依然不夠或者單機計算已經慢到沒法容忍。應對這種狀況，就須要分佈式技術出場了。

說到這裏，借用《計算廣告》一書中所講，對於數據分爲三種：

• 小規模數據：此種數據能夠經過採樣部分數據便可反映出數據的特徵。這時候，根本無需什麼大數據技術，單機規模的傳統數據系統架構便可應對這種場景。
• 中等規模數據：小規模數據沒法反應數據特徵，當數據規模達到必定規模時，再增大特徵趨向於平穩，那麼此時也無需大數據技術的出場。
• 大規模數據：不能經過採樣來反應數據特徵，必須全量採集數據才能獲取到數據特徵。此時，就須要大數據技術來解決問題。

其中，大規模數據就不是通常架構能夠解決的了的了。

大數據

麥肯錫的《大數據：創新、競爭和生產力的下一個前沿領域》中對大數據的定義：

大數據指的是規模超過現有數據庫工具獲取、存儲、管理和分析能力的數據集，並同時強調並非超過某個特定數量級的數據集纔是大數據。

 

大數據系統一般被認爲具備數據的五個主要特徵，一般稱爲數據的5Vs。分別是大規模，多樣性，高效性、準確性和價值性。

相關技術

大數據是一個很寬泛的概念。當單機沒法處理數據時，就有了大數據。而應對各類不一樣的業務場景，誕生了不少不一樣的軟件。完成一個功能完備的系統須要多個軟件的組合。

1. 文件/數據存儲

   傳統的文件存儲都是單機的，不能橫跨不一樣的機器，通常會使用raid作安全冗餘保障。可是仍是沒法從根本上解決問題。HDFS（Hadoop Distributed FileSystem）則是爲了應對這種業務場景產生的，其基本原理來自於google的gfs，讓大量的數據能夠橫跨成千上百萬臺機器。可是對用戶來講，看到的文件和單機沒任何區別，已經屏蔽掉了底層細節。

   除了文件存儲，還有數據的存儲，即數據庫。傳統的mysql等數據庫，在存儲結構化、小規模數據的時候能夠妥妥應對。但當須要存儲半結構化或者非結構化數據，或者用分表、分庫來解決存儲性能、空間問題帶來了複雜的管理、join時，就須要一種更好的數據庫的出現。大數據領域的Hbase就是爲了這種場景產生的，其原理是google的BigTable。固然，hbase底層仍是依賴於hdfs，是一個針對半結構化、非結構化、稀疏的數據的數據庫。

   此外，hbase和hdfs相比起mysql這種毫秒級數據庫，其響應速度是很慢的。若是線上業務場景須要使用這些數據，那麼這時候就須要更好的數據庫的出現。elasticserach就是其中的佼佼者，固然，使用這種基於索引、高效的查詢數據庫，並不建議存儲全量數據(除非你錢有的是)。通常狀況下，存儲熱點數據便可。

2. 離線數據處理

   大數據的處理是很是關鍵的一個環節。當單機的處理程序沒法在指望的時間內處理完數據時，就須要考慮使用分佈式技術了。因而就出現了MapReduce、Tez、Spark這些技術。MapReduce是第一代計算引擎，Tez和Spark是第二代。MapReduce的設計，採用了很簡化的計算模型，只有Map和Reduce兩個計算過程（中間用Shuffle串聯），用這個模型，已經能夠處理大數據領域很大一部分問題了。可是，MR模型很簡單，但也很笨重，有很多缺點，好比：編程模型很是複雜；計算過程磁盤IO過多。因而催生出了第二代數據處理技術，Tez、Spark這些鑑於MR模型的缺點，引入了內存cache之類新的feature，讓Map和Reduce之間的界限更模糊，數據交換更靈活，更少的磁盤讀寫，以便更方便地描述複雜算法，取得更高的吞吐量。

   如上面所說，編寫MR的編程複雜度很是高，因而就產生了Hive、Pig，在MR上面又抽象了一層更高級的語法出來，大大簡化了MR的編程複雜度。其中以Hive爲表明是Sql on xx的一個典型應用。之因此使用sql，一方面是容易編寫、容易維護；另外一方面SQL可讓沒有編程技能的諸如數據分析師均可以不依賴工程師就可使用數據。但因爲一開始的hive仍是基於MR之上的，所以，其運算速度仍是受到很多人的詬病。因而Hive on Tez / Spark和SparkSQL也出現了。它們都旨在用新一代通用計算引擎Tez或者Spark來跑SQL，這樣就避免了基於MR帶來的運算瓶頸。

   對於程序的離線數據處理，hive通常狀況下都可以知足需求。可是對於數據分析師的數據分析需求來講，這速度就真的有點龜速了。所以爲了應對數據分析的需求，Impala、Presto、Drill這些交互式sql引擎應運而生。這些系統的惟一目標就是快，可以讓用戶更快速地處理SQL任務，所以犧牲了通用性穩定性等特性。

   一個典型的數據倉庫系統能夠知足中低速數據處理的需求：底層HDFS，之上是MR、Tez、Spark,再上面則是Hive、Pig；此外，直接跑在HDFS上的Presto、Impala等也是另外一種方案。

   因爲是離線計算，所以是須要一個任務調度工具來定時調度計算過程的。比較流行的一個任務調度工具是azkaban，是一個基於工做流的調度軟件，在必定程度上可以知足目前的離線調度需求。

3. 實時計算

   上面說的都是數據倉庫以及離線處理需求，也是低速數據處理需求。對於高速的數據處理，則須要引出實時計算的概念，也叫流式計算。目前，storm是比較成熟和流行的流式計算技術，spark streaming則是另一種基於批量計算的流式計算技術。所謂流式計算，就是指數據過來的時候馬上進行處理，基本無延遲，可是不夠靈活，計算過的數據也不能回放，所以也沒法替代上面說的數據倉庫和離線計算技術。

4. 資源調度

   綜上的全部東西都在同一個集羣上運行，須要達到一個有序工做的情況。所以，須要一個資源調度系統來調度這些工做，MR2.0帶來的yarn就是負責此工做的一個框架。目前，docker on yarn，storm on yarn等on yarn技術的出現都得益於此框架，大大提升了大數據集羣的資源使用率。此外，mesos也是另外一種資源調度框架。

5. 協調服務

   一個分佈式系統可以有條不紊的運行離不開協調服務的功勞。無論是hadoop仍是storm、kakfa等，都是須要經過zookeeper進行協調的。zookeeper在分佈式服務中扮演的角色就相似其字面意思-動物園管理員，而大數據的各個組件就相似動物園中的動物們。

6. 集羣監控

   集羣的穩定性對於一個數據系統是相當重要的。所以，集羣監控技術也是須要重點考慮的一點。目前，ganglia是對hadoop進行監控一個較好的工具。除了hadoop以外，ganglia也能夠對kafka、zookeeper、storm等集羣進行監控。固然，只要支持jmx，任何集羣都是能夠經過ganglia進行監控的。

7. 數據可視化

   最近幾年，數據可視化是一個很火的概念。尤爲是大數據的可視化，考慮到高效、速度以及體驗等等問題，並不是是個很簡單的事情。目前，百度開源的echarts是比較好的一個可視化前端解決方案，在大數據可視化方面支持的也比較好。

《大數據：可擴展實時系統的原理和最佳實踐》一書的做者將big data相關的開源項目作了如下分類：

1. 批量計算系統：延時較高、吞吐量大，如Hadoop。
2. 序列化框架：爲對象和字段提供一種模式定義語言，實現傳輸通訊以及不一樣語言環境之間的轉化。如Thrift, Protocol Buffers, 和Avro。
3. 支持任意存取的NoSQL數據庫：犧牲了SQL強大的表現力優點，根據應用場景不一樣僅支持部分操做。按照CAP理論來講，就是犧牲C（一致性）或A（可用性）來實現AP或CP。如Cassandra, HBase, MongoDB,Voldemort, Riak, CouchDB等。
4. 消息/排隊系統：保證進程之間以容錯和異步的方式傳遞消息，在實時處理系統中很是重要。如Kestrel。
5. 實時計算系統：高吞吐、低延時的流處理系統。如Storm。

通常架構

下圖爲一個典型的大數據系統架構：

這裏還須要提到的是Lambda架構這個概念。Lambda架構是由Storm的做者Nathan Marz提出的一個實時大數據處理框架。目標是設計出一個能知足實時大數據系統關鍵特性的架構，包括有：高容錯、低延時和可擴展等。Lambda架構整合離線計算和實時計算，融合不可變性（Immunability），讀寫分離和複雜性隔離等一系列架構原則，可集成Hadoop，Kafka，Storm，Spark，Hbase等各種大數據組件。

Lambda架構是由三層組成：批處理層、服務層和速度層，整體可由query = function(alldata)這個公式來表示。

• 批處理層：Hadoop是理想的批處理層工具。特色是延時較高、高吞吐量，而且是append-only（沒有delete和update的概念）的。包括對所有數據集的預計算。
• 服務層：用於加載和顯示數據庫中的批處理視圖，以便用戶可以查詢。可使用Impala做爲這一層的工具（使用Hive元數據指向HDFS中的一個表）。
• 速度層：主要處理新數據和服務層更新形成的高延遲補償，利用流處理系統如 (Storm, Spark)計算實時視圖(HBase)。這些視圖有效期一直到它們已經能經過批處理和服務層得到時爲止。

爲了得到一個完整結果，批處理和實時視圖都必須被同時查詢和融合(實時表明新數據)。

固然，架構的引入是不能照本宣科的，仍是須要根據實際狀況進行調整，以更好地適應業務場景。

數據統計

數據統計是數據首當其衝的一個做用。關於數據統計，有如下幾個關鍵點：

1. 數據統計是業務導向的，須要和數據分析師、運營、市場等需求方作好充分的溝通，且很關鍵的一點要區分清楚哪些是真正的需求，哪些僅僅是臨時需求，對於前者須要以對待產品的態度去對待，後者則一過性產生結果便可。
2. 數據統計通常來講都是pv、uv這些累加指標。使用數據庫自帶的累加器便可，如hbase/redis的incr。
3. 數據統計在牽扯到用戶、IP時，有些業務是須要去重的。去重的方案有bitmap、bloomfilter等，其中，redis的hyperloglog在允許必定偏差的狀況下使用比較普遍。
4. 用戶統計中的用戶質量模型是比較複雜的一個地方。這個地方須要必定的建模，才能作到更好的判斷一個用戶的質量。一般，把一個新增用戶一週內以及一週後的活躍狀況做爲這個用戶質量的判別標準。

個性化推薦

因爲個性化推薦是「機器學習」的典型應用，所以這裏首先要講一下「機器學習」。

機器學習是爲了讓機器具備人的學習能力，目的是建模隱藏的數據結構，而後作識別、預測、分類等。大多數狀況下，這至關於將一組數據傳遞給算法，並由算法判斷出與這些數據的屬性相關的信息，藉助這些信息能夠預測出將來有可能出現的其餘數據。對於機器學習普遍的一個定義是「利用經驗來改善計算機系統自身的性能」，而計算機中的經驗都是以數據的形式存在的。機器學習的一個典型過程就是機器利用它所認定的出現於數據中的重要特徵對數據進行「訓練」，並藉此獲得一個模型。

此外，與機器學習相關的還有幾個名詞會被混淆或者概念不清。

• 集體智慧：簡稱集智，它是一種共享的或羣體的智能。百度百科、維基百科、百度知道、豬八戒網等都是目前使用集體智慧的一種形式；數據挖掘、機器學習一樣須要大量羣體的數據才能作出計算，是使用集體智慧的另外一種形式。
• 數據挖掘：數據挖掘就是試圖從海量數據中找出有用的信息。數據挖掘支撐技術包含了機器學習、數據庫、統計學等。其中，數據庫提供數據管理技術，機器學習和統計學提供了數據分析技術。可是因爲機器學習並不以大數據做爲處理對象，所以數據挖掘要對算法進行改造，使得算法性能和空間佔用達到實用的地步。
• 模式識別：模式識別是一種目的。傳統的模式識別的方法通常分爲兩種：統計方法和句法方法。句法分析通常是不可學習的，而統計分析則是發展了很多機器學習的方法。所以機器學習給模式識別提供了數據分析技術。固然，也就是由於幾乎全部的非隨機數據都會包含這樣或者那樣的「模式(pattern)」，才使得機器學習的預測是可能的。

總之，機器學習也是使用數據的一個很關鍵的領域，典型應用有個性化推薦、CTR預估、模式識別等。牽扯到的算法、技術很是多。如此部分開頭所說，其中的個性化推薦是應用最普遍的領域，用到了不少機器學習相關技術。

從本質上看，個性化推薦和你們接觸很廣泛的搜索引擎是同樣的，一樣是爲了解決信息過載的問題。搜索引擎某種意義上也是一個個性化推薦系統，其輸入特徵是從搜索關鍵字能夠直接獲得的。而個性化推薦中，輸入特徵則是須要使用機器學習相關技術才能獲得。

個性化推薦系統通常由日誌系統、推薦算法、內容展現UI三部分組成。

• 日誌系統：這是推薦系統的輸入源，是一個推薦系統全部信息的源頭。
• 推薦算法：這是推薦系統的核心，根據輸入數據得出最終的推薦結果的具體過程就在這裏。
• 內容展現UI：對於推薦結果如何展現，也是一個值得權衡的地方。以更好地知足推薦系統的目標，並能更好的收集用戶的行爲信息等。

其中，個性化推薦中最爲核心的推薦算法，目前比較流行的有如下幾種：

• 基於內容的推薦：根據內容自己的屬性(特徵向量)所做的推薦。
• 基於關聯規則的推薦：「啤酒與尿布」的方式，是一種動態的推薦，可以實時對用戶的行爲做出推薦。
• 協同過濾推薦：與基於關聯規則的推薦相比是一種靜態方式的推薦，是根據用戶已有的歷史行爲做分析的基礎上作的推薦。可分爲物品協同過濾、用戶協同過濾、基於模型的協同過濾。其中，基於模型的協同又能夠分爲如下幾種類型：基於距離的協同過濾；基於矩陣分解的協同過濾，即Latent Factor Model(SVD)；基於圖模型協同，即Graph，也叫社會網絡圖模型。

個性化推薦系統的典型架構以下圖所示：

在線業務系統的日誌接入數據高速公路，再由數據高速公路迅速運轉到離線數據處理平臺和在線流計算平臺；離線數據處理平臺週期性地以批處理方式加工過去一段時間的數據，獲得人羣標籤和其餘模型參數，存放在高速緩存中，供在線業務系統使用，與此同時，在線流計算平臺實時對線上的日誌數據作處理，對離線計算出的數據進行補充、修正等；在線業務系統綜合離線特徵和在線特徵使用必定的邏輯獲得輸出供業務使用，產生的日誌流入數據高速公路。

基於此框架，個性化推薦系統的典型流程以下：

其餘更爲詳細的，個性化推薦牽扯到的算法、細節還有不少，留待後續推薦系統相關文章中再談。

總結

不管是互聯網仍是其餘領域的產品，數據的做用正變得愈來愈重要。綜合來看，數據統計和機器學習/個性化推薦是目前最關鍵的使用數據的領域。基於具體的需求，搭建合適的數據系統是解決問題的關鍵。其中，大數據是在應對大規模數據的狀況下合適的技術選型架構。

參考資料

• 《計算廣告》
• 《推薦系統實踐》
• 知乎@Xiaoyu Ma的有關回答

 

轉：http://www.rowkey.me/blog/2016/02/23/data-talk/