物化视图。并且仅备份一副本。 3. 备份操作的效率 备份操作的效率取决于数据量、Compute Node 节点数量以及文件数量。备份数据分片所在的每个 Compute Node 都会参与 备份操作的上传阶段。节点数量越多，上传的效率越高。 文件数据量只涉及到的分片数，以及每个分片中文件的数量。如果分片非常多，或者分片内的小文件较多，都可能增加备份 操作的时间。 EXPORT EXPORT EXPORT SQL手册 64 ：当前阶段 ：提交作业后的初始状态。 ：执行快照中。 ：快照完成，准备上传。 ：快照上传中。 ：将作业元信息保存为本地文件。 ：上传作业元信息。 ：作业成功。 ：作业失败。 ：备份的表和分区。 ：任务提交时间。 ：快照完成时间。 ：快照上传完成时间。 ：作业结束时间。 ：在 SNAPSHOTING 和 UPLOADING 阶段会显示还未完成的子任务id。 导入任务的标识。 导入任务当前所处的阶段。在 Broker load 导入过程中主要会出现 PENDING 和 LOADING 这两个导入中的状态。如果 Broker load 处于 PENDING 状态，则说明当前导入任务正在等待被执行；LOADING 状态则表示正在执行中。 导入任务的最终阶段有两个：CANCELLED 和 FINISHED，当 Load job 处于这两个阶段时，导入完成。其中 CANCELLED

• 为了保证At-Most-Once 语意， 用户同一批次数据需要使用相同的Label 03 Doris 中的导入 Prepared 事务和两阶段提交 • FE 充当协调者 • Prepare 阶段下发任务和写入数据 • Submit阶段 • 数据状态改为COMMITED • publish 版本 • 状态改为 VISIBLE Request-to-prepare Commit/Abort 2 总结 03 Doris 中的导入 • 写入带版本 • 查询带版本 多版本机制解决读写冲突 两阶段导入保证多表原子生效 • 支持并行导入 • 有冲突时按导入顺序生效，无冲突导入时并行生效 写入带版本 查询带版本 支持并行导入 冲突时按顺序生效 （多版本机制） （两阶段导入） 事务能力保证 使用案例 04 BI Application 数据加载 数据输出 数据查询

份冗余的数据。  实时性比较差，由于每个 Source 表产出的时间不一样，往往会因为某些延迟比较 大的 Source 表导致整个数据链路延迟增大。  开发成本较高，该方案只能作为离线方式，若想实现实时方式则需要投入开发资源 进行额外的开发。 而在 Flink 中生成宽表，链路简单、成本低也容易实现，主要流程是：首先用 Spark 将相 关 Source 表最新数据离线导入到 Kafka 中， ， TDW 无需维护两份冗余的数据，Kafka 也只需保存最新待导入的数据。同时该方案整体实时性更好且可控，并且大宽表聚合在 Flink 中执行，可灵活加入各种 ETL 逻辑，离线和实时可对多个开发逻辑进行复用，灵活度较高。 数据模型选择 目前我们生产环境所使用的版本为 Apache Doris 1.1.3，我们对其所支持的 Unique 主键模 型、Aggregate 聚合模型和 Duplicate 运维起来比较容易;  高度兼容 MySQL 语法，支持标准 SQL，极大降低开发人员接入使用成本；  支持多种联邦查询方式，支持对 Hive、MySQL、Elasticsearch 、Iceberg 等组件的 联邦查询分析，降低多数据源查询复杂度。 通过以上的方式，使得存储成本降低 42%，开发与时间成本降低了 40% ，成功实现降本提 效，后续我们将继续探索！ 未来规划

齐逻辑复杂。 不同业务线需求差异大，指标需要良好扩展性。 由于业务上的复杂性，实时流计算中，需要考虑诸多业务口径的对齐，业务ER模型在合流处理中 开发成本较高，资源占用较大，通过设计基于Doris的准实时生产数仓，可以灵活地实现业务微批 处理，且开发生产成本都比较低。以下为基于Doris的准实时数仓架构设计，是典型的实时Lambd a生产架构： 实现准实时计算方案，需要以下能力的支撑： 实时的写入能力：目前支持Kafka