文章引用：https://zhuanlan.zhihu.com/p/141182199?from_voters_page=true
簡介： 數據倉庫，數據湖，包括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的大數據架構
HASP系統接入到我們剛剛簡化的架構中就成為非常的完美的大數據架構。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提供在線服務。
