您当前的位置:首页 > 新闻 > 科技

基于 Apache Druid 的实时分析平台在爱奇艺的实践

时间:2020-06-11 13:39:31  来源:  作者:

最近几年大数据技术在各行各业得到广泛应用,为企业的运营决策和各种业务提供支持。随着数据的增长,业务对数据时效性的要求,给企业的大数据分析带来了巨大挑战。针对海量数据的实时分析需求,近年来市场上涌现出众多OLAP分析引擎。这些OLAP引擎有各自的适用场景和优缺点,如何选择一款合适的引擎来更快地分析数据、更高效地挖掘数据的潜在价值?

爱奇艺大数据服务团队评估了市面上主流的OLAP引擎,最终选择Apache Druid时序数据库来满足业务的实时分析需求。本文将介绍Druid在爱奇艺的实践情况、优化经验以及平台化建设的一些思考。

爱奇艺大数据OLAP服务

爱奇艺大数据OLAP服务在2015年前主要以离线分析为主,主要基于Hive+MySQL、HBase等。2016年起引入Kylin和Impala分别支持固定报表和Ad-hoc查询。2018年以来引入Kudu和Druid支持实时分析需求。

基于 Apache Druid 的实时分析平台在爱奇艺的实践

 

在引入Druid之前,业务的一些场景无法通过离线分析满足,如广告主想要实时基于投放效果调整投放策略、算法工程师调整模型推到线上A/B要隔天离线报表才能看到效果。这些场景都可以归纳为对海量事件流进行实时分析,经典的解决方案有如下几种:

  • 离线分析 :

使用Hive、Impala或者Kylin,它们一个共同的缺点是时效性差,即只能分析一天或者一小时前的数据,Kylin还面临维度爆炸的问题

  • 实时分析:
  • 用ElasticSearch或OpenTSDB,由于数据结构本质是行存储,聚合分析速度都比较慢;可以通过查询缓存、OpenTSDB预计算进行优化,但不根本解决问题;
  • 用流任务(Spark/Flink)实时地计算最终结果,存储在MySQL提供进一步服务;问题是每当需求调整,如维度变更时,则需要写新的流任务代码;
  • 使用Kudu和Impala结合能够做到实时分析。在实践过程中发现,Kudu受限于内存和单机分区数,支撑海量数据成本很大;

无论选用哪种实时或离线方案的组合,都会采用Lambda架构,用离线数据校准实时数据。这意味着从摄入、处理、查询都需要维护两套架构,新增一个维度,离线和实时均需对应修改,维护困难

基于 Apache Druid 的实时分析平台在爱奇艺的实践

 

以上种种方案的不足,促使我们寻找新的解决方案,最终决定采用Druid。

Apache Druid介绍

Apache Druid是针对海量事件流进行存储和实时多维分析的开源系统。它具有如下特性:

  • 实时可见:消息摄入后分钟级查询可见
  • 交互查询:查询延时在秒级,核心思想为内存计算和并行计算
  • 维度灵活:支持几十个维度任意组合,仅在索引时指定的维度查询可见
  • 易于变更:需求变更后调整索引配置立马生效;
  • 流批一体:新版本KIS模式可实现Exactly Once语义
基于 Apache Druid 的实时分析平台在爱奇艺的实践

 

上图为Druid架构图,大体分为几个模块:

  • MiddleManager :索引节点,负责实时处理消息,将其转成列式存储,并通过Rollup精简数据量;索引节点定期将内存中数据持久化为不可修改的文件(Segment),保存至HDFS保证数据不会丢失;
  • Historical :历史节点,将Segment加载到本地,负责大部分查询的计算;
  • Broker :查询节点,将查询分解为实时和离线部分,转发给索引节点和历史节点,并汇总最终的查询结果;
  • Overlord :负责索引任务管理;
  • Coordinator :负责负载均衡,确保Segment在历史节点之间尽量均衡;

Druid在爱奇艺的实践

