Hadoop 之上的數據建模 - Data Vault 2.0

對比傳統的基於 RDBMS 之上的數據倉庫和商業智能項目，嘗試著說說，Hadoop 之上的數據倉庫，從ETL, 數據存儲，到分析展現。重點圍繞數據建模方面做分析，因為這是本文的重點，介紹一份新的數據建模方式 Data Vault 2.0.

ETL 最基本的構建來自於 轉換和工作流。

工作流，作用是規劃一條完整的數據轉換流。

轉換，是 ETL 最中心的組件。可以用 MapReduce 來完成，也可以用 Spark, Hive .而使用 Spark, Hive 的益處，是在於 Spark, Hive 能將 MapReduce 封裝起來。MapReduce 可以由多種語言編寫，Java, Python, C++等。為了完成數據轉換，而對每一次的轉換計算都去用高級語言編程，成本過高。因此用 Spark, Hive 集成的函數和 HQL 語法，完成一些數據轉換操作，針對傳統基於 RDBMS 轉醒過來的開發人員，學習成本會降低很多。

假設我們的電商系統後台是用 MySQL, 體量已經達到 10 TB。

用Sqoop 將這 10TB 同步到 Hive, 報表分析專家在分析的時候，就可以利用分散式計算優勢了。簡單的事務性事實表，通過傳統的 ETL 工具抽取完成之後，直接再由 Sqoop 轉入到 Hive.而複雜的二次聚合事實表，可以先由 Sqoop 轉入 Hive, 再由 Hive 聚合生成事實表，導入 MySQL 做分散式存儲或者報表源頭。

hadoop 作為數據倉庫，不再僅僅是分散式存儲，還可以應用生態工具，Spark,Kylin 做計算。將最終的結果或傳回傳統的 RDBMS， 或存儲到 Hive 這類分散式存儲庫里。

除了 Kim ball 的維度建模理論， Data Vault 也是數據倉庫建模的一種方法。

Data Vault 簡單實例，建模思想以及優點劣勢，如下所述：

《Hadoop 構建數據倉庫實踐》中對 Data Vault 做了一些介紹。

從關係錶轉換成 Data Vault 模型，是對 中心實體，關係產生和消亡，實體及其關係屬性的建模。

中心表 - Hubs：

實體，中心表的建模。每個實體都應該單獨作為一個中心表的一個記錄存在。

中心表，記錄實體的代理鍵和主鍵，創建時間與創建源。

鏈接表 - Links：

鏈接兩個實體的關係表。中心表是一個個獨立的代表實體的表，沒有父子關係存在，沒有關聯關係存在。因此作為審核兩個實體關係的鑒證，鏈接表必須存儲中心表的代理鍵，關係生效時間，消亡事件。

附屬表 - Satellites：

中心表，鏈接表記錄的都是一些維度主體信息，而更細粒度的維度屬性信息，事實特徵信息則由附屬表記錄。

讓我們看看維基百科上，對 Data Vault 的解釋：

https://en.wikipedia.org/wiki/Data_vault_modeling

Focused on the business process, the Data Vault as a data integration architecture, has robust standards and definitional methods which unite information in order to make sense if it. The Data Vault model is comprised of three basic table types:

HUB (blue): containing a list of unique business keys having its own surrogate key. Metadata describing the origin of the business key, or record 『source』 is also stored to track where and when the data originated.

LNK (red): establishing relationships between business keys (typically hubs, but links can link to other links); essentially describing a many-to-many relationship. Links are often used to deal with changes in data granularity reducing the impact of adding a new business key to a linked Hub.

SAT (yellow): holding descriptive attributes that can change over time (similar to a Kimball Type II slowly changing dimension). Where Hubs and Links form the structure of the data model, Satellites contain temporal and descriptive attributes including metadata linking them to their parent Hub or Link tables. Metadata attributes within a Satellite table containing a date the record became valid and a date it expired provide powerful historical capabilities enabling queries that can go 『back-in-time』.

重點來了，那麼為什麼我們需要 Data Vault 建模呢？

參考這篇文來做解釋：

https://www.talend.com/blog/2015/03/27/what-is-the-data-vault-and-why-do-we-need-it

There are several key advantages to the Data Vault approach:

- Simplifies the data ingestion process

- Removes the cleansing requirement of a Star Schema

- Instantly provides auditability for HIPPA and other regulations

- Puts the focus on the real problem instead of programming around it

- Easily allows for the addition of new data sources without disruption to existing schema

Simply put, the Data Vault is both a data modeling technique and methodology which accommodates historical data, auditing, and tracking of data.

「The Data Vault is the optimal choice for modeling the EDW in the DW 2.0 framework」

Bill Inmon

文中提出的在 big data 中遇見的現實問題

problem #1 : The one constant is change, so how well can an EDW/BI solution adapt?

當常規的應用場景變化之後，EDW/BI 還能無更改適用嗎？

我在這裡強調無更改適用，是和需求變更區分開來。

需求變化了，底層結構不可能不變化，變化多大是需要衡量的。

每一次需求變化，底層結構都要徹底重構，那麼成本是極高的。

所以在需求更替的情況下，底層結構如果能做到儘可能小的變更，這個問題就解決了。

每個行業都會有自己的業務模型，針對這些業務模型，專家們可以做出最佳實踐來設計數據結構。

一方面，最佳實踐來自於專家的經驗，經驗有來自於時間與案例。

