陳雷 | DataPipeline 合夥人 & CPO，曾任 IBM 大中華區認知物聯網實驗室服務部首席資料科學家、資深顧問經理。十五年資料科學領域與金融領域經驗。綜合交通大資料應用技術國家工程實驗室產業創新部主任，中國電子學會區塊鏈專委會委員。

DataPipeline是一家資料領域的獨立軟體提供商。已成功服務了包括但不限於星巴克、百勝中國、民生銀行、中國人壽等重點領域的近百家客戶。

10 月 20 日，IT 桔子邀請到DataPipeline合夥人 & CPO 陳雷先生，面向 IT 桔子使用者帶來 “企業實時資料管理問題與實踐” 為主題的分享，以下為本次活動的乾貨觀點。（文末附 PPT 下載地址）

為什麼要構建實時資料平臺

2000 年左右甚至更高一些，我們的交易系統和分析系統是不分家的。隨著業務需求的不斷提升，對7*24 小時聯機交易的要求，交易系統服務壓力越來越大。為了避免分析系統影響交易系統，逐漸從業務系統中分離出了分析系統，OLTP（聯機事務處理）和 OLAP（聯機分析處理） 兩類系統概念就此產生。同時產生了兩個概念，一個是ODS（把交易系統裡的全部原始資料複製一份出來，然後在ODS上做各種加工、處理與分析）；另外一個Data Mart（資料集市，按照業務實際需求要把要分析的部分資料從交易系統中取出來做整理）。

 

ODS 和資料集市都是基於核心業務系統/交易系統的資料模型和資料規範的，隨著業務的不斷髮展，交易系統也要不斷進行迭代，而當交易系統升級換代的時候，ODS 和資料集市都要被推翻重建。面對高昂的建設費用和劇烈的系統震盪，大家發現建立一個相對獨立而全面的資料倉儲是一個非常有效的解決方式。

 

隨著儲存和計算資源的成本越來越低，計算能力和計算要求都在不斷的發展，是否還需要一箇中心化的資料倉儲的質疑甚囂塵上。因為資料倉儲通常採用T+1批次載入資料的方式處理資料，時效性不夠高，很難滿足業務上越來越高的時效性要求，除此之外，大量的外部資料無法整合，大資料平臺隨之應運而生。隨著各行業資料量高速增長，逐漸形成資料湖的概念。資料可以先進到資料湖，按需取用。

 

隨著技術演進，資料倉儲、資料集市、ODS、大資料平臺和資料湖等都歸類到了非實時資料處理分析系統裡面。近幾年，由於業務對時效性的要求越來越高，分散式計算、流計算興起，實時資料融合逐漸被推動起來。當前獲取資料模式，要求在不影響業務系統正常執行的情況下實現實時、準確、全面的資料獲取。可以在同一個平臺上對資料進行加工、融合以及計算，然後推送到下游的實時應用系統。

 

以上內容就是為什麼要構建一個實時資料平臺的發展理念。

 

實時資料領域三大常見問題

2000 年左右，一家大型企業所應用資料庫型別比較少，從品牌角度講，Oracle、IBM DB2、Sybase、MS SQL Server 是應用比較多的，但哪怕是多個品牌，也基本上都是關係型資料庫。而資料技術發展到今天，從全球範圍來看，能歸類到資料庫的技術品牌有 200 餘種，包括傳統的關係型的資料庫、時序資料庫、圖資料庫、搜尋引擎、訊息佇列、大資料平臺與物件儲存等，主流的資料庫就有40多種。

 

隨著業務的不斷髮展，為了應對不同的應用場景，交易系統、賬務系統、管理系統等會採用不同的資料庫技術，無形中構建了大量的技術壁壘。而資料本身在一個企業域內都是獨一無二的，是需要相互融合的。在不斷髮展的資料技術和每種技術的差異性逐步增大的過程中，如何能夠打破技術壁壘，讓資料不會因為技術棧的選擇而阻礙其價值釋放，是今天擺在我們面前的一個主要問題。

