「編譯」邏輯數據倉庫-全集數據統一視圖之路

譯自:The Logical Data Warehouse – Towards a Single View of All the Data

原文:https://www.red-gate.com/simple-talk/cloud/cloud-data/the-logical-data-warehouse-towards-a-single-view-of-all-the-data/

編譯:Ling


企業數據倉庫到底出了哪些問題呢?問題看起來似乎相當多。簡單來講,當數據量過大時,存儲和查詢都會出現困難,更別提我們還要解決數據質量、數據安全等問題。這個時候提倡諸如虛擬數據倉庫和邏輯數據倉庫這樣的方案就會很有意義了。

一、前言

多年來,傳統的EDW(Enterprise Data Warehouse,企業數據倉庫)一直是綜合商業智能(BI)解決方案的中流砥柱,它可以提供一個所有人都能相信並使用的中央儲存庫。但在當今信息已然過載的世界中,EDW幾乎無法跟上大數據數量及多樣性爆炸性的增長,這就導致IT技術人員苦苦尋找其他高度靈活、可擴展、且能夠滿足不斷增長的數據實時分析需求的BI解決方案。

在傳統的EDW平臺中,數據可能來自事務型數據庫、企業內重要的軟件應用系統(line-of-business(LOB) applications)、客戶關係管理(CRM)系統、企業資源規劃(ERP)系統或其他來源。將數據加載到數據倉庫之前,需要對其進行清洗和轉換,以確保整個企業範圍內數據的可靠性、一致性和準確性。提取-轉換-加載(ETL)操作精確且高度精煉,它提供了一個穩定且可預測的環境,可以從此環境中訪問數據。

有了EDW,數據科學家和信息工作者就擁有了一個集中處理平臺,他們可以通過該平臺執行復雜的分析並生成信息豐富的報表,供需要的人過濾和鑽取數據。理論上,EDW的設計中應該包含一組粒度足夠細的歷史數據,從中可以獲取十分有意義的信息,從而證明執行和維護這個系統所需的時間和資源投入是合理的。

二、企業數據倉庫萬歲

曾幾何時,EDW也可以存儲足夠多的數據,為決策者提供瞭解趨勢和推動業務戰略所需的信息。數據經轉換之後,被加載到數據倉庫中(通常是夜間批量加載),數據分析師便可以利用各種BI工具來分析這些數據,這些數據為少量分析師提供了豐富的信息庫,他們可以隨時任意分析這些數據。然而,這樣的日子一去不復返。

在當今的互聯網環境下,數據量正在以驚人的速度增長,這在很大程度上歸功於Web2.0時代的到來以及隨之誕生的雲服務、社交網絡、移動設備和物聯網(IoT),所有這些都被列為大數據的範疇,或者更確切地說,數據量大而多樣的、分散的、以非結構化數據為主的開放性數據,帶著無比的榮耀,重新定義了這個信息時代。

信息數量不僅在以20年前無法想象的速度增長,還以各種各樣的格式散落在全球的信息孤島中,在這種情況下,我們依然期望這些信息可訪問、有意義,並且可以被呼之欲出的最新自助式BI產品(著眼於多源、多類型、不斷倍增的數據的實時分析)消費。

面對這種數據過載的情況,傳統EDW的不足之處就顯示出來了。EDW因其單一來源/單一事實的承諾而進入全盛時期,現在卻又因閱讀器、傳感器、掃描儀、社交網站、RFID標籤和無數其他數據生成器和存儲的出現而被迫退位。

EDW提供了一箇中央儲存庫來存儲清洗過的、可信任的、結構良好的數據,雖然這樣的儲存庫仍然可以起到重要作用,但畢竟我們生活的世界主要由原始的、混亂的、非結構化的數據組成。隨著“混亂數據”的不斷升級,人們對它的興趣也不斷增長,想要更好的理解它、從其中獲取價值、並根據它做出決策。這就得需要一個靈活、敏捷、經濟且相對輕鬆的解決方案,然而這些都不是EDW的強項。

