陳雷 | 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並回復關鍵詞“陳雷”。