實時數(shù)倉建設(shè)背景

實時數(shù)倉需求

隨著互聯(lián)網(wǎng)行業(yè)的飛速發(fā)展，企業(yè)業(yè)務(wù)種類變得越來越多，數(shù)據(jù)量也變得越來越大。以 Apache Hadoop 生態(tài)為核心的數(shù)據(jù)看板業(yè)務(wù)一般只能實現(xiàn)離線的業(yè)務(wù)。在部分領(lǐng)域，數(shù)據(jù)實時處理的能力已經(jīng)成為限制企業(yè)數(shù)據(jù)變現(xiàn)的重要瓶頸之一。搭建數(shù)據(jù)看板快節(jié)奏地進行數(shù)據(jù)分析，已經(jīng)成為了一種必然的選擇。

實時數(shù)倉發(fā)展

實時數(shù)倉有三個著名的分水嶺：第一個分水嶺是從無到有，Apache Storm 的出現(xiàn)打破了 MapReduce 的單一計算方式，讓業(yè)務(wù)能夠處理 T+0 的數(shù)據(jù)；第二個分水嶺是從有到全，Lambda 與 Kappa 架構(gòu)的出現(xiàn)，使離線數(shù)倉向?qū)崟r數(shù)倉邁進了一步，而 Lambda 架構(gòu)到 Kappa 架構(gòu)的演進，實現(xiàn)了離線數(shù)倉模型和實時數(shù)倉模型的緊密結(jié)合；第三個分水嶺是從繁到簡，F(xiàn)link 技術(shù)棧的落地使實時數(shù)倉架構(gòu)變得精簡，并且是現(xiàn)在公認的流批一體最佳解決方案。

以 Flink 作為實時計算引擎實現(xiàn)的實時數(shù)倉，將一部分復(fù)雜的計算轉(zhuǎn)嫁給 OLAP 分析引擎上，使得應(yīng)用層的分析需求更加靈活。但仍然無法改變數(shù)據(jù)倉庫變更數(shù)據(jù)的排斥。下一代的實時數(shù)倉平臺，不僅要提供更為優(yōu)秀的性能，同時也需要更為完善的功能以匹配不同的業(yè)務(wù)。

作為一款全平臺極速 MPP 架構(gòu)，StarRocks 提供了多種性能優(yōu)化手段與靈活的建模方式，在預(yù)聚合、寬表和星型/雪花等多種模型上，都可以獲得極致的性能體驗。通過 StarRocks 結(jié)合 Flink 構(gòu)建開源實時數(shù)倉的方案，可以同時提供秒級數(shù)據(jù)同步和極速分析查詢的能力。同時，通過 StarRocks 主鍵模型，也可以更好地支持實時和頻繁更新等場景。

基于 Flink 的開源實時數(shù)倉痛點

原有基于 Flink 構(gòu)建實施數(shù)倉的方案中，由于數(shù)據(jù)源的多樣性，需要使用不同的采集工具，如 Flume、Canal、Logstash。對于不同的業(yè)務(wù)，我們通常會采用不同的分析引擎。比如，對于固定報表業(yè)務(wù)，根據(jù)已知的查詢語句可以預(yù)先將事實表與維度表打平成寬表，充分利用 ClickHouse 強大的單表查詢能力；對于高并發(fā)的查詢請求，可以使用 Apache Druid 承受大量用戶高峰時期集中使用帶來的并發(fā)壓力。通過技術(shù)棧堆疊的方式確實可以滿足業(yè)務(wù)要求，但也會讓分析層變得臃腫，增加開發(fā)與運維的成本。

一般來說，StarRocks X Flink 構(gòu)建開源實時數(shù)倉生態(tài)架構(gòu)分為五層：

