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 實現。每次查詢僅能針對一個數據庫查詢，操作比較繁瑣。
在數據挖掘這塊，目前主要集中在商用公司這塊，通過和某些行業深度合作，從而訓練和深化自己的學習模型，這里不多贅述。
文章的最后，鳴謝網絡上各位知識的分享者，以下是主要參考內容的鏈接，大家可以自行查閱。本人非技術出身，所有資料均系網上整理而成，是互聯網的自由分享精神讓這篇文章成為可能。同時，特別鳴謝轉轉數據技術負責人軍哥友情斧正。如還有紕漏之處，歡迎留言指教。
參考文章：