数仓 调度_作业帮基于Apache Doris的数仓实践

1 背景
作业帮大数据团队主要负责建设公司级数仓，向公司各个重要产品线(拉新、教学、BI等)提供面向业务的数据信息，如到课时长、答题情况等。在过去半年多时间内，我们基于Apache Doris，构建了数仓实时查询系统。本文总结并分享下期间的工作内容，也欢迎大家一起讨论。

典型的数仓从逻辑上划分为下图所示的几个部分。

大数据团队主要负责到ODS-DWS的建设，从DWS到ADS一般是数仓系统和业务线系统的边界。

在过去，由于缺失统一的查询系统，我们探索了很多模式来支持各个业务线发展。

非流量类：

• Kafka 。业务线从Kafka接数据自己做数据的聚合计算。主要问题在于完全没有数仓的概念，业务线在做大量重复的建设。
• Spark + ES。每来一个业务需求，就构建一个Spark+ES集群(spark负责计算写入到ES，ES业务层直接使用)。效率低、构建成本高，且ES高效的使用本身就需要学习ES的接口以及内部原理，对于业务线很难有这样的精力去做。
• ES + 自定义API。大数据将数据写入ES后，case by case构建API。这样做初步建立了数仓的接口，但是由于接口不具备SQL的能力，只能基于需求case by case的构建，效率太低。

流量类：

• 由于数据量大，往往需要预聚合，所以我们引入了Druid。但是Druid只支持聚合数据，无法保留明细数据。导致Druid只能适合流量分析类的场景，对于工作台既需要明细(如查询某个老师的教学数据)也需要聚合(如查询某个部门下所有老师的教学数据)的场景无法满足。

这些“烟囱”式的系统构建方式，导致系统越来越难以维护，且业务接入效率也逐步降低。因此，统一整个查询引擎，对于数仓建设在提高业务支持效率、降低维护成本上都具有非常重大的意义。

2 总体方案

经过数月的探索与实践，我们确立了以Doris为基础的数仓实时查询系统，同时也对整个数仓的数据计算系统做了一次大的重构。最终整体的架构图如下：

<