隨著移動互聯網、雲計算、物聯網和大數據技術的廣泛應用，現代社會已經邁入全新的大數據時代。數據的爆炸式增長以及價值的擴大化，將對企業未來的發展產生深遠的影響，數據將成為企業的核心資產。如何處理大數據，挖掘大數據的價值，讓大數據為企業的發展保駕護航，將是未來信息技術發展道路上關注的重點。

傳統的數據處理方式通常是將數據導入至專門的數據分析工具中，這樣會面臨兩個問題：1、如果源數據非常大時，往往數據的移動就要花費較長時間。2、傳統的數據處理工具往往是單機模型，面對海量數據時，數據處理的時間也是一個很大的問題。通常我們對數據的實時性要求並沒有那麼高，但是對數據能不能及時產出卻是有強烈要求的。

因此產生了一系列的基於大數據技術的計算引擎，來滿足日漸增長的數據量以及複雜的業務場景。下面主要介紹下DataSimba支持的一些計算引擎以及DataSimba是如何選擇相應的計算引擎去解決不同的業務場景。

計 算 引 擎

計算引擎最主要的應用場景就是傳統的ETL過程，如電信領域的KPI、KQI的計算。單據經過探針採集上來後，按照一定的規則轉換成原始單據，根據業務需求，按週期（分鐘、小時、天）等粒度計算成業務單據。以前的這一過程通常使用數據庫來計算，但是隨著數據量越來越多，傳統的數據庫技術遇到了瓶頸，就出現了分佈式的計算引擎技術。

一般來說目前的計算引擎大致分為兩大類：基於磁盤的計算技術、基於內存的計算技術。基於磁盤的典型代表是Hive，基於內存的代表為Spark。還有其它的例如Impala、Presto、Druid、Kylin等計算引擎，都是大數據在不同應用場景下解決不同的問題而產生的。

DataSimba數據中臺採用了多種計算引擎以適應各種應用場景的需要，並且專門為數據開發定製了數據開發平臺，降低開發難度，使數據開發、分析師可以很方便的根據不同的場景使用與之對應的計算引擎。總體架構圖如下所示：

磁盤計算

就目前來說，基於磁盤的計算引擎仍然是大數據處理過程中很重要的一種，其主要特點是穩定、分佈式、多副本、可處理的數據量非常龐大。基於此，通常大數據的數倉會採取此種計算引擎，而這種計算引擎的典型代表就是Hive。

Hive是基於Hadoop構建的一套數據倉庫分析系統，它提供了豐富的SQL查詢方式來分析存儲在Hadoop 分佈式文件系統中的數據，可以將結構化的數據文件映射為一張數據庫表，並提供完整的SQL查詢功能，可以將SQL語句轉換為MapReduce任務進行運行，通過自己的SQL 去查詢分析需要的內容，這套SQL簡稱Hive SQL，使不熟悉MapReduce的用戶很方便的利用SQL語言查詢、彙總、分析數據。而MapReduce開發人員可以把自己寫的Mapper 和Reducer 作為插件來支持Hive做更復雜的數據分析。

Hive是構建DataSimba數據中臺過程中非常重要的一種計算引擎，它能幫助用戶快速的搭建數倉模型、ETL數據清洗、數據開發調式等，目前已經在多個項目中得到了實施驗證。

某母嬰客戶案例

⊙客戶背景：該母嬰集團運營效率低下，無標準數據體系及系統支持的情況下，其電商APP千人一面，所有運營決策都基於經驗決策，影響用戶體驗，老客戶復購率低。

⊙解決方案：奇點雲幫助客戶構建了統一的數據中臺，規範數據採集，打通日誌、交易、售後等數據，基於Hive計算引擎幫助客戶快速的搭建了數倉模型，每天穩定支撐了1000多個任務量的離線調度。離線加實時計算會員、商品、店鋪對象的行為和屬性特徵，在購物主鏈路四個環節（曝光-點擊-加購-購買）做到千人千面推薦引擎。

⊙實施效果：最終提升新客戶50%的轉化率與老客戶80%的復購率。同時幫助客戶運營人員構建業務分析BI系統及一系列運營報表，支撐運營日常數據工作效率提升，快速洞察業務。

內存計算

由於Hive計算框架是基於磁盤的，因此勢必會涉及到頻繁的讀寫磁盤，導致Hive計算框架的計算速度很慢，不適用於實時性要求相對高一點的場景。如今內存容量的增加和成本的降低，促進了基於內存的計算框架的出現，讓離線計算在性能上有了極大的提升。

