近來(lái)數據中臺概念大火，大家對它的定義也五花八門(mén)，不一而足。但無(wú)論怎么定義，一個(gè)完善的數據技術(shù)架構必不可少。了解這些架構里每個(gè)部分的位置，功能和含義，不僅能讓我們更好了解數據產(chǎn)品的范圍和邊界，知道技術(shù)能幫我們實(shí)現什么，能怎么實(shí)現得更好，另一方面，很多技術(shù)的設計理念對我們認知世界，了解復雜系統也會(huì )有所裨益。因此這篇文章旨在梳理市面上常見(jiàn)的開(kāi)源技術(shù)方案，背后原理及應用場(chǎng)景，幫助產(chǎn)品經(jīng)理對大數據技術(shù)體系有個(gè)大致全面的了解。

一般來(lái)說(shuō)，我們將數據整個(gè)鏈條區分為四個(gè)環(huán)節，從數據采集傳輸，到數據存儲，再到數據計算&查詢(xún)，到后續的數據可視化及分析?？蚣軋D如下：

1. 數據采集傳輸

這個(gè)一般對應于公司的日志平臺，任務(wù)是將數據采集后緩存在某個(gè)地方，供后續的計算流程進(jìn)行消費使用。

針對不同的數據來(lái)源有各自的采集方式，從 APP/服務(wù)器 日志，到業(yè)務(wù)表，還有各種 API 接口及數據文件等等。其中因為日志數據有數據量多，數據結構多樣，產(chǎn)生環(huán)境復雜等特點(diǎn)，屬于「重點(diǎn)關(guān)照」的對象。目前市面針對日志采集的有 Flume，Logstash，Filebeat，Fluentd ，rsyslog 幾種常見(jiàn)的框架，我們挑應用較廣泛的前兩者介紹下：

Flume 是一款由 Cloudera 開(kāi)發(fā)的實(shí)時(shí)采集日志引擎，主打高并發(fā)，高速度，分布式海量日志采集。它是一種提供高可用、高可靠、分布式海量日志采集、聚合和傳輸的系統。Flume 支持在日志系統中定制各類(lèi)數據進(jìn)行發(fā)送，用于采集數據；同時(shí)，它支持對數據進(jìn)行簡(jiǎn)單處理，并寫(xiě)到各種數據接收方。目前有兩個(gè)版本，OG和NG，特點(diǎn)主要是：

1. 側重數據傳輸，有內部機制確保不會(huì )丟數據，用于重要日志場(chǎng)景

2. 由java開(kāi)發(fā)，沒(méi)有豐富的插件，主要靠二次開(kāi)發(fā)

3. 配置繁瑣，對外暴露監控端口有數據

Logstash 是 Elastic.co 旗下的一個(gè)開(kāi)源數據收集引擎，可動(dòng)態(tài)的統一不同的數據源的數據至目的地，搭配 ElasticSearch 進(jìn)行分析，Kibana 進(jìn)行頁(yè)面展示，是著(zhù)名的 ELK 技術(shù)棧中的「L」部分。特點(diǎn)主要是：

1. 內部沒(méi)有一個(gè)persist queue，異常情況可能會(huì )丟失部分數據

2. 由ruby編寫(xiě)，需要ruby環(huán)境，插件很多

3. 配置簡(jiǎn)單，偏重數據前期處理，分析方便

從兩者的設計思想來(lái)看，Flume 最初并不是為了采集日志而設計，而是定位在把數據傳入 HDFS 中，這和 Logstash 有根本的區別。所以它理所應當側重于數據的傳輸和安全，且需要更多的二次開(kāi)發(fā)和配置工作。而 Logstash 明顯側重先對日志數據進(jìn)行預處理，為后續的解析做鋪墊。它搭配 ELK 技術(shù)棧使用起來(lái)比較簡(jiǎn)單，更像是為你準備好的便當，開(kāi)盒即食。

我們以 Flume 為例子講些日志采集 Agent 是怎么工作的。

Flume 由三個(gè)部分組成：Source，Channel 和 Sink，對應于采集，緩存和保存三個(gè)環(huán)節。

其中，Source 組件用來(lái)采集各種類(lèi)型的數據源，如 directory、http、kafka 等。Channel 組件用來(lái)緩存數據，有 memory channel，JDBC channel和 kafka channel 三種。最后再通過(guò) Sink 組件進(jìn)行保存，分別支持 HDFS，HBase，Hive 和 Kafka 四種存儲方式。