無論是技術人員還是網際網路從業者，都能明顯感覺到使用者的互動時間越來越短，注意力經濟越來越凸顯，誰能抓住使用者注意力誰就能獲得相應的流量和回報。在這個過程中如何能夠在較短的互動時間裡抓住使用者的注意力，整個實時資料鏈路打通至關重要。但是這又跟實際的研發管理、IT 的資料管理有天然的一些矛盾。研發管理需要進行開發、測試、上線等整套流程，而業務則要求資料要有更高的敏捷性。多數的IT管理系統對敏捷的業務場景的支撐、資料融合或者底層的資料整合反而成為了阻礙。一個端到端的實時鏈路，一般的交付週期以月為單位。同時，十幾種甚至幾十種資料技術混合使用，儲存於其間的資料如何能夠快速的構建鏈路？能夠把增量資料、全量資料進行有效的融合，成為了IT部門核心要解決的問題。

 

把不同的技術壁壘打通之後，緊接著需要構建資料融合平臺。實時資料鏈路兼具著業務運營和後臺業務分析、管理的作用，需要具備非常高的穩定性、容錯性來應對外部組織結構的變化和內部對平臺的要求。當資料融合本身非集中式時，一定會受到資料鏈路、上游系統、下游系統的影響。上游系統是重要程度更高的業務系統。上游資料結構的變化以及資料的大規模處理不會過多顧及下游資料鏈路的實際情況。例如上游一個簡單的更新操作，對下游系統可能造成百萬、千萬級別的增量資料。下游系統的穩定性不僅僅源於自身的穩定性，更多是透過一些預設規則有效地應對上游系統帶給它的影響。當上下游系統都穩定了，執行在底層的系統，如網路環境、儲存環境、CPU 記憶體等環境也會影響到整個系統執行的穩定性。此時，就需要考慮跨網傳輸/大規模的資料鏈路如何遮蔽以上不穩定因素。

 

總結，企業在實施資料管理過程中碰到的三項主要問題。第一個問題，當越來越多的資料庫技術應用在企業內部，出現了大量的技術壁壘，我們如何打破這些技術壁壘，把資料做有效融合驅動業務的發展。第二個問題，業務部門對資料處理的時效性要求變得越來越高，但資料處理實時應用的構建過程依然需要一個科學嚴謹的構建邏輯，業務部門對資料時效性的要求和IT部門構建高質量資料鏈路的效率之間的平衡。最後，實時資料鏈路構建起來後，因為其兼具業務運營和管理支援的要求，所以穩定性和容錯性的要求很高，而這個過程中又受上下游系統及系統環境的制約，如何保證高效穩定的執行，保證高容錯性應對各種突發狀況。

實時資料管理的主要問題及應對之法

下圖展示的是一個標準的金融行業企業級實時資料平臺的整體架構。它的上游是儲存於不同的資料庫技術或外部資料節點的資料，DataPipeline 可以透過不同的技術棧把這些資料融合到平臺裡面來，然後再推送到下游的各類業務系統中。

多元異構的增量資料準確獲取

近二十年來，資料來源型別發生了巨大變化。早期整合的資料大部分都是業務系統資料，企業域內的資料會比較多。而現在，需要整合的資料不僅增加了大量的非結構化資料，而且大量來源於外部。

 

除了業務系統資料，還有客戶行為資料、電子裝置、APP、攝像頭、感測器等的客戶端資料也會進入到實時資料鏈路，而且這一類實時資料的分析價值非常高。

 

如今每家企業都會關注其整個產業鏈的上下游。大量合作伙伴，除了在生意層面的合作，還有IT系統之間的合作。這就要求實時資料處理平臺，能夠應對外部業務系統的實時增量和全量資料的融合。

 

企業還在採集大量的外部資料，例如天氣資料、資訊資料等，這些資料如何有效地進入到企業域內進行整合，進入實時資料鏈路如何發揮作用，也是一個企業在構建實時資料平臺需要關注、解決的問題。

 

