Apache Doris 在拈花云科的统一数据中台实践，One Size Fits All

作者｜NearFar X Lab 团队 洪守伟、陈超、周志银、左益、武超

整理｜SelectDB 内容团队

导读： 无锡拈花云科技服务有限公司（以下简称拈花云科）是由中国创意文旅集成商拈花湾文旅和北京滴普科技有限公司共同孵化组建的。拈花云科以数字化思维为导向，致力于成为文旅目的地数智化服务商。2022 年底，拈花云科 NearFar X Lab 团队在数据需求的驱动下，开始调研并引进 Apache Doris 作为新架构下的数据仓库选型方案。本文主要介绍了拈花云科数据中台架构从 1.0 到 2.0 的演变过程，以及 Apache Doris 在交付型项目和 SaaS 产品中的应用实践，希望本文分享的内容能对大家有所启发。

业务背景

拈花云科的服务对象主要是国内各个景区、景点，业务范围涵盖文旅行业的多个板块，如票务、交通、零售、住宿、餐饮、演绎、游乐、影院、KTV、租赁、服务、会务、康乐、康养、电商、客服、营销、分销、安防等。多业务线条下用户对于数据使用的时效性需求差异较大，需要我们能够提供实时、准实时、T+1 的业务支撑能力。同时根据大部分景区为国有化的特点，我们也需要具备能够提供私有化交付部署及 SaaS 化数据中台产品解决方案的双重服务支撑能力。

数据中台 1.0 - Lambda

早期构建数据中台时，为了优先满足 B 端用户数据整合的需求，以稳定数据输出为出发点，因此我们基于行业中比较成熟的 Lambda 架构形成了数据中台 1.0 。

在数据中台 1.0 架构中分为三层，分别为 Batch Layer，Speed Layer 和 Serving Layer。其中，Batch Layer 用于批量处理全部的数据，Speed Layer 用于处理增量的数据，在 Serving Layer 中综合 Batch Layer 生成的 Batch Views 和 Speed Layer 生成的 Realtime Views，提供给用户查询最终的结果。

Batch Layer： 在我们早期的实施类项目中，单纯以离线 T+1 进行数据支持的项目占了绝大多数。但实施类项目在实现 Lambda 架构的过程中也会面临很多问题。比如数据采集环节，由于项目本身原因业务系统不能开放 DB 的 Binlog 供数据仓库采集，因此只能以 JDBC 的方式完成增量或全量的数据同步，而通过该方式同步的数据往往会由于系统人工补充数据、时间戳不规范等问题产生同步数据差异的情况发生，最终只能通过额外的数据对比逻辑进行校验，以保证其数据的一致性。

Speed Layer： 项目受成本约束较大，大面积基于流的实时计算对于不论是从硬件成本、部署成本还是实施成本、维护成本等角度均难以支撑。基于该原因，在实施类项目中只有部分业务会进行基于流的实时统计计算，同时满足流计算条件的业务上游系统也必须同时满足同步 Binlog 的使用需求。

Serving Layer： 大部分的预计算结果存储在 MySQL 中提供 Report 支持，部分实时场景通过 Merge Query 对外提供 Ad-Hoc 的查询支持。

随着时间的推移，大量的项目交付使用增多，架构的问题也逐渐开始显现：

• 开发和维护成本高：该架构需要维护两套代码，即批处理和实时处理的代码，这无疑增加了开发和维护的成本。
• 数据处理复杂度高：Lambda 架构需要处理多个层次的数据，包括原始数据、批处理数据和实时处理数据，需要对不同的数据进行清洗、转换和合并，数据处理的复杂度较高。
• 实时计算支持有限：业务方对于数据时效性要求越来越高，但是该架构能力有限，无法支持更多、更高要求的的实时计算。
• 资源利用率低：离线资源较多，但我们仅在凌晨后的调度时间范围内使用，资源利用率不高。
• 受成本制约：该架构对于我们部分用户而言使用成本较高，难以起到降低成本提高效率的作用。