下面結合一個(gè)大數據實(shí)時(shí)處理系統闡述下 Flume 在實(shí)際應用中所扮演的重要角色。該實(shí)時(shí)處理系統整體架構如下：通過(guò)將 Agent 部署在 Web 服務(wù)器，一旦發(fā)生新增的日志數據，就會(huì )被 Flume 程序監聽(tīng)到，并且最終會(huì )傳輸到 Kafka 的 Topic 中，再進(jìn)行后續的一系列操作。

Kafka 最初是由領(lǐng)英開(kāi)發(fā)，并隨后于 2011 年初開(kāi)源, 并于 2012 年 10 月 23 日由Apache Incubato 孵化出站。該項目的目標是為處理實(shí)時(shí)數據提供一個(gè)統一、高吞吐、低延遲的平臺。其持久化層本質(zhì)上是一個(gè)“按照分布式事務(wù)日志架構的大規模發(fā)布/訂閱消息隊列”，這使它作為企業(yè)級基礎設施來(lái)處理流式數據非常有價(jià)值。

2. 數據存儲

數據庫存儲方面，有單機/分布式、關(guān)系型/非關(guān)系型、列式存儲/行式存儲三個(gè)維度的劃分，各種維度交叉下都有對應產(chǎn)品來(lái)解決某個(gè)場(chǎng)景下的需求。

在數據量較小的情況下，一般采取單機數據庫，如應用非常廣泛，技術(shù)成熟的 MySQL。數據量大到一定程度后，就必須采取分布式系統了。目前業(yè)界最知名的就是 Apache 基金會(huì )名下的 Hadoop 系統，它基本可以作為大數據時(shí)代存儲計算的經(jīng)典模型。

HDFS 作為 Hadoop 里的分布式文件系統，為 HBase 和 Hive 們提供了高可靠性的底層存儲支持，對應于 Google GFS 的開(kāi)源實(shí)現。一般也會(huì )用于一些批次分析的場(chǎng)景。

HBase 是 Hadoop 數據庫，作為基于列的非關(guān)系型數據庫運行在 HDFS 上。它具備 HDFS 缺乏的隨機讀寫(xiě)能力，因此比較適合實(shí)時(shí)分析。HBase 以 Google BigTable為藍本，以 Key-Value 形式存儲，能快速在主機內數十億行數據中定位所需的數據并訪(fǎng)問(wèn)它。

Hive 和 Pig 都是集成在 Hadoop 頂層的查詢(xún)語(yǔ)言，提供靜態(tài)數據的動(dòng)態(tài)查詢(xún)，支持類(lèi) SQL 語(yǔ)言，底層經(jīng)過(guò)編譯轉為 MapReduce 程序，省去了自己編寫(xiě) MR 程序的繁瑣。區別是 Hive SQL 是類(lèi) SQL 的查詢(xún)語(yǔ)言，要求數據存儲于表中，而 Pig 是面向數據流的一個(gè)程序語(yǔ)言，常用于開(kāi)發(fā)簡(jiǎn)潔的腳本來(lái)轉換數據流從而嵌入到較大的應用程序中。

MR 開(kāi)創(chuàng )了分布時(shí)代計算的先河，使得大批量數據處理成為可能。簡(jiǎn)單來(lái)講，就是將比較龐大的計算任務(wù)先分組，再匯總，提高計算效率。舉例來(lái)講，如果你新家需要裝修，要在不同地方購置很多東西。你一個(gè)人（單機）去買(mǎi)估計得花十天?，F在叫了一堆小伙伴（分布式），每個(gè)人負責去一個(gè)地方買(mǎi)東西（Map），最后再拿到家里分類(lèi)匯總（Reduce），一天就搞定了。

上圖中的其他工具是為了保證整個(gè)大數據計算存儲系統更加健壯和開(kāi)放，如 Zookeeper 提供了穩定服務(wù)和 failover 機制，Sqoop 則為 Hadoop 提供了方便的 RDBMS（關(guān)系型數據庫）數據導入功能，使得傳統數據庫數據向 HBase 中遷移變的非常方便。

值得一提的是，Hadoop 生態(tài)其實(shí)是建立在 Google 2003 年發(fā)表的三大論文的基礎之上?？赡苁钱敃r(shí) Google 有意改善業(yè)內落后的現狀，讓大家稍微跟得上他的腳步才發(fā)布的論文…這么多年過(guò)去了，不知道 Google 內部對數據的理解和使用又到了什么樣的高度。

3. 數據計算&查詢(xún)

大數據處理場(chǎng)景可分為批處理和流處理兩個(gè)，分別對應離線(xiàn)分析和實(shí)時(shí)分析。常見(jiàn)框架分類(lèi)有：

