引子
大多数关注机器学习的同学，更多关注的是算法本身，而机器学习能不能给公司带来价值，需要很多配套系统去支持。对于很多小公司来讲，这块的建设一般比较薄弱，本文来聊聊蘑菇街这几年在这块的工作，并针对研发能力较弱的小公司，给出一些个人建议。
数据链路
数据是一切的根本，因此首先要有一套全链路打点系统。蘑菇街设计了两套字段方案，PTP和ACM，其中PTP负责追踪页面跳转，ACM负责追踪算法实验标识。PTP有个事件管理中心，各个业务方可以在此注册事件类型，比如电商有曝光、点击、加购、成交等事件，PTP必须能保证用户的这些行为交互中，数据链路不会中断。简单来讲，当拿到一条成交日志，要能回溯到用户是在什么地方加购，什么地方点击，那个渠道曝光的。
ACM字段和ABtest系统对接，算法同学一般会在线上做很多实验，需要追踪实验效果。我们会为每一个实验生成唯一的acm，基于实验粒度的分析依靠它。
数据链路的稳定性是比较难的，版本变更时，要特别关心打点丢失、不准确等问题。理想情况下，我们可以建立一个打点schema管理中心，对其做回归测试，但这个方案会比较影响业务的快速迭代，推动成本较大。目前，我们还是基于一些test case来测试管理。
困难点 全链路追踪、链路稳定性
建议 公司内部的方案不能讲的太细，没有接触过这块的同学可以参考友盟、神策等第三方数据分析工具的sdk，再结合自身的需求设计打点系统。
训练平台
机器学习算法是一个试错性很强的领域，因此，算法工程师迭代的速度是重中之重。应该想尽办法提高算法同学迭代的效率，我们经历了单机R、python到spark到搭建了tiny+训练平台。
整体架构如下：
样子如下图，和阿里的PAI、第四范式的先知有点像。
一个常见的使用case如下：
减少算法同学迭代策略时的代码开发工作，将常见的操作抽象成算子，可以拼拼凑凑的构建模型。前几年的时候，我并不赞同这样做，认为这样的工具会让很多同学不熟悉底层，不利于模型优化。但这两年观点有所转变，前者对团队成员的要求有点高，把算法同学从代码细节中解放出来，更多精力放在特征工程和调参上，确实会有更好的业务产出，这样的工具，对效率提升非常有帮助，特别是团队成员变多后，减少了很多重复工作。
除了训练外，tiny+支持一部分模型评估的功能，包含常见的模型指标，比如auc，group auc，F1等，并支持一部分模型分析的功能，比如模型切片分析。
同时，工程同学可以将精力投入到提到算力上，支持更大规模的特征构建和更多数据的训练上。
目前tiny+支持三种任务：
- 基于yarn的纯spark任务
- 基于spark的腾讯开源PS框架angel任务
- 基于k8s+docker的tensorflow的深度学习任务。
困难点 特征的规模、训练的效率、PS计算框架下网络通信瓶颈等
建议 小公司直接用阿里云或者其他大厂的现成服务就挺好的，自研的必要不大。
特征平台
特征是模型的核心，在团队合作过程中，提供一个统一的特征平台，除了能够做到统一处理和方便特征复用，减少重复工作外，还能建立特征生命周期管理、状态监控、与上下游系统交互。
我们的基础系统是搜索引擎，搜索引擎有个重要的组件是数据dump系统，里面会管理很多搜索引擎用的字段，用于索引构建。以前我们也把线上需要用到模型字段、特征字段放在这里管理。发现一个是不灵活，一个是非常容易出问题，生命周期也不好管理，字段容易膨胀，给引擎索引构建造成困难。
特征构建一般是基于hive做，需要写很多sql。做过阿里比赛的同学应该知道，它们的ODPS可以把模型也用sql写出来。但SQL有个问题，可读性不如代码，后期维护成本高，很多同学不愿意维护别人的，喜欢自己搞一份特征集，重复工作外还给数据平台的存储增加了压力。
我们的特征平台实现了基础的算子构建，可以拖拽式的完成特征构建。在减少了开发量的情况下，牺牲了一定的灵活性，当算子不支持时，需要提需求给特征平台的同学。当然好处也是明显的，可以针对特定构建逻辑优化效率，算子粒度比SQL粗，减少构建工作量，统一了构建流程。
样子如下：
困难点
- 控制好度，算子设计容易重复造轮子
- 特征构建性能
建议 小公司可以用metadata管理 + hive + hbase做到基本可用的特征构建和管理
ABTest
ABTest的第一个问题是分流，业界常见是基于session和基于user或设备号，前者用户在每一次请求时都有可能命中不同的实验，而后者的用户AB分桶是稳定的，即会一段时间停留在一个实验内。在APP时代，大部分公司会选择后一种，给用户更稳定的用户体验。当后一种策略由于存在很多黑产及奇怪的设备，会有一部分的用户分流不均，需提前处理。
第二个问题是要能支持灵活的实验。在电商APP里面，场景很丰富，大部分的实验是基于场景，需要教灵活的支持在各种不同场景下做实验，并能方便的在系统中看到实验的数据。
第三个问题是实时性，迭代速度是算法同学的核心诉求。有些指标实时数据不置信，比如gmv，但ctr的实时数据置信度高，很有必要支持实时。我们基于kafka收集日志，在storm上开发了实时ETL系统。
另外，ABTest还需支持实验分析功能。将一些常见的分析工具集成在系统里面，比如根据用户群、业务字段等的切片分析，和前面的tiny+的模型分析配合，类似于google的TF的Extends提到TFX。
困难点
- 实验数据置信度
- 实验效果分析
建议 ABtest应该尽量自己做，首先它并不难，开发成本不大，但却能让大家从实践过程中感受数据的细节，特别是其中的分析功能，有助于理解模型和业务，不应该假人之手。
精排系统
将搜索推荐业务分层match和rerank是常见的操作。我们的精排系统基于Java，类似TF Servering的功能，支持各种线上模型服务，不仅限于搜索推荐，还包括图像、NLP、反作弊等。
在线上提供模型服务，除了能支持各种不同的模型外，比如tf的模型load，spark的模型load外，重点还是要能获取模型预测需要的数据。由于这部分系统对RT的要求较高，特征数据的存储性能是很重要的一个问题，我们写了一套自己的存储。
我们还在这里承接业务需求，支持业务对算法结果的干预。系统交互如下：
困难点
- 在线特征处理和模型训练特征处理代码最好是一套，分开编写除了费人力，也容易出错。
- 稳定性，很多算法工程师工程素养不高，推个模型把线上系统推挂可不好。
建议 现在的TF Servering还比较弱，但他们发展很快，是可以考虑拥抱开源。
User Profile System
要做个性化，前提条件是能实时的获取用户在app的行为，我们构建了UPS来存储这部分用户数据，包含各种类型的行为数据。它的存储性能也比较重要，支持较好的读写性能、持久化等功能。
一份数据有可能会用于多处系统，故这些系统的底层存储最好是一套，减少数据与系统交互的成本。结构如下：
建议 性能没有到瓶颈之前，Redis就很好。
搜索引擎
这个技术目前已经比较成熟，业界有luence，还有基于他们的solra、ES等平台型的解决方案。我们在15年自研了引擎，好处和坏处都很明显。好处是我们和容易就在里面支持了向量的矩阵乘，用于优化各种EMbedding向量做召回时的性能问题，另外做了一个很奇怪的字段级全量更新。坏处是周边配套工具都得自己搞，而且招人很难。
困难点 太多了，略。
建议 研发力量有限，还是拥抱开源吧，大部分需求ES够用了。
推荐引擎
这个技术目前已经比较成熟，专栏已经有篇文章写了细节。简单提下，相对于搜索，推荐的召回多种多样，所以该系统主要是针对灵活多样的召回策略设计。架构如下：
困难点 召回需求各式各样，如何能尽量减少代码开发量。
建议 在业务和数据没有上规模前，把各种策略结果存redis顶一顶也可以。
Query Rewriter
也有公司叫Query Paser，负责搜索query的分词、改写、类目预测、相关性预测等等，可说的不多。
困难点 支持配置化
统一调度平台
相比于系统，数据链路更难维护，集中在两点： 1. 局部数据污染，没有明显的征兆。 2. 数据出了问题，回滚困难。
有一个统一的调度系统，控制住从特征构建、模型训练、校验、版本控制、推送到线上系统、校验，就显得十分重要。
困难点
- 调度本身是一件很难的事情，这个部分的预期更多的是管理流程和预警，不应该去涉及资源利用等问题。
- 灵活性，能支持各式各样的子系统。
建议 前期可以人肉一点，设定模板脚本，基于crontab工作，用钩子将各个脚本串起来，不过要做好报警吧。、
总结
当然还有一些其他系统没有提到，在蘑菇街四年多，见证了上述系统从无到有的过程，参与了大多数系统初版的设计和开发（专栏的其他文章介绍过其中一些系统），走了不少弯路。比较可惜的是，上述的大多数系统，一开始都是算法同学根据需求自己做了原型，拿到了实际收益后，工程同学才慢慢接手。
现在回想，存在其合理性。当时网上可参考的不多，大家对这些没有共识，互相扯需求的合理性的时间还不如撸起袖子加油干。但其中造成的浪费也是显而易见，算法同学更多是实现了系统，但工程素养不高，后期往往要重写，浪费人力。
希望本文能给后来者一点帮助。
