ACDC 是什么？

ACDC 的由來

新東方的一些核心業(yè)務(wù)存在單元寫、中心入倉的場(chǎng)景，因此需要將數(shù)據(jù)從各單元的關(guān)系型數(shù)據(jù)庫同步到中心，并異構(gòu)存儲(chǔ)到數(shù)據(jù)倉庫之中。

技術(shù)團(tuán)隊(duì)最初使用 Apache Sqoop 以批的方式實(shí)現(xiàn)了這個(gè)能力。隨著數(shù)據(jù)量的增長，這個(gè)方案很快暴露出了一些問題，如：

1. 為了不影響業(yè)務(wù)，同步數(shù)據(jù)只能在夜間進(jìn)行，制約了報(bào)表的時(shí)效性
2. 數(shù)據(jù)的同步周期隨著數(shù)據(jù)量增長而增長

這時(shí)，大數(shù)據(jù)團(tuán)隊(duì)引入了 kafka connect 技術(shù)棧，并結(jié)合 Canal、SQLServer CT 等工具，實(shí)現(xiàn)了從批到流的轉(zhuǎn)變，從而有效解決了以上問題。

這時(shí)的數(shù)據(jù)同步仍是以工具的形態(tài)存在，隨著同步鏈路的數(shù)量不斷增長，又暴露出了一些新的問題，如：

1. 核心服務(wù)不具備跨主機(jī)可用性
2. 無 DevOps 手段，需要專屬團(tuán)隊(duì)統(tǒng)一運(yùn)維，邊際成本較高且效率較低
3. 血緣關(guān)系只能依靠文檔記錄，數(shù)據(jù)溯源的成本隨著時(shí)間推移而提升
4. 隨著租戶身份不斷增多，需要精細(xì)的監(jiān)控、告警手段
5. 缺乏數(shù)據(jù)權(quán)限管理手段，仍需借助 OA 等外部系統(tǒng)

因此，新東方集團(tuán)架構(gòu)部決定以平臺(tái)化方式解決上述問題，并將此產(chǎn)品逐漸演進(jìn)為完整的數(shù)據(jù)中臺(tái)解決方案，這個(gè)產(chǎn)品就是 ACDC。

ACDC 簡(jiǎn)介

ACDC：A Change Data Capture，是新東方集團(tuán)架構(gòu)部開源的數(shù)據(jù)平臺(tái)產(chǎn)品，其目標(biāo)是成為一個(gè)完整的數(shù)據(jù)集成、服務(wù)解決方案，為大數(shù)據(jù)團(tuán)隊(duì)和技術(shù)團(tuán)隊(duì)提供以下 DevOps 能力：

1. 端到端全量、增量數(shù)據(jù)同步
2. 數(shù)據(jù)聚合、轉(zhuǎn)換
3. 數(shù)據(jù)接口
4. 可觀測(cè)性

目前 ACDC 在新東方內(nèi)部承載了 1000+ 的實(shí)時(shí)數(shù)據(jù)同步鏈路，仍在穩(wěn)定增長中。

項(xiàng)目地址：https://github.com/xdfdotcn/acdc

使用方式

ACDC 的設(shè)計(jì)目標(biāo)是以 DevOps 的方式為技術(shù)團(tuán)隊(duì)提供數(shù)據(jù)能力，因此所有操作都以多租戶、白屏化進(jìn)行。

角色

在介紹使用方式前，我們先了解下 ACDC 上定義的幾種角色：

1. 平臺(tái)管理員：主要維護(hù)平臺(tái)運(yùn)行環(huán)境級(jí)別的元數(shù)據(jù)，如 kafka 集群等
2. DBA：數(shù)據(jù)系統(tǒng)負(fù)責(zé)人，主要維護(hù)鏈路級(jí)別元數(shù)據(jù)，如項(xiàng)目信息、數(shù)據(jù)系統(tǒng)信息等
3. 技術(shù)團(tuán)隊(duì)負(fù)責(zé)人：數(shù)據(jù)源負(fù)責(zé)人，主要進(jìn)行鏈路審批操作
4. 技術(shù)團(tuán)隊(duì)成員：ACDC 主要使用者，進(jìn)行鏈路的生命周期管理，如鏈路創(chuàng)建、鏈路編輯等

