使用高級分析工具來對業務數據進行分析是很常見的，特別是對于有很多面向客戶系統的大型企業。隨著我們可以訪問的數據越來越多，企業已經開始將大數據存儲到企業數據倉庫（EDW）中。然而，這些大數據部署帶來一系列的問題，它要求數據庫管理員（DBA）和相關支持人員對數據倉庫架構進行重新設計。
大數據時代
在當今的商業化的IT系統中，我們會收集存儲越來越大量的數據。同時要能夠獲取、分析這些數據，大多數企業開始轉向專有硬件、軟件解決方案。這也是一體化設備開始流行的一個原因，針對特定應用場景的硬件數據存儲與業務分析軟件的耦合度越來越高。
比如IBM的DB2 Analytics Accelerator（IDAA），即IBM DB2分析加速器。
這樣的解決方案通常十分昂貴。大數據存儲需要擴展磁盤和內存陣列，高性能訪問則需要大量CPU資源加上復雜的數據訪問以允許多個進程并行訪問數據集的各個部分。
在實現這樣一個解決方案之前，企業需要確認并解決以下問題。
基礎設施需求
就拿IDAA來舉例，它是一個軟硬件解決方案的混合產物。其硬件包括一個大型磁盤存儲陣列并結合可進行大規模并行處理的軟件。技術支持人員要指定哪些DB2表要在設備中加以復制和存儲，及其刷新機制。然后軟件會與DB2數據庫引擎相連接，使得查詢可以訪問設備中的表備份，這可以提供更快的訪問速度。
除了電力和冷卻這些標準問題，在部署這樣一個設備之前，IT人員必須考慮多個架構方面的問題。
IDAA只會存儲生產系統的數據嗎？還是說也可以存儲測試數據？換句話說，DBA和業務分析人員要怎樣開發并測試他們的數據分析查詢。
究竟需要多少設備呢？例如，如果在IDAA上正在執行的數據分析是公司關鍵任務，那么是不是需要額外的設備進行災備？
雖然IDAA可以存儲大量數據，但只能對訪問設備中存儲數據的查詢進行提速。那么系統中要存儲哪些表呢？
特定的用例
超快的數據分析聽上去不錯，但很多企業尚沒有為分析開發特定的查詢或系統。這就導致了很多時間花費在數據加載和查詢測試上，而沒有產生切實的成果。
合理成本會迅速轉化為效益嗎？
大多數業務數據分析包括以下一系列步驟：
1.業務分析人員審查報表，查詢以及其他數據并形成基于他們分析的邏輯問題；
2.然后開發一個或多個查詢用來分析大型數據存儲；
3.執行查詢；
4.分析人員審查并闡釋結果。
一體化的解決方案可以顯著減少步驟3的執行時間。但是，其他步驟依然存在。例如，假設以上的每個步驟要耗費一小時，那么總的消耗時間就是四小時。部署一體機可能會將查詢執行時間減少為幾分鐘。雖然這是一個非常顯著的時間降低，但是總時間也只縮減為三個小時多一點。
總之，減少查詢執行時間肯定是有好處的，但是可能不像之前所認為的那樣效果明顯。
業務數據“消費”群體
大多數業務數據“消費者”可分為以下三類：
1.技術用戶直接運行查詢。這些用戶會使用SQL針對數據表創建查詢，然后使用一個在線SQL執行工具來運行查詢并在原始數據表格中生成結果，這樣他們便可以直接觀察或是下載到一個電子表格以供進一步分析之用。這些用戶熟悉這些數據表，擁有SQL相關知識，并且會用簡單工具來提煉結果。
2.復雜報表分析人員。這些消費者通常會使用一個復雜的報表工具來顯示數據的一個圖形數據模型。然后他們會通過拖拽表和字段到一個報表窗口來操縱此模型。此工具接著會創建基于模型和其他參數的適當SQL語句，執行此查詢，并顯示結果。這些用戶熟悉數據，通常不具備SQL專長，而且需要一些高級查詢和統計報告的技術。
3.數據集市的消費者。這些用戶擁有他們自己的高度專業化的業務數據分析軟件。他們會直接從源頭提取業務數據并將之存儲在一個本地服務器上。然后他們會使用專門的軟件來分析數據 任何一個大數據解決方案都必須將這些不同的群體需求考慮進來。
部署過程中的問題
在部署一體機的過程中，IT人員通常會遇到一些常見問題。
相互矛盾的問題
如果我們尚未對其進行分析那么我們要存儲些什么呢？如果我們還沒有數據那么我們要分析什么呢？業務并不會完整的理解什么數據會是可用的，并且IT支持人員并不了解在一個大數據解決方案中什么樣的業務數據對于整個部署來說是最為有用的。
這兩個問題通常是缺乏特定用例或是IT與業務部門間缺乏交流所導致。
批量數據加載問題
大多數一體機支持大數據解決方案并能承受超大量的數據。最常見的問題之一就是究竟要花多長時間將那些數據加載到一體機中？
一旦數據被加載，其他批量數據問題就出現了：我們要如何才能保持數據是最新的？我們要如何清除大量過期和無用數據？
這些并非新問題。有經驗的IT人員一定不會陌生，其中之一便是災難恢復（DR）準備。如果突發災難（火災，洪水等）在主站點發生，那么典型的災難恢復站點就必須在數小時內準備好，來頂替主站點。對于當今大量的業務數據來說，最為常見的技術解決方案就是去維護一個在DR站點當前業務數據的完全備份，而此DR站點是通過網絡連接和軟件將主站數據“鏡像”到DR站點的。
有了一個大數據解決方案，IT人員就必須找出一種方法通過數據鏡像，定期數據加載和定期數據歸檔工作的組合來讓一體機中的數據保持新鮮。
災難恢復問題
大多數數據倉庫是用來進行分析和報表之用，并非用來處理客戶事務之類的業務數據。一個大數據一體機通常會連接到數據倉庫，所以這并不是通常所認為的在DR站點所需要的東西。但是，在此之前，讓我們來考慮以下場景：
1.你的公司已經部署了大數據一體機；
2.業務分析人員和用戶開始查詢數據；
3.很多查詢產生的結果導致更低的成本和更合適的價格；
4.查詢運行迅速，如此之多的分析人員開始執行很多查詢；
5.隨著更多的查詢產生可執行結果，管理方認同它們的價值；
6.每周一次性的查詢開始運行；某些查詢成為日常報表；
7.在管理中有價值的日常報表結果數量指定大數據解決方案并分析為“關鍵任務”。
然而，IT人員會突然被告知如果災難發生，大數據存儲必須是可用的。
要為企業中所發生的這些做好準備，需要在部署的開始階段審查存儲需求，網絡容量，硬件能力和容量以及軟件許可需求。要讓這些數據在變得關鍵之前進行發布并使之可用于管理。這會讓你的企業提前為其需要做好預算和規劃。
最初的部署問題
你也許要部署一臺進行大數據分析的一體機。通常來說，這些數據并非在當前收集或存儲在數據倉庫中，因為這些數據太大了。相反，這些數據是作為當前可操作數據的一部分來存儲的。一些例子包括語音響應記錄和點擊數據，在線互動和設備傳感器數據。
這就引出了一個有趣的想法：首個分析會是在原始生產系統數據上，而非在數據倉庫中。這是一個誘人的想法。你可以擯棄在數據倉庫中進行獲取，轉換，以及存儲大量數據所耗費的成本和時間。數據可以馬上被訪問，而不用忍受相關的正常數據倉庫的數據暫存和加載所帶來的延遲。
然而，直接的生產系統數據訪問會產生問題。某些生產數據可能是非完整的或是缺失的，亦或是一種不易訪問的形式。某些數據可能是無效的，就像一個類似“99-99-9999”的日期數據，或是一個金額字段包含字母。其他數據可能會需要解釋，例如一個代碼字段包含0，A或C。
另一個問題是，大部分的大數據分析取決于稱之為維度的跨類型數據聚合。例如，客戶訂單數據可能會由地理區域和產品類型加以歸納。這些維度存在于數據倉庫的表中。為了成功執行這些查詢，它們必須對完全在一體機中的數據加以操作。這就意味著數據倉庫數據必須存在于一體機中為查詢而工作。
總結
目前大多數高級分析解決方案都能夠應對大數據挑戰。高速一體機會通過顯著縮短查詢時間來為業務用戶創造價值。但是，最好的架構解決方案會要求一體機作為數據倉庫的一部分。
將大數據一體機整合到一個數據倉庫需要充分準備和深謀遠慮。DBA和業務數據客戶必須協同工作一起確認以上實現過程中的問題并來滿足多種業務數據客戶的需求。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.lukmueng.com/
本文標題：大數據一體機融入數據倉庫架構的解決方法
相關文章
