數據的搬運工——數據集成

大數據平臺并不生產數據，大多數原始數據其實都來源于業務系統，所以，我們需要做好數據“搬運”動作。而這就牽扯到了“數據集成”這個概念。

我不生產數據，我只是數據的搬運工。在大數據平臺中，是不生產數據的，或者說原始數據都是來源于業務系統。所以，我們需要做的第一件事，就是將業務系統的數據搬運到數據平臺。改用那句耳熟能詳的話，我不生產數據，我只是數據的搬運工。這個數據的搬運工，就是數據平臺的第一個模塊——數據集成。

一、搬運工都有哪些稱呼

在進行產品設計的過程中，對于同一個產品，經常會遇到各種各樣的名稱，這些名稱好像可以指代同一個產品，如果細究起來，好像也有些區別。在數據集成產品設計時，也會遇到類似的問題。這些相同的名稱主要是數據集成、數據同步、數據采集。有時候也可能聽到數據管道、數據傳輸等等。

我通過大模型搜索了一下區別。

數據集成：指的是將不同數據源、不同數據類型以及不同格式的數據整合到一起，形成一個統一的數據視圖或數據倉庫，以便后續的分析和處理。數據集成通常涉及到數據的抽取、轉換、清洗和加載等多個步驟，同時也需要解決數據格式轉換、數據質量問題以及數據安全性等問題。數據同步：則是將數據從一個數據源復制或傳輸到另一個數據源，以保持兩個數據源中的數據一致性。數據同步通常涉及到實時或準實時的數據傳輸和復制，可以用于分布式系統中的數據復制、備份以及容災等場景。似乎，數據集成更注重數據的整合和數據處理，而數據同步更注重數據的傳輸和一致性。在大數據領域，數據采集和數據集成是兩個密切相關的概念，但它們在數據處理過程中扮演的角色和目的有所不同。數據采集主要是通過工具或技術，從系統外部獲取數據并輸入到系統內部的過程。它可以是手工的，也可以是自動化的。在這個過程中，獲取的數據可能需要進行清洗、格式轉換等預處理，以便后續的數據集成和使用。數據集成則是將不同來源、不同格式、不同性質的數據在邏輯上或物理上有機地集中起來，形成一個全面、統一的數據視圖或數據倉庫的過程。數據集成通常涉及到數據的抽取、轉換、清洗和加載等多個步驟，它的主要目的是為企業提供全面的數據共享和數據分析能力。

因此，可以說數據采集是數據集成的基礎和前提，數據集成則是數據采集的后續處理和結果。沒有數據采集，數據集成就缺乏數據來源；沒有數據集成，則無法有效利用和管理大數據資產。在這個定義里面數據采集是數據集成之前的一個步驟。個人感覺在實時領域是這樣的，實時獲取到數據的變更相當于數據的采集。

以上都是通過大語言模型給出的結論。對這些名稱有一個基本概念之后，結合實際的公司習慣、部門歷史使用習慣、以及上下文語境來做具體的區分。個人習慣數據集成和數據同步這兩個詞大部分情況下會混用。如果要做區分的話，當有向導式和拖拽式兩種形式的時候。拖拽式的可以稱之為數據集成，因為拖拽式的重數據的轉換和整合。向導式的可以稱之為數據同步，因為向導式的重數據的傳輸和一致性。而數據采集，個人相對混用少些，個人主要理解為將數據庫的變化采集上來。

再次說明，完全是個人角度的劃分。

二、搬運過程中的處理

在進行數據同步的過程中，需不需要進行處理，雖然數據同步常常和**ETL（提取（extract）、轉換（transform）、加載（load））**放在一起做比較，但是實際上是不是需要在同步過程中進行轉換是可以進行商榷的。

1. 一比一同步

同步數據的目的是保留業務的數據歷史，如果要保留歷史那么錯誤的歷史也是歷史。所以這種同步就是完全和業務系統數據一比一的同步，即使同步過來的數據是有異常的或者說不標準的。只有這樣才能真正的如實的保留了業務的歷史，當發生數據異常進行數據追溯的時候，才能夠找到最原始的業務數據。個人認為這個想法很好，能夠完全的保留業務歷史數據。但是有一個問題就是錯誤的數據業務系統可以隨時改的。但是在離線場景下的同步不會隨時進行的。而且感覺這種太極端，對人員，程序要求都比較高。

2. 在同步過程中進行轉換清洗

第二種就顯的要求沒有那么的嚴格，相對寬松些。可以在這個過程中進行行級別的增減、規范化。也可以進行字段的聚合、關聯、轉換等等操作。其實對產品設計來說，支持了這種形式，就支持了一比一的同步。在同步過程中有這個轉換、聚合的能力，不使用的話就是一比一同步了。這樣說來一比一同步更多的似乎是一個規范、一個要求。

三、搬運的目標表類型

將業務數據搬運到數據平臺的目標就是保留歷史、做到數據可追溯。但是業務系統的數據是時時都在變化的，那么怎么保留變化的數據的歷史就是一個目標表建表結構的問題。

這其實算是數據倉庫建模領域的內容，為什么在這里說？先說一下目標表常見的幾種形式。全量表、切片表、拉鏈表。

1. 全量表

全量表和名字一樣，就是數據全量同步到目標端。試用于同步碼表等數據變動不大的表。

2. 切片表

切片表又分為增量切片，和全量切片。全量切片就是將每天的全量業務數據放在當天分區中。增量切片就是僅僅把當天的增量放在當天的分區中。