• 第一層是數(shù)據(jù)源。數(shù)據(jù)源可以是多種多樣的，比如說 MySQL Binlog、爬蟲數(shù)據(jù)或者是平面文件；
• 第二層是數(shù)據(jù)采集層。用戶使用多種不同的 CDC 工具，比如 Canal、Debezium 拉取上游的增量數(shù)據(jù)，通常會將數(shù)據(jù)寫入到 Kafka 中，而后在通過 Flink 消費 Kafka 中的數(shù)據(jù)；
• 第三層是實時計算層?？梢酝ㄟ^ Flink 的實時計算能力完成輕量級的 ETL 工作，如拼寬表或數(shù)據(jù)清洗等；
• 第四層是數(shù)據(jù)存儲層。Flink 相比其他的實時技術(shù)棧更加依賴 OLAP 引擎；
• 最后一層是后端應(yīng)用層。可以是實時監(jiān)控系統(tǒng)，實時報表系統(tǒng)，實時推薦系統(tǒng)以及實時數(shù)據(jù)接口服務(wù)。

我們常說，天下武功，唯快不破。以 Flink 為計算引擎構(gòu)建的實時數(shù)倉系統(tǒng)，最關(guān)心的就是數(shù)據(jù)攝入速度足夠快，延遲足夠低。 在這樣一套架構(gòu)中，數(shù)據(jù)從數(shù)據(jù)源到 OLAP 分析系統(tǒng)途徑采集工具層，消息隊列層，實時計算層。冗長的鏈路給開發(fā)和運維帶來了極大的風(fēng)險，任何一個模塊的阻塞都會對實時性產(chǎn)生影響。同時，在數(shù)據(jù)存儲層上，我們也會選擇不同的存儲引擎適配不同的業(yè)務(wù)。對于上面的數(shù)據(jù)鏈路，我們也面臨著諸多的挑戰(zhàn)，需要從時效性、功能性及可維護性上做更多的探索，由此可以總結(jié)歸納出多個方面尚待優(yōu)化：

• CDC 組件不統(tǒng)一，鏈路過長，任何組件出現(xiàn)瓶頸都會對時效性產(chǎn)生影響，組件過多，需要多部門協(xié)作維護，學(xué)習(xí)成本與維護成本成倍增長；
• 部分同步組件，如 Debezium 在保證數(shù)據(jù)一致性時，需要對讀取的表加鎖，可能會影響業(yè)務(wù)更新；
• 分析層使用多種數(shù)據(jù)存儲產(chǎn)品適應(yīng)不同的業(yè)務(wù)類型，難以有一種產(chǎn)品能夠適應(yīng)大部分的業(yè)務(wù)；
• 去重操作對應(yīng)邏輯復(fù)雜，需要在 flink 里面增加 MapStat 邏輯。

Flink CDC，打通端到端鏈路

Flink CDC 是由 Flink 社區(qū)開發(fā)的集數(shù)據(jù)采集、數(shù)據(jù)轉(zhuǎn)換、數(shù)據(jù)裝載一體的組件，可以直接從 MySQL、PostgreSQL、Oracle 等數(shù)據(jù)源直接讀取全量或增量數(shù)據(jù)并寫入下游的 OLAP 數(shù)據(jù)存儲系統(tǒng)。使用 Flink CDC 后，可以簡單高效的抓取上游的數(shù)據(jù)變更，同步到下游的 OLAP 數(shù)據(jù)倉庫中。

構(gòu)建一體化數(shù)據(jù)傳輸鏈路

在傳統(tǒng)的實時數(shù)倉建設(shè)中，數(shù)據(jù)采集工具是不可或缺的。由于上游的數(shù)據(jù)源不一致，通常來說我們可能會在數(shù)據(jù)采集層接入不同的同步與采集工具，比如采集 Oracle 中的數(shù)據(jù)時，我們通常選擇 GoldenGate，而對于 MySQL，我們可能會選擇 Canal 或 Debezium。有些采集工具支持全量數(shù)據(jù)同步，有些支持增量數(shù)據(jù)同步。數(shù)據(jù)經(jīng)過采集層后，會傳輸?shù)较㈥犃兄腥?Kafka，然后通過 Flink 消費 Kafka 中的增量數(shù)據(jù)再寫入下游的 OLAP 數(shù)據(jù)倉庫或者數(shù)據(jù)湖中。

