數(shù)據(jù)倉庫,、數(shù)據(jù)湖,、流批一體，終于有大神講清楚了,！...

airen89 2020-09-24

展開全文

數(shù)據(jù)倉庫,、數(shù)據(jù)湖、流批一體,，終于有大神講清楚了,！

作者：
蔣曉偉（量仔） 阿里云研究員
金曉軍(仙隱) 阿里云高級技術(shù)專家

摘要：數(shù)據(jù)倉庫，數(shù)據(jù)湖,，包括Flink社區(qū)提的流批一體,，它們到底能解決什么問題？今天將由阿里云研究員從解決業(yè)務(wù)問題出發(fā),，將問題抽絲剝繭,，從技術(shù)維度娓娓道來：為什么你需要數(shù)據(jù)湖或者數(shù)據(jù)倉庫解決方案？它的核心難點與核心問題在哪,？如果想穩(wěn)定落地,，系統(tǒng)設(shè)計該怎么做？

一,、業(yè)務(wù)背景

1.1 典型實時業(yè)務(wù)場景

首先我們來看一個典型的實時業(yè)務(wù)場景,，這個場景也是絕大部分實時計算用戶的業(yè)務(wù)場景，整個鏈路也是一個典型的流計算架構(gòu)：把用戶的行為數(shù)據(jù)或者數(shù)據(jù)庫同步的Binlog,，寫入至kafka,，再通過Flink做同步任務(wù)，訂閱kafka消費的實時數(shù)據(jù),，這個過程中需要做幾件事情,，比如Preprocessing（預(yù)處理），在處理的過程中做Online Training（在線訓(xùn)練）,，在線訓(xùn)練過程中需要關(guān)聯(lián)一些維表或者特征,，這些特征可能可以全量加載到計算節(jié)點里面去，也有可能非常大,，就需要用HBase做一個高并發(fā)的點查,，比如我們做一些樣本也會寫入到HBase中去，形成一個交互過程,，最后實時產(chǎn)生的采樣數(shù)據(jù)或者訓(xùn)練模型推到搜索引擎或者算法模塊中,。以上就是一個很典型的Machine Learning的完整鏈路。
在這里插入圖片描述

1.2 越來越復(fù)雜的架構(gòu)

以上場景展示的鏈路與離線鏈路是相輔相成的,，也有一些公司實時的鏈路還沒有建立起來,，用的是離線鏈路，不過這套鏈路已經(jīng)是一個非常成熟的方案了,。如果我們把這個鏈路變得更加復(fù)雜一些,，看看會帶來什么樣的問題。首先我們把剛剛的鏈路做一個變化,，實時數(shù)據(jù)寫入kafka,，再經(jīng)過Flink做實時的機器學(xué)習(xí)或者指標計算，把結(jié)果寫入到在線服務(wù),，例如HBase或者Cassandra用來做點查,，再接入在線大盤，做指標的可視化展現(xiàn),。
在這里插入圖片描述
這里面產(chǎn)生的一個問題就是：在線產(chǎn)生的數(shù)據(jù)和樣本,，如果想對它們做一個分析，基于HBase或者Cassandra的分析能力是非常弱的且性能是非常差的,。

那么怎么辦呢,？

有聰明的開發(fā)者們可能就有一些實現(xiàn)方式如下：
HBase或者Cassandra不滿足分析需求，就把實時數(shù)據(jù)寫入至適合數(shù)據(jù)分析的系統(tǒng)中,，比如ClickHouse或者Druid,，這些都是典型的列存架構(gòu)，能構(gòu)建index,、或者通過向量化計算加速列式計算的分析,，再對接分析軟件，對數(shù)據(jù)做實時報表,、實時分析展現(xiàn)等,，以此鏈路來解決實時高效分析的問題。
在這里插入圖片描述
但上面的架構(gòu)中,，還有一些額外的需求,，就是要將實時產(chǎn)生的數(shù)據(jù)數(shù)據(jù)歸檔至離線系統(tǒng)，對離線數(shù)據(jù)做一個基于歷史的全量分析,，基于此開發(fā)者們最常用的鏈路就是把實時數(shù)據(jù)離線的歸檔至Hive中,，在Hive中做T+1天或者其他的離線算法。通過Hive對離線數(shù)據(jù)的處理來滿足離線場景的需求,。
在這里插入圖片描述
但是業(yè)務(wù)既有實時寫入的數(shù)據(jù)又有離線的數(shù)據(jù),，有時我們需要對實時數(shù)據(jù)和離線數(shù)據(jù)做一個聯(lián)邦查詢，那應(yīng)該怎么辦呢,？
基于現(xiàn)市面上的開源體系,，開發(fā)者們最常用的架構(gòu)就是基于Drill或者Presto,，通過類似MPP的架構(gòu)層做多數(shù)據(jù)的聯(lián)邦查詢，若是速度不夠快,，還能通過Druid,、ClickHouse等做查詢加速。
在這里插入圖片描述
以上聯(lián)邦查詢的鏈路有個問題就是,，QPS很難上去,，比如前端調(diào)用需要每秒鐘幾百上千的QPS，如果幾百上千的QPS全部通過加速層來做,，那性能肯定是有所下降的,，這時應(yīng)該怎么辦呢？最常見的解決方案就是在常見的加速層再加一個cache,，用來抵擋高并發(fā)的請求,，一般是加Redis或者Mysql用來cache數(shù)據(jù)，這樣就能提供server以及在線服務(wù)的能力,。
在這里插入圖片描述