創(chuàng)建實(shí)時(shí)增量數(shù)據(jù)同步鏈路

目前 ACDC 主要實(shí)現(xiàn)了部分?jǐn)?shù)據(jù)源的實(shí)時(shí)同步能力，經(jīng)過選取數(shù)據(jù)源、選取數(shù)據(jù)目標(biāo)、字段匹配規(guī)則編輯等幾個(gè)步驟后，即可完成鏈路的創(chuàng)建

選取數(shù)據(jù)源

選取數(shù)據(jù)目標(biāo)

字段匹配規(guī)則配置

鏈路維護(hù)

使用場(chǎng)景

單元寫，中心入倉

由于新東方的業(yè)務(wù)特點(diǎn)，全國地面學(xué)校的數(shù)據(jù)都存儲(chǔ)在各自的單元中。在這樣的場(chǎng)景中，數(shù)據(jù)匯總到中心就成為了各類數(shù)據(jù)報(bào)表的前提。

另外，匯總后的數(shù)據(jù)需要來源標(biāo)識(shí)字段，這是單元數(shù)據(jù)中所不具備的，由 ACDC 在同步時(shí)填充。

輕聚合業(yè)務(wù)

一些系統(tǒng)存在輕度聚合的業(yè)務(wù)場(chǎng)景（如清結(jié)算，財(cái)務(wù)等），聚合所需的數(shù)據(jù)源往往來自多個(gè)三方系統(tǒng)。

這類數(shù)據(jù)因?yàn)榱考?jí)較大、沒有明確查詢邊界等原因，不適合使用常規(guī) API 的方式實(shí)現(xiàn)，更適合通過 ACDC 的數(shù)據(jù)鏈路方式同步數(shù)據(jù)。

例如：在清結(jié)算業(yè)務(wù)中，需要根據(jù)教務(wù)系統(tǒng)、報(bào)名系統(tǒng)、行課中心等系統(tǒng)中的流水?dāng)?shù)據(jù)計(jì)算機(jī)構(gòu)間的資金劃接。這些數(shù)據(jù)種類繁雜，沒有明確的查詢邊界。并且所需的數(shù)據(jù)可能會(huì)因?yàn)橛?jì)算規(guī)則的調(diào)整而調(diào)整，因此若以傳統(tǒng) API 方式實(shí)現(xiàn)成本較高、周期較長。

基于數(shù)據(jù)的事件通知

很多業(yè)務(wù)系統(tǒng)之間使用了基于消息的異步處理方式實(shí)現(xiàn)解耦。在很多場(chǎng)景中，這里的消息可以理解為某種領(lǐng)域模型的變更事件。相比業(yè)務(wù)代碼自行產(chǎn)生事件的方式，通過 ACDC 基于 binlog 捕獲各類數(shù)據(jù)事件的方式更加靈活，成本也更低。

數(shù)據(jù)異構(gòu)

在一些較為復(fù)雜的查詢場(chǎng)景下，我們通常會(huì)使用如 ElasticSearch 等 OLAP 型數(shù)據(jù)系統(tǒng)提升查詢性能。因此，我們需要將數(shù)據(jù)從其他數(shù)據(jù)源中同步過來。

技術(shù)團(tuán)隊(duì)通過自行部署 Canal 等服務(wù)可以實(shí)現(xiàn)數(shù)據(jù)的實(shí)時(shí)同步，但這顯然增加了技術(shù)團(tuán)隊(duì)的日常運(yùn)維成本：Canal 的服務(wù)可靠性和數(shù)據(jù)可靠性。為了解決這 2 個(gè)問題，很多技術(shù)團(tuán)隊(duì)甚至還額外開發(fā)了數(shù)據(jù)對(duì)比工具和修復(fù)工具，也是無奈之舉。

數(shù)據(jù)孤島間的數(shù)據(jù)拷貝

在企業(yè)發(fā)展過程中，因?yàn)樵缙诘臒焽枋綀F(tuán)隊(duì)組織和開發(fā)模式，數(shù)據(jù)往往不互通，但不同團(tuán)隊(duì)間又有使用其他團(tuán)隊(duì)數(shù)據(jù)的業(yè)務(wù)需求，這時(shí)候使用數(shù)據(jù)拷貝往往是較為節(jié)約成本的方式。

