乐趣区

关于javascript:流批一体生产应用Bigo-实时计算平台建设实践

jiezi

简介：本文由 Bigo 计算平台负责人徐帅分享，次要介绍 Bigo 实时计算平台建设实际的介绍

本文由 Bigo 计算平台负责人徐帅分享，次要介绍 Bigo 实时计算平台建设实际的介绍。内容包含：

  1. Bigo 实时计算平台的倒退历程
  2. 特色与改良
  3. 业务场景
  4. 效率晋升
  5. 总结瞻望

一、Bigo 实时计算平台的倒退历程

明天次要跟大家分享 Bigo 实时计算平台的建设历程，咱们在建设过程中解决的一些问题，以及所做的一些优化和改良。首先进入第一个局部，Bigo 实时计算平台的倒退历程。

先简略介绍一下 Bigo 的业务。它次要有三大 APP，别离是 Live，Likee 和 Imo。其中，Live 为寰球用户提供直播服务。Likee 是短视频的创作与分享的 App，跟快手和抖音都十分类似。Imo 是一个寰球收费的通信工具。这几个次要的产品都是跟用户相干的，所以咱们的业务要围绕着如何进步用户的转化率和留存率。而实时计算平台作为根底的平台，次要是为以上业务服务的，Bigo 平台的建设也要围绕上述业务场景做一些端到端的解决方案。

Bigo 实时计算的倒退历程大略分为三个阶段。

  • 在 2018 年之前，实时作业还非常少，咱们应用 Spark Streaming 来做一些实时的业务场景。
  • 从 18 年到 19 年，随着 Flink 的衰亡，大家普遍认为 Flink 是最好的实时计算引擎，咱们开始应用 Flink，离散倒退。各个业务线本人搭一个 Flink 来简略应用。
  • 从 2019 年开始，咱们把所有应用 Flink 的业务对立到 Bigo 实时计算平台上。通过两年的建设，目前所有实时计算的场景都运行在 Bigo 平台上。

如下图所示，这是 Bigo 实时计算平台的现状。在 Data Source 端，咱们的数据都是用户的行为日志，次要来自于 APP 和客户端。还有一部分用户的信息存在 MySQL 中。

这些信息都会通过音讯队列，最终采集到咱们的平台里。音讯队列次要用的是 Kafka，当初也在逐步的采纳 Pulsar。而 MySQL 的日志次要是通过 BDP 进入实时计算平台。在实时计算平台这块，底层也是基于比拟罕用的 Hadoop 生态圈来做动静资源的治理。在下面的引擎层，曾经对立到 Flink，咱们在下面做一些本人的开发与优化。在这种一站式的开发、运维与监控的平台上，咱们外部做了一个 BigoFlow 的治理平台。用户能够在 BigoFlow 上开发、调试和监控。最终在数据存储上，咱们也是对接了 Hive、ClickHouse、HBase 等等。

二、Bigo 实时计算平台的特色与改良

接下来咱们看一下 Bigo 计算平台的特色，以及咱们做的改良。作为一个倒退中的公司，咱们平台建设的重点还是尽可能的让业务人员易于应用。从而促成业务的倒退，扩充规模。咱们心愿建设一个一站式的开发、运维、监控平台。

首先，在 BigoFlow 下面，用户能够十分不便的开发。咱们在开发这一块的特色与改良包含：

  1. 功能强大的 SQL 编辑器。
  2. 图形化拓扑调整、配置。
  3. 一键多集群部署。
  4. 版本对立治理，尽可能收敛。

另外，在运维这一块，咱们也做了许多改良：

  1. 欠缺的 savepoint 管理机制。
  2. 日志主动收集到 ES，内置常 用谬误排查规定。
  3. 保留了工作历史，不便进行比照和问题追踪。

最初是监控这一块，咱们的特色有：

  1. 监控主动增加，用户根本无需手动配置。
  2. 自动化剖析资源应用，为用户举荐正当资源配置。

