估計數據更新時刻的方法和設備、數據集成方法和設備的制造方法
【技術領域】
[0001] 本發明一般地涉及信息處理領域。具體而言，本發明涉及一種在數據集成中估計 數據更新時刻的方法和設備、W及相應的數據集成方法和設備。
【背景技術】
[0002] 在許多大型或者中型的機構，如組織、公司等中，有很多獨立的、分隔開的系統，送 些系統之間不能彼此交流數據。重構現有系統的代價通常是很高的，不同的系統又存在交 流數據的需要。
[0003] 因此，為了解決送一問題，提出了數據集成技術。如圖1所示，數據倉庫被利用來 存儲數據，作為數據中必。基于數據倉庫中的數據，可W進行數據呈現和數據挖掘等。數據 倉庫中的數據是通過數據導入從數據源獲得的。數據源例如是數據庫管理系統、Excel表 格、網絡APP(應用）等。當然，希望數據倉庫中的數據與原始的數據源盡可能地保持一致。 但是，何時更新在數據倉庫中的數據是很難把握的。如果更新得不及時，則數據倉庫中的數 據不是最新的。如果更新得過于頻繁，又產生了過多的資源消耗。
[0004] 此外，如下兩種情況更是增加了數據集成的困難。一種情況是作為數據源的系 統是一個黑盒子型服務器。送種服務器除了應用程序接口（Application Programming Intedace，API)之外，沒有提供任何接口幫助判斷數據更新時刻。另一種情況是系統部署 在局域網中，無法接觸到應用，但是可W接觸到服務器，即，可訪問服務器，但不能訪問駐留 在服務器上的應用。
[0005] 因此，期望一種針對如上所述的兩種情況能夠W較小的資源、較準確地估計數據 更新時刻的方法和設備、W及相應的數據集成方法和設備。
【發明內容】
[0006] 在下文中給出了關于本發明的簡要概述，W便提供關于本發明的某些方面的基本 理解。應當理解，送個概述并不是關于本發明的窮舉性概述。它并不是意圖確定本發明的 關鍵或重要部分，也不是意圖限定本發明的范圍。其目的僅僅是W簡化的形式給出某些概 念，W此作為稍后論述的更詳細描述的前序。
[0007] 本發明的目的是針對現有技術的上述問題，提出了一種針對如上所述的兩種情況 能夠W較小的資源消耗為代價相對準確地估計數據更新時刻的方法和設備、W及相應的數 據集成方法和設備。
[0008] 為了實現上述目的，根據本發明的一個方面，提供了一種估計數據更新時刻的方 法，該方法包括：對于僅公開應用程序接口 API的黑盒子型服務器，利用隱馬爾可夫模型， W第一預定頻率，判斷當前時刻與API相關聯的數據是否已更新，所述隱馬爾可夫模型的 顯式狀態是當前時刻數據是否已更新，所述隱馬爾可夫模型的隱式狀態是距離上一次數據 更新的時間；對于可訪問服務器，捕獲超文本傳輸協議HTTP請求的出現及其時刻；根據與 可訪問服務器相關聯的數據的更新和HTTP請求的相關性，W第二預定頻率，判斷當前時刻 數據是否已更新。
[0009] 相應地，根據本發明的再一方面，提供了一種數據集成方法，該方法包括；根據如 上所述的估計數據更新時刻的方法，估計所述僅公開應用程序接口的黑盒子型服務器或可 訪問服務器的數據是否已更新；W及如果判斷為數據已更新，則從相應服務器獲取相應的 數據并存儲到數據中必。
[0010] 根據本發明的另一個方面，提供了一種估計數據更新時刻的設備，該設備包括：第 一判斷裝置，對于僅公開應用程序接口 API的黑盒子型服務器，利用隱馬爾可夫模型，W第 一預定頻率，判斷當前時刻與API相關聯的數據是否已更新，所述隱馬爾可夫模型的顯式 狀態是當前時刻數據是否已更新，所述隱馬爾可夫模型的隱式狀態是距離上一次數據更新 的時間；第二判斷裝置，對于可訪問服務器，捕獲超文本傳輸協議HTTP請求的出現及其時 亥IJ ;根據與可訪問服務器相關聯的數據的更新和HTTP請求的相關性，W第二預定頻率，判 斷當前時刻數據是否已更新。
[0011] 相應地，根據本發明的再一方面，提供了一種數據集成設備，其包括；如上所述的 估計數據更新時刻的設備，用于估計所述僅公開應用程序接口的黑盒子型服務器或可訪問 服務器的數據是否已更新；W及獲取裝置，在判斷為數據已更新的情況下從相應服務器獲 取相應的數據并存儲到數據中必。
[0012] 另外，根據本發明的另一方面，還提供了一種存儲介質。所述存儲介質包括機器可 讀的程序代碼，當在信息處理設備上執行所述程序代碼時，所述程序代碼使得所述信息處 理設備執行根據本發明的上述方法。
[0013] 此外，根據本發明的再一方面，還提供了 一種程序產品。所述程序產品包括機器可 執行的指令，當在信息處理設備上執行所述指令時，所述指令使得所述信息處理設備執行 根據本發明的上述方法。
【附圖說明】
[0014] 參照下面結合附圖對本發明實施例的說明，會更加容易地理解本發明的W上和其 它目的、特點和優點。附圖中的部件只是為了示出本發明的原理。在附圖中，相同的或類似 的技術特征或部件將采用相同或類似的附圖標記來表示。附圖中：
[0015] 圖1示出了數據集成系統的示意圖；
[0016] 圖2示出了根據本發明的實施例的估計數據更新時刻的方法的流程圖；
[0017] 圖3示出了根據本發明的實施例的隱馬爾可夫模型的訓練方法的流程圖；
[0018] 圖4示出了根據本發明的實施例的計算相關性的方法的流程圖；
[0019] 圖5示出了監測結果的示例；
[0020] 圖6示出了根據本發明實施例的估計數據更新時刻的設備的結構方框圖；
[0021] 圖7示出了根據本發明實施例的數據集成設備的結構方框圖；W及
[0022] 圖8示出了可用于實施根據本發明實施例的方法和設備的計算機的示意性框圖。
【具體實施方式】
[0023] 在下文中將結合附圖對本發明的示范性實施例進行詳細描述。為了清楚和簡明起 見，在說明書中并未描述實際實施方式的所有特征。然而，應該了解，在開發任何送種實際 實施方式的過程中必須做出很多特定于實施方式的決定，w便實現開發人員的具體目標， 例如，符合與系統及業務相關的郝些限制條件，并且送些限制條件可能會隨著實施方式的 不同而有所改變。此外，還應該了解，雖然開發工作有可能是非常復雜和費時的，但對得益 于本公開內容的本領域技術人員來說，送種開發工作僅僅是例行的任務。
[0024] 在此，還需要說明的一點是，為了避免因不必要的細節而模糊了本發明，在附圖中 僅僅示出了與根據本發明的方案密切相關的裝置結構和/或處理步驟，而省略了與本發明 關系不大的其他細節。另外，還需要指出的是，在本發明的一個附圖或一種實施方式中描述 的元素和特征可W與一個或更多個其它附圖或實施方式中示出的元素和特征相結合。
[00巧]下面將參照圖2描述根據本發明的實施例的估計數據更新時刻的方法的流程。
[0026] 圖2示出了根據本發明的實施例的估計數據更新時刻的方法的流程圖。如圖2所 示，根據本發明的估計數據更新時刻的方法包括如下步驟：對于僅公開應用程序接口 API 的黑盒子型服務器，利用隱馬爾可夫模型，W第一預定頻率，判斷當前時刻與API相關聯的 數據是否已更新，所述隱馬爾可夫模型的顯式狀態是當前時刻數據是否已更新，所述隱馬 爾可夫模型的隱式狀態是距離上一次數據更新的時間（步驟S1)。另外，根據本發明的估計 數據更新時刻的方法，對于可訪問服務器，首先捕獲超文本傳輸協議HTTP請求的出現及其 時刻（步驟S21);然后根據與可訪問服務器相關聯的數據的更新和HTTP請求的相關性，W 第二預定頻率，判斷當前時刻數據是否已更新（步驟S22)。
[0027] 步驟S1針對僅公開應用程序接口的黑盒子型服務器進行處理。
[0028] 由于黑盒子型服務器僅公開應用程序接口，所W只能觀測數據是否已更新的歷 史，根據觀測的結果，預測將來數據的更新時刻。送樣的觀測和預測通過隱馬爾可夫模型來 實現。
[0029] 具體地，將隱馬爾可夫模型的顯式狀態設定為當前時刻數據是否已更新，將隱馬 爾可夫模型的隱式狀態設定為距離上一次數據更新的時間。通過對隱馬爾可夫模型進行上 述設定，并利用歷史數據對隱馬爾可夫模型進行訓練，就能夠利用隱馬爾可夫模型進行關 于數據更新時刻的判斷。
[0030] 在實際應用時，利用隱馬爾可夫模型，W第一預定頻率，判斷當前時刻與應用程序 接口相關聯的數據是否已更新。
[0031] 此處的第一預定頻率可W由本領域技術人員靈活設計，在設計時，可考慮系統資 源、判斷和更新的及時性等因素。
[0032] 第一預定頻率如果過于頻繁，則會增加很多無謂的探測和判斷，增加系統資源的 消耗。第一預定頻率如果過于稀疏，則會不利于及時更新數據。
[0033] 應注意，應用時的頻率與訓練時的頻率相同，均為第一預定頻率。
[0034] 舉例來說，第一預定頻率可W被設計為每小時一次。
[0035] 由于黑盒子型服務器僅公開了應用程序接口，所W無論訓練還是應用時，隱馬爾 可夫模型只能判斷與應用程序接口相關聯的數據是否已更新。