一種數據倉庫數據異常的預檢測方法和設備與流程

2023-10-27 15:06:35 3

本申請涉及數據倉庫領域，特別是涉及一種數據倉庫數據異常的預檢測方法和設備。

背景技術：

數據倉庫是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用於支持管理決策，所述數據倉庫中的數據從產生到使用需要間隔T(Today，今天)+1一天，即今天產生的數據明天才可以使用，具體的，當所述數據倉庫中存儲的數據位打分規則時，伺服器獲取今天需要打分的對象，所述伺服器在明天的時候才能使用所述數據倉庫中的打分規則對獲取的對象進行打分。

傳統數據倉庫常採用T+1同步在線數據並在此基礎上計算T+1的應用結果。當在線數據是一些人工配置的打分規則信息時，而基於此信息，需要進行離線計算時，如果人工配置出錯，打分結果則會出現異常，且不易被發現及處理。

在現有技術中，是在根據T+1打分規則產生打分結果後，再對打分規則進行效驗，即今天產生的打分規則後，在明天根據今天的打分規則產生打分結果後再對今天的打分規則進行效驗。

在實現本申請的過程中，申請人發現現有技術至少存在以下問題：

T+1的運行流程計算完畢之後，只能通過實際計算結果監控亦或是應用到實際業務中才能發現問題，發現數據異常具有嚴重的滯後性，數據質量問題已成事實，數據修復有一定成本，但是對對業務造成的損失有可能是無法挽回的。

技術實現要素：

本申請的目的在於提供一種數據倉庫數據異常的預檢測方法和設備，在當前規則配置下的在線數據和離線基礎數據的對比，對數據異常進行預判，進而避免由於發現數據異常的滯後性而引起的不可挽回的損失，同時還節省了對異常數據進行修復時而產生的不必要的成本。

一方面，本申請實施例提出了一種數據倉庫數據異常的預檢測方法，所述方法包括：

伺服器根據預設的同步周期，將當前的在線數據同步到數據倉庫中，作為待檢測的基礎數據；

所述伺服器判斷所述待檢測的基礎數據與上一個同步周期的基礎數據是否相同；

如果判斷結果為否，所述伺服器根據前一個打分周期的處理規則，對所述待檢測的基礎數據生成模擬應用數據；

所述伺服器判斷所述模擬應用數據與所述前一個打分周期的應用數據是否相同；

如果判斷結果為否，所述伺服器確定數據倉庫數據異常。

優選的，在當前的同步周期為當前的打分周期內的第一個同步周期時，所述伺服器判斷所述待檢測的基礎數據與上一個同步周期的基礎數據是否相同，具體為：

所述伺服器使用當前打分周期的第一個同步周期的待檢測的基礎數據與上一個打分周期的最後一個同步周期的基礎數據進行對比，判斷兩者是否相同。

優選的，所述伺服器判斷所述待檢測的基礎數據與上一個同步周期的基礎數據是否相同之後，還包括：

如果判斷結果為是，所述伺服器確定數據倉庫數據正常。

優選的，所述伺服器判斷所述模擬應用數據與所述前一個打分周期的應用數據是否相同之後，還包括：

如果判斷結果為是，所述伺服器確定數據倉庫數據正常，並發送包含有用於告知基礎數據變化情況、所述模擬應用數據與所述前一個打分周期的應 用數據的通知消息。

優選的，所述伺服器確定數據倉庫數據異常之後，還包括：

所述伺服器發送數據異常的告警信息。

另一方面，本申請實施例還提出了一種伺服器，，包括：

同步模塊，用於根據預設的同步周期，將當前的在線數據同步到數據倉庫中，作為待檢測的基礎數據；

第一判斷模塊，用於判斷所述同步模塊所同步的待檢測的基礎數據與上一個同步周期的基礎數據是否相同；

生成模塊，用於在所述第一判斷模塊的判斷結果為否時，根據前一個打分周期的處理規則，對所述待檢測的基礎數據生成模擬應用數據；