1. 僅批處理框架：Hadoop MapReduce

2. 僅流處理框架：Storm，Samza

3. 混合框架：Spark，Flink

篇幅所限，除了上文已經(jīng)提到的 Hadoop 生態(tài)外，我們再簡(jiǎn)單科普下 Spark：

Apache Spark 是一種包含流處理能力的下一代批處理框架。

批處理模式下，Spark 與 MapReduce 不同，它將數據處理工作全部在內存中進(jìn)行，計算性能大幅改善。流處理模式下，Spark 主要通過(guò) Spark Streaming 實(shí)現了一種叫做微批（Micro-batch）的概念。該技術(shù)可以將數據流視作一系列非常小的“批”，借此即可通過(guò)批處理引擎的原生語(yǔ)義進(jìn)行處理。這種方式的實(shí)際效果非常好，但相比真正的流處理框架在性能方面依然存在不足。

綜上所述，Spark是多樣化工作負載處理任務(wù)的最佳選擇。Spark批處理能力以更高內存占用為代價(jià)提供了無(wú)與倫比的速度優(yōu)勢。對于重視吞吐率而非延遲的工作負載，則比較適合使用 Spark Streaming 作為流處理解決方案。

而 Flink 作為更新一代的處理框架，擁有更快的計算能力，更低的延遲，已經(jīng)慢慢嶄露頭角。不過(guò)一個(gè)框架的應用，特別是開(kāi)源框架，需要足夠長(cháng)的時(shí)間進(jìn)行運行，測試和優(yōu)化。大數據技術(shù)在開(kāi)源社區的推動(dòng)下，迭代日新月異。在不久的將來(lái)，相信 Flink 會(huì )像 Spark 取代 Storm 一樣，逐漸成為大數據處理技術(shù)的主流。

經(jīng)過(guò)處理后的數據，還需要有高效的查詢(xún)引擎才能被用戶(hù)接觸和使用。目前 OLAP 的查詢(xún)技術(shù)框架大致可分為三類(lèi)：

1. 基于 HBase 做預聚合：如 Opentsdb, Kylin等，均需指定預聚合的指標，在數據接入的時(shí)候進(jìn)行聚合運算，適合相對固定，維度較多的業(yè)務(wù)報表類(lèi)需求

2. 基于 Parquet 做列式存儲：如 Presto, Drill，Impala等，基本是完全基于內存的并行計算，Parquet 系能降低存儲空間，提高IO效率，以離線(xiàn)處理為主，很難提高數據寫(xiě)的實(shí)時(shí)性，超大表的 Join 支持可能不夠好

3. 基于 Lucene 做外部索引：如 ElasticSearch，Solr等，能夠滿(mǎn)足的的查詢(xún)場(chǎng)景遠多于傳統的數據庫存儲，但對于日志、行為類(lèi)時(shí)序數據，所有的搜索請求都也必須搜索所有的分片，另外，對于聚合分析場(chǎng)景的支持也是軟肋

我們以常見(jiàn)的 Presto，Druid，Kylin三個(gè)模型來(lái)講講各自的特點(diǎn)：

1. Presto：由 Facebook 開(kāi)源，是一個(gè)分布式數據查詢(xún)框架，原生集成了 Hive、 Hbase 和關(guān)系型數據庫。它背后所使用的執行模式與Hive有根本的不同，并沒(méi)有使用 MapReduce。因其所有的處理都在內存中完成（與上文的 Spark 類(lèi)似），大部分場(chǎng)景下要比 Hive 快一個(gè)數量級

2. Druid：由 MetaMarket 開(kāi)源，是一個(gè)分布式、面向列式存儲的準實(shí)時(shí)分析數據存儲系統，延遲性最細顆粒度可到 5 分鐘。它能夠在高并發(fā)環(huán)境下，保證海量數據查詢(xún)分析性能，同時(shí)又提供海量實(shí)時(shí)數據的查詢(xún)、分析與可視化功能

3. Kylin：Cube 預計算技術(shù)是其核心，基本思路是預先對數據作多維索引，查詢(xún)時(shí)只掃描索引而不訪(fǎng)問(wèn)原始數據從而提速。劣勢在于每次增減維度必須對 Cube 進(jìn)行歷史數據重算追溯，非常消耗時(shí)間。據說(shuō) Kylingence 在前幾天的新品發(fā)布會(huì )上已經(jīng)解決了這個(gè)問(wèn)題，拭目以待

下圖引自快手在 OLAP 技術(shù)選型時(shí)的評價(jià)，以供大家參考：

