特征平台升级实践

背景

当前团队内有多个围绕着“特征”建立的系统,有特征系统、用户画像系统、分析门户等。在业务发展初期,这些产品都是紧贴业务的发展而建设的,系统功能模块和沉淀下来的特征也是基于运营活动、业务单元而垂直开发的,给后期带来了巨大的维护和开发成本。

而且随着数据的规模和系统功能复杂度的大幅增加,现有系统架构已经不能高效支撑运营和各业务方的使用,因此需要对现有的产品和技术架构做一次升级。

本文从分析现状出发,围绕着平台的价值属性(工具、内容)来解构当前的根本问题,找准升级方向,最后通过调整产品架构、优化或者重构技术架构来完成这次升级。

现状

用户对平台的反馈主要集中在两方面:

  1. 对接流程繁琐,需求开发周期长;
  2. 数据很难找,找到了也不敢用,用了也提心吊胆。

效率问题

从几个case来看下当前的效率问题。

当前的产品架构:

当前产品架构

当前的系统虽然可以满足功能需求,但是在架构上没统一组织起来。模块间的耦合性太强,且特征的元数据都没有被统一管理起来。这些问题都会使上线周期长、排查问题艰难,产品的扩展性也不是很好。

特征接入过程,以画像系统为例:

特征接入

当运营需要使用一个特征时,需要和多个团队对接,接入特征耗时基本都是以周为单位的,而理论上是可以达到以小时为单位的。

业务方认为人群判定不符合需求时,排查问题的流程:

排查问题

事后排查,并且都需要画像团队产品、RD介入,如果是数据源的问题还需要业务方去推动数据生产方优化。当涉及的团队非常多时,排查和解决问题的耗时对运营来说简直是不可想象的,特别是重大运营策略使用的数据有问题时,甚至还会造成资产上的损失。经过总结分析,当前遇到的大多问题都是可以通过技术的手段来自动化定位、告警、提前解决的。

内容问题

当前大多特征接入都是以ft、个人为单位的,带来各种不同的烟囱体系,业务方如果想要夸业务域使用数据也是比较困难的。当特征规模增大以后,数据口径对不齐,特征质量参差不齐的让数据使用方提心掉胆,质量问题也难以追溯的问题就非常突出了。

总结

从当前现状和用户的反馈来看,可以看出当前平台面临的两个根本问题:

  1. 效率 对用户来说,使用平台过程繁琐,流程也过长;平台方来说,重复开发较多;
  2. 内容 当前平台只是做为工具来对外提供一些功能,没有形成有效的治理数据体系,严重不符合用户的期望。

从数据生产侧和数据消费两个角度可以总结以下痛点:

数据消费侧:

  1. 接入特征周期过长
  2. 信息不完整,使用上容易出错,经常重复沟通,效率低;
  3. 对大规模的特征没有建立良好的规范体系,运营在使用时效率低,一些无关的特征会形成很大的噪音;
  4. 没有质量保障,都是在发生事故时才能感知到数据异常,且追踪问题耗时耗力。

数据生产侧:

  1. 有多套功能类似的系统,开发和维护成本过大;
  2. 系统之间的功能存在耦合,且没有被统一整合起来,一次改动可能会涉及到多个系统,排查问题艰难;
  3. 特征缺少统一规范约束,经常会造成重复开发,数据冗余,且同词不同义的情景下沟通成本过大;
  4. 没有一个统一的数据质量管控体系,不能做到事前通知,收到用户较多的负面反馈;
  5. 数据冗余会造成计算和存储资源的浪费。

如何做

定位

除了现有的问题,还需要考虑以下几个方面:

平台的价值属性定位

平台在之前的定位基本上只是一个工具属性,仅仅是为了提高运营、算法同学的工作效率,虽然接入大量的特征,但是并没有很好的管理和利用起来,这样已经不满足当前的业务形式了。因此为了让平台跟上业务的需求,还需要提高平台在内容方面的价值。

特征来源

当前平台内的特征大多都是业务方接入近来的,少部分是特征挖掘组输出的。但是公司内的各个数仓团队在实际上还沉淀了大量的指标(特征),这部分特征如果能直接接入到我们平台中的话,会极大的丰富我们平台的数据内容。

团队合作