實現和維護傳統的EDW平臺需要有完整的規劃和大量的投入,需要仔細思考如何對數據進行ETL操作以及投入多少資源來維持其運轉。

當新需求出現時,EDW卻難以隨之變化,這可能會給業務帶來損害;對源應用程序的修改也可能會對EDW造成嚴重破壞。基於EDW做項目,時間往往過長,當項目實現時,通常已經不能滿足當前的業務需求。這並不是說我們應該徹底拋棄傳統的EDW,而是說,當提到大數據的種種時,EDW已不能與之匹配。

三、邏輯數據倉庫萬萬歲

企業想要更好的利用大量湧入的信息,於是開始尋求其他解決方案來滿足數據需求,這些解決方案或者是傳統EDW的補充,或者是其替代品。這通常意味著企業傾向於轉向一種更加邏輯化的架構,去抽象出大數據領域的固有複雜性。這種架構利用一些能夠緩解數據訪問和數據管控痛點的技術來融入多元環境,例如分佈式處理、數據虛擬化以及元數據管理等技術。

2011年,Mark Beyer在參與Gartner公司關於“大數據、極端信息以及信息能力框架”(Big Data, Extreme Information and Information Capabilities Framework)的研究時,研發了這種虛擬的BI分析基礎架構,並稱之為“邏輯數據倉庫LDW, Logical Data Warehouse)”。他在博文”Mark Beyer, Father of the Logical Data Warehouse, Guest Post,” 中提到,處理分析型數據的方法是關注信息的邏輯,而不是機制:

該架構包括甚至是擴充了企業數據倉庫,但還會添加語義數據抽象(semantic data abstraction)和分佈式處理,通過數據和數據挖掘在元數據中的維護數據資產信息。它還會監控自身的性能,首先將性能信息提供給人工管理,然後逐步實現針對服務等級預期(service level expectations)的動態配置和性能評估。這很重大。這不是信口開河。這會發生。

Beyer介紹了LDW的概念後,和Gartner的同事一起將這個想法具體化,最終確定了定義LDW平臺的七個主要模塊:

  • 儲存庫管理模塊 - 儲存庫管理是對EDW中數據儲存庫的實現,支持保持最高數據質量標準的特定用例,例如合規問題和監管事項所需的用例。假如我們不考慮數據大小的話,數據越有價值,就越有可能駐留在EDW中。
  • 數據虛擬化模塊 - 無論數據類型和位置如何,不管是結構化、半結構化還是非結構化數據,數據虛擬化就是來自分佈式源的單一數據視圖。數據仍保留在源系統中,可以包括Hadoop集群、關係型數據庫,NoSQL數據庫、雲服務、數據湖、文件服務器、社交網絡或任意數量的系統。
  • 分佈式處理模塊 - 分佈式處理是一種將數據處理下推到數據所在的源系統中進行數據查詢和數據分析的方法。如果查詢跨越多個數據源,則每個系統都可以處理自己的數據塊,並將所有系統的處理結果聚合到一個統一數據集裡。
  • 元數據管理模塊 - 元數據管理系統用於維護跨所有類數據服務的元數據,從而使分佈式處理和數據虛擬化更容易進行。元數據還可用於保證數據質量,支持數據治理和主數據管理。
  • 分類/本體解析(Taxonomy/ontology resolution)模塊 - 分類/本體解析系統是一個將數據資產分類與用例本體相關聯的系統,以便有效地聯合來自多個源的數據。從這個過程中派生出的元數據有助於在有效數據存儲中定位數據資產,以及支持審計和服務級別協議(SLA)服務。
  • 審計和性能服務模塊 - 此模塊用於收集LDW其他模塊性能的統計信息,同時也可以記錄連接的用戶和應用程序的使用方式。
  • SLA管理模塊 - SLA管理模塊用於追蹤連接的應用程序和用戶的預期,根據審計統計數據監控相關的SLA性能,並據此提出建議或自動優化操作。

