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

从互联网、移动互联网到物联网,数据量之巨大已突破想象边界。与此同时,实时数据分析的需求日益增长,那么,当数据量达到亿级、百亿级甚至万亿级规模,实时数据分析如何来做?尤其在To B/G来说,大多数企业和政府客户区别于互联网企业,自身不具备技术团队,缺乏技术运维能力,因此在搭建本地化万亿级大数据平台时,如何交付更为标准化、透明化设计的产品成为最大挑战。

嘉宾:百分点研发总监、大数据平台技术负责人赵群

在中国第十届数据库大会DTCC 2019上,百分点研发总监、大数据平台技术负责人赵群分享了《万亿级大数据平台的建设实践》的主题演讲,以国家级大数据平台建设实践,剖析百分点从0到1,在探索落地超大规模实时数据分析典型架构的实战经验。

架构设计理念创新

众所周知,当大数据平台在应对超大规模流量之时,除了要面对超大规模数据量引起的存储及性能遇到的挑战外,维护整体平台的稳定性和可靠性变的更为重要。举例来说,在出现硬件故障、高峰流量甚至异常流量的情况下,平台内部组件之间问题就会层层传导出现蝴蝶效应,最终导致系统崩溃。因此,万亿级大数据平台在搭建中首先要在设计理念上进行突破。

百分点采用了服务透明化、管理精细化的设计理念,通过将每个组件的存储、处理、查询能力标准量化,保证稳定可控。具体来说,每个组件容量都会经过设计,支持线性扩容,且组件的能力指标和当前的状态可以进行可视化展现,同时基于标准值建立预警机制和对应处理措施,另外集合百分点大数据平台对服务和数据提供精细化的管理。

比如,赵群介绍,以设计Kafka能力为例,将整体分为四个阶段:1.在正常设计状态下的读写正常阶段; 2.在流量加在阶段,受限流影响会存在积压延时,这个阶段需要考虑扩容; 3.读写争抢阶段,为保障“写”入“读”的能力就会下降,这个时候必须扩容;4.超流量阶段,就会出现服务异常情况。也就是说,在整个大数据平台部署中根据集群大小和标准值,在监控中心配置相应的预警线,才能在四个阶段实现组件能力的透明可量化和监控管理精细化。

窥斑见豹,对于万亿级实时数据分析面临的一些问题和挑战,也要从整体上进行规划。赵群表示,一般来说,在对大数据平台进行规划之前,需要把平台分为五个维度:一是数据存储;二是实时处理;三是离线处理;四是数据查询;五是系统运维。并且,当进行一个项目或者业务评估的时候,为了聚焦技术挑战点,百分点会把项目上的业务性挑战转换为技术需求,基于这五个维度进行应对和实现。

以百分点国家级大数据平台建设为例,五个维度的技术挑战如下:

 一是两地双中心。

由于大数据平台是两地双中心,因此除了将跨数据中心的数据同步之外,还要从业务层面实现跨数据中心的透明访问。即,用户不用关心数据存储在哪一个IDC,就可以直接进行跨中心的数据查询和分析。

 二是数据存储。

平台主要面对来自两类数据存储的挑战:一是结构分析数据,结构化日志型数据日增处理量 100TB+,支撑写入超过200W/s的吞吐量;二是文件存储方面的数据,为2TB/天的处理量。除了中心处理数据目标要达到2000亿+/天之外,业务方还提了一个需求,要求数据从接入消息通道到业务可以查询的延时小于30秒。可以发现,在实时处理方面平台要应对巨大的挑战。

基于如此大的数据量,还特别需要考虑熔断及限流方案来确保整体服务的稳定,包括实时处理时的延时、峰值的处理能力,甚至是在一些异常流量的情况下都需要保证大数据平台是稳定的、业务平台是可靠的。

 三是离线处理。

在离线处理方面,同样由于数据量的巨大,离线统计的任务也会消耗大量资源。但在保障很多离线处理任务正常进行的同时,不能影响即席查询和写入的性能和效率。

 四是数据查询。

