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

數(shù)據(jù)采集
“巧婦難為無米之炊”，沒有數(shù)據(jù)也就沒有后面的一切，數(shù)據(jù)采集作為基礎(chǔ)至關(guān)重要。采集的數(shù)據(jù)主要由業(yè)務(wù)系統(tǒng)產(chǎn)生，包括存儲在關(guān)系型DB中的結(jié)構(gòu)化數(shù)據(jù)和記錄在日志文件中的半結(jié)構(gòu)化數(shù)據(jù)。Sqoop用于從關(guān)系型DB中采集數(shù)據(jù)，F(xiàn)lume用于日志采集。實時計算由于對時效性要求比較高，它一般采用Kafka和業(yè)務(wù)系統(tǒng)建立實時數(shù)據(jù)通道，完成數(shù)據(jù)傳輸。

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

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提供的日志收集系統(tǒng)，是Apache下的一個孵化項目。Flume是一個高可用的，高可靠的，分布式的海量日志采集、聚合和傳輸?shù)南到y(tǒng)，F(xiàn)lume支持在日志系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方，用于收集數(shù)據(jù)；同時，F(xiàn)lume提供對數(shù)據(jù)進行簡單處理，并寫到各種數(shù)據(jù)接受方（可定制）的能力。其官方地址是 http://flume.apache.org/。官網(wǎng)介紹如下：

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/

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

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

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

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

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

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

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誕生于歐洲的一個大數(shù)據(jù)研究項目StratoSphere。該項目是柏林工業(yè)大學(xué)的一個研究性項目，早期專注于批計算。2014 年，StratoSphere 項目中的核心成員孵化出 Flink，并在同年將 Flink 捐贈 Apache。其官方地址是 https://flink.apache.org/。官網(wǎng)介紹如下：

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用批模擬流實現(xiàn)流計算，F(xiàn)link用流模擬批來支持批處理。與Storm和Spark相比，F(xiàn)link最大的優(yōu)勢在于它實現(xiàn)了有狀態(tài)（Stateful）的計算，這個能力讓它可以提供Exactly-Once語義保證，大大提高了程序員的編程效率。在眾多的流計算框架中，F(xiàn)link是最接近 Dataflow 模型的流計算框架，業(yè)內(nèi)評價它是繼Spark之后的第四代大數(shù)據(jù)計算引擎?，F(xiàn)在國內(nèi)互聯(lián)網(wǎng)公司，包括BAT和TMD都選擇了Flink。

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

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/

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

OLAP
大數(shù)據(jù)的主要應(yīng)用之一就是做數(shù)據(jù)分析，更專業(yè)的表述叫OLAP。OLAP是On Line Analytical Processing（聯(lián)機分析處理）的縮寫，與OLTP（On Line Transaction Processing, 聯(lián)機事務(wù)處理）相對應(yīng)。OLTP是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的主要應(yīng)用，是一種操作型數(shù)據(jù)處理。OLAP是數(shù)據(jù)倉庫的主要應(yīng)用，是一種分析型數(shù)據(jù)處理。

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

基于MPP架構(gòu)的ROLAP引擎：Presto

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

基于預(yù)計算架構(gòu)的MOLAP引擎：Druid、Kylin

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

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

基于搜索引擎架構(gòu)的OLAP：ES

ES是典型的搜索引擎類的架構(gòu)系統(tǒng)，在入庫時將數(shù)據(jù)轉(zhuǎn)換為倒排索引，采用Scatter-Gather計算模型提高查詢性能。- 對于搜索類的查詢效果較好，但當(dāng)數(shù)據(jù)量較大時，對于Scan類和聚合類為主的查詢性能較低。

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