美團的技術架構圖

flume

可以採集檔案，socket資料包等各種形式源資料，又可以將採集到的資料輸出到HDFS、hbase、hive、kafka佇列等眾多外部儲存系統中,一般的採集需求，通過對flume的簡單配置即可實現,Flume針對特殊場景也具備良好的自定義擴充套件能力，因此，flume可以適用於大部分的日常資料採集場景

sqoop

sqoop是apache旗下一款“Hadoop和關係資料庫伺服器之間傳送資料”的工具。

匯入資料：MySQL，Oracle匯入資料到Hadoop的HDFS、HIVE、HBASE等資料儲存系統；

匯出資料：從Hadoop的檔案系統中匯出資料到關係資料庫

資料倉庫

資料倉庫，英文名稱Data Warehouse，簡寫為DW。資料倉庫顧名思義，是一個很大的資料儲存集合，出於企業的分析性報告和決策支援目的而建立，對多樣的業務資料進行篩選與整合。它為企業提供一定的BI（商業智慧）能力，指導業務流程改進、監視時間、成本、質量以及控制。

資料倉庫的輸入方是各種各樣的資料來源，最終的輸出用於企業的資料分析、資料探勘、資料報表等方向。

那麼，資料倉庫都有什麼特點呢？

1.主題性

不同於傳統資料庫對應於某一個或多個專案，資料倉庫根據使用者實際需求，將不同資料來源的資料在一個較高的抽象層次上做整合，所有資料都圍繞某一主題來組織。

這裡的主題怎麼來理解呢？比如對於滴滴出行，“司機行為分析”就是一個主題，對於鏈家網，“成交分析”就是一個主題。

2.整合性

資料倉庫中儲存的資料是來源於多個數據源的整合，原始資料來自不同的資料來源，儲存方式各不相同。要整合成為最終的資料集合，需要從資料來源經過一系列抽取、清洗、轉換的過程。

3.穩定性

資料倉庫中儲存的資料是一系列歷史快照，不允許被修改。使用者只能通過分析工具進行查詢和分析。

4.時變性

資料倉庫會定期接收新的整合資料，反應出最新的資料變化。這和特點並不矛盾。

資料倉庫的資料要通過ETL來產生，詳細請見

ETL(Extraction-Transformation-Loading)

ETL是將業務系統的資料經過抽取、清洗轉換之後載入到資料倉庫的過程，目的是將企業中的分散、零亂、標準不統一的資料整合到一起，為企業的決策提供分析依據。 ETL是BI專案重要的一個環節。 通常情況下，在BI專案中ETL會花掉整個專案至少1/3的時間,ETL設計的好壞直接關接到BI專案的成敗。       

資料倉庫和ODS的區別

DW

資料倉庫儲存是一個面向主題的，反映歷史變化資料，用於支撐管理決策。

ODS

操作型資料儲存，儲存的是當前的資料情況，給使用者提供當前的狀態，提供即時性的、操作性的、整合的全體資訊的需求。

ODS作為資料庫到資料倉庫的一種過渡形式，與資料倉庫在物理結構上不同，能提供高效能的響應時間,ODS設計採用混合設計方式。

ODS中的資料是"實時值",而資料倉庫的資料卻是"歷史值"，一般ODS中儲存的資料不超過一個月，而資料倉庫為10年或更多.

Data Mart

為了特定的應用目的或應用範圍，而從資料倉庫中獨立出來的一部分資料，也可稱為部門資料或主題資料（subjectarea）。在資料倉庫的實施過程中往往可以從一個部門的資料集市著手，以後再用幾個資料集市組成一個完整的資料倉庫。需要注意的就是在實施不同的資料集市時，同一含義的欄位定義一定要相容，這樣再以後實施資料倉庫時才不會造成大麻煩。

DSS(decision-support system)決策支援系統：

用於支援管理決策的系統。通常，DSS包括以啟發的方式對大量的資料單元進行的分析，通常不涉及資料更新。

參考一：http://www.cnblogs.com/liqiu/p/4947801.html

(本部分為轉)我在公司的資料部門工作，每天的訂單類資料處理流程大致如下：