3. 拉鏈表

拉鏈表式最復雜的。需要有一個唯一鍵，需要知道業務數據是否變化，變化之后，就在目標表中新增一條，記錄變化數據的開始時間、結束時間，有的還會有版本、是否當前狀態等字段（拉鏈表也依賴于同步的時間粒度，細于時間粒度，可能會存在無法將數據同步到目標端情況）。

為什么要在這里說，因為數據集成產品需要在功能上支持這些目標表的建表類型。全量表的全量同步。切片表的增量切片，需要能夠過濾出來每日的增量數據。拉鏈表的復雜邏輯，是否需要進行邏輯固化（我只在Powercenter中看到過拉鏈表的邏輯固化。自己也設計過向導式的拉鏈表邏輯固化）。這些都需要在數據同步過程中考慮到。不僅僅能夠將數據搬運到目標端，而且還需要以一種合理的目標端表結構需要將數據搬運到目標端。

四、搬運的交互形式

在搬運過程中，交互形式一般有三種形式，腳本式、拖拽式、向導式。

1. 腳本式

顧名思義，腳本式就是寫一個腳本來進行數據同步。這種形式更多的是偏技術，在產品設計中一般不會過多涉及。

常見的腳本式同步：

古老的是Sqoop了，他實現了結構化數據和Hadoop之間的批量數據遷移，最初由Apache軟件基金會開發，但是在2016年，該項目已經被終止了。在阿里云Dataworks中的數據集成DataX，也會有的腳本界面的數據同步。是因為有些非結構化的數據源，沒有表結構類型，在腳本界面中能夠更加靈活。

2. 拖拽式

拖拽類的數據集成類產品，就是在一個畫布中拖拽各個算子，組成一個ETL的DAG圖，從而實現數據的同步。

常見的拖拽式的同步：

最有名的算是Informatica Powercenter，這款產品在國外似乎知名度很高，常年在Genter象限的領導這位置。但在國內似乎只有一些銀行、等金融行業使用多些，在互聯網公司更是近乎沒什么聲量。IBM Datastage 一款和powercenter類似的軟件。Kettle一款開源的免費的數據ETL工具。如果有拖拽式的數據同步需求，這三個產品也常常會被拉在一起做比較。各有各的特點吧。

單獨提一句，當使用拖拽式的數據集成時，其實多少有了一些數據開發的性質。但是如果細劃分的話，和拖拽式的數據開發還是有些區別的。這個在《常見的數據開發形式》中的拖拽式數據開發中說下區別。

3. 向導式

向導式的數據集成，主要是指通過輸入框或者選擇配置框，就可以完成任務的創建。不需要寫代碼，也不需要拖拽算子，這種開發形式我定義為向導式。

大部分的云廠商的數據集成/數據同步類產品均是向導式的模式。這里就不過多說了。

五、時效性

個人理解數據集成只分為兩大類，離線數據集成和實時的數據集成。至于全量同步、增量同步等等，只是這兩種大形式下的一種選項。而這兩種形式，又均可以使用腳本式、拖拽式或者向導式來實現。形式不重要，本質是實時還是離線才重要，當然設計頁面的時候也會多少有些配置區別。

在失效性上，實時數據越來越受重視，還有一些批流一體的概念，所以實時的數據集成需求也越來越多。

但是個人不認為離線的數據集成會被完全干掉。一方面——成本，顯然實時的成本要比離線的成本要高。一方面——技術，實時集成之后一系列的技術和離線集成是完全不同的，現有的技術架構不一定都做好了準備。

還有一方面就是歷史習慣，以上面介紹為例，切片表、拉鏈表等等均是離線場景下的，在后續介紹中會發現有大量的概念在離線場景下很順暢，但是往往會自動的忽略實時場景。這可能也是因為實時的歷史相對較短。在其他概念出現的時候，并沒有考慮實時的場景。

六、支持的數據源類型

數據集成支持的數據源多少是一個平臺能力的體現，支持的越多，可以理解為能力越強。不同數據源可能支持實時的形式、可能支持離線形式，也可能兩種均支持。數據源大類上也有不同的劃分：關系型數據庫、大數據存儲、消息隊列、文本文件等等。

這是從類型上劃分，如果從接入數據源之后的操作上來分，就兩類：有表結構的和沒有表結構的。

1. 有表結構

有表結構的可以是關系型數據庫、HIVE、Doris等等這類本身有表結構的。也可以是固定格式的文本、JSON這類可以賦予一個固定scheam的，這類需要進行數據平臺有元數據管理能力，在《當我們談元數據的時候，我們在談什么》中會介紹這一部分。這類有表結構的在交互時，以二維表格的形式在向導、或者拖拽中進行交互了。

2. 沒有表結構

沒有表結構的相對會復雜些，有時候可以強制給這種沒有表結構的授予一個表結構。有的時候也只能轉換成腳本的形式來實現映射。這個具體數據源具體分析了。

數據源支持多少體現能力強弱。同樣，作為產品每種數據源可能都有其自身的特性，也需要進行個性化的設計，而產品經理又會將各種類型的數據源都熟悉到，個人感覺也是數據集成類產品設計的一個麻煩的點。

至于各種非結構化的文檔、圖片、音視頻等等。都不在大數據平臺這個范疇內。之前也會提非結構化的大數據平臺，非結構化的大數據治理。但是目前個人沒有接觸到特別好的產品。