是資料倉庫系統的基礎，是整個系統的資料來源泉。通常包括企業內部資訊和外部資訊。內部資訊包括存放於RDBMS中的各種業務處理資料和各類文件資料。外部資訊包括各類法律法規、市場資訊和競爭對手的資訊等等；資料的儲存與管理是整個資料倉庫系統的核心。資料倉庫的真正關鍵是資料的儲存和管理。資料倉庫的組織管理方式決定了它有別於傳統資料庫，同時也決定了其對外部資料的表現形式。要決定採用什麼產品和技術來建立資料倉庫的核心，則需要從資料倉庫的技術特點著手分析。針對現有各業務系統的資料，進行抽取、清理，並有效整合，按照主題進行組織。資料倉庫按照資料的覆蓋範圍可以分為企業級資料倉庫和部門級資料倉庫（通常稱為資料集市）。OLAP伺服器對分析需要的資料進行有效整合，按多維模型予以組織，以便進行多角度、多層次的分析，並發現趨勢。其具體實現可以分為：ROLAP（關係型線上分析處理）、MOLAP（多維線上分析處理）和HOLAP（混合型線上分析處理）。ROLAP基本資料和聚合資料均存放在RDBMS之中；MOLAP基本資料和聚合資料均存放於多維資料庫中；HOLAP基本資料存放於RDBMS之中，聚合資料存放於多維資料庫中。 元資料是描述資料倉庫內資料的結構和建立方法的資料。可將其按用途的不同分為兩類，技術元資料和商業元資料。技術元資料是資料倉庫的設計和管理人員用於開發和日常管理資料倉庫使用的資料。包括：資料來源資訊；資料轉換的描述；資料倉庫內物件和資料結構的定義；資料清理和資料更新時用的規則；源資料到目的資料的對映；使用者訪問許可權，資料備份歷史記錄，資料匯入歷史記錄，資訊釋出歷史記錄等。商業元資料從商業業務的角度描述了資料倉庫中的資料。包括：業務主題的描述，包含的資料、查詢、報表；

一直想整理一下這塊內容，既然是漫談，就想起什麼說什麼吧。我一直是在網際網路行業，就以網際網路行業來說。先大概列一下網際網路行業資料倉庫、資料平臺的用途：

整合公司所有業務資料，建立統一的資料中心；

提供各種報表，有給高層的，有給各個業務的；

為網站運營提供運營上的資料支援，就是透過資料，讓運營及時瞭解網站和產品的運營效果；

為各個業務提供線上或線下的資料支援，成為公司統一的資料交換與提供平臺；

分析使用者行為資料，透過資料探勘來降低投入成本，提高投入效果；比如廣告定向精準投放、使用者個性化推薦等；

開發資料產品，直接或間接為公司盈利；

建設開放資料平臺，開放公司資料；

。。。。。。

上面列出的內容看上去和傳統行業資料倉庫用途差不多，並且都要求資料倉庫/資料平臺有很好的穩定性、可靠性；但在網際網路行業，除了資料量大之外，越來越多的業務要求時效性，甚至很多是要求實時的 ，另外，網際網路行業的業務變化非常快，不可能像傳統行業一樣，可以使用自頂向下的方法建立資料倉庫，一勞永逸，它要求新的業務很快能融入資料倉庫中來，老的下線的業務，能很方便的從現有的資料倉庫中下線；

其實，網際網路行業的資料倉庫就是所謂的敏捷資料倉庫，不但要求能快速的響應資料，也要求能快速的響應業務；

建設敏捷資料倉庫，除了對架構技術上的要求之外，還有一個很重要的方面，就是資料建模，如果一上來就想著建立一套能相容所有資料和業務的資料模型，那就又回到傳統資料倉庫的建設上了，很難滿足對業務變化的快速響應。應對這種情況，一般是先將核心的持久化的業務進行深度建模（比如：基於網站日誌建立的網站統計分析模型和使用者瀏覽軌跡模型；基於公司核心使用者資料建立的使用者模型），其它的業務一般都採用維度+寬表的方式來建立資料模型。這塊是後話。

整體架構下面的圖是我們目前使用的資料平臺架構圖，其實大多公司應該都差不多：

邏輯上，一般都有資料採集層、資料儲存與分析層、資料共享層、資料應用層。可能叫法有所不同，本質上的角色都大同小異。

我們從下往上看：

資料採集資料採集層的任務就是把資料從各種資料來源中採集和儲存到資料儲存上，期間有可能會做一些簡單的清洗。

資料來源的種類比較多：

網站日誌：

作為網際網路行業，網站日誌佔的份額最大，網站日誌儲存在多臺網站日誌伺服器上，

一般是在每臺網站日誌伺服器上部署flume agent，實時的收集網站日誌並存儲到HDFS上；

業務資料庫：

業務資料庫的種類也是多種多樣，有Mysql、Oracle、SqlServer等，這時候，我們迫切的需要一種能從各種資料庫中將資料同步到HDFS上的工具，Sqoop是一種，但是Sqoop太過繁重，而且不管資料量大小，都需要啟動MapReduce來執行，而且需要Hadoop叢集的每臺機器都能訪問業務資料庫；應對此場景，淘寶開源的DataX，是一個很好的解決方案（可參考文章 《異構資料來源海量資料交換工具-Taobao DataX 下載和使用》），有資源的話，可以基於DataX之上做二次開發，就能非常好的解決，我們目前使用的DataHub也是。

