TIS 整合 ChunJun 實操

B 站影片：

一、ChunJun 概述

ChunJun 是一款易用、穩定、高效的批流統一的資料整合框架，可基於實時計算引擎 Flink 實現多種異構資料來源之間的資料同步與計算，既可以採集靜態的資料，比如 MySQL，HDFS 等，也可以採集實時變化的資料，比如 Binlog，Kafka 等。

目前的核心功能包括：

・多源異構資料匯聚

作為一個開放式系統，使用者可以根據需要開發新的外掛，接入新的資料庫型別，也可以使用內建的資料庫外掛。目前相容 30 + 異構資料來源的資料讀寫與 SQL 計算。

・斷點續傳

針對網路波動等異常情況，導致資料同步失敗的任務，在下一次任務時自動從上一次失敗的資料點進行資料同步，避免全部重跑。

・資料還原

除了 DML 操作以外，一些源端資料庫的 DDL 操作也能做到同步，最大程度保證源端資料庫和目標端資料庫的資料統一和結構統一，做到資料還原。

・髒資料管理

資料傳輸過程中，因資料質量或主鍵約束等其他因素導致資料無法同步到目標資料庫，針對這些髒資料進行統計和管理，便於後續進行髒資料分析。

・速率控制

資料同步過程中，資料傳輸效率是關鍵。ChunJun 針對各種場景，有的放矢地控制速率，最大程度保證資料同步的正常進行。

更多詳見：

Github：

Gitee： https://gitee.com/dtstack_dev_0/chunjun

官網：

ChunJun 架構：

二、TIS 概述

TIS 最早是基於 Solr 為使用者提供一站式開箱即用、自助服務的搜尋引擎中臺產品。在 2020 年之前，當 Flink 和 MPP 引擎還沒有形成影響力時 ，TIS 就已經在為網際網路企業內部提供實時 OLAP 分析需求的服務。

為滿足大資料業務需求，快速將工具棧進行整合。TIS 從 2019 年底開始轉型，開始全方位支援現有實時數倉中臺，從原先與搜尋引擎強耦合的技術架構進行重構。從只處理搜尋引擎一個場景，相容到所有資料端的大資料生態場景。

經過 TIS 開發者的努力，現在的 TIS 內部有一套強大的後設資料管理系統，根據使用者需求大部分的工作指令碼可自動生成（TIS 是基於模型的 DataOps，區別於市面上其他基於指令碼任務的 DevOps 系統，摒棄掉所有繁瑣的指令碼操作），等到任務所需資源準備好，使用者輕點資料系統就開始執行。

另外更為關鍵的是，TIS 能夠將專業大資料技術人員和大資料分析師這兩種角色解耦。一個實時數倉中臺，使用它的人並不需要了解裡面的技術細節，並不需要知道 Flink、Hive、Hadoop 的技術細節，只要知道他們是幹什麼的就行。基於以上，TIS 改造之初並沒有針對實時數倉進行編碼，而是花了將近一年時間對 TIS 產品底座進行構建，著重進行了以下幾方面的構建：

外掛倉庫 / 熱生效機制

現有行業中提供的工具棧，需要在後臺系統中自行部署，TIS 則簡化了這一流程，TIS 在構建專案之時會統一將第三方的依賴包進行打包，預先部署到遠端倉庫中，使用者在 TIS 中可以檢視到可用外掛清單。在使用時，只需滑鼠點選下載且熱生效就可使用，操作體驗流暢。

全流程建模

針對 ETL 的各流程進行建模，將可變因素進行抽象，抽取成一個 TIS 系統中的擴充套件點，統一歸檔到 TIS 的主工程中，在主工程中沒有任何具體業務程式碼的實現，這樣在進行具體業務邏輯實現中就不需要更改任何主工程的程式碼，在架構層面最大限度地貫徹了 OCP 原則。

例如以下是對 ETL 中，針對結構化（支援 JDBC 介面）和非結構化資料來源的執行流程圖：

構建 UI-DSL 系統

隨著整合進 TIS 的功能元件越來越多，需要單獨開發的 UI 工作量巨大且風格難以統一，大量重新程式碼維護困難，同時由於行業分工精細化，流程需要前後端工程師相互協作，導致開發效率低，如何讓沒有前端開發經驗的後端開發工程師，能夠獨立且暢快地完成一個 UI 元件的開發，成為一個重要的課題。為解決這個問題，TIS 在底座中實現了一個 UI-DSL 的系統，後端開發工程師使用 JAVA 語言編寫一個表單對應的 MetaData 指令碼，裡面定義表單的佈局，輸入項的校驗等資訊，執行期會自動將 MetaData 指令碼渲染成前端的表單，從而完美解決這個課題。

 如上，是 TIS 中定義的 MySQL 資料來源外掛，只需要在對應 POJO 上為對應的屬性新增 FormFieldAnnotation 標識，在配上欄位對應的預設值、label 等資訊描述檔案：

 @FormField(ordinal = 3, // 表單中的排位順序 
    type = FormFieldType.INPUTTEXT // 表單中控制元件型別
   , validate = {Validator.require, Validator.identity}) // 輸入項的校驗規則
	public String dbName;