咱们元数据的存储次要有三个中央。别离是 Kafka、Hive 和 ClickHouse。目前咱们可能把所有的存储系统的元数据全面买通。这会极大的不便用户，同时升高应用老本。

  • Kafka 的元数据买通之后，就能够一次导入，有限应用，无需 DDL。
  • Flink 与 Hive 也做到了齐全买通，用户在应用 Hive 表的时候，无需 DDL，间接应用即可。
  • ClickHouse 也相似，可主动追踪到 Kafka 的 topic。

其实，咱们明天提供的不仅仅是一个平台，还包含在通用场景提供了端到端的解决方案。在 ETL 场景，咱们的解决方案包含：

  1. 通用打点齐全自动化接入。
  2. 用户无需开发任何代码。
  3. 数据进入 hive。
  4. 自动更新 meta。

在监控这一块，咱们的特色有：

  1. 数据源主动切换。
  2. 监控规定不变。
  3. 后果主动存入 prometheus。

第三个场景是 ABTest 场景，传统的 ABTest 都是通过离线的形式，隔一天之后能力产出后果。那么咱们明天将 ABTest 转为实时的形式去输入，通过流批一体的形式大大提高了 ABTest 的效率。

对 Flink 的改良次要体现在这几个方面：

  • 第一，在 connector 层面，咱们自定义了很多的 connector，对接了公司用到的所有零碎。
  • 第二，在数据格式化层面，咱们对 Json，Protobuf，Baina 三种格局做了十分残缺的反对。用户无需本人做解析，间接应用就能够。
  • 第三，公司所有的数据都间接落到 Hive 外面，在 Hive 的应用上是当先于社区的。包含流式的读取，EventTime 反对，维表分区过滤，Parquet 简单类型反对，等等。
  • 第四，在 State 层面咱们也做了一些优化。包含 SSD 反对，以及 RocksDB 优化。

三、Bigo 典型的业务场景

传统的打点入库，都是通过 Kafka 到 Flume，而后进入到 Hive，最初到 ClickHouse。当然 ClickHouse 外面大部分是从 Hive 导进去的，还有一部分是通过 Kafka 间接写进去的。

这个链路是一个十分老的链路，它存在以下问题：

  • 第一，不稳固，flume 一旦有异样，常常会呈现数据失落和反复。
  • 第二，扩大能力差。面对忽然到来的流量顶峰，很难去扩大。
  • 第三，业务逻辑不易调整。

所以咱们在建设 Flink 之后，做了十分多的工作。把原先 Flume 到 Hive 的流程替换掉，明天所有的 ETL 都是通过 Kafka，再通过 Flink，所有的打点都会进入到 Hive 离线数仓，作为历史的保留，使数据不失落。同时，因为很多作业须要实时的剖析，咱们在另外一个链路，从 Flink 间接进入 ClickHouse 实时数仓来剖析。

在这个过程中，咱们做了一些外围革新，分为三大块。首先，在用户接入这一块，咱们的革新包含：

  1. 尽可能简略。
  2. 通用打点全自动。
  3. 元信息买通，无需 DDL。

另外，在 Flink 本身这一块，咱们的革新有：

  1. Parquet 写优化。
  2. 并发度调整。
  3. 通过 SSD 盘，反对大状态的作业。
  4. RocksDB 优化，更好管制内存。

最初，在数据 Sink 这一块，咱们做了十分多的定制化的开发，不仅反对 Hive，也对接了 ClickHouse。

四、Flink 为业务带来的效率晋升

上面次要介绍 ABTest 场景下，咱们做的一些革新。比如说，数据全副落到 Hive 之后，就开始启动离线的计算，可能通过无数个工作流之后，最终产出了一张大宽表。表上可能有很多个维度，记录了分组试验的后果。数据分析师拿到后果之后，去剖析哪些试验比拟好。