每一項資料來源採用的資料庫技術/資料處理技術可能都不盡相同，因此涉及到多源異構資料處理問題。如何在不影響系統正常執行的前提下獲取全域實時資料。這裡我們就要談到 Log Base Change Data Capture 概念，它是 DataPipeline 自主研發的基於日誌增量資料獲取技術。我們現在也在與 IBM 合作，整合 IBM InfoSphereData Replication 的產品來採集包括大型機、中型機（AS400 系統）的資料庫日誌。針對主流的MySQL、MS SQL Server 等資料庫都可以使用日誌解析的方式獲取資料。當然，基於日誌的實時增量獲取也不是單一的種類，例如MS SQL Server 有兩種實時增量獲取模式：CT 模式和 CDC 模式。

IT系統的敏捷開發

多源異構的增量資料準確獲取問題解決以後，接下來需要解決的第二個問題，快速支援IT系統的敏捷開發。

 

我們將整個實時資料融合平臺解構為資料節點、資料鏈路、融合任務與系統資源四個邏輯概念，透過對資料節點註冊、資料鏈路配置、融合任務構建、系統資源分配等各個環節進行分層管理，在有效地滿足系統運維管理需求的前提下，提升實時資料獲取與管理在各個環節的配合效率。

 

資料節點，資料節點是資料的原始載體。資料節點可以是資料庫、檔案系統、資料倉儲、檔案、應用，一切儲存資料的載體都能成為資料節點。在資料融合過程中，資料節點既可以做資料來源節點也可以做資料目的地節點，在透過資料節點管理註冊一個資料節點時，它是沒有被分配角色的，資料鏈路的存在才會賦予相關資料節點「資料來源節點」和「資料目的地節點」的角色屬性。

 

資料鏈路，資料鏈路是對實時資料融合過程的邏輯描述，既描述了具體業務場景涉及到的資料物件關係，也描述了在執行具體資料融合任務時需要遵循的限制與策略。

在資料融合過程中， 資料鏈路作為分隔資料管理與資料應用的邏輯層次，既保護了資料節點的安全、穩定與資料語義的一致、準確、完整，也保證了資料融合過程中的監控、日誌、預警等基礎運維工作遵循企業整體的資訊化管理機制。

 

融合任務，融合任務是實時資料融合的最小管理單位。融合任務透過選擇資料鏈路確定要執行的具體資料融合內容及基本規則，在保障資料資源可控的前提下，融合任務為資料應用提供更多的自主性。實際使用資料的業務部門或應用開發人員可以自主選擇資料獲取的範圍、融合任務的生命週期、系統資源投入的多寡。在遵循資料鏈路配置的基礎上，可以自行定義自動重啟策略、預警策略、日誌策略、讀取限制、寫入限制、傳輸佇列限制等配置選項。

系統資源，系統資源是系統平臺及融合任務執行的載體。系統資源即是指執行融合任務的融合引擎所使用的資源組，同時也是指保障整個系統正常運轉的各個功能模組所使用的系統資源。在資料融合過程中，融合任務只要關心執行任務所需的系統資源是否滿足效能、效率等影響資料時效性的系統資源即可，而訊息佇列、錯誤資料儲存、日誌儲存、預警儲存乃至平臺配置持久化等功能模組所使用的系統資源則由管理資料鏈路的資料工程師與管理系統資源的運維工程師統一管理即可。

 

為什麼要把資料任務和資料鏈路拆分呢？業務部門/資料使用方不關注資料是怎麼對映的，更關注的是什麼時間點用什麼方式可以獲取什麼樣的資料，是全量資料還是實時的變化資料可以獲取到，是定時模式還是監聽模式，執行的時候要不要幫我清空，這些是資料使用方比較關心的內容。DBA 和資料鏈路的維護方和資料使用方之間，可以透過資料任務、資料鏈路和資料節點這三個邏輯概念來拆分清楚各自應該負責的內容。

 