新架构的设计目标

基于以上架构问题，我们希望实现一套更加灵活的架构方案，同时希望新的架构可以满足日益增高的数据时效性要求。在新方案实现之前，我们必须先对当前的业务应用场景和项目类型进行分析。

我们业务应用场景分为以下四类，这四类场景的特点和需求分别是：

• 看板类：包括 Web/移动端数据看板和大屏可视化，用于展示景区重要场所的数据，如业务播报（实时在园人数监控、车船调度管理等）、应急管理监控（客流密度监控、景区消防预警、景区能耗监控等）。其组成特点一般为业务汇总指标和监控指标报警，对数据时效性要求较高。
• 报表类：数据报表以图表形式展示，主要服务于各业务部门的一线业务人员。会更多关注垂直业务的数据覆盖程度，会有钻取需求（也可能通过不同报表来体现不同数据粒度）。一般以景区的业务部门为单位构建报表栏目和分析主题，除财务结算类报表外，一般可接受 T+1 的报表时效。
• 分析类：自助分析基于较好的数据模型表（数据宽表）实现，对分析人员有一定的数据理解和操作需求，基于我们提供的 BI 分析平台，业务人员可基于此数据范围通过拖拽的方式组合出自己的数据结果，灵活度较高。该场景对数据时效要求不高，更多关注业务数据沉淀和与往期历史数据的对比分析侧重架构的 OLAP 能力。
• 服务类：一般对接三方系统，由数据中台提供数据计算结果。如画像标签等数据，通过数据接口控制权限提供对外数据服务与其它业务系统集成，需要新架构能够提供稳定的数据服务。

接着我们对项目类型的特点和需求也进行了分析，并确定新架构需要同时提供实施类项目和 SaaS 产品的数据中台支撑能力：

数据中台 2.0 - Apache Doris

结合以上需求，我们计划对原有架构进行升级，并对新架构的 OLAP 引擎进行选型。在对比了 ClickHouse 等 OLAP 引擎后（社区有非常多的对比文章参考，这里不过多赘述），最终选择了 Apache Doris 作为数据中台 2.0 的基座。同时，在数据的同步、集成及计算环节，我们也构建了多套方案来适配以 Apache Doris 为核心的计算链路，以应对不同类型的实施类项目及 SaaS 产品需求。

数据中台 2.0 的核心思路是将 Apache Doris 作为核心的数据仓库，并将其作为实时数据同步中心、核心数据计算中心。数据集成环节将专注于数据同步，而计算交由 Apache Doris 完成或由 Doris 辅助计算引擎完成。同时，我们将在提供多种数据同步至 Apache Doris 的方案以应对不同的项目需求。在这个架构下，我们支持实现实时、准实时、T+1 的计算场景支持，以满足不同业务场景的需求。

新架构数据流转：

1. 数据同步集成：架构 2.0 有多种数据同步方式，我们主要借助 Doris Unique Key 模型完成数据的同步更新。

2. 数仓分层计算：根据项目资源情况分 View/实体表单来构建后面的数据层级（DWD、DWS、ADS）。业务较轻或时效性很高时，通过 View 方式来实现逻辑层面的 DWD，通过这种方式为下游 Ad-hoc 提供宽表查询支持，Doris的谓词下推及 View 优化的能力为使用视图查询带来了便利。而当业务较重时，通过实体表单 + 微批任务进行实现，按照调度依赖关系逐层完成计算，针对使用场景对表单进行优化。

3. 数据计算时效：新架构下的数据时效受具体数据计算链路中的三个方面限制，分别是数据采集时效、批次计算时效、数据查询耗时。在不考虑网络吞吐、消息积压、资源抢占的情况下：

（实施类项目经常会遇到第三方不提供 Binlog 的情况，所以这里把通过批次采集数据也作为一个 case 列出来）

在 Doris 中为了达到