開源共建 | TIS整合資料同步工具ChunJun，攜手完善開源生態
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