Druid很好地填补了爱奇艺在实时OLAP分析领域的空白,随着业务实时分析需求的增加,Druid集群和业务规模也在稳步增长。目前集群规模在数百个节点,每天处理数千亿条消息,Rollup效果在10倍以上。平均每分钟6千条查询,P99延时一秒内,P90延时在200毫秒内。在建设Druid服务过程中,我们也不断遇到规模增长带来的性能瓶颈和稳定性问题。

1.Coordinator瓶颈

当时的挑战是实时索引任务经常被阻塞。Druid的Handoff总结如下,索引节点将Segment持久化到HDFS,然后Coordinator制定调度策略,将计划发布到ZooKeeper。历史节点从ZooKeeper获取计划后异步地加载Segment。当历史节点加载完Segment索引节点的Handoff过程才结束。这个过程中,由于Coordinator制定计划是单线程串行的,如果一次触发了大量Segment加载,执行计划制定就会很慢,从而会阻塞Handoff过程,进而索引节点所有的Slot均会被用满。

而以下过程均会触发大量Segment加载,在解决Coordinator调度性能瓶颈前, 很容易引发故障:

• 历史节点因硬件故障、GC、主动运维退出

• 调整Segment副本数、保留规则

通过火焰图对Coordinator进行Profiling最终定位了问题,如下图所示,将最耗时部分放大出来,是负载均衡策略对每个Segment要选择一个最佳的服务器。阅读源码可知其过程为,加载Segment X,需要计算它和服务器的每个Segment Y的代价Cost(X, Y),其和为服务器和Segment X的代价。假设集群有N个Segment,M个Historical节点,则一个节点宕机,有N/M个Segment需要加载,每个Segment都和剩余的N个节点计算一次代价,调度耗时和N成平方关系。

一个节点宕机调度耗时 = (N/M)个Segment * 每个Segment调度耗时 = (N/M) * N = O(N^2)

分析清楚原因后,很容易了解到Druid新很容易了解到Druid新版本提供了新的负载均衡策略(
druid.coordinator.balancer.strategy =
CachingCostBalancerStrategy ),应用后调度性能提升了10000倍,原先一个历史节点宕机会阻塞Coordinator1小时到2小时,现在30秒内即可完成。

基于 Apache Druid 的实时分析平台在爱奇艺的实践

 

2.Overlord瓶颈

Overlord性能慢,我们发现升级到0.14后Overlord API性能较差,导致的后果是索引任务概率性因调用API超时而失败。通过Jstack分析,看到大部分的HTTP线程均为阻塞态,结合代码分析,定位到API慢的原因,如左图所示,Tranquility会定期调用Overlord API,获取所有RunningTasks,Overlord内部维护了和MySQL的连接池,该连接池默认值为8,该默认值值过小,阻塞了API处理。解决方法是增大dbcp连接池大小。
druid.metadata.storage.connector.dbcp.maxTotal = 64

基于 Apache Druid 的实时分析平台在爱奇艺的实践

 

调整后,Overlord性能得到了大幅提升,Overlord页面打开从几十秒降低到了几秒。但意料之外的事情发生了,API处理能力增加带来了CPU的飙升,如右图所示,并且随着Tranquility任务增加CPU逐渐打满,Overlord页面性能又逐步降低。通过火焰图Profile可知,CPU主要花费在getRunningTasks的处理过程,进一步分析Tranquility源码后得知,Tranquility有一个配置项(
druidBeam.overlordPollPeriod)可以控制Tranquility轮询该API的间隔,增大该间隔后问题得到了暂时缓解,但根本的解决方案还是将任务切换为KIS模式。

3.索引成本

Druid索引成本过高。基于Druid官方文档,一个Druid索引任务需要3个核,一个核用于索引消息,一个核用于处理查询,一个核用于Handoff过程。我们采用该建议配置索引任务,压测结果是3核配置下能够支撑百万/分钟的摄入。

