2014年12月12-14日，由中國計算機學會(CCF)主辦，CCF大數據專家委員會承辦，中科院計算所與CSDN共同協辦，以推進大數據科研、應用與產業發展為主旨的 2014中國大數據技術大會 (Big Data Technology Conference 2014，BDTC 2014)暨第二屆CCF大數據學術會議在北京新云南皇冠假日酒店盛大開幕。

星環科技CTO孫元浩的演講主題是“2015年大數據基礎技術的演進趨勢”。期間，他一共總結了四大趨勢：SQL on Hadoop技術對SQL支持的完整度和性能大幅提升，混合架構將逐漸消失;從In-Memory Computing 轉向 On-SSD Computing，固態盤將替代內存作為緩存;數據產生的速度以及處理的速度要求都在快速提高，實時大數據技術得到關注;虛擬化技術的快速演化與Hadoop技術的日益平臺化，云計算與大數據終得融合。期間，他分享了Spark的一個數據：全球已有近50家企業圍繞Spark提供產品和服務，11家提供商業Spark版本。

星環科技CTO孫元浩

以下為演講實錄：

孫元浩：

謝謝大家，謝謝查教授，我今天演講的題目是2015年大數據技術的演進趨勢，過去我們一直從事大數據實踐，有一些心得跟大家分享一下。我們做了明年的預測，邀請大家一起驗證。

***個趨勢是隨著SQL on Hadoop技術的快速發展，SQL完整程度的大幅提高和性能提升，我們認為混合架構逐漸開始消失。

這里我解釋一下為什么出現混合架構，在過去幾年當中Hadoop這個技術最早開始互聯網公司使用，十年之前開始發展，幾年前互聯網公司在企業里面用得越來越多，它處理非結構化數據和半結構化數據非常有利，但是處理結構化數據的時候功能不完整，用戶覺得應該還需要使用數據庫，或者MPP數據庫，放在Hadoop旁邊協助處理結構化的數據。第二個原因Hadoop是為幾百TB，幾個PB數據設計的，但是數據量小的時候，小于100T或者到10個T以下的時候，大家發現Hadoop的性能不如傳統的MPP數據庫，這時大家覺得有必要使用混合架構，把全部數據放在Hadoop上，部分數據放到MPP數據庫進行計算，或者把實時數據放到MPP數據庫，把歷史數據放到Hadoop里面，當數據量積累很大的時候也讓Hadoop計算，這是混合架構典型的部署方式。

我們看到過去的三年當中Hadoop發展非常迅猛，很多公司快速做SQL開發，性能也有很大提升。我們總結了一下市場上大概有四種SQL on Hadoop的技術，我是說Hadoop系統里面原生開發SQL引擎的公司和技術。***個是Impala，它的引擎采用類似于MPP的引擎。第二家是Tez，它吸收了Spark的一些設計思想。這個產品是2012年大概五六月份開始成型。第三個我們公司的產品我們叫做Transwarp Inceptor，這是基于Spark開發的SQL引擎，我們去年10月份是***個版本，目前支持SQL2003，支持函數、游標等功能，我們SQL完整程度目前是所有Hadoop里面支持最完整的。同時，還有 SparkSQL和Drill。四類引擎每一個都在獨立發展自己的技術，而Spark會成為一個主流。我們已經可以支持TPC-DS所有的測試項，TPC-DS是用來衡量數據倉庫的執行性能的，里面有大量的非等值JOIN語句，這使SQL引擎支持比較有難度的。

我們做的***個判斷是混合架構會逐漸的消失，過去MPP數據庫有三個優勢，***個SQL支持完整，現在我們的SQL支持程度已經接近MPP數據庫;第二個它比Hadoop性能高，但我們看到現在Hadoop性能可以超過MPP若干倍。第三個優勢就是說它上面的BI工具，外延工具非常全，傳統的BI廠商都已經轉向Hadoop，Hadoop系統的BI工具也越來越豐富，還有一些新興的創業公司在Hadoop上開發全新的BI工具，這些工具原生支持Hadoop，從這個角度來講Hadoop的生態系統將很快超越傳統MPP數據庫。

我們覺得在未來一年兩年之內，Hadoop將逐漸取代MPP數據庫，大家不需要用混合架構，不需要在不同數據庫之間實現遷移了。有人說我MPP也在遷移，慢慢向Hadoop靠攏，這也是事實，整個MPP的數據庫在慢慢消失，完全走到Hadoop上面來。我們希望***結果就是數據全部放在Hadoop上，不管數據在幾個GB級別還是10個PB級別，都可以在Hadoop上處理，真正做到無限的線性擴展。

