整合公司所有業務數據，建立統壹的數據中心；
提供各種報表，有的給高管，有的給各種業務；
為網站運營提供運營數據支持，就是通過數據讓運營者及時了解網站和產品的運營效果；
為各項業務提供線上或線下數據支持，成為公司統壹的數據交換和提供平臺；
通過數據挖掘分析用戶行為數據，降低投入成本，提高投入效果；比如定向精準廣告，用戶個性化推薦等。；
開發數據產品，使公司直接或間接受益；
搭建開放的數據平臺，開放公司數據；
。。。。。。
上面列舉的內容看起來和傳統行業數據倉庫差不多，都要求數據倉庫/數據平臺有良好的穩定性和可靠性；但是在互聯網行業，除了數據量大，越來越多的業務要求時效性，甚至很多業務要求實時性。另外，互聯網行業的業務變化非常快，不可能像傳統行業那樣，采用自頂向下的方法壹勞永逸地建立數據倉庫。它要求新業務能很快融入數據倉庫，老的線下業務能很容易從現有數據倉庫下線；
互聯網行業的數據倉庫其實就是所謂的敏捷數據倉庫，不僅要求對數據的快速響應，還要求對業務的快速響應。
除了對架構的技術要求，構建敏捷數據倉庫還有壹個非常重要的方面，就是數據建模。如果妳開始考慮構建壹個可以兼容所有數據和服務的數據模型，那妳就又回到了傳統數據倉庫的建設上，很難滿足對業務變化的快速響應。為了應對這種情況，壹般需要對核心持久業務進行深度建模(例如，基於網站日誌的網站統計分析模型、用戶瀏覽軌跡模型；基於公司核心用戶數據的用戶模型)，其他業務壹般采用維度+寬表的方式建立數據模型。這是另壹個故事。
整體架構下圖是我們目前使用的數據平臺的架構圖。其實大部分公司應該都差不多:
邏輯上壹般有數據采集層、數據存儲與分析層、數據共享層和數據應用層。可能叫法不壹樣，但角色基本是壹樣的。
我們從下往上看:
數據采集數據采集層的任務是將各種數據源的數據采集存儲到數據存儲中，在此期間可能會做壹些簡單的清理。
數據來源有很多種:
網站日誌:
作為互聯網行業，網站日誌所占份額最大，網站日誌存儲在多個網站日誌服務器上。
壹般在每個網站日誌服務器上部署flumeagent，實時收集網站日誌，並存儲在HDFS上。
商業數據庫:
還有各種類型的業務數據庫，如Mysql、Oracle、SqlServer等。此時，我們迫切需要壹個工具，可以將各種數據庫的數據同步到HDFS。Sqoop就是其中之壹，但是Sqoop太重了，而且無論數據大小，都需要啟動MapReduce來執行，Hadoop集群中的每臺機器都需要訪問業務數據庫。對於這種場景，淘寶開源的DataX是壹個很好的解決方案(請參考文章《異構數據源海量數據交換工具的下載和使用——淘寶DataTax》)。如果有資源，可以基於DataX做二次開發，會是壹個非常好的解決方案。我們目前使用的數據中心也是如此。
當然，通過配置和開發，Flume還可以將數據庫中的數據實時同步到HDFS。
來自Ftp/Http的數據源:
有可能壹些合作夥伴提供的數據需要定期通過Ftp/Http獲取，DataX也能滿足這種需求；
其他數據來源:
比如壹些手工輸入的數據，只需要提供壹個接口或者壹個小程序就可以完成。
數據存儲與分析毫無疑問，HDFS是大數據環境下數據倉庫/數據平臺最完善的數據存儲解決方案。
離線數據分析計算，也就是對實時性要求不高的部分，在我看來Hive還是首選，數據類型豐富，內置函數；具有極高壓縮比的ORC文件存儲格式；非常方便的SQL支持使得Hive基於結構化數據的統計分析比MapReduce高效很多。為壹個SQL可以完成的需求開發MR可能需要數百行代碼。
當然，使用Hadoop框架自然提供了MapReduce接口。如果妳真的樂於開發Java或者不熟悉SQL，也可以用MapReduce進行分析計算。這兩年星火很火。經過實踐，它的性能確實比MapReduce好很多，與Hive和Yarn的結合也越來越好。所以需要支持使用Spark和SparkSQL進行分析計算。因為HadoopYarn已經存在，使用Spark其實非常容易，不需要單獨部署Spark集群。關於星火紗的相關文章，請參考“星火紗系列文章”。
實時計算部分後面會單獨討論。
數據* * *這裏的享受數據* * *實際上是指存儲數據分析計算後的結果的地方，實際上是壹個關系數據庫和壹個NOSQL數據庫；
Hive、MR、Spark、SparkSQL的分析計算結果還在HDFS上，但是大部分業務和應用不可能直接從HDFS獲取數據，所以需要壹個可以共享數據的地方，讓業務和產品方便地獲取數據。與HDFS的數據采集層相反，需要壹個工具將HDFS的數據同步到其他目標數據源。同樣，DataX也可以滿足。
此外，壹些實時計算結果數據可能會被實時計算模塊直接寫入數據中以供欣賞。
數據應用
商業產品
業務產品使用的數據已經存在於數據* * *享受層，可以直接從數據* * *享受層訪問；
報告表格
同壹業務產品和報表中使用的數據壹般是統計匯總後存儲在數據共享層；
特別的
ad hoc query的用戶很多，可能是數據開發人員、網站和產品運營人員、數據分析師，甚至是部門老板。他們都有即席查詢數據的需求。
這種即席查詢通常是現有報表和數據共享層的數據無法滿足他們的需求，需要直接從數據存儲層查詢。
即席查詢壹般由SQL完成，最大的難點在於響應速度。Hive有點慢。目前我的解決方案是SparkSQL，響應速度比Hive快很多，與Hive非常兼容。
當然妳也可以用Impala，如果妳不在乎平臺裏多壹個框架的話。
OLAP
目前很多OLAP工具都不支持直接從HDFS獲取數據，都是通過把需要的數據同步到關系數據庫來做OLAP，但是如果數據量巨大，關系數據庫顯然不行；
這時候就要做相應的開發，從HDFS或者HBase獲取數據，完成OLAP的功能；
比如根據用戶在界面上選擇的不確定維度和指標，開發界面，從HBase中獲取數據進行顯示。
其他數據接口
這種接口是通用的和定制的。比如壹個從Redis獲取用戶屬性的接口是通用的，所有的業務都可以調用這個接口來獲取用戶屬性。
實時計算現在對實時數據倉庫的需求越來越多，比如:實時了解網站的整體流量；實時獲取壹個廣告的曝光和點擊；在海量數據下，依靠傳統的數據庫和傳統的實現方式，基本上無法完成。我們需要壹個分布式、高吞吐量、低延遲和高可靠性的實時計算框架。Storm在這壹塊相對成熟，但我選擇SparkStreaming的原因很簡單，我不想在平臺中引入另壹個框架。另外，SparkStreaming比Storm稍微延遲壹點，對於我們的需求可以忽略。
目前我們使用SparkStreaming實現兩個功能:實時網站流量統計和實時廣告效果統計。
做法也很簡單。Flume在前端日誌服務器上收集網站日誌和廣告日誌，實時發送到SparkStreaming。SparkStreaming完成統計並將數據存儲在Redis中，業務通過訪問Redis實時獲取。
任務調度和監控在數據倉庫/數據平臺中，有很多種程序和任務，如數據采集任務、數據同步任務、數據分析任務等。
這些任務除了有規律的調度之外，還有非常復雜的任務依賴關系，比如:數據分析任務要在相應的數據采集任務完成後才能開始；數據同步任務只能在數據分析任務完成後啟動；這就需要壹個非常完善的任務調度和監控系統，作為數據倉庫/數據平臺的樞紐，負責調度和監控所有任務的分配和運行。
之前寫過壹篇文章《大數據平臺中的任務調度與監控》，這裏不再贅述。
綜上所述，在我看來，架構不是技術越多越新越好，而是越簡單越穩定越好，如果能滿足需求的話。目前在我們的數據平臺中，開發更註重業務而不是技術。他們明確業務和需求，基本上只需要做簡單的SQL開發，然後配置到調度系統。如果任務異常，他們會收到警報。這樣可以把更多的資源集中在業務上。
7.了解數據倉庫的含義以及數據倉庫和數據庫的區別。
答:意義數據倉庫是面向主題的、集成的、不可再生的、不斷變化的數據集，可以支持企業或組織的決策分析和處理。
差:1。數據庫只存儲當前值，數據倉庫存儲歷史值；
2.數據庫中的數據是動態的，只要有業務發生就會更新，而數據倉庫是靜態的歷史數據，只能定期添加和刷新；
3.數據庫中的數據結構復雜，有多種結構滿足業務處理系統的需要，而數據倉庫中的數據結構相對簡單；
4.數據庫中的數據被頻繁訪問但很少訪問，而數據倉庫訪問頻率低但訪問率高；
5.數據庫中的數據面向業務處理者，為業務處理者提供信息處理支持，而數據倉庫面向高級管理人員，為他們提供決策支持；
6.數據庫在訪問數據時要求快速響應，其響應時間壹般在幾秒之內，而數據倉庫的響應時間可以長達幾個小時。