在業(yè)務(wù)開發(fā)中，上游的數(shù)據(jù)源、消息中間件、Flink 以及下游的分析性數(shù)據(jù)倉庫通常在不同的部門進行維護。遇到業(yè)務(wù)變更或者故障調(diào)試時，可能需要多個部門協(xié)作處理，增加了業(yè)務(wù)開發(fā)與測試的難度。通過使用 Flink CDC 替換上圖中的數(shù)據(jù)采集組件與消息隊列，將虛線框中的采集組件與消息隊列合并到計算層 Flink 中，從而簡化分析鏈路，降低維護成本。同時更少的組件也意味著更少的故障與傳輸瓶頸，數(shù)據(jù)實效性會進一步的提高。

在使用 Flink CDC 之后，數(shù)據(jù)鏈路中的組件變得更少，架構(gòu)變得清晰簡單，維護變得更方便。如在上面的例子中，我們使用 Flink CDC 拉取 MySQL 中的增量數(shù)據(jù)，通過 Flink SQL 創(chuàng)建事實與維度的 MySQL CDC 表，并在 Flink 中進行打?qū)挷僮?，將結(jié)果寫入到下游的 StarRocks 中。通過一個 Flink CDC 作業(yè)就可以完成抓取，轉(zhuǎn)換，裝載的全過程。

全量 + 增量數(shù)據(jù)同步

在傳統(tǒng)的數(shù)據(jù)同步框架中，我們通常會分為兩個階段：

• 全量數(shù)據(jù)同步階段：通過全量同步工具，如 DataX 或 sqoop 等，進行快照級別的表同步。
• 增量數(shù)據(jù)同步階段：通過增量同步工具，如 Canal 或 GoldenGate 等，實時拉取快照之后的增量數(shù)據(jù)進行同步。

在全量數(shù)據(jù)同步時，為了加快導(dǎo)入的速度，我們可以選擇多線程的導(dǎo)入模式。在多線程模型下進行全量數(shù)據(jù)同步時，在對數(shù)據(jù)進行切分后，通過啟動多個并發(fā)任務(wù)完成數(shù)據(jù)的同步。由于多個并發(fā)業(yè)務(wù)之間可能不屬于同一個讀事務(wù)，并且存在一定的時間間隔，所以不能嚴格的保證數(shù)據(jù)的一致性。為了保證數(shù)據(jù)的一致性，從工程學(xué)與技術(shù)實現(xiàn)的角度做平衡，我們有兩種方案：

• 停止數(shù)據(jù)的寫入操作，通過鎖表等方式保證快照數(shù)據(jù)的靜態(tài)性。但這將影響在線的業(yè)務(wù)。
• 采用單線程同步的方式，不再對數(shù)據(jù)進行切片。但導(dǎo)入性能無法保證。

通過 Flink CDC，可以統(tǒng)一全量 + 增量的數(shù)據(jù)同步工作。Flink CDC 1.x 版本中，采用 Debezium 作為底層的采集工具，在全量的數(shù)據(jù)讀取過程中，為了保證數(shù)據(jù)的一致性，也需要對庫或表進行加鎖操作。為了解決這個問題，F(xiàn)link 2.0 中引入了 Chunk 切分算法保證數(shù)據(jù)的無鎖讀取。Chunk 的切分算法類似分庫分表原理，通過表的主鍵對數(shù)據(jù)進行分片操作。

在經(jīng)過 Chunk 數(shù)據(jù)分片后，每個 Chunk 只負責(zé)自己主鍵范圍內(nèi)的數(shù)據(jù)，只要保證每個 Chunk 的讀取一致性，這也是無鎖算法的基本原理。

StarRocks，實時數(shù)據(jù)更新新方案

StarRocks 是一款極速全場景 MPP 企業(yè)級數(shù)據(jù)倉庫產(chǎn)品，具備水平在線擴縮容能力，金融級高可用，兼容 MySQL 協(xié)議和 MySQL 生態(tài)，提供全面向量化引擎與多種數(shù)據(jù)源聯(lián)邦查詢等重要特性。作為一款 MPP 架構(gòu)的分析性數(shù)據(jù)倉庫，StarRocks 能夠支撐 PB 級別的數(shù)據(jù)量，擁有靈活的建模方式，可以通過物化視圖、位圖索引、稀疏索引等優(yōu)化手段構(gòu)建極速統(tǒng)一的分析層數(shù)據(jù)存儲系統(tǒng)。