我們發現一個事實現在Spark成為***的計算引擎，Impala已經開發了三年時間，SQL支持仍然不夠完整，而通過Spark可以快速并行化SQL，SQL支持的完整程度可以快速提高。同時，通過Spark引擎我們證明新引擎性能可以超過MPP數據庫。從今年開始Hadoop的社區發展非常快速，今年六月份的時候Spark Summit大會上，原來Hadoop生態系統中的各個廠商或項目都宣布開始全面支持Spark。我做了簡單的統計，全球已經有近50家企業圍繞Spark提供產品和服務，其中有11家提供商業的Spark版本，這是這里面所有的11家公司，我們也是認證的Spark發行版廠商。

第二個趨勢過去大家談內存計算談高效迭代計算，當時大家覺得這是非常好的方向，把數據放進內存進行緩存，內存速度是磁盤百倍到千倍，我們把這種技術應用到現實當中發現，內存容量小和價格高是比較大的限制條件，把所有數據全放內存的時候，像Spark，和Hadoop都是運行在JVM上的，內存大的時候，GC影響非常嚴重，我們能不能用更好的方式緩存數據?隨著硬件技術的發展我們發現內存可以被大容量的SSD取代做緩存，這個也是非常明顯的趨勢。

這張圖列出了SSD硬件技術的發展，***層是硬盤，現在SSD有幾個量級的提升，我們拿市場上英特爾P3700 PCIe SSD的數據為例，讀性能是每秒鐘46萬次，是硬盤的一千倍，吞吐量是硬盤10倍以上。還有一些廠商把SSD插在內存卡槽，做成內存條的形式。目前做的性能不如P3700，未來性能會逐漸的提升。SSD的內存相比性能對比顯得沒有這么大，因為吞吐量內存的數據是8.5GB/s，PCIe的SSD是2.8GB/s也就是只有三四倍的差距，SSD 的性能已經開始向內存接近，同時這個價格也在迅速下降，SSD公司在中國市場非常多，整個價格下降非常明顯，今天中國市場可以以一萬塊錢到兩萬塊錢買1TB的SSD，如果你買內存條只能買128GB的內存條，我們認為用SSD替代是比較好的方案。這是我們一組數據，把數據放在磁盤、內存和SSD上的對比。***個我們發現我們把數據放在磁盤上，性能作為1的話，我們發現內存的性能仍然是***的，藍色的線是數據放在內存中的統計性能，紅色的線是PCIe SSD的性能，SSD性能跟內存比較接近，我們看到每一個測試場景性能對比圖，發現性能差距最多在30%，平均性能差異9.6%，基本控制在10%以內，你可以以十分之一的價格達到內存只差10%的性能的產品，你原來放在內存里可能只有幾百GB或者幾個TB的數據，現在你可以把幾十TB的東西放在SSD上進行數據分析。

Hadoop2.6提出來一個概念，叫做Storage Tier，在HDFS上提供幾層存儲，一層是磁盤層，一層是SSD層，還有內存層，我可以指定你文件放在哪個層上面，以128MB數據塊為單位，決定放在哪一層上面，以為這樣性能可以迅速提升。我們很快發現其實沒有那么簡單，Hadoop是最早為大容量低速磁盤設計的，SSD比普通磁盤順序讀寫性能大10倍，它隨機訪問性能是磁盤的一千倍，你如果不能利用隨機訪問的性能優勢，你的提升不會像硬件指標這么顯著。我們試過ORC格式，性能只比普通硬盤提升不到3倍。我們覺得明年這里有兩個趨勢，***個趨勢是基于磁盤的Hadoop慢慢開始為SSD做優化，未來會有更多的優化針對SSD專門做的。第二個趨勢內存數據庫這樣廠商也開始覺得內存不夠用，我不可能把所有數據都放在內存里，可能是幾十T的數據我需要大容量的介質，SSD是理想的替代，已經有很多傳統數據庫廠商覺得他的數據庫要專門為SSD做優化。我們設計了一種新的數據格式，叫做holodesk，以前Spark把數據放在內存里，我們首先把數據從Spark當中剝離出來，放到一個外部的介質上面。然后放到SSD上進行存儲編碼壓縮，這里面采用了我們自己專有的編碼技術，當然也有一些索引在上面，做了這個改造以后性能有比較大的提升。這里有一個測試對比，我們比較四種組合情況，一種是基于磁盤文本格式的，第二種在SSD運行TPC-DS的部分結果，我們選TPC-DS部分的場景，因為有的場景是CPU密集型的，磁盤性能不是瓶頸，可能不一定有提升，所以我們選一些IO密集型的場景來測。大家很快發現如果我不改變文件格式，同樣文件放在磁盤和放在SSD，它的性能***提升了1.5倍。這跟我們兩三年前做過測試一樣，我們把Hadoop集群的DataNode全換成SSD，性能提升大概是40%。把這個數據變成ORC格式，確實有助于提升性能，我可以過濾很多數據，可以充分高SSD的性能，這個格式性能額外得到了2.7倍的提升。但是這個還不夠，還沒有完全發揮SSD性能的優勢，所以我們采用了我們設計的holodesk存儲格式，我們采用編碼方式也有點與眾不同，用了這個存儲格式以后比ORC再提升2倍以上，有些純粹是IO密集的測試場景，可以提升五倍到十倍左右。如果采用新的列式存儲方式，我們性能可以比磁盤快8到10倍，相信未來更多軟件會專門利用SSD的這種特性。

