本文从开发效率（易用性）、可扩展性、执行效率三个方面，介绍了微博机器学习框架Weiflow在微博的应用和最佳实践。
在上期《基于Spark的大规模机器学习在微博的应用》一文中我们提到，在机器学习流中，模型训练只是其中耗时最短的一环。如果把机器学习流比作烹饪，那么模型训练就是最后翻炒的过程；烹饪的大部分时间实际上都花在了食材、佐料的挑选，洗菜、择菜，食材再加工（切丁、切块、过油、预热）等步骤。在微博的机器学习流中，原始样本生成、数据处理、特征工程、训练样本生成、模型后期的测试、评估等步骤所需要投入的时间和精力，占据了整个流程的80%之多。如何能够高效地端到端进行机器学习流的开发，如何能够根据线上的反馈及时地选取高区分度特征，对模型进行优化，验证模型的有效性，加速模型迭代效率，满足线上的要求，都是我们需要解决的问题。
Weiflow的诞生源自于微博机器学习流的业务需求，在微博的机器学习流图中（如图1所示），多种数据流（如发博流、曝光流、互动流）经过Spark Streaming、Storm的实时处理，存储至特征工程并生成离线的原始样本。在离线系统，根据业务人员的开发经验，对原始样本进行各式各样的数据处理（统计、清洗、过滤、采样等）、特征处理、特征映射，从而生成可训练的训练样本；业务人员根据实际业务场景（排序、推荐），选择不同的算法模型（LR、GBDT、频繁项集、SVM、DNN等），进行模型训练、预测、测试和评估；待模型迭代满足要求后，通过自动部署将模型文件和映射规则部署到线上。线上系统根据模型文件和映射规则，从特征工程中拉取相关的特征值，并根据映射规则进行预处理，生成可用于预测的样本格式，进行线上的实时预测，最终将预测的结果（用户对微博内容的兴趣程度）输出，供线上服务调用。
图1 微博机器学习流图
Weiflow的设计初衷就是将微博机器学习流的开发简单化、傻瓜化，让业务开发人员从纷繁复杂的数据处理、特征工程、模型工程中解脱出来，将宝贵的时间和精力投入到业务场景的开发和优化当中，彻底解放业务人员的生产力，大幅提升开发效率。
考虑到微博业务场景越来越复杂、多样的趋势，Weiflow在设计之初就充分考虑并权衡了框架的开发效率、可扩展性和执行效率。Weiflow通过统一格式的配置文件式开发（XML流程文件），允许业务人员像搭积木一样灵活地将需要用到的模块（数据处理、特征映射、生成训练样本、模型的训练、预测、测试、评估等）堆叠到一起，根据依赖关系形成计算流图（Directed Acyclic Graph有向无环图），Weiflow将自动解析不同模块之间的依赖关系，并调用每个模型的执行类进行流水线式的作业。对于每一个计算模块，用户无需关心其内部实现、执行效率，只需关心与业务开发相关的参数调优，如算法的超参数、数据采样率、采样方式、特征映射规则、数据统计方式、数据清洗规则等等，从而大幅提升开发效率、模型迭代速度。为了让更多的开发者（包括具有代码能力的业务人员）能够参与到Weiflow的开发中来，Weiflow设计并提供了丰富的多层次抽象，基于预定义的基类和接口，允许开发者根据新的业务需求实现自己的处理模块（如新的算法模型训练、预测、评估模块）、计算函数（如复杂的特征计算公式、特征组合函数等），从而不断丰富、扩展Weiflow的功能。在框架的执行效率方面，在第二层DAG中（后面将详细介绍Weiflow的双层DAG结构），充分利用各种计算引擎（Spark、Tensorflow、Hive、Storm、Flink等）的优化机制，同时结合巧妙的数据结构设计与开发语言（如Scala的Currying、Partial Functions等）本身的特性，保证框架在提供足够的灵活性和近乎无限的可扩展性的基础上，尽可能地提升执行性能。
为了应对微博多样的计算环境（Spark、Tensorflow、Hive、Storm、Flink等），Weiflow采用了双层的DAG任务流设计，如图2所示。
图2 Weiflow双层DAG任务流设计
转自：Spark技术日报
