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

2.2 技术问题
我们对问题进行了一个简单的分析，问题的核心还是前面提到的——被计算的数据规模。

我们目前是300亿——600亿的IO规模，标签数量2000+，由于标签下面还可能会有枚举值，所以最终会有大概300万左右的tag 。对全部数据进行一个扫表操作就要花非常多的时间。
另一个核心问题是，我们之前的业务场景过于复杂，为了配合业务场景在选择技术方案是做了很多的让步——更多的考虑满足业务需求而非性能。所以早期在计算逻辑层面没有处理的特别好，整个计算效率是比较低的。
但是这一类需求在我们的业务当中却展现的尤为强烈，我们非常迫切的想解决性能和功能的问题。所以在调研了非常多类似业务的方案后，我们提出了一种高性能标签索引的解决思路，并且考虑开发一套专用的系统来实现和解决类似的问题。
2.3 技术思路

（1）解决IO规模问题
原先的方法无论是基于MapReduce还是其他类似的逻辑，核心的问题在于我们要对全局数据进行遍历扫。因为我们是以 uid 为 key 的一个正向的数据结构，对标签进行扫必须要扫全量。
这里我们的解决办法是做倒排索引，以标签为 key 把 uid 作为value 。这样构建一个反向索引之后，原来我们是全表扫，现在变成只处理关注的标签，这样整体的IO规模会瞬间下降好几个数量级。
其次我们要做一个计算加速的优化，这里面主要是逻辑的变化。把原来圈选的逻辑变成交并集的处理。
在细节上需要做考虑两个问题：
一个是把原来标签的枚举变成二值化的 tag 。
比如：标签球类运动，它的每一个枚举值，就需要拆解为具体的 tag，如篮球、足球等。基于这个转化，可以把条件圈选变成交集、并集计算的组合。例如，选择喜欢篮球运动、不喜欢足球运动，就可以变成 tag-篮球 1，tag-足球 0 的交集。
另一个是我们有超过300万个 tag，在对 tag 做倒排索引时存储空间会成为一个非常大的问题，所以需要进一步降低存储，提升计算效率。
我们选择采用 Bitmap 来优化标签索引，用一个 bit 来标记一个 value，将用户作为整个 Bitmap 里的一个位，这样可以实现在存储上的空间节省。同时由于位运算在交并集上天然的优势，在计算上也能带来性能提升。
（2）加速计算过程
在解决计算规模问题时，核心的逻辑是用并行计算来加速过程。由于数据的 tag 是 key 构建的，尤其一些基础的标签的数据覆盖率非常高，有些可以达到90%以上，整个 Bitmap 会非常长。
这个情况下，对于一个百亿级的 uid 范围，bitmap 的 size 将会非常大，这些 bitmap 会成为计算平响，需要进一步对 bitmap 进行纵向的分桶，以加速计算，减少长尾。考虑 tag 数乘以分桶的情况，这是一个数量可观的分布式并行的储存与计算过程，对于分布式系统有着很高的要求，也是一种典型的 MPP 场景。
比较巧的是，在和 Doris 同学的交流过程当中，我们得知 Doris 正在做相似的工作。Doris 的 MPP 架构和正在进行的 Bitmap 集成，刚好是我们业务需要的能力。可以说是不谋而合。
我们也调研了其他开源解决方案比如说 Kylin 和 Druid，Kylin 在这个场景下有一定的局限性，它需要预计算，这就带来了维度和空间的爆炸，并且不能满足我们对细粒度数据的需求。Druid 在这方面可以满足我们的需求，但是在一些特定使用场景下我们是依赖Doris 的，所以我们最终选择了 Doris 。