第三個趨勢隨著現在傳感器網絡、物聯網的發展，數據產生的速度越來越快，當然在互聯網里面早就有實時數據產生，使得實時大數據的技術慢慢開始得到更多的關注，我們預計明年有更多的應用。

怎么來處理實時數據和歷史數據。Nathan提出了Lambda Architecture的架構。實時數據進入一個流處理系統進行檢測分析，同時也進入Hadoop，全量數據放在Hadoop對歷史數據進行分析，兩者結果做融合，然后應用程序訪問這個數據庫做分析。今天為止沒有哪個技術既能處理實時數據又能處理大量歷史數據，所以Nathan提出了這樣一個混合的架構，這個混合架構受到很多人的追捧。這種架構實時數據流里面處理完之后仍掉了，只把結果放在里面，也就是我不能對實時數據進行隨機的查詢，這是***個問題。我把隨時數據和歷史數據分離后，我怎么形成統一的視圖，怎么***拼接起來，這是比較難的事情。第三個這個Serving DB可以完成快速查詢但是不能做統計分析。這三個弱點很快大家意識到了，很快大家想出一個辦法，有一個項目叫Druid，這個項目得到大家比較多的關注，現在Twitter和雅虎采用這種實時數據分析。Druid解決了兩個問題，把實時數據和歷史數據全部拼接起來變成一張視圖，它內部把實時數據離線的收集起來拼成一個歷史視圖進行分析。Druid解決了快速采集和統一視圖的問題，但是它還不能解決復雜統計和挖掘的問題。比較理想的架構***是數據經過流處理以后直接進入一個數據庫，這個數據庫可以完整把實時數據和歷史數據拼接起來，在上面既做高速查詢又能做迭代分析，這是比較理想的，這樣可以省去維護兩套架構的麻煩，而且既能對實時數據進行分析，又能對歷史數據進行分析，這是比較理想的架構，現在大家還在想有什么實現的方法。我們做了一個嘗試，這是我們在應用大數據技術到國內各個行業的時候發現的普遍問題，這個驅動力來自于交通流的實時分析，如果我們部署整個集群的時候，他們希望看到早高峰晚高峰任何一個時刻每個路口的實時狀況，一旦發生交通事故，某個地方產生擁堵會有連鎖反應，產生連鎖反應后需要快速分析這種情況的影響，這種情況用剛才的Lambda架構也不能很好實現。我們開發了分布式的緩存holodesk，存在內存或者是SSD上的，當實時數據流到里面去的時候，我們先用Spark Streaming進行實時檢測和告警處理，這是一個批處理系統，可以短到一百毫秒，再小的延時現在還不能實現，Spark本身框架延時比較長。進入Spark內存以后同時我們在上面可以做非常多的實時的檢測甚至是實時的挖掘，同時這個結果以及原有數據我們映射成二維關系表，做一個SQL轉化，轉化成一個歷史存儲。過去我們可以放在內存里，但是內存容量不夠我們把全量數據放到SSD上，我們的holodesk支持快速插入，這樣我可以把所有實時數據包括歷史數據可以全部緩存到SSD上，這個集群可能是10個節點20個節點，你可以存放幾年交通數據，這樣可以對歷史數據和實時數據進行很完整的分析。這個轉化也是非常快的，我們支持高速的數據插入，數據持久性也得到保證，因為數據在SSD上，即使掉線也沒有問題。這種方案解決了三個問題，***個是可以有一個統一的視圖，不管是歷史還是實時都有，第二是可以通過標準SQL或者R語言做任意復雜的分析，第三是數據持久化問題也解決了。還有一個問題沒有解決，如果把這個數據給在線用戶訪問，這個并發度還不夠。改進的方法是一方面我們盡量降低查詢的延時，另外我們也需要擴大集群規模來提高并發度。這個方案很好地解決了交通行業面臨的問題。這個問題蠻普遍的，不光是交通行業，還有網站點擊日志，我們也可以用這個方式做分析，我們可以對傳感器的數據，例如工廠里傳感器的數據進行快速的分析，而且傳感器的數據可以全部在一張表里面。