1.3 典型的大數(shù)據(jù)Lambda架構(gòu)

以上就是絕大部分公司所使用的大數(shù)據(jù)架構(gòu),，也有很多公司是根據(jù)業(yè)務(wù)場景選擇了其中一部分架構(gòu)，這樣既有實時又有離線的大數(shù)據(jù)完整架構(gòu)就搭建出來,，看起來很完美,，能實際解決問題，但是仔細想想,，里面藏了很多坑,，越往后做越舉步維艱，那么問題在哪呢,？現(xiàn)在我們來仔細看一下,。
其實這套大數(shù)據(jù)方案本質(zhì)上就是一個Lambda架構(gòu)，原始數(shù)據(jù)都是一個源頭,，例如用戶行為日志,、Binlog等，分別走了兩條鏈路：一條是實時鏈路,，也就是加速層（Speed Layer）,，通過流計算處理，把數(shù)據(jù)寫入實時的存儲系統(tǒng),；另一條鏈路就是離線鏈路,，也就是批計算，最典型的就是將數(shù)據(jù)歸檔至Hive,，再通過查詢層如Spark對數(shù)據(jù)做加速查詢,，最后再對接在線應(yīng)用、大盤或者第三方BI工具。
在這里插入圖片描述

1.4 典型大數(shù)據(jù)架構(gòu)的痛點

針對市面上這些開源產(chǎn)品,，就存儲而言,，我們來逐一分析，這些產(chǎn)品是否都能具備滿足業(yè)務(wù)需求的能力,。
首先是基于離線存儲的Hive,，其次是提供點查詢能力的HBase、Cassandra,、然后是MPP架構(gòu)號稱能面向HTAP的Greenplum、以及最新興起的用于做快速分析的Clickhouse等等都是基于解決方案而面世的存儲產(chǎn)品,。
但以上的每個存儲產(chǎn)品都是一個數(shù)據(jù)的孤島,，比如為了解決點查詢的問題，數(shù)據(jù)需要在HBase里面存儲一份,；為了解決列存的快速分析,，數(shù)據(jù)需要在Druid或者Clickhouse里面存一份；為了解決離線計算又需要在Hive里面存儲一份,，這樣帶來的問題就是：

1）冗余存儲

數(shù)據(jù)將會存儲在多個系統(tǒng)中,，增加冗余存粗。

2）高維護成本

每個系統(tǒng)的數(shù)據(jù)格式不一致,，數(shù)據(jù)需要做轉(zhuǎn)換,，增加維護成本，尤其是當業(yè)務(wù)到達一定量級時,，維護成本劇增,。

3）高學(xué)習(xí)成本

多個系統(tǒng)之前需要完全打通，不同的產(chǎn)品有不同的開發(fā)方式,，尤其是針對新人來說,，需要投入更多的精力去學(xué)習(xí)多種系統(tǒng)，增加學(xué)習(xí)成本,。
在這里插入圖片描述

1.5 簡化的大數(shù)據(jù)架構(gòu)

