萬億級大數(shù)據(jù)平臺的建設(shè)實踐

1、萬億級大數(shù)據(jù)平臺的建設(shè)實踐技術(shù)創(chuàng)新 變革未來02030401百分點超大規(guī)模實時數(shù)據(jù)分析典型架構(gòu)基于業(yè)務(wù)場景進行核心組件的設(shè)計分享數(shù)據(jù)平臺的持續(xù)運維與監(jiān)控設(shè)計和實現(xiàn)萬億級實時數(shù)據(jù)分析面臨的問題和挑戰(zhàn)目錄問題與挑戰(zhàn) 大數(shù)據(jù)平臺維度劃分大數(shù)據(jù)平臺4.數(shù)據(jù)查詢跨中心數(shù)據(jù)同步跨中心透明訪問2中心處理數(shù)據(jù)：2000億+/天處理到查詢延時：200W/s 熔斷/限流數(shù)據(jù)量巨大小時/分鐘/天的統(tǒng)計任務(wù)日增： 100TB+寫入吞吐：200W/s 歷史存儲：PB級 文件存儲：2TB/天海量數(shù)據(jù)低延時復(fù)雜的即席查詢跨數(shù)據(jù)中心的查詢分析全文搜索查詢離線統(tǒng)計任務(wù)的影響二地雙中心數(shù)據(jù)存儲實時流處理離線處理數(shù)據(jù)查詢系統(tǒng)運維系

2、統(tǒng)結(jié)構(gòu)復(fù)雜組件眾多 | 依賴關(guān)系復(fù)雜 | 部署復(fù)雜硬件利用率(200臺/兩中心)故障常態(tài)化：設(shè)備宕機 | 磁盤損壞系統(tǒng)安全問題與挑戰(zhàn) 超大規(guī)模對平臺提出的高要求DataXFTPJDBC/ODBCFlumeSqoop數(shù)據(jù)接入KafkaHiveHDFSMapReduceShellSparkSQLScalaPythonR離線計算SparkSpark MLlibTensorFlowPyTorchCaffeRPythonStormSpark Streaming實時數(shù)據(jù)處理機器學(xué)習(xí)（深度）/算法處理FlinkHBase數(shù)據(jù)存儲與查詢數(shù)據(jù)標(biāo)準(zhǔn)元數(shù)據(jù)管理數(shù)據(jù)質(zhì)量數(shù)據(jù)生命周期管理數(shù)據(jù)治理融合配置關(guān)系映射圖譜AP

3、I標(biāo)簽知識圖譜標(biāo)簽管理動態(tài)本體 標(biāo)簽提取標(biāo)簽融合算法模型管理模型實驗?zāi)Ｐ桶l(fā)布深度學(xué)習(xí)機器學(xué)習(xí)任務(wù)開發(fā)數(shù)據(jù)接入模型開發(fā)數(shù)據(jù)加工任務(wù)監(jiān)控SparkStreaming任務(wù)Storm任務(wù)SQL on Streaming數(shù)據(jù)工廠（離線/流任務(wù)開發(fā)平臺）數(shù)據(jù)服務(wù)：網(wǎng)關(guān)/接口服務(wù)/資源目錄數(shù)據(jù)API生成-注冊-發(fā)布-運行-監(jiān)控面向業(yè)務(wù)的數(shù)據(jù)資源目錄服務(wù)注冊-服務(wù)發(fā)布-服務(wù)網(wǎng)關(guān)路由大 數(shù) 據(jù) 技 術(shù) 平 臺數(shù) 據(jù) 資 產(chǎn) 管 理 平 臺Elastic SearchNeo4jKylinClickHousePrestoOSSMySQL百分點超大規(guī)模實時數(shù)據(jù)分析典型架構(gòu)結(jié)構(gòu)化存儲：ClickHouse消息通道 ：k

4、afka流處理框架： SparkStreaming全文搜索：ElasticSearch文件存儲：OSS (HBase + Ceph)實時數(shù)據(jù)分析典型架構(gòu)應(yīng)對的核心組件業(yè) 務(wù)：1、超大規(guī)模的單表查詢/分析；2、有一定的并發(fā)要求；3、實時性要求；PB級的數(shù)據(jù)存儲高性能的查詢/分析能力低延時寫入及吞吐能力數(shù)據(jù)壓縮跨中心能力ClickHouse Presto HAWQDruid Elastic Search組件設(shè)計 - 存儲ClickHouse組件設(shè)計 - OLAP引擎的選型與評估分布式表 （配置文件）查詢?nèi)肟贒C1 數(shù)據(jù)DC2 數(shù)據(jù)NginxClickHouse 日志表Grafana日志監(jiān)控展現(xiàn)Sp

5、arkStreaming組件設(shè)計 - ClickHouse整體設(shè)計日志本地表Shard1日志本地表Shard2Shard1Replication日志本地表Shard1日志本地表Shard2DCDC客戶端寫入本地表ClickHouse跨中心透明訪問。業(yè)務(wù)端可以查詢多中心數(shù)據(jù)，也可以查詢特定分中心數(shù)據(jù)。禁止分布式寫。4. 性能影響：1/4 1/3Shard2Replication/data1本地表Shard1/data1單臺物理機Raid5Raid0 - Raid5演進Raid5數(shù)據(jù)恢復(fù)影響組件設(shè)計 ClickHouse磁盤Raid的選擇1、Raid5增加磁盤數(shù)據(jù)可靠性和讀取能 力2、熱備盤減少運