如果這些專家的最佳實踐並沒有被公開，沒有被推廣，那麼年輕一代依舊是無法掌握的。

年輕的工程師依然需要去走一遭前人趟過的坑，才能轉化為自己的見識。

另一方面，業務是不斷變化的，昨天的最佳實踐，用到今天可能不會有太多效率的提高。

比如一直遵循的範式設計，在 OLTP 階段還能管用，但是在 OLAP 階段就不適合了。分析場景如果用範式設計，效率差的不是一個級別，有可能就是跑不出來數據。

在前人的基礎上，加上自己的一點領悟，與時俱進進行改造，才是正確的做事方法。

problem #2: Really Big Data, often characterized as :Volume, Velocity, Variety, Variability, Veracity, Visualization, & Value!

在商業應用領域，各種分析需要用到很多數據。捕獲，清晰，轉換，分析報告等各種技術是通過培訓可以理解和掌握的。這些無形的應用技術與分析手段可以成為公司競爭的有力條件。隨著社交，醫療，互聯網金融的發展，數據的應用越來越多，數據的格式也越來越多樣化。大數據行業帶來的是傳統數據應用技術無法交付的挑戰。數據應用技術究竟在大數據時代該怎麼規範，怎麼適應潮流發展，是不是還有傳統數據應用的規律可循？都等著去發現。

problem #3: Complexity

基於大數據的 ETL, Data Modeling, Reporting 都會變得比以往複雜。

僅僅是 ETL, 就涉及到了傳統資料庫與 NoSQL, Hadoop, Hive 的交互。這些交互使用的工具與編程語言是有很多選擇性的。比如可以用使用 Java 編寫 MapReduce, Sqoop 連接 RDBMS 和 Hadoop, 還可以應用 Talend, Kettle 等 ETL 工具。報表分析工具隨著分析需求的變化，又變得多樣化。傳統的報表工具， BO, SSRS 可能已經不能滿足需求，起碼這部分工具是直連 RDBMS 而不能直連到 HDFS. 可視化的要求，可能涉及到自定義圖像需求，比如聚合，分類，圖連接，都需要藉助 d3.js, Echarts 等的 Javascript 編程實現。Python, R 等用來分析機器學習結果，也都開發了自己的庫。

problem #4： The Business Domain:

業務分析需求多樣化。

人工智慧與機器學習當下火熱的兩個領域，分析需求是多樣化而且多變性的。

每個學習模型需要的數據格式，可能都需要大量隨時可靈活變化。而機器學習專家們是不會去做數據收集這麼繁瑣的工作，理解他們的需求就變的更有成本。往往給非所需，詞不達意。這是更需要數據模型的靈活性建模，在每個需求變化了之後，原先模型都能快速轉變為可用的數據原型，供數據科學家使用。

problem #5: Flexibility

綜合前面四點，我們要做的就是彈性化的設計方案，ETL ，Data Modeling ，分析與報表都要彈性化。需求隨時有變化，上游數據結構也會隨時變化以適應需求的更改，因此作為數據應用下游的數據倉庫，在設計方面需要考慮到靈活性與可擴展性。而整個數據倉庫設計的中心，就是數據建模。一來數據模型是 ETL 的目標結構，可以說 ETL 的設計就是基於數據模型而開展的；二來數據模型是數據分析的基石，決定了報表邏輯以及機器學習等數據挖掘工具的數據輸入格式。

以及 Data Vault 對這幾個現實問題的解決方案

problem #1 : The one constant is change, so how well can an EDW/BI solution adapt?

我們將實體分為三種存在形式：一是實體的 key 值，二是實體的屬性值， 三是實體的 relationship(關係）。Data Vault 2.0 將這些都分開存儲，解決了耦合的複雜度，變得更加靈活與可擴展，也就是彈性化程度更高了。

key, relationship都是固定的幾列值，相對穩定。

實體的屬性值是可以隨時變化的，而這種變化反映在Data Vault 2.0 模型上，就是增加幾個列。

所以可擴展性非常高。

problem #2: big data

傳統的 BI 工具，在ETL 方向上是需要做臟數據處理的，比如刪掉一些不符合邏輯的數據。而 Data Vault 2.0 是基於客觀事實做的數據增量抽取，不做邏輯校驗，因此可以大規模的抽取和處理數據，更符合大數據特徵。

problem #3: Complexity:

傳統的 BI 工具，建模會有很多的可變性，比如 SCD(Slowly Change Dimension), Fact 表的多變性。而 Data Vault 2.0 就只有 Hub, Link, SAT(Satellite), Link-Satellite 表。區分清楚這些表，剩下的重點就只有設計和調度 ETL了。在建模這一步反而更簡單了。

problem #4: The business Domain:

我們不應該把 Data Vault 當做處理臟數據的地方，他僅僅是反映了上游系統數據的真實性，無論是正確還是邏輯錯誤的數據，都應該在 Data Vault 數據倉庫裡面反映出來。基於Data Vault 2.0 模型，很快就可以生成業務分析需要的數據模型。這才是需要處理驗證邏輯的地方。

problem #5: The Flexibility

Data Vault 2.0 是聯合了 Six Sigma, TQM, SDLC 制定的符合 SEI/CMMI Level 5的標準。有著更短的發布周期，一般2-3周即可發布。因此更快更方便的更替業務需求。

推薦閱讀：