在最初,集群所有的索引任务都是统一配置,但实际使用过程中,大部分的索引任务根本达不到百万/分钟的消息量,造成了资源大量浪费。如下图所示,我们按照索引任务的内存使用量从高到低排序,9 GB为默认配置,80%的任务利用率低于1/3,即3 GB。我们以3 GB绘制一条横线,以内存使用最接近的任务绘制一条竖线,定义A为实际使用的内存,B为第二象限空白部分,C为第四象限空白部分,D为第一象限空白部分,则浪费的资源 = (B+C+D)的面积。

我们思考能否采取索引任务分级的策略,定义一种新的类型索引节点 – Tiny节点。Tiny节点配置改为1 core3GB,能够满足80%小任务的资源需求,而default节点继续使用 3 core9 GB的配置,满足20%大任务的需求,在这种新的配置下,浪费的资源 = (B + C)的面积,D这一大块被省下来。简单地计算可知,在不增加机器的情况下,总Slots能够增加1倍。

默认slot资源需求为1,Tiny为1/3,调整后单位任务需要的资源 = 0.2 * 1 + 0.8 * 1/3 = 0.5

基于 Apache Druid 的实时分析平台在爱奇艺的实践

 

在实际操作层面,还需解决一个问题,即如何把Datasource指定给合适的Worker节点。在Druid低版本中,需要通过配置文件将每一个Datasource和Worker节点进行关联,假设有N个Datasource,M个Worker节点,这种配置的复杂度为 N * M,且无法较好地处理Worker节点负载均衡,Worker宕机等场景。在Druid 0.17中,引入了节点Category概念,只需将Datasource关联特定的Category,再将Category和Worker绑定,新的配置方法有2个Category,复杂度 = 2 * N + 2 * M。

4.Tranquility vs KIS

刚使用Druid时,当时主力模式是Tranquility。Tranquility本质上仍然是经典的Lambda架构,实时数据通过Tranquility摄入,离线数据通过HDFS索引覆盖。通过离线覆盖的方式解决消息延迟的问题,缺点是维护两套框架。对于节点失败的问题,Tranquility的解决方案是链路冗余,即同时在两个索引节点各起一份索引任务,任一节点失败仍有一份能够成功,缺点是浪费了一倍的索引资源。自0.14版本起,Druid官方建议使用KIS模式索引数据,它提供了Exactly Once语义,能够很好地实现流批一体。

基于 Apache Druid 的实时分析平台在爱奇艺的实践

 

和Tranquility的Push模式不同,KIS采取Pull模式,索引任务从Kafka拉取消息,构建Segment。关键点在于最后持久化Segment的时候,KIS任务有一个数据结构记录了上一次持久化的Offset位置,如图例左下角所示,记录了每个Kafka Partition消费的Offset。在持久化时会先检查Segment的开始Offset和元信息是否一致。如果不一致,则会放弃本次持久化,如果一致,则触发提交逻辑。提交中,会同时记录Segment元信息和Kafka Offset,该提交过程为原子化操作,要么都成功,要么都失败。

基于 Apache Druid 的实时分析平台在爱奇艺的实践

 

KIS如何处理各个节点失败的情况呢?假设Kafka集群失败,由于是Pull模式,Druid在Kafka恢复后继续从上一个Offset开始消费;假设Druid索引节点失败,Overlord后台的Supervisor会监控到相应任务状态,在新的索引节点启动KIS任务,由于内存中的状态丢失,新的KIS任务会读取元信息,从上一次的Offset开始消费。假设是MySQL或者更新元数据过程失败,则取决于提交的原子操作是否成功,若成功则KIS从新的Offset开始消费,失败则从上一次Offset开始消费。

进一步看一下KIS是如何保证Exactly Once语义。其核心是保证Kafka消费的Offset连续,且每个消息都有唯一ID。Exactly Once可以分为两个部分,一是At Least Once,由KIS检查Offset的机制保证,一旦发现缺失了部分Offset,KIS会重新消费历史数据,该过程相当于传统的离线补数据,只是现在由Druid自动完成了。另一个是At Most Once,只要保证Offset没有重叠部分,则每条消息只被处理了一次。

