所謂的「打寬」，就是將明細表和可能來自多個資料來源的多張維表進行關聯，匯總成一個大寬表，便於後續處理分析的過程。
時至今日，打寬 + 實分時析仍然是流處理領域內最常見的場景。然而，真正面對這個問題時，許多人還是難以理解為何如此普遍而具體的場景卻需要考慮種種疑難雜癥。
在深入這些問題之前，我們可以先回顧一下業內已經解決了什麽：
1 過去基於 StarRocks 的打寬方案
業務資料庫的 CDC 抽取： 如今主流的 MySQL、Postgres、MongoDB 等資料庫的同步均已被 RisingWave、FlinkCDC 等開源工具原生支持。
即時寫入到數倉中： 流行的資料倉儲系統，如 StarRocks，其產品已支持了相對高效的寫入能力：
主鍵表： 這一表型別在 StarRocks 儲存內部維護了主鍵索引，可以高效地處理更新和刪除。RisingWave 寫入 StarRocks 預設就需要這一表型別。
部份列更新： 非常適合大寬表下，每次更新只有少部份列（一般低於30%）被變更的場景。
StreamLoad： StarRocks 支持透過 HTTP 進行數據批次寫入，實測下來寫入吞吐在絕大多數場景都能滿足需求。
小狀態的數據清洗和打寬： 許多開源或商業的流處理軟體都提供了標準 SQL支持，這使得數據清洗時不需要擔心表達能力的缺失。
2 大狀態的無奈
但需要註意的是，不論是 FlinkSQL 還是 Materialize，在超大狀態維護上都或多或少地會遇到一些挑戰，使用者需要在復雜的記憶體磁盤調優與犧牲狀態大小這兩害之間選其輕。例如 FlinkSQL 就提供了許多減少狀態的技巧，包括但不限於時間視窗+Watermark，Lookup Join，狀態清理（TTL）等功能，而同時使用者也不得不去學習大狀態下 Checkpoint 的調優方式。
但如果手裏鈔票充足的話，還有一種選擇，就是采購單台數十萬成本的大規格伺服器。
回到我們最初的討論，即使基本的 ETL（即 CDC → 數據清洗 → 數倉即時寫入）已被解決，事實上行業內仍然有許多尚未解決的痛點：
復雜流處理邏輯的大狀態維護
如何長時間地（例如數月）保留中間狀態
如何基於大寬表做即時物化檢視
3 即時打寬的最後一公裏
相信有深入過以上問題的朋友都能意識到，這其中所缺乏的恰恰是一個面向流計算的大狀態儲存：
它的儲存成本必須低，不常存取的數據應當被放在相對廉價的儲存上，例如 HDFS 或 S3。
它應該能夠高效地處理流 Join 的頻繁更新。
它應該可查詢，從而能在一些查詢固定的監控場景裏，直接基於流計算結果構建即時指標檢視。
它應該能夠迅速地從故障中恢復。
RisingWave 旨在提供的就是這樣的能力。
在即時打寬這一場景裏，RisingWave 能夠在較低的機器成本下，利用存算分離的能力，無需調優技巧，來支撐一個過去難以維護的 Join 鏈路。
上圖參照自 RisingWave 使用者案例 「 」，裏面提到即使是 13 個表的 Join（如今已有數十個表的 Join），RisingWave 依然能夠遊刃有余地處理。
4 完善的實分時析技術棧
隨著 RisingWave 的打寬能力在許多使用者場景裏逐步被驗證，我們也更多地將精力投入到對這一場景的全方面打磨。
在剛剛釋出的 1.7 版本，我們最佳化了對 StarRocks 的寫入，使得整個過程更加絲滑。
除了打寬，使用者還可以將 RisingWave 視作一個數倉的即時緩存。在即時性要求低的場景，使用者可以基於 StarRocks 完成離線分析，而當即時性無法滿足的時候，使用者就可以基於 RisingWave 的大寬表開發物化檢視。在這套技術棧裏，使用者依照具體情況選擇合適的技術即可。
除了透過 StarRocks Sink 寫入外，RisingWave 也可以被用作 StarRocks 的外表，實作離線和線上的查詢入口統一。
CREATEEXTERNALRESOURCE rw_jdbc
PROPERTIES (
"type"="jdbc",
"user"="postgres",
"password"="",
"jdbc_uri"="jdbc:postgresql://risingwave-standalone:4566/dev",
"driver_url"="https://repo1.maven.org/maven2/org/postgresql/postgresql/42.3.3/postgresql-42.3.3.jar",
"driver_ class"="org.postgresql.Driver"
);
CREATEEXTERNALTABLEusers (
idBIGINT,
description VARCHAR(255),
nameTEXT,
created_at DATETIME
) ENGINE=jdbc
properties (
"resource"="rw_jdbc",
"table"="users"
);
5 未來展望
即使大狀態的問題解決了，我們仍然需要面對 Schema change 的挑戰。上遊 MySQL 表加列了，下遊的 StarRocks 是否能同步加列？RisingWave 自身的表是否也能同步加列？
我們看到有些行業實踐能夠自動捕獲上遊的 DDL，同時對 StarRocks 也進行加列。未來我們或許也會提供類似的能力。目前而言，RisingWave 提供了 手動的加減列功能 [1] ，我們仍然在圍繞這一能力不斷加強。
參考資料
[1]
手動的加減列功能:
https://docs.risingwave.com/docs/current/alter-streaming/
關於 RisingWave
RisingWave 是一款基於 Apache 2.0 協定開源的分布式流資料庫，致力於為使用者提供極致簡單、高效的流數據處理與管理能力。RisingWave 采用存算分離架構，實作了高效的復雜查詢、瞬時動態擴縮容以及快速故障恢復，並助力使用者極大地簡化流計算架構，輕松搭建穩定且高效的流計算套用。
RisingWave 始終聆聽來自社群的聲音，並積極回應使用者的反饋。目前，RisingWave 已匯聚了近 150 名開源貢獻者和近 3000 名社群成員。全球範圍內，已有上百個 RisingWave 集群在生產環境中部署。
往期推薦
技術內幕
使用者案例
