人群圈选系统基本逻辑架构

人群圈选并不是一个新业务， 几乎所有的互联网公司都在做，因为这是一个基本营销场景，选定的人群要发代金券，要导入流量，要做针对性促销，要选择合适的人群，那怎么做这件事情呢？实际上要通过人群的行为特征，采购特性，关注特征，兴趣特性，甚至是教育程度等等，把人群划分成不同的组。通过划分人群组，在有限的营销预算里面，将资源投放给转化率或点击率最高的人群。

那这个业务需求的背后技术要求是什么呢？

典型人群业务版块的核心是洞察分析，洞察分析一般的场景是，要支撑几万个不同的广告主，他们会在平台上自由选择更感兴趣的人群，每个广告主对人群的诉求是不一样的，某些人关注的购买力，有些关注的是收藏行为。每天数万广告主发出数百万次的查询请求，构建数万次各种人群包，各个系统的计算复杂度是要求非常高的。这里的核心诉求包含几个点，毫秒级洞察，因为所有的查询希望是交互式的，需要在界面上每一次互动，每一次下拉菜单，每一次选择，每一次条件组合，都希望看到一个互动结果，整个人群是变大还是变小，目标人群是不是跟期望的相似。这一点对性能要求是非常大的。同时提醒大家，数据一定要脱敏处理，保护好用户的个人隐私，所有的分析都是建立在合规数据基础之上的分析。

人群圈选系统服务引擎核心诉求

规模数据上的交互式分析性能

数万广告主提交数百万次的数据查询，需要毫秒级的响应，查的快是必须的。这个快加了一个限定词，是规模数据。百万级不算规模，行为日志是非常大的，希望是百亿级别以上，依旧有一个很好的交互式分析能力，能够在秒级响应。

灵活筛选能力

用户的筛选行为多种多样，等值比较、数值大小范围比较、时间范围比较等。各种各样的筛选条件能够灵活组合，表达这些筛选结果就体现出来计算引擎的能力。

高吞吐更新能力

用户标签并不是静态的，当前一切实时化，一切在线化，所有的行为数据变化，都希望能够实时触发，实时反馈下一时刻的系统决策。比如最新收藏夹里放了什么商品，这种行为能不能成为在线画像的一部分。所以对高实时的吞吐能力要求会很高。

从计算层面来讲，可以分成下图几种计算模式。

标签过滤分为等值过滤，可以用Equal/In/Between，这些过滤可以在百亿级别上进行操作。操作之后的结果集，要做很多的交差并集，举个常见例子，一个用户既关注了竞品品牌也关注了本公司商品，却没有买，这里面其实有并的关系，有差的关系，有交的关系。所以这些人群关系之间要组合，有很高的交差并集计算。最后还有很强的精确去重的需求，因为最终要把计算结果，变成一个唯一定位用户的ID，这个ID会用来做广告的投递。那这些需求，在引擎层面上就是数据读取效率怎么样，如果用行存读取是不是会出现IO放大的问题，数据按行去存，真正过滤是按照某一列过滤，但是IO读取，会把整行读取，会出现IO放大问题。列存还会有索引问题、过滤效果问题。计算算子上表连接时是Hash JOIN方式还是用Nest Loop JOIN方式。精确去重的效果如何。这些都是对计算引擎效率上有很高的要求。所以本质上是要解决高效数据存储与过滤、关系运算内存/CPU消耗、精确去重内存/CPU消耗问题。

这里就有很多不同的解决优化思路，是用更多的内存还是CPU。行业内大致的思路有两种。

一种是通过预结算思路，有Kylin/Druid这样的技术。这些技术可以在一些预定义的维度上，进行一次提前的预加工。预加工后，数据集会在本质上进行减少。比如要找一个用户群体，关注了第一个商品却没有关注第二个商品。每一个结果集都可以用bitmap数组来表达，数组之间做交差并集效率是非常高的。预计算技术实际上是把精确去重和交差并集上计算是有很大好处的。但缺陷也比较明显，最大的缺陷就是不灵活，同时完整SQL表达能力也比较弱。另一种是属于MPP分布式数据库技术，一些通过列存、分布式、索引方式提供更好的查询性能。

