從選型到實現——企業級雲端大數據平臺最佳實踐

內容來源：2017 年 7 月 29 日，青雲資深產品經理李威在「大數據與人工智能大會」進行《雲端大數據平臺最佳實踐》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：3289 | 9分鐘閱讀

嘉賓演講視頻及PPT回顧： suo.im/4A4Y7h

摘要

不少企業在作大數據平臺或大數據方案的時候，經常不知道該選用哪些產品來知足本身的需求。本次分享將從青雲的雲平臺架構出發，探討大數據平臺的實踐以及思考。

雲平臺架構

青雲提供了完整的基礎架構雲和技術平臺雲，圖中最下方的IaaS層提供標準的網絡存儲和計算服務，咱們認爲主機、虛擬機、容器、物理機等在架構中都是資源，共用同一套調度器。上層PaaS服務中的大數據平臺以及數據庫和緩存都是基於IaaS的，調用的是IaaS的API接口。再往上就是管理服務，它包含自身的一些部署架構。

完整的企業級大數據平臺

通常的大數據平臺架構首先面對的就是各類數據源，接着就是數據的傳輸，這裏的傳輸層推薦使用Kafka。數據傳輸完成後就來到了大數據存儲層，這裏最常使用的有MongoDB、HBase、對象存儲等。再往上的計算層通常分幾類，實時處理主流使用Storm、準實時處理推薦使用Spark，批處理則使用Hadoop、Hive等。另外還須要任務的調度和平臺管理層來管理接入的各類開源產品。咱們將Redis、Memcached、MySQL歸類到最上層，可是這層並非UI層，而是由於離用戶比較近，使用率較高。

以上全部的架構都是創建在IaaS之上的，不論是虛擬機、物理機仍是容器。整個架構的核心地方在於從下到上的層次和從左到右的生命週期中的每一個模塊均可以根據企業的場景替換。

大數據產品選型

實時流處理引擎對比

實時流處理引擎主流的產品有 Storm、Storm Trident、Spark Streaming、SAMZA、Flink 等，在選擇它們時能夠考慮的維度不少，好比說消息的傳遞機制保護（Guarantees）有 At-least-once（至少傳輸一次，它帶來的結果是消息的重發）和 Exactly-once（消息必定只處理 一次，不管是在出錯的狀況仍是其餘的狀況下）的區別；Latency（延遲）方面，如 Storm 是經過 Native 實現的流處理，延遲很是低。而 Spark Streaming 是經過 Micro-batching 實現的，它會把一段時間內的流組成小批量地處理，這樣它的延遲就會高一些；吞吐量（Throughput）方面， Storm 的 Native 吞吐量沒有那麼高，Spark Streaming 的吞吐量就會很高。

存儲——HBase .VS. Cassandra

HBase和Cassandra是很是相近的兩個產品，都能提供高性能的海量數據讀取，也都是列存儲，讀寫性能都很是好。並且應用場景也很類似，都會用來作監控或者日誌數據的存儲。

可是它們也有不少不一樣的，首先一致性上HBase是行的強一致，Cassandra是最終一致；穩定方面HBase有多Hmaster，Namenode HA，Cassandra則去中心化，沒有單點故障；分區策略方面，HBase 是基於主鍵有序排列的範圍分區，Cassandra 是一致性 Hash 排列，可自定義策略；可用性方面，HBase是犧牲了可用性換取了一致性， Down 掉一臺後短暫不可讀寫,Cassandra 是 Down 掉可繼續讀寫。

Ad-hoc & OLAP查詢分析產品對比

交互式查詢這方面考慮的維度有不少，這裏選取數據量、靈活性、性能這三個維度來衡量。

Hive

能夠處理海量處理，查詢靈活，可是性能比較低。

Phoenix + HBase

這兩個組合也能夠查詢海量數據，同時性能也比較高，可是查詢是基於Rowkey的，很是不靈活，比較適合業務固定的場景。

ElasticSearch

ElasticSearch的查詢靈活，性能也很高，不過承載的數據量很難達到p級別，只能支撐TB級別數據。這個主要是和它的架構有關係，由於它是屬於全連接的結構，全部可能致使節點的擴展性有問題。

