架构师手记 15 个性化标签系统的需求分析

分析很重要，比如美人脸的标准就被量化了

个性化标签系统 需求分析文档

带墨镜的 番茄哥

文档修订记录

版本编号 修订时间 修订说明 作者 审核 第 2 页 共 8 页

目 录

文档修订记录 ................................................................................................................................................. 2 1. 前言 ......................................................................................................................................................... 4

1.1. 文档说明 .......................................................................................................................4 1.2. 目标读者 .......................................................................................................................4

2. 难点及对策 ............................................................................................................................................. 5

2.1. 数据量巨大 ...................................................................................................................5 2.2. 标签和数据格式的依赖关系 .......................................................................................5 2.3. 标签的计算逻辑过于灵活 ...........................................................................................5 2.4. 标签计算会对上层标签和目标用户群的获取产生影响 ...........................................6 2.5. 标签计算资源的浪费 ...................................................................................................6 2.6. 标签的主体 ...................................................................................................................6 2.7. 标签的定义和实现分离 ...............................................................................................6 2.8. 目标用户群的计算速度较慢，另外，目标用户群数据较大，无法实时查询 .......7 2.9. 与其它系统的交互 .......................................................................................................7 2.10. 用户行为数据抽取的问题 ...........................................................................................7 2.11. 计算任务有次序依赖关系 ...........................................................................................8

第 3 页 共 8 页

1. 前言

1.1. 文档说明

此文档是番茄版的个性化标签系统的需求分析文档。

此文档将会是架构师手记—架构实战中的一个系列。为什么说将会呢？因为我不一定能把这个系统写完。

需求分析，其实应该做两件事：  分析并抽象出系统的功能点

 纠正业务用户的错误和遗忘功能，如果有 很遗憾，读者将看不到以上内容，因为我懒。

这篇文档中将讲述个性化标签系统面对的难点，以及对应的思考和对策。

1.2. 目标读者

架构师、程序员、测试人员、热爱妹子的猥琐大叔、看金鱼的怪叔叔、不可救药的腐女、屌丝、宅基、各种非人类、外星生命体等爱好架构设计的卖萌的优秀青年。

第 4 页 共 8 页

2. 难点及对策

2.1. 数据量巨大

难点：标签计算涉及到大量的数据，数据源来自于各个业务系统，涵盖用户网站访问日志、用户APP访问日志、用户消费历史、用户个人信息、用户购物车记录、用户收藏记录等等。如果在业务系统的数据库中直接计算标签，会影响业务系统性能；另外，很多计算都依赖数据的JOIN操作，如果数据分散在不同的数据源，不易支持分布式JOIN。所以这些数据需要汇聚在一个支持海量数据存储的数据仓库中，供标签计算使用。海量数据的计算需要消耗很多的计算资源，所以需要一个支持分布式计算的系统来承担标签的计算工作。 对策：使用Kettle、HIVE、Hadoop解决数据抽取、数据存储和数据计算问题。

引申问题：这些ETL、Hadoop Job、HIVE SQL执行等后台任务如何调度？如何监控？如何建立故障告警和故障处置的机制？ 引申问题的对策：需要通过设计和开发来提供对应的功能。

2.2. 标签和数据格式的依赖关系

难点：标签需要依赖数据计算，每类数据都有自己的表定义，当某个表定义需要修改时，如何找到会影响的标签？特别是当标签足够多的时候，表定义的修改牵一发动全身，必须先知道影响范围，再做打算。

对策：需要通过设计和开发来提供对应的功能。

2.3. 标签的计算逻辑过于灵活

难点：每个标签都可以具有不同的属性，使用不同的数据表，使用不同的算法，计算结果存放在不同表中。系统如何足够灵活可以支持上面的需求？

对策：替标签定义标签类型，针对每类标签，提供对应的插件来解释属性定义、执行计算和存储结果。 这是标签系统里面最复杂的地方，如何足够灵活？ 当然，看完哥的设计思路，你会觉得一点也不复杂，其实你也能想到。哥的成就感就来自于你的这种感觉。 复杂逻辑简单化。

第 5 页 共 8 页

2.4. 标签计算会对上层标签和目标用户群的获取产生影响

难点：标签在计算过程需要清空已有结果集（即目标用户群），重新生成新的结果集。有部分标签是每天定时计算的，如果用户正在获取目标用户群，就会发生错误。同样，某些标签可以依赖于其它标签的结果集进行二次计算，比如“痴女”依赖“女性”的结果集。当“痴女”正在计算时，“女性”标签正好到了每天定时的点了，那么“痴女”的计算就会产生异常。

对策：给所有计算完成的结果集都打上时间戳，对结果集的访问之前，必须先查询目前可用的最新结果集是哪个，然后依赖这个最新的结果集进行计算。另外，标签开始计算之前，不能删除已有结果集。已有结果集可以设置有效期。结果集的有效期可以设置成目前系统中最复杂的计算需要消耗的时间。比如说，当前系统中最复杂的计算最多需要2天就可以完成，这就意味着，假如有一个任务使用了某个结果集，最多两天就使用完毕了。然后这个结果集就可以被删除了，新的任务可以使用这个结果集的最新版。

