數據倉庫、數據湖、流批一體，終於有專家講清楚了！

時間 2020-06-22

標籤數據倉庫一體終於專家講清楚简体版

原文原文鏈接

做者：前端

蔣曉偉（量仔）阿里雲研究員算法

金曉軍(仙隱) 阿里雲高級技術專家sql

摘要：數據倉庫，數據湖，包括Flink社區提的流批一體，它們到底能解決什麼問題？今天將由阿里雲研究員從解決業務問題出發，將問題抽絲剝繭，從技術維度娓娓道來：爲何你須要數據湖或者數據倉庫解決方案？它的核心難點與核心問題在哪？若是想穩定落地，系統設計該怎麼作？數據庫

1、業務背景

1.1 典型實時業務場景

首先咱們來看一個典型的實時業務場景，這個場景也是絕大部分實時計算用戶的業務場景，整個鏈路也是一個典型的流計算架構：把用戶的行爲數據或者數據庫同步的Binlog，寫入至kafka，再經過Flink作同步任務，訂閱kafka消費的實時數據，這個過程當中須要作幾件事情，好比Preprocessing（預處理），在處理的過程當中作Online Training（在線訓練），在線訓練過程當中須要關聯一些維表或者特徵，這些特徵可能能夠全量加載到計算節點裏面去，也有可能很是大，就須要用HBase作一個高併發的點查，好比咱們作一些樣本也會寫入到HBase中去，造成一個交互過程，最後實時產生的採樣數據或者訓練模型推到搜索引擎或者算法模塊中。以上就是一個很典型的Machine Learning的完整鏈路。
緩存

1.2 愈來愈複雜的架構

以上場景展現的鏈路與離線鏈路是相輔相成的，也有一些公司實時的鏈路尚未創建起來，用的是離線鏈路，不過這套鏈路已是一個很是成熟的方案了。若是咱們把這個鏈路變得更加複雜一些，看看會帶來什麼樣的問題。首先咱們把剛剛的鏈路作一個變化，實時數據寫入kafka，再通過Flink作實時的機器學習或者指標計算，把結果寫入到在線服務，例如HBase或者Cassandra用來作點查，再接入在線大盤，作指標的可視化展示。架構

這裏面產生的一個問題就是：在線產生的數據和樣本，若是想對它們作一個分析，基於HBase或者Cassandra的分析能力是很是弱的且性能是很是差的。併發

那麼怎麼辦呢？機器學習

有聰明的開發者們可能就有一些實現方式以下：異步

HBase或者Cassandra不知足分析需求，就把實時數據寫入至適合數據分析的系統中，好比ClickHouse或者Druid，這些都是典型的列存架構，能構建index、或者經過向量化計算加速列式計算的分析，再對接分析軟件，對數據作實時報表、實時分析展示等，以此鏈路來解決實時高效分析的問題。ide

但上面的架構中，還有一些額外的需求，就是要將實時產生的數據數據歸檔至離線系統，對離線數據作一個基於歷史的全量分析，基於此開發者們最經常使用的鏈路就是把實時數據離線的歸檔至Hive中，在Hive中作T+1天或者其餘的離線算法。經過Hive對離線數據的處理來知足離線場景的需求。

可是業務既有實時寫入的數據又有離線的數據，有時咱們須要對實時數據和離線數據作一個聯邦查詢，那應該怎麼辦呢？

基於現市面上的開源體系，開發者們最經常使用的架構就是基於Drill或者Presto，經過相似MPP的架構層作多數據的聯邦查詢，如果速度不夠快，還能經過Druid、ClickHouse等作查詢加速。

以上聯邦查詢的鏈路有個問題就是，QPS很難上去，好比前端調用須要每秒鐘幾百上千的QPS，若是幾百上千的QPS所有經過加速層來作，那性能確定是有所降低的，這時應該怎麼辦呢？最多見的解決方案就是在常見的加速層再加一個cache，用來抵擋高併發的請求，通常是加Redis或者Mysql用來cache數據，這樣就能提供server以及在線服務的能力。

1.3 典型的大數據Lambda架構

