現在市面上的大數據產品太多了，但它們還遠遠沒達到像 IaaS 層那樣的標準化程度，每個產品之間的差別也並不是特別明確清晰。很多企業在做大數據平臺或大數據方案的時候，常常不知道該選用哪些產品來滿足自己的需求。一般的做法是做調研、學習、搭環境、測試、做各種產品的集成，但通常這個過程會很漫長，成本也很高。
我們希望這些事情都交給雲平臺來做，雲上所有的產品都可以一鍵部署、一鍵伸縮，不論是加節點還是減節點都能夠在 UI 界面上直接操作。對於一個企業來說，真正的核心是自己的業務，而不需要花太多的時間搞明白到底該用哪些工具搭建、部署、管理大數據。 大數據產品的運維和管理，應該交給更專注、具有更大規模效益的大數據服務廠商，用戶只需聚焦於自己的業務 。本文來自青雲QingCloud 大數據平臺架構師李威(Jordan)在青雲QingCloud 深圳站實踐課堂上的分享， 全文 3158 字，閱讀時長約為 13 分鐘 。
QingCloud 基礎架構雲和技術平臺雲
QingCloud 提供了一個完整的基礎架構雲和技術平臺雲，這裡面分了很多層，最下面一層是大家熟知的 IaaS 層，包括標準的計算、存儲、網絡。網絡裡還有路由器、負載均衡等，存儲裡面有塊存儲、共享存儲、對象存儲等各種面向不同場景的存儲服務，計算中有主機、容器、映象等計算資源。
IaaS 層上面是 PaaS，QingCloud 在幾年前就開始做 PaaS 平臺，有一個原則貫穿始終 —— QingCloud 的 PaaS 服務需要全部基於 IaaS，這樣做的好處是可以將 QingCloudIaaS 層所有的技術創新，如資源調度、SDN 網絡、性能優化，都透過IaaS 層被 PaaS 享用，QingCloud 的架構是一套統一的架構。
此外，QingCloud 在 PaaS 層之上還提供了一些高級的管理服務，如編排、定時器、監控告警等以及客戶部署的各種類型服務(如 VPC、專屬雲、託管雲)。
QingCloud 完整的企業級大數據平臺
QingCloud 的大數據平臺包含了完整的數據生命週期：負責數據傳輸的有 Kafka; 數據傳進來之後可以存儲在對象存儲、HBase、MongoDB;負責從存儲裡拿出數據進行計算處理的有主流的實時處理工具 Storm、準實時處理工具 Spark、批處理工具 hadoop、Hive 等;還有一些在公有云上用量非常大的大數據組件：如 Elasticsearch ，性能和業務性很強，場景非常明確，只要做大數據、海量數據搜索都非常易用，以及 Redis、Memcached、ZooKeeper 等離用戶比較近的大數據產品。
由於 QingCloud 是一家雲服務商，所以提供的大數據平臺是一個通用的服務，這與美團、小米、百度等互聯網公司的大數據概念不太一樣，它們的平臺中會有很多與自己業務相關的東西。而 QingCloud 是在雲上給所有的用戶提供服務，所提供的這套大數據平臺是一個通用的架構，每個組件之間的關係都非常靈活。QingCloud 主要提供主流的大數據組件和組件之間關係的管理。
大數據產品如何選型?
很多用戶在面對大數據時都會遇到一個相同的問題，應該選用什麼產品?其實這個問題沒有一個百分之百確定的答案，下面我們將會從各個維度來解析當前主流的大數據產品：
實時流處理引擎對比
實時流處理引擎主流的產品有 Storm、StormTrident、Spark Streaming、SAMZA、Flink 等，在選擇它們時可以考慮的維度很多，比如說消息的傳遞機制保護(Guarantees)有 At-least-once(至少傳輸一次，它帶來的結果是消息的重發)和Exactly-once(消息一定只處理一次，無論是在出錯的情況還是其他的情況下)的區別;Latency(延遲)方面，如 Storm 是通過 Native 實現的流處理，延遲非常低。而 Spark Streaming 是通過 Micro-batching 實現的，它會把一段時間內的流組成小批量地處理，這樣它的延遲就會高一些;吞吐量(Throughput)方面， Storm 的 Native 吞吐量沒有那麼高，SparkStreaming 的吞吐量就會很高。
一個企業的架構師或者方案的設計者在選型這些產品的時候，需要平衡自身流處理的業務到底在意什麼維度，是在意吞吐量、性能，還是在意消息的處理機制。
存儲 - HBase vs Cassandra
HBase 和 Cassandra 是兩個非常接近的產品，很多人對它們可能不是很熟。它們都是列存儲，都可以處理海量的數據，讀寫性能都非常好。但它們也有很多維度可以對比，首先是一致性，HBase 是基於行的強一致性，Cassandra 則是最終一致性，如果在中間的某個點寫入數據的時候去讀取，有可能不會讀到最新數據;
穩定性方面，HBase 有自己的 HMaster、Namenode HA，Cassandra 是 P2P 的架構，去中心化，沒有單點故障;分區策略方面，HBase 是基於主鍵有序排列的範圍分區，Cassandra 是一致性 Hash 排列，可自定義策略;可用性，HBase 是 Down 掉一臺短暫不可讀寫，Cassandra 是 Down 掉可繼續讀寫。
從這些對比可以明顯地看出來， HBase 犧牲了可用性，注重強一致性，Cassandra有高可用性，沒有強一致性。因此，在應用場景方面，HBase 由於有強一致性，它可以做一些 OLTP 類型、交易類型的工作。 Cassandra 因為併發讀寫的量比較大，性能比較強，但是數據不要求強一致性，不要求數據時時刻刻精準和統一，可以做監控數據的存儲。
常用 Ad - hoc & OLAP 查詢分析產品對比
常用的數據倉庫 Ad-hoc 和 OLAP 產品也非常多，在選擇的時候可以從三個維度來衡量——數據量、靈活性和性能。
Hive：
基於 MapReduce，可以 處理海量數據，查詢靈活，但性能較低;
Phoenix + HBase：
也可以處理海量數據，性能高，但查詢只能通過Rowkey 查詢，靈活性較差;
Elasticsearch：
可以用來做數據分析和日誌分析等應用場景， 特點是查詢靈活、性能高，但是它目前還支持不了海量數據， 只能支撐 TB 級數據。這個原因主要是和它的架構有關係，Elasticsearch 屬於全鏈接的結構，所有節點之間都有通信，這應該是影響擴展性的一個原因;
Kylin：
百度、小米、美團等互聯網企業都會用它來做數據倉庫的分析， 它可以處理海量數據，性能也很高，但是靈活性較低 。由於 Kylin 採用的是預聚合查詢，在數據倉庫中需要把你要算的 cube 的維度和事實預先計算好，存到 Hbase 裡面才能達到很高的性能，這導致它就喪失了靈活性;
Druid：
海量數據、性能、查詢靈活都滿足了，但是它也有一個限制，數據來源的每條記錄裡必須有一個 Timestand，它是時序數據的處理，更多的被應用在實時處理的場景，比如廣告分析;
HashData(GreenPlum)：
GreenPlum 是一個傳統的數據倉庫，三個創始人依次是雅虎 Hadoop 團隊的研發、全球 Hadoop 集群的運維和 GreenPlum 的核心研發工程師。他們在 Apache 上開源了一個基於 Hadoop 的數據倉庫項目—— Apache hook，在這個項目中他們貢獻了一半以上的代碼。所以，該團隊在數據倉庫的技術研發能力是很強的，與QingCloud 一起實現 HashData， 這款產品查詢靈活，性能高。但是它的侷限是隻能處理結構化的數據，不能處理非結構化數據。
計算與存儲關係的思考
做大數據肯定會想到一個問題 —— 大數據的數據到底放在什麼地方?是放在硬盤裡還是放在對象存儲裡?如果放在本地的話性能倒是可以滿足，但是容量又不夠。而放在對象存儲裡，容量可以無限擴展，但是性能肯定又沒有本地硬盤快。例如Hadoop 或者 Spark，下面的數據如果放在本地機器或集群相關的存儲上，它就擁有了大數據中數據本地性這個特性。但是這樣做也會有問題，碰到海量小文件就不行了。這個問題誰能幫你解決?對象存儲。對象存儲針對小文件有專門的合併和優化，問題可以迎刃而解。
所以，QingCloud 要做的就是讓計算和數據不僅可以在一起，還可以分開。當數據量達到 PB 級以上的時候，數據存到 IaaS 和 PaaS 之上的分佈式存儲裡成本也很高，這個時候就需要對象存儲方案，將很久不用的歷史數據和海量小文件都存在對象存儲裡。當你需要計算的時候，你有兩個選擇，如果不考慮實時性或者性能的話，你就可以直接在對象存儲上面計算。如果需要高性能，可以將數據拉在 HDFS 上計算，這樣就會變得很靈活。
那麼，計算和存儲的關係到底是什麼呢?我們的理解是，當你想要性能的時候，就讓它們在一起。當需要大批量計算處理的時候，就讓它們分開。以前我們面對的是一個 Hadoop 集群或一個 Spark 集群，數據是到處分散的，而將數據都放在對象存儲後，可以做到數據不動、計算隨便動，計算引擎可以是 Hadoop、Spark、Hive，它們都針對同一份數據進行計算。
大數據案例分析
QingCloud 在線業務大數據分析流程圖
QingCloud 會用自己的大數據服務做業務、市場、銷售的分析。我們會將一些線上數據庫的數據進行解析、同步，包括典型的 ETL 處理，數據處理完存在 HDFS 裡面，之後由 Spark 進行計算，最後把處理結果存到對於業務來說易於使用的產品，如 PostgreSQL、Elasticsearch，通過 API-server 曝露給前端使用。這是一個比較典型的大數據分析流程，我們用它來驗證 QingCloud 大數據平臺提供的各種服務。
某大型互聯網社交平臺
這是一個在 QingCloud 公有云上運行的大型的互聯網社交平臺，架構非常典型，它有一個數據的服務層，下面可以處理 MySQL、緩存、Elasticsearch、MongoDB 等數據存儲，下面的數據層有 ZooKeeper 和 Kafka，可以將應用級系統日誌等信息輸入到 Spark 平臺上進行分析，如對於系統推薦的好有，用戶是否添加了好友等。
某創新型綜合金融公司
這是一個 QingCloud 的私有云案例，QingCloud 可以將自己的整個軟件全部部署到用戶自己的環境當中去，架構主要有三大塊：數據的抽取、數據處理、數據服務。數據源涵蓋日誌、關係型數據，還有一些 ETL 工具、日誌處理框架、實時數據同步系統。中間有離線計算、實時計算。計算完之後會提供給離線服務，比如 Hive、Spark，進行內部的數據分析。同時，還有一些在線服務，性能比較高、易用性比較好的服務。
這些案例的架構千奇百怪，但是仔細看其實都差不多，都分成數據的來源、收集、傳輸、計算、存儲等架構，只不過具體用到的每個產品不一樣，這和它的場景是相關的。對於 QingCloud 來說，無論用戶是傳統企業還是互聯網企業，我們都能夠提供一套非常靈活的大數據平臺，滿足任何一種應用場景的需求。
QingCloud 大數據平臺 Rodmap
大數據平臺管理架構
當大數據組件特別多的時候，需要有一個單獨的平臺來管理。 QingCloud 會提供一個界面執行一些 Hive、SQL、Spark 的腳本，在這個平臺上你可以看到 Storm 和 ZooKeeper 數據的信息，存儲可以直接從瀏覽器、HDFS、對象存儲看到文件的結構，可以提交 HBase 實時的查詢，可以看 Kafka 傳輸隊列裡現在的數據結構是什麼樣的 。所以，它相當於一個管理的 UI，你可以管理很多大數據的組件。以前用戶需要分散管理這些組件，當系統比較複雜的時候，易用性就會變得比較差。
大數據平臺 + AppCenter 2.0
大數據技術發展太快了， QingCloud 面臨一個困境：大數據產品是無窮無盡的，我們不可能把所有的產品提供出來，但是如果用戶需要，我們怎麼辦?
第一，QingCloud 的大數據平臺也會通過 QingCloud AppCenter 交付。如Hadoop、Spark、Elasticsearch 等產品都將是 AppCenter 中的一個 APP，當你需要一些非常典型的組合的時候，它也可以作為一個組合的 APP 出現在 AppCenter 上。對於用戶來說，大數據產品的易用性會大大增強。 QingCloud AppCenter 不但提供 APP 的開發框架，它還提供 APP 運營的框架，你可以在 APP 上進行編排，將幾個簡單的 APP 拼裝成一個大的 APP。
第二，大數據的場景太多了，如果 QingCloud 提供的沒有你想用的怎麼辦?也很簡單，如果你對這個產品非常熟，可以用 QingCloud AppCenter 框架將其做成一個雲應用，提供給別人使用。這個概念非常接近於蘋果的 Appstore 中的 APP 開發者， 如果你是一個企業用戶或者在大數據領域中技能很強的個人開發者，就可以在 QingCloud 之上利用 AppCenter 框架在短期之內把你熟悉的大數據產品變成一個雲服務，放在 QingCloud 的 AppCenter 上提供給所有人使用。
這樣的事情在以前完全是不可想象的，即使做也需要花非常大的成本，QingCloud AppCenter 可以幫你在幾天之內將已有的產品變成雲服務。 同時，雲服務的運營管理、生命週期框架都內置於 AppCenter 中。
在不久的將來，多智時代一定會徹底走入我們的生活，有興趣入行未來前沿產業的朋友，可以收藏多智時代，及時獲取人工智能、大數據、雲計算和物聯網的前沿資訊和基礎知識，讓我們一起攜手，引領人工智能的未來
閱讀更多 多智時代 的文章
