作者簡介：陳新濤，現任轉轉資料負責人，曾任美團外賣首任資料產品經理，著有公眾號「三生萬數」及知識星球「資料人修煉之路」，歡迎關注交流
近來資料中臺概念大火，大家對它的定義也五花八門，不一而足。但無論怎麼定義，一個完善的資料技術架構必不可少。瞭解這些架構裡每個部分的位置，功能和含義，
不僅能讓我們更好了解資料產品的範圍和邊界，知道技術能幫我們實現什麼，能怎麼實現得更好，另一方面，很多技術的設計理念對我們認知世界，瞭解複雜系統也會有所裨益。
因此這篇文章旨在梳理市面上常見的開源技術方案，背後原理及應用場景，幫助產品經理對大資料技術體系有個大致全面的瞭解。
一般來說，我們將資料整個鏈條區分為四個環節，從資料採集傳輸，到資料儲存，再到資料計算&查詢，到後續的資料視覺化及分析。框架圖如下：
1。 資料採集傳輸
這個一般對應於公司的日誌平臺，任務是將資料採集後快取在某個地方，供後續的計算流程進行消費使用。
針對不同的資料來源有各自的採集方式，從 APP/伺服器 日誌，到業務表，還有各種 API 介面及資料檔案等等。其中因為日誌資料有資料量多，資料結構多樣，產生環境複雜等特點，屬於「重點關照」的物件。目前市面針對日誌採集的有 Flume，Logstash，Filebeat，Fluentd ，rsyslog 幾種常見的框架，我們挑應用較廣泛的前兩者介紹下：
1。1 Flume 和 Logstash
Flume 是一款由 Cloudera 開發的實時採集日誌引擎，主打高併發，高速度，分散式海量日誌採集。它是一種提供高可用、高可靠、分散式海量日誌採集、聚合和傳輸的系統。Flume 支援在日誌系統中定製各類資料進行傳送，用於採集資料；同時，它支援對資料進行簡單處理，並寫到各種資料接收方。目前有兩個版本，OG和NG，特點主要是：
側重資料傳輸，有內部機制確保不會丟資料，用於重要日誌場景
由java開發，沒有豐富的外掛，主要靠二次開發
配置繁瑣，對外暴露監控埠有資料
Logstash 是
http：//
Elastic。co
旗下的一個開源資料收集引擎，可動態的統一不同的資料來源的資料至目的地，搭配 ElasticSearch 進行分析，Kibana 進行頁面展示，是著名的 ELK 技術棧中的「L」部分。特點主要是：
內部沒有一個persist queue，異常情況可能會丟失部分資料
由ruby編寫，需要ruby環境，外掛很多
配置簡單，偏重資料前期處理，分析方便
從兩者的設計思想來看，Flume 最初並不是為了採集日誌而設計，而是定位在把資料傳入 HDFS 中，這和 Logstash 有根本的區別。所以它理所應當側重於資料的傳輸和安全，且需要更多的二次開發和配置工作。而 Logstash 明顯側重先對日誌資料進行預處理，為後續的解析做鋪墊。它搭配 ELK 技術棧使用起來比較簡單，更像是為你準備好的便當，開盒即食。
1。2 日誌採集如何工作
我們以 Flume 為例子講些日誌採集 Agent 是怎麼工作的。
Flume 由三個部分組成：Source，Channel 和 Sink，對應於採集，快取和儲存三個環節。
其中，Source 元件用來採集各種型別的資料來源，如 directory、http、kafka 等。Channel 元件用來快取資料，有 memory channel，JDBC channel和 kafka channel 三種。最後再透過 Sink 元件進行儲存，分別支援 HDFS，HBase，Hive 和 Kafka 四種儲存方式。
下面結合一個大資料實時處理系統闡述下 Flume 在實際應用中所扮演的重要角色。該實時處理系統整體架構如下：透過將 Agent 部署在 Web 伺服器，一旦發生新增的日誌資料，就會被 Flume 程式監聽到，並且最終會傳輸到 Kafka 的 Topic 中，再進行後續的一系列操作。
1。3 資料傳輸 Kafka
Kafka 最初是由領英開發，並隨後於 2011 年初開源， 並於 2012 年 10 月 23 日由Apache Incubato 孵化出站。該專案的目標是為處理實時資料提供一個統一、高吞吐、低延遲的平臺。其持久化層本質上是一個“按照分散式事務日誌架構的大規模釋出/訂閱訊息佇列”，這使它作為企業級基礎設施來處理流式資料非常有價值。
2。 資料儲存
資料庫儲存方面，有單機/分散式、關係型/非關係型、列式儲存/行式儲存三個維度的劃分，各種維度交叉下都有對應產品來解決某個場景下的需求。
在資料量較小的情況下，一般採取單機資料庫，如應用非常廣泛，技術成熟的 MySQL。資料量大到一定程度後，就必須採取分散式系統了。目前業界最知名的就是 Apache 基金會名下的 Hadoop 系統，它基本可以作為大資料時代儲存計算的經典模型。
HDFS
HDFS 作為 Hadoop 裡的分散式檔案系統，為 HBase 和 Hive 們提供了高可靠性的底層儲存支援，對應於 Google GFS 的開源實現。一般也會用於一些批次分析的場景。
HBase
HBase 是 Hadoop 資料庫，作為基於列的非關係型資料庫執行在 HDFS 上。它具備 HDFS 缺乏的隨機讀寫能力，因此比較適合實時分析。HBase 以 Google BigTable為藍本，以 Key-Value 形式儲存，能快速在主機內數十億行資料中定位所需的資料並訪問它。
Hive 和 Pig
Hive 和 Pig 都是整合在 Hadoop 頂層的查詢語言，提供靜態資料的動態查詢，支援類 SQL 語言，底層經過編譯轉為 MapReduce 程式，省去了自己編寫 MR 程式的繁瑣。
區別是 Hive SQL 是類 SQL 的查詢語言，要求資料儲存於表中，而 Pig 是面向資料流的一個程式語言，常用於開發簡潔的指令碼來轉換資料流從而嵌入到較大的應用程式中。
MapReduce
MR 開創了分佈時代計算的先河，使得大批次資料處理成為可能。簡單來講，就是將比較龐大的計算任務先分組，再彙總，提高計算效率。舉例來講，如果你新家需要裝修，要在不同地方購置很多東西。你一個人（單機）去買估計得花十天。現在叫了一堆小夥伴（分散式），每個人負責去一個地方買東西（Map），最後再拿到家裡分類彙總（Reduce），一天就搞定了。
其他輔助工具
上圖中的其他工具是為了保證整個大資料計算儲存系統更加健壯和開放，如 Zookeeper 提供了穩定服務和 failover 機制，Sqoop 則為 Hadoop 提供了方便的 RDBMS（關係型資料庫）資料匯入功能，使得傳統資料庫資料向 HBase 中遷移變的非常方便。
值得一提的是，Hadoop 生態其實是建立在 Google 2003 年發表的三大論文的基礎之上。可能是當時 Google 有意改善業內落後的現狀，讓大家稍微跟得上他的腳步才釋出的論文…這麼多年過去了，不知道 Google 內部對資料的理解和使用又到了什麼樣的高度。
3。 資料計算&查詢
3。1 批計算和流計算
大資料處理場景可分為批處理和流處理兩個，分別對應離線分析和實時分析。常見框架分類有：
僅批處理框架：Hadoop MapReduce
僅流處理框架：Storm，Samza
混合框架：Spark，Flink
篇幅所限，除了上文已經提到的 Hadoop 生態外，我們再簡單科普下 Spark：
3。2 Spark 和 Flink
Apache Spark 是一種包含流處理能力的下一代批處理框架。
批處理模式下，Spark 與 MapReduce 不同，它將資料處理工作全部在記憶體中進行，計算效能大幅改善。流處理模式下，Spark 主要透過 Spark Streaming 實現了一種叫做微批（Micro-batch）的概念。該技術可以將資料流視作一系列非常小的“批”，藉此即可透過批處理引擎的原生語義進行處理。
這種方式的實際效果非常好，但相比真正的流處理框架在效能方面依然存在不足。
綜上所述，
Spark是多樣化工作負載處理任務的最佳選擇。Spark批處理能力以更高記憶體佔用為代價提供了無與倫比的速度優勢。對於重視吞吐率而非延遲的工作負載，則比較適合使用 Spark Streaming 作為流處理解決方案。
而 Flink 作為更新一代的處理框架，擁有更快的計算能力，更低的延遲，已經慢慢嶄露頭角。不過一個框架的應用，特別是開源框架，需要足夠長的時間進行執行，測試和最佳化。大資料技術在開源社群的推動下，迭代日新月異。在不久的將來，相信 Flink 會像 Spark 取代 Storm 一樣，逐漸成為大資料處理技術的主流。
3。3 資料查詢
經過處理後的資料，還需要有高效的查詢引擎才能被使用者接觸和使用。目前 OLAP 的查詢技術框架大致可分為三類：
基於 HBase 做預聚合：如
Opentsdb, Kylin
等，均需指定預聚合的指標，在資料接入的時候進行聚合運算，適合相對固定，維度較多的業務報表類需求
基於 Parquet 做列式儲存：如
Presto, Drill，Impala
等，基本是完全基於記憶體的平行計算，Parquet 系能降低儲存空間，提高IO效率，以離線處理為主，很難提高資料寫的實時性，超大表的 Join 支援可能不夠好
基於 Lucene 做外部索引：如
ElasticSearch，Solr
等，能夠滿足的的查詢場景遠多於傳統的資料庫儲存，但對於日誌、行為類時序資料，所有的搜尋請求都也必須搜尋所有的分片，另外，對於聚合分析場景的支援也是軟肋
我們以常見的
Presto，Druid，Kylin
三個模型來講講各自的特點：
Presto：由 Facebook 開源，是一個分散式資料查詢框架，原生集成了 Hive、 Hbase 和關係型資料庫。它背後所使用的執行模式與Hive有根本的不同，並沒有使用 MapReduce。
因其所有的處理都在記憶體中完成（與上文的 Spark 類似），大部分場景下要比 Hive 快一個數量級
Druid：由 MetaMarket 開源，是
一個分散式、面向列式儲存的準實時分析資料儲存系統
，延遲性最細顆粒度可到 5 分鐘。它能夠在高併發環境下，保證海量資料查詢分析效能，同時又提供海量實時資料的查詢、分析與視覺化功能
Kylin：
Cube 預計算技術是其核心，基本思路是預先對資料作多維索引，查詢時只掃描索引而不訪問原始資料從而提速
。劣勢在於每次增減維度必須對 Cube 進行歷史資料重算追溯，非常消耗時間。據說 Kylingence 在前幾天的新品釋出會上已經解決了這個問題，拭目以待
下圖引自快手在 OLAP 技術選型時的評價，以供大家參考：
很多時候，在計算和查詢這塊沒有明顯的邊界區分。這裡為了方便闡述分成了兩個部分。事實上，對於技術能力比較強的團隊，可以針對這些開源系統進行魔改，比如採用 Kylin 的預計算能力+Druid 的查詢引擎，來提高查詢的速度等等。
4。 資料視覺化及分析
在資料視覺化這塊，一般會採取三個途徑來進行資料展示。最基礎的利用開源的圖表庫，如國外的 HighCharts、D3，百度的 ECharts，還有阿里 Antv 的 G2、G6、F2 等。往上一層是各個知名公司開源的視覺化框架，如 Airbnb 的 Superset，Redash，Metabase 等等。這些框架一般能夠滿足從資料來源接入，自助製作報表和報表整理展示的功能，接入起來更加方便。再往上一層就是商用的視覺化軟體，如國外的 Tableau，Qlik ，國內的 FineReport，永洪 BI 等等。這種軟體需要付費，但都具備更豐富的視覺化功能並提供一些技術支援，對於那些沒有精力折騰視覺化的公司會是個不錯的選擇。
4。1 圖表庫
理解整個圖表開源生態，我們得先了解下
SVG 和 Canvas 這兩個瀏覽器提供的原生能力
。SVG 全稱叫可縮放向量圖，跟 HTML 一樣，有自己的名稱空間，使用 XML 標籤來繪圖。而 Canvas 是 HTML5 中的新標籤，用於客戶端的圖形繪製，有一個基於 JavaScript 的繪圖 API。
D3。js 全稱是 Data-DrivenDocuments，支援 SVG 和 Canvas。相對於其他產品，
它更偏底層，並沒有對圖表進行歸類。開發者可以透過 D3 豐富的類庫來方便的操作 DOM，繪製任何想繪製的圖形，以增加開發複雜度的代價，覆蓋更加全面的視覺化場景。
而國外的 HighCharts 是基於 SVG 開發的圖表庫，ECharts 和 G2 則均基於 Canvas。ECharts 有完整的圖表封裝，開箱即用，而 G2 則是一套基於視覺化編碼的圖形語法，以資料驅動，具有高度的易用性和擴充套件性。阿里後續基於 G2 又往上封裝了一套基於 React 的圖表庫 Bizcharts，主打電商業務圖表視覺化，沉澱電商業務線的視覺化規範。在 React 專案中實現常見圖表和自定義圖表。
ECharts 和 G2 的對比可借用 ECharts 作者的一句話，
G2 是麵粉，ECharts 是麵條，皆微小但美好。
4。2 視覺化框架
這裡主要介紹下業內比較出名的 Superset 和 Metabase。前者的方案更加完善，支援集合不同資料來源形成對應的指標，再透過豐富的圖表型別進行視覺化。在時間序列分析上比較出色，支援移動平均及週期偏移等分析方法。同時與 Druid 深度整合，可以快速解析大規模資料集。劣勢則是不支援分組管理報表，一旦報表多了使用起來很麻煩。且不提供圖表下鑽及聯動功能，許可權管理也不夠友好。
Metabase 則比較注重非技術人員（如產品經理和運營人員）的使用體驗，讓他們能自由地探索資料，回答自己的問題，介面相對來講更加美觀。在許可權管理上做得較為完善，甚至無需賬號也可以對外共享圖表和資料內容。Dashboard 支援分類，便於管理報表。劣勢在時間序列分析上不支援不同日期對比，還需要自定義SQL 實現。每次查詢僅能針對一個數據庫查詢，操作比較繁瑣。
在資料探勘這塊，目前主要集中在商用公司這塊，透過和某些行業深度合作，從而訓練和深化自己的學習模型，這裡不多贅述。
文章的最後，鳴謝網路上各位知識的分享者，以下是主要參考內容的連結，大家可以自行查閱。本人非技術出身，所有資料均系網上整理而成，是網際網路的自由分享精神讓這篇文章成為可能。同時，特別鳴謝轉轉資料技術負責人軍哥友情斧正。如還有紕漏之處，歡迎留言指教。
參考文章：
部署Flume，大資料採集又快又穩
Flume日誌採集與Logstash對比
詳解日誌採集工具——Logstash、Filebeat、Fluentd、Logagent對比
Hive，Hbase，HDFS等之間的關係
批處理和流處理
D3。js 入門簡介
圖表元件D3調研及和Echarts對比
資料視覺化的開源方案： Superset vs Redash vs Metabase
猜你喜歡
資料產品
PM 修煉： 核心職責 | 關鍵能力 | 認知升級 | 如何修煉
資料產品分類：企內 | 使用者 | 商用
行業研究：Gartner報告 | Domo
產品功能：Dashboard | 實時 | 視覺化
資料分析
分析方法：基礎方法論 | 使用者分析 | 統計學
分析案例：Pinterest | GrowingIO
資料技術
資料倉庫