以上就是絕大部分公司所使用的大數據架構，也有不少公司是根據業務場景選擇了其中一部分架構，這樣既有實時又有離線的大數據完整架構就搭建出來，看起來很完美，能實際解決問題，可是仔細想一想，裏面藏了不少坑，越日後作越舉步維艱，那麼問題在哪呢？如今咱們來仔細看一下。

其實這套大數據方案本質上就是一個Lambda架構，原始數據都是一個源頭，例如用戶行爲日誌、Binlog等，分別走了兩條鏈路：一條是實時鏈路，也就是加速層（Speed Layer），經過流計算處理，把數據寫入實時的存儲系統；另外一條鏈路就是離線鏈路，也就是批計算，最典型的就是將數據歸檔至Hive，再經過查詢層如Spark對數據作加速查詢，最後再對接在線應用、大盤或者第三方BI工具。

1.4 典型大數據架構的痛點

針對市面上這些開源產品，就存儲而言，咱們來逐一分析，這些產品是否都能具有知足業務需求的能力。

首先是基於離線存儲的Hive，其次是提供點查詢能力的HBase、Cassandra、而後是MPP架構號稱能面向HTAP的Greenplum、以及最新興起的用於作快速分析的Clickhouse等等都是基於解決方案而面世的存儲產品。

但以上的每一個存儲產品都是一個數據的孤島，好比爲了解決點查詢的問題，數據須要在HBase裏面存儲一份；爲了解決列存的快速分析，數據須要在Druid或者Clickhouse裏面存一份；爲了解決離線計算又須要在Hive裏面存儲一份，這樣帶來的問題就是：

1）冗餘存儲

數據將會存儲在多個系統中，增長冗餘存粗。

2）高維護成本

每一個系統的數據格式不一致，數據須要作轉換，增長維護成本，尤爲是當業務到達必定量級時，維護成本劇增。

3）高學習成本

多個系統以前須要徹底打通，不一樣的產品有不一樣的開發方式，尤爲是針對新人來講，須要投入更多的精力去學習多種系統，增長學習成本。

1.5 簡化的大數據架構

面對這樣一個無比冗餘無比複雜的系統，咱們應該怎麼去解決這些問題呢？咱們能夠對Lambda架構作一個簡化。其實業務的本質就是將數據源作一個實時處理或者離線處理（批處理），從業務場景出發，咱們但願無論是實時數據仍是離線數據，都能統一存儲在一個存儲系統裏面，並且這個存儲還必需要知足各類各樣的業務需求。這樣聽起來很玄乎，感受這個產品須要支持各類各類的場景，很是複雜。可是若是咱們能把架構作成這樣，將會很是完美，這樣就從本質上解決了流批統一的計算問題，一套SQL既能作流計算又能作批計算，再深挖其底層原理，還解決了存儲問題，流數據和批數據都統一存儲在同一個產品。

2、看起來很完美的Data Lakes

針對以上簡化的架構，咱們能夠看看開源社區爲了解決這些問題所推出的一些產品，例如Data Lakes。
首先採集的數據有統一的存儲，無論是HDFS、OSS仍是AWS，數據以增量的形式存儲在數據湖裏，再經過查詢層無論是Hive、Spark仍是Flink，根據業務需求選擇一個產品來作查詢，這樣實時數據以及離線數據都能直接查詢。整個架構看起來很美好，可是實際問題在於：

1）數據增量寫入不知足實時性

開源的實時寫入並非實時寫入，而是增量寫入。實時和增量的區別在於，實時寫一條數據就能立馬查詢可見，可是增量爲了提升吞吐會將數據一批一批的寫入。那麼這套方案就不能徹底知足數據實時性的要求。

2）查詢的QPS

咱們但願這個架構既能作實時分析，又能作流計算的維表查詢，存儲裏面的數據可否經過Flink作一個高併發的查詢，例如每秒鐘支持上千萬上億QPS的查詢？

3）查詢的併發度

整個方案本質都是離線計算引擎，只能支持較低的併發，若是要支持每秒鐘上千的併發，須要耗費大量的資源，增長成本。

綜上所述，這個方案目前還不能徹底解決問題，只能做爲一個初期的解決方案。

3、HSAP之我見

3.1 什麼是HSAP

針對以上問題咱們作了一個細緻的分析，大體根據查詢併發度要求或者查詢Latency要求，將Patterns分爲四類：

