在集成平臺建設中，我們經常會遇到許多數據整合、同步或者上報等場景，比如：
.....
這些場景會用到數據交換技術之一的ETL方式來實現，同時這種方式許多廠商也會作為集成平臺整體架構中數據交換層的核心中間件。在ETL技術應用中，往往會遇到各種數據源（數據庫、文件、流媒體等），數據量是少量也可能是海量。數據如何抽取、怎樣抽取在ELT中是最多討論和關心的，本文就集成平臺在醫療行業實現ETL，尤其是數據抽取的方式和優劣勢進行探討。
ETL: 我們只是數據的搬運工
ETL是 (抽取)， (轉換) 和Load (加載) 這三個過程的簡寫, 簡單來說ETL的目的就是將數據從源數據庫搬運至目標數據庫。抽取()就是找出需要搬運的數據并進行抽取；轉換()就是調整抽取的源數據格式使它滿足搬運目標數據庫的標準；加載(Load)則是將數據載入目標數據庫。
集成平臺在醫療行業實現ETL中數據抽取的常見方式
1. 技術對接方式：
1.1視圖/快照方式---由于時常會遇到集成平臺從醫院的第三方系統進行抽取，為保證數據安全性，通常會以視圖/快照的方式生成一個源數據庫的本地副本，該副本是只讀文件不能進行編輯修改，但可以讀取視圖中數據進行數據抽取，通常采用全量或增量的抽取方式。
優點：對數據庫的侵入性低，無需調整原有數據庫的架構，實現上簡單容易圖數據庫應用場景，實現難度低周期短。
缺點：實時性較低，需抽取端不停的輪訓，增加IO壓力，另外對于增量數據的判斷需要有特定字段（自增列、時間等）。
1.2 操作日志---需要源數據庫生成數據完畢之后，在外部生成日志。數據抽取時通過檢查源系統的執行日志找出數據增刪查改的痕跡進行抽取作業，通常采用增量抽取方式。
優點：能實時實現數據的獲取，無需判斷增量的特定字段。
缺點：影響原有數據庫性能，需調整數據庫架構，實現難度大周期長。
1.3 改造成接口---對源系統接口進行改造，能讓系統在對數據進行增刪改等操作時通過程序接口主動同步發送數據至目標庫，發送數據的動作可以跟業務修改數據動作脫耦，獨立發送，通常采用增量抽取方式
優點：對原系統沒有壓力和影響，實時性好，可靠度高，可控性更強，靈活度好。
缺點：需改造原系統，有一定的改造工作量，周期較長。
建議：
集成平臺中ETL應根據不同系統靈活切換不同的對接方式，醫院原有系統可采用非侵入或侵入性較小的視圖或快照方式進行數據抽取，保證系統的安全運轉；新系統可采用改造接口方式，提升數據抽取的效率和可靠性。
各類數據抽取方式優劣圖一覽
2. 數據傳輸方式：
2.1批量抽取：
即一批批抽取數據，醫院的數據上報場景通常就會采用批量抽取方式。在該場景下，醫院會在程序中設置一個數據已加載完畢同時對源數據庫壓力較小的時間（如每日凌晨2點），時間一到自動發起抽取，通常采用增量或全量抽取方式。
然而，隨著醫院數據量的越來越大，單純在夜間進行批量抽取，時間上已慢慢變得捉襟見肘，甚至會出現醫院第二天開始日常工作了前一天的數據仍然沒有抽取完畢的窘境。
2.2 流式數據抽取：
通過輪詢方式實現的小批量多次抽取，且可以實現不間斷抽取，用于實時性要求較高的場景，例如醫院新老系統交替時日常業務的數據同步。數據及時性可以通過輪詢時間的間隔進行調整，大大提高了數據同步的實時性，但并未達到完全的實時抽取。
2.3 通過消息格式主動推送：
該方式并非由ETL工具進行數據的搬運而是讓源系統在每次進行數據的更新后主動將更新的部分推送給目標數據庫。此類數據同步過程并不是由數據抽取的形式達成，但仍可以達成源數據庫與目標數據庫的數據同步，是實時性最高的一種數據傳輸方式。不過缺點就是多數醫院的老舊系統不支持，需要進行系統改造才能實現。
建議:
需要根據不同場景需求靈活使用不同的數據抽取方式，大部分數據建議采用流式抽取，能兼顧數據抽取的實時性和抽取效率，對于小量但實時性要求高的數據則通過消息格式主動推送，達到實時同步。
3.增量數據抽取的核心難點
在增量數據抽取的過程中，主要的難點就是去判斷數據源中哪些數據需要搬運，以下將會分析三種較為常見的解決辦法以及其對應的優缺點和局限性。
3.1 有判定標識或能添加判定標識：即通過判定標識以確認該數據是否已被抽取
該方式最易操作且最有效，但局限性較大。需要實施人員有權限對原表進行增刪查改。如果遇到從第三方系統進行數據抽取，出于數據安全等因素考慮很多時候只能通過視圖方式抽取圖數據庫應用場景，那該方法就不能實現。
3.2 有時間戳或序號標識：根據最后更新時間或主鍵序號，確認每次需要搬運的數據
這種情況下由于增量數據僅關注新出現的時間或序列號，對于已搬運的數據被刪除無法識別，也無法區分數據的插入和更新。因此在這種場景下，需要重起一行描述該數據的刪除、插入或更新的操作，以便讓ETL工具進行識別或抽取。
3.3 只有數據沒有任何標識：這種情況最為常見，而且由于沒有任何標識作為錨點，無法直接從視圖/快照中找出需要搬運的數據。此時的解決辦法如下：
ETL中的轉換（）
以上是對ETL中的“E”做了較為詳細的剖析。當然，除了數據抽取之外，ETL中的“T”也備受關注，不論是實際項目需求還是互聯互通測評要求，都需要標準之間的轉換處理，數據交換系統是否能夠更好的支撐ETL中的也需要考慮。目前各廠商有自己的數據結構和產品標準，國際上有HL7 v2、v3、FHIR等，國內有互聯互通2020(HL7 CDA)，引擎對于對于標準的建模、存儲、使用以及轉換等能力，也越來越被重視。
HL7 v2.x 標準協議示例
因此，引擎不僅需要支持上述行業協議標準，還需要提供模板工具和數據轉換工具等功能，幫助醫院減少開發成本、降低學習門檻、提高數據轉換效率。
集成平臺僅使用ETL夠用了么?
醫療衛生機構僅用ETL已無法滿足各種復雜的數據處理和交換場景，有些復雜場景需要完成一個完整業務，需要對接不同協議和技術的第三方應用，會使用到ESB、API、MQ等其他數據交換技術。因此在考慮集成平臺建設時除了具備ETL能力外，還更應該考慮多種數據交換技術使用的綜合能力。
應用場景舉例：非稅電子發票開票項目
場景描述：
非稅電子發票開票項目服務流程包括：從各院區數據庫中抽取開票信息，訪問系統API，將開票記錄結果返回給對應的數據庫。
場景技術需求分析：
在這個場景中，前半段開票信息抽取業務適合通過ETL實現，開票過程中調用接口的動作適合通過APIs實現，而后半段電子發票處理結果的分發和處理業務適合通過ESB實現。在處理這個業務場景時，需要ETL、ESB和APIs根據具體的業務要求協同使用。
多院區非稅電子發票開票業務場景示意圖
那么數據交換除了ETL技術外還有更好的方式和實現思路么？
——答案來了，有的
在不久前的HL7新西蘭年中會議，特別將一項名為ALEX（ Layer ）的項目列入專題。ALEX的特別之處在于能基于FHIR API直接對接應用層實現端到端互聯。ALEX解決方案涵蓋了新西蘭 90% 以上的初級醫療數據，允許診所通過ALEX平臺的FHIR API與第三方（包括應用程序、全科醫生、患者、保險公司等）安全共享實時醫療數據和記錄。該方式既保證了數據同步的安全性和實時性，同時對源系統也不會產生影響，以后我們也會對ALEX項目進行詳細的描述，敬請期待。
不感興趣
看過了
取消