1. 刪除分析資料庫的歷史訂單資料
2. 全量更新訂單資料到分析資料庫。（由於訂單核心資料不大，所以經受得起這麼折騰）
3. 將資料簡單清洗，並生成資料集市層
4. 分析處理，產出報表。當然還有其他的資料也是這麼處理的（比如產品的資料、景區的資料、票種的資料、供應商的資料等等）

還有日誌類的資料，這裡不是重點，就不介紹了！這麼幹了一年，發現有如下問題：

• 業務變化很快，比如業務資料表經常變化欄位含義、增加各種邏輯資料等
• 業務資料來源越來越多，隨著品類越來越多，新部門逐步成立，資料來源也就越來越多樣化
• 需求越來越多，越來越複雜，以前只有大佬想我們要戰略資料，可是現在所有的產品和運營都向我們要各種各樣的使用者行為資料、訂單分析資料和競對優勢資料
• 資料的實時行要求越來越高，這到不是說秒級別就看見結果，而是早晨提出個新業務資料需求，晚上就要！

資料畢竟是為了市場服務的，所以需求我們要跟上它的節奏，這就對資料系統提出了很大的挑戰，導致資料質量下降、生產效率下降！該怎麼解決哪？在解決這個問題的過程中，逐步發現了一點苗頭：發現我們建立的資料倉庫與它的定義不太符合。下面是資料倉庫的定義：

資料倉庫（Data Warehouse）：是一個面向主題的（Subject Oriented）、整合的（Integrated）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的資料集合，用於支援管理決策(Decision Making Support)。

很明顯我們並不符合相對穩定的和反應歷史變化的兩個條件，因為類似訂單類資料，每天全量更新（原因是同一個訂單狀態隨著時間會變化，比如今天買了，明天退貨了）。這就明顯不符合想對穩定這一概念了，更別說反應歷史變化了！經過最近的思考，發現自己搭建的系統更符合ODS的定義：

ODS：是一個面向主題的、整合的、可變的、當前的細節資料集合，用於支援企業對於即時性的、操作性的、整合的全體資訊的需求。

那麼大家可能會問ods和資料倉庫的區別是什麼哪？答：ods是短期的實時的資料，供產品或者運營人員日常使用，而資料倉庫是供戰略決策使用的資料；ods是可以更新的資料，資料倉庫是基本不更新的反應歷史變化的資料，還有很多，這裡就不一一列舉了。

講到這裡問題就明晰了，如何能搭建一個體系，既能支援戰略決策使用的資料倉庫資料，又能相容業務快速的變化和運營產品人員日常需求的ODS資料哪？

資料倉庫和ODS並存方案

經過調研，發現大體上有三種解法：

1、業務資料 － ODS － 資料倉庫

優點：這樣做的好處是ODS的資料與資料倉庫的資料高度統一；開發成本低，至少開發一次並應用到ODS即可；可見ODS是發揮承上啟下的作用，調研阿里巴巴的資料部門也是這麼實現的。

缺點：資料倉庫需要的所有資料都需要走ODS，那麼ODS的靈活性必然受到影響，甚至不利於擴充套件、系統的靈活性差

2、OB － ODS

優點：結構簡單。一般的初創資料分析團隊都是類似的結構，比如我們部門就應該歸結到這一範疇

缺點：這樣所有資料都歸結到ODS，長期資料決策分析能力差，軟硬體成本高，模組劃分不清晰，通用性差

3、資料倉庫和ODS並行

可見這個模型兼顧了上面提高的各自優點，且便於擴充套件，ODS和資料倉庫各做各的，形成優勢互補！可以解決現在網際網路公司遇到的快速變化、快速開發等特點！特別是對於那些剛剛建立資料團隊，資料開發人員緊缺的公司，可以嘗試使用這個資料架構解決問題！

參考2

http://blog.csdn.net/hero_hegang/article/details/8691912