第四隨著虛擬化技術快速演進，我們說云計算和大數據終于可以融合起來了。

虛擬機幫助快速部署已經得到了時間的驗證，這種方式把一臺機器拆分到很多小機器，每臺機器給用戶使用。大數據覺得一臺機器不夠，我需要上千臺、幾百臺機器組成一臺機器處理。這個怎么融合起來，是不是我把虛擬機替代物理機做成了一個集群?這個嘗試基本上都是失敗的，因為IO的瓶頸是非常嚴重的，特別是在虛擬機跑大數據應用，CPU利用往往達到99%，很少有人在虛擬機上把CPU用到99%，這樣對hypervisor是很大的考驗，穩定性成為一個大問題。最近一兩年虛擬化技術在快速發展，不亞于一場新的技術革命。首先輕量級的Linux container技術出現，container之間可以做資源隔離，這使得虛擬機變得非常輕量級。很快一家公司叫做Docker發現應用打包遷移安裝還是不方便，所以做了一個工具，使得你做應用打包遷移非常容易。大家發現還不大夠，因為我要創立單個container或者單個應用比較容易，但是多個container應用就很麻煩。谷歌開發一個開源項目叫做Kubernetes， 簡化了創建container集群的任務，你可以非常方便的創建Hadoop集群，也可以創建傳統的應用，提供多container集群的部署同時也提供一些基礎服務，比如說一些調度服務，這開始具備分布式操作系統的雛形。另外一個方向像大數據領域去年推出Hadoop2.0資源管理的框架YARN，這個確實是革命性的，因為把資源管理放在***層，在上面可以跑多種計算框架，我們覺得可以一統天下了。隨后大家發現YARN資源隔離做得不夠好，內存/磁盤/IO沒有管好。因此Hortonworks嘗試把Google Kubernetes作為YARN的一個Application Manager, 內部用Docker進行資源調度。而另一家公司mesosphere異軍突起，以mesos為資源調度核心，以docker作為container的管理基礎工具，開發了一套分布式資源管理的框架，提出了數據中心操作系統的概念。這家公司最近融資了數千萬美元。盡管底層技術在快速變化，但不妨礙一些公司已經提供Hadoop as a Service的服務，例如AltiScale，BlueData，Xplenty等。

大家看到在這個領域過去一兩年發生了革命，從底層虛擬化技術到上層都在發生非常大的變化。逐漸引出了數據中心操作系統的概念。我們把數據中心操作系統分成三層，***層就跟操作系統內核是一樣的，可以方便的創建方便銷毀計算資源，包括對CPU/網絡/內存/存儲進行處理。同時我們還需要多個服務之間能夠發現這種機制，這種機制是目前還是缺乏的，我們需要在這一層繼續往上加一些基礎服務。再往上是平臺服務，我們可以創建Hadoop、Spark等我們可以部署這樣傳統應用。這種架構提出來我們發現現在市場上有幾種，兩個技術方向，我們不知道哪一種會獲勝。一個方向是把YARN作為資源調度的基礎，Kubernetes作為運行在YARN上的某一個應用框架，但實際上Kubernetes是和YARN并列在同一層的。另外一個技術方向是把調度器抽象出來作為plugin，例如YARN和mesos都可以作為Kubernetes的調度器，當然也可以實現自己的調度程序;使用docker或者coreOS進行container的管理，而hadoop等分布式服務運行在Kubernetes之上。對下能夠提供資源隔離和管理，對上面能夠提供各種服務，包括Hadoop生態系統的各種服務，這個可能是明年的主流趨勢，現在還很難判斷誰會獲勝，但是我更傾向于第二種，我們可以首先嘗試這兩種方案，看哪種方案更有生命力。

總結一下就是我們把明年的發展趨勢歸納成四個，一個混合架構會逐漸消失，第二個我們發現SSD慢慢替代內存作用緩存，因為性價比更高。第三實時大數據技術得到廣泛關注和應用，第四云計算與大數據終于可以融合。這里做個廣告，星環科技是目前國內極少數掌握企業級大數據Hadoop和Spark核心技術的高科技公司，從事大數據時代核心平臺數據庫軟件的研發與服務。公司產品Transwarp Data Hub (TDH)的整體架構及功能特性比肩硅谷同行，產品性能在業界處于領先水平。在全球去IOE的大背景下，Hadoop已成為公認的替代傳統數據庫的技術。大家可以去外面展臺看看我們新版本，歡迎有興趣的同學加入我們公司。