关于人工智能:云音乐FeatureStore建设与实践

图片起源：https://unsplash.com/photos/Z…

作者：卡妙

概述

在机器学习全流程的生命周期中，Feature Store 是连贯 Data 和 Model 之间的桥梁。他通过存储和治理 ML 过程中的数据集和数据管道，缩小特色工程的反复工作，以实现高效率的特色数据开发，缩短模型迭代周期。

从 ML-Ops 到 Feature-Ops

规范的机器学习零碎由 ”数据“、“模型”、“代码” 三个局部组织而成，其别离对应着 “特色工程”、“模型训练”、“模型部署” 三个阶段。他们彼此关联和依赖，并在各自的阶段承当着重要的职责和性能，以实现整个机器学习过程的使命。

随着 AI 利用的疾速倒退，并在人脸识别、广告、搜寻、个性化举荐等畛域有了大规模利用后，人们开始器重 AI 零碎能力的根底建设。各大云平台厂商陆续推出了一些通用的 AI 平台来减速 “模型训练” 和“模型部署”流程，例如：AWS SageMaker、Google Vertex AI、阿里 PAI 等，这块流程和零碎，咱们能够对立称之为 ML-Ops¹。

the extension of the DevOps methodology to include Machine Learning and Data Science assets as first class citizens within the DevOps ecology.

随着 AI 平台的遍及和利用，“模型训练”和 “模型部署” 效率失去了极大的晋升，而 “特色工程” 作为整个机器学习流程的最后步骤，还停留在利用传统的数据开发流程阶段。为了满足机器学习对数据开发的各种定制化要求，AI 畛域逐渐开始摸索针对机器学习场景的数据开发解决方案，于是承接 ML-Ops 的 Feature-Ops 诞生了，业内随之也推出了一系列面向特色工程的零碎，并称之为 Feature Store，例如：Feast、Tecton、AWS SageMaker Feature Store、Databricks Feature Store。

Feature Store 定义

最早提出并明确 Feature Store 的概念，来自 2017 年 Uber 的 Michelangelo Platform²。他形容了 Feature Store 的次要目标是为了在机器学习过程中，促成特色的注册、发现以及复用，并且保障特色数据在离线批处理和在线应用程序读取时的一致性。其可能提供高性能、低提早的数据服务（面向在线的预估场景）和高吞吐、大容量的数据服务（面向离线的训练和批预测场景）以供模型应用。

一个简略而规范的 Feature Store 如下所示：

Music FeatureBox

FeatureBox 解决的问题

在云音乐，咱们通过辨认云音乐算法场景特有的业务问题，打造了云音乐自研的 Feature Store – Music FeatureBox。致力于解决以下问题：

• 特色发现 / 治理 / 复用：没有中心化的治理，不同的算法团队通常无奈复用特色数据，特色工程会占用算法工程师大量的工夫，且还会造成计算资源和存储资源的节约。咱们通过实现特色元数据的注册与中心化治理，来帮忙特色发现 / 治理，以促成特色复用，减速机器学习过程中的特色工程效率。
• 高性能的特色存储和服务：特色数据存储引擎在不同的场景有着齐全不同的利用需要（训练 / 批预估须要扩展性好、存储空间大；实时预估须要低提早、高响应），咱们通过自研不同内核的存储引擎（MDB/RDB/FDB/TDB），并封装逻辑存储层来路由不同的物理存储引擎，在不同的场景应用不同的物理存储引擎来满足个性化的利用要求。
• 模型训练 / 预估应用的特色数据一致性：用于训练和预估的特色数据往往因为不同的数据实现，而产生异构或者不统一，这会导致模型的预估产生偏差。咱们在 Datahub 零碎形象出一层繁多的数据拜访层，将模型和物理存储隔离并解耦。通过对立数据拜访 API 和自动化数据同步工作，来保障训练 / 预估应用的特色数据一致性。
• 特色抽取 & 算子复用：因为计算的环境和数据上下文有所不同，通常模型的离线训练和在线预估会各自实现一套特色的抽取逻辑，这样的做法不仅会带来额定的开发工作量，还会造成因为跨语言、跨环境等因素所引起的计算精度不统一、品质危险和保护成本增加等问题。咱们设计了一套跨语言、跨平台的算子库 & 特色抽取计算引擎，以达到一套算子代码库 + 对立的 DSL 语法配置可能在线上 / 线下各个计算环境中失效。
• 训练样本生产 / 治理：从特色数据到最终喂给模型训练的样本数据集，往往会通过特色筛选、特色抽取、样本采样、样本拼接等过程，FeatureBox 通过规范的 API 标准了该过程的输出和输入，并反对自定义数据管道且托管了整个过程的数据管道工作，以实现特色数据和模型训练的无缝对接。
• 特色品质监控和剖析：机器学习零碎产生的误差很大一部分是来自于数据的问题，FeatureBox 能够通过统计存储和服务中的一些指标，来帮忙算法工程师发现和监控这些数据的品质问题。其中包含但不限于特色品质、特色重要性、服务的性能等。