以下是KIS在爱奇艺的一个实例,左下图为业务消息量和昨天的对比图,其中一个小时任务持久化到HDFS失败了,看到监控曲线有一个缺口。之后Druid后台启动了一个新的KIS任务,一段时间后,随着KIS补录数据完成,曲线图恢复到右下图所示。那么,如果业务不是一直盯着曲线看,而是定期查看的话,完全感受不到当中发生了异常。

基于 Apache Druid 的实时分析平台在爱奇艺的实践

 

基于Druid的实时分析平台建设

Druid性能很好,但在初期推广中却遇到很大的阻力,主要原因是Druid的易用性差,体现在如下几个方面:

  1. 数据摄入需要撰写一个索引配置,除了对数据自身的描述(时间戳、维度和度量),还需要配置Kafka信息、Druid集群信息、任务优化信息等
  2. 查询的时候需要撰写一个JSON格式的查询,语法为Druid自定义,学习成本高
  3. 返回结果为一个JSON格式的数据,用户需自行将其处理成最终图表、告警
  4. 报错信息不友好,上述所有配置均通过JSON撰写,一个简单的逗号、格式错误都会引起报错,需花费大量时间排查

为解决Druid易用性差的问题,爱奇艺自研了实时分析平台RAP(Realtime Analysis Platform),屏蔽了Kafka、Druid、查询的细节,业务只需描述数据格式即可摄入数据,只需描述报表样式、告警规则,即可配置实时报表和实时告警。

RAP实时分析平台,主要有六大特性:

  • 全向导配置:业务无需手写ETL任务
  • 计算存储透明:业务无需关心底层OLAP选型
  • 丰富报表类型:支持常见的线图、柱状图、饼图等
  • 数据延时低:从App数据采集到生成可视化报表的端到端延时在5分钟内,支持数据分析师、运营等业务实时统计分析UV、VV、在线用户数等
  • 秒级查询:大部分查询都是秒以内
  • 灵活变更:更改维度后重新上线即可生效
基于 Apache Druid 的实时分析平台在爱奇艺的实践

 

RAP实时分析平台目前已经在爱奇艺会员、推荐、BI等多个业务落地,配置了上千张报表,帮助业务在实时监控报警、实时运营分析、实时AB测试对比等场景提升排障响应速度、运营决策效率。

未来展望

进一步迭代完善Druid及RAP,提升稳定性、服务能力,简化业务接入成本:

• 接入爱奇艺自研的Pilot智能SQL引擎,支持异常查询拦截、限流等功能

• 运维平台:包括元信息管理、任务管理、服务健康监测等,提升运维效率

• 离线索引:支持直接索引Parquet文件,通过Rollup进一步提升查询效率

• 支持JOIN:支持更丰富的语义

 