StarRocks 在 1.19 版本推出了主鍵模型（Primary Key model）。相較更新模型，主鍵模型可以更好地支持實時和頻繁更新等場景。主鍵模型要求表有唯一的主鍵（傳統(tǒng)數(shù)據(jù)倉庫中的 primary key），支持對表中的行按主鍵進行更新和刪除操作。

主鍵模型對實時數(shù)據(jù)變更的優(yōu)化

在 OLAP 數(shù)據(jù)倉庫中，可變數(shù)據(jù)通常是不受歡迎的。在傳統(tǒng)數(shù)倉中，一般我們會使用批量更新的方式處理大量數(shù)據(jù)變更的場景。對于數(shù)據(jù)的變更我們有兩種方法處理：

• 在新的分區(qū)中插入修改后的數(shù)據(jù)，通過分區(qū)交換完成數(shù)據(jù)變更。
• 部分 OLAP 數(shù)據(jù)倉庫產(chǎn)品提供了基于 Merge on Read 模型的更新功能，完成數(shù)據(jù)變更。

分區(qū)交換數(shù)據(jù)更新模式

對于大部分的 OLAP 數(shù)據(jù)倉庫產(chǎn)品，我們可以通過操作分區(qū)的方式，將原有的分區(qū)刪除掉，然后用新的分區(qū)代替，從而實現(xiàn)對大量數(shù)據(jù)的變更操作。一般來說需要經(jīng)歷三個步驟：

通過交換分區(qū)來實現(xiàn)大規(guī)模數(shù)據(jù)變更是一個相對較重的操作，適用于低頻的批量數(shù)據(jù)更新。由于涉及到了表定義的變更，一般來說開發(fā)人員無法通過該方案獨立完成數(shù)據(jù)變更。

Merge on Read 數(shù)據(jù)更新模式

部分的 OLAP 數(shù)據(jù)倉庫提供了基于 Merge on Read 的數(shù)據(jù)變更模型，如 ClickHouse 提供了 MergeTree 引擎， 可以完成異步更新，但無法做到數(shù)據(jù)實時同步。在指定 FINAL 關(guān)鍵字后，ClickHouse 會在返回結(jié)果之前完成合并，從而實現(xiàn)準實時的數(shù)據(jù)更新同步操作。但由于 FINAL 操作高昂的代價，不足以支撐實時數(shù)倉帶來的頻繁維度更新需求。同時，即便是在低頻的更新場景中，也無法將 ClickHouse Merge Tree 的方案復(fù)制到其他存儲系統(tǒng)中。

StarRocks 提供了與 ClickHouse Merge Tree 類似的更新模型（Unique Key model），通過 Merge on Read 的模式完成數(shù)據(jù)的更新操作。在更新模型中，StarRocks 內(nèi)部會給每一個批次導(dǎo)入的數(shù)據(jù)分配一個版本號，同一主鍵可能存在多個版本，在查詢時進行版本合并，返回最新版本的記錄。

Merge on Read 模式在寫入時簡單高效，但讀取時會消耗大量的資源在版本合并上，同時由于 merge 算子的存在，使得謂詞無法下推、索引無法使用，嚴重的影響了查詢的性能。StarRocks 提供了基于 Delete and Insert 模式的主鍵模型，避免了因為版本合并導(dǎo)致的算子無法下推的問題。主鍵模型適合需要對數(shù)據(jù)進行實時更新的場景，可以更好的解決行級別的更新操作，支撐百萬級別的 TPS，特別適合 MySQL 或其他業(yè)務(wù)庫同步到 StarRocks 的場景。

在 TPCH 標準測試集中，我們選取了部分的查詢進行對比，基于 Delete and Insert 模式的主鍵模型相較于基于 Merge on Read 的 Unique Key 模型，性能有明顯的提高：

主鍵模型對去重操作的支持

