數據倉庫歷史悠久，這里的基本想法是，大多數企業建立各種應用程序來自動化其基本業務流程，而這些業務流程各自發展，從而產生多個版本的數據。在過去，對于那些想了解不同產品線或地區的銷售收入或利潤率的人來說，數據不一致是令人頭疼的問題。

實質上，數據倉庫的原始概念是從各種事務系統中復制關鍵數據，解決不一致問題并生成易于分析的干凈數據集。這個過程通常使用定期運行的程序來完成，這些程序將在攝取新數據時使數據倉庫保持最新狀態。

數據倉庫環境的歷史

為確保數據倉庫環境正常運行，這里需要很多組件。它需要數據提取程序，并且數據倉庫必須使用其自己的架構進行設計。現代數據倉庫還需要其他程序，以通過業務規則解析背景數據的競爭版本，從而決定數據主版本的層次結構。

這里的歷史性挑戰是，數據倉庫類似于在不斷變化的底層操作系統上構建的建筑物。當這些系統發生重大變化時（例如重組或業務收購），數據倉庫的結構需要更改以反映基礎業務變化。如果業務變化的步伐過快，則數據倉庫可能會在一段時間內變得不可靠，從而破壞業務人員對它的信心。

為解決這個問題，數據集市應運而生。但是，除非數據集市與數據倉庫中的數據同步，否則它們可能會與之競爭并產生多種數據版本。為了解決這種不穩定性，開始出現各種數據倉庫設計，其中包括星形模式、雪花模式，以及技術專家Bill Inmon和Ralph Kimball提倡的其他模式。

隨后主數據管理領域開始出現，企業希望收集越來越復雜的業務背景數據集，這些業務背景數據通常具有可與數據倉庫協同工作的獨立數據庫。爭用不同版本的產品層次結構需要業務投入，從而使數據倉庫中的數據治理提供流程，以對此類主數據進行業務控制。

除龐大的數據量外，增加的復雜性也是一個問題。最終我們開始看到更加復雜的查詢和分析工具，它們本身通常需要自己的元數據層來表示數據倉庫的業務視圖。

同時，提取、轉換和加載（ETL）數據催生數據集成工具行業的發展。這些工具使流程自動化，并擁有自己的專有腳本，從而在數據倉庫環境中添加需要處理的其他組件。

數據倉庫現代化

多年以來，人們一直在嘗試整理企業數據倉庫環境的組件。為了現代化日益復雜的數據倉庫，供應商嘗試生產預構建的模板和數據倉庫生成器，這些示例包括Idera、Magnitude和Attunity。盡管在某些用例中取得成功，但這些都沒有取得市場主導地位。

此外，DevOps和DataOps致力于幫助數據倉庫模式演變，以及使數據倉庫環境以可控方式運行的其他方面。

盡管創新供應商付出巨大的努力，但數據倉庫現代化并沒有捷徑。

大型企業已經在企業數據倉庫及其相關環境中投入大量資金，但龐大的流程、程序、腳本和模式仍然是前進的重大障礙。還有一個障礙是克服數據庫管理員和IT員工當前做法的慣性。

由于企業大部分分析都依賴于數據倉庫，因此很難進行遷移。重組運營數據倉庫環境就像機械師試圖為行駛中的汽車升級發動機升級。盡管如此，數據倉庫自動化工具和現代DataOps市場正在盡力幫助企業現代化其數據倉庫環境。
責編AJX