业界中DS/ML应用上线Implementation的问题

zxiaoc 发表于 2018-8-18 03:39
正在做的工作内容就是exactly做这个: 将data scientist做好的model launch to production, 简单答一波~
在 ...

在哪家公司呀，你们的Machine Learning主要应用在哪方面的业务？

实习的时候离职以前最后一步就是上线text classification模型，当时的需求是不需要real-time，只要定时跑一遍inference然后把分类结果存下来就可以。
阿里内部各个BU有大大小小的机器学习平台（这种技术上各自为政可能也是一个缺点），比如文娱UCWeb有A平台，支付宝有B平台，调度 / 封装 / 调用自己部门的模型。
在已经有训练好的模型（包括分类器本身、word embedding等等），小数据量验证已经通过，之后，当时首先和mentor等人讨论定下来数据来源于哪个表（Apache Hive），会使用哪些临时表，最终输出结果在哪张表上，然后记在文档里面。
接下来的工作在一个shell脚本中：
- 对文本（original data）做一些处理，比如去掉stop word，替换一些生僻词语，用一两个稍复杂的SQL
- embedding mapping，这个是之前工作写好的python script，调用一下便成；数据存储什么的在公司内部也有API
- 模型本身prediction+多进程处理+数据分片，占用比较多的计算资源但保证运行速度
- 预测出的label存进Hive，这个步骤会用SQL汇总几种数据，但具体怎么做的记不清了
最后这个shell script+所有work的python script会上传到调度平台，运行类似于crontab，定时出结果。
至于monitor等等其他问题，公司的平台上早已有service，直接用就是了。。写起来感觉自己就像个大机器上的小螺丝钉？

猜测国内的“算法工程师”更像一个SDE + Data Scientist的结合体，除了撸数据撸模型之外，开发也要会不少

Serving的问题，特别是有Real-Time要求的，其实是一个很复杂的问题，确实不应该由一个DS来牵头做，还是需要更多人来一起设计。需要考虑的因素有：

1. online和offline的feature extraction步骤显然不同，一个是raw request，一个通常是大致处理过的table。这就需要设计一个interface来保证一致性。这里编程语言通常不是问题所在，要保证数据类型一致性的话可以用protobuf。

2. model evaluation需要一致性，最好是同一个模型同样的运行环境，所以micro service架构配上docker会很方便。

3. performance tracking，a/b testing，model refresh这些最好都要有，只有offline simulation的ML system是不完整的。

4. model多的话自动refresh可能需要上airflow这样的scheduling system，而且自动refresh没有人手动把关，那么模型质量的验证也要很完备。模型表现最好有实时监控。模型文件refresh的时候不能覆盖旧版本，一旦出现问题可以快速rollback。

如果model数量不多，可以考虑一下托管平台，像H2O或者Sagemaker之类的产品。

我们用的也是Airflow， 非常适合multiple step workflow。
一个product用一个DAG，里面每一步都用python class包起来，比如data ingestion， feature engineering， model training等等都有自己class。python下面那些machine learning的包都可以用, 还可以用来schedule spark job. 我们的是结果最后写回到db就完事了。你这个如果real time recommendation的话，搞一个Kafka topic写回去.
Airflow基本上是我们data science own的service，跟我们main stack那些Java的东西基本无关。

模型简单的话用AWS sagemaker上的demo改改就好。复杂的话sagemaker也可以deploy用docker封装的模型，demo挺全的

Docker 封装是最常见的，这样可以仿照 Severless 的思路 deploy。 Docker 里面如果是TF会把东西都写好。

如果要求速度，就比较 Tricky 了，比如你可以 model 并行，数据并行，甚至把model拆开并行，推荐几个文章吧。

Clipper: A Low-Latency Online Prediction Serving System

DeepCPU: Serving RNN-based Deep Learning Models 10x Faster

Pretzel: Opening the Black Box of Machine Learning Prediction Serving Systems

感觉现在ML都趋向GPU based， Spark mllib  应该现在还不support GPU。 这一块应该是独立的service。 所以Python 不会有太大问题。 至于和其他模块通讯已经是很成熟了。完全看你们的设计要求。

我知道的也有限，但是最近公司的一次做法是我把算法写成python package， SDE组用AWS lambda包装起来。至于包装之后怎么用我就不知道了，SDE就说你写个python package传个github就可以了。我不懂AWS的东西，所以不清楚这个是不是合理做法。貌似这样做可以建一个什么web api？不太确定。