在数据查询方面,一是业务系统对海量数据的低延时且复杂的即席查询需求、跨数据中心的查询能力,以及业务系统在调用查询时需要实时反馈结果。二是结合之前跨中心的透明访问,需要数据中心的查询和分析对业务系统是完全透明的,同时也要满足性能和延时性的要求。

 五是系统运维。

面对系统运维经常会出现一些硬件和网络的故障,需要保证在发生重点故障时及时地发现问题,保障系统在出现如设备宕机、磁盘损坏等常见故障情况下系统的可靠性和稳定性。

百分点超大规模实时数据分析的典型架构

面对万亿级大数据平台的这些挑战,百分点基于全新的架构设计理念搭建了以Kafka、Spark Streaming、ClickHouse、HBase、Ceph和ES为基础的大数据平台,不仅验证了设计理念的可行性,在整个过程中,百分点还沉淀了很多有价值的评测报告,涉及查询评测、PageCache影响、Raid5数据恢复、横向扩展影响评测和写入稳定性等。

现在,这个平台正承载着万亿级数据的存储、处理和应用,能够支持线上2000+亿/天、峰值500+万/秒的数据处理,且在实时性、稳定性、异构存储能力方面同样表现优异,在本地化部署万亿级大数据平台方面引领行业前沿。

那么,这个超大规模实时数据分析架构具体是如何实现的?

如上图所示,百分点将整个平台分为两层:大数据技术平台层和数据资产管理平台。

图:赵群 在 DTCC2019 大会分享现场

一是大数据技术平台。

在云计算、大数据、人工智能等技术融合的时代,开源已变得无处不在,对于许多大企业来说,开源大数据分析已经成为日常业务中一个必不可少的组成部分。因此,在这一层百分点采用了比较常见的开源组件,包括三个方面:数据接入层、数据处理层,以及数据查询与存储。.其中,通过数据接入层的各式组件接入数据后,在数据处理方面分为离线计算、实时处理、机器学习处理3类处理方式。数据存储与查询层包括列式Hbase、全文搜索Elastic Search、Kylin、ClickHouse等,这些组件都会根据客户的业务需求,选择合适的组件来支持即席查询或全文搜索、OLAP分析。

二是数据资产管理平台。

百分点基于底层组件建立了可视化、交互式开发的SaaS开发平台。数据治理负责对大数据技术平台内各类数据提供数据生命周期的管理:包括数据标准、元数据管理、数据质量、数据生命周期管理等,在整个数据资产管理平台中提供基础的数据管理支撑。数据资产管理整体包含四个部分:数据管理、数据加工、数据产品加工与管理和数据服务。其中,数据工厂包括离线和实时部分,与上文介绍的底层组件数据处理分类一一对应;百分点机器学习平台基于算法模型的管理形成整体的机器学习平台,除了常用的Spark Mlib、R、Python等机器学习算法,也融合了TensorFlow、Caffe、PyTorch等深度学习框架;百分点还通过数据工厂、机器学习平台和标签知识图谱平台进行数据处理形成数据集、标签、知识图谱、模型等数据产品;整个平台的数据资产形成的各类数据产品,还可以通过数据服务的方式对外支撑业务应用。

回看整个架构,从业务角度理解,实际就是目前业内火热讨论的数据中台概念。百分点在最近几年一直在落地数据中台,随着在重点行业的深耕,基于数据中台之上逐渐沉淀了行业的业务中台,更贴近客户的业务场景,有效实现业务价值。

针对超大规模实时数据分析平台的关键挑战,百分点基于这个典型架构基础,在分解技术需求后,以ClickHouse为平台核心存储,实现了跨数据中心的万亿级数据的查询与分析;Kafka为消息通道,来实现数据路由,数据缓冲、承担峰值压力;应用SparkStreaming实时数据处理,并进行处理能力控制、资源控制和数据限流;ElasticSearch支持跨数据中心的全文搜索;同时,基于HBase + Ceph封装了百分点自研的OSS服务,来支撑线上高并发、高吞吐量的文件存储。