综上所述，FeatureBox 是一套针对机器学习场景定制的数据系统，用来解决 Feature-Ops 中所形容的问题，次要包含以下三个方面：

• 存储数据和治理元数据。
• 创立和治理特色抽取管道。
• 为模型训练 / 预估提供一致性的数据服务。

FeatureBox 整体架构

FeatureBox 并不是繁多的服务或者代码库，而是一套残缺的面向机器学习流程的数据系统。

FeatureBox 是基于云音乐自研的数据服务管理系统 – “Datahub” 构建起来的，整体的架构图如下：

这外面模块别离有什么作用？他们之间的关系是怎么样的？上面咱们来对其中几个外围模块进行具体的介绍：

Datahub

“Datahub” 是 FeatureBox 中最外围的模块，能够说是整个 FeatureBox 的基石。他结构了一套形象的特色元数据，并且封装各种不同物理存储的 API，将所有对物理数据的读写都形象成对特色的操作。咱们能够通过 Datahub 获取特色的 Schema 和 Storage 元数据，并且能够在任意语言和环境中应用 Datahub API 拜访到你须要的特色数据。通过 Datahub，FeatureBox 可能让算法工程师对特色数据的操作在离线 / 实时 / 在线等各种环境下，保持一致的体验。

同时作为拜访 Storage 的 Proxy，Datahub 也蕴含了序列化、压缩、埋点监控等切面化性能，以帮忙用户屏蔽一些技术优化项，实现更高的读写效率。此外，Datahub 还能作为数据和物理存储交互的拦挡解决管道，增加各种自定义的处理过程（语法过滤、平安解决、缓存优化等）。

Schema& 序列化

​ 要想所有的存储数据都有元数据，首先要做的第一步就是设计一套规范的 table schema，可能表白目前所有业务数据的格局。而对于 schema 实现来说，最重要的就是 value 的序列化计划选型，咱们须要思考以下几点指标：

• schema 要容易了解，可能不便的扩大字段
• 反对跨语言的序列化形式
• 领有高效的编解码性能和高压缩比

​ 依据以上几点，咱们很容易想到两个备选计划，一是 json，二是 protobuff，这两个选型各有利弊，咱们来剖析一下。

json：

​ 长处 – 很容易了解，扩展性也十分好，可能兼容各种语言。

​ 毛病 – 是 string 明文存储，压缩比和编解码性能都不高。

protobuff：

​ 长处 – 作为 google 老牌序列化形式，领有十分好的编解码性能和压缩比，也有很好的跨语言反对能力。

​ 毛病 – 须要生成.proto 来保护 schema，不利于字段动静扩大。（一个 table 减少字段，可能波及线上利用、flink 利用、etl 利用、spark 训练脚本等多个中央变更 schema）。

​ 那么有没有方法，即能领有 pb 的高效性能，又能领有 json 的扩大能力呢？答案是必定的！