尽管这个构造很简略，然而流程太长，出后果晚，并且不易减少维度。次要问题其实在 Spark 这块，这个作业有无数个工作流去执行，一个工作流要等到另外一个执行完能力去调度。而且离线资源没有十分好的保障。咱们之前最大的问题是 ABTest 上一天的后果要等到下一天的下午能力输入，数据分析师常常反馈上午没法干活，只能下午快下班的时候能力开始剖析。

所以咱们就开始利用 Flink 实时计算能力去解决时效性的问题。不同于 Spark 工作要等上一个后果能力输入，Flink 间接从 Kafka 生产。基本上能够在上午出后果。然而过后因为它最终产出的后果维度十分多，可能有几百个维度，这个时候 State 就十分大，常常会遇到 OOM。

因而咱们在第一步的革新过程中取了一个折中，没有间接利用 Flink 在一个作业外面把所有的维度 join 起来，而是把它拆分成了几个作业。每个作业计算一部分维度，而后把这些后果先利用 HBase 做了一个 join，再把 join 的后果导入到 ClickHouse 外面。

在革新的过程中，咱们发现了一个问题。可能作业须要常常的调整逻辑，调完后要去看后果对不对，那么这须要 1 天的工夫窗口。如果间接读历史数据，Kafka 就要保留很久的数据，读历史数据的时候，要到磁盘下来读，对 Kafka 的压力就十分大。如果不读历史数据，因为只有零点能力触发，那么明天改了逻辑，要等到一天之后才可能去看后果，会导致调试迭代十分慢。

后面提到咱们的所有数据在 Hive 外面，过后还是 1.9 的版本，咱们就反对了从 Hive 外面流式的去读取数据。因为这些数据都是用 EventTime 去触发，咱们在 Hive 上反对了用 EventTime 去触发。为了流批对立，这里没有用 Spark，因为如果用 Spark 去做作业验证，须要保护两套逻辑。

咱们在 Flink 下面用流批一体的形式去做离线的补数据，或者离线的作业验证。而实时的这条用于日常作业的产生。

方才说了这其实是一个折中的计划，因为对 HBase 有依赖，也没有充分发挥 Flink 的能力。所以咱们进行了第二轮的革新，彻底去除对 HBase 的依赖。

通过第二轮迭代之后，咱们明天在 Flink 上曾经可能扛住大表的天级别的窗口交易。这个流批对立的计划曾经上线了，咱们间接通过 Flink 去计算残缺个大宽表，在每天的窗口触发之后，将后果间接写到 ClickHouse 外面，基本上凌晨就能够产出后果。

在整个过程两头，咱们对 Flink 的优化包含：

  1. State 反对 SSD 盘。
  2. 流式读取 Hive，反对 EventTime。
  3. Hive 维表 join，反对 partition 分区 load。
  4. 欠缺的 ClickHouse Sinker。

优化之后，咱们的小时级任务再也不提早了，天级别实现工夫由下午提早到下班前，大大减速了迭代效率。

五、总结与瞻望

总结一下实时计算在 Bigo 的现状。首先，十分贴近业务。其次，跟公司里用到的所有生态无缝对接，基本上让用户不须要做任何的开发。另外，实时数仓已现雏形。最初，咱们的场景跟大厂相比还不够丰盛。一些比拟典型的实时场景，因为业务需要没有那么高，很多业务还没有真正的切换到实时场景上来。

咱们的倒退布局有两大块。

  • 第一块是拓展更多的业务场景。包含实时机器学习，广告，风控和实时报表。在这些畛域，要更多的去推广实时计算的概念，去跟业务对接好。
  • 另外一块就是在 Flink 本身下面，咱们外部有很多场景要做。比如说，反对大 Hive 维表 join，自动化资源配置，CGroup 隔离，等等。以上就是咱们在将来要做的一些工作。

作者：徐帅
原文链接
本文为阿里云原创内容，未经容许不得转载

退出移动版