Spark是基於內存的迭代計算框架，適用於需要多次操作特定數據集的場合。需要反覆操作的次數越多，需要讀取的數據量越大，性能提升就越大；同時也非常的適合數據量不是特別大，但是要求實時統計分析的場景。

RDD是Spark的最基本抽象，是對分佈式內存的抽象使用，以操作本地集合的方式來操作分佈式數據集的抽象實現。RDD是Spark最核心的內容，它表示了已被分區、不可變的、能夠被並行操作的數據集，不同的數據集格式對應不同的RDD實現。RDD必須是可以序列化的。RDD可以緩存到內存中，每次對RDD數據集的操作結果都可以存放到內存中，下一個操作可以直接從內存中獲取數據，省略了大量的磁盤I/O操作，大大的提高了離線計算的速度。

DataSimba數據中臺採取了Hive和Spark互補的雙批處理引擎，針對不同的應用場景採取不同的引擎。例如我們在項目上採用了Hive去搭建數倉模型，用Spark去做一些準實時場景的離線開發。

即席查詢

在數據倉庫領域有一個概念叫Adhoc Query，中文也叫“即席查詢”。即席查詢是指用戶在使用系統時，根據自己當時的需求定義的查詢，一般的應用場景為實時數據分析、在線查詢等。因為是查詢應用，所以通常具有幾個特點：延時低、查詢條件複雜、查詢範圍大、返回結果小、併發要求高、需要SQL化。

傳統上，常常使用關係型數據庫來承擔Adhoc Query的職責，但是隨著數據量的日益變大，數據庫已經無法承受這樣的壓力，基於內存模型的分佈式查詢引擎成為了必然的選擇。

DataSimba採用了Impala作為即席查詢引擎，它提供SQL語義，能查詢存儲在Hdfs中的PB級大數據，並且計算的時候不需要把中間結果寫入磁盤，省掉了大量的I/O開銷，完全拋棄了批處理這個不太適合做SQL查詢的範式，借鑑了MPP並行數據庫的思想，從而省掉不必要的shuffle、sort等開銷，大大的提高了查詢速度。

多維度分析

在數據倉庫裡面有兩種聯機查詢：聯機事務查詢OLTP和聯機分析查詢OLAP。OLTP是傳統的關係型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是數據倉庫系統的主要應用，支持複雜的分析操作，需要對各種維度和度量進行上卷、下鑽、切片和切塊分析，側重決策支持，並且提供直觀易懂的查詢結果。隨著目前數據規模的急劇膨脹，從傳統的單表千萬級到現在的單表百億、萬億級，維度也從傳統的幾十維到現在的一些互聯網企業可能存在的萬維，而且因為交互對象是人，如此大的數據量查詢響應延遲要求仍為秒級，OLTP正在逐步的被OALP所替換。

DataSimba底層使用了Druid作為OLAP查詢引擎。Druid主要運用了四大關鍵技術來解決大規模數據量的實時查詢：預聚合、列式存儲、字段編碼、位圖索引。首先通過數據的預聚合，可以減少大量不必要數據的存儲以及避免查詢時很多不必要的計算；並且因為OLAP的分析場景大多隻關心某個列或者某幾個列的指標計算，列式存儲可以很好的滿足這個場景；最後在列式存儲的基礎之上，再加上字段編碼，能夠有效的提升數據的壓縮率，然後位圖索引讓很多查詢最終直接轉化成計算機層面的位計算，提升查詢效率。

某零售客戶解決方案如下

⊙數據量：保存近幾年的數據

⊙數據接入方式：當天數據Kafka實時數據接入，隔天離線數據覆蓋昨天數據

⊙查詢方式：實時查詢

⊙ 業務實現：TopN實現銷售額曲線展示，GroupBy分組客流分佈，TimeSerise做天彙總

目前市場上開源的計算引擎很多，如何選擇適合業務場景的計算引擎，是一個比較令人頭疼的問題。DataSimba後續會在統一引擎方面投入一定的資源去做研究，屏蔽計算引擎底層、降低用戶使用門檻，無需再去學習各引擎使用方法和優缺點，無需手動選擇執行引擎、通過SQL畫像智能選取合適的計算引擎、收集SQL執行數據，通過決策樹，Logistic迴歸，SVM等分類算法實現引擎的智能路由。