所以真正落地一套人群筛选方案时，一般不是只选择一个方案。因为不管是预计算方案还是MPP方案都有一些本质的缺陷。

那市场上哪些技术更适合做存储和查询呢？

第一类技术，大家都比较熟悉的事务数据库。事务数据库是行存储，对单行数据写入存储效率是非常高的，用来做查询，做过滤统计，在千万级以上会发现消耗资源是非常大的。所以一般不会拿TP系统直接做分析操作。

第二类系统，AP系统，是我们常见OLAP系统。这一类系统针对大规模数据扫描场景做了优化，包括利用分布式技术，列存技术，压缩技术、索引的技术等等。这类技术查的都很快，但本质缺陷是大部分系统更新上做的不太友好，因为数据查的快，所以数据该紧凑紧凑，该压缩压缩，所以在更新能力上弱一些。还有一类系统，在大数据分析也常见，我们把它叫Serving系统，支持在线业务的一类系统，这类系统查的是足够快，但牺牲的其实是查询的灵活性。比如，文档数据库、KeyValue系统查询方式有很大的局限，只能按照它的key去查询。这样灵活性减少了，但是性能上无限放大，因为可以横向扩展，因为key相对来说访问效率是最高的，而且更新效率也非常高，按照key更新，可以替换整条记录。我们过去就不得不针对不同场景，把数据拆分到TP、AP、Serving，数据在几个系统之间来回传递。让我们对整个系统的依赖度变的更高，只要数据有一次依赖，就会产生一次数据不一致，产生数据不一致就意味着数据的修正，数据的开发成本变的更高。所以大家都会在很多领域做创新，第一类创新是在TP和AP领域里做一个混合负载能力。尝试通过一个技术把这两个场景解决掉。有支持事务，又能支持分析，也希望未来有一天这个系统真正很好的落地。这类系统也有一定的局限，要支持事务操作，各种分布式锁开销还是必不可少的。这类系统因为具备了一些能力，所以在整个并发和性能上，开销是比较大的，所以有一定的性能瓶颈。

在下图左侧部分也是可以做一些创新的，左侧的创新会发现最大的问题是不支持事务。把事务能力弱化，不需要那么多事务，希望查的足够快，更新的足够快。所以这个地方是有可能做技术创新，这个技术既具备很好的灵活的分析能力，也具备很好的数据写入能力，有具备完整的SQL表达能力。所以左侧的交集部分的技术，很适合刚才提到的三点技术要求。这就是今天要分享的产品Hologres。

Hologres=向量化SQL引擎 + 灵活的多维分析+高吞吐实时更新

Hologres，一站式实时数仓，提供实时分析（OLAP）与在线服务（点查）两种能力，与MaxCompute无缝打通，实现一套架构，多种负载（OLAP、在线服务、交互式分析）共存，减少数据孤岛，避免数据割裂，简化链路，提升用户体验。

统一存储

• 一份数据支持多种负载 (OLAP、在线服务、MaxCompute交互式分析)，减少数据割裂
• 数据无孤岛，无频繁数据导入导出，提高数据开发效率、简化链路

统一接口

• 接口兼容开源Postgres协议，支持主流开发和BI工具，无需应用层重写，生态开放
• 统一用SQL描述多种场景，提高数据应用开发效率
• 统一数据模型，通过“表”来描述数仓模型，语义一致

实时离线一体

• 支持实时写入、实时更新、写入即可查，原生集成Flink
• 与MaxCompute存储无缝打通，透明加速，无需数据移动，支持交互式分析能力，支持实时数据关联历史数据

高性能

• OLAP场景性能好于Clickhouse、Impala、Presto，支持亚秒级响应与高QPS
• 在线服务（点查）场景性能好于HBase，点查支持100K+QPS

Hologres：一站式实时数仓

