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

1、万亿级大数据平台的建设实践万亿级大数据平台的建设实践目 录01万亿级实时数据分析面临的问题和挑战百分点超大规模实时数据分析典型架构基于业务场景进行核心组件的设计分享数据平台的持续运维与监控设计和实现02030405问题与挑战 大数据平台维度划分大数据平台4.数据查询问题与挑战 超大规模对平台提出的高要求日增： 100TB+系统结构复杂组件众多 | 依赖关系复杂 | 部署复杂硬件利用率(200台/两中心)故障常态化：设备宕机 | 磁盘损坏系统安全写入吞吐：200W/s数据量巨大历史存储：PB级小时/分钟/天的统计任务文件存储：2TB/天二地双中心数据存储实时流处理离线处理数据查询系统运维跨中心数

2、据同步跨中心透明访问2中心处理数据：2000亿+/天海量数据低延时复杂的即席查询跨数据中心的查询分析全文搜索查询处理到查询延时：200W/s熔断/限流离线统计任务的影响百分点超大规模实时数据分析典型架构数据服务：网关/接口服务/资源目录数据API生成-注册-发布-运行-监控服务注册-服务发布-服务网关路由面向业务的数据资源目录标签知识图谱数数据据资资产产管管理理平平台台数据治理数据标准数据工厂（离线/流任务开发平台）机器学习算法模型管理模型实验数据接入SparkStreaming任务Storm任务标签管理标签提取标签融合动态本体元数据管理数据质量模型开发数据加工任务开发融合配置关系映射SQL

3、on Streaming任务监控模型发布数据生命周期管理深度学习图谱API数据存储与查询HBaseElastic SearchNeo4jKylinClickHousePrestoOSSMySQL大大数数据据技技术术平平台台离线计算实时数据处理机器学习（深度）/算法处理MapReduceSparkSQLScalaShellPythonRSparkHiveSpark StreamingStormSpark MLlibRTensorFlowCaffeHDFSFlinkPythonPyTorchDataXFlumeSqoop数据接入KafkaFTPJDBC/ODBC实时数据分析典型架构应对的核心组件结

4、构化存储：结构化存储：ClickHouse消息通道消息通道 ：kafka流处理框架：流处理框架： SparkStreaming全文搜索：全文搜索：ElasticSearch文件存储：文件存储：OSS (HBase + Ceph)组件设计 - 存储ClickHouse业 务：1、超大规模的单表查询/分析；2、有一定的并发要求；3、实时性要求；1.2.3.4.5.PB级的数据存储ClickHousePresto高性能的查询/分析能力低延时写入及吞吐能力数据压缩HAWQDruidElastic Search跨中心能力组件设计 - OLAP引擎的选型与评估组件设计 - ClickHouse整体设计Ng

5、inxGrafana日志监控展现ClickHouse 日志表SparkStreaming查询入口分布式表 （配置文件）DCDC日志本地表日志本地表Shard1Shard2Replication日志本地表Shard1DC2 数据日志本地表Shard2Shard1Shard2ReplicationDC1 数据客户端写入本地表1. ClickHouse跨中心透明访问。2. 业务端可以查询多中心数据，也可以查询特定分中心数据。3. 禁止分布式写。4. 性能影响：1/4 1/3组件设计 ClickHouse磁盘Raid的选择1、Raid5增加磁盘数据可靠性和读取能2、热备盘减少运维压力3、控制写入，保障

6、查询性能力Raid0 - Raid5演进演进/data1Raid5数据恢复影响本地表Shard1Raid5/data1单台物理机组件设计 ClickHouse的相关测试分析PageCache缓存对查询的影响横向扩展对查询性能几乎无影响可以基于单节点/分区评估查询性能数据预热对查询有数量级提升针对缓存更换条件同样生效组件设计 - 如何保障ClickHouse写入的稳定性1、20W/s （35次）提交，并发502、10W/s(17次)提交，并发90d3、5W/s(8次)提交，并发90确保业务命中在安全区域1、平衡好合并速度和Part数量的关系，一定是需要相对均衡的。2、Part数量，实际代表着提交