很多時(shí)候，在計算和查詢(xún)這塊沒(méi)有明顯的邊界區分。這里為了方便闡述分成了兩個(gè)部分。事實(shí)上，對于技術(shù)能力比較強的團隊，可以針對這些開(kāi)源系統進(jìn)行魔改，比如采用 Kylin 的預計算能力+Druid 的查詢(xún)引擎，來(lái)提高查詢(xún)的速度等等。

4. 數據可視化及分析

在數據可視化這塊，一般會(huì )采取三個(gè)途徑來(lái)進(jìn)行數據展示。最基礎的利用開(kāi)源的圖表庫，如國外的 HighCharts、D3，百度的 ECharts，還有阿里 Antv 的 G2、G6、F2 等。往上一層是各個(gè)知名公司開(kāi)源的可視化框架，如 Airbnb 的 Superset，Redash，Metabase 等等。這些框架一般能夠滿(mǎn)足從數據源接入，自助制作報表和報表整理展示的功能，接入起來(lái)更加方便。再往上一層就是商用的可視化軟件，如國外的 Tableau，Qlik ，國內的 FineReport，永洪 BI 等等。這種軟件需要付費，但都具備更豐富的可視化功能并提供一些技術(shù)支持，對于那些沒(méi)有精力折騰可視化的公司會(huì )是個(gè)不錯的選擇。

理解整個(gè)圖表開(kāi)源生態(tài)，我們得先了解下SVG 和 Canvas 這兩個(gè)瀏覽器提供的原生能力。SVG 全稱(chēng)叫可縮放矢量圖，跟 HTML 一樣，有自己的命名空間，使用 XML 標簽來(lái)繪圖。而 Canvas 是 HTML5 中的新標簽，用于客戶(hù)端的圖形繪制，有一個(gè)基于 JavaScript 的繪圖 API。

D3.js 全稱(chēng)是 Data-DrivenDocuments，支持 SVG 和 Canvas。相對于其他產(chǎn)品，它更偏底層，并沒(méi)有對圖表進(jìn)行歸類(lèi)。開(kāi)發(fā)者可以通過(guò) D3 豐富的類(lèi)庫來(lái)方便的操作 DOM，繪制任何想繪制的圖形，以增加開(kāi)發(fā)復雜度的代價(jià)，覆蓋更加全面的可視化場(chǎng)景。

而國外的 HighCharts 是基于 SVG 開(kāi)發(fā)的圖表庫，ECharts 和 G2 則均基于 Canvas。ECharts 有完整的圖表封裝，開(kāi)箱即用，而 G2 則是一套基于可視化編碼的圖形語(yǔ)法，以數據驅動(dòng)，具有高度的易用性和擴展性。阿里后續基于 G2 又往上封裝了一套基于 React 的圖表庫 Bizcharts，主打電商業(yè)務(wù)圖表可視化，沉淀電商業(yè)務(wù)線(xiàn)的可視化規范。在 React 項目中實(shí)現常見(jiàn)圖表和自定義圖表。

ECharts 和 G2 的對比可借用 ECharts 作者的一句話(huà)，G2 是面粉，ECharts 是面條，皆微小但美好。

這里主要介紹下業(yè)內比較出名的 Superset 和 Metabase。前者的方案更加完善，支持集合不同數據源形成對應的指標，再通過(guò)豐富的圖表類(lèi)型進(jìn)行可視化。在時(shí)間序列分析上比較出色，支持移動(dòng)平均及周期偏移等分析方法。同時(shí)與 Druid 深度集成，可以快速解析大規模數據集。劣勢則是不支持分組管理報表，一旦報表多了使用起來(lái)很麻煩。且不提供圖表下鉆及聯(lián)動(dòng)功能，權限管理也不夠友好。

Metabase 則比較注重非技術(shù)人員（如產(chǎn)品經(jīng)理和運營(yíng)人員）的使用體驗，讓他們能自由地探索數據，回答自己的問(wèn)題，界面相對來(lái)講更加美觀(guān)。在權限管理上做得較為完善，甚至無(wú)需賬號也可以對外共享圖表和數據內容。Dashboard 支持分類(lèi)，便于管理報表。劣勢在時(shí)間序列分析上不支持不同日期對比，還需要自定義SQL 實(shí)現。每次查詢(xún)僅能針對一個(gè)數據庫查詢(xún)，操作比較繁瑣。

在數據挖掘這塊，目前主要集中在商用公司這塊，通過(guò)和某些行業(yè)深度合作，從而訓練和深化自己的學(xué)習模型，這里不多贅述。