作者： StarRocks Active Co ntributor、微信 OLAP 內核研發工程師 馮呂
小編導讀：
微信作為國內活躍使用者最多的社交軟體，其數據平台建設經歷了從 Hadoop 到 ClickHouse 亞秒級即時數倉的階段，但仍舊面臨著數據體驗割裂、儲存冗余的問題。透過 StarRocks 的湖倉一體方案，以及和社群密切配合開發的即時增量物化檢視，微信解決了「即時、極速」背後的「統一」訴求。在直播業務場景中，透過湖上建倉的方案改造，使得數據開發同學需要運維的任務數減半，同時儲存成本降低65%以上，離線任務產出時間縮短兩小時。
當前，基於 StarRocks 的湖倉一體方案已經在微信的多個業務場景中上線使用，包括視訊號直播、微信鍵盤、微信讀書和公眾號等，集群規模達到數百台機器，數據接入量近千億，向理想化的湖倉一體形態不斷演進。
背景
從 Hadoop 到亞秒級即時數倉建設 ： 多年以前，微信的數據分析架構還是完全基於 Hadoop 生態的，其存在著較多的弊端：首先，查詢非常慢，數據延遲高，業務同學進行數據開發也很慢；其次，在架構方面，采用的是流批分離的架構，整體架構非常臃腫。
隨著微信業務的不斷發展，視訊號等推薦系統對個人化體驗的強烈訴求，我們基於 ClickHouse 內核打造了亞秒級的 OLAP 即時數倉，廣泛用於 A/B 實驗平台、BI 分析、即時指標計算等場景中。在基於 ClickHouse 的即時數倉中，我們做到了億行數據的亞秒級響應，海量數據的低延遲、精確一次接入，實作了流批一體架構。
「即時、極速」後的「統一」訴求 ： 一直以來，數據分析技術棧從 MySQL 開始基本上是沿著兩條路線不斷往前演進的，一條是即時的路線，另一條是極速的路線。即時的路線經歷了從 Lambda 架構到 Kappa 架構，再演進到最近的 Data Lake，形成流批一體；而極速的路線經歷了從 Hive 小時以上的分析時延，然後演進到 SparkSQL，再到 Presto/Druid/Kylin 達到分鐘級的查詢時延，最終演進到了諸如 ClickHouse 這類的 OLAP 資料庫，達到亞秒級響應。從未來的趨勢來看，兩者會形成統一，這也是湖倉一體/Modern OLAP 所要達到的目標。
在微信的數據分析場景中，主要面臨三個方面的挑戰：
海量數據：在我們的業務場景下，數據規模很大，單表日增萬億，單次查詢掃描數據量在10億以上，同時需要計算的指標和維度可能會非常多（50+維度，100+指標）；
極速：微信業務場景對查詢耗時要求極高，查詢耗時 TP 90 需要在5秒以內，同時要求數據低時效（秒/分鐘）；
統一：我們希望能夠實作計算側和儲存側的統一。
過去，在基於 ClickHouse 的即時數倉中，我們 已經解決了海量數據和極速的挑戰，但還有一個統一的需求沒有解決 。
湖倉一體
湖倉一體要解決的是通用大數據計算引擎處理 OLAP 數倉體驗割裂、儲存多份的問題。過去，無論是在湖上面還是倉上面，都存在著相應的困境。
湖上面面臨的主要問題是查詢效能太慢，如果需要對 Hadoop 中的數據進行即席查詢，則需要先將數據匯出到 OLAP 資料庫中再進行查詢加工，造成了資源的浪費，工序繁瑣；而倉上面，存在著通用大數據計算引擎處理 OLAP 即時數倉生態不夠友好的問題，例如，Spark 無法直接分析 ClickHouse 中的數據，如果要進行查詢分析，則需要先將數據從 ClickHouse 落回 Hive 中。總結來看，過去的架構存在的問題就是：
兩份儲存
口徑不一致
額外的數據匯入匯出步驟
數據分析流程難以標準化
透過湖倉一體架構，我們希望能夠真正解決上述問題，實作儲存統一、介面統一、後設資料統一，亞秒級查詢與分鐘級查詢統一等，最終理想化的湖倉一體形態：面向 SQL ，使用者不再需要感知底層架構。
01
技術路線一：湖上建倉實作湖倉一體的第一種技術路線是湖上建倉，即在數據湖基礎上實作數倉的功能，代替傳統數倉，構建 Lakehouse：在傳統 Hadoop 系統中引入 Delta lake、Hudi、Iceberg 或 Hive 3.0 等更新技術；引入 Presto、Impala 等 SQL on Hadoop 查詢引擎；引入 Hive Meta Store 進行統一後設資料和許可權管理；引入物件儲存作為底層儲存等數倉特性，形成湖倉一體，業務比較有代表性的是 Databricks 提出的湖倉一體架構。
在微信內部，湖上建倉的架構經歷了從 Presto + Hive 到 StarRocks + Iceberg 的演變過程，透過使用 StarRocks 替代 Presto，數據的時效性從小時/天級提高到了分鐘級，同時查詢效率從分鐘級提高到了秒級/分鐘級，其中80%的大查詢用 StarRocks 解決，秒級返回，剩下的超大查詢透過 Spark 來解決。
秒級：中大表，秒級返回，StarRocks
分鐘級：大表查詢，分鐘級，Spark
與 Presto 相比，StarRocks 直接查湖的效能提升 3-6 倍以上。
目前，在我們的使用場景中，湖上建倉的方案主要透過外掛排程的方式來實作。未來，當 StarRocks 的外表物化檢視功能更加成熟以後，會采用更加簡潔、方便、易於運維的外表物化檢視來實作。
湖上建倉方案具有的優點是成本低，實作簡單，同時 Hadoop 生態相容性更好。但其存在的缺點是：數據延遲較高，需要5-10分鐘左右；另外，ODS、DWD 層的查詢會比較慢，需要透過本地緩存等方式來進行加速。因此，綜合來看，湖上建倉的方案主要還是湖為主，更適合於離線分析為主的場景。
02
技術路線二：倉湖融合實作湖倉一體的第二種技術路線是倉湖融合，透過在數倉中加入跨源融合聯邦查詢的功能，打通內容儲存，從而不需要經過 ETL 能夠直接分析數據湖。在該方案中，我們采用冷存下沈的手段，實作倉湖數據的統一。
在該方案中，數據會先即時接入倉，之後，冷存經過轉換下沈到湖，透過 Meta Server 實作倉湖後設資料的統一管理，在查詢時，能夠合並冷熱數據讀取，同時，透過 SparkLake API 提供對通用離線計算的支持。在該方案中，由於數據是先落倉的，因此數據的即時性會更高，在秒級到2分鐘以內，同時 DWD 層的查詢響應會更快。但其缺點是成本高（熱數據TTL），Hadoop 生態相容性不如湖上建倉的方案。因此，綜合來看，倉湖融合的方案主要還是考慮倉為主，更適合於實分時析為主的場景。
當前，倉湖融合、冷存下沈的湖倉一體方案已經在微信安全的業務場景中落地，接入的大表每日數據量達數十億，超大表每日數據量千億以上。小分時區降冷耗分時鐘級，天分區降冷耗時小時級；在記憶體消耗方面，單任務最大消耗 5GB 左右，對集群無明顯影響。
同時，透過 BE/FE 參數調優：compaction 執行緒數比例調整、flush 執行緒數調整、並行事務數調整，消除了大表並行時的數據擠壓，全天穩定執行：
上線前
上線後
03
湖倉一體架構從前面的分析中可以看到，湖上建倉和倉湖融合兩種方案各有優缺點，分別適用於湖為主和倉為主的業務場景，而在微信的業務場景中，兩種路線都有需求。
因此，在我們的湖倉一體方案中，采用的是湖上建倉和倉下沈湖的融合方案。
在該方案中，我們同時支持即時接入和準即時接入，使用者可以根據自身對成本、效能和數據時效性的要求來選擇透過哪種方式進行接入，並且是可切換的。例如，剛開始時，使用者對效能、數據時效性要求不是特別高，那麽可以選擇透過湖接入的方式，這樣成本較低，當後續該使用者對效能和數據時效性要求變高了，那麽他可以切換到倉接入的方式，這樣就可以滿足需求。因此，在我們的湖倉一體架構中，既能夠支持極速 BI 分析的場景，也能夠滿足通用離線計算的需求。
即時增量物化檢視
過去，在 StarRocks 中主要有兩種不同型別的物化檢視：異步物化檢視和同步物化檢視。
異步 物化 檢視 會根據基表的數據變化，定時觸發重新整理或手動重新整理物化檢視更新數據變化，在進行重新整理時，需要對整個表或整個分區進行一次完整的 INSERT OVERWRITE，如下圖所示。在查詢基礎表時，最佳化器會根據物化檢視定義自動進行查詢覆寫，從而利用物化檢視的預計算結果來對查詢進行加速，同時也可以直接查詢物化檢視表的數據。
然而，由於需要不斷進行分區級的 INSERT OVERWRITE 重新整理，當基礎表的數據量比較大時，這一重新整理的過程開銷會非常大，容易影響集群整體負載和穩定性；同時，物化檢視是透過異步重新整理來更新數據的，更適合於離線數倉場景，而不適用於即時數倉場景。
同步 物化檢視 能夠在數據寫入基礎表的時候同步重新整理物化檢視。與異步物化檢視不同的是，同步物化檢視的結果是作為一個 Index 和基礎表繫結在一起的，物化檢視本身對使用者不可見，不能直接查詢。在查詢基礎表數據時，能夠基於基礎表中存在的同步物化檢視進行透明加速
然而， StarRocks 的同步物化檢視具有 一些 限制：
不支持復雜運算式，僅能夠對基礎表中的列進行簡單的聚合操作，無論是維度列還是指標列中，都不能包含復雜運算式；
不支持輸出列別名；
基礎表中的列不能在物化檢視中被多次參照；
僅支持少量聚合函式，不支持通用聚合函式；
物化檢視數據與基礎表強繫結，無法直接查詢物化檢視數據。
在湖倉一體場景下，對於即時性、效能要求高的場景，我們需要透過即時增量物化檢視來進行加速。微信的即時物化檢視具有如下一些特點：
大規模，單表數據量大，因此物化檢視只能增量更新，不能全量重新整理
即時性要求高：需要同步重新整理，不能異步重新整理
多表指標拼接：多個基礎表的物化檢視計算指標拼接到同一個物化檢視目標表中
在物化檢視寫入時進行高效能維表關聯
...
針對這些特點和要求，我們基於 StarRocks 的物化檢視功能，與社群共同在過去的同步物化檢視基礎上進行了新的探索，以適應這類更加復雜的分析。
物化檢視增強技術路線： 多流同步物化檢視 -> 全域字典關聯 -> streaming 物化檢視(doing) -> 湖上增量同步物化檢視
目前實作到第二階段，已經可以實作多數 ClickHouse 增量同步物化檢視的能力，下邊詳細介紹：
01
多流同步物化檢視在新的即時增量物化檢視設計中，我們將基礎表與儲存物化檢視結果的目標表進行了解耦，物化檢視本身僅用來表達計算邏輯，如下圖所示。這樣做有多個方面的原因：
在數倉體系中，基礎表通常屬於 ODS 層，需要保留3～7天，而儲存物化檢視結果的目標表屬於 DWS 層，通常需要保留半年到一年，將這兩者解耦之後，我們才能夠分別為其定義不同的儲存周期。
將物化檢視的計算邏輯和計算結果完全解耦，業務不需要關心具體的計算邏輯，直接查詢物化檢視目標表中儲存的指標結果即可，能夠極大提高易用性，同時能夠將上下遊業務邏輯解耦，上遊計算邏輯發生變化不會影響下遊使用。
最後，只有將兩者解耦，我們才能夠實作多個基礎表的協定關聯，透過讓多個基礎表的物化檢視計算結果寫同一個目標表，從而完成指標拼接。
02
基於全域字典的維表關聯在我們的物化檢視場景中，另一個比較關聯的需求是基於全域字典的維表關聯。維表關聯是在 BI 場景、流式計算中一個非常通用的問題。在過去，我們需要依賴於 Flink 任務在上遊先完成維表關聯的工作，得到中間表，然後再將中間表寫入物化檢視進行查詢加速。而基於高效能的全域字典功能，我們能夠在數據寫入時，透過查詢字典表，直接在 OLAP 資料庫的內部完成維度表的關聯，從而不再需要依賴於繁重的 Flink 任務，同時，字典表也可以用於最佳化 BI 查詢的 JOIN 效能。
03
未來當前，我們已經支持多流同步物化檢視，同時社群全域字典功能也基本可用。但是，目前的多流同步物化檢視仍然存在較多限制：例如，不支持 JOIN，不支持通用聚合函式等。未來，我們希望新的 Stream MV 能夠消除上述限制，進一步滿足更多的業務場景；更進一步，Stream MV 結合外表物化檢視，達到湖上即時增量物化檢視，成為更好的湖上建倉方案。
總結與展望
當前，基於 StarRocks 的湖倉一體方案已經在微信的多個業務場景中上線使用，包括視訊號直播、微信鍵盤、微信讀書和公眾號等，集群規模達到數百台機器，數據接入量近千億。
在收益方面，我們以一個具體的業務來舉例，在直播業務場景中，透過湖上建倉的方案改造，使得數據開發同學需要運維的任務數減半，同時儲存成本降低 65% 以上，離線任務產出時間縮短兩小時。
未來，我們希望不斷探索和完善現有的湖倉一體架構，最終能夠達到理想中的湖倉一體：
面向 SQL，使用者不再感知底層架構；
接入/查詢體驗統一，儲存統一；
秒級/分鐘級延遲架構體驗統一，亞秒/分鐘級分析統一；
SQL 互動標準統一。
致謝
感謝 「 騰訊大數據團隊 」 提供穩定內部集群和各類技術支持，幫助業務落地；
感謝" StarRocks 社群"在功能開發，問題定位解決上的諸多幫忙，祝願社群發展的越來越好！
關於 StarRocks
Linux 基金會計畫 StarRocks 是數據分析新範式的開創者、新標準的領導者。面世三年來，StarRocks 一直專註打造世界頂級的新一代極速全場景 MPP 資料庫， 幫助企業構建極速統一的湖倉分析新範式，是實作數位化轉型和降本增效的關鍵基礎設施。
StarRocks 持續突破既有框架，以技術創新全面驅動使用者業務發展。當前全球超過 300 家市值 70 億元以上的頭部企業都在基於 StarRocks 構建新一代數據分析能力，包括騰訊、攜程、平安銀行、中原銀行、中信建投、招商證券、大潤發、百草味、順豐、京東物流、TCL、OPPO 等，並與全球雲端運算領導者亞馬遜雲、阿裏雲、騰訊雲等達成戰略合作夥伴。
擁抱開源，StarRocks 全球開源社群飛速成長。目前，已有超過 300 位貢獻者，社群使用者近萬人，吸引幾十家國內外行業頭部企業參與共建。計畫在 GitHub 星數已超 6800 個，成為年度開源熱力值增速第一的計畫，市場滲透率躋身中國前十名。
金融： ｜
互聯網： ｜ ｜ ｜
遊戲：
新經濟： ｜
StarRocks 技術內幕： ｜ ｜ ｜ ｜ ｜ ｜