当前一个特征需求需要业务方自己去跨团队来推动完成,效率是非常低的,如果我们能和数据、算法团队建立良好的合作机制,打造一个一站式特征需求平台,将会极大提高业务方的工作效率。但这就涉及到我们平台如何向数据、算法团队反馈收益。

特征平台面向的用户有分析师、算法工程师、研发工程师,支持的上层应用有用户画像系统、智能模型服务,图计算平台等。

因此我们平台的最终定位是大数据特征平台是数据平台体系下的数据应用,目标是建设公司范围内口径统一,促进数据共享,降低数据使用门槛,解决数据消费侧和生产侧面临的核心问题。整个平台的工作主要分为数据规范、数据服务、数据质量、数据运营四个部分。

加强与数据、算法团队的合作,尽量打造一个一站式的特征、画像平台,不仅要大幅提高业务方的工作效率,还需要为其提供高质量的特征数据,让用户可以大胆、放心、高效的使用我们平台上的任何功能和数据。

目标拆解

根据前面的分析,我们这次需要做的事情可以分解为三个部分,数据治理、产品架构、技术架构,也就是以下几点:

  1. 通过数据治理来制定数据规范、保证数据质量;
  2. 然后再通过调整产品架构清晰划分每个产品的功能边界,提高数据生产方和数据消费方的工作效率;
  3. 最后再以设计良好的技术架构,保证产品功能落地,性能上高效的支撑系统运转。

数据治理

平台内当前的所有数据都是由各个数仓团队的数据工程师(DE)、业务方RD、算法工程师提供的特征,然后再以产品的形式提供给用户使用,不涉及到数据清洗和复杂的数据建模。因此我们需要解决的问题主要是:

  1. 制定一套业务标准来规范特征的接入、使用、上下线;
  2. 建立特征的质量监控体系,并且能够做到做持续监控,事前告警,事后追踪复盘。

业务标准

业务标准主要针对的是特征的管理过程,主要目的是使各业务方对特征的认知达成一致。标准的定义主要参考的是数仓团队制定的标准,后期的更新迭代也需要尽量要与数仓团队保持一致。

口径规范

口径规范的目的主要是为了消除特征的二义性,影响的主要是接入、生产环节。使用基础数仓团队已经沉淀出的特征规范体系,并且保持一致的一个好处是可以将其沉淀出的大量特征快速接入到我们平台上。主要解决了以下几个问题:

  1. 口径不一致的问题,例如:同名不同义;
  2. 重复计算和接入的问题,节省存储和计算资源,并且也节省了用户等待需求完成时间和开发人力。

将一个特征拆分为业务板块、数据域、业务过程、原子指标、实体类型等,多个特征也可以通过四则运算生成新的复合特征。拆解过程如下图:

指标拆解过程

业务板块

指的是事业部,可能有由多个业务线组成,如网约车,包含专车、快车等多个业务线。

数据域

业务过程的抽象集合,例如,交易域、流量域。

业务过程

是指企业的企业活动事件,业务过程是一个不可拆分的事件,例如交易过程中的发单、完单事件。

原子指标

基于某一业务时间行为下的度量,是业务定义中不可再拆分的指标(比率等指标除外),具有明确业务含义和业务完整定义的名词。例如 发单(业务过程)+ 数量(度量 )

实体类型

指的是特征依附的实体,例如乘客、司机、商家、订单、骑手等。

特征

衍生特征指的是普通特征,例如乘客历史截止到当日网约车完单数。复合特征指的是两个或多个特征经过四则运算生成的一个新型特征,例如:乘客历史累计网约车完单数 (实时) = 乘客历史截止到当日网约车完单数 (离线) + 乘客当日网约车完单数 (实时)

特征分类

业务分类的目的是帮助平台的用户更快的找到所需要的特征,影响的主要是应用环节。通过建立三个并行的分类体系,业务分类、内容属性、活动主题,可以使用户可以更加方便的找到所需数据:

  1. 业务分类 其实就是指标拆解的那个过程,可以换一种用户更容易看懂的说法来描述
  2. 内容属性分类 这是特征固有的属性,与业务线、活动主题无关,例如:基础属性(性别、年龄),行为特征(打车次数);
  3. 活动主题 运营在制定实际的活动策略时,会跨业务板块、数据域去使用特征,并且活动策略的目的可以分为多种主题,例如:拉新、增长、沉默召回等等。同时一个特征也可能会适用于多种主题,因此特征和主题是多对多的关系。主题的定义是与业务系统、活动策略紧密相关的,特征归属的主题可以适当的下放给用户来设置。