DBA 可以把日常所用到的全企業域內的所有資料節點迅速地定義到平臺，資料組就可以基於這些資料節點，按照業務部門的需求或者IT系統的規劃，把相應的資料鏈路進行配置，如對映規則、鏈路執行策略、日誌策略、預警策略、配置策略。資料使用方可以基於已經配置好的資料鏈路，按照自己的需求，在合適的時間用合適的方式獲取合適的資料。這樣，實時資料融合參與的各方都可以透過無程式碼配置的方式快速地完成各自的任務與管理控制要求。

IT系統的穩定、高容錯性

在支援了IT系統的敏捷多速開發要求之後，我們再來一起關注一下系統的穩定、高容錯性如何做到。

資料鏈路構建成功後，其執行的容錯性和穩定性如何保證？實時資料鏈路受資料鏈路上下游節點和執行時的影響。我們需要給到實時資料鏈路有效地、符合使用者預期的相應處理策略和規則。比如上游發生了資料結構變化，針對資料鏈路的下游應該執行什麼模式？如果是非常重要的資料，結構不應該丟失，可以讓任務停下來。但並不是每一個資料任務都應該停下來，資料任務都停下來可能會影響業務推進，這時就可以為鏈路預設一些規則，比如當上遊資料庫的表增加或者減少了欄位的時候，可以把這些變化同步到下游，為使用者提供一個選項是暫停任務、忽略變化或者應用變化。

另外，大概有 5% 的 IT 系統故障是找不到原因的，且透過重啟的方式就可以自然恢復，DataPipeline平臺也支援自動重啟模式。但在分散式系統中，某些情況下的頻繁重啟會導致情況越來越糟。因此， DataPipeline 會預設一些規則，告訴使用者在遇到某些故障時不建議自動重啟，應該停下來處理故障。

 

在資料節點、資料鏈路、資料任務上預設的策略配置和限制配置有幾十種，可以有效的幫助使用者應對可能在資料鏈路執行過程中出現的各種已知或未知情況。

 

除了在系統預設策略提升容錯性以外，DataPipeline實時資料融合平臺採用分散式引擎，系統元件與計算元件都經過嚴格的高可用測試，支援元件級高可用，保證了整體的容錯性，同時可以非常動態靈活地做擴縮容，允許不同的計算任務重新分佈到不同的機器上，而不影響其他部分的執行。

 

下圖左側是在DataPipeline分散式叢集中，當某個節點出現問題的時候，剩餘的節點就可以把相應的任務接管過來繼續執行。當中間的節點恢復的時候被重新註冊了進來，這時可以選擇兩個不同的策略，如果另外兩臺機器的負載已經很高了，有新的節點被註冊進來，要做一次重平衡，把這六個任務再重新均勻分佈出去。另外一種策略是，兩個節點執行的負擔還在理想範圍內，可以持續執行下去就可以不做重平衡，而是等到有新的任務產生再被分配，因為重平衡也是很消耗系統資源的。

在分散式叢集的基礎上，DataPipeline支援透過劃分獨立資源組方式，確保高優先順序的任務能夠穩定、高效執行，比如有一些跟客戶有關的資料任務，對其資料處理效率有很高的要求，就可以獨立劃分出一個資源組，不讓其他的融合任務來搶佔系統資源。

 

DataPipeline基於日誌 CDC 技術打破各類紛繁複雜的資料技術壁壘，透過資料語義的各種對映解決多源異構問題，幫助企業打破由於採用不同資料庫技術而導致的資料融合壁壘問題。透過資料節點、資料鏈路、資料任務和系統資源來保證不同的角色可以在平臺上有效地分工合作。透過低程式碼配置方式，提升資料鏈路尤其是實時資料鏈路的敏捷性，能在5分鐘之內構建出一個實時資料鏈路。最後，透過各類的預設規則和分散式架構的高容錯性，來保障整個系統穩定正常的執行。

獲取完整版PPT，請關注公眾號DataPipeline並回復關鍵詞“陳雷”。