消除重復(fù)數(shù)據(jù)是實際業(yè)務(wù)中經(jīng)常遇到的難題。在數(shù)據(jù)倉庫中，重復(fù)數(shù)據(jù)的刪除有助于減少存儲所消耗的容量。在一些特定的場景中，重復(fù)數(shù)據(jù)也是不可接受的，比如在客群圈選與精準營銷業(yè)務(wù)場景中，為了避免重復(fù)推送營銷信息，一般會根據(jù)用戶 ID 進行去重操作。在傳統(tǒng)的離線計算中，可以通過 distinct 函數(shù)完成去重操作。在實時計算業(yè)務(wù)中，去重是一個增量和長期的過程，我們可以在 Flink 中通過添加 MapState 邏輯進行去重操作。但通過 MapStat，多數(shù)情況下只能保證一定的時間窗口內(nèi)數(shù)據(jù)去重，很難實現(xiàn)增量數(shù)據(jù)與 OLAP 庫中的存量數(shù)據(jù)進行去重。隨著時間窗口的增加，F(xiàn)link 中的去重操作會占用大量的內(nèi)存資源，同時也會使計算層變得臃腫復(fù)雜。

主鍵模型要求表擁有唯一的主鍵，支持表中的行按照主鍵進行更新和刪除操作。主鍵的唯一性與去重操作的需求高度匹配，在數(shù)據(jù)導(dǎo)入時，主鍵模型就已經(jīng)完成了去重操作，避免了手動去重帶來的資源消耗。通過對業(yè)務(wù)邏輯的拆解，我們可以選取合適去重列作為主鍵，在數(shù)據(jù)導(dǎo)入時通過 Delete and Insert 的方式完成“數(shù)據(jù)根據(jù)唯一主鍵進行去重”的需求。相比于在 Flink 中實現(xiàn)去重，StarRocks 主鍵模型可以節(jié)省大量的硬件資源，操作更為簡單，并且可以實現(xiàn)增量數(shù)據(jù)加存量數(shù)據(jù)的去重操作。

主鍵模型對寬表數(shù)據(jù)變更優(yōu)化

在固定報表業(yè)務(wù)場景中，通常會根據(jù)固定的查詢，在 Flink 中對數(shù)據(jù)進行簡單的業(yè)務(wù)清洗后打平成寬表，借用寬表極佳的多維分析性能，助力查詢提速，同時也簡化了分析師使用的數(shù)據(jù)模型。但由于寬表需要預(yù)聚合的屬性，在遇到維度數(shù)據(jù)變更的情況，需要通過重跑寬表以實現(xiàn)數(shù)據(jù)更新。StarRocks 的主鍵模型不僅可以應(yīng)用于數(shù)據(jù)變更場景，同時部分列更新的功能，也高度契合多種業(yè)務(wù)對寬表中不同字段進行部分更新的需求。

在寬表模型中，一般會有幾十上百甚至上千列。這給通過 UPSERT 方式完成數(shù)據(jù)更新的主鍵模型帶了一定的挑戰(zhàn)。我們需要獲得變更行的所有信息后，才能后完成寬表的數(shù)據(jù)更新。這使得變更操作會附帶上回表讀取的操作，需要從 StarRocks 中拉取變更的數(shù)據(jù)行，然后拼出插入的語句完成數(shù)據(jù)更新。這給 StarRocks 帶來了極大的查詢壓力。部分列更新的功能（partical update）極大程度的簡化 upsert 操作。在開啟參數(shù) partial_update 后，我們可以根據(jù)主鍵，只修改部分指定的列，原有的 value 列保持不變。

如下面的例子中，我們可以通過 Routine Load 導(dǎo)入方式來消費 Kafka 中的數(shù)據(jù)。在 properties 中需要設(shè)置 “partial_update” = “true”，指定開啟部分列更新模式，并指定需要更新的列名 COLUMN(id, name)。

CREATE ROUTINE LOAD routine_load_patical_update_demo on example_table COLUMNS (id, name), COLUMNS TERMINATED BY ‘,’ PROPERTIES ( “partial_update” = “true” ) FROM KAFKA ( “kafka_broker_list” = “broker1:9092,broker2:9092,broker3:9092”, “kafka_topic” = “my_topic”, “kafka_partitions” = “0,1,2,3”, “kafka_offsets” = “101.0.0.200” );

