延迟，均会造成大宽表延迟， 进而导致数据时效性下降。  加速层：不同的标签跟指标特性不同、更新频率也各不相同。由于 ClickHouse 目前 更擅长处理宽表场景，无区别将所有数据导入大宽表生成天的分区将造成存储资源 的浪费，维护成本也将随之升高。  应用层：ClickHouse 采用的是计算和存储节点强耦合的架构，架构复杂，组件依赖 严重，牵一发而动全身，容易出现集群稳定性问题，对于我们来说，同时维护 到 DWS 的计算逻 辑将在语义层中进行定义，且以单个指标和标签的形式进行定义，之后由语义层来 发送命令，生成 SQL 命令给数仓层执行计算。  加速层：从语义层接收配置、触发导入任务，比如加速哪些指标与标签均由语义层 指导。  应用层：向语义层发起逻辑查询，由语义层选择引擎，生成物理 SQL。 架构优势：  可以形成统一视图，对于核心指标和标签的定义进行统一查看及管理。 应用层与物理引擎完成解耦，可进一步对更加灵活易用的架构进行探索：如何对相 关指标和标签进行加速，如何在时效性和集群的稳定性之间平衡等。 存在的问题： 因为当前架构是对单个标签和指标进行了定义，因此如何在查询计算时自动生成一个准确有 效的 SQL 语句是非常有难度的。如果你有相关的经验，期待有机会可以一起探索交流。 优化经验 从上文已知，为更好地实现业务需求，数据架构演进到 4.0 版本，其中 Apache Doris

INSERT INSERT Description Description 需要导入数据的表名。 指定需要导入数据的分区。 为本次 INSERT 操作指定一个 Label。如果不指定，则系统会自动生成一个随机 ID。 指定目标列顺序 INSERT 操作支持两种方式。一种是通过 VALUES 语句即常量表达式进行单行数据写入。另一种是用过 Query 语句从其他表 中查询数据并导入。 Example OK 4 rows affected 4 rows affected 2 warnings 2 warnings Baidu 百度智能云文档 SQL手册 13 为用户指定的 label 或自动生成的 label。Label 是该 Insert Into 导入作业的标识。每个导入作业，都有一 个在单 database 内部唯一的 Label。 表示导入数据是否可见。如果可见，显示 ，如果不可见，显示 ：成功后是否产生一个空文件标识。文件名为 "my_file_file_name"。其中 是在 中指定的前缀， 为该参数的值。 返回结果说明： 如果正常导出并返回，则结果如下： ：最终生成的文件个数。 ：结果集行数。 file_path file_path bos://my_bucket/my_file_ # 远端目录 bos://my_bucket/my_file_

BE （C++） BE (C++) BE (C++) BE (C++) 整体架构简单，产品易用 • 高度兼容MySQL协议 • 主从架构，不依赖任何其他组件 • FE负责解析/生成/调度查询计划 • BE负责执行查询计划、数据存储 • 任何节点都可线性扩展 01 Doris 简介 导入的问题 02 典型应用场景——OLAP分析 数据源 数据应用 数据存储 对象存储BOS 使用 MySQL 协议定期提交和查看导入作业。 确定导入方式的协议 • 导入方式为同步或异步。 确定导入方式的类型 • 每一批次数据唯一且固定，保证 At-Most-Once 制定 Label 生成策略 • 外部系统需要保证自身的 At-Least-Once，这样就可以保证 导入流程的 Exactly-Once。 程序自身保证 At-Least-Once 多表原子性导入 • 每个表拆分多个任务，并下发BE

量会显 著减少。 查询执行多实例并发优化 如上图所示，Doris默认在每个节点上为每个算子只会生成1个执行实例。这样的话，如果数据量 很大，每个执行实例的算子就需要处理大量的数据，而且无法充分利用集群的CPU、IO、内存等 资源。 一个比较容易想到的优化手段是，我们可以在每个节点上为每个算子生成多个执行实例。这样每 个算子只需要处理少量数据，而且多个执行实例可以并行执行。 下图是并发度设置