Hologres推出了聲明式資料處理架構Dynamic Table，該架構可以自動處理並儲存一個或者多個基表（Base Table）對象的資料彙總結果，內建不同的資料重新整理策略，業務可以根據需求設定不同的資料重新整理策略，實現資料從基表對象到Dynamic Table的自動流轉，滿足業務統一開發、資料自動流轉、處理時效性等訴求。
業務背景
在即時數倉情境中，通常會涉及到複雜的業務處理，例如多表關聯查詢，大表彙總查詢等，其資料一般都是巨量資料量（TB級甚至PB級），同時業務又有不同時效性的訴求，在資料加工上通常會有以下幾個痛點：
Lambda架構過於冗餘：為了滿足業務資源成本、開發效率、業務時效性等需求，業界早期通常使用Lambda架構，但是該架構上產品組合眾多，面向不同的業務情境，導致架構冗餘、儲存冗餘，開發和營運不便捷、資料口徑不一致等一系列問題。
離線ETL重複性調度，時效性差：使用離線計算引擎（例如Hive）ETL是常見的資料加工手段，這種方案通常適用於高吞吐的巨量資料量加工，計算資料量大，缺乏Realtime Compute的能力，如果要提高加工效率，通常是將資料通過周期性調度的方式，重複計算，勢必會造成大量的資源浪費，同時時效性也不能完全滿足業務需求。
Realtime Compute成本過高：為了提升資料處理的時效性，使用Realtime Compute引擎即時加工成為新的技術演化趨勢，但數倉情境中，並不是所有的業務都需要Realtime Compute，更多的是准即時分鐘級加工情境（例如BI報表查詢），這種方案會導致資源成本過高。
基於上述資料加工的痛點，Hologres重磅推出DynamicTable，支援全量計算、增量計算2種計算模式，既能支援離線巨量資料量的全量加工，又能使用增量計算提升資料計算時效性，且成本相比Realtime Compute更低。Dynamic Table可以做到資料自動計算，結果更新，實現更高效、更低成本的資料自動流動與數倉分層，再結合Hologres本身特性，能夠統一儲存層，統一計算層、統一資料加工層、統一資料服務層，滿足開發效率、時效性等需求。
Dynamic Table的優勢
簡化數倉架構
Dynamic Table支援全量計算和增量計算2種重新整理模式，可實現離線資料加工（全量計算）和准即時資料加工（增量計算），滿足業務不同時效性的查詢訴求，再基於Hologres的統一儲存（儲存即時資料、離線資料），直接賦能業務OLAP查詢、線上服務、AI與大模型等多個應用情境的查詢訴求，一套引擎，一份計算，一份SQL多種計算模式，可以完美替換Lambda架構，簡化數倉架構，節約開發、營運等成本。
自動數倉分層
Dynamic Tanle可以根據基表資料的新鮮度，自動觸發重新整理（refresh），實現資料從ODS>DWD>DWS>ADS的自動資料流轉，提升數倉分層開發體驗。
提升資料處理（ETL）效率
Dynamic Table的增量重新整理計算，每一次重新整理都只會處理基表的新增資料，可以有效減少每次ETL計算的資料量，顯著提升資料處理效率，同時資源也無需像Realtime Compute一樣常駐，根據資料新鮮度自動觸發重新整理，可以有效降低成本。
降低開發營運成本
Dynamic Table的重新整理模式都使用統一的SQL介面，自動管理重新整理任務、自動管理資料之間的層級和依賴關係，簡化繁瑣的開發營運，提升開發效率。
基本概念
基表（Base Table）
Dynamic Table中資料來源的基表，可以是一張表（內部表或外部表格），也可以是多個表關聯。不同的重新整理模式，支援的基表類型不同。詳情請參見Dynamic Table支援範圍和限制。
Query
建立Dynamic Table時指定的Query，是指對基表資料的處理Query，相當於ETL過程。不同的重新整理模式支援的Query類型不同，詳情請參見Dynamic Table支援範圍和限制。
重新整理（Refresh）
當基表中的資料發生變化時，需要通過重新整理（Refresh）Dynamic Table以更新資料的變動。Dynamic Table會根據設定的重新整理開始時間和重新整理間隔，自動在後台運行重新整理任務，對重新整理任務的觀測和營運詳情請參見營運Dynamic Table重新整理任務。
技術原理
基表中的資料根據Dynamic Table中Query定義的資料處理流程，通過重新整理的方式寫入Dynamic Table。以下將從重新整理模式、計算資源、資料存放區及表索引四個方面介紹Dynamic Table的部分技術原理。
重新整理模式
當前Dynamic Table支援兩種重新整理模式，即全量重新整理（Full）和增量重新整理（Incremental），根據設定的重新整理模式不同，Dynamic Table的技術原理也有所差異。
全量重新整理（Full）
全量重新整理是指每次執行重新整理時，都以全量的方式進行資料處理，並將基表的彙總結果物化寫入Dynamic Table，其技術原理類似於INSERT OVERWRITE的相關原理。
增量重新整理（Incremental）
增量重新整理模式下，每次重新整理時只會讀取基表中新增的資料，根據中間彙總狀態和增量資料計算最終結果並更新到Dynamic Table中。相比全量重新整理，增量重新整理每次處理的資料量更少，效率更高，從而可以非常有效地提升重新整理任務的時效性，同時降低計算資源的使用。
技術原理
建立了增量重新整理的Dynamic Table，並通過Stream或Binlog的方式讀取基表的增量資料後，系統會在底層建立一個列存的狀態表（State表），用於儲存Query的中間彙總狀態，引擎在編碼、儲存等方面對中間彙總狀態進行了最佳化，可以加快對中間彙總狀態的讀取和更新。增量資料會以微批次方式做記憶體態的彙總，再與狀態表中的資料進行合并，然後以BulkLoad的方式將最新彙總結果高效地寫入Dynamic Table。微批次的增量處理方式減少了單次重新整理的資料處理量，顯著提升了計算的時效性。
Stream和Binlog方式讀取基表增量資料的對比
讀取基表增量資料的方式
原理
讀取效能
特點
注意事項
Stream（推薦）
從檔案層級識別資料的變化記錄，計算基表的增量資料。
比Binlog方式高10倍以上。
使用更簡單。
不單獨記錄增量變化，因此無額外的儲存開銷，也無需管理Binlog的儲存生命週期。
不支援以行存表作為基表。
Binlog
Binlog會記錄基表的DML變化，並在底層儲存成二進位日誌，增量消費基表時通過讀取Binlog日誌識別增量資料的變化。
較低。
因記錄DML的變化，產生額外的儲存開銷。
需要管理Binlog的儲存生命週期（TTL），否則隨著資料的變更或增長，儲存會持續增加。
無。
注意事項
增量重新整理模式支援的基表存在一定的限制，詳情請參見Dynamic Table支援範圍和限制。
增量重新整理內建的狀態表會佔用一定的儲存，系統會設定TTL定期清理資料，您可以使用函數查看狀態表的儲存大小，詳情請參見狀態表（State）管理。
計算資源
執行重新整理任務的計算資源可以是本執行個體的資源或者Serverless資源：
Serverless資源（預設）：從V3.1版本開始，建立表預設使用Serverless方式執行重新整理，如果Query比較複雜，處理的資料量較多，通過Serverless方式可以有效提升重新整理任務的穩定性，避免本執行個體內多任務間的資源爭搶，同時也可以對單個重新整理任務修改計算資源，以便更合理地使用Serverless資源。
本執行個體資源：重新整理任務將會使用本執行個體的資源運行，與執行個體中的其他任務共用資源，高峰期可能會出現資源爭搶現象。
資料存放區
Dynamic Table在資料存放區方面與普通表一致，預設使用熱儲存模式。為了減少儲存成本，也可以將查詢頻率較低的資料設定為冷儲存，有效降低成本。
表索引
業務在查詢時，可以直接查詢Dynamic Table，相當於直接查詢彙總結果，這樣可以顯著提升查詢效能。同時，Dynamic Table也如同普通表，支援設定表索引，如行存/列存、Distribution Key、Clustering Key等，通常情況下，引擎會根據Dynamic Table的Query推匯出合適的索引，如業務有進一步的調優需求，可以重新為其設定合適的索引，以進一步提升查詢效能。
與物化視圖對比
Dynamic Table VS Hologres即時物化視圖
Hologres在V1.3版本推出了SQL管理物化視圖，但是支援的能力相對較弱，與Dynamic Table的差異如下：
功能分類 | Hologres Dynamic Table | Hologres即時物化視圖 |
基表類型 |
| 單內表 |
基表操作 |
| 僅支援append寫入 |
重新整理原理 | 非同步重新整理（全量重新整理、增量重新整理） | 同步重新整理 |
重新整理時效性 |
| 即時 |
Query類型 |
說明 不同的重新整理模式，支援的Query類型不同，詳情請參見Dynamic Table支援範圍和限制。 | 有限運算元支援（AGG、RB函數等） |
查詢模式 | 直接查Dynamic Table |
|
Dynamic Table VS 非同步物化視圖
當前市面上，與Dynamic Table功能類似的有OLAP產品的非同步物化視圖、Snowflake的Dynamic Table等，其差別如下：
功能分類 | Hologres Dynamic Table | OLAP產品非同步物化視圖 | Snowflake Dynamic Table |
基表類型 |
說明 不同的重新整理模式，支援的Query類型不同，詳情請參見Dynamic Table支援範圍和限制。 |
|
|
重新整理模式 |
|
|
|
重新整理時效性 |
| 小時級 |
|
Query類型 |
說明 不同的重新整理模式，支援的Query類型不同，詳情請參見Dynamic Table支援範圍和限制。 |
|
|
查詢模式 | 直接查Dynamic Table |
| 直接查Dynamic Table |
觀測/營運 |
| 豐富的監控指標 | 可視化介面 |
典型應用情境
Dynamic Table可以自動完成資料加工和儲存，通過Dynamic Table，可以加速資料查詢，提升業務時效性，推薦的使用情境如下：
Lambda架構升級
為了滿足業務資料的不同時效性處理需求，Lambda架構會使用不同的產品組件來完成。這就會導致架構冗餘、資料口徑不一致、系統維護難，儲存冗餘等一系列問題。通過Hologres Dynamic Table，可以很好地支撐批量資料加工，近即時加工等情境，結合Holo的統一儲存，統一資料服務（支援OLAP查詢、KV線上點查）等能力，可以在一個產品支援多種應用情境，簡化架構，降低開發難度，學習成本，儲存成本等。
近即時資料加工
如果基表中有大量資料，需要進行複雜的ETL處理來滿足業務的時效性需求，常見的做法就是數倉分層。對於即時數倉，業界在數倉分層上的方案較多，例如使用物化視圖、周期性調度等，但這些方案雖然能解決一部分問題，但是也都存在資料時效性、開發不便捷等問題。而Hologres Dynamic Table本身就具備資料自動處理的能力，因此可以通過Dynamic Table很方便的實現數倉分層。
推薦做法如下：
可以在Hologres中通過Dynamic Table構建數倉分層DWD>DWS>ADS層：
每一層之間的資料同步使用增量重新整理模式，這樣可以保證每一層處理的資料少，減少不必要的重複計算，提升同步速度。也可以根據業務情況，將重新整理任務提交到Serverless Computing執行，進一步提升重新整理的時效性和穩定性。
如果要對每一層的資料進行回刷，可以使用全量重新整理執行一次重新整理，以此來保證每一層資料口徑的一致性。同樣也可以根據業務情況，將重新整理任務提交到Serverless Computing執行，進一步提升重新整理的時效性和穩定性。
每一層都在Hologres中構建，數倉分層明確，每一層都可以根據業務情況提供查詢，保證資料的可見度、複用性。
通過Hologres Dynamic Table方案就能完成資料加工+應用的情境，顯著提升數倉開發、營運效率。
湖倉加速
Dynamic Table的基表資料可以來源於Hologres表，也可以來源於資料倉儲，例如MaxCompute、資料湖OSS、Paimon等，通過對基表資料的全量/增量重新整理，滿足不同時效性的資料查詢探索需求。推薦的使用情境包括：
定期報表查詢
對於周期性觀測的相關情境，例如周期性報表等，如果資料量較少或者Query不複雜，可以使用全量重新整理或者增量重新整理的模式，周期性地將湖倉資料的彙總分析結果重新整理至Dynamic Table，應用側直接查詢Dynamic Table擷取分析結果，加速報表查詢。
即時大屏/報表
對於即時大屏和即時報表等情境，資料的時效性要求更高，推薦使用增量重新整理的模式，將湖Paimon或者即時資料的彙總分析結果重新整理至Dynamic Table，以此來加速對即時資料的處理，應用側直接查詢Dynamic Table擷取資料分析結果，達到近即時分析的目的。
替換離線周期性重複調度
典型的離線加工情境中，資料量大，計算周期長，為了提升計算時效性，通常的做法是周期性調度方案：
從DWD-DWS-ADS，T+H周期性（例如30min調度一次）處理最近幾天的資料，為了保證資料的準確性，同樣也會單獨起一個離線鏈路，T+1每天處理最近幾天的資料，相當於是對資料回刷，導致有一大部分資料是重複計算的，資源浪費，資料也有冗餘，同時，系統也不能保證每次調度都能完成計算，導致後續的調度任務阻塞，業務延遲計算時效性得不到保障。
通過Hologres，從DWD-DWS-ADS每一層都採用T+H的增量重新整理，原作業合并到一個增量計算的作業，不用關心具體的資料查詢範圍，只負責重新整理，SQL更簡化，DynamicTable自動調度，無需維護外部調度作業。每次只計算增量的資料，避免重複計算，計算提速，無任務的堆積，計算資源也大幅降低。
