作為數(shù)據(jù)中臺(tái)系列的入門科普篇，在上一講中，我們著重幫各位同學(xué)厘清楚，究竟什么樣的企業(yè)才真正需要數(shù)據(jù)中臺(tái)？（需要補(bǔ)課的同學(xué)可以點(diǎn)擊此處直達(dá)）而在今天的文章中，我們有必要先簡(jiǎn)單介紹下目前存在的數(shù)據(jù)引擎，便于大家對(duì)理解之后所講的數(shù)據(jù)中臺(tái)建設(shè)中的相關(guān)技術(shù)，提供一些基礎(chǔ)。

以下內(nèi)容摘錄自互聯(lián)網(wǎng)：

Hive（Hadoop 生態(tài)組件）

Hive 可以被認(rèn)為是 MapReduce 的一個(gè)封裝、包裝。它的意義就是在業(yè)務(wù)分析中將用戶容易編寫(xiě)、會(huì)寫(xiě)的 Sql 語(yǔ)言轉(zhuǎn)換為復(fù)雜難寫(xiě)的 MapReduce 程序，從而大大降低 Hadoop 學(xué)習(xí)的門檻，讓更多的用戶可以利用 Hadoop 進(jìn)行數(shù)據(jù)挖掘分析。

Spark

Spark 是基于內(nèi)存計(jì)算的大數(shù)據(jù)并行計(jì)算框架。它基于內(nèi)存計(jì)算，提高了在大數(shù)據(jù)環(huán)境下數(shù)據(jù)處理的實(shí)時(shí)性，同時(shí)保證了高容錯(cuò)性和高可伸縮性，允許用戶將 Spark 部署在大量的廉價(jià)硬件之上，形成集群。

Spark 誕生于加州大學(xué)伯利克分校 AMPLab，AMPLab 開(kāi)發(fā)以 Spark 為核心的 BDAS 時(shí)提出的目標(biāo)是：One stack to rule them all，也就是說(shuō)在一套軟件棧內(nèi)完成各種大數(shù)據(jù)分析任務(wù)。Spark 是 MapReduce 的替代方案，而且兼容 HDFS、Hive 等分布式存儲(chǔ)層，可融入 Hadoop 的生態(tài)系統(tǒng)，以彌補(bǔ)缺失 MapReduce 的不足。

SparkSQL（Spark 生態(tài)組件）

SparkSQL 的前身是 Shark。為了給熟悉 RDBMS 但又不理解 MapReduce 的技術(shù)人員提供快速上手的工具，Hive 應(yīng)運(yùn)而生，它是當(dāng)時(shí)唯一運(yùn)行在 Hadoop上 的 SQL-on-Hadoop 工具。但是 MapReduce 計(jì)算過(guò)程中大量的中間磁盤落地過(guò)程消耗了大量的 I/O，降低的運(yùn)行效率，為了提高 SQL-on-Hadoop 的效率，Shark 應(yīng)運(yùn)而生，但又因?yàn)?Shark 對(duì)于 Hive 的太多依賴（如采用 Hive 的語(yǔ)法解析器、查詢優(yōu)化器等等)，2014 年 Spark 團(tuán)隊(duì)停止對(duì) Shark 的開(kāi)發(fā)，將所有資源放 SparkSQL 項(xiàng)目上。

Hive on Spark（Spark 生態(tài)組件）

Hive on Spark 是由 Cloudera 發(fā)起，由 Intel、MapR 等公司共同參與的開(kāi)源項(xiàng)目，其目的是把 Spark 作為 Hive 的一個(gè)計(jì)算引擎，將 Hive 的查詢作為 Spark 的任務(wù)提交到 Spark 集群上進(jìn)行計(jì)算。通過(guò)該項(xiàng)目，可以提高 Hive 查詢的性能，同時(shí)為已經(jīng)部署了 Hive 或者 Spark 的用戶提供了更加靈活的選擇，從而進(jìn)一步提高 Hive 和 Spark 的普及率。

