Meetup 回顾｜星策社区 FeatureStore Meetup V2

2022 年 4 月 19 日
本文字数：4572 字
阅读完需：约 15 分钟

继 2021 年 12 月 11 日举办第一次 Feature Store Meetup 之后，星策开源社区于 2022 年 4 月 10 日举办了第二期「FeatureStore Meetup V2 」，本次活动邀请星策社区发起人---中国开源推进联盟副秘书长、开放原子基金会 TOC 副主席-谭中意；第四范式系统架构师、开源项目 OpenMLDB 负责人-卢冕；中国工商银行软件开发中心大数据和人工智能实验室副主任-黄炳；AWS 数据分析解决方案架构师-唐清原、网易云音乐人工智能研究员-吴官林，从不同领域不同视角下的深入探讨 FeatureStore 在各行业内的实践演进。共有 4000 余名观众在线观看了直播，并与几位嘉宾共同讨论了 FeatureStore 未来的发展趋势。

🌟本期 Meetup 嘉宾分享 PPT 获取方式：关注公众号「星策开源」并回复「0410」

内容回顾

Part 1 | 开场 + 介绍特征平台/Feature Store 概念——谭中意

中国开源推进联盟副秘书长、开放原子基金会 TOC 副主席谭中意，在此次 meetup 开场中介绍了特征平台 FeatureStore 的概念和意义。

作为星策社区的发起人与本次 Meetup 的组织者，谭中意表示，星策开源社区作为作为助力企业智能化转型的开源社区，非常重视 AI 技术在企业的“多快好省”的落地问题，然而现实中机器学习的落地非常慢，效果经常达不到预期，同时效果还可能会被回退。

而落地慢的原因是在实际的生产环境中，与机器学习相关的代码只占很小一部分，AI 系统是代码+数据+模型的整合，而数据又是其中最重要却又很难保证正确的部分。所以为了解决这一问题，在借鉴 DevOps 的经验后发展出了 MLOps，如下图所示 MLOps=CI+CD+CT+CM，即机器学习全过程从项目项目到定义和搜集加工数据到训练+迭代再到部署+监控的自动化循环与迭代，它包括了模型、代码与数据。

MLOps 不只是流程和 Pipeline，还包括工具平台，而本次活动所讨论的重点 FeatureStore，则是 MLOps 领域中的关键产品。它是一个构建、管理、共享机器学习所需特征的平台。

Part 2 | OpenMLDB: 开源全栈实时特征开发解决方案——卢冕

第四范式系统架构师、开源项目 OpenMLDB 负责人、数据库团队和高性能计算团队负责人卢冕，在本次活动中介绍了人工智能工程化落地中企业面临的数据与特征难题的现状，重点介绍了如何通过 OpenMLDB 为企业提供全栈 FeatureOps 解决方案。

当前企业在 AI 工程化落地的过程中，有 95%的时间花费在数据上，市面上众多解决数据问题的开源方案在实践过程中并不能完全高效的解决工程化落地问题。为了解决这一问题，特征工程 FeatureStore 的出现变得非常重要。

FeatureOps 工程化面临的最大挑战是线上线下的一致性校验问题。在实际过程中，工具能力的不一致性和需求沟通的认知差都会导致线上线下的不一致，为了校验这种不一致带来了高昂的工程化落地成本。面临这种问题，市场上 1%的头部企业会可能会选择耗费上千小时来自研构建平台；非头部企业则可能会选择采购昂贵的 SaaS 工具和服务。而开源项目 OpenMLDB 的出现则提供了更低成本更高效的企业级解决方案。开发者只需要三步即可做到开发即上线的功能，即线下 SQL 特征脚本开发、一键部署上线、介入实时请求数据流。

其中，OpenMLDB 的 FeatureOps 工作流如下图所示；在离线部分引入数据，在离线特征计算与模型训练阶段进行交互调参，在质量达标之后即可开始 SQL deployment，其中 SQL deployment 可以理解为把 SQL 传给线上服务并启动相应的服务，之后导入冷启动的数据（比如三个月内的交易记录），然后将实时数据流接入，全部完成后就可以进行余额态特征计算，当收到特征需求后，就可以在在线的 Database 里拿到原始数据，然后从 SQL 的 Deployment 里获取 SQL 做实时的特征计算，最后将特征宽表返回给请求端。

如今，OpenMLDB Cover 了整个 FeatureOps 的解决方案，如下图所示 OpenMLDB 前后与 DataOps、ModelOps 的衔接已经有了非常多的生态整合。上游 DataOps 衔接了包括离线部分的 HDFS，S3，HBase 等，在线部分的 Kafka、Pilsar、Flink 等；下游 ModelOps 部分衔接了 XGBoost，LightGBM，TensorFlow 等。同时 OpenMLDB 在 ProductioneOps 方面也会在 0.5.0 版本中与 Airflow、Kubeflow 进行整合。

Part 3 | 工行人工智能平台建设实践分享——黄炳

中国工商银行软件开发中心大数据和人工智能实验室副主任，中国工商银行大数据和人工智能领域技术专家黄炳，在本次 meetup 中重点介绍了工商银行企业级人工智能平台建设的建设历程，系统架构，和工行人工智能平台的应用情况与发展思考。

工商银行企业级人工智能平台技术架构主要由数据要素层、基础平台层和智能服务层组成，并建立贯穿三层的“易追溯、可共享”的智能资产管理机制，实现数据、算法、模型、服务等智能资产的统一标准、统一管理、统一运营。如图所示为工商银行企业级人工智能平台技术架构。