Kylin

能夠處理海量數據，性能也很高，可是靈活性較低。因爲 Kylin 採用的是預聚合查詢，在數據倉庫中須要把你要算的 cube 的維度和事實預先計算好，存到 HBase 裏面才能達到很高的性能，這致使就它喪失了靈活性。

Druid

海量數據、性能、查詢靈活都知足了，可是它是時序數據，數據來源的每條記錄裏必須有一個 Timestamp。

HashData（GreenPlum）

採用標準的SQL查詢，因此查詢很靈活。並且性能也很高，支持PB級別數據，能在雲上橫向擴展節點。可是它的限制在於只能處理結構化的數據。

海量數據OLTP —— 分佈式數據庫

上圖是咱們用來處理海量數據的產品，它有一箇中間件的集羣，下方的每個節點都是一個分片，每一個分片又是一個MySQL的集羣。這些分片在雲上是能夠無限擴展的，因此這種架構能夠支持還海量數據。

在架構層面咱們還將自動分庫分表、數據強一致、分佈式事務能力都作到了分佈式數據庫中。

無限擴展的對象存儲服務

對象存儲在大數據的處理中很是重要，通常咱們使用的都是S3對象存儲，它能夠無限擴展，而且支持的文件類型是通用的，不論是非結構化的數據、日誌、視頻、音頻、圖片都能存儲，對文件的存在也沒有限制。

青雲提供的對象存儲就支持S3接口，這樣一些主流的大數據產品就能夠直接使用QingStor的對象存儲。雖然這種形式在性能上有所損失，可是數據的集中存儲方便了計算引擎的切換，同一份數據可使用不一樣的計算引擎計算。

Ad-hoc & OLAP查詢分析產品對比

某大型家電集團——基於海量數據的輿情分析系統

整個架構中首先會將爬取的數據以及關係型數據庫的備份數據都存儲在對象存儲中，而後經由Spark進行數據分析。分析完成的結果中的展現文件能夠經過UI展現。

青雲——在線業務大數據分析流程圖

青雲自身的也有不少的業務須要分析，咱們會將一些線上數據庫的數據進行解析、同步，包括典型的 ETL 處理，數據處理完存在 HDFS 裏面，以後由 Spark 進行計算，最後把處理結果存到對於業務來講易於使用的產品，如 PostgreSQL、Elasticsearch，經過 API-server 曝露給前端使用。這是一個比較典型的大數據分析流程，咱們用它來驗證 QingCloud 大數據平臺提供的各類服務。

全球某大型互聯網職場社交平臺

這是一個在 QingCloud 公有云上運行的大型的互聯網社交平臺，架構很是典型。最上層用自身的Web Server接入負載均衡，下方有一個數據的服務層，能夠處理 MySQL、緩存、Elasticsearch、MongoDB 等數據存儲，再往下的數據傳輸層Kafka，能夠將應用級系統日誌等信息輸入到 Spark 平臺上進行分析，如對於系統推薦的好有，用戶是否添加了好友等。

Roadmap

大數據平臺管理架構

青雲不只提供大數據的相關組件，還提供了管理這些組件的平臺。咱們的大數據管理平臺能夠經過UI界面直接執行Hive、SQL、Spark的腳本，還能夠直接看到 Storm 和 ZooKeeper 數據的信息，存儲能夠從瀏覽器、HDFS、對象存儲看到文件的結構，能夠提交 HBase 實時的查詢，能夠看 Kafka 傳輸隊列裏如今的數據結構是什麼樣的。這些是在大數據的組件之上的平臺管理層。

大數據平臺+Appcenter2.0

大數據技術的變化太過迅速，咱們沒法提供全部的相關產品，因此須要在大數據平臺下提供一個框架層，這樣就能夠將各類產品轉化爲服務集成到平臺中。

青雲的AppCenter就是這樣的一個框架，咱們的PaaS以及大數據服務所有都是基於這個框架交互。這樣就能保證上層有統一的平臺管理，下層有插件式的框架集成各類產品。