万亿级大数据平台的建设实践

1、万亿级大数据平台的建设实践技术创新 变革未来02030401百分点超大规模实时数据分析典型架构基于业务场景进行核心组件的设计分享数据平台的持续运维与监控设计和实现万亿级实时数据分析面临的问题和挑战目录问题与挑战 大数据平台维度划分大数据平台4.数据查询跨中心数据同步跨中心透明访问2中心处理数据：2000亿+/天处理到查询延时：200W/s 熔断/限流数据量巨大小时/分钟/天的统计任务日增： 100TB+写入吞吐：200W/s 历史存储：PB级 文件存储：2TB/天海量数据低延时复杂的即席查询跨数据中心的查询分析全文搜索查询离线统计任务的影响二地双中心数据存储实时流处理离线处理数据查询系统运维系

2、统结构复杂组件众多 | 依赖关系复杂 | 部署复杂硬件利用率(200台/两中心)故障常态化：设备宕机 | 磁盘损坏系统安全问题与挑战 超大规模对平台提出的高要求DataXFTPJDBC/ODBCFlumeSqoop数据接入KafkaHiveHDFSMapReduceShellSparkSQLScalaPythonR离线计算SparkSpark MLlibTensorFlowPyTorchCaffeRPythonStormSpark Streaming实时数据处理机器学习（深度）/算法处理FlinkHBase数据存储与查询数据标准元数据管理数据质量数据生命周期管理数据治理融合配置关系映射图谱AP

3、I标签知识图谱标签管理动态本体 标签提取标签融合算法模型管理模型实验模型发布深度学习机器学习任务开发数据接入模型开发数据加工任务监控SparkStreaming任务Storm任务SQL on Streaming数据工厂（离线/流任务开发平台）数据服务：网关/接口服务/资源目录数据API生成-注册-发布-运行-监控面向业务的数据资源目录服务注册-服务发布-服务网关路由大 数 据 技 术 平 台数 据 资 产 管 理 平 台Elastic SearchNeo4jKylinClickHousePrestoOSSMySQL百分点超大规模实时数据分析典型架构结构化存储：ClickHouse消息通道 ：k

4、afka流处理框架： SparkStreaming全文搜索：ElasticSearch文件存储：OSS (HBase + Ceph)实时数据分析典型架构应对的核心组件业 务：1、超大规模的单表查询/分析；2、有一定的并发要求；3、实时性要求；PB级的数据存储高性能的查询/分析能力低延时写入及吞吐能力数据压缩跨中心能力ClickHouse Presto HAWQDruid Elastic Search组件设计 - 存储ClickHouse组件设计 - OLAP引擎的选型与评估分布式表 （配置文件）查询入口DC1 数据DC2 数据NginxClickHouse 日志表Grafana日志监控展现Sp

5、arkStreaming组件设计 - ClickHouse整体设计日志本地表Shard1日志本地表Shard2Shard1Replication日志本地表Shard1日志本地表Shard2DCDC客户端写入本地表ClickHouse跨中心透明访问。业务端可以查询多中心数据，也可以查询特定分中心数据。禁止分布式写。4. 性能影响：1/4 1/3Shard2Replication/data1本地表Shard1/data1单台物理机Raid5Raid0 - Raid5演进Raid5数据恢复影响组件设计 ClickHouse磁盘Raid的选择1、Raid5增加磁盘数据可靠性和读取能 力2、热备盘减少运

6、维压力3、控制写入，保障查询性能横向扩展对查询性能几乎无影响可以基于单节点/分区评估查询性能数据预热对查询有数量级提升针对缓存更换条件同样生效PageCache缓存对查询的影响组件设计 ClickHouse的相关测试分析1、平衡好合并速度和Part数量的关系，一定是需要相对均衡的。2、Part数量，实际代表着提交频率，一定是稳定，且经过估算的。3、ClickHouse的查询和写入共同受限于Query数限制，需要分配好配额。4、不推荐直接写入分布式表。1、20W/s （35次）提交，并发502、10W/s(17次)提交，并发903、5W/s(8次)提交，并发90确保业务命中在安全区域组件设计 -

7、 如何保障ClickHouse写入的稳定性组件设计 - ClickHouse的查询查询入口NginxClickHouse 日志表Grafana日志监控展现SparkStreaming分布式表 （配置文件）1、限制单条查询内存使用量和单节点查询内存使用量，预防节点Down机。2、Query数量限制异常：控制好配额/连接池。3、集群的Query日志，找出慢查询。我们直接通过Nginx收集了原始日志。4、针对热数据进行查询预热。组件设计 - 最佳实践之参数配置解耦吞吐量数据缓冲数据路由大数据生态关系Kafka Pulsar组件设计 消息通道Kafka消费延时监控组件设计 - Kafka设计与评估思路

8、阶段一：读写正常 （正常设计状态）阶段二：流量增大，根据限流影响、高峰期存在积压 （如果长期，根据业务情况扩容）阶段三：读写争抢，读资源不够，入库能力下降（必须扩容；思考：读写配额控制 ？）阶段四：超流量，写入失败，服务开始出现异常高的吞吐量稳定的处理流控制（数据量/时间）计算资源的控制KafkaDataElasticSearch实时指标统计Spark Streaming流处理框架组件设计 - 流处理框架SparkStreamingDB(ClickHouse)StormFlink目标源PullSparkExecutorExecutor ExecutorTime Windows MaxRateP

9、erPatitionKafka TopicPartition1Partition2 Partition3时间窗口保障持续稳定提交频率。（保障对ClickHouse写入的稳定）SparkStreaming反压机制，实现处理能力动态平衡。（设定合理的拉取数量）Spark on Yarn 资源可控。一个Executor可以处理多个Partition,一个Partition不能同时由多个Executor处理。以写入ClickHouse为例，目前一个Executor处理在30000/s 左右。假设我们需要一个满足300W/s的处理能力。 在源读取没有瓶颈的情况下，可以 Executor数 : 300 /

10、3 = 100（个）。组件设计 - 流处理框架SparkStreamingES NodeES NodeESClusterSparkES NodeES NodeESClusterSparkESnode1node4Data Center 1Data Center 2QueryQueryQueryCross Cluster Search组件设计 - ElasticSearch的设计性能影响：TPS：2到3倍降低配置多个Cross Cluster Search负载均衡集群Down、节点Down机器容错配置基于SparkStreaming持续稳定的时间窗口提交存储二进制数据友好的API支持（Http)异

11、步调用大量的小文件写多读少GlusterFSHDFSSwift OSS(HBase + Ceph)组件设计 二进制文件存储OSS1、Hbase K-V存储支撑高并发读写。Ceph支撑大文件存储基于Nio通信，异步提交存储。LVS支撑高吞吐量。HBase和Ceph的TTL支持文件的生命周期管理HBase(1MB)tomcattomcatCeph ClusterHBaseClusterLVSDR模式tomcatClickHouse日志表Grafana日志监控展现Elastic Search内容索引索引通道 日志通道LBS组件设计 存储OSS的设计数据平台的持续运维与监控设计和实现：拥抱开源206796232392626428根据容量配置预警线服务、磁盘、负载ClickHouse实时写入吞吐，查询监控数据平台的持续运维与监控设计和实现：拥抱开源有波峰/波谷，和SparkStreaming时间窗口相关大的波峰和波谷流量高峰造成处理量大于60W/s消费延时持续扩大，没有缩减。 意味着处理有问题，或者需要增加 处理能力。数据平台的持续运维与监控设计和实现：拥抱开源正常状态异常状态数据平台的持续运维与监控设