面對這樣一個無比冗余無比復(fù)雜的系統(tǒng),，我們應(yīng)該怎么去解決這些問題呢？我們可以對Lambda架構(gòu)做一個簡化,。其實業(yè)務(wù)的本質(zhì)就是將數(shù)據(jù)源做一個實時處理或者離線處理（批處理）,，從業(yè)務(wù)場景出發(fā)，我們希望不管是實時數(shù)據(jù)還是離線數(shù)據(jù),，都能統(tǒng)一存儲在一個存儲系統(tǒng)里面,，而且這個存儲還必須要滿足各種各樣的業(yè)務(wù)需求。這樣聽起來很玄乎,，感覺這個產(chǎn)品需要支持各種各種的場景,，非常復(fù)雜。但是如果我們能把架構(gòu)做成這樣,，將會非常完美,，這樣就從本質(zhì)上解決了流批統(tǒng)一的計算問題,，一套SQL既能做流計算又能做批計算，再深挖其底層原理,，還解決了存儲問題,，流數(shù)據(jù)和批數(shù)據(jù)都統(tǒng)一存儲在同一個產(chǎn)品。
在這里插入圖片描述

二,、看起來很完美的Data Lakes

針對以上簡化的架構(gòu),，我們可以看看開源社區(qū)為了解決這些問題所推出的一些產(chǎn)品，例如Data Lakes,。
首先采集的數(shù)據(jù)有統(tǒng)一的存儲,，不管是HDFS、OSS還是AWS,，數(shù)據(jù)以增量的形式存儲在數(shù)據(jù)湖里,，再通過查詢層不管是Hive、Spark還是Flink,，根據(jù)業(yè)務(wù)需求選擇一個產(chǎn)品來做查詢,，這樣實時數(shù)據(jù)以及離線數(shù)據(jù)都能直接查詢。整個架構(gòu)看起來很美好,，但是實際問題在于：

1）數(shù)據(jù)增量寫入不滿足實時性

開源的實時寫入并不是實時寫入,，而是增量寫入。實時和增量的區(qū)別在于,，實時寫一條數(shù)據(jù)就能立馬查詢可見,，但是增量為了提高吞吐會將數(shù)據(jù)一批一批的寫入。那么這套方案就不能完全滿足數(shù)據(jù)實時性的要求,。

2）查詢的QPS

我們希望這個架構(gòu)既能做實時分析,，又能做流計算的維表查詢，存儲里面的數(shù)據(jù)能否通過Flink做一個高并發(fā)的查詢,，例如每秒鐘支持上千萬上億QPS的查詢,？

3）查詢的并發(fā)度

整個方案本質(zhì)都是離線計算引擎，只能支持較低的并發(fā),，如果要支持每秒鐘上千的并發(fā),，需要耗費大量的資源，增加成本,。
在這里插入圖片描述
綜上所述,，這個方案目前還不能完全解決問題，只能作為一個初期的解決方案,。

三,、HSAP之我見

3.1 什么是HSAP

針對以上問題我們做了一個細致的分析，大致根據(jù)查詢并發(fā)度要求或者查詢Latency要求，將Patterns分為四類：

Batch：離線計算
Analytical：交互式分析
Servering：高QPS的在線服務(wù)
Transaction：與錢相關(guān)的傳統(tǒng)數(shù)據(jù)庫（絕大多數(shù)業(yè)務(wù)并不需要）

目前市面上都在說HTAP,，經(jīng)過我們調(diào)研HTAP是個偽命題,，因為A和T的優(yōu)化方向不一樣。為了做T,，寫入鏈路將非常復(fù)雜,，QPS無法滿足需求。若是對T的要求降低一點,，就會發(fā)現(xiàn)Analytical和Severing的聯(lián)系非常緊密,，這兩塊的技術(shù)是可以共用的，所以我們放棄了T就相當于放棄了Transaction,，于是我們提出新的一個架構(gòu)叫做HSAP,，那我們需要做的就是把提供服務(wù)和分析的數(shù)據(jù)存儲在一個系統(tǒng)里，通過一套分析引擎做處理,。
在這里插入圖片描述

3.2 基于HSAP的大數(shù)據(jù)架構(gòu)

HASP系統(tǒng)接入到我們剛剛簡化的架構(gòu)中就成為非常的完美的大數(shù)據(jù)架構(gòu)。HSAP系統(tǒng)與Flink做維表關(guān)聯(lián),，對離線數(shù)據(jù)做批處理,，然后對接在線應(yīng)用提供在線服務(wù)，例如報表,、大盤等,。
在這里插入圖片描述

3.3 PostgreSQL生態(tài)

那么接入HSAP系統(tǒng)之后，在線應(yīng)用和系統(tǒng)怎么樣來用呢,？為了減少使用難度,，就要引需要一個生態(tài)系統(tǒng)來做支撐，經(jīng)過我們反復(fù)調(diào)研,，我們認為是PostgreSQL,，主要有以下幾點：

