共计 4231 个字符，预计需要花费 11 分钟才能阅读完成。
一、业务背景
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 技术自媒体
