DORIS是什么牌子 Doris是什么意思( 三 ) _云知道

3 基于Doris的技术实现
3.1 Doris分布式查询引擎
结合业务场景，我们将方案调整为基于Doris实现全套的标签索引服务。

Doris 采用的 MPP 架构非常简洁，由 FE 和 BE 完成从服务接入到数据存储、管理、计算的分布式服务。其中，FE 负责存储以及维护集群数据、接收、解析、查询、设计规划整体查询流程，BE 负责数据存储和具体的实施过程。FE 会根据用户的查询去生成一个完整的逻辑规划，进一步构建分布式的逻辑发给整个集群去执行。
在右边规划图中，由一个 BE 去执行的时候，需要通过 RPC 进行数据交换，不同的计算方法和内容，交换的数据也不同。
3.2 Bitmap在Doris的应用
Bitmap 通常作为 OLAP 系统和存储系统的索引，Doris 很早就集成了 Bitmap 来加速数据查询的过程。

如上图所示，右边是 Doris Bitmap 索引的数据结构。

和索引应用不同，Bitmap 作为数据应用，可以解决明细数据的查询、交并集问题。我们在使用的时候将 Bitmap 作为数据结构，直接使用 Bitmap 作为实际存储数据来解决明细数据查询和交并集计算的问题。

基于Doris，首先我们通过离线的MR形式完成了标签 tag 的二值化和 uid 倒排（这里还包括对ID的顺序处理）。
然后我们用 Bitmap 作为数据结构，Bitmap Union为聚合函数，采用Doris Load的方法完成了数据建库和数据Load，这个过程可能比较慢但很可行。
接下来，我们需要把条件查询转变成交并集计算，对单个节点来说，intersect_count / union_count 的方法 Doris 可以自动完成分布式的计算过程，实现已经 Bitmap 化的标签数据的聚合计算。
基于以上的逻辑，我们只用了两周就完成了测试过程。
3.3 标签索引应用在Doris基础实现的问题
以上的方案在比较小的计算规模上可以得到计算结果，对于稍微复杂的计算场景，就出现了一些问题。

我们做了一个测试，在300亿的 uid，平均标签数为300的情况下，能够完成不包含稠密 Bitmap 的 tag 进行6个标签的交集和并集的计算，但当我们把条件 tag 换成稠密的 Bitmap 之后，用14个标签就已经超时了。（这里稠密的Bitmap指 tag 数据在全量用户 id 的覆盖率非常高的情况，而这种 tag 恰恰是我们业务中最常用到的。）
除此之外还有一个功能问题，当时Doris还不支持批量ID导出。
3.4 标签索引应用在Doris基础实现的性能问题
结合 Doris 的计算过程，我们分析认为问题的核心主要有两点。第一点在于 Bitmap 本身实现的逻辑，第二点在于在 Doris 中 Bitmap 分布式实现的问题。

一般来说，32位 Bitmap 在压缩比和计算效率上有很好的平衡，但是64位的 Bitmap 的计算效率就相对比较差。画像的数据在百亿级别，所以需要用64位的 Bitmap，那么计算效率就比较低。
第二个，当 Bitmap 基数比较大时，数据规模也比较大，网络磁盘和网络IO处理时间比较长。Doris 在计算过程中需要 scan 数据后全部传输到顶层节点进行求交和求并运算，但本质上交并集计算是在单节点进行的，同时要经过网络IO之后才能进行处理，这都成为了影响性能的关键点。