作者：
蔣曉偉（量仔） 阿裡雲研究員
金曉軍(仙隐) 阿裡雲進階技術專家
摘要：資料倉庫，資料湖，包括Flink社群提的流批一體，它們到底能解決什麼問題？今天将由阿裡雲研究員從解決業務問題出發，将問題抽絲剝繭，從技術次元娓娓道來：為什麼你需要資料湖或者資料倉庫解決方案？它的核心難點與核心問題在哪？如果想穩定落地，系統設計該怎麼做？
一、業務背景
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、或者通過向量化計算加速列式計算的分析，再對接分析軟體，對資料做實時報表、實時分析展現等，以此鍊路來解決實時高效分析的問題。
但上面的架構中，還有一些額外的需求，就是要将實時産生的資料資料歸檔至離線系統，對離線資料做一個基于曆史的全量分析，基于此開發者們最常用的鍊路就是把實時資料離線的歸檔至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既能做流計算又能做批計算，再深挖其底層原理，還解決了存儲問題，流資料和批資料都統一存儲在同一個産品。
二、看起來很完美的Data Lakes
針對以上簡化的架構，我們可以看看開源社群為了解決這些問題所推出的一些産品，例如Data Lakes。
首先采集的資料有統一的存儲，不管是HDFS、OSS還是AWS，資料以增量的形式存儲在資料湖裡，再通過查詢層不管是Hive、Spark還是Flink，根據業務需求選擇一個産品來做查詢，這樣實時資料以及離線資料都能直接查詢。整個架構看起來很美好，但是實際問題在于：
1）資料增量寫入不滿足實時性
開源的實時寫入并不是實時寫入，而是增量寫入。實時和增量的差別在于，實時寫一條資料就能立馬查詢可見，但是增量為了提高吞吐會将資料一批一批的寫入。那麼這套方案就不能完全滿足資料實時性的要求。
2）查詢的QPS
我們希望這個架構既能做實時分析，又能做流計算的維表查詢，存儲裡面的資料能否通過Flink做一個高并發的查詢，例如每秒鐘支援上千萬上億QPS的查詢？
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的大資料架構
HSAP系統接入到我們剛剛簡化的架構中就成為非常的完美的大資料架構。HSAP系統與Flink做維表關聯，對離線資料做批處理，然後對接線上應用提供線上服務，例如報表、大盤等。
3.3 PostgreSQL生态
那麼接入HSAP系統之後，線上應用和系統怎麼樣來用呢？為了減少使用難度，就要引需要一個生态系統來做支撐，經過我們反複調研，我們認為是PostgreSQL，主要有以下幾點：
1）豐富的工具對接
PostgreSQL具有非常完備的工具對接，不管是開發工具還是BI分析工具，都有着豐富的支撐能力。
2）詳盡的文檔支撐
通常來講寫文檔需要耗費大量的時間，PostgreSQL有着非常詳盡的文檔，如果能夠直接複用PostgreSQL的文檔，将會減少工作量。同時開發者們隻需要根據postgreSQL文檔來開發，減少學習成本。
3）多元化的擴充
PostgreSQL有着非常多元化的擴充，例如地理資訊的PostGis，Matlab等，開發者們可以根據業務需求選擇對應的擴充。
四、新一代的實時互動式引擎--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中通路資料，無需對接其他系統，這樣也能解決之前架構的各種查詢、存儲問題。
4.4 真正的實時數倉：Flink+Hologres
綜上所述，我們認為，真正的實時數倉隻需要Flink+Hologres即可，Flink做流、批資料的ETL處理，将處理的資料寫入Hologres做統一的存儲和查詢，這樣業務端直接對接Hologres提供線上服務。
聯系我們
歡迎大家掃碼加入Hologres釘釘交流群，我們将會在群裡分享有關Hologres的最新産品咨詢、解讀産品技術以及為開發者們答疑解惑！
附件：演講材料
1）演講PDF
08-仙隐-Data WareHouse, Data Lakes, What's Next的副本.pdf2）視訊回看位址：
https://www.bilibili.com/video/BV1Uf4y1m7Hx?p=15