企業應用整合
面向服務的體系結構 (soa) 目前應該是乙個很受歡迎的名詞，中介軟體技術人員幾乎到了言必稱soa的程度，資料整合當然也不例外，在oracle openworld2008大會上，就推出了一堆資料整合的專場演講，其中和soa結合最緊密的就是實時資料整合 real time data integration。我總結了一下，實時資料整合一般分為兩個處理過程：一是對資料按照soa架構的需要進行整合加工形成可用的資訊，二是將資訊以符 合soa規範的方式發布出去。具體的實時資料整合模式可以按照對這兩個處理過程的設計分為以下四種：
1. 在中介軟體層上進行資料的加工整合，同時通過中介軟體層的標準介面將整合後的資料以標準介面發布。
2. 資料來源層負責資料的加工處理，然後將整合後的資料以標準的介面發布到中介軟體層，由中介軟體層負責資料的訪問。
3. 將分散在資料層的資料先整合到ods或者資料倉儲中進行整合加工，然後再將加工整理後的資料以標準介面發布到中介軟體層。
4. 採用資料網格的方式將資料層的資料整合在中間層，形成資料網格，中介軟體負責資料的加工，整合，然後以標準的方式發布出去。
我們先看第一種模式，資料整合發生在中介軟體層，資料發布也發生在中介軟體層，如下圖所示：
在中間層上存在乙個虛擬的資料服務層，該層通過jdbc，file 介面卡、應用介面卡等與資料層的各種資料來源實現連線，將資料來源中的各種資料實體對映成中介軟體的虛擬資料層的表，虛擬資料層中的表都只有元資料，而不儲存實 際的生產資料。使用者可以在虛擬資料層上採用視覺化圖形介面定義資料對映關係，進行資料加工整合，這些資料加工邏輯一般會以檔案或者資料庫方式儲存。定義好 的資料可以通過web service，jdbc,資料物件等多種方式發布出去。當使用者通過中介軟體訪問虛擬資料層的資料時，虛擬資料層會根據系統定義的邏輯首先將需要加工的細節 資料從各個資料來源抽取到虛擬資料層，然後中介軟體根據設計時的資料加工邏輯對其進行加工，最後中介軟體將加工好的資料以呼叫介面要求的格式返回。
採用虛擬資料服務層的優勢為：
1. 處理都在中介軟體伺服器上，相對來講，對資料的處理會比較靈活，應用和底層的資料實現松耦合。
2. 當乙個請求涉及到多個底層資料來源時，對底層的資料訪問可以採用併發方式進行。
3. 借助中介軟體的靈活性，資料可以採用多種方式對外提供介面，從而大大方便各種應用的開發。
4. 所有的資料都是實時從資料來源取來，保證資料的時效性。
問題：資料的處理在中介軟體層進行，一是帶來從資料來源到中介軟體層的資料傳輸，二是中介軟體一般都是j2ee架構，其強項並不是資料處理，在資料量不大時並無大礙，當資料量非常大時，其實現機制就注定了效率會出現問題。
第二種模式的實現方法為：資料來源層負責資料的加工處理，然後將整合後的資料以標準的介面發布到中介軟體層，中介軟體層只負責資料的接入訪問，如下圖所示：
這種處理方式一般是資料庫廠商或者etl廠商推薦的方式，根據使用者的業務需求邏輯，首先在資料來源層通過etl工具設計資料轉化流程，然後將流程的轉化邏輯發布成web服務，同時將轉化後的資料也發布成web服務，然後將這些服務註冊到中介軟體層，當前端使用者需要資料服務時，它需要呼叫兩個web服務，第乙個是轉化web服務，該web服務呼叫相應的etl工具對資料進行整合加工，然後將整合的資料儲存在臨時表中。第二個服務是呼叫資料服務，直接從臨時表中取出加工後的資料，與第一種模式的區別在於，它將資料的加工處理放在了資料來源層，其優勢在於：
1. etl工具天生就是做資料整合的，而且適合大資料量的整合，所以針對大資料量效率會非常高。
2. 在資料來源層整合可以充分利用資料庫的處理能力，畢竟資料庫才是做資料處理的行家。
3. 依靠e-lt工具的變化資料捕捉功能，可以進行增量資料的處理。
4. 資料轉化和資料獲取松耦合，可以實現非同步處理。
該模式的問題在於：
1. 由於資料的加工處理依賴於資料庫的處理能力，因此在所有的資料來源中，必須有乙個為關係型資料庫系統，而第一種模式由中介軟體負責資料處理，資料來源沒有限制。
2. 在應用的流程設計中，需要呼叫兩次web服務，一次為轉化，一次為取資料讀取，資料量非常小的情況下，有點畫蛇添足的味道。
第三種模式其實是前兩種模式的組合，但其資料整合是基於資料倉儲的概念發展演化而來，象現在很多企業單位正在建的ods系統。如下圖：
為了保證為企業提供乙個全域性的資料檢視，我們可以通過建立乙個全域性的操作型資料庫ods(operational data storage)，該資料庫與企業內的其它資料來源通過變化資料捕捉（change data capture）方式保持實時同步，當資料來源內的資料發生變化時，cdc會捕捉到變化的資料並通過etl工具或者其它手段（如主資料管理工具）同步到ods資料庫中。ods數庫內儲存的資料可以分為三層，如下圖所示：
介面資料層：主要負責接收從各個實時系統收集到的臨時變化資料。
統一模型層：針對企業共享資料的要求建立的企業級統一資料模型，介面資料層的資料通過加工整合然後進入統一模型層。統一模型層是ods對外提供資料**的主要資料來源
彙總資料層：根據使用者的業務需要，在ods上 建立一些統計、彙總，提供一些全域性的資料包表。從介面層到統一模型層以及從統一模型層到彙總層資料都可以採用非同步的方式完成，很多企業目前採用的方式是從 介面層到統一模型層採用準實時的方式完成，而從統一模型層到彙總層一般在晚上或者其它時間視窗完成，一方面避免對生產系統的影響，另一方面也可以充分利用 機器的處理能力，當客戶需要訪問一些彙總資料時，可以從彙總表直接取已經彙總好的資料，從而加快系統的響應時間。
最後一點就是資料的發布格式，在該模式中，中介軟體層負責資料的接入訪問，ods裡的資料可以封裝成web服務發布在中介軟體層。當前端業務流程需要整合的資料時，可以直接訪問ods內的資料，如果資料整合比較複雜，我們可以根據使用者的業務需要，通過etl工具或者其它工具（第二種模式）對統一模型層的資料進行加工放到彙總資料層，然後再從彙總資料層訪問資料。
第四種模式是採用資料網格的技術來實現實時資料整合，它和第一種方式非常相似，資料的整合加工和發布都在中介軟體層上，唯一不同的是我們採用資料網格技術在中間層增加了一層物件快取層，如下圖示：
資料的整合加工和訪 問接入都發生在中介軟體層，當客戶端訪問資料時，所有的流程方式都和第一種模式沒什麼區別，但需要訪問的資料都通過資料網格層快取在了中介軟體層，因此減少了 資料來源訪問和網路傳輸的時間，訪問速度會大大加快，從而可以在一定程度上解決第一種模式的不足，但資料處理仍然發生在中介軟體層，如果中介軟體處理能力有限， 系統的效率還會受到侷限。
在這裡需要說明的是資料網格並不是專門來做資料整合的，從上面的示意圖中我們也可以看到，資料整合只是資料網格的乙個副產品而已，關於資料網格的定義及功能，我們會在其它文章中解釋。
該模式的優勢：
1. 系統擴充套件性好，資料網格層的擴充套件性決定了整個系統的擴充套件性。
2. 當機器的處理能力不足時，通過集群方式可以大大提高效能。
3. 真正實現了前台資料與後台資料來源的松耦合。資料網格負責與各種後台資料來源的互動。
問題1. 中介軟體層資料的加工整理過程仍然存在。
2. 如果應用已經上線，需要針對資料網格提供的介面修改應用。
總結以上四個模式各有自己的應用範圍，從總體上看，資料的處理越靠近底層，效率越高，靈活性越差；越往上走，效率越低（網路傳輸和j2ee語言的擅長點不在資料處理），靈活性越好；其實各種資料整合模式無所謂好壞，關鍵是看業務需求，只要能夠滿足業務需求就夠了。
新瓶裝老酒 實時資料整合 模式
面向服務的體系結構 soa 目前應該是乙個很受歡迎的名詞，中介軟體技術人員幾乎到了言必稱soa的程度，資料整合當然也不例外，在oracle openworld2008大會上，就推出了一堆資料整合的專場演講，其中和soa結合最緊密的就是實時資料整合real time data integration ...
實時採集mysql mysql實時資料採集
0 集群環境介紹 10.20.201.51 namenode resourcemanager hmaster spark 10.20.201.52 namenode resourcemanager hmaster spark 10.20.201.53 datanode nodemanager hre...
遠端實時資料傳送
2006 05 06 00 03 19 摘要 介紹了以微控制器作為下位機採集電力引數資料，並控制數據機自動撥號，與上位機進行遠端實時資料傳送的方法，並給出了硬體電路圖和軟體流程圖。我國中大型石油化工企業大都採用小電流接地系統來供電，電力系統較為龐大。這類系統一般擁有幾座乃至十幾座35kv級的總降壓站...