​ 咱们调研通过 PB 库中的 com.google.protobuf.DynamicMessage 和com.google.protobuf.Descriptors.Descriptor类来实现基于 protobuff 的元数据管理和转换，并通过开源库 protostuff 来实现.proto 文件的动静编译，从而将 protobuff 格局做到像 json 一样能够间接通过 Map<String,Object> 来操作的便利性，并且不必多端同时更新公布.proto 文件。

​ 确定了 value 的序列化形式之后，构建 table schema 就容易多了。因为 Datahub 对于特色服务只提供 KV/KKV 的数据接口，那么咱们定义的 table schema 只有在减少最为 pk 和 sk 的列就能够了，剩下的列就是 value 的 pb schema。这样咱们就能即保障存储引擎对于高效读写的要求，又保障了业务零碎对于简略易用的要求。

​ 例子：music_alg:fm_dsin_user_static_ftr_dpb

主动生成 protobuff

syntax = "proto3";
package alg.datahub.dto.proto;
message UserStaticFeature {
  repeated float userTag = 1;
  repeated float userLan = 2;
  repeated float userRedTag = 3;
  repeated float userRedLan = 4;
  SparseVector userMultiStyleSparseVector = 5;
  repeated float userRedSongTimespan = 6;
  repeated int32 userBaseFeatureStr = 7;
  float userAgeType = 8;
  float userRank = 9;
  repeated float userSong2VectorEmbedding = 10;
  repeated float userChineseTag = 11;
  repeated float userTagPlayEndRate = 12;
  repeated float userLanPlayEndRate = 13;
  repeated float userPubTimePlayEndRateAll = 14;
  SparseVector artistPlayEndRatioSparseVector = 15;
  repeated float dsUserTag = 16;
  repeated float dsUserLan = 17;
  repeated float dsUserRedTag = 18;
  repeated float dsUserRedLan = 19;
  repeated float fatiRatio = 20;
}
message SparseVector {
  int32 size = 1;
  repeated int32 indices = 2;
  repeated double values = 3;
}

Transform

“Transform” 是 FeatureBox 除 Datahub 外的另一外围模块，他次要治理从特色读取到模型输出的整个过程，是机器学习零碎中特色工程 - 模型工程连接的纽带。Transform 是由 FeatureBox 中注册的 Feature 元数据、算子元数据等编排配置而成，他可能跨语言、跨引擎的表白特色抽取的执行过程。

与业内的 Transform 定义不同，这里的 Transform 只是一个自定义 DSL 的配置形容，他示意的是整个特色抽取的的计算过程，并不包含具体的工作和工作管道（相干局部在 Job Generator 和 Web Console 的工作治理性能中）。

Transform 依据理论的利用场景不同，能够分为三种状况：

咱们能够通过同样的 Transform 语法（MFDL）来表白不同环境和计算引擎的特色计算执行过程，以产出最终须要特征值：

对于咱们 Transform 模块中的 MFDL 是如何实现和利用的，能够浏览上篇文章云音乐预估零碎建设与实际的内容，其详细描述了 MFDL 在线上预估零碎中的应用。

Monitor

当机器学习零碎呈现问题时，大部分的起因来自于数据问题。因为 FeatureBox 蕴含了所有的特色存储、特色元数据、特色服务信息等性能，所以他能成为一个十分好的特色监控核心服务，来帮忙整个机器学习流程定位和发现各种特色数据问题。个别的状况下，咱们次要会统计和监控以下三类指标：

• 特色根底指标：“特色根底指标”是指基于存储引擎的特色数据的一些 metrics 统计，如特色覆盖度、存储容量、新鲜度、散布等。这些根底指标可用帮忙咱们疾速理解一个特色的根本信息，以不便具体的算法工程师 / 数据开发工程师来应用或运维该特色数据。
• 特色服务指标：“特色服务指标”是指 DataService/Storage 等在线零碎的实时运行信息，如存储指标（可用性 / 容量 / 利用率等）、服务指标（QPS/RT/ 错误率等）等相干指标。这些指标能够帮忙你实时察看和剖析以后整个 FeatureBox 的在线零碎是否稳固可用，以确保上游业务和 APP 提供的服务稳固可用。
• 特色 / 模型偏移指标：“特色 / 模型偏移指标”是指通过特色重要性、模型训练 / 预测数据偏差等指标来表白特色数据品质。因为随着工夫的推移或者一些突发的内部事件，可能会造成线上部署的模型的训练数据和理论的预测数据之间产生比拟大的偏差，从而造成模型成果降落，所以咱们须要统计“特色 / 模型偏移指标”来帮忙维持生产环境中机器学习模型的成果。

