隨著實時資料庫的套用和網際網路的迅速發展，實時數據集成已經成為一個很重要的問，且實時數據集成與批處理數據集成兩者在某些方面互補。實時數據集成元數據主要包括3類：業務元數據、技術元數據以及操作元數據。實時數據集成的最佳實踐突破了點對點方案和緊耦合接口設計所帶來的複雜性問題：多種不同的邏輯設計方案可以用不同的技術去實現，但是如果沒有很好地理解底層的設汁問題，這些技術在實施時也同樣會導致比較低效的數據集成。
基本介紹
- 中文名：實時數據集成
- 外文名：Real-time data integration
- 優點：能夠及時處理數據
- 缺點：速度慢於批處理方式，技術更複雜
- 元數據：業務、技術以及操作元數據
- 套用學科：大數據管理
簡介,實時數據集成的必要性,數據大小限制,接口,所使用技術,兩組技術,成本角度,事務處理量,實時數據集成架構和元數據,元數據,建模,概要分析,元資料庫,企業服務匯流排——數據轉換和調度,
簡介
為了完成一個業務事務處理而需要即時地貫穿多個系統的接口就是所謂的“實時”接口。一般情況下，這類接口需要以“訊息”的形式傳送比較小的數據量。大多數實時接口依然是點對點的，傳送系統和接收系統是緊耦合的，因為傳送系統和接收系統需要對數據的格式達成特殊的約定，所以任何改變都必須在兩個系統之間同步實施。實時接口通常也稱為同步接口，因為事務處理需要等待傳送方和接口都完成各自的處理過程。
實時數據集成的最佳實踐突破了點對點方案和緊耦合接口設計所帶來的複雜性問題：多種不同的邏輯設計方案可以用不同的技術去實現，但是如果沒有很好地理解底層的設汁問題，這些技術在實施時也同樣會導致比較低效的數據集成。
實時數據集成的必要性
對於大多數據集成需求來說，因為要隔一夜，所以批處理的數據移動方式可能不可接受。一筆業務交易發生之後，要到第二天才能看到，這是難以接受的。同樣不能被接受的是某個客戶和組織新設立了一個賬戶之後，卻不能夠在當天辦理業務。
數據大小限制
實時數據互動過程通常會對在一次互動中所能包含的數據的數量或者大小有所限制。在一次實時數據互動中所能處理的數據塊稱為一個“訊息”。另外，批處理數據互動中對數據大小几乎沒有任何限制。而且，每個實時互動訊息都必須穿過在批處理集成中所描述的安全層次。由於每個小數據集或者訊息都必須經過這么處理，所以實時移動數據的方式對大量的數據處理來說，其速度要慢於批處理方式。在某些套用系統中，批處理數據集成的大量數據處理能力是有優勢的，因此會採用批處理的方式來移動數據。但是，如今大多數數據集成過程都以一種實時或者接近實時的方式運行。
接口
在套用系統之間的實時數據互動通常稱為接口，其含義與套用系統之間的批處理互動一樣。組織的套用系統組合管理，這即使對於一個擁有上百個活動套用的組織來說也可能是讓人望而卻步的。有時候，套用系統之間接口的複雜性可能會更加讓人崩潰。
所使用技術
處理實時數據集成所用到的技術要比批處理數據集成稍微複雜一些。一些基本步驟，如抽取、轉換，以及載入依然存在。當然，它們是以一種實時的方式在業務交易層面進行處理。對套用系統之間或者“點對點”的實時接口進行管理，相對於一個套用組合之內的所有必要互動的管理來說要稍微低效些。因此，為了管理接口，每個組織擁有一個企業級數據集成架構和管理能力就顯得相當重要。否則，事情很快就會變得不可思議的複雜。
兩組技術
兩組技術包括實時數據集成工具和批處理集成工具。
成本角度
在創建了實時數據集成能力之後依然保留批處理集成能力的第一個原因在於，現存的批處理接口已經被開發處理，並且經過測試，使用於生產環境中。遷移到另外一種技術可能會花費大量的時間和資源，雖然從成本的角度看可能是合理的，因為不需要維護兩組技術許可以及給兩組技術人員支付工資。
事務處理量
維護批處理和實時數據集成兩組技術的首要原因是實時數據集成的不足以處理大量的事務，例如在常規批處理數據接口視窗內將數據載入到數據倉庫或者在給定的時間之類完成數據轉換。實時數據集成天生就比較慢，因為對於移動的每個數據來說，都需要調用API訪問所有的安全層次並經過評估。改變數據倉庫的架構，在源系統中的數據發生變化的時候就載入這些數據，而不是每天、每周才載入數據，可能會減輕一些時間壓力。但是，在某個時刻（每天結束的時候）獲取的快照中所包含的數據量，對實時接口來說可能仍然難以在可用的批處理視窗之內進行處理。
因此，大多數組織都實施了批處理數據集成工具和實時數據集成工具，並針對不同的任務使用合適的工具。在合適的場合下，批處理數據集成工具通常為數據倉庫套用系統所擁有，並可以用於任何數據轉換。
實時數據集成架構和元數據
元數據
與實時數據集成有關的元數據和批處理數據集成非常相似，元數據可以分為3類：業務、技術以及操作。
（1）業務元數據。實時數據集成的業務元數據包括對將要在組織內部和企業之間移動和集成的數據的業務定義。安全訪問信息，例如哪些應用程式和用戶可以訪問哪些數據，可以歸為業務元數據，雖然其中包含了不少技術和操作型的信息。
（2）技術元數據。和實時數據集成相關的技術元數據包含了邏輯和物理模型、元數據布局、目標數據，以及中間規範化模型。它還包括了源、目標以及中間模型和物理實現之間的轉換和映射。與批處理接口調度相比，行為的調度需要對哪些數據以及變化進行監控，當某個事件發生時採取什麼行動屬於技術元數據。技術元數據提供了在螢幕上、報表中，以及欄位中所顯示的數據來源的“世系”信息以及轉換信息。
（3）操作型元數據。從實時數據集成的執行過程中產生的操作型元數據，對於業務用戶、技術用戶、作者以及監管者來說都是極具價值的。技術元數據提供了諸如數據是什麼時候產生的，以及如何變化的等“世系”信息。操作型元數據還提供了誰在什麼時候訪問並修改了數據之類的信息。
建模
通常有必要通過一個工具來支持實時數據集成所需要的模型開發，包括每一個點對點的接口模型，通用互動或者中心模型，以及數據服務模型。數據建模中使用的大部分工具也可以用於實時數據集成建模，雖然並不是所有的工具都有能力生成物理實現層次上的模型，例如XML模式或者數據服務類。可能還是有必要將模型導人那些面向實現的工具，如ESB、XML工具或者資料庫，以及（或）面向對象編程環境。可能使用實現工具來創建初始的模型，但是，通常建模者們比較喜歡在模型設計的時候使用一些可視化功能，傳統的數據建模工具以及最常使用的建模工具—visio，都提供這一功能。除了數據建模之外，通常使用流程建模工具對互動的數據流進行建模設計。
概要分析
如同批處理數據集成一樣，在項目開始之前，對實際的生產環境下的源和目標數據進行概要分析對於任何數據集成項目開發的成功來說都是至關重要的。這樣做，就有可能了解所有可能涉及的數據對於期望的目的來說是否具備足夠高的質量，以及是否已經識別出來恰當的源系統和目標系統。在批處理數據集成中使用的工具同樣適用於這裡。
元資料庫
建模、概要分析以及轉換（ESB）工具都有它們自己的源數據存儲庫，這些對於管理開發和操作實時數據集成方案相關的元數據來說可能已經足夠。而就批處理集成元數據而言，組織可能會從一個統一的元資料庫中獲益匪淺，該資料庫將會連結不同的工具和引擎，同時在整個組織內部提供一個企業級的全局視圖，以及對數據的移動和轉換提供追蹤和審計。當然，一個統一的元資料庫當然應當同時包括批處理和實時數據集成方案中的元數據。
一個企業級元資料庫可以成為一項核心競爭力，它可以給業務用戶提供以下信息：在組織內部何處可以找到相關數據；數據的相對質量；如何以合適的方式使用數據；數據的更新歷史；以及訪問歷史。提供以上這些數據審計信息的功能被認為最佳實踐，並且在很多情況下，這是一項法規要求。
企業服務匯流排——數據轉換和調度
實現實時數據集成最主要的工具就是企業服務匯流排（ESB），它提供了大量用於管理實時數據接口所需要的功能。ESB提供了技術中介服務以及對那些已經開發出來的業務語義的套用。從技術角度看，ESB提供或者集成了不同伺服器之間物理數據移動的傳輸機制，對事件和互動的順序進行調度，協調運行在不同伺服器上的不同技術之間的互動和轉換，監控並進行錯誤恢復。ESB還將與組織的數據安全方案進行集成。組織必須指定什麼時候需要移動什麼數據，可以將這些業務決策配置到ESB中。