架构选型应对关键挑战

为了应对整个项目的关键挑战,百分点在核心组件架构选型中做了很多技术实践。以核心存储组件为例:

针对业务场景需求:1.超大规模的单表查询/分析。2.有一定的并发要求,通过多个业务系统做查询/分析。3.实时性要求。

拆解成技术需求如下: 1.PB级存储。2.高性能查询/分析能力。3.低延时。4.需要考虑一定的压缩比。 5.系统支持跨中心查询。

在选型上,百分点基于ClickHouse、Presto和HAWQ进行了写入、存储等多维度的评测,并且针对实际业务场景,在同样的数据集下挑选4类典型SQL,每个引擎根据测试维度选择最优的存储格式。

从查询的对比测试结果来看,ClickHouse呈现出了数量级的优势: 1.基于查询/分析的性能,在单表的场景下ClickHouse完全占有优势。2.由于查询性能的优异,在并发响应上同样表现出色。3.实时写入方面,ClickHouse评测写入场景最高已经达到单节点60Wrow/s,此时的写入仍非常稳定,这是由于 ClickHouse自身的分布式设计是一种逻辑上的拓扑,水平扩展非常容易。

在选择ClickHouse作为大数据平台核心存储选择后,百分点继而对ClickHouse进行了整体设计,主要包括以下几点:

1.双中心ClickHouse集群。百分点通过配置文件将两个数据中心的CLickHouse配置成跨中心的分布式表,虽然实际查询和分析是基于两个中心的数据做汇聚,但对业务系统访问而言是完全透明的,呈现给业务人员的就是一张表。在实际测试场景中,这种配置方式对查询会造成大约1/4~1/3的性能损耗,对于毫米级的响应速度来说,这个影响是完全可以接受的。

2.禁止分布式写入。通过在客户端控制写入ClickHouse本地表,实现客户端负载均衡。这是因为,ClickHouse本身提供了分布式表的写入方式,但关系到对ClickHouse自身的稳定性评估,在平台内部是绝对禁止使用的。

3.优化参数设置。ClickHouse副本是通过ZooKeeper来管理元数据的,在使用中总会遇到稳定性问题,比如变成只读、不可写或者数据不一致等问题。关于是否使用复制集(Replication),很多社区朋友在使用时大都很谨慎,有些公司甚至因为不稳定都没有配置副本。对此,建议优化一些参数设置,针对ZooKeeper管理的节点/表情况进行一定的控制,同时配合稳定写入,这样在使用复制集(Replication)时候就可以保证稳定性,同时还解决了在部分节点出现问题时数据的完整性和可靠性问题。

最佳实践之参数配置

在实践中,百分点已经优化了一些参数,沉淀出了非常稳定的参数配置,并且在大会上进行了公布,涉及查询导致进程奔溃问题、使用Replications时与ZooKeeper通信引起的集群状态异常等常见问题。

4.基于Nginx实现负载均衡,同时控制查询入口机器。实际上,分布式表的配置只需要在几个入口机器进行相关配置就可以,也可以使用LBS组件。同时针对热数据做查询预热,将日志表分析出来近期或者最近几天的客户经常采用的SQL进行分析,在数据资产管理平台里面,通过数据工厂将其变成离线调度的任务并主动缓存。这样一来,针对热数据场景的查询会走PageCache缓存,性能上也将得到数量级的提升。

5.收集Nginx中的所有查询日志并分析,基于Grafana进行可视化展现。一方面,这对搜集和优化线上的查询语句特别重要,因此在平台上线后,百分点会针对长尾的查询进行分析。另一方面,系统对于低效或者不标准的SQL写法的反馈,也会推动业务系统进行SQL优化。

一个不能忽视的关键问题是,如何保障多中心核心存储ClickHouse的稳定?

