作者：
蔣曉偉（量仔） 阿里云研究員
金曉軍(仙隱) 阿里云高級(jí)技術(shù)專家
摘要
數(shù)據(jù)倉(cāng)庫(kù)，數(shù)據(jù)湖，包括Flink社區(qū)提的流批一體，它們到底能解決什么問題？今天將由阿里云研究員從解決業(yè)務(wù)問題出發(fā)，將問題抽絲剝繭，從技術(shù)維度娓娓道來：為什么你需要數(shù)據(jù)湖或者數(shù)據(jù)倉(cāng)庫(kù)解決方案？它的核心難點(diǎn)與核心問題在哪？如果想穩(wěn)定落地，系統(tǒng)設(shè)計(jì)該怎么做？
業(yè)務(wù)背景
1.1 典型實(shí)時(shí)業(yè)務(wù)場(chǎng)景
首先我們來看一個(gè)典型的實(shí)時(shí)業(yè)務(wù)場(chǎng)景，這個(gè)場(chǎng)景也是絕大部分實(shí)時(shí)計(jì)算用戶的業(yè)務(wù)場(chǎng)景，整個(gè)鏈路也是一個(gè)典型的流計(jì)算架構(gòu)：把用戶的行為數(shù)據(jù)或者數(shù)據(jù)庫(kù)同步的Binlog，寫入至kafka，再通過Flink做同步任務(wù)，訂閱kafka消費(fèi)的實(shí)時(shí)數(shù)據(jù)，這個(gè)過程中需要做幾件事情，比如Preprocessing（預(yù)處理），在處理的過程中做Online Training（在線訓(xùn)練），在線訓(xùn)練過程中需要關(guān)聯(lián)一些維表或者特征，這些特征可能可以全量加載到計(jì)算節(jié)點(diǎn)里面去，也有可能非常大，就需要用HBase做一個(gè)高并發(fā)的點(diǎn)查，比如我們做一些樣本也會(huì)寫入到HBase中去，形成一個(gè)交互過程，最后實(shí)時(shí)產(chǎn)生的采樣數(shù)據(jù)或者訓(xùn)練模型推到搜索引擎或者算法模塊中。以上就是一個(gè)很典型的machine Learning的完整鏈路。
1.2 越來越復(fù)雜的架構(gòu)
以上場(chǎng)景展示的鏈路與離線鏈路是相輔相成的，也有一些公司實(shí)時(shí)的鏈路還沒有建立起來，用的是離線鏈路，不過這套鏈路已經(jīng)是一個(gè)非常成熟的方案了。如果我們把這個(gè)鏈路變得更加復(fù)雜一些，看看會(huì)帶來什么樣的問題。首先我們把剛剛的鏈路做一個(gè)變化，實(shí)時(shí)數(shù)據(jù)寫入kafka，再經(jīng)過Flink做實(shí)時(shí)的機(jī)器學(xué)習(xí)或者指標(biāo)計(jì)算，把結(jié)果寫入到在線服務(wù)，例如HBase或者Cassandra用來做點(diǎn)查，再接入在線大盤，做指標(biāo)的可視化展現(xiàn)。
這里面產(chǎn)生的一個(gè)問題就是：在線產(chǎn)生的數(shù)據(jù)和樣本，如果想對(duì)它們做一個(gè)分析，基于HBase或者Cassandra的分析能力是非常弱的且性能是非常差的。
那么怎么辦呢？
有聰明的開發(fā)者們可能就有一些實(shí)現(xiàn)方式如下：
HBase或者Cassandra不滿足分析需求，就把實(shí)時(shí)數(shù)據(jù)寫入至適合數(shù)據(jù)分析的系統(tǒng)中，比如ClickHouse或者Druid，這些都是典型的列存架構(gòu)，能構(gòu)建index、或者通過向量化計(jì)算加速列式計(jì)算的分析，再對(duì)接分析軟件，對(duì)數(shù)據(jù)做實(shí)時(shí)報(bào)表、實(shí)時(shí)分析展現(xiàn)等，以此鏈路來解決實(shí)時(shí)高效分析的問題。
但上面的架構(gòu)中，還有一些額外的需求，就是要將實(shí)時(shí)產(chǎn)生的數(shù)據(jù)數(shù)據(jù)歸檔至離線系統(tǒng)，對(duì)離線數(shù)據(jù)做一個(gè)基于歷史的全量分析，基于此開發(fā)者們最常用的鏈路就是把實(shí)時(shí)數(shù)據(jù)離線的歸檔至Hive中，在Hive中做T+1天或者其他的離線算法。通過Hive對(duì)離線數(shù)據(jù)的處理來滿足離線場(chǎng)景的需求。
但是業(yè)務(wù)既有實(shí)時(shí)寫入的數(shù)據(jù)又有離線的數(shù)據(jù)，有時(shí)我們需要對(duì)實(shí)時(shí)數(shù)據(jù)和離線數(shù)據(jù)做一個(gè)聯(lián)邦查詢，那應(yīng)該怎么辦呢？
基于現(xiàn)市面上的開源體系，開發(fā)者們最常用的架構(gòu)就是基于Drill或者Presto，通過類似MPP的架構(gòu)層做多數(shù)據(jù)的聯(lián)邦查詢，若是速度不夠快，還能通過Druid、ClickHouse等做查詢加速。
以上聯(lián)邦查詢的鏈路有個(gè)問題就是，QPS很難上去，比如前端調(diào)用需要每秒鐘幾百上千的QPS，如果幾百上千的QPS全部通過加速層來做，那性能肯定是有所下降的，這時(shí)應(yīng)該怎么辦呢？最常見的解決方案就是在常見的加速層再加一個(gè)cache，用來抵擋高并發(fā)的請(qǐng)求，一般是加redis或者M(jìn)ySQL用來cache數(shù)據(jù)，這樣就能提供server以及在線服務(wù)的能力。
1.3 典型的大數(shù)據(jù)Lambda架構(gòu)
以上就是絕大部分公司所使用的大數(shù)據(jù)架構(gòu)，也有很多公司是根據(jù)業(yè)務(wù)場(chǎng)景選擇了其中一部分架構(gòu)，這樣既有實(shí)時(shí)又有離線的大數(shù)據(jù)完整架構(gòu)就搭建出來，看起來很完美，能實(shí)際解決問題，但是仔細(xì)想想，里面藏了很多坑，越往后做越舉步維艱，那么問題在哪呢？現(xiàn)在我們來仔細(xì)看一下。
其實(shí)這套大數(shù)據(jù)方案本質(zhì)上就是一個(gè)Lambda架構(gòu)，原始數(shù)據(jù)都是一個(gè)源頭，例如用戶行為日志、Binlog等，分別走了兩條鏈路：一條是實(shí)時(shí)鏈路，也就是加速層（Speed Layer），通過流計(jì)算處理，把數(shù)據(jù)寫入實(shí)時(shí)的存儲(chǔ)系統(tǒng)；另一條鏈路就是離線鏈路，也就是批計(jì)算，最典型的就是將數(shù)據(jù)歸檔至Hive，再通過查詢層如Spark對(duì)數(shù)據(jù)做加速查詢，最后再對(duì)接在線應(yīng)用、大盤或者第三方BI工具。
1.4 典型大數(shù)據(jù)架構(gòu)的痛點(diǎn)
針對(duì)市面上這些開源產(chǎn)品，就存儲(chǔ)而言，我們來逐一分析，這些產(chǎn)品是否都能具備滿足業(yè)務(wù)需求的能力。
首先是基于離線存儲(chǔ)的Hive，其次是提供點(diǎn)查詢能力的HBase、Cassandra、然后是MPP架構(gòu)號(hào)稱能面向HTAP的Greenplum、以及最新興起的用于做快速分析的Clickhouse等等都是基于解決方案而面世的存儲(chǔ)產(chǎn)品。
但以上的每個(gè)存儲(chǔ)產(chǎn)品都是一個(gè)數(shù)據(jù)的孤島，比如為了解決點(diǎn)查詢的問題，數(shù)據(jù)需要在HBase里面存儲(chǔ)一份；為了解決列存的快速分析，數(shù)據(jù)需要在Druid或者Clickhouse里面存一份；為了解決離線計(jì)算又需要在Hive里面存儲(chǔ)一份，這樣帶來的問題就是：
1）冗余存儲(chǔ)
數(shù)據(jù)將會(huì)存儲(chǔ)在多個(gè)系統(tǒng)中，增加冗余存粗。
2）高維護(hù)成本
每個(gè)系統(tǒng)的數(shù)據(jù)格式不一致，數(shù)據(jù)需要做轉(zhuǎn)換，增加維護(hù)成本，尤其是當(dāng)業(yè)務(wù)到達(dá)一定量級(jí)時(shí)，維護(hù)成本劇增。
3）高學(xué)習(xí)成本
多個(gè)系統(tǒng)之前需要完全打通，不同的產(chǎn)品有不同的開發(fā)方式，尤其是針對(duì)新人來說，需要投入更多的精力去學(xué)習(xí)多種系統(tǒng)，增加學(xué)習(xí)成本。
1.5 簡(jiǎn)化的大數(shù)據(jù)架構(gòu)
面對(duì)這樣一個(gè)無比冗余無比復(fù)雜的系統(tǒng)，我們應(yīng)該怎么去解決這些問題呢？我們可以對(duì)Lambda架構(gòu)做一個(gè)簡(jiǎn)化。其實(shí)業(yè)務(wù)的本質(zhì)就是將數(shù)據(jù)源做一個(gè)實(shí)時(shí)處理或者離線處理（批處理），從業(yè)務(wù)場(chǎng)景出發(fā)，我們希望不管是實(shí)時(shí)數(shù)據(jù)還是離線數(shù)據(jù)，都能統(tǒng)一存儲(chǔ)在一個(gè)存儲(chǔ)系統(tǒng)里面，而且這個(gè)存儲(chǔ)還必須要滿足各種各樣的業(yè)務(wù)需求。這樣聽起來很玄乎，感覺這個(gè)產(chǎn)品需要支持各種各種的場(chǎng)景，非常復(fù)雜。但是如果我們能把架構(gòu)做成這樣，將會(huì)非常完美，這樣就從本質(zhì)上解決了流批統(tǒng)一的計(jì)算問題，一套SQL既能做流計(jì)算又能做批計(jì)算，再深挖其底層原理，還解決了存儲(chǔ)問題，流數(shù)據(jù)和批數(shù)據(jù)都統(tǒng)一存儲(chǔ)在同一個(gè)產(chǎn)品。
看起來很完美的Data Lakes
針對(duì)以上簡(jiǎn)化的架構(gòu)，我們可以看看開源社區(qū)為了解決這些問題所推出的一些產(chǎn)品，例如Data Lakes。
首先采集的數(shù)據(jù)有統(tǒng)一的存儲(chǔ)，不管是HDFS、OSS還是AWS，數(shù)據(jù)以增量的形式存儲(chǔ)在數(shù)據(jù)湖里，再通過查詢層不管是Hive、Spark還是Flink，根據(jù)業(yè)務(wù)需求選擇一個(gè)產(chǎn)品來做查詢，這樣實(shí)時(shí)數(shù)據(jù)以及離線數(shù)據(jù)都能直接查詢。整個(gè)架構(gòu)看起來很美好，但是實(shí)際問題在于：
1）數(shù)據(jù)增量寫入不滿足實(shí)時(shí)性
開源的實(shí)時(shí)寫入并不是實(shí)時(shí)寫入，而是增量寫入。實(shí)時(shí)和增量的區(qū)別在于，實(shí)時(shí)寫一條數(shù)據(jù)就能立馬查詢可見，但是增量為了提高吞吐會(huì)將數(shù)據(jù)一批一批的寫入。那么這套方案就不能完全滿足數(shù)據(jù)實(shí)時(shí)性的要求。
2）查詢的QPS
我們希望這個(gè)架構(gòu)既能做實(shí)時(shí)分析，又能做流計(jì)算的維表查詢，存儲(chǔ)里面的數(shù)據(jù)能否通過Flink做一個(gè)高并發(fā)的查詢，例如每秒鐘支持上千萬上億QPS的查詢？
3）查詢的并發(fā)度
整個(gè)方案本質(zhì)都是離線計(jì)算引擎，只能支持較低的并發(fā)，如果要支持每秒鐘上千的并發(fā)，需要耗費(fèi)大量的資源，增加成本。
綜上所述，這個(gè)方案目前還不能完全解決問題，只能作為一個(gè)初期的解決方案。
HSAP之我見
3.1 什么是HSAP
針對(duì)以上問題我們做了一個(gè)細(xì)致的分析，大致根據(jù)查詢并發(fā)度要求或者查詢Latency要求，將Patterns分為四類：
·Batch：離線計(jì)算
·Analytical：交互式分析
·Servering：高QPS的在線服務(wù)
·Transaction：與錢相關(guān)的傳統(tǒng)數(shù)據(jù)庫(kù)（絕大多數(shù)業(yè)務(wù)并不需要）
目前市面上都在說HTAP，經(jīng)過我們調(diào)研HTAP是個(gè)偽命題，因?yàn)锳和T的優(yōu)化方向不一樣。為了做T，寫入鏈路將非常復(fù)雜，QPS無法滿足需求。若是對(duì)T的要求降低一點(diǎn)，就會(huì)發(fā)現(xiàn)Analytical和Severing的聯(lián)系非常緊密，這兩塊的技術(shù)是可以共用的，所以我們放棄了T就相當(dāng)于放棄了Transaction，于是我們提出新的一個(gè)架構(gòu)叫做HSAP，那我們需要做的就是把提供服務(wù)和分析的數(shù)據(jù)存儲(chǔ)在一個(gè)系統(tǒng)里，通過一套分析引擎來做處理。
3.2 基于HSAP的大數(shù)據(jù)架構(gòu)
HASP系統(tǒng)接入到我們剛剛簡(jiǎn)化的架構(gòu)中就成為非常的完美的大數(shù)據(jù)架構(gòu)。HSAP系統(tǒng)與Flink做維表關(guān)聯(lián)，對(duì)離線數(shù)據(jù)做批處理，然后對(duì)接在線應(yīng)用提供在線服務(wù)，例如報(bào)表、大盤等。
3.3 PostgreSQL生態(tài)
那么接入HSAP系統(tǒng)之后，在線應(yīng)用和系統(tǒng)怎么樣來用呢？為了減少使用難度，就要引需要一個(gè)生態(tài)系統(tǒng)來做支撐，經(jīng)過我們反復(fù)調(diào)研，我們認(rèn)為是PostgreSQL，主要有以下幾點(diǎn)：
1）豐富的工具對(duì)接
PostgreSQL具有非常完備的工具對(duì)接，不管是開發(fā)工具還是BI分析工具，都有著豐富的支撐能力。
2）詳盡的文檔支撐
通常來講寫文檔需要耗費(fèi)大量的時(shí)間，PostgreSQL有著非常詳盡的文檔，如果能夠直接復(fù)用PostgreSQL的文檔，將會(huì)減少工作量。同時(shí)開發(fā)者們只需要根據(jù)postgreSQL文檔來開發(fā)，減少學(xué)習(xí)成本。
3）多元化的擴(kuò)展
PostgreSQL有著非常多元化的擴(kuò)展，例如地理信息的PostGis，Matlab等，開發(fā)者們可以根據(jù)業(yè)務(wù)需求選擇對(duì)應(yīng)的擴(kuò)展。
新一代的實(shí)時(shí)交互式引擎--Hologres
基于以上所有內(nèi)容，進(jìn)入到我們今天的重點(diǎn)主題，也就是我們?cè)诎⒗镌浦匕醢l(fā)布的新一代實(shí)時(shí)交互式引擎，中文名叫交互式分析，英文名叫Hologres。Hologres這個(gè)名字怎么來的呢？Hologres由Holographic（全息宇宙）和Postgres組成。
4.1 Hologres的架構(gòu)
Hologres的架構(gòu)比較簡(jiǎn)單，從下往上看，最底層是統(tǒng)一的存儲(chǔ)系統(tǒng)，可以是阿里云統(tǒng)一的Pangu、業(yè)務(wù)的HDFS或者OSS、S3等，存儲(chǔ)上面是計(jì)算層，提供類似的MMP架構(gòu)計(jì)算服務(wù)，再往上是FE層，根據(jù)查詢信息將Plan分發(fā)到各個(gè)計(jì)算節(jié)點(diǎn)，再往上就是PostgreSQL生態(tài)的對(duì)接，只要有JDBC/ODBC Driver就能對(duì)Hologres做查詢。
4.2 Hologres：云原生
1）存儲(chǔ)計(jì)算分離
Hologres的架構(gòu)是完全是存儲(chǔ)計(jì)算分離，計(jì)算完全部署在K8s上，存儲(chǔ)可以使用共享存儲(chǔ)，可以根據(jù)業(yè)務(wù)需求選擇HDFS或者云上的OSS，這樣用戶就能根據(jù)業(yè)務(wù)需求對(duì)資源做彈性擴(kuò)縮容，完美解決資源不夠帶來的并發(fā)問題。
2）存儲(chǔ)優(yōu)勢(shì)
·全異步：支持高并發(fā)寫入，能夠?qū)PU最大化利用；
·無鎖：寫入能力隨資源線性擴(kuò)展，直到將CPU全部寫滿；
·內(nèi)存管理：提供數(shù)據(jù)cache，支持高并發(fā)查詢。
3）計(jì)算優(yōu)勢(shì)
·高性能混合負(fù)載：慢查詢和快查詢混合一起跑，通過內(nèi)部的調(diào)度系統(tǒng)，避免慢查詢影響快查詢；
·向量化計(jì)算：列式數(shù)據(jù)通過向量化計(jì)算達(dá)到查詢加速的能力；
·存儲(chǔ)優(yōu)化：能夠定制查詢引擎，但是對(duì)存儲(chǔ)在Hologres數(shù)據(jù)查詢性能會(huì)更優(yōu)。
4.3 基于Hologres的典型應(yīng)用
下面給大家介紹一下，Hologres在阿里巴巴內(nèi)部的一個(gè)典型應(yīng)用。數(shù)據(jù)實(shí)時(shí)寫入至Flink，經(jīng)由Flink做實(shí)時(shí)預(yù)處理，比如實(shí)時(shí)ETL或者實(shí)時(shí)訓(xùn)練，把處理的結(jié)果直接寫入Hologres，Hologres提供維表關(guān)聯(lián)點(diǎn)查、結(jié)果緩存、復(fù)雜實(shí)時(shí)交互、離線查詢和聯(lián)邦查詢等，這樣整個(gè)業(yè)務(wù)系統(tǒng)只需要通過Hologres來做唯一的數(shù)據(jù)入口，在線系統(tǒng)可以通過PostgreSQL生態(tài)在Hologres中訪問數(shù)據(jù)，無需對(duì)接其他系統(tǒng)，這樣也能解決之前架構(gòu)的各種查詢、存儲(chǔ)問題。
4.4 真正的實(shí)時(shí)數(shù)倉(cāng)：Flink+Hologres
綜上所述，我們認(rèn)為，真正的實(shí)時(shí)數(shù)倉(cāng)只需要Flink+Hologres即可，F(xiàn)link做流、批數(shù)據(jù)的ETL處理，將處理的數(shù)據(jù)寫入Hologres做統(tǒng)一的存儲(chǔ)和查詢，這樣業(yè)務(wù)端直接對(duì)接Hologres提供在線服務(wù)。