DataSourceFactory.json

 { "dbName": { "label": "資料庫名", "help": "資料庫名,建立JDBC例項時用"
	 }}

三、整合 ChunJun 完善 TIS 生態

經過幾個月時間的研發，TIS V3.6.0-alpha 版本終於釋出了。該版本的最大亮點，即整合了大資料領域資料同步工具的翹楚 ChunJun，將 TIS 的業務能力提升到了新高度。

TIS 的最新版本：

早在 V3.6.0-alpha 之前，TIS 已經整合了 Alibaba DataX 和 Flink-CDC。離線批次同步利用 DataX 元件實現，而在實時資料變更 Source 元件方面，TIS 是基於 Flink-CDC 來實現的。至於 Sink 部分，則一直是基於各種資料端提供的生態 API 包經過二次開發完成的。

其中存在的問題是，開發週期長，除錯困難，例如，僅僅為了實現 StarRocks 一個 Sink 端實現一個基於 StreamFunction 的 Sink 實現，連開發帶測試花去了整整三個星期的時間。

直到整合 ChunJun 之後才解決了這些問題。ChunJun 已經很好地支援了大資料領域的大部分資料端，包括 Source 和 Sink。它的 Source 端基於 Polling 輪詢機制來實現，相較與 Flink CDC 實現的 Source 端是有自己的特色的。

例如，並不是所有的端都支援類似 MySQL binlog 這樣的實時同步機制，即使支援類似 Oracle 的 LogMiner，如需開啟，也需要專業 Oracle DBA 協助，不然設定許可權就會嚇退很多使用者。而基於 Polling 機制的實時更新訂閱卻可以支援所有的 Source 端，只要實現了 JDBC 介面就行。

所以 ChunJun 的 Source 端通用性非常好，比之於 Flink CDC 的唯一劣勢是實時性要低，不過一般在大部份 OLAP 的場景下使用者對實時性的要求並沒有那麼高，所以一般情況下推薦使用 ChunJun 的 Source 來監聽實時資料變更。

另外，ChunJun 的 Sink 端實現也是一大特色，一般情況下資料端的生態產品中會提供 Flink Sink 的實現，例如：ElasticSearch 的 Flink 官網提供了一個基於 SinkFunction 的實現，StarRocks 在官網也提供了 Sink 實現。但是各家實現方式各不相同，沒有一個統一的抽象模型。另外各廠商提供的實現中基本上只是一些半成品，像容災、監控等都沒有提供，導致 TIS 在整合各家 Sink 端時著實花了不少精力且很難做得完美。

因此在 TIS v3.6.0 中利用 ChunJun v1.12.5 全面改寫了 TIS 原有的 Sink 端實現，由於 ChunJun 實現是一個封裝好並且已經在生產環境中經過檢驗的，並且在實現方式上已經透過統一建模，每種端的接入方式可以統一，對 TIS 來說大大提高了整合開發效率，而且將容災、監控、髒資料管理也一併實現。

ChunJun 支援的 Connector 端非常豐富，TIS v3.6.0 中只是揀取了幾個使用者高頻使用的端來封裝，其他端的封裝會在後續版本中逐步實現。以下是 v3.6.0 版本中實現的端型別：

四、TIS 是如何整合 ChunJun

利用 TIS 後設資料管理系統接管 ChunJun 流資料型別控制

ChunJun 流處理中構建的 RowData 例項是透過目標端 Jdbc MetaData 自動生成的（使用者不需要在 JSON 配置檔案中設定），內部需要透過目標端（Source/Sink）欄位 JDBC 中的後設資料資訊的 fieldType 作為引數來對映 flink 的 DataType 例項，呼叫的介面是 com.dtstack.chunjun.converter.RawTypeConverter，

public interface RawTypeConverter {   
 DataType apply(String type);
 }

在實際處理過程中發現，僅僅利用 JDBC col metaDatafieldType 作為引數還是不夠，例如：MySQL 的表定義為 bigint，int，smallint 的整型，當使用者新增 unsigned 修飾，bigint 在 Flink 中的對映型別需要從 BigIntType 變成 DataTypes.DECIMAL，原 smallint 型別需要變成 IntType，不然執行就會出錯。另外像 Oracle 的 Jdbc 內部實現了一套區別於 Jdbc 標準的型別規範 oracle.jdbc.OracleTypes，當得到 Oracle 的型別之後需要歸一化成 Jdbc 的型別 java.sql.Types，不然沒法正常執行。