1）豐富的工具對接

PostgreSQL具有非常完備的工具對接，不管是開發(fā)工具還是BI分析工具,，都有著豐富的支撐能力,。

2）詳盡的文檔支撐

通常來講寫文檔需要耗費大量的時間，PostgreSQL有著非常詳盡的文檔,，如果能夠直接復(fù)用PostgreSQL的文檔,，將會減少工作量。同時開發(fā)者們只需要根據(jù)postgreSQL文檔來開發(fā),，減少學(xué)習(xí)成本,。

3）多元化的擴展

PostgreSQL有著非常多元化的擴展，例如地理信息的PostGis,，Matlab等,，開發(fā)者們可以根據(jù)業(yè)務(wù)需求選擇對應(yīng)的擴展。
在這里插入圖片描述

四、新一代的實時交互式引擎–Hologres

基于以上所有內(nèi)容,，進入到我們今天的重點主題,，也就是我們在阿里云重磅發(fā)布的新一代實時交互式引擎，中文名叫交互式分析,，英文名叫Hologres,。Hologres這個名字怎么來的呢？Hologres由Holographic（全息宇宙）和Postgres組成,。
在這里插入圖片描述

4.1 Hologres的架構(gòu)

Hologres的架構(gòu)比較簡單,，從下往上看，最底層是統(tǒng)一的存儲系統(tǒng),，可以是阿里云統(tǒng)一的Pangu,、業(yè)務(wù)的HDFS或者OSS、S3等,，存儲上面是計算層,，提供類似的MMP架構(gòu)計算服務(wù)，再往上是FE層,，根據(jù)查詢信息將Plan分發(fā)到各個計算節(jié)點,，再往上就是PostgreSQL生態(tài)的對接，只要有JDBC/ODBC Driver就能對Hologres做查詢,。
在這里插入圖片描述

4.2 Hologres：云原生

1）存儲計算分離

Hologres的架構(gòu)是完全是存儲計算分離,，計算完全部署在K8s上，存儲可以使用共享存儲,，可以根據(jù)業(yè)務(wù)需求選擇HDFS或者云上的OSS,，這樣用戶就能根據(jù)業(yè)務(wù)需求對資源做彈性擴縮容，完美解決資源不夠帶來的并發(fā)問題,。
在這里插入圖片描述

2）存儲優(yōu)勢

全異步：支持高并發(fā)寫入,，能夠?qū)PU最大化利用；
無鎖：寫入能力隨資源線性擴展,，直到將CPU全部寫滿,；
內(nèi)存管理：提供數(shù)據(jù)cache，支持高并發(fā)查詢,。

3）計算優(yōu)勢

高性能混合負載：慢查詢和快查詢混合一起跑,，通過內(nèi)部的調(diào)度系統(tǒng)，避免慢查詢影響快查詢,；
向量化計算：列式數(shù)據(jù)通過向量化計算達到查詢加速的能力,；
存儲優(yōu)化：能夠定制查詢引擎，但是對存儲在Hologres數(shù)據(jù)查詢性能會更優(yōu),。

4.3 基于Hologres的典型應(yīng)用

下面給大家介紹一下,，Hologres在阿里巴巴內(nèi)部的一個典型應(yīng)用,。數(shù)據(jù)實時寫入至Flink，經(jīng)由Flink做實時預(yù)處理,，比如實時ETL或者實時訓(xùn)練,，把處理的結(jié)果直接寫入Hologres，Hologres提供維表關(guān)聯(lián)點查,、結(jié)果緩存,、復(fù)雜實時交互、離線查詢和聯(lián)邦查詢等,，這樣整個業(yè)務(wù)系統(tǒng)只需要通過Hologres來做唯一的數(shù)據(jù)入口,，在線系統(tǒng)可以通過PostgreSQL生態(tài)在Hologres中訪問數(shù)據(jù)，無需對接其他系統(tǒng),，這樣也能解決之前架構(gòu)的各種查詢,、存儲問題。
在這里插入圖片描述

4.4 真正的實時數(shù)倉：Flink+Hologres

綜上所述,，我們認為,，真正的實時數(shù)倉只需要Flink+Hologres即可，F(xiàn)link做流,、批數(shù)據(jù)的ETL處理,，將處理的數(shù)據(jù)寫入Hologres做統(tǒng)一的存儲和查詢，這樣業(yè)務(wù)端直接對接Hologres提供在線服務(wù),。
在這里插入圖片描述