BIGO基于DS打造离线服务平台

1 . 2021 BIGO基于DS打造离 线服务平台 讲师：徐帅 BIGO计算平台 

2 .目录 CONTENTS 01 建设背景 02 提升用户体验 03 内核改造 04 未来计划 

3 . 01 BIGO简介 建设背景 计算平台现状 为什么选择DolphinScheduler 

4 .认识BIGO 成立于2014年，为全球用户提供音视频服务 产品覆盖全球150个国家和地区，4亿月活用户 

5 .BIGO计算平台现状 支持离线、olap、实时等多种场景 离线集群2000台，每天7W+作业，上千个用户 目前使用了Oozie、Airflow、Crontab等多种调度方式 作业以Spark为主，覆盖了Hive，Python，MR，Shell，Sqoop等 

6 .为什么选择DolphinScheduler 目标： 搭建离线服务平台，作为用户的统一入口 要求： 扩展性、易用性、完善的API、社区活跃 综合对比： Oozie、Airflow、DolphinScheduler、Livy、DataSphereStudio、DataWorks 

7 . 02 用户管理 提升用户体验 项目管理 工作流 

8 .提升用户体验 用户管理 • 打通OA，免去注册 • 屏蔽租户概念 

9 .提升用户体验 项目管理 • 允许不同人项目和资源重名 • 个人有分享权限 

10 .提升用户体验 工作流管理 • 工作流页面完成开发、上线、查看一站式操作 

11 .提升用户体验 工作流管理 • 工作流历史聚合 • 用户可直达APP 

12 .提升用户体验 各种任务开发 • 支持多种资源方式 • 支持sub process个性化参数 • 等等 

13 .03 任务提交去中心化 内核改造 Worker支持Failover 工作流并发度限制 补数支持触发下游 

14 .任务提交去中心化 DS是worker fork进程提交作业 • Worker做client，限制了worker同时运行任务的上限 • SQL依赖hive server/ spark thrift server等，稳定性和规模性都比较差 分布式任务提交 • Spark/Spark SQL/MR直接提交为Yarn的任务 • Shell/Sqoop等运行在自己开发的一个APP中 

15 .Worker支持Failover DS worker重启后，作业要杀掉重新提交 • 作业可长达十几小时 • 限制了worker同时运行任务的上限 • 升级重启可能会比较频繁 在任务提交优化基础上，对任务管理进行了优化 • Worker提交任务到Yarn之后，记录application信息 • Worker后台异步追踪application运行信息 • 一个worker失联后，其他worker接管原先的application，继续追踪 

16 .工作流并发度限制 工作流常见的运行场景 • 部分工作流要求同时只能有一个在运行 • 部分工作流可以并发运行，但需要设置并发上限 • 补数时，可能需要补比较长区间，需要限制上限，以免对集群造成冲击 增加了并发度配置 • 如果当前运行的工作流实例已达上限，需要等待前面的运行结束才能启动新的实例 

17 .补数支持触发下游 补数时，可能下游数据也需要重算 • DS目前上游不知道下游 记录工作流之间依赖关系 • 补数时，上游可选是否触发下游 • 自动计算下游需要什么时候触发 

18 .其他改动 日志清理 磁盘目录清理 接入电话、微信告警 

19 .04 Oozie迁移 未来计划 依赖关系 升级DS 2.0 回馈社区 

20 .所有调度任务迁移到DS Oozie • 几千个调度 • 自动迁移工具 Airflow • 数量少，但难度大 Crontab • 数量多，难度大 

21 .依赖关系 依赖关系展示 补数时可选范围 

22 .升级DS 2.0版并回馈社区 利用2.0版master端的性能优化 将普适的改动推回社区，减少私有代码，尽量跟紧社区 

23 . THANKS！ Ending