同一個(gè)數(shù)據(jù)集被同步到多個(gè)下游數(shù)據(jù)系統(tǒng)中

在實(shí)際生產(chǎn)中，難免會(huì)出現(xiàn)同一個(gè)源數(shù)據(jù)集被同步到多個(gè)目標(biāo)數(shù)據(jù)集中的情況：例如用戶中心的數(shù)據(jù)，會(huì)同步到大數(shù)據(jù)團(tuán)隊(duì)的數(shù)倉中，也會(huì)被同步到 ES 中用于加速搜索。

ACDC 通過 kafka 做數(shù)據(jù)緩沖，只需要抽取一次數(shù)據(jù)，便可以同步到多個(gè)目標(biāo)數(shù)據(jù)集中。這樣做可以節(jié)約上游數(shù)據(jù)系統(tǒng)的性能開銷，不會(huì)隨著目標(biāo)數(shù)據(jù)集的數(shù)量增加而加大，從宏觀看是一種降本增效的行為。

術(shù)語表

source

數(shù)據(jù)源，產(chǎn)生數(shù)據(jù)事件的數(shù)據(jù)系統(tǒng)

sink

數(shù)據(jù)目標(biāo)，存儲(chǔ)數(shù)據(jù)事件的數(shù)據(jù)系統(tǒng)

connect worker

kafka connect 實(shí)例，一個(gè) jvm 進(jìn)程

connect cluster

工作在 connect distributed 模式下的 connect worker 組成的集群，是 connector 的運(yùn)行時(shí)環(huán)境。同一個(gè)集群中的 connector 以及因此產(chǎn)生的 task 會(huì)調(diào)度到不同 connect worker 中

connector

代表一個(gè)同步鏈路，運(yùn)行在 connect woker、connect cluster 中。被創(chuàng)建后將會(huì)產(chǎn)生若干 task 執(zhí)行實(shí)際的同步鏈路任務(wù)。

根據(jù)在鏈路中所處的位置不同，又分為 source connector 以及 sink connector

source connector

負(fù)責(zé)將數(shù)據(jù)事件從數(shù)據(jù)源寫入到 kafka 中，以供后續(xù)的處理環(huán)節(jié)消費(fèi)

sink connector

負(fù)責(zé)將 kafka 中的數(shù)據(jù)寫入到目標(biāo)數(shù)據(jù)系統(tǒng)中，kafka 中的數(shù)據(jù)通常是由 source connector 所生產(chǎn)

task

工作在 connect worker 進(jìn)程中，執(zhí)行實(shí)際同步任務(wù)的線程

在 connector 被創(chuàng)建后，connect worker 會(huì)根據(jù)其配置啟動(dòng)相應(yīng)數(shù)量的 task 線程

架構(gòu)設(shè)計(jì)

從宏觀看，ACDC 目前分為控制面和數(shù)據(jù)面兩部分?？刂泼嬷饕磉_(dá)用戶意圖，數(shù)據(jù)面主要實(shí)現(xiàn)數(shù)據(jù)同步。

在這種模式下，性能瓶頸往往發(fā)生在數(shù)據(jù)面。又由于項(xiàng)目的定位是平臺(tái)型產(chǎn)品，需要考慮到較大規(guī)模的應(yīng)用場(chǎng)景，因此我們對(duì)數(shù)據(jù)面設(shè)計(jì)的基本要求之一就是各組件可水平擴(kuò)容。

另外，我們認(rèn)為這種控制面、數(shù)據(jù)面分離的設(shè)計(jì)模式很適合采用聲明式編程，因此我們使用這種范型實(shí)現(xiàn)了 DevOps 模塊。

模塊拓?fù)?/h3>

ACDC 目前的主要模塊包括：

1. 控制面
   1. UI
   2. API
   3. Controller
2. 數(shù)據(jù)面
   1. Kafka Connector
   2. Kafka Connect Cluster
   3. AVRO Schema Registry
   4. Kafka Cluster

數(shù)據(jù)同步

ACDC 的增量數(shù)據(jù)同步基于 kafka connect 實(shí)現(xiàn)，對(duì)比 flinkCDC 等內(nèi)存式數(shù)據(jù)同步流，具備以下優(yōu)點(diǎn)：

