# 画像标签的基本架构梳理

By [zeck](https://paragraph.com/@qgstudio) · 2022-05-07

---

起因
--

四月份换了岗位，从运维转到了大数据平台开发，整个知识体系都要重新梳理。幸好之前学习的大数据知识还存在，对于一些组件还算熟悉，这篇文章主要梳理一下当前我司画像标签系统的基本架构，由于还在熟悉中，一些细节会逐渐补充。

为什么需要画像标签系统
-----------

作为一家金融公司，通过画像标签系统可以构建对于不同客户的区分，提高营销活动目标人群的准确性。巴拉巴拉.

数据流向
----

一般而言，画像标签系统都依据公司的大数据平台计算能力来构建，在数据仓库完成基本的标签计算，然后讲数据推送到指定的存储系统，数据流向如下：

![](https://storage.googleapis.com/papyrus_images/b2d1eacd8d1653dc90376ab16ece7bdce2ecb0966d6d59ccdbaa7672f44696c8.png)

一个完整的画像标签系统数据流向如上，从数据源抽取需要的数据到大数据平台进行加工，加工完成后推送到存储平台。

但是，一般而言，但公司决定做画像标签系统的时候，大数据的仓库应该基本构建完成，构建画像标签的数据之间从仓库的基础模式里面获取就可以。抽取，我们公司的调度改了一下DataX拿来使用。

这个的设计难点有两个：

**标签存在hive在里面应该用哪种模式？**

标签存储
----

画像标签有一个非常大的特点就是每个标签的更新时间是分开，一个客户会有成千上百个标签，每个标签的依赖的基础数据不一样，计算的时间也会不一样。在一开始的版本，是在Hive 使用多分区，每个标签作为时间的下级标签，这样更新某个用户的数据的时候只需要做到更新单独的分区既可以，但是这样做的带来的一个问题，但是我们想查看某个用的所有标签的时候，会扫描几千个分区，如果再乘以一个时间，会拖累hive的metastore的性能。

后面经过调研，选择Icebery

[https://iceberg.apache.org/](https://iceberg.apache.org/)

选择iceberg有一下理由

1.  iceberg的表结构是松散的
    
2.  iceberg支持ACID
    
3.  icbery的元数据不依赖hive的metastore，不会对metaster造成压力查询
    

基本的画像架构就变成：

![](https://storage.googleapis.com/papyrus_images/03b23706bbc43f4fe6af1b0a51d2fde4c71200cde3711e2a291b33dc3a7d16ac.png)

Spark负责数据的加工和推送一份最新的数据到ES，由于目前ES存储有限，只保留了一份最新的用户数据，如果画像系统里面需要查询其他的历史，我们使用了trino（presto）来解决这个问题。

虽然基本架构是看起来是没有文档，但是目前还一些细节上还存很多问题，包括数据同步慢、前后端没有分离、上线不够自动化、以及数据接口非常多的个性化，这些是我转岗之后要解决的问题，也是接下来一个月的任务。

暂时先写这么多，最近在学习Vue，一个老运维的转型之路。

---

*Originally published on [zeck](https://paragraph.com/@qgstudio/L8PCk7lIBY3TrOrVAmW7)*