除此之外，ClickHouse 由国外开源，交流具有一定的语言学习成本，遇到问题无法准确反 馈、无法快速获得解决，与社区沟通上的阻塞也是促进我们进行架构升级的因素之一。 数据架构 2.0 3 基于架构 1.0 存在的问题和 ClickHouse 的局限性，我们尝试对架构进行优化升级，将分析 引擎 ClickHouse 切换为 Doris，Doris 具有以下的优势： Apache Doris 的优势： ，因此如何在查询计算时自动生成一个准确有 效的 SQL 语句是非常有难度的。如果你有相关的经验，期待有机会可以一起探索交流。 优化经验 从上文已知，为更好地实现业务需求，数据架构演进到 4.0 版本，其中 Apache Doris 作为 分析加速场景的解决方案在整个系统中发挥着重要的作用。接下来将从场景需求、数据导入、 查询优化以及成本优化四个方面出发，分享基于 Doris 的读写优化经验，希望给读者带来 也只需保存最新待导入的数据。同时该方案整体实时性更好且可控，并且大宽表聚合在 Flink 中执行，可灵活加入各种 ETL 逻辑，离线和实时可对多个开发逻辑进行复用，灵活度较高。 数据模型选择 目前我们生产环境所使用的版本为 Apache Doris 1.1.3，我们对其所支持的 Unique 主键模 型、Aggregate 聚合模型和 Duplicate 明细模型进行了对比 ，相较于 Unique 模型和 Duplicate

lo的企业级托管版本 发展历程 01 02 03 • 1.0版本正式上线 • 应用于百度凤巢统计报表的 需求场景，上线后数据更新 频率从天级提升至分钟级 2008 • 进行了通用化改造，开始承 接公司内部其他报表系统 • 助力百度统计成为国内最大 的中文网站分析工具 2009 • 随百度业务飞速发展，对 Doris的性能、可用性、拓 展性进行了全面升级 • 承担百度所有统计报表业务 中的导入 Prepared 事务和两阶段提交 • FE 充当协调者 • Prepare 阶段下发任务和写入数据 • Submit阶段 • 数据状态改为COMMITED • publish 版本 • 状态改为 VISIBLE Request-to-prepare Commit/Abort Done Coordinator Participant Prepare Phase Commit Phase Prepare Txn • 创建事务 • 规划导入执行计划 • 分发子任务 03 Doris 中的导入 FE Leader Analyzer FE Follower 数据版本 N 事务状态 PREPARE 事务管理 1.Begin Txn Phase 1 Execute Txn • 接受查询计划 • 初始化ScanNode • 初始化 TableSink和

短板。因此，高频的大规模汇 总统计，并发能力将面临较大挑战，这取决于集群硬件方面的并行计算能力。传统去重算法需要 大量计算资源，实时的大规模去重指标对CPU、内存都是一个巨大挑战。目前Doris最新版本已经 支持Bitmap算法，配合预计算可以很好地解决去重应用场景。 3 / 8 Apache Doris在美团外卖数仓中的应用实践 性能受限于集群的性能。一般原则是并发 较高的业务，需要严格控制查询时效（基本在毫秒级），对于并发不高的业务，允许进行 较大的查询，但也要考虑集群的承受能力。 通过一年来的应用以及Doris的不断改进升级，Doris的高可靠、高可用、高可扩展性也得 到进一步验证，服务稳定可靠。 准实时场景下的应用 离线业务分析大多基于T+1的离线数据，但在营销活动场景下，外卖团队往往需要当日的实时数 据进行业务 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

可以为表指定别名。最 终恢复的表会采用这个别名。分区名称不能修改。如果不指定分区，则默认恢复该表的所有分区。所指定的表和分区必须已 存在于仓库备份中。 ：指定恢复操作相关属性 ：指定恢复对应备份快照的哪个时间版本，必填。该信息可以通过 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. 可以