雖然數據虛擬化和分佈式處理作為單獨的模塊列出來,但這兩種技術通常合併在一起使用。例如已經添加到SQL Server 2016中的Microsoft PolyBase,它允許從數據庫表結構內部訪問Hadoop集群,提供了數據的虛擬化視圖,同時將處理下推到數據所在的集群中進行。

還有就是Denodo,Denodo是一個成熟的數據虛擬化解決方案,與PolyBase一樣,它也將處理下推到數據所在的系統,不管這個系統是事務型數據庫、EDW解決方案 還是Hadoop集群。

在LDW架構中,Gartner所確定的其他模塊跟數據虛擬化和分佈式處理兩個模塊同樣重要,要完整的實現LDW架構,就需要全部或者大多數模塊相互結合,通過跨數據源來支持自助BI、預測分析和實時決策制定。這並不是說LDW必須以特定的方式實現,而是需要用這些模塊有機組合,形成一個邏輯整體。

LDW力求在不把數據從原始數據孤島中搬運出來的情況下,提供所有數據的單一視圖,使查詢一個或多個數據源就像是查詢關係型數據庫一樣輕鬆。只有在邏輯層面上處理數據,才能實現大數據時代所需的靈活性和可擴展性。

四、邏輯數據倉庫之名

技術在發展過程中面臨的一種挑戰是其概念會讓人產生極大的困惑,比如LDW以及Gartner提出過的其他概念。和物聯網一樣,LDW也需要有一個簡明的定義,即使是外行人也能根據其定義對LDW的實現結構有一個相對清晰的認識。它是SQL Server這一類的產品嗎?還是像Salesforce這樣的雲服務?或者它更像是一個數據庫抽象層或者說是虛擬化技術?後面這種說法相對更有吸引力,因為LDW通常又被稱為虛擬數據倉庫(VDW),雖然它還有“數據層”、“數據湖”等許多其他名稱。

但VDW畢竟有點曲折的歷史,所以這種叫法尤其讓人覺得有問題。實際上VDW已經存在了一段時間,並且跟LDW一樣,VDW承諾會完成EDW所不能完成的任務,也就是將數據統一到一個通用的虛擬儲存庫中。

然而,與LDW不同的是,VDW主要關注的是關係型數據庫,而不是大量的大數據孤島。通過將多個數據庫串聯起來,VDW承諾快速簡單的執行項目,不必操心傳統EDW所有那些惱人的集成細節。數據保留在各自的存儲中,不同的應用程序可以虛擬的連在一起,並且可以避免EDW大量消耗資源的情況。

可惜的是,VDW也有不足之處,比如它的性能就不算很完善。想象一下,假如你嘗試利用一個查詢同時訪問多個數據庫,響應時間可能會變化,緩存可能不一致,並且一個系統停機可能會造成整個操作的停止。

VDW更大的問題在於,它也未能解決傳統EDW最大的難題,即清洗所有數據。同步多個數據庫(每個數據庫都有自己真實數據的版本),可能會將最基本的查詢變成不可預測和不可靠的分析結果。無論在哪裡清洗數據,我們總要在某一時刻對數據進行清洗以獲取有價值的信息。

當然,VDW還有很多其他問題,但重點是,我們應該謹慎對待在LDW中加上 VDW的標籤,並希望LDW可以避免VDW存在的所有缺陷。

人們也常拿數據湖與LDW作比較,數據湖是一個存儲大量非結構化數據的儲存庫,通常出現在Hadoop基礎架構中。數據湖可以支持所有類型的數據,並且有能力對這些數據進行轉換,並根據需要定義數據結構。谷歌和雅虎是最先進行“數據湖運動”(data lake movement)的公司,但是之後甚至是微軟都帶著的AzureData Lake服務加入其中,現在正在公開試運行中。根據Microsoft的說法,你可以利用該服務來存儲和分析任何類型或大小的數據。

Azure Data Lake和其他技術一起構建於Hadoop YARN(YetAnother Resource Negotiator)之上。YARN是一個集群管理服務器,是Hadoop 2框架的一部分,它利用Hadoop的線性擴展存儲和處理,解耦了許多MapReduce組件,允許多個第三方引擎使用Hadoop作為訪問數據的通用標準。