StarRocks X Flink CDC，打造極速統(tǒng)一的開源實時數(shù)倉平臺

Flink CDC 解決了數(shù)據(jù)鏈路冗長的問題，而 StarRocks 在 OLAP 分析層提供了極致的性能與一體化的數(shù)據(jù)存儲方案以匹配不同的業(yè)務(wù)場景。通過 StarRocks 結(jié)合 Flink CDC 構(gòu)建的實時數(shù)倉平臺的方案，能夠極大程度的減少開發(fā)與運維的成本。

StarRocks X Flink CDC，寬表實時數(shù)倉架構(gòu)

使用 StarRocks 與 Flink CDC 的聯(lián)合解決方案，我們可以較為清晰的將實時數(shù)倉規(guī)劃成為四層結(jié)構(gòu)：

• 數(shù)據(jù)源層，實時應(yīng)用層，與原有架構(gòu)相同，未做調(diào)整
• 數(shù)據(jù)傳輸與計算層，通過引入 Flink CDC，將數(shù)據(jù)采集層，消息隊列與事實計算層都放置在 Flink CDC 中，簡化了數(shù)據(jù)鏈路，減少了開發(fā)與運維成本。
• 數(shù)據(jù)分析與存儲層，StarRocks 中作為分析層數(shù)據(jù)存儲引擎，能夠提供不同的數(shù)據(jù)模型支撐不同類型的業(yè)務(wù)，簡化了分析層數(shù)據(jù)存儲復(fù)雜的技術(shù)棧。

在 ETL 不復(fù)雜的場景，我們可以將大部分 ETL 的操作放在 Flink 中實現(xiàn)。在某些場景下，業(yè)務(wù)模型相對簡單，事實數(shù)據(jù)與維度數(shù)據(jù)利用 Flink 多流 join 的能力打平成寬表，在 Flink 中完成了 DWD，DWS 與 ADS 層模型劃分。同時對于非結(jié)構(gòu)化的數(shù)據(jù)，也可以增量寫入到 Iceberg、Hudi 或 Hive 中，利用 StarRocks 的外表功能完成湖倉一體的架構(gòu)。

當 ETL 的過程中引入較為復(fù)雜的業(yè)務(wù)邏輯是，可能會在 Flink 計算層占用大量的內(nèi)存資源。同時，寬表的模式無法應(yīng)對查詢不固定的多維度分析場景。我們可以選擇使用星型模型來替換寬表模型，將數(shù)據(jù)清洗與建模的操作放到 StarRocks 中完成。

StarRocks X Flink CDC，實時數(shù)據(jù)變更架構(gòu)

在某些復(fù)雜的業(yè)務(wù)，如自助 BI 報表，運營分析等場景中，分析師往往會從不同的維度進行數(shù)據(jù)探查。查詢的隨機性與靈活性要求 OLAP 分析引擎對性能和多種建模方式都有良好的支持，以滿足使用者近乎“隨意”的在頁面上拉去指標和維度，下鉆、上卷和關(guān)聯(lián)查詢。

對于 StarRocks 而言，可以使用更為靈活的星型模型代替大寬表。為了增強多表實時關(guān)聯(lián)能力，StarRocks 提供了不同的 join 方式，如 Boardcast Join、Shuffle Join、Bucket Join、Replica Shuffle Join、Colocation Join。CBO 會根據(jù)表的統(tǒng)計信息選擇 join reorder 與 join 的類型。同時也提供了多種優(yōu)化手段，如謂詞下推、limit 下推、延遲物化等功能，進行多表關(guān)聯(lián)的查詢加速。

基于 StarRocks 的實時 join 能力，我們可以將 ETL 操作后置到 StarRocks 中，在 StarRocks 通過實時 join 的方式完成數(shù)據(jù)建模。同時通過 Primary Key 模型對于數(shù)據(jù)變更的支持，可以在 StarRocks 中創(chuàng)建緩慢變化維實現(xiàn)維度數(shù)據(jù)變更。