1. 對(duì)上游數(shù)據(jù)系統(tǒng)的性能影響更?。阂淮纬槿?，多次使用
2. 更精準(zhǔn)的運(yùn)維手段：調(diào)整某個(gè) sink connector 的消費(fèi)點(diǎn)位，不會(huì)影響其他 sink connector

被 kafka cluster 解耦后，source connector 與 sink connector、sink connector 與 sink connector 之間不會(huì)互相影響。

隨著鏈路數(shù)量的增長，以上拓?fù)渲械?connect worker、kafka 容易成為性能瓶頸。短期內(nèi)我們可以通過水平擴(kuò)展增加這些集群的承載能力，但長期來看負(fù)載需求總量可能大于單集群的上限（我們?cè)趯?shí)際生產(chǎn)中發(fā)現(xiàn)：當(dāng)單 connect cluster 中的 task 數(shù)量超過 1000 時(shí)，集群的故障恢復(fù)時(shí)間會(huì)明顯加長）。所以我們?cè)?ACDC 中增加了集群路由能力，使數(shù)據(jù)面的吞吐量水平擴(kuò)展能力大大提升。

目前 ACDC 支持 MySQL、TiDB 作為數(shù)據(jù)源，Hive、MySQL、Oracle、Kafka、TiDB、SQLServer 作為數(shù)據(jù)目標(biāo)。依托 kafka connect 強(qiáng)大的生態(tài)，未來我們將會(huì)支持更多的數(shù)據(jù)系統(tǒng)，包括開源、商業(yè)數(shù)據(jù)系統(tǒng)。

DevOps

DevOps 是 ACDC 的控制面，采用命令式編程范性實(shí)現(xiàn)，核心是 ACDC API 以及 ACDC controller。

這里我們借鑒了 k8s 的模塊設(shè)計(jì)，上述兩個(gè)模塊分別與 apiserver、controller-manager 對(duì)等。熟悉 k8s 的同學(xué)一定知道，API 模塊主要完成用戶意圖的表達(dá)，controller 模塊則主要完成用戶意圖的實(shí)現(xiàn)：數(shù)據(jù)鏈路的生命周期管理。

雖然帶來了一些新的開發(fā)成本，但我們還是很明顯的體會(huì)到了聲明式編程帶來的收益：更低的模塊間耦合性，更高的擴(kuò)展性。

可以簡(jiǎn)單的總結(jié)為：大多數(shù)用戶操作周期與實(shí)際運(yùn)算周期不同的業(yè)務(wù)，都適合采用這種開發(fā)范型。

服務(wù)可靠性

服務(wù)可靠性主要體現(xiàn)在數(shù)據(jù)面，依托 kafka connect distributed 模式、kafka 集群天然的跨進(jìn)程故障恢復(fù)能力，ACDC 數(shù)據(jù)面具備整體的可靠性保障。

kafka 的可靠性原理相信大家已經(jīng)很熟悉了，這里就不再過多介紹。

而 kafka connect distributed 模式主要基于 kafka 的 Coordinator 機(jī)制以及相應(yīng)的 Group Management Protocol。在 kafka consumer 的場(chǎng)景中，被協(xié)調(diào)的資源是 partition 的消費(fèi)機(jī)會(huì)。而在 connect 場(chǎng)景中，被協(xié)調(diào)的資源主要是執(zhí)行同步鏈路的機(jī)會(huì)。

上圖的 worker 代表集群中的每個(gè) connect 進(jìn)程，task 代表執(zhí)行數(shù)據(jù)同步的線程。

當(dāng)某個(gè) worker 故障后，會(huì)觸發(fā) task 的重新分配，之前分配給故障節(jié)點(diǎn)的 task 會(huì)重新分配給其他健康節(jié)點(diǎn)，由此實(shí)現(xiàn)跨進(jìn)程故障轉(zhuǎn)移。kafka connect 與 kafka consumer 的故障轉(zhuǎn)移都是 Coordinator 機(jī)制所提供的能力。

數(shù)據(jù)可靠性