Spark Streaming（Spark 生態(tài)組件）

Spark 是一個(gè)類似于 MapReduce 的分布式計(jì)算框架，其核心是彈性分布式數(shù)據(jù)集(RDD)，提供了比 MapReduce 更豐富的模型，可以在快速在內(nèi)存中對(duì)數(shù)據(jù)集進(jìn)行多次迭代，以支持復(fù)雜的數(shù)據(jù)挖掘算法和圖形計(jì)算算法。Spark Streaming 是一種構(gòu)建在 Spark 上的實(shí)時(shí)計(jì)算框架，它擴(kuò)展了 Spark 處理大規(guī)模流式數(shù)據(jù)的能力。

Apache Flink

一個(gè)面向數(shù)據(jù)流處理和批量數(shù)據(jù)處理的可分布式的開(kāi)源計(jì)算框架，它基于同一個(gè) Flink 流式執(zhí)行模型（Streaming execution model），能夠支持流處理和批處理兩種應(yīng)用類型。由于流處理和批處理所提供的 SLA（服務(wù)等級(jí)協(xié)議）完全不相同， 流處理一般需要支持低延遲、Exactly-Once 保證，而批處理需要支持高吞吐、高效處理，所以在實(shí)現(xiàn)的時(shí)候通常是分別給出兩套實(shí)現(xiàn)方法，或者通過(guò)一個(gè)獨(dú)立的開(kāi)源框架來(lái)實(shí)現(xiàn)其中每一種處理方案。比較典型的：實(shí)現(xiàn)批處理的開(kāi)源方案有 MapReduce、Spark；實(shí)現(xiàn)流處理的開(kāi)源方案有 Storm；Spark 的 Streaming 其實(shí)本質(zhì)上也是微批處理。

Flink 在實(shí)現(xiàn)流處理和批處理時(shí)，與傳統(tǒng)的一些方案完全不同，它從另一個(gè)視角看待流處理和批處理，將二者統(tǒng)一起來(lái)：Flink 是完全支持流處理，也就是說(shuō)作為流處理看待時(shí)輸入數(shù)據(jù)流是無(wú)界的；批處理被作為一種特殊的流處理，只是它的輸入數(shù)據(jù)流被定義為有界的。

Impala

Cloudera 在受到 Google 的 Dremel 啟發(fā)下開(kāi)發(fā)的實(shí)時(shí)交互 SQL 大數(shù)據(jù)查詢工具。Impala 沒(méi)有再使用緩慢的 Hive MapReduce 批處理，而是通過(guò)使用與商用并行關(guān)系數(shù)據(jù)庫(kù)中類似的分布式查詢引擎（由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分組成），可以直接從 HDFS 或 HBase 中用 SELECT、JOIN 和統(tǒng)計(jì)函數(shù)查詢數(shù)據(jù)，從而大大降低了延遲。其架構(gòu)如圖 1所示，Impala 主要由 Impalad，State Store，Impala Catalog Service 和 CLI 組成。

Phoenix

是構(gòu)建在 HBase 之上的關(guān)系型數(shù)據(jù)庫(kù)層，作為內(nèi)嵌的客戶端 JDBC 驅(qū)動(dòng)用以對(duì) HBase 中的數(shù)據(jù)進(jìn)行低延遲訪問(wèn)。Apache Phoenix 會(huì)將用戶編寫(xiě)的 Sql 查詢編譯為一系列的 scan 操作，最終產(chǎn)生通用的 JDBC 結(jié)果集返回給客戶端。數(shù)據(jù)表的元數(shù)據(jù)存儲(chǔ)在 HBase 的表中被會(huì)標(biāo)記版本號(hào)，所以進(jìn)行查詢的時(shí)候會(huì)自動(dòng)選擇正確的 Schema。直接使用 HBase 的 API，結(jié)合協(xié)處理器（Coprocessor）和自定義的過(guò)濾器的話，小范圍的查詢?cè)诤撩爰?jí)響應(yīng)，千萬(wàn)數(shù)據(jù)的話響應(yīng)速度為秒級(jí)。