通過星型/雪花模型構(gòu)建的實時數(shù)倉，可以將計算層 Flink 的建模操作后置到 StarRocks 引擎中。在 Flink 中，只需要做 ODS 層數(shù)據(jù)的清洗工作，維度表與事實表會通過 Flink CDC 同步寫入到 StarRocks 中。StarRocks 中會在 ODS 層進行事實數(shù)據(jù)與維度數(shù)據(jù)的落地，通過聚合模型或物化視圖完成與聚合操作。利用 StarRocks 的實時多表關(guān)聯(lián)能力，配合智能 CBO 優(yōu)化器，稀疏索引及向量化引擎等多種優(yōu)化手段，能夠快速計算查詢結(jié)果，保證業(yè)務(wù)的在不同模型層的數(shù)據(jù)高度同源一致。

在現(xiàn)實生活中，維度的屬性并非是靜止的，會隨著時間的流逝發(fā)生緩慢的變化。星型模型可以將事實表與維度表獨立存儲，將維度數(shù)據(jù)從寬表中解藕，從而利用 StarRocks 的主鍵模型處理緩慢變化維的問題。一般來說，我們有三種方案處理緩慢變化維的問題：

• 使用主鍵模型，直接根據(jù)主鍵覆蓋原有的維度值。這種方式較為容易實現(xiàn)，但是沒有保留歷史數(shù)據(jù)，無法分析歷史維度變化信息；
• 使用明細模型，直接添加維度行，通過 version 列來管理不同的維度屬性版本，改種方案在查詢是需要根據(jù)業(yè)務(wù)條件篩選出合適的維度 version
• 使用主鍵模型，在主鍵中引入 version 信息，混合使用直接修改與新添加維度行的方法，該方法較為復(fù)雜，但也能更全面的處理復(fù)雜的維度變化需求

StarRocks X Flink CDC 用戶案例

在某知名電商平臺業(yè)務(wù)中，通過使用 StarRocks 與 Flink CDC 極大程度的簡化聊數(shù)據(jù)鏈路的復(fù)雜度。用戶通過 StarRocks 構(gòu)建實時數(shù)據(jù)看板平臺，實現(xiàn)了多維度數(shù)據(jù)篩選、靈活漏斗分析、不同維度上卷下鉆的靈活分析。

困難與挑戰(zhàn)

在電商數(shù)據(jù)看板平臺中，最初選擇了 ClickHouse 作為數(shù)據(jù)分析層的存儲引擎。但隨著業(yè)務(wù)的發(fā)展，ClickHouse 在部分場景中無法有效的支撐，主要體現(xiàn)在以下幾個方面：

• 根據(jù)用戶下單的操作，部分訂單的狀態(tài)會發(fā)生變化。但一般來說，超過兩周的訂單狀態(tài)基本不會發(fā)生變化；
• 部分變化的數(shù)據(jù)不適合通過寬表的形式存儲，部分的業(yè)務(wù)需求迭代較為頻繁，寬表 + 星型模型的建模方式可以更好的服務(wù)于業(yè)務(wù)變更；
• ClickHouse 擴縮容操作復(fù)雜，無法自動對表進行 rebalance 操作，需要較長的業(yè)務(wù)維護窗口。

為了解決以上的問題，該電商平臺重新做了技術(shù)選型。經(jīng)過不斷的對比與壓測，最終選擇使用 StarRocks 作為分析層的數(shù)據(jù)存儲引擎。

系統(tǒng)架構(gòu)

在實時看板業(yè)務(wù)中，主要可以劃分成五個部分：

數(shù)據(jù)源層：數(shù)據(jù)源注意有兩種，來自 Web 端與客戶端的埋點日志，以及業(yè)務(wù)庫中的訂單數(shù)據(jù)；

Flink CDC：Flink CDC 抓取上游的埋點日志與業(yè)務(wù)數(shù)據(jù)，在 Flink CDC 中進行數(shù)據(jù)的清洗與轉(zhuǎn)換，寫入到 StarRocks 中；

數(shù)據(jù)存儲層：根據(jù)業(yè)務(wù)的需求，將 DWD 層中的事實數(shù)據(jù)聯(lián)合維度數(shù)據(jù)拼成寬表，通過視圖的方式寫入到 DWS 層，在 ADS 層劃分出不同的主題域；

