前言
記得幾年前，曾經有人預測過未來最流行的三大技術：大資料、高併發、資料探勘。到現在來看，這三種技術的確也隨著這幾年網際網路的發展變得越發成熟和可靠。掌握這三種技術的人，不管是求職還是創業，都屬於香餑餑。一個很深的印象就是當年研究生畢業的時候，專業是資料探勘、大資料的學生都比較受各種企業的青睞，不管他是不是真的掌握了這些東西。雖然我對大部分高校的相關專業持懷疑態度，但是卻也不得不承認，這些專業的確改變了很多東西，也給很多學生鍍上了一層金。
自己一直從事的是Java EE中介軟體、基礎架構等方面的研發工作，對資料這一塊只是略知皮毛，在前東家的時候我也沒有機會接觸資料平臺。但由於現公司業務的原因，卻不得不去觸碰這一塊，到目前為止也就僅僅半年時間（其間穿插各種協調、管理的雜事）。因此，資料相關的東西對我來說完全是一個新的領域，算是離開了自己的舒適區。不過，逃離舒適區這個想想也挺興奮的。
資料
什麼是資料？
最近有一本很火的書叫《精益資料分析》，其核心的一個觀點就是：需要用資料驅動產品和公司的發展，而不能靠直覺或者拍腦袋。可見，資料是多麼的重要。在一個產品的生命週期中，會產生很多資料：使用者資訊、使用者行為資訊、ugc資料等等。這些資料表現形式可以為文字、圖片、日誌、視訊、音訊等等。
從技術角度來講，資料一般分為結構化資料、半結構化資料和非結構化資料。
- 結構化資料：指的是行資料庫可以儲存的，資料具有相同的欄位，以及相同的儲存大小,可以用二維表的邏輯結構來表達實現。
- 半結構化資料：半結構化資料，指的整體上是結構化資料形式，但欄位數目不定，資料結構和內容混雜在一起。
- 非結構化資料：不方便用二維表描述的資料，如各種文件、圖片、音/視訊等。
能用來幹什麼?-資料探勘
說到資料的作用，不得不提資料分析師這個職位。此職位一般來說傾向的是數學相關專業人士，使用資料來指導產品、運營、市場等工作，是公司中使用資料最多的人。在公司中，市場運營銷售這幾個部門也都是和資料關係很密切的。市場需要參考資料分析哪一個渠道推廣效果更好，運營部門需要根據資料分析什麼內容更能提高產品的活躍度，銷售部門則需要資料反映公司的收入情況。當然，除了這些，資料探勘就是另一個很重要的使用資料的方面了，可以使用資料對使用者進行行為分析，從而挖掘使用者的興趣，最終達到精準推薦、精準營銷的目的。
概括來看，資料的作用就是資料探勘，就是試圖從海量資料中找出有用的知識，也可以稱為“知識發現”。資料探勘的支撐技術主要包含統計學以及機器學習兩方面。從這個角度來看，資料主要有以下兩點作用：
- 資料統計：通過對資料的統計計算出一些和產品、使用者相關的指標，從而指導產品、市場、運營、銷售工作。
- 機器學習：使用相關技術讓機器通過已有的資料學習到新的有用的知識。比如：從已有的使用者行為資料分析得到使用者的興趣、愛好等資訊，從而進一步實現使用者個性化推薦。個性化推薦也是機器學習目前使用資料最為廣泛的一點。
資料庫&&資料倉儲
有了資料，就需要有存放資料的地方。資料庫和資料倉儲即存放資料庫的兩種形式。兩者在本質上沒有區別，都是為了儲存資料。
資料庫：面向業務設計，一般針對的是線上業務，儲存的是線上業務資料。如：Oracle、DB2、MySQL、Sybase、MS SQL Server等。可以分為：關係型資料庫和NoSql資料庫，其中後者又可分為KV資料庫、文件型資料庫、列資料庫。
資料倉儲：是資料庫概念的升級，面向分析，儲存的是歷史資料。從資料量來說，資料倉儲要比資料庫更龐大得多。主要用於資料探勘和資料分析，代表軟體為Hive。
ETL: 資料倉儲很多時候是需要從其他地方傳輸資料到資料倉儲，這個過程就是ETL：extract-抽取、transform-轉換、load-載入。
資料的生命週期
無論是歷史資料還是線上資料，都是有生命週期的。比如，對於一個產品的使用者活躍度統計業務，最近半年的資料是熱點資料，訪問較頻繁；而隨著時間的推移，慢慢的這些資料不再被頻繁關注，變為了一般資料；再隨著時間的推移，總有一天這些資料不再會被關注就成為了冷資料。
熱點資料→一般資料→冷資料，這就是資料的一個生命週期，對於不同的生命週期，所需要的技術選型也應該不一樣。
資料系統
不管是資料統計還是資料探勘，構建一個資料系統都是做好這些的前提。一般來說，構建一個完備的資料系統有以下幾點：
資料採集
無論是移動端還是web上，要做好資料採集集最重要的一點就是埋點。也就是要在你需要採集資料的地方做一個標記，向服務端發起一個日誌請求。當然，對於服務端能夠通過業務邏輯獲取的內容，原則上不要打點。比如，統計某一篇新聞的閱讀數目、點贊數，這些行為其實在使用者開啟此新聞、點贊時已經發起了服務端請求，不需要再埋一個點；此外，統計使用者數目這種，在使用者資料庫中就可以計算出來，也不需要埋點。埋點主要針對的是通過產品的業務邏輯無法獲取到的一些資料，如一個站點中某一個模組的pv、uv等。
埋點後向服務端發起日誌請求，這些請求在使用者量規模並不很大的架構設計中直接實時計算資料入庫即可，但是在使用者請求量很大的情況下，這種設計是有問題的，會增加業務請求的壓力，從而影響線上服務，因此好的設計應該是資料請求只形成一條日誌（一般通過nginx日誌實現）。因此，這裡很關鍵的一點就是如何將這些日誌收集起來進行處理。目前常用的技術有flume、Scribe、Chukwa等。其中，flume是目前比較成熟且應用比較廣泛的方案。
由於從資料來源到來的資料並不一定是我們處理需要的資料或者資料格式，因此這裡還有資料的清洗過程，包括分析，驗證，清洗，轉換，去重，
資料佇列
資料採集之後需要通過資料佇列傳輸，這裡的佇列主要起的是緩衝作用以及其他非採集資料來源的輸入(比如某一業務邏輯產生了一條統計報文，可以直接寫入佇列中)，可以採取本地佇列或者分散式佇列。目前，比較成熟的佇列有kafka、rabbitMQ等。其中，在資料統計領域kafka是應用比較廣泛的。
資料處理
對於採集到的資料，很多是需要計算才能得到需要的統計結果的。這時候就牽扯到了計算模型。這裡分為離線計算和實時計算兩種模型。離線計算針對實時來講，就是非實時的，可以定時排程進行計算的，一般來說是耗時比較長，對結果需求沒那麼實時的業務場景，適合非線上業務；實時計算則是需要在資料一到達就開始進行計算、處理的，適合對實時性要求高的一些業務場景，比如廣告的實時結算等。
資料儲存
服務端在資料統計中一個關鍵的功能是對採集到的內容進行儲存。對於中小規模的資料，使用mysql等傳統資料庫即可應對，大一點規模採用分表、分庫也能應對。再大一點的那就只能祭出大資料資料庫了。此外，資料的儲存結構也需要慎重考慮，尤其是在應對多維度查詢的時候，不合理的資料結構設計會導致低下的查詢效率和冗餘的儲存空間。
資料視覺化
資料儲存的下一步是要把資料展示出來，也就是資料視覺化。通常情況下，匯出excel表格是一種形式，此外，web端/移動端甚至pc端也需要展示資料的話，就引出了資料視覺化技術，尤其是在大資料量情況下如何更加高效快速地展示資料。
資料採集+資料佇列+資料處理+資料儲存+資料視覺化即組成了一個完整的資料系統。而從本質上來看，資料系統=資料+查詢，萬變不離其宗。
對於一般規模的產品，資料其實遠遠沒有達到需要使用大資料技術的地步。使用傳統的收集資料→定時排程程式計算，儲存到mysql中即可解決。如果有大的併發請求，那麼使用資料佇列做緩衝。當資料規模大到一定規模時，例如mysql資料庫在分表分庫的情況下，單表資料量還是達到了千萬的規模、單機儲存依然不夠或者單機計算已經慢到無法容忍。應對這種情況，就需要分散式技術出場了。
說到這裡，借用《計算廣告》一書中所講，對於資料分為三種：
- 小規模資料：此種資料可以通過取樣部分資料即可反映出資料的特徵。這時候，根本無需什麼大資料技術，單機規模的傳統資料系統架構即可應對這種場景。
- 中等規模資料：小規模資料無法反應資料特徵，當資料規模達到一定規模時，再增大特徵趨向於平穩，那麼此時也無需大資料技術的出場。
- 大規模資料：不能通過取樣來反應資料特徵，必須全量採集資料才能獲取到資料特徵。此時，就需要大資料技術來解決問題。
其中，大規模資料就不是一般架構可以解決的了的了。
大資料
麥肯錫的《大資料：創新、競爭和生產力的下一個前沿領域》中對大資料的定義：
大資料指的是規模超過現有資料庫工具獲取、儲存、管理和分析能力的資料集，並同時強調並不 是超過某個特定數量級的資料集才是大資料。
大資料系統通常被認為具有資料的五個主要特徵，通常稱為資料的5Vs。分別是大規模，多樣性，高效性、準確性和價值性。
相關技術
大資料是一個很寬泛的概念。當單機無法處理資料時，就有了大資料。而應對各種不同的業務場景，誕生了很多不同的軟體。完成一個功能完備的系統需要多個軟體的組合。
檔案/資料儲存
傳統的檔案儲存都是單機的，不能橫跨不同的機器，一般會使用raid做安全冗餘保障。但是還是無法從根本上解決問題。HDFS（Hadoop Distributed FileSystem）則是為了應對這種業務場景產生的，其基本原理來自於google的gfs，讓大量的資料可以橫跨成千上百萬臺機器。但是對使用者來說，看到的檔案和單機沒任何區別，已經遮蔽掉了底層細節。
除了檔案儲存，還有資料的儲存，即資料庫。傳統的mysql等資料庫，在儲存結構化、小規模資料的時候可以妥妥應對。但當需要儲存半結構化或者非結構化資料，或者用分表、分庫來解決儲存效能、空間問題帶來了複雜的管理、join時，就需要一種更好的資料庫的出現。大資料領域的Hbase就是為了這種場景產生的，其原理是google的BigTable。當然，hbase底層還是依賴於hdfs，是一個針對半結構化、非結構化、稀疏的資料的資料庫。
此外，hbase和hdfs相比起mysql這種毫秒級資料庫，其響應速度是很慢的。如果線上業務場景需要使用這些資料，那麼這時候就需要更好的資料庫的出現。elasticserach就是其中的佼佼者，當然，使用這種基於索引、高效的查詢資料庫，並不建議儲存全量資料(除非你錢有的是)。一般情況下，儲存熱點資料即可。
離線資料處理
大資料的處理是非常關鍵的一個環節。當單機的處理程式無法在期望的時間內處理完資料時，就需要考慮使用分散式技術了。於是就出現了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，是一個基於工作流的排程軟體，在一定程度上能夠滿足目前的離線排程需求。
實時計算
上面說的都是資料倉儲以及離線處理需求，也是低速資料處理需求。對於高速的資料處理，則需要引出實時計算的概念，也叫流式計算。目前，storm是比較成熟和流行的流式計算技術，spark streaming則是另外一種基於批量計算的流式計算技術。所謂流式計算，就是指資料過來的時候立刻進行處理，基本無延遲，但是不夠靈活，計算過的資料也不能回放，因此也無法替代上面說的資料倉儲和離線計算技術。
資源排程
綜上的所有東西都在同一個叢集上執行，需要達到一個有序工作的狀況。因此，需要一個資源排程系統來排程這些工作，MR2.0帶來的yarn就是負責此工作的一個框架。目前，docker on yarn，storm on yarn等on yarn技術的出現都得益於此框架，大大提高了大資料叢集的資源使用率。此外，mesos也是另一種資源排程框架。
協調服務
一個分散式系統能夠有條不紊的執行離不開協調服務的功勞。不管是hadoop還是storm、kakfa等，都是需要通過zookeeper進行協調的。zookeeper在分散式服務中扮演的角色就類似其字面意思-動物園管理員，而大資料的各個元件就類似動物園中的動物們。
叢集監控
叢集的穩定性對於一個資料系統是至關重要的。因此，叢集監控技術也是需要重點考慮的一點。目前，ganglia是對hadoop進行監控一個較好的工具。除了hadoop之外，ganglia也可以對kafka、zookeeper、storm等叢集進行監控。當然，只要支援jmx，任何叢集都是可以通過ganglia進行監控的。
資料視覺化
最近幾年，資料視覺化是一個很火的概念。尤其是大資料的視覺化，考慮到高效、速度以及體驗等等問題，並非是個很簡單的事情。目前，百度開源的echarts是比較好的一個視覺化前端解決方案，在大資料視覺化方面支援的也比較好。
《大資料：可擴充套件實時系統的原理和最佳實踐》一書的作者將big data相關的開源專案做了以下分類：
- 批量計算系統：延時較高、吞吐量大，如Hadoop。
- 序列化框架：為物件和欄位提供一種模式定義語言，實現傳輸通訊以及不同語言環境之間的轉化。如Thrift, Protocol Buffers, 和Avro。
- 支援任意存取的NoSQL資料庫：犧牲了SQL強大的表現力優勢，根據應用場景不同僅支援部分操作。按照CAP理論來說，就是犧牲C（一致性）或A（可用性）來實現AP或CP。如Cassandra, HBase, MongoDB,Voldemort, Riak, CouchDB等。
- 訊息/排隊系統：保證程式之間以容錯和非同步的方式傳遞訊息，在實時處理系統中非常重要。如Kestrel。
- 實時計算系統：高吞吐、低延時的流處理系統。如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)。這些檢視有效期一直到它們已經能通過批處理和服務層獲得時為止。
為了獲得一個完整結果，批處理和實時檢視都必須被同時查詢和融合(實時代表新資料)。
當然，架構的引入是不能照本宣科的，還是需要根據實際情況進行調整，以更好地適應業務場景。
資料統計
資料統計是資料首當其衝的一個作用。關於資料統計，有以下幾個關鍵點：
- 資料統計是業務導向的，需要和資料分析師、運營、市場等需求方做好充分的溝通，且很關鍵的一點要區分清楚哪些是真正的需求，哪些僅僅是臨時需求，對於前者需要以對待產品的態度去對待，後者則一過性產生結果即可。
- 資料統計一般來說都是pv、uv這些累加指標。使用資料庫自帶的累加器即可，如hbase/redis的incr。
- 資料統計在牽扯到使用者、IP時，有些業務是需要去重的。去重的方案有bitmap、bloomfilter等，其中，redis的hyperloglog在容許一定誤差的情況下使用比較廣泛。
- 使用者統計中的使用者質量模型是比較複雜的一個地方。這個地方需要一定的建模，才能做到更好的判斷一個使用者的質量。通常，把一個新增使用者一週內以及一週後的活躍情況作為這個使用者質量的判別標準。
個性化推薦
由於個性化推薦是“機器學習”的典型應用，因此這裡首先要講一下“機器學習”。
機器學習是為了讓機器具有人的學習能力，目的是建模隱藏的資料結構，然後做識別、預測、分類等。大多數情況下，這相當於將一組資料傳遞給演算法，並由演算法判斷出與這些資料的屬性相關的資訊，藉助這些資訊可以預測出未來有可能出現的其他資料。對於機器學習廣泛的一個定義是“利用經驗來改善計算機系統自身的效能”，而計算機中的經驗都是以資料的形式存在的。機器學習的一個典型過程就是機器利用它所認定的出現於資料中的重要特徵對資料進行“訓練”，並藉此得到一個模型。
此外，與機器學習相關的還有幾個名詞會被混淆或者概念不清。
- 集體智慧：簡稱集智，它是一種共享的或群體的智慧。百度百科、維基百科、百度知道、豬八戒網等都是目前使用集體智慧的一種形式；資料探勘、機器學習同樣需要大量群體的資料才能做出計算，是使用集體智慧的另一種形式。
- 資料探勘：資料探勘就是試圖從海量資料中找出有用的資訊。資料探勘支撐技術包含了機器學習、資料庫、統計學等。其中，資料庫提供資料管理技術，機器學習和統計學提供了資料分析技術。但是由於機器學習並不以大資料作為處理物件，因此資料探勘要對演算法進行改造，使得演算法效能和空間佔用達到實用的地步。
- 模式識別：模式識別是一種目的。傳統的模式識別的方法一般分為兩種：統計方法和句法方法。句法分析一般是不可學習的，而統計分析則是發展了不少機器學習的方法。因此機器學習給模式識別提供了資料分析技術。當然，也就是因為幾乎所有的非隨機資料都會包含這樣或者那樣的“模式(pattern)”，才使得機器學習的預測是可能的。
總之，機器學習也是使用資料的一個很關鍵的領域，典型應用有個性化推薦、CTR預估、模式識別等。牽扯到的演算法、技術非常多。如此部分開頭所說，其中的個性化推薦是應用最廣泛的領域，用到了很多機器學習相關技術。
從本質上看，個性化推薦和大家接觸很普遍的搜尋引擎是一樣的，同樣是為了解決資訊過載的問題。搜尋引擎某種意義上也是一個個性化推薦系統，其輸入特徵是從搜尋關鍵字可以直接得到的。而個性化推薦中，輸入特徵則是需要使用機器學習相關技術才能得到。
個性化推薦系統一般由日誌系統、推薦演算法、內容展示UI三部分組成。
- 日誌系統：這是推薦系統的輸入源，是一個推薦系統所有資訊的源頭。
- 推薦演算法：這是推薦系統的核心，根據輸入資料得出最終的推薦結果的具體過程就在這裡。
- 內容展示UI：對於推薦結果如何展示，也是一個值得權衡的地方。以更好地滿足推薦系統的目標，並能更好的收集使用者的行為資訊等。
其中，個性化推薦中最為核心的推薦演算法，目前比較流行的有以下幾種：
- 基於內容的推薦：根據內容本身的屬性(特徵向量)所作的推薦。
- 基於關聯規則的推薦：“啤酒與尿布”的方式，是一種動態的推薦，能夠實時對使用者的行為作出推薦。
- 協同過濾推薦：與基於關聯規則的推薦相比是一種靜態方式的推薦，是根據使用者已有的歷史行為作分析的基礎上做的推薦。可分為物品協同過濾、使用者協同過濾、基於模型的協同過濾。其中，基於模型的協同又可以分為以下幾種型別：基於距離的協同過濾；基於矩陣分解的協同過濾，即Latent Factor Model(SVD)；基於圖模型協同，即Graph，也叫社會網路圖模型。
個性化推薦系統的典型架構如下圖所示：
線上業務系統的日誌接入資料高速公路，再由資料高速公路迅速運轉到離線資料處理平臺和線上流計算平臺；離線資料處理平臺週期性地以批處理方式加工過去一段時間的資料，得到人群標籤和其他模型引數，存放在快取記憶體中，供線上業務系統使用，與此同時，線上流計算平臺實時對線上的日誌資料做處理，對離線計算出的資料進行補充、修正等；線上業務系統綜合離線特徵和線上特徵使用一定的邏輯得到輸出供業務使用，產生的日誌流入資料高速公路。
基於此框架，個性化推薦系統的典型流程如下：
其他更為詳細的，個性化推薦牽扯到的演算法、細節還有很多，留待後續推薦系統相關文章中再談。
總結
無論是網際網路還是其他領域的產品，資料的作用正變得越來越重要。綜合來看，資料統計和機器學習/個性化推薦是目前最關鍵的使用資料的領域。基於具體的需求，搭建合適的資料系統是解決問題的關鍵。其中，大資料是在應對大規模資料的情況下合適的技術選型架構。