數(shù)據(jù)可靠性是數(shù)據(jù)鏈路服務(wù)最重要的基礎(chǔ)之一，是我們優(yōu)先級(jí)最高的實(shí)現(xiàn)目標(biāo)：每條數(shù)據(jù)鏈路都至少包含 4～5 個(gè)服務(wù)節(jié)點(diǎn)（數(shù)據(jù)源數(shù)據(jù)系統(tǒng)、source connector、kafka、sink connector、目標(biāo)數(shù)據(jù)系統(tǒng)），任何一個(gè)節(jié)點(diǎn)都可能會(huì)丟失數(shù)據(jù)事件，并且故障定位成本很高。

流式處理常用“至少一次"，”精準(zhǔn)一次“來描述數(shù)據(jù)的準(zhǔn)確等級(jí)，ACDC 滿足”至少一次“的可靠性要求。我們認(rèn)為在數(shù)據(jù)鏈路領(lǐng)域，”至少一次“可滿足絕大多數(shù)應(yīng)用的需求，并且這樣可以降低一定實(shí)現(xiàn)成本。

source connector 的數(shù)據(jù)可靠性

source connector 的主要任務(wù)是將數(shù)據(jù)從源系統(tǒng)中提取出來，將付給 connect 框架，并最終寫入到 kafka 集群中，供 sink connector 消費(fèi)。

所以在 source connector 中，我們主要完成 2 個(gè)數(shù)據(jù)傳遞動(dòng)作（數(shù)據(jù)內(nèi)容處理，協(xié)議轉(zhuǎn)換這里暫不展開）：

1. 通過上游數(shù)據(jù)系統(tǒng)的客戶端提取數(shù)據(jù)事件（ACDC 主要基于 binlog 方式）
2. 將數(shù)據(jù)事件交付給 kafka connect 框架

在這個(gè)場(chǎng)景中，保證“至少一次”也可以拆分為以下 3 個(gè)具體要求：

1. 記錄 source connector 對(duì)于上游數(shù)據(jù)系統(tǒng)的處理進(jìn)度（例如 MySQL 的 binlog position）
2. source connector task 重啟后可以讀取到最新進(jìn)度，并從這個(gè)進(jìn)度開始繼續(xù)產(chǎn)生數(shù)據(jù)事件
3. 進(jìn)度在被記錄前，要確保被發(fā)送到了下游 kafka 集群

依托于 kafka connect 框架，我們可以通過實(shí)現(xiàn) source connector task 接口中的若干方法達(dá)到以上要求。

例如，下面的方法會(huì)在 kafka connect 通過 kafka producer 生產(chǎn)消息成功后被回調(diào)，實(shí)現(xiàn)這個(gè)方法即可滿足上述第 3 點(diǎn)要求。

public abstract class SourceTask implements Task {

    /**
     * <p>
     * Commit an individual {@link SourceRecord} when the callback from the producer client is received. This method is
     * also called when a record is filtered by a transformation, and thus will never be ACK'd by a broker. In this case
     * {@code metadata} will be null.
     * </p>
     * <p>
     * SourceTasks are not required to implement this functionality; Kafka Connect will record offsets
     * automatically. This hook is provided for systems that also need to store offsets internally
     * in their own system.
     * </p>
     * <p>
     * The default implementation just calls {@link #commitRecord(SourceRecord)}, which is a nop by default. It is
     * not necessary to implement both methods.
     * </p>
     *
     * @param record {@link SourceRecord} that was successfully sent via the producer or filtered by a transformation
     * @param metadata {@link RecordMetadata} record metadata returned from the broker, or null if the record was filtered
     * @throws InterruptedException
     */
    public void commitRecord(SourceRecord record, RecordMetadata metadata)
            throws InterruptedException {
        // by default, just call other method for backwards compatibility
        commitRecord(record);
    }
}

sink connetor 的數(shù)據(jù)可靠性

sink connector 的工作方式和一個(gè)常規(guī)的 kafka client 類似：

1. 從 broker 拉取消息
2. 完成消息處理事務(wù)
3. 提交已處理的消息的 offset 至 broker

所以要滿足“至少一次”，只需要在提交了處理消息的事務(wù)后再提交偏移量即可，這與 kafka client 的日常使用類似，不再過多展開。

值得一提的是，若只是簡(jiǎn)單按上述方式實(shí)現(xiàn) sink connector，可能會(huì)由于串行的處理方式影響性能。因此，ACDC 對(duì)上述流程進(jìn)行了優(yōu)化：在保證了可靠性的基礎(chǔ)上，通過異步的方式提升了一定的性能。這部分內(nèi)容將在后續(xù)的文章中繼續(xù)展開討論。

