DataSet，作为逻辑视图从大宽表选取所需的标签与指标，同 时可以二次定义衍生的标签与指标。 存在的问题：  数仓层：不支持部分列更新，当上游任一来源表产生延迟，均会造成大宽表延迟， 进而导致数据时效性下降。  加速层：不同的标签跟指标特性不同、更新频率也各不相同。由于 ClickHouse 目前 更擅长处理宽表场景，无区别将所有数据导入大宽表生成天的分区将造成存储资源 的浪费，维护成本也将随之升高。 Doris 的优势：  Doris 架构极简易用，部署只需两个进程，不依赖其他系统，运维简单；兼容 MySQL 协议，并且使用标准 SQL。  支持丰富的数据模型，可满足多种数据更新方式，支持部分列更新。  支持对 Hive、Iceberg、Hudi 等数据湖和 MySQL、Elasticsearch 等数据库的联邦查 询分析。  导入方式多样，支持从 HDFS/S3 等远端存储批量导入，也支持读取 数据模型可支持部分列实时更新，因此我们去 掉了 DWM 集市层的构建，直接增量到 Doris / ES 中构建宽表，解决了架构 1.0 中 上游数据更新延迟导致整个宽表延迟的问题，进而提升了数据的时效性。数据（指 标、标签等）通过 Spark 统一离线加载到 Kafka 中，使用 Flink 将数据增量更新到 Doris 和 ES 中（利用 Flink 实现进一步的聚合，减轻了 Doris 和 ES 的更新压力）。

e社区后更名为 Apache Doris 系统定位 • 百度内部统称其为“百度数据仓库Palo”，同时百度云上提供Palo的企业级托管版本 发展历程 01 02 03 • 1.0版本正式上线 • 应用于百度凤巢统计报表的 需求场景，上线后数据更新 频率从天级提升至分钟级 2008 • 进行了通用化改造，开始承 接公司内部其他报表系统 • 助力百度统计成为国内最大 的中文网站分析工具 中的导入 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和

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

业务分析除了宏观数据之外，对明细数据查询也是一种刚需。通常大家会选择MySQL等关系型DB 作为明细数据的快速检索查询，但当业务成长较快时，很快就会遇到性能瓶颈，并且运维成本也 很高。例如，大数据量的同步、新增字段、历史数据更新等操作，它们的维护成本都非常高。 外卖运营业务特点 美团的使命是“帮大家吃得更好，生活更好”。外卖业务为大家提供送餐服务，连接商家与用户， 这是一个劳动密集型的业务，外卖业务有上万人的运营团队来服务全国几百万的商家，并以“商圈 短板。因此，高频的大规模汇 总统计，并发能力将面临较大挑战，这取决于集群硬件方面的并行计算能力。传统去重算法需要 大量计算资源，实时的大规模去重指标对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