作业帮基于 DeltaLake 的数据湖建设实践

内容框架：
业务背景
问题&痛点
解决方案
基于 DeltaLake 的离线数仓
未来规划
致谢

一、业务背景

作业帮是一家以科技为载体的在线教育公司。目前旗下拥有工具类产品作业帮、作业帮口算，K12直播课产品作业帮直播课，素质教育产品小鹿编程、小鹿写字、小鹿美术等，以及喵喵机等智能学习硬件。作业帮教研中台、教学中台、辅导运营中台、大数据中台等数个业务系统，持续赋能更多素质教育产品，不断为用户带来更好的学习和使用体验。其中大数据中台作为基础系统中台，主要负责建设公司级数仓，向各个产品线提供面向业务主题的数据信息，如留存率、到课率、活跃人数等，提高运营决策效率和质量。

上图为作业帮数据中台总览。主要分为三层：

• 第一层是数据产品以及赋能层

主要是基于主题数据域构建的数据工具以及产品，支撑商业智能、趋势分析等应用场景。

• 第二层是全域数据层

通过OneModel统一建模，我们对接入的数据进行了标准化建模，针对不同时效性的场景构建了业务域的主题数据，提高上层产品的使用效率和质量。

• 第三层是数据开发层

构建了一系列的系统和平台来支持公司内所有的数据开发工程，包括数据集成、任务开发、数据质量、数据服务、数据治理等。

本次分享的内容主要是面向离线数仓（天级、小时级）解决其生产、使用过程中的性能问题。

二、问题&痛点

作业帮离线数仓基于 Hive 提供从 ODS 层到 ADS 层的数据构建能力，当 ADS 表生成后，会通过数据集成写入 OLAP 系统面向管理人员提供 BI 服务；此外，DWD、DWS、ADS 表，也会面向分析师提供线下的数据探查以及取数服务。

随着业务逐步发展以及对应的数据量越来越多，离线数仓系统突显如下主要问题：

• ADS 表产出延迟越来越长

由于数据量增多，从 ODS 层到 ADS 层的全链路构建时间越来越长。虽然对于非常核心的 ADS 表链路可以通过倾斜资源的模式来短期解决，但是其实这个本质上就是丢车保帅的模式，该模式无法规模化复制，影响了其他重要的 ADS 表的及时产出，如对于分析师来说，由于数据表的延迟，对于T+1的表最差需等到T+2才可以看到。

• 小时级表需求难以承接

有些场景是小时级产出的表，如部分活动需要小时级反馈来及时调整运营策略。对于这类场景，随着数据量增多、计算集群的资源紧张，小时级表很多时候难以保障及时性，而为了提高计算性能，往往需要提前预备足够的资源来做，尤其是需要小时级计算天级数据的时候，最差情况下计算资源需要扩大24倍。

• 数据探查慢、取数稳定性差

数据产出后很多时候是面向分析师使用的，直接访问 Hive 则需要几十分钟甚至小时级，完全不能接受，经常会收到用户的吐槽反馈，而采用 Presto 来加速 Hive 表的查询，由于 Presto 的架构特点，导致查询的数据表不能太大、逻辑不能太复杂，否则会导致 Presto 内存 OOM，且 Hive 已有的 UD