可擴(kuò)展性

在 ACDC 領(lǐng)域，可擴(kuò)展性分為兩個(gè)部分：

1. DevOps
2. 數(shù)據(jù)鏈路

數(shù)據(jù)鏈路的可擴(kuò)展性

由于 ACDC 基于 kafka connect 框架，因此天然就具備其所包含的良好的可插拔式的擴(kuò)展方式。這些可擴(kuò)展點(diǎn)包括：

1. source、sink connector 支持的數(shù)據(jù)系統(tǒng)：對(duì)應(yīng) ETL 中的 E 和 L
2. Converter 插件實(shí)現(xiàn)消息的序列化：這對(duì)于自行消費(fèi)數(shù)據(jù)事件的用戶很有幫助
3. Transformer 插件實(shí)現(xiàn)消息內(nèi)容轉(zhuǎn)換：對(duì)應(yīng) ETL 中的 T

ACDC 也實(shí)現(xiàn)了一些自己的 Transformer、Converter，這些擴(kuò)展既可以與 ACDC 一起工作，也可以單獨(dú)與 kafka connect 工作。

DevOps 模塊的可擴(kuò)展性

前文提到 ACDC DevOps 模塊采用聲明式編程的開發(fā)范型，這種范型比較明顯的一個(gè)受益就是：模塊間的耦合度極低，低到幾乎只有存儲(chǔ)元數(shù)據(jù)的數(shù)據(jù)服務(wù)。這里講的模塊不單指項(xiàng)目中的 module，粒度可以細(xì)到單個(gè)領(lǐng)域模型。

舉例來講，ACDC 中鏈路相關(guān)的最重要的領(lǐng)域模型是 Connection，他負(fù)責(zé)描述用戶創(chuàng)建的鏈路。在用戶創(chuàng)建鏈路時(shí)，模塊間的大致處理流程如下：

文字版

1. ACDC 的 API 模塊負(fù)責(zé)檢驗(yàn)用戶通過 UI 提交的數(shù)據(jù)，并保存至 ACDC 原數(shù)據(jù)存儲(chǔ)服務(wù)中（目前是 MySQL）
2. Connection 模型具備預(yù)期、實(shí)際兩個(gè)狀態(tài)，代表用戶的預(yù)期狀態(tài)和鏈路的實(shí)際狀態(tài)。此時(shí)兩個(gè)狀態(tài)都是 stopped
3. 用戶啟動(dòng)鏈路，API 將 connection 的預(yù)期狀態(tài)改為 running
4. ACDC 的 Connection Controller 模塊通過 Informer 機(jī)制 watch 到有新的 Connection 創(chuàng)建，并且預(yù)期狀態(tài)域?qū)嶋H狀態(tài)不一致后（running : stopped），根據(jù) Connection 創(chuàng)建 Connector 模型的兩個(gè)實(shí)例： source connector、sink connector，并將 Connection 的實(shí)際狀態(tài)更改為 starting
5. Connector Controller 模塊 watch 到新的實(shí)例后，通過 kafka connect REST API 完成實(shí)際的創(chuàng)建動(dòng)作，并將 Connector 的實(shí)際狀態(tài)改為 starting
6. Connector Controller 模塊 watch 到 kafka connect 集群中存在了剛創(chuàng)建的 connector 實(shí)例，并且狀態(tài)為 running 后，將 Connector 的實(shí)際狀態(tài)更改為 running
7. Connection Controller watch 到剛創(chuàng)建的 Connection 相關(guān)的兩個(gè) Connector 實(shí)際狀態(tài)都是 running 后，將 Connection 的實(shí)際狀態(tài)改為 running

時(shí)序圖版

至此，用戶可以在 UI 上看到剛剛創(chuàng)建的鏈路狀態(tài)已經(jīng)更改為 running。

在上述業(yè)務(wù)流程中，API、Connection Controller、Connector Controller 間的耦合只有存儲(chǔ) ACDC 元數(shù)據(jù)的 MySQL。這樣除了降低系統(tǒng)復(fù)雜度外，也十分便于擴(kuò)展。

一個(gè)例子

試想我們現(xiàn)在需要增加一個(gè)新功能：新表自動(dòng)入倉。