对此,百分点定义了危险区域和安全区域。赵群介绍,根据写入及业务情况查询的并发情况定,百分点得到这样一个关系:比如以10W/s提交(包括并发提交情况),可以支撑90并发数的查询,当超过这个数的时候,节点就会出现不稳定情况。

关于如何评估节点稳定性,首先要结合ClickHouse的特性,因其在每次提交都会生成一个Part,后台会有异步任务进行Part合并,当Part数量默认超过150个的时候,ClickHouse会进行强制写入延时,当Part数量超过300的时候直接就抛异常了。因此,针对这种特性需要实现写入part和part合并的相对均衡,也就是说保持分区中Part数量是一个相对稳定的值,不能随着时间增加而增加,如果不这样做,时间积累到一定程度肯定会现出问题。进一步说,Part的稳定代表着经过估算的提交频率的稳定。这是什么意思呢?简单来说,一个本地表每分钟提交的频率是固定的,变化的只是批次提交的数据量。比如,本地表每分钟提交20次,每次最多提交30W。这样即使出现业务高峰期,Part数量也是不变的,变化的只是单个part中的数据量。这也是一种流量控制,通过这样就可以很好地评估ClickHouse集群的设计写入和查询能力。

以此类推,基于这个理念百分点应用SparkStreaming同样实现了处理能力评估和流量控制能力。

以一个例子来说明服务能力透明化的整体思路:假设写入节点为100,SparkStreaming的时间窗口是3秒,每个Executor处理能力是3W/s,每分钟就会生成20个Part。如果需要300W的处理能力,就可以配置Executor的数量为100。每分钟生成2000个Part,平均到一个节点是20个Part。这样一来,就可以保障提交频率和数据量的稳定,即使流量压力加大,也能直接加大时间窗口(比如加到6秒),这样Part的数量就会减少一半。

值得注意的是,万亿级大数据平台进行整体处理能力评估时,一定是要遵循硬件利用率的最大化,细化到每一个任务资源配额,还要基于资源配额的组件处理能力设计值。为了保证数据的可靠性,在选择磁盘Raid时,强力推荐试用Raid5,同时针对Raid5方式做热备份,这样当一块硬盘坏了之时就会自动替代,并不会引起一些问题。不过在实际项目中,经过多个维度的测试后发现,Raid在提升查询能力方面十分有限。

最后,为了数据平台的持续运维与监控设计和实现,百分点拥抱开源,基于Ambari、Zabblx和Grafana做了一套可视化监控体系。

具体来说,通过Ambari进行大数据基础组件的安装并进行相关监控;Zabblx负责服务、网络、硬件相关的情况,虽然传统但实际应用中非常高效;同时结合Zabbix和Ambari Metric监控信息接入到Grafana中做更优化的展现;对于采集不到的信息,通过Exporter放到Prometheus中进行监控。实际上,ClickHouse本身有一些支持的插件来做监控,为了进一步使组件服务透明化,百分点还增加了很多服务能力方面的监控,并根据能力配置相应的警戒线,比如会监控ClickHouse当天的数据分布情况,写入吞吐、查询并发、处理延时等。

百分点认为,面对如此巨大的数据量,在万亿级大数据平台建设中架构是重中之重,架构设计的好坏直接关系到平台整体是否可以稳定运行。

百分点国家级大数据建设实践,在项目规划、问题分解、测试选型等整个流程中,贯穿了百分点万亿级大数据分析平台的核心设计理念:服务透明化、管理精细化。百分点为客户交付了自主可控、跨数据中心的解决方案的同时,也希望以自身实践经验分享回馈社区,推进大数据平台架构创新和行业落地。

Image placeholder
西西呀
未设置
  69人点赞

没有讨论,发表一下自己的看法吧

推荐文章
宜信微服务任务调度平台建设实践|分享实录

导读:如今,无论是互联网应用还是企业级应用,都充斥着大量的批处理任务,常常需要一些任务调度系统帮助我们解决问题。随着微服务化架构的逐步演进,单体架构逐渐演变为分布式、微服务架构。内容来源:宜信技术学院

Kafka 集群在马蜂窝大数据平台的优化与应用扩展

马蜂窝技术原创文章,更多干货请订阅公众号:mfwtechKafka是当下热门的消息队列中间件,它可以实时地处理海量数据,具备高吞吐、低延时等特性及可靠的消息异步传递机制,可以很好地解决不同系统间数据的

媒体开放日,探秘百分点认知智能战略!

2009年7月1日,数据智能技术公司百分点正式成立,今年正好是第10个年头。百分点公司新址10年间,百分点经过多次转型,逐步形成了目前的企业级(ToB)、政府级(ToG)和SaaS服务三大业务体系,服

万亿级消息背后: 小米消息队列的实践

目录业务背景架构与关键问题性能与资源优化平台化效率小米消息中间件的规划与愿景前文《消息队列价值思考》讲述了消息中间件在企业IT架构中的重要价值,本文将呈现这些价值在落地小米业务过程中的遇到的问题和实践

耗时6年生成代码1.6亿行,农业银行大数据平台打造攻略!

摘要: 耗时6年,135个项目,8000页需求,累计投入11000多人月,生成的代码行1.6亿行,支持了8大业务领域,33条业务线,120多个应用场景,这就是中国农业银行大数据平台。近日,中国人民银行

腾讯万亿级 Elasticsearch 技术解密

作者: johngqjiang,腾讯TEG云架构平台部研发工程师Elasticsearch(ES)作为开源首选的分布式搜索分析引擎,通过一套系统轻松满足用户的日志实时分析、全文检索、结构化数据分析等多

研发总监谈:异地研发中心的建设的若干要点(上)

和楼主说好要写一点技术管理方向的文章,从开始说到正式接受主题为《异地研发中心建设模式》的约稿有数月之久,原计划1~2周内写完,结果光思考“应该要写什么”就花了一个月。一方面是拖延癌的原因,另一方面也是

Oracle ADW业务数据平台点亮DTCC2019数据库技术大会!

数字大脑、互联网+、智能+、人工智能、边缘计算……信息技术领域好像从不缺少概念,但无论世界如何变化,数据是一切业务的核心。要想有效管理、分析和挖掘数据带来的价值,数据库一定是必需品。2019年5月8日

DTCC 干货 | 腾讯营销数据平台

摘要:广告平台是一个数据驱动的平台,数据在系统中高效流动,形成闭环,产生价值。腾讯广告系统每天有上百亿次请求量,以及上百T的数据,保证数据流的稳定可靠和高性能是数据系统的核心问题。对于数据分析场景,腾

代表性企业级大容量氦气硬盘解析:希捷Exos X14

 海量数据时代,AI、大数据、物联网等技术不止带来了业务应用的转型,还带来了数据的“井喷式”爆发增长。IDC曾预测,2025年全球数据量将高达163ZB。在如此情况下,数据存储成了一个至关重要的问题,

亿级海量数据的实时读写和复杂查询实践

摘要:本文分享了每日亿级增量数据的实时读写、复杂查询场景实践介绍,涉及MySQL分表分库策略、数据异构、TiDB使用和优化、微服务架构等内容。  作者:黄哲铿  黄哲铿,中通商业CTO,前1号店技术总

谈PaaS平台建设:如何应对企业架构多元异构资源的挑战

据forbes预测,在2020年到来之前,83%的IT资源都会迁移上云。整个云的生态中,PaaS是最具有抽象属性的云形态,落地较晚也迟迟没有形成统一的标准。近几年,随着SaaS层业务的成熟,以及Iaa

做银行家里的数据专家:ING探索大数据时代下的金融最佳实践

大数据文摘出品记者:高延6月18-21日,O’ReillyAIConference在北京召开。大会上,来自荷兰的金融公司ING的IT主管BasGeerdink带来了《关于数字驱动企业》的主题分享。进入

