一、业务背景
BIGO寰球音视频业务对数据的实时能力要求越来越高,数据分析师心愿多维度实时看到新增用户、沉闷用户等业务数据以便尽快把握市场动向,机器学习工程师心愿实时拿到用户的浏览、点击等数据而后通过在线学习将用户偏好疾速退出到模型中,以便给用户推送以后最感兴趣的内容,APP开发工程师心愿可能实时监控APP关上的成功率、解体率。这些实时数据的能力都要依附实时计算平台来提供。从业界来看,实时化的趋势正在减速,本文将介绍BIGO基于flink的实时计算平台的建设教训和成绩。
二、平台介绍
BIGO实时计算的倒退大略分为两个阶段,在2018年之前,实时场景还比拟少,实时的作业数量也不多,过后次要采纳Spark Streaming来反对。从2018年开始,在综合思考了Flink绝对于Spark Streaming的劣势之后,BIGO技术决定将实时计算平台切换到基于flink的技术路线上来。通过近两年的倒退,BIGO实时计算平台日趋完善,根本反对了公司内支流的实时计算场景,下图是BIGO实时计算平台的架构图:
实时计算的数据起源可分为两大类,一类是用户在APP或者浏览器里的浏览、点击等行为日志,通过kafka收集进入实时计算;另一类是用户的行为产生的关系型数据库里记录的扭转,这些改变产生的biglog被BDP抽取进入实时计算。
从图中能够看出,BIGO实时计算平台底层基于yarn来做集群资源管理,借助于Yarn的散布式调度能力,实现大规模集群下的调度。实时平台的计算引擎在开源Flink的根底上,为适配BIGO的场景进行了非凡的定制及开发。实时平台的下层是BIGO自研的一站式开发平台BigoFlow,在这里,用户能够不便的进行作业的开发、调试以及监控运维。BigoFlow提供了欠缺的SQL开发能力、自动化监控配置能力以及日志主动收集、查问能力,让用户仅须要一条SQL,就能够实现一个业务作业。它具备以下性能:
1. 提供了弱小的SQL编辑器,能够进行语法查看及主动提醒。
2. 能够对接公司所有的数据源及数据存储,省去了业务方自定义的工作。
3. 日志主动收集到ES里,用户能够不便的检索和查问,能够疾速的定位谬误。
4. 作业要害指标主动对接到公司的监控告警平台,用户不必再本人配置。
5. 收集所有作业的资源应用状况,主动进行剖析,帮忙辨认、治理不合理作业。
实时计算出来的后果依据业务的需要,会寄存到不同的存储中。ETL类作业的后果通常会入库到hive中,须要进行adhoc查问的数据通常会放到clickhouse外面。监控告警等类型的作业能够间接把后果输入到告警平台的Prometheus数据库里,供告警平台间接应用。
三、业务利用
随着实时计算平台的倒退,越来越多的场景都搬到了BigoFlow平台上,实时计算也给这些场景带了很多益处,上面BIGO技术以几个典型场景为例来阐明实时计算为它们带来的能力或者性能的加强。
数据ETL
数据的抽取、转换是一个典型的实时场景,用户在APP、浏览器里的行为日志是实时不间断产生的,要实时的去采集并通过抽取转换,最初入到数据库里。BIGO之前的ETL场景数据门路通常是Kafka->flume->Hive。通过flume入库的门路存在着一下几方面的问题:
1. Flume的容错能力差,遇到已成可能会导致丢数据或者数据反复。
2. Flume的动静扩大能力差,流量忽然到来时候很难立即扩大。
3. 一旦数据字段或者格局发生变化,flume比拟难于灵便调整。
而Flink提供了基于state的弱小的容错能力,能够端到端exactly once,并发度能够灵便的调整,Flink SQL能够灵便的去调整逻辑。因而,绝大部分的ETL场景目前都曾经迁徙到了Flink架构上。
实时统计
作为一家有多个APP产品的公司,BIGO须要有大量的统计指标来反馈产品的日活、营收等指标。传统这些指标个别都是通过离线Spark作业来每天或者每小时计算一次。离线计算很难保证数据的产生的及时性。常常会呈现重要指标提早产生的问题。因而咱们缓缓的将重要指标通过实时计算来产生,极大的保障了数据产生的及时性。最显著的是之前一个重要指标常常提早导致它的上游在下午能力产出,给数据分析师带来了很多困扰,革新为实时链路后,最终指标在早上7点就能产出,数据分析师下班就能够应用了。
机器学习
随着信息的爆炸倒退,用户的趣味转移的越来越快,这就要求机器学习可能尽快依据用户过后的行为举荐他感兴趣的视频。传统机器学习基于批处理的形式,通常要到最快小时级别能力更新模型。明天基于实时计算的样本训练能够不间断的将样本训练成实时模型并利用于线上,真正做到了在线学习,将依据用户行为产生的举荐做到分钟级别更新。目前,机器学习的作业曾经占到了实时计算集群的50%以上。
实时监控
实时监控也是一个很重要的实时场景,app的开发者须要实时监控app关上的成功率等指标,如果出现异常,就要及时告警告诉进去。之前的做法通常是原始数据寄存于Hive或者ClickHouse,在基于Grafana的监控平台配置规定,每个肯定工夫用Presto或者ClickHouse去查问一下,依据计算出来后果进行判断是否须要告警。这种形式存在几个问题:
1. Presto或者ClickHouse自身尽管是OLAP的引擎,性能很好,但并不保障集群的高可用及实时性。而监控对实时性和高可用要求比拟高。
2. 这种形式的每次计算指标都要把当天的全副数据计算一遍,存在着极大的计算节约。
而通过实时计算的监控计划能够实时计算出来指标,间接输入到Grafana的数据库里,不仅保障了实时性,更是能够将计算的数据量缩小上千倍。
四、BIGO实时平台特色
BIGO实时计算平台在倒退过程中,逐渐依据BIGO外部业务的应用特点,造成了本人的特色和劣势。次要体现在以下几个方面:
元数据买通
一个常见的状况是数据的产生者和使用者不是同一批人。打点的共事将数据上报到kafka或者hive里,数据分析师要用这些数据去计算。他们不晓得kafka的具体信息,只晓得要应用的hive表名。为了缩小用户应用实时计算的麻烦,BigoFlow将元数据和Kafka、hive、ClickHouse等存储都进行了买通,用户能够在作业里间接应用hive、ClickHouse的表,不须要写DDL,BigoFlow主动去解析,依据元数据的信息主动转换成Flink里的DDL语句,极大的缩小了用户的开发工作。这得益于BIGO计算平台的统一规划,是很多离线、实时零碎离开的公司所做不到的。
端到端的产品化计划
BigoFlow不仅仅是实时计算的平台,为了不便用户应用或者迁徙,也会依据业务场景,提供端到端的整个解决方案。像后面介绍的监控场景,用户有很多监控业务须要迁徙,为了尽量减少的工作,BigoFlow专门提供了监控场景的解决方案,用户只须要将计算监控指标的sql迁徙到flink sql,其余包含Flink作业的DDL,数据sink到监控平台等工作齐全不必做,都由BigoFlow主动实现,用户原先配置的规定也都不必变。这使得用户能够用起码的工作量实现迁徙。
另外后面也提到了,BigoFlow主动将用户作业的要害指标增加了告警,这根本满足了绝大多数用户的需要,让他们分心于业务逻辑,而不必操心其余事件。用户的日志也会主动收集到ES里,不便用户查看。ES里有积淀了一些总结进去的考察问题的搜寻query,用户能够依据景象间接点击查问。
弱小的hive能力
因为BIGO内的绝大部分数据都是存在Hive里的,实时作业也常常须要将后果写入hive,不少场景也须要可能从hive里读数据。所以BigoFlow跟hive的集成始终走在业界的前列。在社区1.11之前,BIGO技术就本人实现了向hive写数据,并能够动静更新meta的能力。1.11还未正式公布,咱们就在1.11的根底上,自研开发了流式读取hive表反对EventTime、反对动静过滤分区、反对txt格局压缩等性能,这些性能都当先于开源社区。
这是咱们在ABTest上通过Flink实现的一个批流对立的场景。失常状况下,flink生产kafka的实时数据,实时计算结果存入到hive。但作业常常会遇到业务逻辑调整,须要从新追数据进行对数。因为数据量很大,如果追数据还从kafka生产,就会对kafka带来很大的压力,影响线上的稳固。因为数据在hive里也存了一份,咱们追数据的时候,抉择从hive里读取,这样用同一份代码,能够走离线和在线两条路,最大限度缩小了追数据对在线的影响。
自动化ETL作业生成
Flink目前承接了大部分的ETL场景。ETL作业的逻辑个别比较简单,但作业泛滥,而且用户上报的数据格式会常常变动,或者字段进行了增减。为了缩小用户开发、保护ETL作业的老本,咱们开发ETL作业主动生成的性能,用户只须要提供上报数据的topic和格局,就能够主动生成ETL作业,将后果写入到hive中。上报数据格式或者字段产生了变动之后,也能够主动将作业进行更新。目前反对json、pb等多种数据格式。
五、瞻望
随着BIGO业务的疾速倒退,BigoFlow实时计算平台也在一直的壮大和欠缺,但也还有很多须要改良以及进步的中央,BIGO技术将来将会在平台欠缺和业务反对两个方面重点建设:
平台欠缺:重点晋升平台的产品化程度。次要包含几个方面:开发自动化资源配置、主动调优等性能,能够依据作业的实时数据量,主动配置作业须要的资源,在流量顶峰进行主动扩大,在流量低谷主动缩容;反对表血缘关系展现,不便用户剖析作业之间依赖关系;反对异地多集群,flink下面反对了泛滥要害业务,须要极高的SLA保障,咱们会通过异地多机房来保障要害业务的可靠性。摸索流批对立、数据湖等场景。
反对更多业务场景:开辟更多机器学习、实时数仓的场景,进一步推广Flink SQL的应用。
六、团队简介
BIGO大数据团队专一于在PB级别数据上实现疾速迭代,用大数据分析技术赋能下层业务。具体负责面向公司所有业务建设EB级别的分布式文件存储、日均万亿音讯队列和50PB规模的大数据计算,包含批、流、MPP等多种计算架构,涵盖从数据定义、通道、存储与计算、数据仓库和BI等全链路技术栈。团队技术气氛浓重,有泛滥开源软件的开发者,期待优良的人才退出咱们!
稿件起源来自于BIGO技术自媒体