第二判斷模塊，用於判斷所述生成模塊所生成的模擬應用數據與所述前一個打分周期的應用數據是否相同；

確定模塊，用於在所述第二判斷模塊的判斷結果為否時，確定數據倉庫數據異常。

優選的，所述第一判斷模塊，還用於：

在在當前的同步周期為當前的打分周期內的第一個同步周期時，使用當前打分周期的第一個同步周期的待檢測的基礎數據與上一個打分周期的最後一個同步周期的基礎數據進行對比，判斷兩者是否相同。

優選的，所述確定模塊，還用於：

在所述第一判斷模塊的判斷結果為是時，確定數據倉庫數據正常。

優選的，所述確定模塊，還用於：

在所述第二判斷模塊的判斷結果為是時，確定數據倉庫數據正常，並發送包含有用於告知基礎數據變化情況、所述模擬應用數據與所述前一個打分周期的應用數據的通知消息。

優選的，所述確定模塊，還用於：

在確定數據倉庫數據異常之後，發送數據異常的告警信息。

與現有技術相比，本申請實施例所提出的技術方案具有以下技術進步：

通過應用本申請實施例所提出的技術方案，伺服器將當前的在線數據同 步到數據倉庫中作為待檢測的基礎數據，與之前的離線數據進行對比，並在基礎數據出現變化的情況下，按照之前的處理規則生成模擬應用數據，進一步通過與之前的應用數據進行對比，來確定數據是否異常，從而，伺服器可以對數據異常進行預判，而待檢測的基礎數據和模擬應用數據均為預生成的數據，可以有效的避免由於發現數據異常的滯後性而引起的不可挽回的損失，同時還節省了對異常數據進行修復時而產生的不必要的成本。

附圖說明

為了更清楚地說明本申請或現有技術中的技術方案，下面將對本申請或現有技術描述中所需要使用的附圖作簡單的介紹，顯而易見地，下面描述中的附圖僅僅是本申請的一些實施例，對於本領域普通技術人員來講，在不付出創造性勞動的前提下，還可以根據這些附圖獲得其他的附圖。

圖1為本申請實施例所提出的一種數據倉庫數據異常的預檢測方法流程圖；

圖2為本申請實施例所提出的一種具體應用場景下的數據倉庫數據異常的預檢測方法流程圖；

圖3為本申請實施例所提出的一種伺服器的結構示意圖。

具體實施方式

下面將結合本申請中的附圖，對本申請中的技術方案進行清楚、完整的描述，顯然，所描述的實施例是本申請的一部分實施例，而不是全部的實施例。基於本申請中的實施例，本領域普通技術人員獲得的其他實施例，都屬於本申請保護的範圍。

本申請實施例提出了一種數據倉庫數據異常的預檢測方法，其流程示意圖如圖1所示，該方法包括以下步驟：

步驟S101，伺服器根據預設的同步周期，將當前的在線數據同步到數據倉庫中，作為待檢測的基礎數據。

具體的，在線數據同步到所述伺服器中的數據倉庫中作為待檢測的基礎 數據，以使所述伺服器後續可以根據相應的處理規則，將基礎數據轉換為應用數據。需要指出的是，如果按照正常的數據處理流程，當前的在線數據是無需在此時同步到數據倉庫的，因此，本實施例所提出的技術方案是在進行預先判定，可以避免後置判定在出現錯誤後才進行進行修改和恢復所導致的資源浪費和處理效率降低。

如果打分周期以天為單位，即今天的處理規則所生成的結果實際上需要到明天才可以完全呈現，如果到那時再進行數據校驗發現錯誤，則進行錯誤數據恢復等操作必然導致額外操作程序的增加和處理資源的浪費。

而由於在線數據為人工配置數據，所以，為了可以儘早發現由於人為原因或其他原因造成的配置的在線數據是錯誤的情況，所述伺服器按照預設的同步周期將當前的在線數據同步到數據倉庫中，所述伺服器就可以提前對當前的在線數據進行相應的處理。

