預測2015大資料趨勢 星環孫元浩為你揭秘

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已成為公認的替代傳統資料庫的技術。 大家可以去外面展臺看看我們新版本，歡迎有興趣的同學加入我們公司。

(責任編輯：mengyishan)