震惊！这个分布式ID生成方案，让我看到了李小龙的影子

一臻数据

发布于 2024-12-24 15:52:14

6000

代码可运行

运行总次数：0

代码可运行

“数据分析的世界里，经常会遇到这样的困扰：上亿用户的画像分析要跑好几个小时，后台分页查询越往后越慢，用户标签去重让内存爆炸...面对这些性能瓶颈，你是否也在寻找一个优雅的解决方案？最近在技术圈刮起一阵"自增列"旋风。通过创新的预分配策略，完美解决了分布式系统中自增ID的性能难题。不仅让用户画像秒级响应，还能让深分页查询飞起来，堪称分布式数据库的一次优雅突破。作为一名资深数据摸鱼师，看到这个设计的第一反应是：太妙了！看似平淡无奇，实则暗藏玄机。今天就带大家一起探秘Doris AUTO_INCREMENT背后的故事，领略技术设计之美。

Doris如何破解分布式自增列的难题?

最近在做数据分析平台架构设计,遇到一个有趣的挑战:需要为数亿用户生成唯一ID做画像分析。传统数据库中的自增主键在单机环境下轻松搞定,可在分布式系统中就没那么简单了。

刚好 Apache Doris 2.1版本推出了自增列功能。仔细研究后发现这是一个非常优雅的实现 - 通过预分配策略解决了分布式自增的性能瓶颈。

核心特性解析:

表内唯一性保证 - Doris通过预分配机制保证自增列值在表内唯一。每个BE节点获取一段序列号缓存,互不相交,消除了分布式环境下的并发冲突。

高效预分配策略 - FE节点统一分配序列段给Coordinator BE节点,各BE节点直接获取使用。这种两级分配机制大大减少了节点间通信开销。

稠密数值分配 - 虽不保证完全连续,自增值会稠密分布。这对很多业务场景够用,比如用户画像中的字典编码。

灵活导入支持 - 支持普通导入和部分列更新两种模式。对于null值自动填充,非null值保持不变,满足不同数据处理需求。

技术实现上最妙的是预分配策略。它打破了分布式系统中强一致性带来的性能瓶颈,在保证唯一性的同时实现了高并发。

Doris自增列的功能价值不仅在于解决了技术难题,更在于它为业务开发提供了便利。

接下来一起看看实际应用案例。

自增列的应用场景

记得前几天和一位数据分析师朋友聊天,他吐槽道:"每天要分析上亿用户数据,光用户ID去重就头大。要么内存爆炸,要么性能拉胯。"

我笑着说:"这不巧了吗?Doris的自增列简直就是为这种场景量身定制的。"

让我们一起看看在实战中如何玩转这个功能。

案例一：超大规模用户画像分析

在进行 PV/UV 统计或人群圈选等需要精确去重的查询时，可以使用自增列对 UserID 或订单 ID 等字符串值创建字典表，将用户数据批量或者实时写入字典表即可生成字典，根据各种维度的条件对对应的 Bitmap 进行聚合运算；

CREATE TABLE `demo`.`dictionary_tbl` (
    `user_id` varchar(50) NOT NULL,
    `aid` BIGINT NOT NULL AUTO_INCREMENT
) ENGINE=OLAP
UNIQUE KEY(`user_id`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 32
PROPERTIES (
"replication_allocation" = "tag.location.default: 3",
"enable_unique_key_merge_on_write" = "true"
);

-- 导入数据自动生成字典
insert into dictionary_tbl(user_id) 
select user_id from user_behavior group by user_id;

妙就妙在,自增列会自动为每个用户分配一个自增的整数ID。这样不仅节省存储空间,bitmap计算性能还能提升3-5倍。一个同事测试后兴奋地说:"以前1分钟才能算完的UV查询,现在秒出结果!"

案例二：告别分页查询的"深渊"

在页面展示数据时，往往需要做分页展示。传统的分页通常使用 SQL 中的 limit, offset + order by 进行查询。在进行深分页查询时，即使查询数据量较少、数据库仍需将全部数据读取至内存进行全量排序，查询效率比较低下。采取自增列可以为每一行生成唯一标识、查询时记住上一页最大唯一标识并用于下一页的查询条件，实现更高效的分页查询。

以下表为例，unique_value 是一个唯一值：

CREATE TABLE `demo`.`records_tbl2` (
    `key` int(11) NOT NULL COMMENT "",
    `name` varchar(26) NOT NULL COMMENT "",
    `address` varchar(41) NOT NULL COMMENT "",
    `city` varchar(11) NOT NULL COMMENT "",
    `nation` varchar(16) NOT NULL COMMENT "",
    `region` varchar(13) NOT NULL COMMENT "",
    `phone` varchar(16) NOT NULL COMMENT "",
    `mktsegment` varchar(11) NOT NULL COMMENT "",
    `unique_value` BIGINT NOT NULL AUTO_INCREMENT
) DUPLICATE KEY (`key`, `name`)
DISTRIBUTED BY HASH(`key`) BUCKETS 10
PROPERTIES (
    "replication_num" = "3"
);

-- 在分页展示中，每页展示 100 条数据，使用如下方式获取第一页的数据：
select * from records_tbl2 order by unique_value limit 100;

-- 通过程序记录下返回结果中unique_value中的最大值，假设为 99，则可用如下方式查询第二页的数据：
select * from records_tbl2 where unique_value > 99 order by unique_value limit 100;

一位测试工程师看到这个结果后打趣道:"这不就是从'慢如蜗牛'变成'快如闪电'了吗?"

实战小贴士

使用中还发现一个有趣的现象:由于每个BE节点缓存一段序列号,新导入数据的自增值可能比老数据小。这让我想起量子物理中的"叠加态" - 在你观察之前,X既可能是活的也可能是死的。同样,在你查询之前,下一个自增值既可能比当前大也可能比当前小。因此，不能根据自增列分配出的值的大小来判断导入时间上的先后顺序：