之前給大家講了《 ETL的靈魂：排程系統 》，今天給大家講一下數倉中的計算存儲系統。 大資料計算平台目前主要都是圍繞着hadoop生态發展的，運用HDFS作為資料存儲，計算架構分為批處理、流處理。
01 傳統的計算平台
我們都知道，沒有大資料之前，我們計算平台基本是依賴資料庫，大資料量的計算基本依賴Oracle資料庫。Oracle很強大，支撐了很多年銀行、電信業務資料的計算存儲。Oracle多以集中式架構為主，最大特點就是将所有的資料都集中在一個資料庫中，依靠大型高端裝置來提供高處理能力和擴充性。集中式資料庫的擴充性主要采用向上擴充的方式，通過增加CPU，記憶體，磁盤等方式提高處理能力。這種集中式資料庫的架構，使得資料庫成為了整個系統的瓶頸，已經越來越不适應海量資料對計算能力的巨大需求。同時傳統資料庫架構對高端裝置的依賴，無疑将直接導緻系統成本的大幅度增加，甚至可能會導緻系統被主機和硬體廠商所“綁架”，不得不持續增加投入成本。
02 Hadoop的崛起
随着網際網路行業的發展，特别是移動網際網路的快速發展，傳統資料庫面臨着海量資料的存儲成本、有限的擴充能力等問題。新的計算架構MapReduce出現了，新的存儲編碼方式HDFS出現了，二者合起來，我們一般稱之為Hadoop。
Hadoop很快憑借其高可靠性、高擴充性、成本低、高效計算等優勢在各個領域得到了廣泛應用。
03 Hive的應用
Hive最初是Facebook開源的，我們來看看Hive的特點：
- Hive是一個建構于Hadoop頂層的資料倉庫工具，可以查詢和管理PB級别的分布式資料。
- 支援類SQL語音。
- 可以看作為使用者程式設計接口，本身不存儲和處理資料
- 依賴HDFS作為存儲
我們看到Hive支援類SQL文法，我們可以很容易的把傳統關系型資料庫建立的資料倉庫任務遷移到Hadoop平台上。
Hive的架構：
我們可以看到hive提供了多種連接配接方式：JDBC、ODBC、Thrift。
那麼我們以前使用Oracle的存儲過程怎麼遷移到Hive中呢？用過Hive的同學可能都知道，Hive是沒有想Oracle那樣的遊标循環呀，是以我們必須借助其他語言來配合hive一起完成資料倉庫的ETL過程。比如這個項目：PyHive(
https://github.com/dropbox/PyHive) 借助Python，我們可以很好的彌補Hive在複雜處理的一些缺陷，同時也能更好的開發ETL任務。
是以，通過Hive我們就可以搭建起一套大資料計算平台。
04 Spark的應用
Hive在剛開始使用過程中很好用，對大資料量的處理确實比以前傳統資料庫要好，但是随着業務的增長，公司越來越多的資料工程師回報查詢慢，同時業務側也紛紛提出，我們的資料能不能早點出，不要老是等到早上8點才重新整理。我們需要更強大的計算引擎，Spark使用了十分之一的計算資源，獲得了比Hadoop快3倍的速度，Spark為什麼這麼快呢？
我們來看看Spark的特點：
- 速度快，使用DGA（有向無環圖）。
- 支援記憶體計算。
- 低延遲、高容錯。
Spark提供了存計算，可以将計算結果存放到記憶體中，我們都知道MR是将資料存儲在磁盤，對磁盤讀寫，勢必會增加IO操作，計算時間過長。之前我也做過一個Hive和Spark的一個執行效率的對比，當時使用的是Spark1.6，資料是千萬級别的表。
還是可以看出Spark比Hive快了很多，現在Spark2.0以後，會更快了。而且，Spark同樣提供的有JDBC、ODBC 、Thrift連接配接方式。
我們可以從Hive環境直接遷移到Spark環境，提高執行效率。
05 MPP的應用
用了Spark還是不夠快，每次查詢送出任務後，都得等着任務啟動然後看着任務執行進度一直等着。
MPP（Massively Parallel Processing）是指多個處理器（或獨立的計算機）并行處理一組協同計算。為了保證各節點的獨立計算能力，MPP資料庫通常采用ShareNothing架構。比較有代表性大家熟知的比如：GPDB、Vertica。
MPP具備以下特點：
- 低成本的硬體、和Hadoop一樣，使用x86架構的PC就可以
- 資料存儲采用不同的壓縮算法，減少使用空間，提高IO性能
- 資料加載高效，并行加載、資料加載的速度取決于帶寬
- 易擴充，容易對叢集節點進行增減
- 列存儲，很多MPP支援列存儲架構，能夠更高效的通路需要的資料
- 支援标準SQL，MPP比SparkSQL、HiveSQL對标準SQL支援的更好
從以上MPP的特點和上面我們介紹的Hadoop的特點，會發現MPP更适合資料自助分析、即席查詢等場景、能夠使資料人員快速擷取資料結果。
06搭建自己的數倉計算平台
開源的計算引擎這麼多、我們如何選擇合适的計算引擎搭建平台呢？
下面分多個場景來和大家探讨下：
1、小公司、無大資料平台
真正的從無到有搭建大資料平台，開發人員較少。可以直接使用CDH搭建起來你的大資料平台，選用Hive作為資料倉庫的計算引擎。為什麼這樣選擇呢？很多小公司沒有足夠的資金支撐大資料平台的建設，那麼就會選擇相對來說的比較穩定的開源元件，Hive發展了很多年，和磁盤的互動MR計算架構中的任務很少會出錯。Hive對SQL支援的很好，開發人員很容易上手，而且維護成本很低。
2、小公司、大資料平台更新
已經有過一段時間使用Hive作為計算引擎後，工程師們對大資料平台已經有一定的了解和知識積累，對Hadoop的運維能力也提升了，随着開發人員回報Hive比較慢，上司也考慮更新平台，這時候就可以引入Spark了。上面我們也說了Spark是基于記憶體運算的，記憶體始終是沒有磁盤穩定，Spark任務很多時候會因為資源設定不合理而報錯。而SparkSQL和可以直接共享Hive的metestore，直接從Hive遷移到Spark上很自然，工作流很小。同時Spark還提供了Streaming功能，可以滿足公司逐漸發展遇到的實時資料問題，再也不用擔心以前hive沒半小時執行一次任務，任務還偶爾出現執行不完的場景了。
3、大公司
很多傳統行業的大公司一直依賴傳統關系型資料庫來處理資料，花了很多錢購置硬體和服務。現在要“降本增效”，必然會對IT部門下手。大公司有錢，就可以招聘到專業的工程師，他們有過建設大資料平台的經驗，在計算選型上可以根據自己的技術棧選擇合适的計算引擎。
另外，可以買一些MPP資料庫的服務，比如GreenPlum商業版、Vertica。商業版的很穩定，幾乎不會碰到棘手的問題，平時隻管使用就行了，大大提高的運維、開發效率。對比下來會發現比以前使用傳統的關系型資料庫省了不少錢。
07總結與展望
基于多個計算引擎搭建大資料平台是目前的現狀，針對不同的企業和團隊選擇适合自己的，同一個公司不同的業務也可以選擇不同的計算引擎。不考慮商業方案，就要根據自己的技術掌握情況，選擇自己精通的并且适合業務的。考慮商業方案的可以選擇商業的MPP，給開發和業務人員提供更好的環境和體驗。
目前市面上還沒有一款計算引擎，能很好的覆寫流批一體的場景，有人會說是Flink不是流批一體嗎？是的，Spark也可以流批一體，但是在生産業務中，他們還不能給資料分析人員很好的體驗，包括編碼、調優，不能像曆史上那個時代的Oracle一樣“無敵”，未來是否還會演進出現一款全能的計算引擎呢？
以上個人見解，歡迎大家留言讨論~