大資料：資料品質的好朋友？ 事務性來源

許多人都有一個誤解，認為資料集數量及其內部維護的資料品質之間存在一種固有的平衡。 這個問題頻繁顯現，並且成為了 Tom 加入的 Financial Services Information HTTP://www.aliyun.com/zixun/aggregation/16967.html">Sharing and Analysis Center (FS-ISAC) 和其他地方的座談小組最近談論的一大主題。

根據這種思維，如果沒有填寫 Apache Hadoop 集群、大規模並行資料倉儲和包含不一致、不准確、冗余、過時或不確定的17830.html">垃圾資料的其他節點，就無法擴展到 PB 級別。 但我們不同意這樣的觀點。 這也是我們認為這個概念對於實際情況過於簡單化的原因所在。

大資料並非大部分資料問題的事務性來源

絕大部分企業中的資料品質問題通常可歸因於來源事務系統，無論是客戶關係管理 (CRM) 系統、通用賬務應用程式，還是其他程式。 這些系統通常都處於 TB 級別。

在進行這方面的討論時，Jim 正確指出，未能保證記錄系統整潔、通用且一致的任何 IT 管理員實際上已經輸了一半。 當然，您可以通過聚合、匹配、合併和清除中間臨時資料庫中的資料（使之達到某種程度），從下游修復問題。 但品質問題與資料事務性來源控制不足有著密切的關係，但與來源的絕對數量並無太大關系。

通過大規模並行部署 IBM® InfoSphere® QualityStage®（或使用 IBM BigInsights™ 來冒充此功能），您可以從問題來源下游來擴展資料清除操作，但不能將無法「治癒」 某個疾病歸咎于該疾病並非由它所導致的。
大資料如今可以聚合以前從不需要清除的新型資料來源

在傳統的資料倉儲系統中，人們已對資料品質問題已經有很清楚的認識（即使它仍然是一項挑戰），但是，當時人們主要關心的是核心記錄系統的維護問題，包括客戶、財務、人力資源、供應鏈等。 但在大資料空間又該如何做呢？

很多大通話方案均用於深入分析聚合資料來源，比如社會行銷情報、即時感應器資料來源、從外部來源提取的資料、瀏覽器點擊流會話、IT 系統日誌等這類資料來源。 在歷史上，這些來源並未連結到事務性系統的官方參考資料。 一直以來，人們不必清除它們，因為通常採用離線方式處理問題的專業團隊往往會孤立地看待這些問題，並未將處理結果記入官方記錄系統中。 然而，跨資訊類型分析（在大資料空間很常見）改變了這一機制。

雖然個別資料點可能具有孤立的邊際價值，但拼湊起來可能會相當可觀。 它們有助於為發生（或即將發生）的問題提供上下文。

與業務參考資料不同的是，這些新型來源沒有提供需要直接載入到企業資料倉儲和離線存檔中的資料，或者說沒有提供需要為了進行電子搜索而保留的資料。 相反，您需要深入瞭解它們，以提取關鍵模式、趨勢和根源；一旦達到自身的核心戰術目的，您就可以將它們當中的大部分清理掉。 這通常需要執行大量的挖掘、切片和切割操作。

在這種情況下，資料品質問題將以兩種形式體現。 首先，您不能失去來源、主角、參與者或操作，而這些專案需要與其餘數據的定義保持一致。 第二，您不能丟棄處理事務的沿襲方法。 人物、事件、時間、地點以及發現和複製的方式。

正如我們 IBM 研究院的同事 John McPherson 所說的，「請記住，很多時候，當您談到大資料時，我們所說的資料指的是過去無法很好利用的一些資料，因此我們通常是在嘗試解決不同的問題。 我們並非試圖劃定各店面的盈利能力。 我們應當已經運用記錄系統中的高品質資料做到了這一點，並竭盡所能在將資料放入資料倉儲之時進行規范和重塑。 」此處，也就是在 John 的案例中，我們要做的是找出提高店面盈利能力的一些因素。
本文仍會在第 2 部分繼續我們的討論。 與此同時，請在評論中告知我們您在保持大資料品質方面的一些經驗。