超过有效期的结果集由系统定时删除。当然，系统需要判断，如果该结果集是最新版，已经超过了有效期，则不能删除，还需要再延长有效期2天。这是因为系统故障时，会导致标签的计算中断。为了保证前端访问不受影响，则不能删除最新版。 这特么的是血泪教训啊。某群兄弟不听哥的劝，事发时被业务人员逼迫蹂躏得那个惨啊，内伤吐血。哥看着他们的鲜血，流下同情的眼泪，然后在他们的伤口上撒了一把盐，“我当初是怎么说的，哇哈哈~~~~~” 不犯错就不知道小心。有些错误，正是因为犯过，才会刻骨铭心。

2.5. 标签计算资源的浪费

难点：许多标签的计算可能会有相似的逻辑，比如“少女”“美少女”“失足少女”、“青年”“中年”“老年”。如果每个标签都从基本的用户信息表开始计算，会造成系统大量的重复计算，造成浪费。

对策：把用户的基础信息抽出来做成基础表，比如用户信息基础表包括“性别、年龄、地域、婚姻状态、账户余额”等信息，用户消费行为基础表包括“本月下单数，本月下单金额，三月内下单数，三月内下单金额”等。这些基础表每天计算一次，标签的计算需要尽量依赖于这些基础表，减少重复计算。

2.6. 标签的主体

讨论：虽然我们一直讨论的都是给人打标签，其实在行业应用中，商品可以打标签，广告可以打标签，其它很多东西都可以打标签。所以这里提出一个主体的概念，主体就是打标签的对象，这个主体不一定是人。

对策：考虑到将来的扩展，本系统需要支持多种标签的主体。

2.7. 标签的定义和实现分离

难点：不同的用户对标签的关注度。比如业务用户只关心标签的业务含义，IT用户除了关心标签的业务含义，还需要关心它的配置和实现的信息。如果把所有信息混合在一起展示给用户，会使

第 6 页 共 8 页

得业务用户基本上不愿意用本系统，一些原本可以让他们自助的工作，比如目标用户群的下载或导入，都需要IT人员来执行。 对策：把标签的定义（业务人员能看懂的）和标签的IT配置信息（用于计算）分离。从设计上区分业务人员的界面和IT配置人员的界面，并用权限控制不同角色能访问的界面。

2.8. 目标用户群的计算速度较慢，另外，目标用户群数据较大，无法实时

查询

讨论：由于标签计算涉及的数据量大，算法可能很复杂，导致计算过程较长，也无法满足目标用户群实时查询的需求。

对策：本系统的定位就是以批处理的方式负责生成目标用户群数据，并不提供实时查询的功能。实时查询的需求由其它系统提供。 这实际上是个性化标签系统的定位问题。

2.9. 与其它系统的交互

难点：有很多其它系统都需要以不同的方式来获取目标用户群的数据，如何最小化未来不断变更的集成接口开发工作？ 对策：本系统只提供唯一并且统一的文件交互接口，对于其他系统而言，需要把请求参数按规定格式写成文件，上传到指定FTP服务器指定目录下，本系统收到请求后，会在标签计算完成后，把目标用户群数据按规定格式，上传到指定FTP服务器指定目录下。 在这个虚构的场景中，我们完全有权力说，我们只提供一种而且就这一种接口。

2.10. 用户行为数据抽取的问题

这个难点只适应部分公司。

难点：某些公司的系统是由很多松耦合的服务组合的。服务相互之间并不清楚对方的实现细节。每个服务都自己写日志。每个服务的日志都是单独的数据存储，而且日志格式不同。这就造成了一个潜在的问题，一个单一的用户请求，会请求多个服务，造成多个服务记日志。所以需要聚合多个服务的日志，才能组成一个完整的用户日志。所以需要有人专门分析各个数据源，用户请求涉及到数据源（各种服务的日志），理解日志的格式，然后做JOIN，把这些分布在各个数据源的行为日志重新构成一个完整的用户请求行为。绝大多数用户行为相关的标签，都需要根据用户行为日志来计算。所以这会是一个无法避免的问题。 从根本上来说，SOA架构需要考虑实现统一用户日志的机制，统一日志格式，合并不同数据源的日志用于后续分析。但这非一日之功。而且很多公司并没有认识到统一用户日志的重要性。因为开发和分析是有矛盾的，如果想要分析人员过的爽，开发人员的活就重一些；如果想要开发人员过的爽，分析人员就累一些。这是平衡的问题。而一般的公司都优先于系统功能的开发，分析的功能优先级低。（很不幸，个性化标签系统常常被归类成分析系统） 对策：如果没有现成的统一用户日志，需要仔细评估自己实现合并不同数据源的行为日志的工作量，然后伺机而动。无非三种：不做，做，被强迫做。关键是“被强迫做”时，你如何控制风险？

第 7 页 共 8 页

2.11. 计算任务有次序依赖关系

难点：部分标签是依赖基础表或其它标签的计算结果来计算。所以它们的计算必须要等到基础表和其它标签算完了，才能执行。 对策：需要设计和实现一个计算任务的调度系统来解决这个问题。

3. 写在后面的话

其实第二章的内容都是在做一些架构决策。

其实架构设计的写法一直有两个流派，一派认为架构决策就是架构设计的内容，另一派认为架构设计应该要划分系统边界、模块、交互等。然后出现了第三派，他们很中立地觉得架构设计要包含这两类内容。

哥一向是第三派的粉，但常常变成第二派，十分不认同第一派。 读者可以自己选择阵营。

第 8 页 共 8 页