由百度自研，2017年开源，2018年贡献给Apache社区后更名为 Apache Doris 系统定位 • 百度内部统称其为“百度数据仓库Palo”，同时百度云上提供Palo的企业级托管版本 发展历程 01 02 03 • 1.0版本正式上线 • 应用于百度凤巢统计报表的 需求场景，上线后数据更新 频率从天级提升至分钟级 2008 • 进行了通用化改造，开始承 接公司内部其他报表系统 • 助力百度统计成为国内最大 数据完整性问题 原始数据 导入结果 已生效 Vn 已生效 V1-Vn-1 未生效 数据 已生效 V1-Vn-1 02 导入的问题 Vn • 读取到未生效数据 • 生效的数据未被读取到 读写冲突问题 原始数据 查询导入结果 源 操作1 操作2 处理 失败 失败 源 操作1 操作2 重试成功 额外重试 处理两次 02 导入的问题 At-Most-Once & At-Least-Once 中的导入 Prepared 事务和两阶段提交 • FE 充当协调者 • Prepare 阶段下发任务和写入数据 • Submit阶段 • 数据状态改为COMMITED • publish 版本 • 状态改为 VISIBLE Request-to-prepare Commit/Abort Done Coordinator Participant Prepare Phase Commit

语句是非常有难度的。如果你有相关的经验，期待有机会可以一起探索交流。 优化经验 从上文已知，为更好地实现业务需求，数据架构演进到 4.0 版本，其中 Apache Doris 作为 分析加速场景的解决方案在整个系统中发挥着重要的作用。接下来将从场景需求、数据导入、 查询优化以及成本优化四个方面出发，分享基于 Doris 的读写优化经验，希望给读者带来 一些参考。 场景需求 6 目前我们有 800+ 标签， 1300+ 也只需保存最新待导入的数据。同时该方案整体实时性更好且可控，并且大宽表聚合在 Flink 中执行，可灵活加入各种 ETL 逻辑，离线和实时可对多个开发逻辑进行复用，灵活度较高。 数据模型选择 目前我们生产环境所使用的版本为 Apache Doris 1.1.3，我们对其所支持的 Unique 主键模 型、Aggregate 聚合模型和 Duplicate 明细模型进行了对比 ，相较于 Unique 模型和 Duplicate  Unique 模型适用于需要保证 Key 唯一性场景，同一个主键 ID 多次导入之后，会 以 append 的方式进行行级数据更新，仅保留最后一次导入的数据。在与社区进行 沟通后，确定后续版本 Unique 模型也将支持部分列更新。  Duplicate 模型区别于 Aggregate 和 Unique 模型，数据完全按照导入的明细数据 进行存储，不会有任何预聚合或去重操作，即使两行数据完全相同也都会保留，因

可以为表指定别名。最 终恢复的表会采用这个别名。分区名称不能修改。如果不指定分区，则默认恢复该表的所有分区。所指定的表和分区必须已 存在于仓库备份中。 ：指定恢复操作相关属性 ：指定恢复对应备份快照的哪个时间版本，必填。该信息可以通过 SHOW SNAPSHOT 命令获取。 ：指定恢复的表或分区的副本数。默认为3。若恢复已存在的表或分区，则副本数必须和已存在表或 分区的副本数相同。同时，Compute Node ：任务超时时间，默认为一天。单位秒。 Example Example 1. 从 example_repo 中恢复备份 snapshot_1 中的表 backup_tbl 到数据库 example_db1，时间版本为 "2020-05-04-16-45- 08"。恢复为 1 个副本： kafka_partitions kafka_partitions kafka_partitions kafka_partitions example_repo 中恢复备份 snapshot_2 中的表 backup_tbl 的分区 p1,p2，以及表 backup_tbl2 到数据库 example_db1， 并重命名为 new_tbl，时间版本为 "2020-05-04-17-11-01"。默认恢复为 3 个副本： Keywords Keywords 最佳实践 最佳实践 1. 同一数据库下只能有一个正在执行的恢复操作。 2. 可以

短板。因此，高频的大规模汇 总统计，并发能力将面临较大挑战，这取决于集群硬件方面的并行计算能力。传统去重算法需要 大量计算资源，实时的大规模去重指标对CPU、内存都是一个巨大挑战。目前Doris最新版本已经 支持Bitmap算法，配合预计算可以很好地解决去重应用场景。 3 / 8 Apache Doris在美团外卖数仓中的应用实践 Join 谓词下推的传递性优化 如上图所示，对于下面的 SQL： select * from t1 join t2 on t1.id = t2.id where t1.id = 1 Doris开源版本默认会对t2表进行全表Scan，这样会导致上面的查询超时，进而导致外卖业务在D oris上的第一批应用无法上线。 于是我们在Doris中实现了第一个优化：Join谓词下推的传递性优化（MySQL和TiDB中称之为Cons