Tags:Apache Druid   点击:()  评论:()
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,如有任何标注错误或版权侵犯请与我们联系(Email:2595517585@qq.com),我们将及时更正、删除,谢谢。
▌相关推荐
目前广为人知的Druid有两个,一个是阿里巴巴开源的Durid数据库连接池,一个是MetaMarkets开源的分布式、实时多维OLAP分析的数据处理系统。这篇文章将介绍后者,即Apache Druid。...【详细内容】
2021-01-12  Tags: Apache Druid  点击:(280)  评论:(0)  加入收藏
最近几年大数据技术在各行各业得到广泛应用,为企业的运营决策和各种业务提供支持。随着数据的增长,业务对数据时效性的要求,给企业的大数据分析带来了巨大挑战。针对海量数据的...【详细内容】
2020-06-11  Tags: Apache Druid  点击:(40)  评论:(0)  加入收藏
> Photo by Carlos Muza on Unsplash Apache druid是最流行的在线分析处理(OLAP)开源解决方案之一。 Airbnb和Netflix等许多科技公司都使用它来对每分钟包含数百万个事件的数...【详细内容】
2020-04-17  Tags: Apache Druid  点击:(78)  评论:(0)  加入收藏
▌简易百科推荐
非法购买公民信息、开发人脸认证规避技术……今年年初,广东省公安厅网安部门侦破全国首例破解“青少年防沉迷系统”的新型网络犯罪案件,抓获犯罪嫌疑人13名,查处非...【详细内容】
2021-12-28    人民日报客户端  Tags:数据安全步   点击:(5)  评论:(0)  加入收藏
就在今天,腾讯方面宣布将在2022年1月31日下架企业QQ和营销QQ,其实这一消息的降临并不让笔者意外,因为早在今年的10月28日20点之后,企业QQ和营销QQ就被停止了续费服务。相信很多...【详细内容】
2021-12-27  科技探险家    Tags:企业QQ   点击:(20)  评论:(0)  加入收藏
日前,上海交通大学发布《全球电竞之都评价报告》,对全球15个致力于发展电竞之都的城市进行评价,上海作为中国城市电竞发展的排头兵,其拥有众多优质电竞企业及完整产业集群,因此排...【详细内容】
2021-12-27  经济日报    Tags:电竞   点击:(3)  评论:(0)  加入收藏
为优化网络氛围环境,微博又开始整顿用户信息了。本月月初,微博官方发布公告,要求昵称中带有如“二货”“SB”“瘪三”“娘炮”等明显低俗或侮辱性词汇的用户尽快修改,否则将面临...【详细内容】
2021-12-24  运了个营    Tags:微博   点击:(10)  评论:(0)  加入收藏
昨日谷歌宣布,自2022年12月19日开始停止对OnHub的软件支持,OnHub路由器仍将提供Wi-Fi信号,但用户无法用谷歌Home应用程序管理它。无法更新Wi-Fi网络设置、添加额外的Wifi设备或...【详细内容】
2021-12-22  雷峰网    Tags:Google OnHub   点击:(5)  评论:(0)  加入收藏
IT之家 12 月 20 日消息,百度网盘青春版 iOS 客户端今日晚间率先开启内测,安卓客户端将在稍后内测。使用苹果 iPhone 的IT之家小伙伴可以点此下载内测版,需要先下载 TestFlight...【详细内容】
2021-12-21  IT之家    Tags:百度网盘   点击:(10)  评论:(0)  加入收藏
对于拼车单,是接还是不接,不少网约车司机表示很矛盾。接吧,钱少事多,常常跑了个寂寞,不接吧,车多客少,挑三拣四没饭吃。 在平台大力推广拼车单之下,不少司机迫于生活压力,最终还是打...【详细内容】
2021-12-17  网约车情报分享    Tags:滴滴   点击:(9)  评论:(0)  加入收藏
蓝鲸TMT频道12月16日讯,据饿了么官方微信公众号,近日,在圆桌会上,蓝骑士与平台交流了配送安全问题。饿了么表示,线上将技术手段融入安全防护;线下将持续进行安全培训,并试点智能头...【详细内容】
2021-12-17    金融界  Tags:饿了么   点击:(24)  评论:(0)  加入收藏
开源最前线(ID:OpenSourceTop) 猿妹编译项目地址: https://github.com/restic/restic全球知名代码托管平台 GitHub 今天就重磅发布了今年的年度报告——《2021 年度 O...【详细内容】
2021-12-17  Python部落    Tags:   点击:(9)  评论:(0)  加入收藏
新京报快讯 据中国网络视听节目服务协会网站消息,12月15日,中国网络视听节目服务协会发布了《网络短视频内容审核标准细则》(2021)。中国网络视听节目服务协会组织有关短视频平...【详细内容】
2021-12-16    新京报  Tags:短视频   点击:(11)  评论:(0)  加入收藏
相关文章
    无相关信息
最新更新
栏目热门
栏目头条