更多精彩内容，欢迎观看：
带你读《Apache Doris 案例集》——08秒级数据写入，毫秒查询响应 天眼查基于 Apache Doris 构建统一实时数仓（1）：https://developer.aliyun.com/article/1405690
新数仓架构
经过对 Doris 进行综合评估，我们最终决定采用 Doris 对原有架构进行升级优化，并在架构层级进行了压缩。新的架构图如下所示：
在新架构中，数据源层和数据接入层与原有架构保持一致，主要变化是将Doris作为新架构的数据服务层，统一了原有架构中的数据计算层和存储层，这样实现了数据门户的统一，大大缩短了 数据处理链路，解决了开发流程冗长的问题。同时，基于 Doris 的高性能，实现了即席查询能力，提高了数据查询效率。另外，Flink 与 Doris 的结合实现了实时数据快速写入，解决了T+1数据更新延迟较高的问题。除此之外，借助于 Doris 精简的架构，大幅降低了架构维护的难度。
数据流图
缩短数据处理链路直接或间接地带来了许多收益。接下来，我们将具体介绍引入 Doris 后的数据流图。
总体而言，数据源由MySQL 和日志文件组成，数据在 Kafka 中进行分层操作(ODS、DWD、DWS)，Apache Doris 作为数据终点统一进行存储和计算。应用层包含 C端、Tableau 和DMP 系统，通过网关服务从 Doris 中获取相应的数据。
具体来看， MySQL 通过 Canal 把 Binlog 接入 Kafka, 日志文件通过 Flume 接入 Kafka 作为 ODS 层。然后经过 Flink SQL 进行清洗、关联维表，形成 DWD 层的宽表，并生成聚合表。为了节省空间，我们将 ODS层存储在 Kafka 中，DWD 层和 DWS 层主要与 Doris 进行交互。DWD 层的数据一般通过 Flink SQL 写入 Doris。 针对不同的场景，我们应用了不同的数据模型进行数据导入。MySQL 数据使用Unique 模型，日志数据使用 Duplicate 模型， DWS 层采用Aggregate 模型，可进行实时聚合，从而减少开发成本。
应用场景优化
在应用新的架构之后，我们必须对业务场景的数据处理流程进行优化以匹配新架构，从而达到最佳应用效果。接下来我们以人群圈选、C 端分析数据及精准营销线索为主要场景，分享相关场景流程优化的实践与经验。
人群圈选
原流程(左)中，业务人员在画像平台页面上利用表的元数据创建人群圈选任务，任务创建后进行人群 ID 分配，写入到 PG 画像表和 MySQL 任务表中。接着根据任务条件定时在ES 中查询结果，获取结果后更新任务表的状态，并把Bitmap 人群包写入 PG。利用 PG 插件提供的Bitmap 交并差能力操作人群包，最后下游运营介质从PG 取相应人群包。
然而，该流程处理方式非常复杂， ES 和 PG 中的表无法复用，造成成本高、效益低。同时，原流程中的数据为 T+1 更新，标签必须提前进行定义及计算，这非常影响查询效率。
现流程(右)中，业务人员在画像平台创建人群圈选任务，后台分配人群 ID,并将其写入MySQL 任务表中。首次圈选时，根据任务条件在 Doris 中进行即席查询，获取结果后对任务表状态进行更新，并将人群包写入 Doris。后续根据时间进行微批轮询，利用 Doris Bitmap 函数提供的交并差功能与上一次的人群包做差集，如果有人群包更新会主动通知下游。
引入 Doris 后，原有流程的问题得到了解决，新流程以 Doris 为核心构建了人群圈选服务，支持 人群包实时更新，新标签无需提前定义，可通过条件配置自助生成，减少了开发时间。新流程表 达方式更加灵活，为人群包 AB 实验提供了便捷的条件。流程中采用 Doris 统一了明细数据和人 群包的存储介质，实现业务聚，无需处理多组件数据之间的读写问题，达到了降本增效的终极目标。
C端分析数据及精准营销线索场景
原流程：在原流程中，如果业务提出新需求，需要先发起需求变更，再经过评审、排期开发，然后开始对 Hive 中的数据模型进行开发并进行测试，测试完成后进行数仓上线，配置T+1 调度任务写入 MySQL, 最后C端和精准营销系统对MySQL 数据进行读取。原流程链路复杂，主要体现在流程长、成本高、上线周期长。
现流程： 当前明细数据已经在Doris 上线，当业务方发起需求变更时，只需要拉取元数据管理平台元数据信息，配置查询条件，审批完成后即可上线，上线 SQL 可直接在Doris 中进行即席查询。相比原流程，现在的流程大幅缩短了需求变更流程，只需进行低代码配置，成功降低了开发成本，缩短了上线周期。
优化经验
为了规避风险，许多公司的人群包user id 是随机生成的，这些user id 相差很大且是非连续的。然而，使用非连续的user_id 进行人群圈选时，会导致 Bitmap 生成速度较慢。因此，我们生成了映射表，并生成了连续稠密的user id 。当使用连续user_id 圈选人群时，速度较之前提升了70%。
用户 ID 映射表样例数据：从图可知原始用户 ID 由多位数字组合，并且ID 很稀疏(用户 ID 间相差很大),而连续用户ID 则从1开始，且ID很稠密。
案例展示：
1、用户ID映射表：
用户 ID 映射表将用户ID作为唯一键模型，而连续用户ID则通过用户 ID来生成，一般从1开始，严格保持单调递增。需要注意的是，因为该表使用频繁，因此将in memory设置为true直接将其缓存在内存中： 
2、人群包表
人群包表是以用户标签作聚合键的模型，假设以 user_id 大于0、小于2000000 作为圈选条件，使用原始user_id 进行圈选耗费的时间远远大于连续稠密 user_id 圈选所耗时间。 
如下图所示，左侧使用tyc user id 圈选生成人群包响应时间：1843ms,右侧使用使tyc user id continuous 圈选生成人群包响应时间：543ms, 消耗时间大幅缩短。
规模与收益
引入 Doris 后，我们已经搭建了2个集群，承载的数据规模正随着迁移的推进而持续增大。目前，我们已经处理的数据总量已经达到了数十TB,单日新增数据量已经达到了数十亿条， 而数据体量还在持续增长中。此外，我们在 Doris 上运行的指标和人群包数量已经超过了500,分别涵盖了商查、搜索、运营、用户和营收五大类指标。
Doris的引入满足了业务上的新需求，解决了原有架构的痛点问题，具体表现为以下几点：
●降本增效：Doris统一了数据的门户，实现了存储和计算的统一，提高了数据/表的复用率，降低了资源消耗。同时，新架构优化了数据到 MySQL、ES 的流程，开发效率得到有效提
升。
●导入速率提升：原有数据流程中，数据处理流程过长，数据的导入速度随着业务体量的增长和数据量的不断上升而急剧下降。引入Doris后，我们依赖 Broker Load 优秀的写入能力，使得导入速率提升了75%以上，
●响应速度：Doris的使用提高了各业务场景中的查询响应速度。例如，在人群圈选场景中，对于500万及以下的人群包进行圈选时，能够做到毫秒级响应。
未来规划
正如前文所讲，Apache Doris 的引入解决了许多架构及业务上的难题，初见成效，同时也收获 了公司内部数据部门、业务方的一致好评，未来我们将继续探索，基于Doris 展开更深度的应用，不久的将来，我们将重点推进以下几个方面工作：
●离线指标实时化：将更多的指标从离线转为实时，提供更及时的数据服务。
●搭建数据血缘系统：将代码中的血缘关系重新定义为可视，全面构建数据血缘关系，为问题 排查、链路报警等提供有效支持。
●探索批流一体路线：从使用者的角度思考设计，实现语义开发层的统一，使数据开发更便捷、更低门槛、更高效率。
在此特别感谢SelectDB 团队，作为一家基于Apache Doris 的商业化公司，为社区投入了大量的研发和用户支持力量，在使用过程中遇到任何问题都能及时响应，为我们降低了许多试错成本。未来，我们也会更积极参与社区贡献及活动中来，与社区共同进步和成长，欢迎大家选择和使用Doris, 相信Doris一定不会让你失望。