7、频率，一定是稳定，且经过估算的。3、ClickHouse的查询和写入共同受限于Query数限制，需要分配好配额。4、不推荐直接写入分布式表。组件设计 - ClickHouse的查询Grafana日志监控展现ClickHouse 日志表NginxSparkStreaming分布式表 （配置文件）查询入口1、限制单条查询内存使用量和单节点查询内存使用量，预防节点Down机。2、Query数量限制异常：控制好配额/连接池。3、集群的Query日志，找出慢查询。我们直接通过Nginx收集了原始日志。4、针对热数据进行查询预热。组件设计 - 最佳实践之参数配置组件设计 消息通道Kafka1. 解耦2.

8、吞吐量KafkaPulsar3. 数据缓冲4. 数据路由5. 大数据生态关系组件设计 - Kafka设计与评估思路消费延时监控阶段一：读写正常 （正常设计状态）阶段二：流量增大，根据限流影响、高峰期存在积压 （如果长期，根据业务情况扩容）阶段三：读写争抢，读资源不够，入库能力下降（必须扩容；思考：读写配额控制 ？）阶段四：超流量，写入失败，服务开始出现异常组件设计 - 流处理框架SparkStreaming流处理框架 高的吞吐量ElasticSearchSpark Streaming 稳定的处理流控制（数据量/时间）KafkaData 计算资源的控制StormFlinkDB(ClickHous

9、e)实时指标统计组件设计 - 流处理框架SparkStreamingKafka TopicSparkTime WindowsMaxRatePerPatitionPartition1ExecutorPull目标源ExecutorExecutorPartition2Partition31. 时间窗口保障持续稳定提交频率。（保障对ClickHouse写入的稳定）2. SparkStreaming反压机制，实现处理能力动态平衡。（设定合理的拉取数量）3. Spark on Yarn 资源可控。4. 一个Executor可以处理多个Partition,一个Partition不能同时由多个Executor

10、处理。5. 以写入ClickHouse为例，目前一个Executor处理在30000/s 左右。6. 假设我们需要一个满足300W/s的处理能力。 在源读取没有瓶颈的情况下，可以 Executor数 : 300 /3 = 100（个）。组件设计 - ElasticSearch的设计QueryQueryESQuerynode1node4ESClusterESClusterCross Cluster SearchSparkSparkES NodeES NodeData Center 1ES NodeES NodeData Center 21. 性能影响：TPS：2到3倍降低2. 配置多个Cross

11、 Cluster Search负载均衡3. 集群Down、节点Down机器容错配置4. 基于SparkStreaming持续稳定的时间窗口提交组件设计 二进制文件存储OSS1.2.3.4.5.存储二进制数据友好的API支持（Http)异步调用GlusterFSHDFSSwift大量的小文件写多读少OSS(HBase + Ceph)组件设计 存储OSS的设计OSSHBase(1MB)LBStomcat1、Hbase K-V存储支撑高并发读写。1. Ceph支撑大文件存储HBaseClusterLVSDR模式tomcattomcat2. 基于Nio通信，异步提交存储。3. LVS支撑高吞吐量。Ce

12、phCluster4. HBase和Ceph的TTL支持文件的生命周期管理日志通道日志通道索引通道索引通道Grafana日志监控展现ClickHouseElastic Search日志表内容索引数据平台的持续运维与监控设计和实现：拥抱开源数据平台的持续运维与监控设计和实现：拥抱开源服务、磁盘、负载ClickHouse实时写入吞吐，查询监控根据容量配置预警线323926264282067962数据平台的持续运维与监控设计和实现：拥抱开源正常状态有波峰/波谷，和SparkStreaming时间窗口相关大的波峰和波谷流量高峰造成处理量大于60W/s异常状态消费延时持续扩大，没有缩减。意味着处理有问题，或者需要增加处理能力。数据平台的持续运维与监控设计和实现：拥抱开源关于百分点赵赵 群群 百分点研发总监，大数据平台技术负责人。百分点研发总监，大数据平台技术负责人。2015年加入百分点，负责大数据操作系统BD-OS、数据开放服务平台、机器学习平台等多款产品的架构设计和研发；百分点是一家中国领先的数据智能技术企业，致力于帮助企业和政府机构在智能时代下，最大限度 从海量的数据资源中挖掘内在价值，在复杂多变的业务场景下，实现从数据到知识再到智能决策的演进。