當然，Flume透過配置與開發，也可以實時的從資料庫中同步資料到HDFS

來自於Ftp/Http的資料來源：

有可能一些合作伙伴提供的資料，需要透過Ftp/Http等定時獲取，DataX也可以滿足該需求;

其他資料來源：

比如一些手工錄入的資料，只需要提供一個介面或小程式，即可完成

資料儲存與分析毋庸置疑，HDFS是大資料環境下資料倉庫/資料平臺最完美的資料儲存解決方案。

離線資料分析與計算，也就是對實時性要求不高的部分，在我看來，Hive還是首當其衝的選擇，豐富的資料型別、內建函式；壓縮比非常高的ORC檔案儲存格式；非常方便的SQL支援，使得Hive在基於結構化資料上的統計分析遠遠比MapReduce要高效的多，一句SQL可以完成的需求，開發MR可能需要上百行程式碼；

當然，使用Hadoop框架自然而然也提供了MapReduce介面，如果真的很樂意開發Java，或者對SQL不熟，那麼也可以使用MapReduce來做分析與計算；Spark是這兩年非常火的，經過實踐，它的效能的確比MapReduce要好很多，而且和Hive、Yarn結合的越來越好，因此，必須支援使用Spark和SparkSQL來做分析和計算。因為已經有Hadoop Yarn，使用Spark其實是非常容易的，不用單獨部署Spark叢集，關於Spark On Yarn的相關文章，可參考：《Spark On Yarn系列文章》

實時計算部分，後面單獨說。

資料共享這裡的資料共享，其實指的是前面資料分析與計算後的結果存放的地方，其實就是關係型資料庫和NOSQL資料庫；

前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取資料，那麼就需要一個數據共享的地方，使得各業務和產品能方便的獲取資料； 和資料採集層到HDFS剛好相反，這裡需要一個從HDFS將資料同步至其他目標資料來源的工具，同樣，DataX也可以滿足。

另外，一些實時計算的結果資料可能由實時計算模組直接寫入資料共享。

資料應用

業務產品

業務產品所使用的資料，已經存在於資料共享層，他們直接從資料共享層訪問即可；

報表

同業務產品，報表所使用的資料，一般也是已經統計彙總好的，存放於資料共享層；

即席查詢

即席查詢的使用者有很多，有可能是資料開發人員、網站和產品運營人員、資料分析人員、甚至是部門老大，他們都有即席查詢資料的需求；

這種即席查詢通常是現有的報表和資料共享層的資料並不能滿足他們的需求，需要從資料儲存層直接查詢。

即席查詢一般是透過SQL完成，最大的難度在於響應速度上，使用Hive有點慢，目前我的解決方案是SparkSQL，它的響應速度較Hive快很多，而且能很好的與Hive相容。

當然，你也可以使用Impala，如果不在乎平臺中再多一個框架的話。

OLAP

目前，很多的OLAP工具不能很好的支援從HDFS上直接獲取資料，都是透過將需要的資料同步到關係型資料庫中做OLAP，但如果資料量巨大的話，關係型資料庫顯然不行；

這時候，需要做相應的開發，從HDFS或者HBase中獲取資料，完成OLAP的功能；

比如：根據使用者在介面上選擇的不定的維度和指標，透過開發介面，從HBase中獲取資料來展示。

其它資料介面

這種介面有通用的，有定製的。比如：一個從Redis中獲取使用者屬性的介面是通用的，所有的業務都可以呼叫這個介面來獲取使用者屬性。

實時計算現在業務對資料倉庫實時性的需求越來越多，比如：實時的瞭解網站的整體流量；實時的獲取一個廣告的曝光和點選；在海量資料下，依靠傳統資料庫和傳統實現方法基本完成不了，需要的是一種分散式的、高吞吐量的、延時低的、高可靠的實時計算框架；Storm在這塊是比較成熟了，但我選擇Spark Streaming，原因很簡單，不想多引入一個框架到平臺中，另外，Spark Streaming比Storm延時性高那麼一點點，那對於我們的需要可以忽略。

我們目前使用Spark Streaming實現了實時的網站流量統計、實時的廣告效果統計兩塊功能。

做法也很簡單，由Flume在前端日誌伺服器上收集網站日誌和廣告日誌，實時的傳送給Spark Streaming，由Spark Streaming完成統計，將資料儲存至Redis，業務透過訪問Redis實時獲取。

任務排程與監控在資料倉庫/資料平臺中，有各種各樣非常多的程式和任務，比如：資料採集任務、資料同步任務、資料分析任務等；

這些任務除了定時排程，還存在非常複雜的任務依賴關係，比如：資料分析任務必須等相應的資料採集任務完成後才能開始；資料同步任務需要等資料分析任務完成後才能開始； 這就需要一個非常完善的任務排程與監控系統，它作為資料倉庫/資料平臺的中樞，負責排程和監控所有任務的分配與執行。

前面有寫過文章，《大資料平臺中的任務排程與監控》,這裡不再累贅。

總結在我看來架構並不是技術越多越新越好，而是在可以滿足需求的情況下，越簡單越穩定越好。目前在我們的資料平臺中，開發更多的是關注業務，而不是技術，他們把業務和需求搞清楚了，基本上只需要做簡單的SQL開發，然後配置到排程系統就可以了，如果任務異常，會收到告警。這樣，可以使更多的資源專注於業務之上。