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、内存，网络资源也会显著减少，并且不再会随着数据规模而线性增加。 总结与思考 在外卖运营分析的业务实践中，由于业务的复杂及应用场景的不同，没有哪一种数据生产方案能 够解决所有业务问题。数据库引擎技术的发展，

万时，查询时长会达到 60 秒，圈选群体再次增大甚至会出现超时报错。经排查分析， 主要的耗时包括两方面：  BE 从 ES 中拉取数据（默认一次拉取 1024 行），对于 100 万以上的群体，网络 IO 开销会很大。  BE 数据拉取完成以后，需要和本地的指标表做 Join，一般以 SHUFFLE/BROADCAST 的方式，成本较高。 针对这两点，我们进行了以下优化： 11 Bucket Join 执行计划，将分桶序号下发到 BE ScanNode 节点，并下推到 ES；  ES 对查询出的数据进行 Bitmap 压缩，并将数据的多批次获取优化为一次获取，减 少网络 IO 开销；  Doris BE 只拉取和本地 Doris 指标表相关 Bucket 的数据，直接进行本地 Join，避 免 Doris BE 间数据再 Shuffle 的过程。 通过

公有云用户必须使用 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 语句进行查询即可。 Doris 对于外部表的查询，本质上是通过某一个 Compute Node 节点上的 ODBC Client 对外部数据源进行连接和查询。所以 要求外部数据源和 Compute Node 节点网络是双向连通的。 同时，Doris 查询外部表并不是分布式查询，而是单 Client 方式连接查询。所以性能效率上要远低于查询 Doris 自身存储的 表。外部表比较适用的场景式一些频繁更新的维度表和