背景知識：在當今這樣一個資訊科技發展迅速的時代，資料量也在不斷的增長，面臨這樣的壓力，總是會有大神提出一些解決方案。比如高層管理人員希望能檢視整個公司的發展業績，資料倉庫(Data Warehouse, DW)正是解決該問題的主要方案，隨之DW就這樣產生了。可是時代在變，需求也會隨著改變，比如保險公司的員工希望提高自己的業績，拿更多的工資，那麼他首先希望的就是能把更多的客戶挖進來，其實這其中是有很多方法的。最基本的例子，比方說某保險公司的一個客服希望能夠以最高的成功率向客戶推薦相關的業務，一旦客戶來電，客服可以立刻從資料庫中調出該客戶的相關的一連串資訊，從而可以根據這些資訊有針對性的向客戶推薦相關的業務了，顯然，這樣的推薦方式明顯可以提高成功率。那麼問題就來了，怎麼解決這樣的問題呢？隨之，操作型資料儲存(Operational Data Store, ODS)的誕生給此類問題提供了良好的解決方案。從理論上講，這兩種解決方案到底有什麼區別呢？現在進入正題。

ODS與DW的區別主要有以下幾點：

1、資料的當前性

ODS包括的是當前或接近當前的資料，ODS反映的是當前業務條件的狀態，ODS的設計與使用者或業務的需要是有關聯的，而DW則是更多的反映業務條件的歷史資料。

2、資料的更新或載入

ODS中的資料是可以進行修改的，而DW中的資料一般是不進行更新的。ODS的更新是根據業務的需要進行操作的，而沒有必要立即更新，因此它需要一種實時或近實時的更新機制。另外，DW中的資料是按照正常的或預先指定的時間進行資料的收集和載入的。

3、資料的彙總性

ODS主要是包括一些細節資料，但是由於效能的需要，可能還包括一些彙總資料，如果包括彙總資料，可能很難保證資料的當前性和準確性。ODS中的彙總資料生命週期比較短，所以可稱作為動態彙總資料，如果細節資料經過了修改，則彙總資料同樣需要修改。而DW中的資料可稱為靜態的彙總資料。

4、資料建模

ODS是站在記錄層面訪問的角度而設計的，DW或DM則是站在結果集層面訪問的角度而設計的。ODS支援快速的資料更新，DW作為一個整體是面向查詢的。

5、查詢的事務

ODS中的事務操作比較多，可能一天中會不斷的執行相同的事務，而DW中事務的到達是可以預測的。

6、用途

ODS用於每一天的操作型決策，是一種短期的；DW可以獲取一種長期的合作廣泛的決策。ODS是策略型的，DW是戰略型的。

7、使用者

ODS主要用於策略型的使用者，比如保險公司每天與客戶交流的客服；而DW主要用於戰略型的使用者，比如公司的高層管理人員。

8、資料量（主要區別之一）

ODS只是包括當前資料，而DW儲存的是每一個主題的歷史快照；

OLTP與OLAP的介紹

    資料處理大致可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統的關係型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是資料倉庫系統的主要應用，支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。 

OLTP 系統強調資料庫記憶體效率，強調記憶體各種指標的命令率，強調繫結變數，強調併發操作；
OLAP 系統則強調資料分析，強調SQL執行市場，強調磁碟I/O，強調分割槽等。 

OLTP與OLAP之間的比較：   

    OLTP，也叫聯機事務處理（Online Transaction Processing），表示事務性非常高的系統，一般都是高可用的線上系統，以小的事務以及小的查詢為主，評估其系統的時候，一般看其每秒執行的Transaction以及Execute SQL的數量。在這樣的系統中，單個數據庫每秒處理的Transaction往往超過幾百個，或者是幾千個，Select 語句的執行量每秒幾千甚至幾萬個。典型的OLTP系統有電子商務系統、銀行、證券等，如美國eBay的業務資料庫，就是很典型的OLTP資料庫。