（以上內(nèi)容摘錄于互聯(lián)網(wǎng)）

有了基本的概念，我們用一張圖來(lái)熟悉下什么是實(shí)時(shí)計(jì)算、離線計(jì)算、即席查詢（Ad Hoc）和實(shí)時(shí)查詢。

備注：即席查詢（Ad Hoc）是用戶根據(jù)自己的需求，靈活的選擇查詢條件，系統(tǒng)能夠根據(jù)用戶的選擇生成相應(yīng)的統(tǒng)計(jì)數(shù)據(jù)。

總結(jié)一下：

下面列舉典型的兩個(gè)場(chǎng)景：

需求：BI 報(bào)表需求，需要從多個(gè)業(yè)務(wù)庫(kù)抽取數(shù)據(jù)清洗加工成指標(biāo)，最終利用可視化工具進(jìn)行展示，每天早上能看到昨天的數(shù)據(jù)即可。

離線計(jì)算 實(shí)時(shí)查詢：如 Hive 和 Mysql 是最常見(jiàn)的搭配。

需求：在以上基礎(chǔ)上，需要?jiǎng)討B(tài)調(diào)整查詢條件，從而動(dòng)態(tài)展示滿足條件的報(bào)表數(shù)據(jù)。

離線計(jì)算 即席查詢（動(dòng)態(tài)條件） 實(shí)時(shí)查詢（無(wú)動(dòng)態(tài)條件）：如 Hive、Impala 是比較常見(jiàn)的搭配。

需求：在以上的基礎(chǔ)上，需要對(duì)多個(gè)指標(biāo)的更新做到準(zhǔn)實(shí)時(shí)

實(shí)時(shí)計(jì)算 離線計(jì)算 即席查詢（動(dòng)態(tài)條件） 實(shí)時(shí)查詢（無(wú)動(dòng)態(tài)條件）：如Spark/Flink 、Hive、Impala是比較常見(jiàn)的搭配。

需求：用戶個(gè)人畫(huà)像需求，需要從多個(gè)業(yè)務(wù)庫(kù)抽取數(shù)據(jù)清洗加工成標(biāo)簽，最終由決策類工具透出使用，用戶規(guī)模在幾億級(jí)別。

離線計(jì)算 實(shí)時(shí)查詢：如Hive Phoenix ，如果具備 Mysql 分庫(kù)分表中間件，Hive Mysql（分庫(kù)分表中間件）。

需求：在以上基礎(chǔ)上，需求根據(jù)條件自由圈定人群，然后定時(shí)推送到通知中心。

離線計(jì)算 實(shí)時(shí)查詢 即席查詢：如 Hive Phoenix Impala

需求：在以上基礎(chǔ)上，需求對(duì)指定人群（運(yùn)營(yíng)人員上傳）做人群透視需求。

離線計(jì)算 實(shí)時(shí)查詢 即席查詢：如 Hive Phoenix Impala

以上兩個(gè)場(chǎng)景是企業(yè)大數(shù)據(jù)建設(shè)當(dāng)中常見(jiàn)的需求，從這里可以看出，僅是熟悉各個(gè)組件，把數(shù)據(jù)流程串起來(lái)就已經(jīng)非常費(fèi)勁了，更不用說(shuō)在此基礎(chǔ)上去做好數(shù)據(jù)治理（元數(shù)據(jù)，數(shù)據(jù)血緣和數(shù)據(jù)質(zhì)量等）。

所以，企業(yè)需要一個(gè)統(tǒng)一的平臺(tái)來(lái)滿足離線/實(shí)時(shí)計(jì)算需求，各種查詢需求（實(shí)時(shí)查詢和 ad hoc），同時(shí)，在將來(lái)新數(shù)據(jù)引擎（更快的計(jì)算框架，更快的查詢響應(yīng)）出現(xiàn)時(shí)，又不需要重構(gòu)目前的大數(shù)據(jù)建設(shè)。