建立质量体系

通过建立特征的质量体系,量化特征的质量,会影响特征的全部环节。主要目的有以下几点:

  1. 接入前评估,保证接入到我们平台的特征质量都是合格的;
  2. 接入后持续监控,当特征质量发生波动时,给相关责任人发出告警;如果低于某个阈值,阻断后续使用,并向所有特征使用方发出告警,从而可以联合用户推动数据生产方改善数据质量;
  3. 保证数据一致性,在不同的应用场景下,存储引擎也会不同,因此还需要监控不同的数据库中数据是否一致;
  4. 事后复盘,完善的监控体系详细的记录与事故相关的所有信息,为事后快速定位问题提供有力的依据;
  5. 监控长时间不用的特征 可将其下线或者冷藏,节省资源。冷藏还可以再次快速启用,不需要重复开发。

通过以上几点也可以极大的提升我们平台的口碑。

根据监控方式的不同,将质量监控分为以下类型:

基础质量评估

会覆盖大部分数据,评估结果代表着数据的健康程度。监控指标有:主键重复、枚举值、空值,表行数,存储文件大小,数据源的监控等。

生产任务监控

生产任务的健康程度也会影响到数据的健康,因此也需要健康它的运行情况。监控指标有:启动时间点,运行时长,是否发生异常。

数据一致性

在不同的应用场景下,数据的存储引擎也会不同,同一份数据可能会存储到多个数据源中,因此还需要想办法核对数据的一致性。例如:画像系统中,离线数据会同时存储在hive、es、fusion(kv数据库);根据更新周期的不同,特征也分为实时(存储在redis)和离线(存储在hive),它们的计算口径虽然相同但数据来源不同,因此通过校验它们的值是否一致,也可以监控口径是否发生变化。

数据运营

主动的向外输出,提升平台的知名度、用户的活跃度、特征使用量。具体措施有:

  1. 收集优秀案例,并向用户展示特征的用途、玩法;
  2. 向用户推荐可能想要使用的特征,免去频繁查找之苦;
  3. 通过监控体系,根据使用次数、相关度、特征质量综合排序,将高质量的特征优先推给用户,并且主动下线、优化质量不好的特征。

产品架构

当前的系统虽然可以满足功能需求,但是在架构上没统一组织起来。模块间的耦合性太强,且特征的元数据都没有被统一管理起来。这些问题都会使上线周期长、排查问题艰难,产品的扩展性也不是很好。

顶层架构

本次调整,各个产品对外的主体功能不会发生改变,主要是根据产品的特性进行模块划分和分层,将具有相同特性的项目划分成一个大的产品,再根据每个产品的功能和依赖关系进行分层。在划分后,每个产品都有了明确的定位,只需要专注于自己的业务逻辑。调整后的结构为:

产品顶层架构图

特征平台

将所有与特征管理、生产、监控的聚合到特征平台上,向上屏蔽掉了与特征相关的所有细节,简化了上层应用系统的接入方式。

画像系统

将与特征接入、生产相关的功能剥离到特征平台,只通过特征平台使用特征,主体功能不变。主体功能有人群筛选、人群分组、人群下载。

算法模型系统

将与算法模型相关的模块抽象成一个系统,主要负责模型的上下线,版本迭代。

特征平台

相比前两篇文档,本次文档主要只是将功能模块依据这次的规划重新组织了一下。落实到技术架构上变化很小。

模块划分的分析过程就不再详述了,下面是这次重新划分后的架构。

特征平台架构图

画像系统

多租户示意图

当前所有用户是共用一个大空间的,接入的几千个特征和用户创建的人群都是堆在一起的,这会造成以下几个问题:

  1. 信息干扰;
  2. 因为功能需要,所有特征都是存储在同一个ES索引,生成速度慢;
  3. 权限控制较为复杂。

因此将画像系统按照业务线、FT为单位划分成多个空间,每个空间只包含与空间主题相关的特征、操作数据。拆分后的优势:

  1. 减少信息干扰,让用户更加聚焦;
  2. 可以提高数据处理的并行度,加快数据处理速度;
  3. 逻辑上隔离,各个团队之间的数据不会相互影响。

评论