型別對映雖然很簡單，但由於 Java 是強型別語言，在流處理執行過程中稍有不慎就會出現 ClassCastException，所以得格外小心地處理，因此 TIS 在 ChunJun 中引入了一個新的型別抽象 com.qlangtech.tis.plugin.ds.ColMeta 來封裝 Jdbc MetaData 的列資訊，在具體執行過程中可以更加細膩地控制 Flink 內部的列型別。

 public interface RawTypeConverter {   
   DataType apply(ColMeta type);
	 } 
	public class ColMeta implements Serializable {public final String name;public final DataType type;public final boolean pk;public ColMeta(String name, DataType type, boolean pk) {    this.name = name;    this.type = type;    this.pk = pk;
}//...}public class DataType implements Serializable { 
public final int type;public final int columnSize;public final String typeName;// decimal 的小數位長度private Integer decimalDigits;public DataType(int type, String typeName, int columnSize) {    this.type = type;    this.columnSize = columnSize;    this.typeName = typeName;
}/**
 * is UNSIGNED
 */public boolean isUnsigned() {  //...  } 
 }

取代基於 JSON 配置驅動的任務變為基於後設資料模型驅動任務

有了 TIS 底層後設資料關係管理的支援，資料同步任務定義的大部分工作可以自動生成，使用者只需要做一些輔助工作，例如，使用者需要匯入一個張表，表有 10 列，使用者需要做的是輔助確認：對於 Source 端確認表主鍵，Polling 策略的輪詢間隔時間及輪詢列名，對於 Sink 端選取 Insert 的插入策略，這些都只需要點選滑鼠就能完成，頁面 UI 中的顯示邏輯和 ChunJun 的規則相一致。

 

為 ChunJun 新增新的 TIS 擴充套件點

想要在 v3.6.0 版本順利地將 ChunJun Connector 整合進 TIS，需要新增兩個功能擴充套件點，一是為增量 Source 端表的屬性設定 com.qlangtech.tis.plugins.incr.flink.chunjun.source.SelectedTabPropsExtends，二是為 Sink 端表的屬性設定 com.qlangtech.tis.plugins.incr.flink.chunjun.sink.SinkTabPropsExtends

五、開源共建，繁榮生態

TIS 的構建理念是堅決避免重複造輪子，必須站在行業的巨人的肩膀上，做大資料行業中優秀工具棧的粘合劑。TIS V3.6.0alpha 有幸能按時釋出，得益於行業中有像 ChunJun、DataX、Flink-CDC、Flink 這樣優秀的開源專案存在 ，使得 TIS 整體可靠性得到保障。特別要感謝 Apache Flink，提供了一個強大的實時計算生態，Flink CDC、ChunJun 和 TIS 都是生長在這個生態中的茁壯成長的小樹苗，每個專案都專注於自己擅長的領域，且相互補充。

臨近釋出，發現一個很有意思的使用場景，那就是使用者可以選擇基於 Flink-CDC 的 MySQL Source 外掛來監聽 MySQL 表的增量變更，將資料同步到以 ChunJun 構建的 Sink 中去，這樣的混搭使用方式給使用者帶來了更多的選擇自由度，也避免了在 Flink-CDC 和 ChunJun 各自的框架內部重複造輪子從而造成生態內卷。

六、擁抱 CloudNative

雲原生（CloudNative）時代的到來為我們描繪了一副美好的畫卷，對於終端使用者來說提供了低成本、可靠的 IT 基礎服務，可以專注於業務開發，這非常好。

但對於網際網路技術從業者來說，似乎有隱憂，那就是網際網路紅利將會被阿里雲這樣的雲廠商通吃，小廠商只有乾瞪眼的份，那我們煞費苦心構建的像 TIS 這樣的開源專案在雲時代還有用武之地嗎？其實這樣的擔心是多餘的。

一個健康的生態，必須要保證生物多樣性，生態中各個物種並不是獨立，他們之間存在相互依存的關係。同樣在大資料生態中如果只有像阿里雲、亞馬遜這樣網際網路大廠活得很滋潤，並且構成了一個人才黑洞，把其他小廠的資源全部吸乾了，想必這樣的生態也不可能長遠。

從本質來說，促成任何個人或組織之間的合作都有一個前提，那就是存在比較優勢，就如同瞎子背瘸子相互協助前行，國家之間的合作也是，中國具有廉價勞動力和廣闊的市場與已開發國家的技術優勢進行互補，這種合作是可持續的。

雲大廠可以把昂貴的網際網路基礎設定，用集約化採購的規模優勢大大地降低成本，然後用技術手段將這些裝置雲化成 IAAS 服務提供給客戶，小廠技術具有靈活高效與較低的技術人員薪資成本優勢，以這種優勢在 IAAS 之上構建 PAAS 服務，類似任務排程，實時數倉非常合適。國外也已經有成功的案例，比如 Snowflake 提供的雲原生實時數倉和亞馬遜等雲廠商之間的合作，有同學肯定會問："為啥亞馬遜不能自己搞一個像 snowflake 呢？"，其實答案前面已經提到。

想了解更多有關袋鼠雲大資料產品、行業解決方案、客戶案例的朋友，瀏覽袋鼠雲官網：https://www.dtstack.com/?src=szitpub

新增【小袋鼠：dtstack001】入qun，免費獲取大資料&開源乾貨