6、維壓力3、控制寫入，保障查詢性能橫向擴展對查詢性能幾乎無影響可以基于單節(jié)點/分區(qū)評估查詢性能數(shù)據(jù)預(yù)熱對查詢有數(shù)量級提升針對緩存更換條件同樣生效PageCache緩存對查詢的影響組件設(shè)計 ClickHouse的相關(guān)測試分析1、平衡好合并速度和Part數(shù)量的關(guān)系，一定是需要相對均衡的。2、Part數(shù)量，實際代表著提交頻率，一定是穩(wěn)定，且經(jīng)過估算的。3、ClickHouse的查詢和寫入共同受限于Query數(shù)限制，需要分配好配額。4、不推薦直接寫入分布式表。1、20W/s （35次）提交，并發(fā)502、10W/s(17次)提交，并發(fā)903、5W/s(8次)提交，并發(fā)90確保業(yè)務(wù)命中在安全區(qū)域組件設(shè)計 -

7、 如何保障ClickHouse寫入的穩(wěn)定性組件設(shè)計 - ClickHouse的查詢查詢?nèi)肟贜ginxClickHouse 日志表Grafana日志監(jiān)控展現(xiàn)SparkStreaming分布式表 （配置文件）1、限制單條查詢內(nèi)存使用量和單節(jié)點查詢內(nèi)存使用量，預(yù)防節(jié)點Down機。2、Query數(shù)量限制異常：控制好配額/連接池。3、集群的Query日志，找出慢查詢。我們直接通過Nginx收集了原始日志。4、針對熱數(shù)據(jù)進行查詢預(yù)熱。組件設(shè)計 - 最佳實踐之參數(shù)配置解耦吞吐量數(shù)據(jù)緩沖數(shù)據(jù)路由大數(shù)據(jù)生態(tài)關(guān)系Kafka Pulsar組件設(shè)計 消息通道Kafka消費延時監(jiān)控組件設(shè)計 - Kafka設(shè)計與評估思路

8、階段一：讀寫正常 （正常設(shè)計狀態(tài)）階段二：流量增大，根據(jù)限流影響、高峰期存在積壓 （如果長期，根據(jù)業(yè)務(wù)情況擴容）階段三：讀寫爭搶，讀資源不夠，入庫能力下降（必須擴容；思考：讀寫配額控制 ？）階段四：超流量，寫入失敗，服務(wù)開始出現(xiàn)異常高的吞吐量穩(wěn)定的處理流控制（數(shù)據(jù)量/時間）計算資源的控制KafkaDataElasticSearch實時指標(biāo)統(tǒng)計Spark Streaming流處理框架組件設(shè)計 - 流處理框架SparkStreamingDB(ClickHouse)StormFlink目標(biāo)源PullSparkExecutorExecutor ExecutorTime Windows MaxRateP

9、erPatitionKafka TopicPartition1Partition2 Partition3時間窗口保障持續(xù)穩(wěn)定提交頻率。（保障對ClickHouse寫入的穩(wěn)定）SparkStreaming反壓機制，實現(xiàn)處理能力動態(tài)平衡。（設(shè)定合理的拉取數(shù)量）Spark on Yarn 資源可控。一個Executor可以處理多個Partition,一個Partition不能同時由多個Executor處理。以寫入ClickHouse為例，目前一個Executor處理在30000/s 左右。假設(shè)我們需要一個滿足300W/s的處理能力。 在源讀取沒有瓶頸的情況下，可以 Executor數(shù) : 300 /

10、3 = 100（個）。組件設(shè)計 - 流處理框架SparkStreamingES NodeES NodeESClusterSparkES NodeES NodeESClusterSparkESnode1node4Data Center 1Data Center 2QueryQueryQueryCross Cluster Search組件設(shè)計 - ElasticSearch的設(shè)計性能影響：TPS：2到3倍降低配置多個Cross Cluster Search負(fù)載均衡集群Down、節(jié)點Down機器容錯配置基于SparkStreaming持續(xù)穩(wěn)定的時間窗口提交存儲二進制數(shù)據(jù)友好的API支持（Http)異

11、步調(diào)用大量的小文件寫多讀少GlusterFSHDFSSwift OSS(HBase + Ceph)組件設(shè)計 二進制文件存儲OSS1、Hbase K-V存儲支撐高并發(fā)讀寫。Ceph支撐大文件存儲基于Nio通信，異步提交存儲。LVS支撐高吞吐量。HBase和Ceph的TTL支持文件的生命周期管理HBase(1MB)tomcattomcatCeph ClusterHBaseClusterLVSDR模式tomcatClickHouse日志表Grafana日志監(jiān)控展現(xiàn)Elastic Search內(nèi)容索引索引通道 日志通道LBS組件設(shè)計 存儲OSS的設(shè)計數(shù)據(jù)平臺的持續(xù)運維與監(jiān)控設(shè)計和實現(xiàn)：擁抱開源206796232392626428根據(jù)容量配置預(yù)警線服務(wù)、磁盤、負(fù)載ClickHouse實時寫入吞吐，查詢監(jiān)控數(shù)據(jù)平臺的持續(xù)運維與監(jiān)控設(shè)計和實現(xiàn)：擁抱開源有波峰/波谷，和SparkStreaming時間窗口相關(guān)大的波峰和波谷流量高峰造成處理量大于60W/s消費延時持續(xù)擴大，沒有縮減。 意味著處理有問題，或者需要增加 處理能力。數(shù)據(jù)平臺的持續(xù)運維與監(jiān)控設(shè)計和實現(xiàn)：擁抱開源正常狀態(tài)異常狀態(tài)數(shù)據(jù)平臺的持續(xù)運維與監(jiān)控設(shè)