要實(shí)現(xiàn)這個(gè)功能，我們需要掃描某個(gè)數(shù)據(jù)源 database 中的表，并在發(fā)現(xiàn)新表時(shí)建立對(duì)應(yīng)的 Connection 即可。

在聲明式開發(fā)范型下，我們只需要再增加一個(gè)類似 AutoConnection 的模型，以及相關(guān) Controller。在用戶創(chuàng)建了這個(gè)模型的實(shí)例后，Controller 就會(huì) watch 目標(biāo) database 中的 table，并在發(fā)現(xiàn) table 后創(chuàng)建對(duì)應(yīng)的 Connection 實(shí)例，即可實(shí)現(xiàn)這個(gè)功能。

在實(shí)現(xiàn)過程中，不需要對(duì)原先的邏輯做任何改動(dòng)，即沒有耦合存在。

可觀測(cè)性

ACDC 的可觀測(cè)性基于 Prometheus 生態(tài)，這也是云原生的可觀測(cè)性標(biāo)準(zhǔn)設(shè)施。

目前大部分模塊都暴露了 metrics 接口，當(dāng)前的指標(biāo)主要體現(xiàn)了健康狀態(tài)以及性能狀態(tài)，未來我們會(huì)繼續(xù)完善各類業(yè)務(wù)指標(biāo)。

我們根據(jù)租戶類型、數(shù)據(jù)系統(tǒng)的維度繪制了 5 類監(jiān)控看板，可覆蓋平臺(tái)各類用戶的可觀測(cè)關(guān)注點(diǎn)。

平臺(tái)管理人員

在宏觀方面，運(yùn)維人員重點(diǎn)關(guān)注全部鏈路的健康情況，性能情況，各組件、集群資源使用情況

在微觀方面，運(yùn)維人員重點(diǎn)關(guān)注某個(gè) sink connector 的 task 調(diào)度、所在 connect worker 的 JVM、source connector 的性能情況等等

技術(shù)團(tuán)隊(duì)成員

技術(shù)團(tuán)隊(duì)成員是數(shù)據(jù)鏈路的創(chuàng)建者，主要關(guān)注某鏈路的工作狀態(tài)、延遲情況等

MySQL Source

TIDC Source

現(xiàn)狀與 roadmap 規(guī)劃

就像文章開篇介紹的，ACDC 的產(chǎn)品定位是 DevOps 形式的數(shù)據(jù)中臺(tái)產(chǎn)品，他將具備：

1. 端到端增量數(shù)據(jù)同步
2. 端到端全量數(shù)據(jù)同步
3. 數(shù)據(jù)聚合、轉(zhuǎn)換能力
4. 數(shù)據(jù)服務(wù)能力

目前我們還處于起步階段：具備了一些數(shù)據(jù)系統(tǒng)間的增量數(shù)據(jù)同步能力。下一個(gè)階段我們將會(huì)支持更多的數(shù)據(jù)系統(tǒng)種類，并且增加全量同步能力。

數(shù)據(jù)處理方面，主要是針對(duì)數(shù)據(jù)提供一些加工、聚合能力，例如數(shù)據(jù)變換，數(shù)據(jù)過濾，數(shù)據(jù)維度打?qū)挼取＿@在同步到 OLAP 型數(shù)據(jù)系統(tǒng)的場(chǎng)景中很常見。

數(shù)據(jù)服務(wù)方面，主要是將數(shù)據(jù)同步、處理的結(jié)果提供 REST 等訪問方式。

彩蛋：努力成為像 AC/DC 一樣偉大的旗幟

相信熱愛搖滾樂的同學(xué)一定會(huì)像我一樣，對(duì) AC/DC 這四個(gè)字母有著深深的崇敬。

為產(chǎn)品賦予這樣的名字，除了開篇提到的字面語意外，也是我們團(tuán)隊(duì)向這支偉大的搖滾樂隊(duì)表達(dá)敬意的一種方式。

同時(shí)也在時(shí)刻提醒自己：要向著偉大不斷前行，永遠(yuǎn)純粹和熱情。文章來源地址http://www.zghlxwxcb.cn/news/detail-415098.html

到了這里，關(guān)于ACDC：開箱即用的多租戶數(shù)據(jù)集成平臺(tái)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！