LDW的分佈式處理組件很適合應用在數據湖上。實際上,數據湖在處理數據方面非常有效並且可以以相對較低的成本實現,因此LDW平臺可以將其大部分數據清洗和轉換操作推送到數據湖,甚至對EDW中的數據也可以進行這樣的操作。當然,我們需要在進行這些操作與移動數據的成本之間進行權衡,但其潛力是存在的,也必定會是有利的。

Hadoop 2和YARN框架使得數據訪問、數據處理和數據聯邦比以往更高效,但數據湖不是LDW,也不是EDW的替代品。數據湖通常是LDW解決方案中非常重要的一部分,但也只是一個組成部分。

也就是說,將LDW與VDW或數據湖區分開,並沒有給出LDW的具像。實際上,要得出這個“具像”並不容易,因為從整體上看,LDW既是一個概念或是一種倡導,也是一種物理實現。這就是為什麼“邏輯”這個詞在LDW這個名稱中如此突出。

也許我們最好把LDW看作是一個由各個部分相結合組成的邏輯結構,包括EDW、雲服務、Hadoop集群、數據湖以及其他元素,某些組成部分有虛擬化數據和分發處理的能力。然而,僅這些元素並不能完成LDW架構。因此,我們還要尋求其他產品。

例如ThoughtWeb提供的Enterprise Analytics Studio,這是一種用於集中管理、設計和構建企業LDW的軟件解決方案。該解決方案可以利用結構化和非結構化數據,組織和轉換數據,應對SLA管理以及分類/本體解析。

MarkLogic也提供了一個LDW解決方案,將其作為一個可搜索的企業數據層,這個數據層提供了各種數據孤島的統一視圖。MarkLogic解決方案中包括NoSQL數據庫、元數據目錄和儲存庫、Web服務以及用於連接遠程數據源的工具。它還可以接收大量數據,轉換和聚合數據,並將其提供給多個應用程序。

甚至Cisco也攜其數據虛擬化平臺加入了舞臺。據介紹,該平臺支持LDW的每個模塊,包括儲存庫管理、分佈式處理,當然還有數據虛擬化。

【小編語:當然,還有來自敏捷大數據團隊的 Moonbox 計算服務平臺,也是支持了數據虛擬化、分佈式處理、元數據管理以及審計功能,為用戶帶來虛擬數據庫般使用體驗,用戶只需通過統一SQL語言,即可透明實現跨異構數據系統混算和寫出,可以成為LDW架構中非常重要的一部分。】

這些解決方案看起來似乎很完整,但它們本身並不是整個LDW平臺,而是為系統提供動力的組件,目的是使所有數據完美的發揮作用。這些解決方案中的任何一個都不能絕對定義LDW,沒有一種架構可以定義LDW應該如何組成。它是可變的、可適的、可塑的,是大數據這道菜中必不可少的成分。

五、大數據世界

隨著Hadoop的YARN,微軟的PolyBase和Denodo數據虛擬化平臺等技術的不斷湧現,以及來自Cisco,ThoughtWeb和MarkLogic等公司解決方案的不斷提出,將不同系統整合到LDW平臺的能力將持續增長。確實,全球數據越來越多,除了從邏輯平臺上進行數據虛擬化、分佈式處理和數據治理之外,我們還有什麼選擇呢?

不過,隨LDW而來的,是我們不得不解決的問題:如何在適當控制訪問的基礎上確保數據安全?如何處理遠程分析所需的歷史數據?如何處理隱私、合規和監管問題?如何處理孤島之間存在的數據不一致問題?我們是否完全忽視了數據質量?

在解決這些問題之前,LDW可能面臨與VDW相同的命運。然而,如果能在不影響性能的前提下很好的解決這些問題,LDW將有望成為企業把控不斷湧入的大數據的重要工具。那麼,接下來的問題,就是該如何運用好這些送上門來的新信息以發揮更大的作用了。



分享到:


相關文章: