应用实践ApacheDoris在小米集团

背景为了提高小米增长分析平台的查询性能以及降低平台的运维成本,年9月小米集团首次引入了ApacheDoris。在过去两年多的时间里,ApacheDoris在小米集团得到了广泛的应用,目前已经服务了增长分析、集团数据看板、天星金融、小米有品、用户画像、广告投放、A/B实验平台、新零售等数十个业务,如图1所示。在小米集团,质量就是生命线,随着业务持续增长,如何保障线上Doris集群的服务质量,对集群的运维人员来说是个不小的挑战。本文将从运维的角度对ApacheDoris在小米集团的应用实践进行分享。图1-ApacheDoris在小米的业务分布集群部署和升级基于ApacheDoris社区发布的稳定版本,小米也维护了内部的Doris分支用于内部小版本的迭代。由于和社区编译Docker第三方库的硬件环境存在差异,基于社区Docker编译出的Doris二进制包运行在小米的线上环境会有问题,因此小米内部也维护了自己的Docker镜像,用于内部Doris分支的编译及发版。内部发版时,在Docker容器中会完成源码的编译和打包,并通过Minos将二进制包上传到TankServer(小米内部的版本仓库),小米内部的Doris发版流程如图2所示。图2-小米内部的Doris发版流程

Minos是小米自研并开源的一款基于命令行的大数据部署和进程管理系统,支持Doris、HDFS、HBase、Zookeeper等服务的部署和管理。在小米内部,包上传、集群部署、集群下线、集群升级、进程重启、配置变更等操作都可以通过Minos完成,Minos对于服务的管理依赖于配置文件deployment-config,其中配置了服务版本信息、集群的节点信息、集群的配置参数等信息。部署集群时,Minos会根据deployment-config中配置的服务版本信息从TankServer上拉取对应的二进制包,并根据deployment-config中配置的节点信息和集群参数部署集群。在集群部署之后,如果进程意外挂掉,Minos会自动拉起进程,恢复服务。

轻舟是小米自研的分布式服务生命周期管理平台,贯穿分布式大数据系统从需求评估开始到资源下线结束的生命周期互联互通管理,主要由发布中心、巡检中心、运营数仓、环境管理、故障管理、容量管理等组成,各模块之间逻辑互联、数据互通,如图3所示。轻舟发布中心提供了可编排、低代码、可视化的服务发布和进程管理能力。轻舟发布中心底层依赖Minos,因此,可以基于轻舟对Doris服务实现平台化管理,包括集群部署、集群下线、集群升级、进程重启、配置变更等操作,如果Doris的FE或BE进程意外挂掉,轻舟会自动拉起进程,恢复服务。图3-轻舟管理平台业务实践ApacheDoris在小米的典型业务实践如下:01用户接入数据工场是小米自研的、面向数据开发和数据分析人员的一站式数据开发平台,底层支持Doris、Hive、Kudu、Iceberg、ES、Talso、TiDB、MySQL等数据源,同时支持Flink、Spark、Presto等计算能力。

在小米内部,用户需要通过数据工场接入Doris服务,用户需要在数据工场进行注册,并完成建库审批,Doris运维同学会根据数据工场中用户提交的业务场景、数据使用预期等描述进行接入审批和指导,用户完成接入审批后即可使用Doris服务,在数据工场中进行可视化建表和数据导入等操作。

02数据导入在小米的业务中,导入数据到Doris最常用的两种方式是StreamLoad和BrokerLoad。用户数据会被划分为实时数据和离线数据,用户的实时和离线数据一般首先会写入到Talos中(Talos是小米自研的分布式、高吞吐的消息队列)。来自Talos的离线数据会被Sink到HDFS,然后通过数据工场导入到Doris,用户可以在数据工场直接提交BrokerLoad任务将HDFS上的大批量数据导入到Doris,也可以在数据工场执行SparkSQL从Hive中进行数据查询,并将SparkSQL查到的数据通过Spark-Doris-Connector导入到Doris,Spark-Doris-Connector底层对StreamLoad进行了封装。来自Talos的实时数据一般会通过两种方式导入到Doris,一种是先经过Flink对数据进行ETL,然后每隔一定的时间间隔将小批量的数据通过Flink-Doris-Connector导入到Doris,Flink-Doris-Connector底层对StreamLoad进行了封装;实时数据的另一种导入方式是,每隔一定的时间间隔通过SparkStreaming封装的StreamLoad将小批量的数据导入到Doris。03数据查询小米的Doris用户一般通过数鲸平台对Doris进行分析查询和结果展示。数鲸是小米自研的通用BI分析工具,用户可以通过数鲸平台对Doris进行查询可视化,并实现用户行为分析(为满足业务的事件分析、留存分析、漏斗分析、路径分析等行为分析需求,我们为Doris添加了相应的UDF和UDAF)和用户画像分析。Doris的数据导入和数据查询方式如图4所示。

图4-Doris的数据导入和数据查询方式

04Compaction调优

对Doris来说,每一次数据导入都会在存储层的相关数据分片(Tablet)下生成一个数据版本,Compaction机制会异步地对导入生成的较小的数据版本进行合并(Compaction机制的详细原理可以参考之前的文章《DorisCompaction机制解析》)。小米有较多高频、高并发、近实时导入的业务场景,在较短的时间内就会生成大量的小版本,Compaction对数据版本合并不及时的话,就会造成版本累积,一方面过多的小版本会增加元数据的压力,另一方面版本数太多会影响查询性能。小米的使用场景中,有较多的表采用了Unique和Aggregate数据模型,查询性能严重依赖于Compaction对数据版本合并是否及时,在我们的业务场景中曾经出现过因为版本合并不及时导致查询性能降低数十倍,进而影响线上服务的情况。但是,Compaction任务本身又比较耗费机器的CPU、内存和磁盘IO资源,Compaction放得太开会占用过多的机器资源,也会影响到查询性能,还可能会造成OOM。

针对Compaction存在的这一问题,我们一方面从业务侧着手,通过以下方面引导用户:对表设置合理的分区和分桶,避免生成过多的数据分片。规范用户的数据导入操作,尽量降低数据导入频率,增大单次导入的数据量,降低Compaction的压力。避免过多地使用delete操作。delete操作会在存储层的相关数据分片下生成一个delete版本,CumulativeCompaction任务在遇到delete版本时会被截断,该次任务只能合并CumulativePoint之后到delete版本之前的数据版本,并将CumulativePoint移动到delete版本之后,把delete版本交给后续的BaseCompaction任务来处理。如果过多地使用delete操作,在Tablet下会生成太多的delete版本,进而导致CumulativeCompaction任务对版本合并的进度缓慢。使用delete操作并没有真正从磁盘上删除数据,而是在delete版本中记录了删除条件,数据查询时会通过Merge-On-Read的方式过滤掉被删除的数据,只有delete版本被BaseCompaction任务合并之后,delete操作要删除的数据才能作为过期数据随着StaleRowset从磁盘上被清除。如果需要删除整个分区的数据,可以使用truncate分区操作,而避免使用delete操作。另一方面,我们从运维侧对Compaction进行了调优:根据业务场景的不同,针对不同集群配置了不同的Compaction参数(Compaction策略、线程数等)。适当地降低了BaseCompaction任务的优先级,增加了CumulativeCompaction任务的优先级,因为BaseCompaction任务执行时间长,有严重的写放大问题,而CumulativeCompaction任务执行比较快,并且能快速合并大量的小版本。版本积压报警,动态调整Compaction参数。CompactionProducer生产Compaction任务时,会更新相应的metric,其中记录了BE节点上最大的CompactionScore的值,可以通过Grafana查看该指标的趋势判断是否出现了版本积压,另外,我们还增加了版本积压的报警。为方便Compaction参数调整,我们从代码层面进行了优化,支持运行时动态调整Compaction策略和Compaction线程数,避免调整Compaction参数的时候需要重启进程。支持手动触发指定Table、指定Partition下数据分片的Compaction任务,提高指定Table、指定Partition下数据分片的Compaction优先级。监控和报警管理01监控系统Prometheus会定时从Doris的FE和BE上拉取Metrics指标,并展示在Grafana监控面板中。基于轻舟数仓的服务元数据(轻舟数仓是轻舟平台基于小米全量大数据服务基础运行数据建设的数据仓库,由2张基表和30+张维度表组成,覆盖了大数据组件运行时的资源、服务器cmdb、成本、进程状态等全流程数据)会自动注册到Zookeeper中,Prometheus会定时从Zookeeper中拉取最新的集群元数据信息,并在Grafana监控面板中动态展示。另外,我们在Grafana中还添加了针对Doris大查询列表、实时写入数据量、数据导入事务数等常见排障数据的统计和展示看板,能够联动报警让Doris运维同学在集群异常时以最短的时间定位集群的故障原因。02Falcon报警Falcon是小米内部广泛使用的监控和报警系统,因为Doris原生地提供了较为完善的metrics接口,可以基于Prometheus和Grafana方便地提供监控功能,所以我们在Doris服务中只使用了Falcon的报警功能。针对Doris出现的不同级别故障,我们将报警定义为P0、P1和P2三个等级:

P2报警(报警等级为低):单节点故障报警。单节点指标或进程状态发生异常一般作为P2等级发出报警,报警信息以小米办公(小米办公是字节跳动飞书在小米的私有化部署产品,功能和飞书类似)消息的形式发送到告警组成员。

P1报警(报警等级为较高):集群短时间(3分钟以内)内查询延迟升高或写入异常等短暂异常状况将作为P1等级发出报警,报警信息以小米办公消息的形式发送到告警组成员,P1等级报警要求Oncall工程师进行响应和反馈。

P0报警(报警等级为高):集群长时间(3分钟以上)查询延迟升高或写入异常等情况将作为P0等级发出报警,报警信息以小米办公消息+电话报警的形式发送,P0级别报警要求Oncall工程师1分钟内进行响应并协调资源进行故障恢复和复盘准备。

以上对报警类型和案例进行了简单举例,实际上为了维护Doris系统稳定,我们还会有形式多样、级别各异的报警和巡检。03Cloud-Doriscloud-Doris是小米针对内部Doris服务开发的数据收集组件,其最主要的能力在于对Doris服务的可用性进行探测以及对内部


转载请注明:http://www.aierlanlan.com/rzdk/8467.html