互聯網和移動互聯網技術開啟了大規模生產、分享和應用數據的大數據時代。面對如此龐大規模的數據，如何存儲？如何計算？各大互聯網巨頭都進行了探索。Google的三篇論文 GFS(2003)，MapReduce(2004)，Bigtable(2006)為大數據技術奠定了理論基礎。隨后，基于這三篇論文的開源實現Hadoop被各個互聯網公司廣泛使用。在此過程中，無數互聯網工程師基于自己的實踐，不斷完善和豐富Hadoop技術生態。經過十幾年的發展，如今的大數據技術生態已相對成熟，圍繞大數據應用搭建的平臺架構和技術選型也逐漸趨向統一。

數據采集
“巧婦難為無米之炊”，沒有數據也就沒有后面的一切，數據采集作為基礎至關重要。采集的數據主要由業務系統產生，包括存儲在關系型DB中的結構化數據和記錄在日志文件中的半結構化數據。Sqoop用于從關系型DB中采集數據，Flume用于日志采集。實時計算由于對時效性要求比較高，它一般采用Kafka和業務系統建立實時數據通道，完成數據傳輸。

Sqoop是Apache的一個獨立項目，始于2009年。Sqoop是一個用來將Hadoop和關系型數據庫中的數據相互轉移的工具，可以將一個關系型數據庫（例如 ：MySQL ,Oracle ,Postgres等）中的數據導進到Hadoop的HDFS中，也可以將HDFS的數據導進到關系型數據庫中。其官方地址是 http://sqoop.apache.org/。官網介紹如下：

Apache Sqoop(TM) is a tool designed for efficiently transferring bulk data between Apache Hadoop and structured datastores such as relational databases.

http://sqoop.apache.org/

Flume最早是Cloudera提供的日志收集系統，是Apache下的一個孵化項目。Flume是一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸的系統，Flume支持在日志系統中定制各類數據發送方，用于收集數據；同時，Flume提供對數據進行簡單處理，并寫到各種數據接受方（可定制）的能力。其官方地址是 http://flume.apache.org/。官網介紹如下：

Flume is a distributed, reliable, and available service for efficiently collecting, aggregating, and moving large amounts of log data. It has a simple and flexible architecture based on streaming data flows.

http://flume.apache.org/

離線計算
離線計算是指在計算開始前已知所有輸入數據，輸入數據不會產生變化，且在解決一個問題后就要立即得出結果的前提下進行的計算。離線計算處理的數據是靜態不變的，但是數據量非常大。因此如何存儲和計算海量數據是離線計算最大的技術挑戰。這也是Hadoop技術生態核心解決的問題。如果你對大數據開發感興趣，想系統學習大數據的話，可以加入大數據技術學習交流扣扣君羊：522189307

HDFS是基于谷歌GFS論文實現的開源分布式文件系統，主要解決海量數據的存儲問題。系統架構上，HDFS是一個典型的主從分布式架構。主節點叫NameNode，從節點叫DataNode。NameNode負責集群的全局管理，處理來自客戶端的讀寫請求。DataNode是實際存儲文件的數據塊，執行來自主節點的讀寫命令。HDFS保證了CAP中的CP，追求強一致高吞吐設計，不適合低延遲的應用場景。此外，HDFS采用流數據模式訪問和處理文件，只支持追加（append-only）的方式寫入數據，不支持文件任意offset的修改。它的主要使用場景是作為數倉的底層存儲系統。

離線計算的核心計算模型基于MapReduce實現。Hive用類SQL的方式，簡化了MapReduce的腳本實現過程，目前已成為搭建數倉的首選工具。Spark將MapReduce對磁盤的多點I/O改為內存中的多線程實現，將中間處理數據存于內存來減少磁盤IO操作，速度比傳統MapReduce快10倍。此外，Spark還支持流式計算，使它在實時計算中也占有一席之地。Presto也是完全基于內存的并行計算模型，查詢性能好，但是受內存大小限制，更多用于OLAP查詢。由于離線計算對時延要求不高，完全基于內存的計算支撐不起數倉大量的ETL過程，在實際場景中，ETL過程大部分還是基于Hive的HSQL實現。

實時計算
實時計算與離線計算相對應。離線計算在計算開始前已經知道所有的輸入數據。實時計算在計算開始前并不知道所有的輸入數據，輸入數據以序列化的方式一個個輸入并進行處理。實時計算過程處理的數據量不大，但是要求數據處理的速度非常快。如果說離線計算看重的是高吞吐能力，那么實時計算看重的就是快響應能力。為了實現快響應，實時計算通常會采用流計算（Stream Computing）方式。

流計算與批計算（Batch Computing）相對應，兩者區別在于處理的數據粒度不同。批計算以數據塊為單位進行數據處理，流計算以單條數據記錄為單位進行數據處理。批處理的吞吐效率高于流處理，但是由于數據到達不會立即處理，所以延遲比流處理要高。批處理主要用于離線計算，流處理主要用于實時計算。但這不是絕對的，實時計算有時為了提高吞吐率，也會犧牲一些延時，比如Spark Streaming采用微批量（micro-batch，spark中稱為Discretized Stream）的方式進行實時計算。除Spark外，Storm和Flink也是主流的實時計算框架，它們都是基于Native Streaming實現，延遲（latency）非常低，Storm在幾十毫秒級別，Flink在百毫秒級別。

