前言

本文介绍一个ClickHouse应用案例—用户画像系统。将从用户画像的需求出发，结合ClickHouse的特点，设计用户画像的系统架构，最终实现用户画像系统。

本案例以单机版ClickHouse为基础，ClickHouse超强的单机性能，使得用户画像系统能够轻松承担千万级别的用户画像业务。对于很多中小型企业来说，单机版的ClickHouse已经足以满足业务需求。一个设计良好的ClickHouse表，即使是单机的，也能支撑数以亿计的数据量。

用户画像概述

用户画像系统介绍

用户画像是推荐系统的一种实现，通过用户的历史行为分析用户特征，与商品或者活动的特征对应后，即可将商品或活动推荐给对应用户，这些用户特征组成的集合就称为用户画像。用户画像具备可解释性高、实现简单、计算简单等特征，成为推荐系统常用的实现方式，广泛应用于商品推荐、活动营销等领域。

下图展示了用户画像的原理。绘制用户画像一般分为两个阶段：分析和运营。

分析阶段

• 分析阶段是将用户在数据库中的行为进行分析和加工，得出多种特征。
• 这一阶段完成后得到的是所有用户的特征库，基于这些特征可以指导后续运营阶段的各种业务。
• 分析阶段一般每天进行一次分析，也就是说每天刷新一次特征库。分析阶段的技术特征是数据量大，由于原始数据来源于业务数据库，因此存在大量的Join操作。

运营阶段

• 运营阶段是由业务方驱动的，需要推广某个产品时，可以依据该产品的目标人群，确定这些目标人群的特征，再从特征库中筛选出符合条件的用户，进行进一步的推广运营。
• 除了应用于商品推广，用户画像系统还可以应用于会员运营、活动运营等多个领域。
• 活动运营阶段的技术特征是业务随时都会发生，业务方希望以最短的时间得出结果，也就是说，运营阶段即席查询的需求比较强。
• 由于该系统是公司内部人员使用的，因此并发量有限，不会出现淘宝、京东这类面向消费者的高并发场景。总体来看，运营阶段就是并发有限的即席查询场景。
  

用户画像系统的需求描述

用户画像系统基于用户行为进行推荐，为了实现这个功能，用户画像系统至少具备如下能力。

1. 允许用户配置数据源，将数据从业务数据库导入ClickHouse。
2. 允许用户创建数据清洗逻辑，对导入ClickHouse的原始数据进行加工清洗，生成DW。
3. 允许用户创建、浏览、删除标签定义。
4. 定时根据标签定义对DW进行扫描，筛选出符合条件的用户，对这些用户打上标签。
5. 对用户标签进行适当处理，以支持业务的即席查询。
6. 输入标签ID，输出标签下所有的用户。
7. 输入一组标签ID，输出同时满足这些标签的用户（标签圈人）。
   

用户画像系统的需求分析

1. 用户画像系统由三类用户使用——数据工程师、业务建模工程师、业务运营人员。
2. 数据工程师的主要工作是上边的第1、2条需求。
3. 数据工程师主要负责将数据源的原始数据带入到ClickHouse的ODS层，并将其经过清洗生成DW，供业务建模工程师使用。
4. 数据工程师的工作流程是配置数据源→配置清理规则→配置导入任务的运行时间。
5. 业务建模工程师的主要工作是上边的第3～5条需求。
6. 业务建模工程师的职责是将标签输出到即席查询表中供业务运营人员使用。
7. 业务建模工程师的工作流程是创建标签定义→配置即席查询表输入脚本→配置标签创建任务运行时间。
8. 业务运营人员的主要工作是上边的第6、7条需求。
9. 数据工程师和业务建模工程师的技能重合度较高，在实际业务中，可能是同一个人担任两个角色，在设计功能时将这两个角色的功能合并。
   

用户画像系统的架构

用户画像架构由业务系统和底层数据引擎组成，架构图如下，有两个功能入口：运营系统和分析系统。
运营系统供业务运营人员使用，提供共同特征探索和人群圈选的能力。
分析系统供数据工程师和业务建模工程师使用，提供配置任务的入口。

• 该架构的特点是由ClickHouse负责所有的计算，由业务系统程序负责启动ClickHouse的计算过程。
• ClickHouse的数据清洗、变换、数据导入等流程都通过ClickHouse提供的SQL语句实现，相关的SQL语句由数据工程师和业务建模工程师编写，并保存在业务系统中，由业务系统的定时调度机制在每天固定时间启动SQL，开始流程。
  

关键技术实现（Clickhouse SQL）

分析阶段

分析阶段的目标是将用户行为通过一系列的操作，生成即席查询表供业务运营人员使用。
业务数据接入

• 业务数据接入指将业务数据库的代码导入ClickHouse的ODS层。这个过程可以直接使用ClickHouse提供的集成表引擎实现。
• 首先在ClickHouse中创建外部的PostgreSQL表，接着在ClickHouse的ODS层中创建目标表，最后在执行时运行INSERT INTO xxx SELECT语句实现数据导入。下面的代码展示了一个使用ClickHouse实现数据导入用户表的实例。

• 当任务初始化时，执行代码中#1～#3的代码，将历史数据导入。之后只需要每天在固定的时间执行#4的代码导入前一天新增的数据。