其中，为了满足大规模的模型训练同时还能保证高质量的管理，工行创新实现了生产环境和研发环境的打通，形成 MLOps、DevOps 相融合的模型敏捷研发运营模式，基于生产环境形成高质量的模型，基于 DevOps 实现模型与代码的高质量集成交付，模型在全生命周期各阶段流转高效、管理精细，模型上线周期缩短约 50%，实现了工行人工智能大规模应用的“精准构建、快速流转、持续运营”的目标，下图所示为人工智能平台中基础平台层，MLOPS 模型的全生命周期管理流程。

当前，中国工商银行的人工智能生态体系建设项目已经拥有了广泛的应用实践，实现智慧服务、智慧产品、智慧风控、智慧运营、智慧生态等超过 1500 个业务应用落地，人工智能技术在工商银行已经进入规模化业务应用新阶段。

未来，工行将践行大行责任，打造跨界融合，开放共赢的金融生态。聚焦内外数据融合创新、人工智能高地建设、数字人才队伍培养等工作，依托工银图灵平台建设开放共享的数字金融创新生态平台，面向政产学研各方合作伙伴开放场景、开放技术、开放算力、开放数据，形成赛事承办中心、产学研实训中心、数据共享流通中心等服务能力，打造“走出去”和“请进来”双轮驱动的人工智能创新生态圈，助力国家科技自立自强。

Part 4 | Amazon Feature Store 解决方案介绍——唐清原

AWS 数据分析解决方案架构师唐清原，在此次 meetup 中介绍了特征库在行业领域中的各类需求场景，以及 AWS 针对性的特征库技术解决方案及生产实践。

特征库是 AI/ML 中的数据仓库，是机器学习领域万丈高楼的地基和刚需，高质量的特征数据，决定上层算法模型的 AUC，准确率等等，业界 data driven 的模型优化也是重要的研究方向。AWS 从客户案例中发现，ML/AIOps 中，对特征库的需求可以分成以下两层面，首先从技术层面看，特征需要基于时间版本特征数据查询及提取，同时还要考虑特征值的 update，以及新增特征维度。从管理层来看，很多客户希望可以复用数据分析平台的计算资源，复用数仓/大数据平台能力，快速培养团队。

所以面对这些问题，AWS 有了自己的 FeatureStore 解决方案，整体思路可以总结为与 AWS 的大数据 &数据分析服务深度集成，形成端到端的特征工程构件，同时根据业务场景的针对性，灵活组合服务组件。

上图所示是 AWS 的特库解决方案架构图。从下到上离线特征库、在线特征库。从左到右是数据源、特征库或特征工程，最右边是 AI 和机器学习平台。离线特征库整体上是利用数仓和大数据平台的能力通过 AWS 提供的存算分离的 S3，打通机器学习平台和大数据平台特征的处理、抽取、转换的桥梁。而在线特征是利用 AWS 的 no-Sql 数据库及流批一体的计算框架、流式数据管道来实现批量及实时 ingest 在线特征库并提供低延迟的读写。除此之外，客户还可以利用 AWS redshift 实时数仓的功能，通过和流式数据管道组件的集成来实现在线特征库与离线特征库统一的构建存储和读写的能力。客户可以通过不同的需求场景灵活选择相应的服务组件，其中详细的各组件介绍如下图所示。

总体来看，当前 AWS 所提供的 FeatureStore 解决方案可以同时提供在线和离线特征库，流批合一的实时特征 ingestion，同时还能实现与数据湖，数仓统一的元数据管理及 schema evaluate。对于特征探索与处理可以让算法工程师用他们所熟悉的 Sql 或者 python 语言。而在快速构建特征库层面，AWS 所提供的方案可以尽量复用大数据，数仓平台功能及分布式计算框架，最大程度减少构建的工作量。同时还提供了 OnDemand/serverless 的全托管模式，有效的降低整体的 TCO 成本。

Part 5 | 网易云音乐特征平台的建设与实践——吴官林

网易云音乐人工智能研究员、网易云音乐实时计算总监吴官林，在此次 meetup 中结合网易云音乐业务特性构建服务于商业化和内容分发算法场景下特征平台，从特征生产、特征存储和特征应用三方面介绍针对特征属性做的相关改造和实践经验。

对于网易云音乐来说，随着业务的发展，云音乐 DAU 提升至几千 W 级别、几十算法场景、几百算法模型、算法团队几十人情况下，如果没有全流程工程化系统、平台支撑，就会出现特征失控、复杂的 DNN 上不去、周期拉的很长、算法效果受制约的情况。基于这种实时化程度低、建模效率低、模型能力受限的背景，为了提升云音乐算法在支撑商业化、内容分发业务时的建模效率，助力算法效果提升，云音乐设计出了如下图所示包含特征生产、特征处理、样本生产、模型生产、模型上线等的一站式全链路端到端的学习平台。

而对于特征来说，云音乐的各个算法团队拥有自己所构建的数据，如 CTR 数据等存在口径差异，并且由于时间窗通常由各个团队自己完成，所以在特征生产方面出现了公有库与私有库。针对特征处理方面，云音乐除了考虑特征抽取的性能，还考虑了特征抽取的算子能否针对某一个特征，在改变某个参数或配置时可以定义出自己的算子，然后把这些算子在线上线下做到同一代码多数据使用的能力。而对于样本生产方面，云音乐关注于解决因为实时特征所带来的相关穿越的问题。对于以上这种针对特征生产、特征处理和样本生产的部分定义为 FeatureStore 的范围。

随着云音乐在多业务覆盖中发现，大部分痛点都集中在特征上，其中复用/发现难、一致性难、开发效率低的问题尤为关键。面对如何实现特征处理标准化，提高特征样本开发效率并带来算法效果的提升是云音乐的目标。所以基于云音乐的业务，自建了云音乐的 FeatureStore，整体框架可以分成从特征存储到转换到特征上线，由此提供了为机器学习场景服务的特征系统平台（FeatureStore）来负责特征计算与供给。