Storm始于2011年，是Twitter開源的分布式實時大數據處理框架，被業界稱為實時版Hadoop，2013年開源給Apache。其官方地址是 http://storm.apache.org/。官網介紹如下：

Apache Storm is a free and open source distributed realtime computation system. Apache Storm makes it easy to reliably process unbounded streams of data, doing for realtime processing what Hadoop did for batch processing.

http://storm.apache.org/

Flink誕生于歐洲的一個大數據研究項目StratoSphere。該項目是柏林工業大學的一個研究性項目，早期專注于批計算。2014 年，StratoSphere 項目中的核心成員孵化出 Flink，并在同年將 Flink 捐贈 Apache。其官方地址是 https://flink.apache.org/。官網介紹如下：

Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed to run in all common cluster environments, perform computations at in-memory speed and at any scale.

https://flink.apache.org/

Flink計算的主流方向被定位成流計算，但它和Spark一樣是流批一體的。Spark用批模擬流實現流計算，Flink用流模擬批來支持批處理。與Storm和Spark相比，Flink最大的優勢在于它實現了有狀態（Stateful）的計算，這個能力讓它可以提供Exactly-Once語義保證，大大提高了程序員的編程效率。在眾多的流計算框架中，Flink是最接近 Dataflow 模型的流計算框架，業內評價它是繼Spark之后的第四代大數據計算引擎。現在國內互聯網公司，包括BAT和TMD都選擇了Flink。

除了計算問題外，對于實時計算還有一個很重要的問題：如何建立實時輸入的數據流通道。Kafka就是解決這個問題的最佳利器。Kafka起源于LinkedIn，2011年開源給Apache。其官方地址是 http://kafka.apache.org/。官網介紹如下：

Kafka is used for building real-time data pipelines and streaming apps. It is horizontally scalable, fault-tolerant, wicked fast, and runs in production in thousands of companies.

http://kafka.apache.org/

技術選型上，經常會拿Kafka跟MQ中間件（比如RabbitMQ、RocketMQ）進行比較。但Kafka設計的初衷是做日志統計分析，不是以可靠消息傳輸為設計目標。比如Kafka中消息可能會重復或亂序，它也不支持事務消息等。另外，Kafka采用批處理的方式傳遞消息，吞吐量高，但會有延遲，時效性不如MQ中間件，這也是為什么不建議用Kafka替代MQ中間件的原因。

OLAP
大數據的主要應用之一就是做數據分析，更專業的表述叫OLAP。OLAP是On Line Analytical Processing（聯機分析處理）的縮寫，與OLTP（On Line Transaction Processing, 聯機事務處理）相對應。OLTP是傳統的關系型數據庫的主要應用，是一種操作型數據處理。OLAP是數據倉庫的主要應用，是一種分析型數據處理。

OLAP分析處理的數據一般采用維度建模，基于“維度”的分析操作包括：鉆取（上鉆roll up和下鉆drill down）、切片(slice)和切塊(dice)、以及旋轉(pivot)等。按數據存儲方式不同，OLAP引擎分為ROLAP、MOLAP和HOLAP三種（如下圖所示）。按實現架構不同，OLAP引擎可分為：MPP（Massively Parallel Processor, 大規模并行處理）架構、預處理架構和搜索引擎架構。

基于MPP架構的ROLAP引擎：Presto

利用關系模型來處理OLAP查詢，通過并發來提高查詢性能。Presto是Facebook于2012年開發，2013年開源的，完全基于內存的并⾏計算，分布式SQL交互式查詢引擎。其官網地址是：https://prestodb.io/ 。

基于預計算架構的MOLAP引擎：Druid、Kylin

Kylin是完全的預計算引擎，通過枚舉所有維度的組合，建立各種Cube進行提前聚合，以HBase為基礎的OLAP引擎。其官網地址是：http://kylin.apache.org/ 。

Druid則是輕量級的提前聚合(roll-up)，同時根據倒排索引以及bitmap提高查詢效率的時間序列數據和存儲引擎。其官網地址是：https://druid.apache.org/ 。

基于搜索引擎架構的OLAP：ES

ES是典型的搜索引擎類的架構系統，在入庫時將數據轉換為倒排索引，采用Scatter-Gather計算模型提高查詢性能。- 對于搜索類的查詢效果較好，但當數據量較大時，對于Scan類和聚合類為主的查詢性能較低。

看數：敏捷BI工具
看數解決數據可視化問題，幫助BI進行數據分析，支持企業決策，實現商業價值。這個領域，國內外已經有很多成熟的軟件，比如QlikView、TableAU、FineBI、PowerBI、QuickBI等。大部分BI軟件都是商業軟件，不支持私有化部署或者私有化部署成本很高。并且，BI工具的用戶定位偏專業數據分析師，對普通人來說有一定的學習使用門檻。隨著前端數據可視化組件的不斷完善（比如Highcharts、百度的Echats、阿里的antV(G2)等），許多互聯網公司會選擇定制的數據可視化方案。一些大公司也會自研BI工具，比如滴滴的數易。