数据清洗及建模

• 数据清洗及建模的目的是删除ODS层中不符合规范的数据，并生成DW层。

• 这个过程的关键动作是将多张高范式的ODS表进行Join操作，逆规格化到低范式的宽表。

• 下面的代码展示了一个将用户表(user)和支付历史表(payment_history)进行Join操作的并生成DW层的例子。

  
  

  • #1展示了支付历史表的表结构
  • #2展示了初始化DW表的SQL代码，初始化DW代码被语句“AS”分割为两部分，AS之前的是框架代码，可以由模板生成，AS之后的代码需要业务建模工程师依据业务的实际情况编写，并保存到业务数据库，以实现动态创建DW的目的；
  • #3展示了每日定时刷新时执行的SQL语句，可以利用ClickHouse的Replace Table语法实现数据刷新。这部分SQL语句也是由框架代码和用户代码组合而成的。

标签定义

• 构建DW层结束后，即可依据DW层的数据构建标签。标签使用二级标签的定义，二级标签指的是一个标签分为标签名和标签值，例如性别是标签名，男（或女）是性别标签的标签值。一级标签指的是标签仅有一级，例如性别男是一个标签，性别女是另一个标签。

• 使用二级别签的好处是可以将部分指标视为标签进行处理，同时可以减少业务建模工程师的工作量。坏处是对于例如VIP用户、夜猫子、高净值人群等明显只有一级的标签，处理起来会相对复杂。

• 本文对这类一级标签采用标签值名和标签值相同的处理方案，例如标签名和标签值都是夜猫子。下图展示了部分标签示例：

  

打标

• 了解标签的定义后，即可开始对用户进行打标。

• 打标的本质是通过SQL语句将DW表中的数据写入用户标签表。下面的代码展示了用户标签表的定义。

  
  用户标签表即为所有用户统一的特征库，下面的代码展示了几段基于DW打标的示例。
  
  

• 上述代码展示了4个标签的打标方法，打标的本质就是业务建模工程师依据业务需求，按照用户标签表的格式从DW层中筛选出符合条件的用户，写入用户标签表。

• 标签类似于SQL语句，业务建模工程师只需要将标签对应的SQL语句保存到业务系统的标签定义表，业务系统会在每天固定的时刻按照标签定义的SQL语句依次执行。

转换阶段

• 在事务数据库中，业务已经可以通过用户标签表实现各种运营阶段的运营业务。这张表的数据量非常庞大，假设有100万个用户，1000个标签，那么用户标签表中很可能拥有10亿的数据量。

  这个量级一般的事务数据库都无法承受，即使是在ClickHouse中也很庞大，因此还需要进一步加工才可以以低延迟的效果对外提供服务。

• 转换阶段的本质就是将用户标签表的数据使用ClickHouse的位图能力进行重新组织，使用位图的好处是可以使用比较小的存储容量来保存这些数据，同时将运营阶段对用户画像的操作转变为位图的交并补操作。

ClickHouse对位图的交并补操作性能是非常高的，下面的代码展示了将用户标签表进行转换的示例。

转换之后的ads.tag_user_bitmap已经可以支撑业务的即席查询访问了，业务建模工程师的任务也就完成了。

运营阶段

用户画像的一个核心能力就是在运营阶段通过特征快速选择人群，进行精准的营销。

人群圈选
人群圈选的功能是输入一串标签，找出符合标签的人群列表，向其精准营销。

例如，索尼发布了PS5(PlayStation 5)夜间会员服务，该服务让用户可以在每天晚上免费畅玩PS5的所有游戏。

如果推广该服务，那么人群标签可以为夜猫子、高消费人群。

将这两个标签输入用户画像系统，用户画像系统可以迅速得出符合这两类特征的所有人群，代码如下。

人群加减
在部分营销活动中，人群圈选无法满足需求。

例如某公司进行感恩回馈活动，给所有还不是会员的高消费人群赠送一年会员，这类需求需要使用人群加减的能力，即筛选高消费人群，减去会员人群，代码如下。

基于ClickHouse的用户画像系统的优点

架构简单、开发成本低、开发周期快

• 基于ClickHouse的用户画像系统最大的优点就是架构简单。

  对于一些中小型企业来说，只需要安装ClickHouse数据库即可满足所有需求。

• ClickHouse的开发成本低，用户画像系统工作量最大的部分是定义标签。ClickHouse支持使用SQL语句进行标签定义，学习成本低，效率高。

查询速度快

• ClickHouse以查询速度快著称，单机情况下对于千万级别的用户数据量，能做到毫秒级响应。

标签定义灵活

• ClickHouse使用SQL语句进行标签定义，可以灵活定义各类标签。同时，在实际使用中还有一类派生标签，派生标签是基于已有原生标签定义的，例如本文所举的例子，已经有了高消费人群和性别标签，那么可以基于这两个原生标签定义一个名为高消费女性的派生标签。
• 使用ClickHouse构建用户画像系统，可以实时完成对派生标签定义的修改，更好地支撑业务。

运维成本低、架构灵活

• 架构简单，运维成本低，灵活，当数据量非常大超出 Clickhouse JOIN 承受的范围时可以将这些JOIN查询操作下推至 Spark 等大数据组件中