OLTP系統最容易出現瓶頸的地方就是CPU與磁碟子系統。
（1）CPU出現瓶頸常表現在邏輯讀總量與計算性函式或者是過程上，邏輯讀總量等於單個語句的邏輯讀乘以執行次數，如果單個語句執行速度雖然很快，但是執行次數非常多，那麼，也可能會導致很大的邏輯讀總量。設計的方法與優化的方法就是減少單個語句的邏輯讀，或者是減少它們的執行次數。另外，一些計算型的函式，如自定義函式、decode等的頻繁使用，也會消耗大量的CPU時間，造成系統的負載升高，正確的設計方法或者是優化方法，需要儘量避免計算過程，如儲存計算結果到統計表就是一個好的方法。
（2）磁碟子系統在OLTP環境中，它的承載能力一般取決於它的IOPS處理能力. 因為在OLTP環境中，磁碟物理讀一般都是db file sequential read，也就是單塊讀，但是這個讀的次數非常頻繁。如果頻繁到磁碟子系統都不能承載其IOPS的時候，就會出現大的效能問題。
    OLTP比較常用的設計與優化方式為Cache技術與B-tree索引技術，Cache決定了很多語句不需要從磁碟子系統獲得資料，所以，Web cache與Oracle data buffer對OLTP系統是很重要的。另外，在索引使用方面，語句越簡單越好，這樣執行計劃也穩定，而且一定要使用繫結變數，減少語句解析，儘量減少表關聯，儘量減少分散式事務，基本不使用分割槽技術、MV技術、並行技術及點陣圖索引。因為併發量很高，批量更新時要分批快速提交，以避免阻塞的發生。 
OLTP 系統是一個數據塊變化非常頻繁，SQL 語句提交非常頻繁的系統。 對於資料塊來說，應儘可能讓資料塊儲存在記憶體當中，對於SQL來說，儘可能使用變數繫結技術來達到SQL重用，減少物理I/O 和重複的SQL 解析，從而極大的改善資料庫的效能。
    這裡影響效能除了繫結變數，還有可能是熱快（hot block）。 當一個塊被多個使用者同時讀取時，Oracle 為了維護資料的一致性，需要使用Latch來序列化使用者的操作。當一個使用者獲得了latch後，其他使用者就只能等待，獲取這個資料塊的使用者越多，等待就越明顯。 這就是熱快的問題。 這種熱快可能是資料塊，也可能是回滾端塊。 對於資料塊來講，通常是資料庫的資料分佈不均勻導致，如果是索引的資料塊，可以考慮建立反向索引來達到重新分佈資料的目的，對於回滾段資料塊，可以適當多增加幾個回滾段來避免這種爭用。 
    OLAP，也叫聯機分析處理（Online Analytical Processing）系統，有的時候也叫DSS決策支援系統，就是我們說的資料倉庫。在這樣的系統中，語句的執行量不是考核標準，因為一條語句的執行時間可能會非常長，讀取的資料也非常多。所以，在這樣的系統中，考核的標準往往是磁碟子系統的吞吐量（頻寬），如能達到多少MB/s的流量。
    磁碟子系統的吞吐量則往往取決於磁碟的個數，這個時候，Cache基本是沒有效果的，資料庫的讀寫型別基本上是db file scattered read與direct path read/write。應儘量採用個數比較多的磁碟以及比較大的頻寬，如4Gb的光纖介面。
在OLAP系統中，常使用分割槽技術、並行技術。
    分割槽技術在OLAP系統中的重要性主要體現在資料庫管理上，比如資料庫載入，可以通過分割槽交換的方式實現，備份可以通過備份分割槽表空間實現，刪除資料可以通過分割槽進行刪除，至於分割槽在效能上的影響，它可以使得一些大表的掃描變得很快（只掃描單個分割槽）。另外，如果分割槽結合並行的話，也可以使得整個表的掃描會變得很快。總之，分割槽主要的功能是管理上的方便性，它並不能絕對保證查詢效能的提高，有時候分割槽會帶來效能上的提高，有時候會降低。
    並行技術除了與分割槽技術結合外，在Oracle 10g中，與RAC結合實現多節點的同時掃描，效果也非常不錯，可把一個任務，如select的全表掃描，平均地分派到多個RAC的節點上去。
    在OLAP系統中，不需要使用繫結（BIND）變數，因為整個系統的執行量很小，分析時間對於執行時間來說，可以忽略，而且可避免出現錯誤的執行計劃。但是OLAP中可以大量使用點陣圖索引，物化檢視，對於大的事務，儘量尋求速度上的優化，沒有必要像OLTP要求快速提交，甚至要刻意減慢執行的速度。
    繫結變數真正的用途是在OLTP系統中，這個系統通常有這樣的特點，使用者併發數很大，使用者的請求十分密集，並且這些請求的SQL 大多數是可以重複使用的。
    對於OLAP系統來說，絕大多數時候資料庫上執行著的是報表作業，執行基本上是聚合類的SQL 操作，比如group by，這時候，把優化器模式設定為all_rows是恰當的。 而對於一些分頁操作比較多的網站類資料庫，設定為first_rows會更好一些。 但有時候對於OLAP 系統，我們又有分頁的情況下，我們可以考慮在每條SQL 中用hint。 如：
    Select  a.* from table a;
