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=https://www.cnblogs.com/DTinsight/p/szbky
添加【小袋鼠：dtstack001】入qun，免費獲取大資料&開源干貨
同時，歡迎對大資料開源專案有興趣的同學加入「袋鼠云開源框架釘釘技術qun」，交流最新開源技術資訊，qun號碼：30537511，專案地址：https://github.com/DTStack
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/538876.html
標籤：大數據
上一篇：視圖 觸發器 事務 MVCC 存盤程序 MySQL函式 MySQL流程控制 索引的資料結構 索引失效 慢查詢優化explain 資料庫設計三范式