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