spark 宽表 mysql_扒一扒某厂的新零售用户画像系统大宽表 | 知识整理

扒一扒某厂如何构建新零售领域中用户画像的大宽表。字数不多，就600字。

用户画像系统的维度表构建

画像大维表是一个画像系统所支持的所有标签的元数据，一个体系完整的画像设计范围广，一般是由很多团队共同构建。因此构建的时候会有多方参与来形成子画像，需要给每一个子画像分配唯一的ID，标签前缀，存储位置及表信息。

子画像又可以分为宽表和纵表，是两种不同的标准：

维度宽表示例，有value的概念：

维度纵表示例，没有value的概念：

实时用户画像系统的宽表构建

用户画像大宽表需要拉通大维表中的所有子画像，形成统一的的大宽表。

大宽表建设的关键在于Spark中对RDD的CoGrouped，对所有加工好的子画像进行整合：所有维度宽表及用户数据拉通整合成结构一致的大宽表；而由于维度纵表多变，不具备value，不适合将其整合到大宽表列中，会造成列数过多、数据稀疏、schema易变，所以将其数据以空格整合成一列，追加至大宽表最后。

子画像加工：

以商家用户行为子树为例，用户行为数据通过数据链路上报、清洗加工，存储至数仓DWS层。按画像接入标准从DWS加工出子画像的标签维表数据和用户打标数据用于构建大宽表和用户画像数据。

CoGrouped：

按UserKey类型分类子画像，分别做id映射及CoGrouped，形成大宽表。通过配置文件按序加载加工好的子画像集合，依次加载schema，按schema依次加载各子画像data组成Rdd集合。对RDD集合做以用户id为key的CoGrouped，遍历CoGrouped结果集，对缺失的内容(缺失值为子画像)做空值填补，拉通大宽表。

上一步每个UserKey类型的处理结果都会形成大宽表数据，对所有结果集做CoGrouped，拉通不同UserKeyType类型的大宽表，对缺失的数据(缺失值为某KeyType画像)做空值填补，形成最终的大宽表画像数据，存储至HDFS。

最后基于这个大宽表利用OLAP引擎(例如社区的clickhouse等)进行索引构建和数据存储。并对新画像数据规模做合法校验，防止数据污染。用户画像大宽表使用OLAP引擎分析，用户画像大维表使用PostgreSql查询分析。

支撑某厂新零售百亿数据画像系统的服务中台其实包含离线和实时两部分，今天主要分享讨论的是实时模块下用户画像大宽表的构建，有机会再讨论构建之后的OLAP分析引擎或当下实时数仓的构建或离线的部分，欢迎留言讨论，感谢点赞关注。