如图所示为数据架构 1.0 架构图，分为数仓层、加速层、应用层三部分，数据架构 1.0 是 一个相对主流的架构，简单介绍一下各层的作用及工作原理：  数仓层：通过 ODS-DWD-DWS 三层将数据整合为不同主题的标签和指标体系， DWM 集市层围绕内容对象构建大宽表，从不同主题域 DWS 表中抽取字段。  加速层：在数仓中构建的大宽表导入到加速层中，Clickhouse 作为分析引擎， DataSet，作为逻辑视图从大宽表选取所需的标签与指标，同 时可以二次定义衍生的标签与指标。 存在的问题：  数仓层：不支持部分列更新，当上游任一来源表产生延迟，均会造成大宽表延迟， 进而导致数据时效性下降。  加速层：不同的标签跟指标特性不同、更新频率也各不相同。由于 ClickHouse 目前 更擅长处理宽表场景，无区别将所有数据导入大宽表生成天的分区将造成存储资源 的浪费，维护成本也将随之升高。  Spark 统一离线加载到 Kafka 中，使用 Flink 将数据增量更新到 Doris 和 ES 中（利用 Flink 实现进一步的聚合，减轻了 Doris 和 ES 的更新压力）。  加速层：该层主要将大宽表拆为小宽表，根据更新频率配置不同的分区策略，减小 数据冗余带来的存储压力，提高查询吞吐量。Doris 具备多表查询和联邦查询性能 特性，可以利用多表关联特性实现组合查询。 

、列、分 区、物化视图等等。 3. 当指定恢复表的部分分区时，系统会检查分区范围是否能够匹配。 4. 恢复操作的效率： 在集群规模相同的情况下，恢复操作的耗时基本等同于备份操作的耗时。如果想加速恢复操作，可以先通过设置 参数，仅恢复一个副本，之后在通过调整副本数 ALTER TABLE PROPERTY，将副本补齐。 SELECT-INTO-OUTFILE SELECT INTO 公有云用户必须使用 Compute Node（BE）的 HTTP 协议端口，默认为 8040。 私有化部署用户可以使用 Leader Node（FE）的 HTTP 协议端口，默认为 8030。但须保证客户端所在机器网络能够联通 Compute Node 所在机器。 本文档主要通过 cURL 命令来介绍 Stream Load 的使用方式 HTTP 的请求方式为 扫描-导出 扫描-导出 exec_mem_limit 有两种方式： 1. 指向 FE 的 HTTP 协议端口。这种方式，FE 会直接将请求做 307 转发到随机的一个 BE 节点。最终请求和数据直接和 这个 BE 节点通讯。这种方式需要客户端和 BE 节点的网络能够正常通讯。 2. 指向 BE 的 HTTP 协议端口。则请求直接和 BE 节点交互。 注：百度云 Doris 用户请直接连接 Compute Node 的 HTTP 协议端口即可。 在 URL

Colocate Join（Local Join）是和Shuffle Join、Broadcast Join相对的概念，即将两表的数据提前按照Join Key Shard，这样在Join执行时就没有数据网络传输的开销，两表可以直接在本地进行Join。 整个Colocate Join在Doris中实现的关键点如下： 数据导入时保证数据本地性。 查询调度时保证数据本地性。 数据Balance后保证数据本地性。 按照下图的方式进行计算，先根据page列和user_id 列group by，最后再Count： 显然，上面的计算方式，当数据量越来越大，到几十亿几百亿时，使用的IO资源、CPU资源、内 存资源、网络资源会变得越来越多，查询也会变得越来越慢。 于是我们在Doris中新增了一种Bitmap聚合指标，数据导入时，相同维度列的数据会使用Bitmap 聚合。有了Bitmap后，Doris中计算精确去重的方式如下： Doris在美团外卖数仓中的应用实践 Spark大数据博客 - https://www.iteblog.com 可以看到，当使用Bitmap之后，之前的PV计算过程会大幅简化，现场查询时的 IO、CPU、内存，网络资源也会显著减少，并且不再会随着数据规模而线性增加。 总结与思考 在外卖运营分析的业务实践中，由于业务的复杂及应用场景的不同，没有哪一种数据生产方案能 够解决所有业务问题。数据库引擎技术的发展，