如何构建批流一体数据融合平台的一致性语义保证?

一、批流一体架构 批和流是数据融合的两种应用形态 下图来自Flink官网。传统的数据融合通常基于批模式。在批的模式下,我们会通过一些周期性运行的ETLJOB,将数据从关系型数据库、文件存储向下游的目标

建立开放的大数据精准扶贫平台,让全社会参与进来!

精准扶贫”的重要思想最早是在2013年11月,习近平主席到湖南湘西考察时首次作出了“实事求是、因地制宜、分类指导、精准扶贫”的重要指示。2015年6月,习近平主席在贵州召开部分省区市党委主要负责同志座

包银消费CTO汤向军:消费金融大数据风控架构与实践

01风险在哪里1.1 信用风险根据银行业的风险理论,信用风险是指借款人因各种原因未能及时、足额偿还债权人或银行贷款而违约的可能性。信用风险的风控重点在于,甄别客户违约的原因究竟是还款能力,还是还款意愿

MySQL 亿级数据数据库优化方案测试-银行交易流水记录的查询

作者:逸宸a链接:https://www.jianshu.com/p/cbdef47fb837对MySQL的性能和亿级数据的处理方法思考,以及分库分表到底该如何做,在什么场景比较合适?比如银行交易流水

Kubernetes1.14 版发布,增强了云原生平台的Windows节点支持

Kubernetes1.14GA版本,是开源云原生平台Kubernetes在2019年的一次重大更新。自3月25日开始,这一版本正式推出,供开发者全面使用。  Kubernetes,由云原生计算基金会

使用Electron构建跨平台的桌面应用

作者:李晓健。苏宁视频云前端部门经理。拥有7年前端业务研发和架构经验,目前负责苏宁云视频前端研发和架构工作。Electron简介Electron是一个使用JavaScript,HTML和CSS等Web

华为斥资1.5亿启动金种子计划, ITPUB联合推进数据库生态建设!

9月19日,主题为“鲲鹏聚数,‘芯’融合数据基础设施,使能数字经济”峰会在上海世博展览馆召开。期间,鲲鹏智能数据产业联盟-数据库产业推进组,举行成立仪式!数据库产业推进组,主要由华为牵头,联合产、学、

ElasticSearch 亿级数据检索案例实战

一、前言数据平台已迭代三个版本,刚开始遇到很多常见的难题,终于有时间整理一些已完善的文档了,在此分享一下。希望能帮助大家少走些弯路,在此篇幅中偏重于ES的优化。关于HBase,Hadoop的设计优化估

Elasticsearch 亿级数据检索性能优化案例实战!

一、前言数据平台已迭代三个版本,从头开始遇到很多常见的难题,终于有片段时间整理一些已完善的文档,在此分享以供所需朋友实现参考,少走些弯路,在此篇幅中偏重于ES的优化,关于HBase,Hadoop的设计

干货 | 每天十亿级数据更新,秒出查询结果,ClickHouse在携程酒店的应用

本文转自 |携程技术中心 作者 |蔡岳毅作者简介蔡岳毅,携程酒店大数据高级研发经理,负责酒店数据智能平台研发,大数据技术创新工作。喜欢探索研究大数据的开源技术框架。一、背景1)携程酒店每天有上千表,累

10分钟搞懂:亿级用户的分布式数据存储解决方案!

来源:IT进阶思维原创,转载请注明原出处内容提供:李智慧,前阿里巴巴技术专家,《大型网站技术架构》作者6月6日晚,林志玲与Akira公布婚讯、徐蔡坤祝福高考同学超常发挥,粉丝们百万的转发和点赞造成微博

搞个大事情,阿里如何实现上亿级数据的精准计数?

背景关系型数据库在执行计数任务时,其执行效率会随着数据量级的增长而降低;当数据量达到亿级别时,计数任务的执行效率已经低到令人不忍直视。在闲鱼团队的关系系统中,我们采用了这样一种方式来实现亿级别数据的毫