在實際的應用場景中，所述預設的同步周期可以為1小時，所述伺服器以1小時為單位將在線數據同步到所述數據倉庫中，例如：所述伺服器將2點-3點所對應的在線數據同步到所述數據倉庫中並進行相應的檢測處理，在3點-4點時，所述伺服器將3點-4點所對應的在線數據同步到所述數據倉庫中並進行相應的檢測處理，以此類推，直到所述伺服器將當天的在線數據都同步到所述數據倉庫中並完成相應的檢測處理，這樣，就能夠在第一時間檢測到在線數據的異常，在在線數據發生變化時也能儘早發現。當然，打分周期和同步周期還可以以秒、小時、周、月、年等位單位，具體的打分周期和同步周期的長度可以根據在線數據變化的快慢或具體處理數據對象的類型確定，例如：具體處理的數據對應的類型是天氣時打分周期可以以年為單位，但始終需要保證的是同步周期小於打分周期。

其中，所述伺服器將為當前頁面數據對象配置的在線數據同步到數據倉庫中時，無論所述預設時間的單位是多少，當天打分規則的開始時間是以0點為起點的，如果以5小時為單位，那麼一天24中，最後4小時為一個單位，即把一天分為5個單位，分別為：0點-5點、5點-10點，10點-15點，15點-20點，20點-24點。

步驟S102，所述伺服器判斷所述待檢測的基礎數據與上一個同步周期的基礎數據是否相同。

其中，在當前的同步周期為當前的打分周期內的第一個同步周期時，本步驟的處理過程具體為：

所述伺服器使用當前打分周期的第一個同步周期的待檢測的基礎數據與上一個打分周期的最後一個同步周期的基礎數據進行對比，判斷兩者是否相同。

具體的，如果打分周期以天為單位，所述預設的同步周期以1小時為單位，則在所述當前單位時間為2點-3點時，所述伺服器獲取2點-3點所對應的在線數據，同時還要獲取1點-2點所對應的已被同步的在線數據，所述伺服器用2點-3點所對應的在線數據和1點-2點所對應的在線數據進行對比，如果兩個數據不同時，則可以判定2點-3點所對應的在線數據發生了變化，即配置了新的在線數據。

如果當前時間為0點-1點時，所述伺服器獲取的是當前0點-1點所對應的在線數據和昨天23點-24點所對應的已被同步的在線數據並進行對比。

如果判斷結果為否，即在線數據發生變化，說明為當前配置的在線數據發生變化，並需要進一步判斷為當前在線數據是否有錯誤，執行步驟S103；如果判斷結果為是，即在線數據沒有發生變化，說明為當前在線數據沒有發生變化，執行步驟S106，並不做任何處理。

步驟S103，所述伺服器根據前一個打分周期的處理規則，對所述待檢測的基礎數據生成模擬應用數據。

步驟S104，所述伺服器判斷所述模擬應用數據與所述前一個打分周期的應用數據是否相同。

具體的打分周期以天為例，在發現當前被同步的在線數據發生變化時，需要進一步驗證當前被同步的在線數據是否是配置錯誤的，具體的，如果當前2點-3點對應的被同步的在線數據發生變化，需要使用前一個打分周期(即昨天)的處理規則將當前被同步的在線數據生成模擬應用數據，這裡之所以稱之為模擬應用數據，是因為這樣的處理是預判操作，不會實質性的生成應 用數據的結果，所以，相應的操作只是模擬操作。

通過上述的操作，如果2點-3點對應的被同步的在線數據是配置正確的在線數據的話，那麼，2點-3點對應的被同步的在線數據在通過昨天的處理規則進行模擬處理之後所生成的模擬應用數據，應與昨天真正生成的應用數據相一致，即如果本步驟的判斷結果為是，則執行步驟S106。

相反，則表示當前被同步的在線數據是配置錯誤的，即如果本步驟的判斷結果為否，則執行步驟S105。