对于特色根底指标和偏移检测，FeatureBox 的 Monitor 模块次要集成 TFX 中的 Data Validation 组件来实现对数据集的剖析和监控。咱们次要提供以下三种剖析和监控性能：

• 针对静态数据集统计的可视化剖析。
• 依据先验冀望 Schema 校验数据集统计分析。
• 采纳双样本比照检测数据偏差和漂移。

下图详细描述 Monitor 模块在整个机器学习流程中的地位和作用。

示例：针对数据集的根底统计信息和散布提供可视化的视图，以不便算法同学排查数据异样问题。（原生的 TFDV 通过 jupyter notebook 执行脚本以生成可视化信息，咱们也能够通过采集每次统计的 stats 数据以展现到 FeatureBox 界面中）

统计视图会将特色分为间断值和离散值两类，两者都会有散布统计（间断值采纳规范直方散布），另外间断值会有中位数、方差、标准差等统计。

Storage

“Storage“ 是 FeatureBox 中的物理存储层，负责存储实在的特色数据，并对上游的数据服务层提供数据的读写服务。依据不同的特色利用场景，Storage 模块能够分为离线存储和在线存储。

离线存储：离线存储通常利用在训练或批预测场景，存储近月 / 近年来 TB 级别的特色数据，提供小时级 / 天级的批量读写能力。常见的离线存储有 HIVE/HDFS 等。

在线存储：在线存储通用利用在实时预测场景，只存储特色数据的最新值，并有着高响应、低提早的要求。常见的在线存储有 Redis/Tair/MySQL 等。在云音乐，咱们为了满足不同类型的特色存储要求和不同场景的响应要求，还基于 Tair 架构定制了存储引擎内核，他们别离是：

• MDB：基于内存 Hash 表的内存型存储引擎，有着高响应、低提早，存储资源代价高的特点，通常用于存储对响应要求十分高的小容量特色数据的在线预测场景。
• RDB：基于 RocksDB 的磁盘型存储引擎，响应和提早略不如 MDB、但存储资源代价更低，可能反对数据批量更新 Bulkload，通常用于存储大容量特色数据的在线预测场景。具体内容能够浏览之前的文章：自研磁盘型特色存储引擎 RDB 在云音乐的实际。
• FDB：基于 FIFO Compaction 策略的 RocksDB 存储引擎，因为 FIFO Compaction 所以很适宜存储日志型数据而不会带来写放大，通常用于存储 Snapshot 特色快照数据。
• TDB：自研的时序存储引擎，可能依据不同工夫粒度聚合计算数据，但响应和提早要低于 MDB/RDB，通常用于存储带工夫字段聚合的统计型特色数据。

FeatureBox 通过 Datahub/DataService 作为路由代理，将下层业务对特色数据的读写路由并转化到理论对应的 Storage 连贯进行操作。所以用户对底层的 Storage 的 API 和运维其实是不感知的，他们只是通过 Web Console 来定义 Schema 与抉择他们特色数据更实用的 Storage。这也促成了 FeatureBox 能够让特色存储的治理、运维、数据迁徙、疾速失败、扩缩容等工作变得更加不便。

结语

以上就是本篇文章的全部内容，咱们简略的介绍了 FeatureOps 和 FeatureStore 的定义和他所解决的问题，并以此开展讲述了云音乐自建 Feature Store – FeatureBox 的次要设计和模块性能，心愿能给对特色工程感兴趣的小伙伴带来启发和帮忙。因为篇幅问题，在整个 Featur Store 中还有十分多的细节没有开展，大家能够关注后续的文章。