Hologres为什么能支持高性能，高吞吐写入？

实际上没有神秘的地方，Hologres更多还是依赖于整个IT行业，有很多底层技术上的进步。比如，带宽变宽，延迟变低。好处是之前必须依赖本地的操作，比如之前依赖本地磁盘，现在可以依赖网盘。其实Hologres底层的存储，分多副本存储，高可靠存储，把这些负责状态管理的事情，都交给阿里云，底层是盘古存储引擎，自带多副本，自带压缩，自带缓存，自带高可靠。这就会使整个计算节点的逻辑变的轻薄和简单，也让高可靠更加简单。任何一个节点宕掉之后，可以很快从一个分布式的网盘里恢复状态。会让计算层变的无状态，这是第一点。第二点是磁盘的利用，过去磁盘的转速有机械瓶颈。机械磁盘是按圈去转的，一秒钟多少转。所以我们的IO场景都是面向扫描场景做了大量的优化。我们希望所有的数据都是以块为单位，进行更新、读写。所以在过去这种高更新场景，在整个数仓里很难实现。Hologres是采用SSD设计，固态硬盘支持更好的随机读写能力。这让我们设计存储架构的时可以抛开过去必须依赖于这种扫描场景，去设计整个存储的数据结构。Hologres可以行存也可以列存，分别适应不同的场景，同时也采用log structured merge tree 的方式。支持高吞吐数据的写入和更新的场景。第三个是CPU多核化，CUP的主频已经不会有本质的提升。但是在多核化场景下，如果可以把一CPU内部多个核并行利用起来，就能把CPU资源充分发挥到极致。这就要求对操作系统的底层语言掌握的要比较好，Hologres使用C++实现的数仓。Hologres底层的算子都会用向量化方式重写，尽量发挥多核化并行计算能力，吧计算力发挥到极致。

从下图可以看出，我们在网络上、存储上、计算上、硬件层面有很多改进，这些改进都充分发挥出来，能够做出一个不一样的效果的系统。

人群圈选场景之前提到，既有预计算场景，又有MPP分布式计算场景。使用单一某一个技术往往不太适合，真正落地的时候，希望既有预计算又有分布式计算，要把两个技术更好的整合在一起。比如维度过滤场景就很适合用BITMAP，因为可以在BITMAP上做位图索引。如true和false的场景，购买级别、对什么产品关注等等，这些需要过滤的场景就适合做位图索引。Hologres是支持位图索引的。

第二种是关系运算，关系运算是我们提到的各种数据集之间的交差并，也非常适合位图计算。因为位图计算相当于是0和1之间，做很多与或差的操作，而且是并行操作，效率也是非常高的。

精确去重是BITMAP天生就具备的能力，因为位图在构建时，就通过下标位，就唯一确定了ID。通过不同下标位之间上面一的值的简单累加，就可以很快计算出精确去重的值是多少。这几乎是把一个O(N)的问题变成O(1)的场景，效果也非常明显。所以在做人群圈选场景里面，预计算是很重要的技术。Hologres支持RoaringBitmap数据类型，高效率实现Bitmap的交叉并计算。

上文提到预计算是灵活性不足，需要通过分布式计算把计算力发挥出来，就用到了Hologres的向量化执行引擎。对MaxCompute数据外表直接加速，包括MaxCompute数据同步到Hologres里，是会比MaxCompute同步到其它数据源性能提高10倍已上。

典型架构图