其中，所述伺服器在前一個打分周期結束之後就可以獲取到前一個打分周期真正生成的應用數據，以便在判斷模擬應用數據與前一個打分周期的應用數據是否相同時使用，這樣可以使伺服器只獲取一次應用數據就能再後續的整個打分周期內使用，當然，所述伺服器也可以在當前打分周期發現數據發生變化時獲取，即在步驟S102判斷結果為否時才去獲取前一個打分周期的應用數據，具體獲取方案可以根據實際情況確定，但是所有的獲取時機均屬於本申請的保護範圍。

步驟S105，所述伺服器確定數據倉庫數據異常。

在實際的應用場景中，本步驟被執行後，所述伺服器還需要發送數據異常的告警信息，所述告警信息中包含有用於告知基礎數據變化情況、所述模擬應用數據與所述前一個打分周期的應用數據。

步驟S106，所述伺服器確定數據倉庫數據正常。

如果是在步驟S104之後執行本步驟，則所述伺服器需要發送包含有用於告知基礎數據變化情況的通知消息。

與現有技術相比，本申請實施例所提出的技術方案具有以下技術進步：

通過應用本申請實施例所提出的技術方案，伺服器將當前的在線數據同步到數據倉庫中作為待檢測的基礎數據，與之前的離線數據進行對比，並在基礎數據出現變化的情況下，按照之前的處理規則生成模擬應用數據，進一步通過與之前的應用數據進行對比，來確定數據是否異常，從而，伺服器可以對數據異常進行預判，而待檢測的基礎數據和模擬應用數據均為預生成的數據，可以有效的避免由於發現數據異常的滯後性而引起的不可挽回的損失， 同時還節省了對異常數據進行修復時而產生的不必要的成本。

下面將結合本申請中的附圖，對本申請中的技術方案進行清楚、完整的描述，顯然，所描述的實施例是本申請的一部分實施例，而不是全部的實施例。基於本申請中的實施例，本領域普通技術人員在沒有做出創造性勞動的前提下所獲得的所有其他實施例，都屬於本申請保護的範圍。

本申請實施例所提出的技術方案在一種具體實施例場景中的實現流程的示意圖如圖2所示，具體的操作流程如下：

首先，需要指出的是，在本實施例所提出的應用場景中，在線(online)數據為模型打分的規則配置表，離線(offline)基礎數據就是該規則配置表對應到數據倉庫的表，離線(offline)應用數據則是根據離線基礎數據產出的模型打分結果。

在後續說明中，T+0表示當前時間，T+1表示明天，以此類推，H+1表示當前小時之後的一個小時，相應的，打分周期設置為一天，同步周期為一小時。

步驟S201、首先，伺服器將當前的規則配置表(今天)，即當前的在線數據，按照每小時一個同步周期的頻率，同步到數據倉庫對應表中，作為離線基礎數據，由於是預處理，該離線基礎數據標識為離線基礎數據(H+1)，即前文所述的待檢測的基礎數據。

步驟S202、伺服器將離線基礎數據(H+1)與上一小時的離線基礎數據進行比對。

如果沒有變化，則沒有異常變動，確定數據正常，不返回報警；如果有變化，則執行步驟S203。

步驟S203、伺服器根據數據倉庫對應表中的離線基礎數據(H+1)，按照昨天的處理規則，模擬生成昨天的模型打分結果，即模擬的離線(Offline)應用數據(昨天)，也即前文所述的模擬應用數據。

步驟S204、比對模擬的離線(Offline)應用數據(昨天)和實際已存在的離線(Offline)應用數據(昨天)。

若沒變化，則只告知規則變動情況；

若有變化，則告知規則變化及由此帶來的離線應用數據變動情況。

與現有技術相比，本申請實施例所提出的技術方案具有以下技術進步：