Batch：離線計算
Analytical：交互式分析
Servering：高QPS的在線服務
Transaction：與錢相關的傳統數據庫（絕大多數業務並不須要）

目前市面上都在說HTAP，通過咱們調研HTAP是個僞命題，由於A和T的優化方向不同。爲了作T，寫入鏈路將很是複雜，QPS沒法知足需求。如果對T的要求下降一點，就會發現Analytical和Severing的聯繫很是緊密，這兩塊的技術是能夠共用的，因此咱們放棄了T就至關於放棄了Transaction，因而咱們提出新的一個架構叫作HSAP，那咱們須要作的就是把提供服務和分析的數據存儲在一個系統裏，經過一套分析引擎來作處理。

3.2 基於HSAP的大數據架構

HASP系統接入到咱們剛剛簡化的架構中就成爲很是的完美的大數據架構。HSAP系統與Flink作維表關聯，對離線數據作批處理，而後對接在線應用提供在線服務，例如報表、大盤等。

3.3 PostgreSQL生態

那麼接入HSAP系統以後，在線應用和系統怎麼樣來用呢？爲了減小使用難度，就要引須要一個生態系統來作支撐，通過咱們反覆調研，咱們認爲是PostgreSQL，主要有如下幾點：

1）豐富的工具對接

PostgreSQL具備很是完備的工具對接，無論是開發工具仍是BI分析工具，都有着豐富的支撐能力。

2）詳盡的文檔支撐

一般來說寫文檔須要耗費大量的時間，PostgreSQL有着很是詳盡的文檔，若是可以直接複用PostgreSQL的文檔，將會減小工做量。同時開發者們只須要根據postgreSQL文檔來開發，減小學習成本。

3）多元化的擴展

PostgreSQL有着很是多元化的擴展，例如地理信息的PostGis，Matlab等，開發者們能夠根據業務需求選擇對應的擴展。

4、新一代的實時交互式引擎--Hologres

基於以上全部內容，進入到咱們今天的重點主題，也就是咱們在阿里雲重磅發佈的新一代實時交互式引擎，中文名叫交互式分析，英文名叫Hologres。Hologres這個名字怎麼來的呢？Hologres由Holographic（全息宇宙）和Postgres組成。

4.1 Hologres的架構

Hologres的架構比較簡單，從下往上看，最底層是統一的存儲系統，能夠是阿里雲統一的Pangu、業務的HDFS或者OSS、S3等，存儲上面是計算層，提供相似的MMP架構計算服務，再往上是FE層，根據查詢信息將Plan分發到各個計算節點，再往上就是PostgreSQL生態的對接，只要有JDBC/ODBC Driver就能對Hologres作查詢。

4.2 Hologres：雲原生

1）存儲計算分離

Hologres的架構是徹底是存儲計算分離，計算徹底部署在K8s上，存儲可使用共享存儲，能夠根據業務需求選擇HDFS或者雲上的OSS，這樣用戶就能根據業務需求對資源作彈性擴縮容，完美解決資源不夠帶來的併發問題。

2）存儲優點

全異步：支持高併發寫入，可以將CPU最大化利用；
無鎖：寫入能力隨資源線性擴展，直到將CPU所有寫滿；
內存管理：提供數據cache，支持高併發查詢。

3）計算優點

高性能混合負載：慢查詢和快查詢混合一塊兒跑，經過內部的調度系統，避免慢查詢影響快查詢；
向量化計算：列式數據經過向量化計算達到查詢加速的能力；
存儲優化：可以定製查詢引擎，可是對存儲在Hologres數據查詢性能會更優。

4.3 基於Hologres的典型應用

下面給你們介紹一下，Hologres在阿里巴巴內部的一個典型應用。數據實時寫入至Flink，經由Flink作實時預處理，好比實時ETL或者實時訓練，把處理的結果直接寫入Hologres，Hologres提供維表關聯點查、結果緩存、複雜實時交互、離線查詢和聯邦查詢等，這樣整個業務系統只須要經過Hologres來作惟一的數據入口，在線系統能夠經過PostgreSQL生態在Hologres中訪問數據，無需對接其餘系統，這樣也能解決以前架構的各類查詢、存儲問題。