典型架构图如下，数据源基本是通过埋点数据，通过消息中间件kafka，第一件时间投递到Flink，做一次轻量级数据加工，包括数据治理的修正，数据轻度汇总，数据维度拉宽。其中维度关联是一个很重要的场景，真正的埋点数据都是记录某些ID，这些ID都要转换成有属性意义的维度信息。第一件事就是做维度拉宽，这是就可以使用Hologres的行存表，维度关联时，基本是通过主键去关联的，使用Hologres的行存表，可以存几亿几十亿的维度信息。这些信息可以实时的被更新。加工的结果集会写到kafka里面，因为并不是一次加工，可能是加工几个循环。通过kafka做消息驱动的方式，在Flink里面做几次加工，加工的结果基本上双写的场景会比较多，一部分实时写入Hologres，另一部分以批量方式写到MaxCompute里面。离线数仓到实时数仓是一个很好的数据修正的场景，数据是一定会被修正的，所以会有大量通过离线数仓对实时数仓进行修正的场景，包括标签加工也是典型的离线数仓来补充实时数仓的场景。所以一些行为是需要通过离线数仓加工好之后，把数据同步到实时数仓里。但有另外一些属性，是跟当下决策有关系的。这些是可以直接写到实时数仓Hologres里。所以可以把标签分为离线和实时两部分，实时写到Hologres，离线通过MaxCompute加工后同步到Hologres。

在对外提供数据服务是，有几种方式。建议的方式是，对外提供服务时，加一个网关，网关服务里面会做很多限流、熔断等等，这也是能提高数据服务稳定性的一个很好的帮助。如果是对内使用交互式分析的长治，可以直接通过JDBC的方式连接Hologres，如果是一个在线应用，建议通过API网关连接到Hologres。

数据结构层

离线数仓加工两张表，一个是用户基础属性表，记录一些用户属性，性别城市年龄等。一个是交易明细表，记录某个人在某一天针对某个商品买过多少，看过多少，收藏多少等。这些通过离线数仓加工好后，数据导入Hologres。在通过配置把表列描述信息以人类可读的方式描述出来，再配置相关属性标签。把标签上线后，广告主会通过交互界面进行配置筛选。这种筛选背后都是翻译成各种SQL语句，其实就是个各种SQL表达式。真正把查询下发到底层引擎。那下发时底层引擎该如何建表呢？

宽表模式

每行描述一个用户的标签组合，每个key是一列，每一行对应value。

列不建议超过300列，列多会降低实时写入的性能。分为热点标签和非热点标签

热点标签独立为列，具备明确的数据类型，可以针对性设计索引，对查询友好

非热点标签，通过数组类型和JSON支持，适合动态更新，但索引不是最优，可扩展性更好

适应场景：维度属性数量较低；实时写入频繁；更新以人的单位

优势：开发简单快速上线

方案描述：

用户数据：例如user_tags表，宽表

行为数据：例如shop_behavior表，事实表

更新时，可以实时、批量更新不同的列

案例

-------------------- 用户标签维度表 ---------------------begin;--3个热点标签字段（text、integer、boolean类型），2个扩展标签字段（text[]类型和JSON类型）create table user_tags(  user_id text not null primary key,  city_id text,  consume_level integer,  marriaged boolean,  tag_array text[],  tag_json json);call set_table_property('user_tags', 'orientation', 'column');-- 分布列call set_table_property('user_tags', 'distribution_key', 'user_id');-- text类型设置bitmap索引call set_table_property('user_tags', 'bitmap_columns', 'city_id,tag_array');-- 热点标签，这是字典编码call set_table_property('user_tags', 'dictionary_encoding_columns', ‘city_id:auto’);commit;

-------------------- 用户行为事实表 ---------------------begin;create table shop_behavior(  user_id text not null,  shop_id text not null,  pv_cnt integer,  trd_amt integer,  ds integer not null);call set_table_property('shop_behavior', 'orientation', 'column');call set_table_property('shop_behavior', 'distribution_key', 'user_id');--- 聚合键 对group by等运算更加友好call set_table_property('shop_behavior', 'clustering_key', 'ds,shop_id');Commit；

窄表模式

将user_tag表转为窄表，每一个标签一行记录，标签名为一列，标签值为一列。

数据类型均退化为字符串类型，适合标签不固定，标签稀疏，允许牺牲部分性能但提高标签定义的灵活度。支持几十到几十万不同标签规模。

适应场景：维度属性数量高；更新以标签的单位

优势：开发简单快速上线

案例

本文为阿里云原创内容，未经允许不得转载。