通過應用本申請實施例所提出的技術方案，伺服器將當前的在線數據同步到數據倉庫中作為待檢測的基礎數據，與之前的離線數據進行對比，並在基礎數據出現變化的情況下，按照之前的處理規則生成模擬應用數據，進一步通過與之前的應用數據進行對比，來確定數據是否異常，從而，伺服器可以對數據異常進行預判，而待檢測的基礎數據和模擬應用數據均為預生成的數據，可以有效的避免由於發現數據異常的滯後性而引起的不可挽回的損失，同時還節省了對異常數據進行修復時而產生的不必要的成本。

基於與上述方法同樣的申請構思，本申請還提出了一種伺服器，其結構示意圖如圖3所示，該伺服器包括：

同步模塊31，用於根據預設的同步周期，將當前的在線數據同步到數據倉庫中，作為待檢測的基礎數據；

第一判斷模塊32，用於判斷所述同步模塊31所同步的待檢測的基礎數據與上一個同步周期的基礎數據是否相同；

生成模塊33，用於在所述第一判斷模塊32的判斷結果為否時，根據前一個打分周期的處理規則，對所述待檢測的基礎數據生成模擬應用數據；

第二判斷模塊34，用於判斷所述生成模塊33所生成的模擬應用數據與所述前一個打分周期的應用數據是否相同；

確定模塊35，用於在所述第二判斷模塊34的判斷結果為否時，確定數據倉庫數據異常。

在具體的應用場景中，所述第一判斷模塊32，還用於：

在在當前的同步周期為當前的打分周期內的第一個同步周期時，使用當前打分周期的第一個同步周期的待檢測的基礎數據與上一個打分周期的最後 一個同步周期的基礎數據進行對比，判斷兩者是否相同。

在具體的應用場景中，所述確定模塊35，還用於：

在所述第一判斷模塊32的判斷結果為是時，確定數據倉庫數據正常。

進一步的，所述確定模塊35，還用於：

在所述第二判斷模塊34的判斷結果為是時，確定數據倉庫數據正常，並發送包含有用於告知基礎數據變化情況的通知消息。

進一步的，所述確定模塊35，還用於：

在確定數據倉庫數據異常之後，發送數據異常的告警信息，所述告警信息中包含有用於告知基礎數據變化情況、所述模擬應用數據與所述前一個打分周期的應用數據。

與現有技術相比，本申請實施例所提出的技術方案具有以下技術進步：

通過應用本申請實施例所提出的技術方案，伺服器將當前的在線數據同步到數據倉庫中作為待檢測的基礎數據，與之前的離線數據進行對比，並在基礎數據出現變化的情況下，按照之前的處理規則生成模擬應用數據，進一步通過與之前的應用數據進行對比，來確定數據是否異常，從而，伺服器可以對數據異常進行預判，而待檢測的基礎數據和模擬應用數據均為預生成的數據，可以有效的避免由於發現數據異常的滯後性而引起的不可挽回的損失，同時還節省了對異常數據進行修復時而產生的不必要的成本。

通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到本申請可藉助軟體加必需的通用硬體平臺的方式來實現，當然也可以通過硬體，但很多情況下前者是更佳的實施方式。基於這樣的理解，本申請的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟體產品的形式體現出來，該計算機軟體產品存儲在一個存儲介質中，包括若干指令用以使得一臺終端設備(可以是手機，個人計算機，伺服器，或者網絡設備等)執行本申請各個實施例所述的方法。

以上所述僅是本申請的優選實施方式，應當指出，對於本技術領域的普通技術人員來說，在不脫離本申請原理的前提下，還可以做出若干改進和潤 飾，這些改進和潤飾也應視本申請的保護範圍。

本領域技術人員可以理解實施例中的裝置中的模塊可以按照實施例描述進行分布於實施例的裝置中，也可以進行相應變化位於不同於本實施例的一個或多個裝置中。上述實施例的模塊可以集成於一體，也可以分離部署；可以合併為一個模塊，也可以進一步拆分成多個子模塊。上述本申請實施例序號僅僅為了描述，不代表實施例的優劣。

以上公開的僅為本申請的幾個具體實施例，但是，本申請並非局限於此，任何本領域的技術人員能思之的變化都應落入本申請的保護範圍。