數(shù)據(jù)服務(wù)層：包含了數(shù)據(jù)指標平臺和漏斗分析平臺兩部分，根據(jù)內(nèi)部的指標、漏斗定義進行邏輯計算，最終生成報表供分析師查看；

數(shù)據(jù)中臺：圍繞大數(shù)據(jù)分析平臺，提供穩(wěn)定性保障、數(shù)據(jù)資產(chǎn)管理、數(shù)據(jù)服務(wù)體系等基礎(chǔ)服務(wù)；

選型收益

數(shù)據(jù)傳輸層：通過 Flink CDC 可以直接拉取上游的埋點數(shù)據(jù)與 MySQL 訂單庫中的增量數(shù)據(jù)。相比于 MySQL -> Canal -> Kakfa -> Flink 的鏈路，架構(gòu)更加清晰簡單。特別是對于上游的 MySQL 分庫分表訂單交易庫，可以在 Flink CDC 中通過 Mapping 的方式，將不同的庫中的表和合并，經(jīng)過清洗后統(tǒng)一寫入到下游的 StarRocks 中。省略了 Canal 與 Kafka 組件，減少了硬件資源成本與人力維護成本。

數(shù)據(jù)存儲層：通過 StarRocks 替換 ClickHouse，可以在業(yè)務(wù)建模時，不必限制于寬表的業(yè)務(wù)模型，通過更為靈活的星型模型拓展復(fù)雜的業(yè)務(wù)。主鍵模型可以適配 MySQL 業(yè)務(wù)庫中的訂單數(shù)據(jù)變更，根據(jù)訂單 ID 實時修改 StarRocks 中的存量數(shù)據(jù)。同時，在節(jié)點擴容時，StarRocks 更為簡單，對業(yè)務(wù)沒有侵入性，可以完成自動的數(shù)據(jù)重分布。

性能方面：單表 400 億與四張百萬維度表關(guān)聯(lián)，平均查詢時間 400ms，TP99 在 800ms 左右，相較于原有架構(gòu)有大幅的性能提升。替換 StarRocks 后，業(yè)務(wù)高峰期 CPU 使用從 70% 下降到 40%。節(jié)省了硬件成本。

在極速統(tǒng)一上更進一步

一款優(yōu)秀的產(chǎn)品，只提供極致的性能是不夠的。還需要豐富的功能適配用戶多樣的需求。未來我們也會對產(chǎn)品的功能進行進一步的拓展，同時也會在穩(wěn)定性與易用性上做進一步的提升。

日前，阿里云 E-MapReduce 與 StarRocks 社區(qū)合作，推出了首款 StarRocks 云上產(chǎn)品。我們也可以在 EMR 上選擇相應(yīng)規(guī)格的 Flink 與 StarRocks。為了提供更好的使用體驗，阿里云 E-MapReduce 團隊與 StarRocks 也在不斷的對產(chǎn)品進行優(yōu)化，在未來的幾個月會提供以下的功能：

• 多表物化視圖：StarRocks 將推出多表關(guān)聯(lián)物化視圖功能，進一步加強 StarRocks 的實時建模能力；
• 湖倉一體架構(gòu)：StarRocks 進一步 Apache Iceberg 與 Apache Hudi 外表功能，打造 StarRocks 湖倉一體架構(gòu)；
• 表結(jié)構(gòu)變更同步：在實時同步數(shù)據(jù)的同時，還支持將源表的表結(jié)構(gòu)變更（增加列信息等）實時同步到目標表中；
• 分庫分表合并同步：支持使用正則表達式定義庫名和表名，匹配數(shù)據(jù)源的多張分庫分表，合并后同步到下游的一張表中；
• 自定義計算列同步：支持在源表上新增計算列，以支持您對源表的某些列進行轉(zhuǎn)換計算；

一款優(yōu)秀的產(chǎn)品也離不開社區(qū)的生態(tài)，歡迎大家參與 StarRocks 與 Flink 社區(qū)的共建，也歡迎大家測試 StarRocks Primary Key X Flink CDC 的端到端實時數(shù)倉鏈路方案。

原文鏈接：http://click.aliyun.com/m/1000346410/

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。