Ⅰ 青雲李威：在雲上做大數據平台有什麼獨特的挑戰
7月18日,"雲用戶生態發展論壇暨第三屆中國雲計算用戶大會"在北京國家會議中心召開。在下午的會議中，青雲QingCloud系統工程師及大數據平台負責人李威帶來主題為「大數據雲平台之最佳實踐」的精彩演講，以下是他的演講實錄：
李威：大家好，我是QingCloud青雲的系統工程師李威。今天我講的這個話題可能技術性有點強，可能需要大家費點腦子。分成幾大塊。第一，先說一下雲計算和大數據的關系。第二，在雲上做大數據平台有什麼獨特的挑戰。第三，我們會講一下大數據平台它有一個比較基本的，或者說通用的一個系統架構是什麼樣子。最後，分享一些我們自己的，包括和在客戶那兒的一些跟大數據相關的最佳實踐。
大數據的例子，我就不說太多了，說一些我們的一些企業客戶的。比如說第一個是一個非常大型的一個跨國的一個互聯網社交企業。然後他們會用我們在雲上的大數據的一些平台，包括一些具體的技術，會做比如用戶畫像。就是你在社交網路裡面，然後為什麼推薦給你的朋友正好是你可能會認識的，然後為什麼推薦給你的信息可能就是你感興趣的。這個都是用戶畫像用大數據來做的。
第二，像一個非常大型的互聯網的金融企業，它會用大數據做一些風控分析。因為在互聯網金融，尤其是互聯網金融行業裡面，它之所以可以和傳統金融PK，就是因為它在風控這方面可以用大數據技術把風險控制的非常小。大家可以想一想，在P2P平台上面，憑什麼沒有像以前傳統銀行各種人來調查你，沒有什麼抵押金，但是可以讓你用錢。包括政府部門海量信息檢索，比如它需要把全國的各種部門聯合起來，然後我需要有一個犯罪嫌疑人他有沒有可能在各個地方有一些其他數據，我可以搜索，可以挖掘，然後進行一些分析。
大數據很火，它跟雲計算到底什麼關系?其實我們認為大數據現在大家可能覺得到什麼地方都聽見大數據，其實很可能每個人說的不一樣，也得人說的是大數據平台，有的人說的是大數據的某個產品，有的人可能說的是大數據的某個應用，比如Alpha Go。
尤其在企業裡面，我們和客戶談的時候，客戶第一個比較想不明白的就是大數據的產品和技術太多了，而且每個場景都區別不是那麼明顯。所以，在大數據這個技術裡面，我們第一個要解決的就是到底怎麼選擇大數據的解決方案，怎麼為企業做大數據解決方案。但是，每個企業需求變化又特別大，或者有很多企業，就是傳統企業他們對大數據的需求不是非常明確，互聯網企業他們需求變化非常快。按照傳統的比如建一套大數據平台，可能花費很多成本，時間成本、人力成本，包括金錢。但是雲平台，大家知道IaaS、PaaS、SaaS，最後所有東西都變成伺服器。你要構建一個非常復雜方案的時候成本就低，因為你只需要按照服務構建的方式來做，而且這樣非常靈活，如果你發現其中方案某一部分有問題，你可以很快的替換掉，因為很多都是平台上的服務。所以，它可以滿足你的業務不確定性的需求，包括業務彈性的需求。因為大家知道現在變化太快了。
第二，雲計算給大數據帶來的好處是什麼?比如它可以自動化運維，一些復雜系統的安裝、部署、監控都不用你自己做，在界面上非常快的就可以，非常簡單就能做完。然後還有一些包括穩定、性能，這個不多說了，雲計算的好處大家肯定知道特別多，說幾個有意思的。
比如，網路和存儲，計算引擎的切換，這個比較有意思。也就是當你的平台足夠復雜，足夠大的時候，每塊部分都是一個伺服器，每一塊變成一個伺服器之後，可以非常靈活的替換掉它，把他換成別的產品實現，或者別的技術實現。後面就是Service Orchestration，就是比如你有一個界面，需要畫各種圖，或者工具也好，但是他們有一個非常致命的缺點，你畫的那個圖是不能執行的，就是是不能部署，不能執行的。Service Orchestration是給你一個大的拓撲圖，這也是青雲今年年初發布的一個產品，叫做資源編排。可以在雲平台把一整套的架構部署出來，這是雲上他們這些帶來的一些好處。
雲上大數據平台的挑戰。很多企業做大數據平台在物理機上做，為什麼沒有在雲上做?因為挑戰非常多。第一，穩定性的挑戰，比如高可用、災備。第二，性能。一直被人垢病的，因為你是虛擬機，肯定沒有網路機的硬碟快。在青雲第一個IaaS層的穩定性已經運行好幾年了，沒有太多可說的。垢病性能這一塊，我們去年做了軟體定義網路的2.0，2.0出來之後，這個是為雲計算，為大的IaaS平台專門研發的一套SDN，可以做到點對點之間的網路傳輸，可以達到物理網卡。第二，在硬碟這塊一直被垢病的，我們容器技術，可以把硬碟的技術降的非常低。第三個好處就是遷移，遷移技術非常好，因為現在已經有一些比較成形的，比如關系型資料庫和非關系型資料庫。
我們說解決這些挑戰之後，我們會有一個大數據的平台系統架構出來這個架構其實都是一個非常通用的架構。就是你可能在很多企業裡面，不管京東、美團、亞馬遜，可能看到的基本都是這樣的樣子。其實先從左開始看起，其實是一個數據的生命周期，就是數據從哪個地方收集，可能是日誌，可能是感測器，收集過來到中間的核心平台，最下面一層就是IaaS，青雲所有PaaS層的服務都是基於IaaS做的，就是都是在雲上面的。然後到第一個就是存儲。中間三個大塊，第一個叫實時計算，叫Storm，當然Twitter現在出來的可能宣稱比Storm更強。第二，就是Batch Processing，第三個就是Big SQL，包括像Kylim等。右邊就是你做所有平台可能都會做的，包括它的數據管理、監控、安全，包括用來做分布式的配置中心的一項東西。
所有的數據經過存儲、計算之後，你可能會通過一些，就是你想要一些非常好的用戶友好的方式使用這些數據，我們一般可能會把數據提交到比如說像一些交互性比較好的技術組件裡面，這樣在最上層，不管報表還是可視化，像Hadoop生態圈裡面比較流行的做可視化就比較方便。
我現在畫的這個圖裡面，基本上就是在大數據的生命周期裡面最核心的，或者說最主流的產品或者技術都涵蓋在裡面了，青雲自己的大數據平台也是按照這個架構來做的。
接下來先說一下，我會按照這個架構，挨個的挨個的說。第一，先說一下計算。計算上面最經典的就是Hadoop，這個圖不需要太多說。如果大家平時研究大數據，可以提一點，從2.0後之，它的HDFS有高可用，把之前的變成Yarn來支持，這樣會提升很大的性能。第二個計算型的架構就是Spark，比如它上面有主流的一些功能。如果做實時計算，Storm肯定首選的。MapRece延遲非常高，但是吞吐量很大。MapRece的硬碟非常高，Spark Streaming由於它是硬碟計算，所以計算還好。如果之前有一些Hadoop生態圈的基礎，可能選Spark比較好，如果不是要求非常實時，因為Spark平台非常強，它本身就是一個平台，現在的平台發展非常快，所以可能選Spark，對你要求非常高，現在我們碰見的客戶都有。第二，Big SQL裡面，提幾個，一個是Phoenix，提供了SQ語言上包裝的產品。第二種就是MPP的。
存儲。最初就是HDFS，第一，一定是為大文件設計的，不是為海量小文件設計的。如果想處理海量小文件，在青雲平台上有一個想像就是對象存儲，我們當時設計的時候不管文件什麼類型，不管文件什麼大小，都可以用這個存儲。HDFS為什麼不能存海量小文件，原因很簡單，像Linux裡面所有數據都有一個索引，如果存海量小文件，索引的數據有一個特點，不管數據文件大還是小，索引的數據都是一樣的大。存海量小文件的時候其實文件沒有多大，它會非常影響性能，導致數據整個存儲空間沒有利用慢，但是性能已經不可用了。
第二個比較主流的存儲就是Hbase，Hbase是架構在HDFS之上，它可以存非常寬的樣表，也可以存非常高的樣表，所有表的數據分布在每個節點上，其實它的架構比這個復雜多了。其實你可以看成對應一個表的概念。不知道大家有沒有人看Hbase，可能剛開始看Hbase比較費解，因為它是列式的存儲，和以前看到的資料庫解的不一樣。其實它的定義非常簡單，就是最上面，第二行那句話，是一個稀疏的、分布式的、多維的、持久化的一個影射。稀疏的就是是一個單位格的比，Hbase在存儲格式上已經解決了這個問題，可以存一個稀疏的表。第二，分布式的就不用解釋了。這個圖裡面可以看到有一些時間戳的概念在裡面，這是一個比如第一個是一個記錄的Row Key，然後有一個Column Families，然後有一個版本號。
存儲裡面的選型，剛才說了幾個，做存儲選型怎麼選?並不一定是一開始肯定會聽到很多人說Hbase一定比HDFS快，這些說法都是不責任的，都是一定要在什麼場景下。比如說Hadoop，這樣的方式就是在做全局文件掃描的時候是快的，但是像Hbase做隨機存儲的時候是快的，所以也是分場景的。但是像中間這個KUDU，昨天一個客戶說他們正在用一個KUDU，屬於一個中間的方案，介於HDFS和Hbase之間的一個存儲引擎，現在還沒有看到大規模的生產應用。這個就是今年年初做的一個數據倉庫，Greenplum Database，是去年開源的。之前Greenplum的核心就能工業他們自己出來，它最大的一個好處，我們覺得有幾個，第一個是標準的SQL，你可能看到很多市面上的產品都說支持SQL，但是其實都不是標準的。不是標準的意味著什麼?比如很多語法不一樣，你以前像數據工程師，數據分析師，他們用的比較高級的用法都沒法用。但是，Greenplum Database不一樣，因為它的核心計算引擎我們覺得比MySQL更好，它還有很多別的特點。
我們說完計算的產品，說完存儲的產品，接下來一些數據的傳輸。數據傳輸我們說一個最經典的Kafka，是分布式、可分區、多副本、低延遲的。低延遲什麼意思?左右這兩張圖長的很像，其實就是Kafka相當於進入和留出的數據，Kafka就是領英開源的，因為我們平台提供了Kafka服務，他們現在也在用，這是他們是使用出來的一個產品。意思就是Kafka的延遲非常低，基本數據不落下來，直接就出去了。
為什麼它可以這樣?有兩個非常本質的原因：第一，它在寫數據的時候是直接寫到PageCatch裡面，往外發的時候直接通過Linux發出去的，所以它的吞吐量延時非常低，這是兩個核心的原因。Kafka的架構非常簡單，就是三個松偶合的，比如最上層是它的生產者，然後是一個集群，中間是一個伺服器，Kafka的伺服器，下面是它的消費者。它的生產者一個集群都可以往broker裡面發數據，相當於broker把數據發到第一個Partition裡面，第二個發到第二個Partition裡面，Partition第一個主要概念就是你發布的消息是什麼，你生產出的消息相對於在Kafka裡面有幾個隊列，每個隊列就是一個Partition。
第二個集群就是它的消費者，消費者可以提比較重要的一點，它有一個消費組的概念，這個組的概念非常重要。當你想把一個Topic的消息想多播出去，想被很多個消費者處理的時候，這個時候需要建多個消費組，這個消息才能被多個消費者來消費。如果只建了一個消費組，哪怕這個消費組有好幾個消費者，每次都是由一個消費者處理的。第二個問題，就是消費組裡面消費者的數量，這裡面一個是兩個，一個是四個，就是一個消息裡面有四個Partition，如果有四個消費者，正好一對一，每個消費者消費一個Partition，如果只有一個消費者，有一個會消費兩個Partition。這種情況比較好。有一種情況要避免，就是比如有5個消費者，你那個Topic只有4個隊列，你就會浪費掉一個消費者。這個是需要注意的。
說完了計算，說完了存儲，說完了傳出，然後說一些我們碰到的問題。第一個大問題就是復制因子的問題，為什麼原生的不用考慮，但是雲上為什麼要獨特考慮呢?原因很簡單，因為在雲上面所有的服務都是基於IaaS做的，IaaS這一層本身有高可用，就是它的數據本身就是有副本的，如果你還照搬物理機上的做法，你就找三個副本，你想想2×3就是6個。所以，第一個就是要去副本，把它用兩個副本，這是我們最開始想的方案，用兩個副本就行了。但是，後來我們覺得兩個副本還是2×2=4，還是空間浪費上會多一點。
後來我們想更高級的方案是什麼?就是我們在IaaS這一層提供一種能力，讓PaaS層可以選擇，說我要幾個副本，就是變成一個選項，這樣比如像大數據這樣，或者非常脆弱的應用，但是有時候比如不需要，有它自己的一個副本的策略，完全不需要IaaS層的副本，這個時候就根據你自己的配置，或者根據你自己的產品的需要可以配置IaaS層的副本策略，這樣跟物理就是一樣的了。
這個參數調優，比如像典型的大數據裡面每個產品或者每個平台都有兩三百個參數，這個太正常了，這個時候做調優第一個重要的步驟就是你應該知道我們應該盡量去知道這些調優的參數之間什麼關系，他們之間到底什麼關系，不能只知道每一個參數是干什麼的，要不然調一個，影響另外一個，或者調按沒有任何反應，那是因為你沒有把這個關系搞清楚。像這樣的圖，可以把yarn裡面的Node Manager都弄的比它小，然後是yarn裡面分配的內存，這個之間的關系嘎明白，在做性能調優的時候是很重要的。
最後一個比較重要的最佳實踐就是在數據格式上，這個肯定很多人都會忽略。但是在大數據裡面非常重要，為什麼?因為數據很大，數據量非常大的時候，如果不注重數據格式就會導致這幾個問題。比如可能性能會下降，然後你的空間反而浪費了很多，成倍的上升。
其實數據格式比較注意的項非常多。我們挑出兩個比較重要的准則，第一這個數據格式要可分隔。可分隔支持的格式有這些，比較多的像Avro、Parquet Lzop+index、SequenceFile，不支持的就是XML、JSON文件。
然後可塊壓縮的，支持的就是Avro、Parquet、Lzop+index、SequenceFile，不支持的就是CSV、JSON記錄。大家可以想一下，我們在大數據平台裡面計算都是並行計算，它所有的數據都是分開來計算的，然後每一個分片對它進行計算，所以，第二個是可塊壓縮的。其實還有很多點，比如數據格式是不是支持眼鏡的，像Avro就支持，就是數據格式的老版本和新版本還是可以兼容的。包括像SequenceFile，可伸縮，可壓縮，但是它只在Hadoop這個生態系統，不像Avro和Parquet。我們7月28號在北京飯店有一個青雲自己的用戶大會，我們只負責服務，上面都是各個行業的精英講他們自己技術的干貨，產品的干貨，我們是這樣形式做的。