Doris的性能、可用性、拓 展性进行了全面升级 • 承担百度所有统计报表业务 2012 01 Doris简介 04 05 06 • 全新的数据模型，查询存储 效率大幅提升 • MPP框架，支持分布式计算 2013 • 精简架构、统一用户客户端， 实现高可用 • 正式开始对外提供服务 2015 • 正式开源 • 希望能帮助更多人、让更多 人帮助Doris 2017 • 贡献给Apache社区，更名

Oracle PostgreSQL 创建 ODBC 外部表需要在建表语句中填写外部数据源连接信息。 有两种方式提供连接信息。 一种是直接想连接信息描述在建表语句中。 一种是通过创建资源的形式统一管理连接信息，并在建表语句中引用该资源。 建议使用第二种方式，便于连接信息的管理。创建资源可参阅 资源管理 文档。 ON LOCATION ON LOCATION bos_repo bos_repo Label State State Progress Progress N/A N/A LOAD 进度 = 当前完成导入的表个数 / 本次导入任务设计的总表个数 * 100% LOAD 进度 = 当前完成导入的表个数 / 本次导入任务设计的总表个数 * 100% Type Type EtlInfo EtlInfo unselected.rows unselected.rows dpp

掉了 DWM 集市层的构建，直接增量到 Doris / ES 中构建宽表，解决了架构 1.0 中 上游数据更新延迟导致整个宽表延迟的问题，进而提升了数据的时效性。数据（指 标、标签等）通过 Spark 统一离线加载到 Kafka 中，使用 Flink 将数据增量更新到 Doris 和 ES 中（利用 Flink 实现进一步的聚合，减轻了 Doris 和 ES 的更新压力）。  加速层：该层主 特性，可以利用多表关联特性实现组合查询。  应用层：DataSet 统一指向 Doris，Doris 支持外表查询，利用该特性可对 ES 引擎 直接查询。 架构 2.0 存在的问题：  DataSet 灵活度较高，数据分析师可对指标和标签自由组合和定义，但是不同的分 析师对同一数据的定义不尽相同、定义口径不一致，导致指标和标签缺乏统一管理， 4 这使得数据管理和使用的难度都变高。 Dataset 与物理位置绑定，应用层无法进行透明优化，如果 Doris 引擎出现负载较 高的情况，无法通过降低用户查询避免集群负载过高报错的问题。 数据架构 3.0 针对指标和标签定义口径不统一，数据使用和管理难度较高的问题，我们继续对架构进行升 级。数据架构 3.0 主要的变化是引入了专门的语义层，语义层的主要作用是将技术语言转 换为业务部门更容易理解的概念，目的是将标签 (tag)与指

的业务场景中，模型的利用率也比较低。 2. Kylin配置过程繁琐，需要配置模型设计，并配合适当的“剪枝”策略，以实现计算成本与查 询效率的平衡。 3. 由于MOLAP不支持明细数据的查询，在“汇总+明细”的应用场景中，明细数据需要同步到 DBMS引擎来响应交互，增加了生产的运维成本。 4. 较多的预处理伴随着较高的生产成本。 ROLAP模式的优势 1. 应用层模型设计简化，将数据固定在一个稳定的数据粒度即可。比如商家粒度的星形模型 降低了运维成本。 3. 同时支持“汇总+明细”。 4. 模型轻量标准化，极大的降低了生产成本。 综上所述，在变化维、非预设维、细粒度统计的应用场景下，使用MPP引擎驱动的ROLAP模式， 可以简化模型设计，减少预计算的代价，并通过强大的实时计算能力，可以支撑良好的实时交互 体验。 双引擎下的应用场景适配问题 架构上通过MOLAP+ROLAP双引擎模式来适配不同应用场景，如下图所示： 技术权衡 不同业务线需求差异大，指标需要良好扩展性。 由于业务上的复杂性，实时流计算中，需要考虑诸多业务口径的对齐，业务ER模型在合流处理中 开发成本较高，资源占用较大，通过设计基于Doris的准实时生产数仓，可以灵活地实现业务微批 处理，且开发生产成本都比较低。以下为基于Doris的准实时数仓架构设计，是典型的实时Lambd a生产架构： 实现准实时计算方案，需要以下能力的支撑： 实时的写入能力：目前支持Kafka To Dori