毫秒级从百亿大表任意维度筛选数据，是怎么做到的...

随着闲鱼业务的发展，用户规模达到数亿级，用户维度的数据指标，达到上百个之多。如何从亿级别的数据中，快速筛选出符合期望的用户人群，进行精细化人群运营，是技术需要解决的问题。业界的很多方案往往需要分钟级甚至小时级才能生成查询结果。本文提供了一种解决大数据场景下的高效数据筛选、统计和分析方法，从亿级别数据中，任意组合查询条件，筛选需要的数据，做到毫秒级返回。

从技术角度分析，我们这个业务场景有如下特点：

• 需要支持任意维度的组合(and/or)嵌套查询，且要求低延迟；

• 数据规模大，至少亿级别，且需要支持不断扩展；

• 单条数据指标维度多，至少上百，且需要支持不断增加； 综合分析，这是一个典型的OLAP场景。

下面简单对比下OLTP和OLAP：

• 数据量瓶颈：mysql比较适合的数据量级是百万级，再多的话，查询和写入性能会明显下降。因此，一般会采用分库分表的方式，把数据规模控制在百万级。

• 查询效率瓶颈：mysql对于常用的条件查询，需要单独建立索引或组合索引。非索引字段的查询需要扫描全表，性能下降明显。

综上分析，我们的应用场景，并不适合采用行存储数据库，因此我们重点考虑列存数据库。

下面简单对比一下行式存储与列式存储的特点：

• 任意维度智能组合索引(使用方无需单独自建索引)

• 百亿大表查询毫秒级响应

• MySql BI生态兼容，完备SQL支持

• 空间检索、全文检索、复杂数据类型(多值列、JSON)支持

那么，HybridDB for MySQL计算规格是如何做到大数据场景下的任意维度组合查询的毫秒级响应的呢？

• 首先是HybridDB的高性能列式存储引擎，内置于存储的谓词计算能力，可以利用各种统计信息快速跳过数据块实现快速筛选；

• 第二是HybridDB的智能索引技术，在大宽表上一键自动全索引并根据列索引智能组合出各种谓词条件进行过滤；

• 第三是高性能MPP+DAG的融合计算引擎，兼顾高并发和高吞吐两种模式实现了基于pipeline的高性能向量计算，并且计算引擎和存储紧密配合，让计算更快；

• 第四是HybridDB支持各种数据建模技术例如星型模型、雪花模型、聚集排序等，业务适度数据建模可以实现更好的性能指标。

综合来说，HybridDB for MySQL计算规格是以SQL为中心的多功能在线实时仓库系统，很适合我们的业务场景，因此我们在此之上构建了我们的人群圈选底层引擎。

在搭建了人群圈选引擎之后，我们重点改造了我们的消息推送系统，作为人群精细化运营的一个重要落地点。

离线数据层：用户维度数据，分散在各个业务系统的离线表中。我们通过离线T+1定时任务，把数据汇总导入到实时计算层的用户大宽表中。

实时计算层：根据人群的筛选条件，从用户大宽表中，查询符合的用户数量和用户ID列表，为应用系统提供服务。

人群圈选前台系统：提供可视化的操作界面。运营同学选择筛选条件，保存为人群，用于分析或者发送PUSH。每一个人群，对应一个SQL存储。类似于： select count(*) from userbigtable where column1> 1 and column2 in ('a','b') and ( column31=1 or column32=2) 同时，SQL可以支持任意字段的多层and/or嵌套组合。 用SQL保存人群的方式，当用户表中的数据变更时，可以随时执行SQL，获取最新的人群用户，来更新人群。

闲鱼PUSH系统：从人群圈选前台系统中获取人群对应的where条件，再从实时计算层，分页获取用户列表，给用户发送PUSH。在实现过程中，我们重点解决了分页查询的性能问题。

分页查询性能优化方案： 在分页时，当人群的规模很大(千万级别)时，页码越往后，查询的性能会有明显下降。因此，我们采用把人群数据增加行号、导出到MySql的方式，来提升性能。表结构如下：

• 批次号：人群每导出一次，就新加一个批次号，批次号为时间戳，递增。

• 行号：从1开始递增，每一个批次号对应的行号都是从1到N。

我们为"人群ID"+"批次号"+"行号"建组合索引，分页查询时，用索引查询的方式替换分页的方式，从而保证大页码时的查询效率。

另外，为此额外付出的导出数据的开销，得益于HybridDB强大的数据导出能力，数据量在万级别至百万级别，耗时在秒级至几十秒级别。综合权衡之后，采用了本方案。

人群圈选系统为闲鱼精细化用户运营提供了强有力的底层能力支撑。同时，圈选人群，也可以应用到其他的业务场景，比如首页焦点图定投等需要分层用户运营的场景，为闲鱼业务提供了很大的优化空间。

本文实现了海量多维度数据中组合查询的秒级返回结果，是一种OLAP场景下的通用技术实现方案。同时介绍了用该技术方案改造原有业务系统的一个应用案例，取得了很好的业务结果，可供类似需求或场景的参考。

人群圈选引擎中的用户数据，我们目前是T+1导入的。这是考虑到人群相关的指标，变化频率不是很快，且很多指标(比如用户标签)都是离线T+1计算的，因此T+1的数据更新频度是可以接受的。后续我们又基于HybridDB构建了更为强大的商品圈选引擎。闲鱼商品数据相比用户数据，变化更快。一方面用户随时会更新自己的商品，另一方面，由于闲鱼商品单库存(售出即下架)的特性，以及其他原因，商品状态会随时变更。因此我们的选品引擎，应该尽快感知到这些数据的变化，并在投放层面做出实时调整。我们基于HybridDB(存储)和实时计算引擎，构建了更为强大的“马赫”实时选品系统。已推出“马赫”的系列文章，有兴趣的同学可以关注。另外如果对本文中的具体技术实现(细节)有任何问题，请联系我们。谢谢。

参考资料： HybridDB for MySQL介绍： https://www.aliyun.com/product/petadata

关注二维码，前瞻技术尽在掌握