j現在市面上的大資料產品太多了，但它們還遠遠沒達到像 IaaS 層那樣的標準化程度，每個產品之間的差別也並不是特別明確清晰。很多企業在做大資料平臺或大資料方案的時候，常常不知道該選用哪些產品來滿足自己的需求。一般的做法是做調研、學習、搭環境、測試、做各種產品的整合，但通常這個過程會很漫長，成本也很高。

　　我們希望這些事情都交給雲平臺來做，雲上所有的產品都可以一鍵部署、一鍵伸縮，不論是加節點還是減節點都能夠在 UI 介面上直接操作。對於一個企業來說，真正的核心是自己的業務，而不需要花太多的時間搞明白到底該用哪些工具搭建、部署、管理大資料。 大資料產品的運維和管理，應該交給更專注、具有更大規模效益的大資料服務廠商，使用者只需聚焦於自己的業務

　　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 主要提供主流的大資料元件和元件之間關係的管理。

　　想學習大資料或者想學習大資料的朋友，我整理了一套大資料的學習視訊免費分享給大家，從入門到實戰都有，大家可以加微信：Lxiao_28獲取，還可以入微信群交流!(備註領取資料，真實有效哦)。

　　大資料產品如何選型?

　　很多使用者在面對大資料時都會遇到一個相同的問題，應該選用什麼產品?其實這個問題沒有一個百分之百確定的答案，下面我們將會從各個維度來解析當前主流的大資料產品：

　　實時流處理引擎對比

　　實時流處理引擎主流的產品有 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 中。

​