TIS整合ChunJun實操

B站視頻：

https://www.bilibili.com/video/BV1QM411z7w5/?spm_id_from=333.999.0.0

一、ChunJun 概述

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

目前的核心功能包括：

· 多源異構數據匯聚

作為一個開放式系統，用戶可以根據需要開發新的插件，接入新的資料庫類型，也可以使用內置的資料庫插件。目前相容30+異構數據源的數據讀寫與SQL計算。

· 斷點續傳

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

· 數據還原

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

· 臟數據管理

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

· 速率控制

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

更多詳見：

Github：https://github.com/DTStack/chunjun

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

官網：https://dtstack.github.io/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的最新版本：

https://github.com/qlangtech/tis/releases/tag/v3.6.0-alpha

早在 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=szbky

添加【小袋鼠：dtstack001】入qun，免費獲取大數據&開源乾貨

同時，歡迎對大數據開源項目有興趣的同學加入「袋鼠雲開源框架釘釘技術qun」，交流最新開源技術信息，qun號碼：30537511，項目地址：https://github.com/DTStack