摘要：本文整理自 Apache Flink 中文社區(qū)發(fā)起人、阿里巴巴開源大數(shù)據平臺負責人王峰（莫問），在 Flink Forward Asia 2022 主會場的分享。本篇內容主要分為四個部分：
- 實時流計算全球范圍事實標準
- 2022 數(shù)據實時化技術創(chuàng)新不止
- Streaming Data Warehouse
- 流式數(shù)倉 Demo
一、實時流計算全球范圍事實標準
Apache Flink 社區(qū)從 2014 年誕生到 2022 年已經經過了連續(xù)八年的快速發(fā)展。從早期的互聯(lián)網行業(yè)逐步擴展到更多的傳統(tǒng)行業(yè)，比如金融、電信、交通、物流、以及能源制造等等。
Apache Flink 誕生于歐洲，爆發(fā)于中國。最近幾年席卷全球，在北美、東南亞等全球各地開始被大量使用?？梢哉f在全球的各個行業(yè)，只要大家想到實時流計算，基本上都會選擇 Apache Flink。因此我們就可以認定 Apache Flink 社區(qū)已經成為了全球范圍內實時流計算的事實標準。從 2022 年社區(qū)的各項指標中，也進一步得到印證。
Flink 社區(qū)經過八年的快速發(fā)展，在 Github Star 上也一直持續(xù)穩(wěn)定的快速增長。目前為止，F(xiàn)link 的 Github Star 已經超過了 20000，這在 Apache 主流的大數(shù)據項目中依然是名列前茅的。
在開發(fā)者生態(tài)方面，我們也已經積累了超過 1600 名的開發(fā)者，為 Flink 社區(qū)做貢獻，2022 年又新增加了 200 多名開發(fā)者。從下載量上也可以看到，F(xiàn)link 在 2022 年再創(chuàng)新高，月度峰值的下載量最高已經突破 1400 萬次。
在整個 Flink 國際化生態(tài)不斷繁榮發(fā)展的過程中，我們可以非常自豪的看到，中國開發(fā)者在里面承擔了非常大的核心推動力。
通過 OSS Insight 網站的數(shù)據統(tǒng)計可以看到，F(xiàn)link 社區(qū)在 Github 上產生的 Pull Request 有 45% 是來自于中國的開發(fā)者。由此可見，整個社區(qū)的技術演進和技術開發(fā)的推動力主要都是由中國開發(fā)者帶來的。
Apache Flink 中文社區(qū)這幾年也在持續(xù)穩(wěn)定的發(fā)展中。去年非常多國內的開發(fā)者在 Apache Flink 社區(qū)公眾號上發(fā)布了文章，數(shù)量達 100 多篇。Apache Flink 社區(qū)公眾號的訂閱人數(shù)也已經超過了 60000 名。今年我們還推出了 Apache Flink 官方的視頻號，目前訂閱人數(shù)也已經將近 4000 名。
Flink 經過多年持續(xù)的健康發(fā)展，形成了一個繁榮的生態(tài)， 它的核心競爭力是什么呢？其實非常明確的可以看到，就是 Flink 的技術領先性，實時化的大數(shù)據計算能力。
Flink 社區(qū)最近幾年其實也和其他的主流的開源社區(qū)和生態(tài)進行了合作，形成了一系列豐富多彩的實時化大數(shù)據場景解決方案，例如：
和 HBase 社區(qū)聯(lián)合起來形成實時大屏分析的解決方案。
和一些生態(tài)數(shù)倉項目，比如 Hudi、Iceberg、ClickHouse、StarRocks、Doris、TiDB 等開源湖倉產品，形成全鏈路實時湖倉分析解決方案。
和主流的深度學習框架，比如 TensorFlow，PyTorch 項目進行聯(lián)合使用，提供實時化、個性化推薦的解決方案。
和 Prometheus 形成實時監(jiān)控報警的解決方案。
從以上內容我們可以看到，F(xiàn)link 社區(qū)的心態(tài)是非常開放的，可以和很多主流的開源社區(qū)形成聯(lián)合解決方案。讓豐富多彩的實時化場景解決方案，推動各個行業(yè)大數(shù)據實時化技術的升級。
二、2022 數(shù)據實時化技術創(chuàng)新不止
接下來我將為大家介紹一下，2022 年中 Flink 社區(qū)在實時化技術路線上的一些重要技術成果和創(chuàng)新成果。
Apache Flink 社區(qū)在 2022 年發(fā)布了兩個大的版本，F(xiàn)link 1.15 和 Flink 1.16。在 1.15 中，F(xiàn)link 解決了很多以前歷史存在的一些難題，比如初步支持了跨版本流 SQL 作業(yè)升級，在 1.15 中可以檢測到新老版本不兼容的情況并對用戶進行提示，也可以去兼容老版本的 plan 進行升級。
此外 1.15 也解決了 Flink 在多 Source 對齊情況下的挑戰(zhàn)。因為 Flink 的一個流任務可以有時候會有多個數(shù)據源或者日志流。不同的日志流的數(shù)據進展是不一樣的，所以就有可能導致他們的數(shù)據進度差異較大。在 1.15 中提出了新的方案，更加方便的實現(xiàn)了多 Source 的 Watermark 對齊。
在 Flink 核心理念中，比如 Checkpoint 和 Savepoint 這兩個概念用戶就一直不是很清楚，經常會使用不當。因此在 1.15 中也對這兩個概念重新進行了梳理和定義。同時也將 Checkpoint 和 Savepoint 進行存儲格式的統(tǒng)一，讓 Savepoint 也可以像 Checkpoint 一樣高效的被使用。
此外對批處理技術也進行了更多的完善，包括批算子的自動并發(fā)設置，讓批處理更加易用，流批一體更加實用。
在 1.16 中，我們做了更多的技術創(chuàng)新和新的技術的嘗試。比如我們對整個 Flink 分布式一致性快照技術架構，進行了很大程度的升級，落地了 Unaligned CP + Log-Based CP 新組合。在 Flink Streaming 方面引進了異步化的技術和緩存能力，使得 Streaming 維表 Join 有更強的能力。
在流批一體領域提出了流批自適應 Hybrid Shuffle，通過更加合理的利用集群資源，來提升網絡 Shuffle 的性能。
在生態(tài)方面，對 Hive 生態(tài)進行了更好的兼容和擁抱。不僅能夠無縫對接 Hive 的 HMS，也完全兼容了 HiveServer2 協(xié)議。在 Hive SQL 的兼容性上，F(xiàn)link SQL 也達到了 94%以上的兼容度，也就是原來用戶在 Hive 生態(tài)上寫的 Hive SQL 絕大部分都可以不經過修改直接運行在 Flink 引擎之上，利用 Flink 實時化計算高性能的能力，去加速 Hive 離線數(shù)倉的性能。
在 Python API 方面，PyFlink 也得到了徹底的完善。在 1.16 中已經基本覆蓋了所有 Flink 的關鍵算子。這樣對 Python 程序員來說，也可以通過 Python 語言使用 Flink 所有特性了。
剛才介紹的 Flink 1.15 和 Flink 1.16 的諸多特性，也只是冰山一角。其實整個 1.15 和 1.16，還推出了非常多的特性和改進。接下來我會選擇一些比較有代表性和創(chuàng)新性的技術點進行深度解讀。
首先來看一下新一代分布式一致性快照的架構。我們知道分布式一致性快照技術在整個 Flink 社區(qū)里是非常核心的理念。Flink 作為一款有狀態(tài)的流計算引擎，分布式快照是它的非常核心的特點。
比如 Flink 在不停做流計算的過程中，會定期 Take Snapshot 或者 Checkpoint 將流計算的狀態(tài)進行持久化。就算流任務出現(xiàn)異常，它也可以從上一個臨近的狀態(tài)進行恢復，保證業(yè)務的連續(xù)性。因此 Flink 的用戶都有一個天然的訴求，就是希望 Flink 的分布式一致性快照可以更加低成本、高頻的做出來，從而讓業(yè)務更加流暢。
但是在真實的生產環(huán)境中，尤其是大規(guī)模、復雜的生產環(huán)境中， 分布式一致性快照是面臨非常多挑戰(zhàn)的。尤其是在反壓的情況下，挑戰(zhàn)尤為突出。因為在反壓的過程中，整個流計算的網絡 buffer 會被打滿，也就是網絡擁塞。
用來做 Checkpoint 的 Barrier 沒有辦法成功的在流里面?zhèn)鬏?，所以各個流計算的算子也沒有辦法收集到這些 Barrier，并且讓 Barrier 對齊，也就沒有辦法觸發(fā) Checkpoint。即使能夠觸發(fā) Checkpoint，在執(zhí)行 Checkpoint 動作的時候，也需要把本地的狀態(tài)數(shù)據上傳到遠程的云存儲之上，數(shù)據量的大小也是不可控的。如果在狀態(tài)數(shù)據的變化比較大的情況下，Checkpoint 依然會持續(xù)很久，并變得不可控。
所以 Flink 在最近幾個版本中對整個分布式一致性快照架構做的很多的技術點的升級 。比如我們連續(xù)做了多個版本的 Unaligned Checkpoint，推出了 Buffer Debloating 技術。在 Flink 1.16 中落地了 Log-based Checkpoint 來做架構升級和改造。
通過 Buffer Debloating 可以讓整個網絡 buffer 使用更加高效；通過 Unaligned Checkpoint 去除對 Barrier 對齊的依賴；通過 Log-based Checkpoint 大幅降低執(zhí)行 Checkpoint 的成本。
接下來分享一下 State 狀態(tài)存儲體系。在云原生時代，我們需要對 Flink 的狀態(tài)存儲體系進行了更大范圍的升級。相信各個開源軟件或者基礎軟件都需要去考慮如何去適應 Cloud Native 時代，如何去進行相應的升級和轉型。
云原生時代給我們帶來了的最明顯的特點就是資源的彈性更強了，越來越 Serverless 了，這對 Flink 架構提出了更高的彈性擴縮容需求。Flink 作業(yè)的并發(fā)會隨著資源彈性和業(yè)務負載不斷改變，因此 Flink 的狀態(tài)存儲也需要進行相應的適配，即狀態(tài)數(shù)據的分裂和合并。
如果狀態(tài)存儲根據并發(fā)的變化而進行分裂合并的性能變差，整個 Flink 的彈性擴縮容就會受到嚴重的影響。因此在 Flink 1.16 中，對 RocksDB State Backend 的狀態(tài)重建算法進行了大量優(yōu)化，使之有 2-10 倍的提升。
但這還不是我們的終極方案，后續(xù) Flink 將會對整個狀態(tài)存儲管理體系進行更大的升級，變成一個徹底的存算分離架構來適應云原生環(huán)境。我們希望所有的狀態(tài)數(shù)據全部都原生在 HDFS 或者云存儲之上，本地磁盤和內存只是狀態(tài)數(shù)據的緩存加速層，構建一套體系化的 Tiered State Backend 系統(tǒng)。
接下來分享一下流批一體上的技術創(chuàng)新。流批一體是 Flink 中一個非常有特色的技術理念，Shuffle 是整個分布式計算里非常核心的一個性能相關的技術。在 Flink 的 Shuffle 中，有兩種經典的 Shuffle，分別是流式的 Pipeline Shuffle 和批式的 Blocking Shuffle。
流式的 Pipeline Shuffle 是任務的上下游，通過網絡的方式直接連接進行數(shù)據傳輸。批式的 Blocking Shuffle 是上游將中間數(shù)據寫到磁盤或者存儲服務上，下游通過磁盤或者存儲服務下載中間數(shù)據。因此在常規(guī)的理念中，流執(zhí)行模式都會用流式 Shuffle，批任務都會用批式 Shuffle。
但我們也可以明顯的看出，流式 Shuffle 的性能比較高，因為它不經過磁盤 Io，而批式 Shuffle 經過一次磁盤 Io 性能會更差一點。所以我們能不能將流式 Shuffle 也應用在批執(zhí)行模式或者批任務場景下，加速批式 Shuffle 呢？
從技術本身來說是可以的，但在真正生產環(huán)境下執(zhí)行的時候，會發(fā)現(xiàn)有一個很大的約束或者不確定性。因為流式 Shuffle 有個前提條件是，上下游或者說一個聯(lián)通的連通圖需要同時拉起。但這就需要更多的資源，而真正在生產環(huán)境下是否能有這么多資源是不可保證的，所以就可能有死鎖的情況發(fā)生。
因此是否可以在資源相對充足的情況下，把連通圖一起拉起進行流式 Shuffle 加速。而資源不夠的情況下，退回到經典的批式 Blocking Shuffle，這樣就可以合理的利用資源來進行 Shuffle 加速了。答案肯定是可以的。這也是在 1.16 中推出 Hybrid Shuffle 的背景和思路起因。
接下來分享一下最近一兩年新提出的概念 Flink CDC，即基于 Flink 的全增量一體數(shù)據同步技術。首先介紹一下做 Flink CDC 的原因。
Flink 本質上是一款流式的分布式執(zhí)行引擎或者計算引擎，它在大家心目中已經是連接各種不同存儲的數(shù)據管道或者數(shù)據通道了。Flink 本身具有非常多的技術特色，比如有豐富的 Connector 生態(tài)，能夠連接各種各樣的主流存儲系統(tǒng)；有優(yōu)秀的分布式架構，包括支持 Checkpoint 機制，流批融合機制。這些都是一款全增量一體數(shù)據集成引擎所需要的特性。所以我們認為，在 Flink 的肩膀上去構建一款全增量數(shù)據同步引擎是特別容易成功的，因此就啟動了 Flink CDC 項目。
其實在去年 Flink-CDC 1.0 的試水中，整個開發(fā)者生態(tài)對它都是一個非常正向的反饋。所以今年加大了對 Flink CDC 的投入，推出了更加完善和成熟的 Flink CDC 2.0 大版本和框架。在 2.0 中，我們抽象出了通用的增量快照一致性讀取算法。有了它之后，就可以降低接入數(shù)據源的成本，加速接入更多的數(shù)據源。
同時結合整個分布式框架的諸多優(yōu)勢，F(xiàn)link CDC 已經具備了非常強的能力。比如支持高性能的并行讀取，借助 Flink Checkpoint 優(yōu)勢，實現(xiàn)數(shù)據斷點續(xù)傳。并通過增量一致性快照讀取算法，可以全程對數(shù)據庫無鎖，這樣我們在整個全增量一體數(shù)據同步的過程中不會對在線業(yè)務有任何的影響。
從下圖中可以看到，F(xiàn)link-CDC 2.0 已經接入了很多主流的數(shù)據源，比如 MySQL 家族，PolarDB，Oracle，MariaDB 等，接入中有 PG，TiDB 和 Ocean Base 等，相信日后會有更多的數(shù)據源接入到 Flink CDC 數(shù)據同步框架中。
在最后一項技術創(chuàng)新中，我分享一下 Flink 在機器學習場景中的子項目 - Flink ML 2.0。大家都知道在老版的 Flink 中有一個模塊叫 Flink ML，即 Flink 機器學習算法庫。老的 Flink ML 模塊是基于 Flink DataSet API 來構建的，但 DataSet API 已經被廢棄了。在最近幾個版本中，F(xiàn)link 已經將基礎的 API 層全部統(tǒng)一到流批一體的 DataStream API 之上，不再使用 DataSet，所以老版 Flink ML 也相當于被廢棄了。
去年其實已經預告了要重新建設 Flink ML 成為一個新的 Flink 子項目。今年我們通過努力已經將這件事進行了從 0-1 的孵化和落地，并發(fā)布了兩個版本，第三個版本也在進行之中。
我們都知道機器學習的算法庫，它的運算核心是迭代計算框架，因此我們在 Flink ML 2.0 項目中，基于 Flink Data Stream 流批一體的 API，重建了一套流批一體的迭代計算框架。它不僅支持傳統(tǒng)的同步迭代訓練，也支持異步的迭代訓練模型。
Flink 不只支持有限數(shù)據集的訓練，也支持無限流數(shù)據集上的在線迭代訓練。同時借助 Flink Checkpoint 分布式框架的優(yōu)勢，也支持整個分布式訓練斷點的異?；謴汀＿@對一些需要長時間運行的訓練任務還是有很好的生產意義的。
經過一年的努力，在社區(qū)版已經對 Flink ML 的算法進行了第一步的完善。阿里云實時計算和機器學習團隊共同貢獻了 30 多個經典的機器學習算法，覆蓋了常見的特征工程場景，明年將會完成所有主流經典 ML 算法庫的完善。
三、Streaming Data Warehouse
Flink 下一步核心演進的方向是 Streaming Data Warehouse。在這之前，為了更好理解，先來回顧一下歷史上核心理念的演進的過程。
Flink 在誕生的時候，它為什么能擊敗了上一代流式計算引擎 Storm，受到開發(fā)者的青睞，成為新的一代流計算的計算引擎的呢？我覺得關鍵的核心點是 Flink 是一款有狀態(tài)的流計算，而 Storm 是一個無狀態(tài)的流計算引擎。
Flink 將 Streaming 計算和狀態(tài)存儲進行有機融合，這樣就可以在框架層支持整個流計算狀態(tài)的精準數(shù)據一致性。不僅保持低延遲、高吞吐的流計算能力，還保證了數(shù)據一致性，而且是在框架層面保持的，這是 Storm 做不到的。所以 Flink 憑借技術架構上的創(chuàng)新成為了新一代流計算的霸主。
但在 Flink 誕生之后的幾年，就遇到了一個瓶頸，推廣門檻過高。因為大家在早期開發(fā) Flink 的時候，都要寫 Java 程序，通過 DataStream 的 API 寫 Java 代碼，這對很多數(shù)據分析師來說門檻還是很高的。因為在整個數(shù)據分析師的世界里，標準的語言是 SQL，這也是 Flink 很難推廣的一個原因。
2019 年，阿里巴巴將自己內部積累的 Blink SQL 貢獻給了 Flink 社區(qū)，從此 Flink 社區(qū)也有了一套非常易用的 Stream SQL。有了 SQL 后大幅降低了開發(fā)門檻，所以之后 Flink 的應用得到了爆炸式的增長，這也是為什么大家看到最近這兩三年 Flink 出現(xiàn)了一個加速普及的過程。
但是 SQL 只能夠解決計算層的一些體驗問題。即使 Flink 具備流批一體 SQL 的能力，能夠實現(xiàn)全量增量開發(fā)一體化的體驗，但它依然沒有辦法解決存儲層割裂的問題。
下一階段 Flink 社區(qū)新的機會點就是繼續(xù)提升一體化的體驗，來實現(xiàn)一套實時數(shù)據鏈路。因此我們可以通過 Flink 的流批一體的 SQL 和流批一體的存儲，構建一套真正一體化體驗的流式數(shù)倉- Streaming Data Warehouse。
在 Streaming Data Warehouse 新的理念和形態(tài)中，可以保證所有的數(shù)據端到端都可以實時流動；整個全鏈路的開發(fā)過程中，用戶都可以有全增量一體化的開發(fā)體驗，并且有統(tǒng)一的數(shù)據存儲和管理體系。
因此如果要去做下一代的 Streaming Data Warehouse 架構。第一步要完善的就是流批一體存儲。目前在開源生態(tài)中還沒有一款真正能夠實現(xiàn)，高性能流讀流寫、批讀批寫的流批一體存儲。
因此 Flink 社區(qū)去年推出了全新子項目 Table Store，它的定位就是實現(xiàn)流批一體的存儲能力。它的特點是能實現(xiàn)高性能的流讀流寫、批讀批寫，所以我們把 Table Store 的數(shù)據表稱為動態(tài)表。
Table Store 的設計完全遵循現(xiàn)在新一代存算分離的理念，可以把數(shù)據存儲在 HDFS 或者主流云存儲上。它的核心存儲格式是由 Lake Store 和 Log Store 兩部分組成。
在 Lake Store 中，應用了很多經典的數(shù)據結構，比如 LSM 和 ORC，以及一系列索引技術。LSM 技術比較適合大規(guī)模數(shù)據更新，ORC 的列存技術配合一些索引，適合高性能的數(shù)據讀取。在 Log Store 中，提供了完整 CDC 語義的 Changelog，這樣配合 Flink 的 SQL 就可以增量訂閱 Table Store，進行流式的數(shù)據分析了。
整個 Table Store 的數(shù)據體系是完全開放的，它除了可以默認對接 Flink 之外，它也能對接 Spark、Hive、Trino 等這些主流的開源計算引擎。
Table Store 在 Flink 社區(qū)已經發(fā)布了兩個版本，0.1 和 0.2。目前除了阿里巴巴以外，字節(jié)跳動等一些公司也參與了項目的共建。接下來看一下經過兩個版本發(fā)布，Table Store 在真正場景下的流讀、流寫、批讀、批寫的性能怎么樣。我們做了一個性能測試，將 Table Store 和目前最主流的數(shù)據湖存儲 Hudi 進行了對比。
整個性能測試的業(yè)務場景來自經典的 TPC-H，利用 TPC-H 的工具產生 6000 萬條訂單數(shù)據，寫入到 MySQL 的訂單表中，模擬一個真實的業(yè)務行為。然后利用 Flink CDC 做數(shù)據同步，將 MySQL 的數(shù)據同步到數(shù)據湖倉表中。一條鏈路將它寫入到 Apache Hudi 里，一條鏈路寫入到 Table Store。然后去測試、對比一下，兩個不同技術數(shù)據更新的性能差異，同時我們再用 Flink SQL 對這兩張數(shù)據表進行查詢。
在測試結果中，我們可以看到 Table Store 的更新性能非常優(yōu)秀，明顯領先了 Hudi 的更新能力。在數(shù)據查詢的性能上明顯領先了 Hudi 的 MOR 模式，比較接近 COW 模式，綜合性能上可以看出 Table Store 流批一體的讀寫性能還是非常優(yōu)秀的。
四、流式數(shù)倉 Demo
為了讓大家更好的理解 Streaming Data Warehouse 這個新理念，制作了一個 demo 供大家觀看。
首先通過 Flink SQL 實時同步到 Table Store，然后構建 ODS, DWD，ADS 層。數(shù)據及元數(shù)據存儲在云上 OSS。demo 使用 TPC-H 數(shù)據集，包含兩張事實表，主訂單 orders，子訂單 lineitem，和兩張維度表，分別是用戶維表 customer、國家維表 nation。
主訂單表關聯(lián)用戶維表可以得到用戶所在國家標識，關聯(lián)子訂單表可以得到訂單價格，關聯(lián)國家維表可得到國家字段。被打寬后的明細表，按年和國家進行聚合即可得到年度國家 GMV 分布。
首先創(chuàng)建 MySQL 數(shù)據庫到 Table Store 的同步任務。第一張是訂單明細表 line item。在 Table Store 中，為了更好的區(qū)分不同數(shù)據層，我們給它加上 ods 前綴。在 with 參數(shù)中，我們指定了表的 OSS 存儲地址，并設置 auto-create 屬性為 true，即自動創(chuàng)建當前表的所在目錄。
類似的方式聲明其余三張表的 DDL，將主訂單表、用戶維表、國家維表進行同步。在提交任務時，我們使用 statement set 語法，將四張表放在一個任務里進行同步。下面我們開始操作；
從模板中心創(chuàng)建同步任務，點擊提交準備上線作業(yè)。
切換到運維界面，準備啟動。
在同步任務啟動后，我們可以開始生成訂單明細數(shù)據，接下來的動畫會演示生成明細數(shù)據的過程。
首先使用主訂單中的 o_orderkey 關聯(lián)子訂單中的 l_orderkey，可以看到主訂單中只有 o_orderkey 等于 1 的記錄，滿足等值條件。
這里使用 interval join 讓主訂單表的下單日期 o_order_date 與子訂單表的發(fā)貨日期 l_shipdate 在 14 天內，可以看到子訂單表中只有一條記錄滿足 interval 條件。
同時我們用子訂單中的金額字段和折扣字段計算出 GMV 字段 l_revenue。
緊接著，我們使用 customer key 與用戶維表進行 look up join，得到了用戶所在國家的標識 c_nation_key。
最后我們與國家維表進行關聯(lián)，得到了用戶所在國家字段。
通過一次 interval join 和兩次 look up join 訂單明細表就構建完成了。
接下來我們就可以對明細表按年和國家進行匯總，計算出 GMV 金額。我們同樣使用 statement set 語法將明細層和匯總層的計算放在同一個任務里。
下面開始生成作業(yè)：點擊提交，準備上線作業(yè)。
切換到運維界面準備啟動。
現(xiàn)在所有任務都在運行中，我們創(chuàng)建臨時查詢來預覽匯總表的數(shù)據。隨機選取 1993 年，各個國家的 GMV 數(shù)據已經展示出來了。
在上一步中，我們已經計算并查詢了匯總之后的國家 GMV 數(shù)據。假設我們接到一個新的需求，要將國家維表中的國家字段從英文轉換為中文，進行數(shù)據訂正。此時我們可以創(chuàng)建 batch 作業(yè)，對維表和它所產生的下游表進行 overwrite。
從模板中心創(chuàng)建為表訂正任務。點擊提交準備上線作業(yè)，切換到運維界面準備啟動。
等待作業(yè)啟動并執(zhí)行完畢后，按照同樣方式對 DWD 和 ADS 表進行 overwrite。在上游數(shù)據訂正任務都執(zhí)行完成后，我們重新查詢匯總表的數(shù)據，可以看出在訂正后匯總表的國家已經轉化為中文。
以上就是本次 demo 的全部內容。