分開設計與優化
    在設計上要特別注意，如在高可用的OLTP環境中，不要盲目地把OLAP的技術拿過來用。
    如分割槽技術，假設不是大範圍地使用分割槽關鍵字，而採用其它的欄位作為where條件，那麼，如果是本地索引，將不得不掃描多個索引，而效能變得更為低下。如果是全域性索引，又失去分割槽的意義。
    並行技術也是如此，一般在完成大型任務時才使用，如在實際生活中，翻譯一本書，可以先安排多個人，每個人翻譯不同的章節，這樣可以提高翻譯速度。如果只是翻譯一頁書，也去分配不同的人翻譯不同的行，再組合起來，就沒必要了，因為在分配工作的時間裡，一個人或許早就翻譯完了。
    點陣圖索引也是一樣，如果用在OLTP環境中，很容易造成阻塞與死鎖。但是，在OLAP環境中，可能會因為其特有的特性，提高OLAP的查詢速度。MV也是基本一樣，包括觸發器等，在DML頻繁的OLTP系統上，很容易成為瓶頸，甚至是Library Cache等待，而在OLAP環境上，則可能會因為使用恰當而提高查詢速度。
    對於OLAP系統，在記憶體上可優化的餘地很小，增加CPU 處理速度和磁碟I/O 速度是最直接的提高資料庫效能的方法，當然這也意味著系統成本的增加。      
    比如我們要對幾億條或者幾十億條資料進行聚合處理，這種海量的資料，全部放在記憶體中操作是很難的，同時也沒有必要，因為這些資料快很少重用，快取起來也沒有實際意義，而且還會造成物理I/O相當大。 所以這種系統的瓶頸往往是磁碟I/O上面的。
    對於OLAP系統，SQL 的優化非常重要，因為它的資料量很大，做全表掃描和索引對效能上來說差異是非常大的。
其他
    Oracle 10g以前的版本建庫過程中可供選擇的模板有：
        Data Warehouse （資料倉庫）
        General Purpose  （通用目的、一般用途）
        New Database
        Transaction Processing  （事務處理）
    Oracle 11g的版本建庫過程中可供選擇的模板有：
        一般用途或事務處理
        定製資料庫

        資料倉庫

個人對這些模板的理解為：

     聯機分析處理（OLAP,On-line Analytical Processing），資料量大，DML少。使用資料倉庫模板
     聯機事務處理（OLTP,On-line Transaction Processing），資料量少，DML頻繁，並行事務處理多，但是一般都很短。使用一般用途或事務處理模板。

     決策支援系統（DDS，Decision support system)，典型的操作是全表掃描，長查詢，長事務，但是一般事務的個數很少，往往是一個事務獨佔系統。

資料倉庫與資料集市的區別詳細請見

資料倉庫是企業級的，能為整個企業各個部門的執行提供決策支援手段；而資料集市則是一種微型的資料倉庫,它通常有更少的資料,更少的主題區域,以及更少的歷史資料,因此是部門級的，一般只能為某個區域性範圍內的管理人員服務，因此也稱之為部門級資料倉庫。資料倉庫和資料集市之間的區別如下圖：

資料倉庫和資料集市的區別可從如下三個方面進行理解：
（1） 資料倉庫向各個資料集市提供資料
（2） 幾個部門的資料集市組成一個數據倉庫
 

（3） 下面從其資料內容特徵進行分析，資料倉庫中資料結構採用規範化模式，資料集市中的資料結構採用星型模式，通常倉庫中資料粒度比集市的粒度要細，下圖反映了資料結構和資料內容特徵的區別