机器学习实践心得：数据平台设计与搭建
|
选择Jupyter作为主要建模IDE而不是自研可视化拖拽建模工具，这样的好处是可以做交互式的分析，建模效率也很高，扩展方便，研发成本低。当然类似微软Azure这样的可视化拖拽建模平台，可以非常清晰地看到整个流程，适合入门级同学快速上手。但我们的目标用户是专家和半专家群体，所以我们选择了最合适的Jupyter。 使用Jupyter时候，为了支持多租户，我们采用Jupyterhub。底层机器学习框架我们用了Tensorflow、Pyspark、Sklearn等。数据处理探索时候，结合sparkmagic，可以非常方便地将写在Jupyter上的Spark代码运行到Spark集群上。 对于Jupyter没有现成的版本管理控制和项目管理， 我们结合git来解决。 另外为了提高建模人员在Jupyter上的效率，我们引入了比较多的插件，例如：把一些典型挖掘pipeline做成Jupyter模板，这样需要再做一个类似业务的时候只需要基于模板再扩展开发，比较好地解决了不规范的问题，避免了很多重复代码，也为实验代码转化为生产代码做好了基础。 第二点，说下工具函数： 我们内部提供了主要机器学习相关的函数库和工具： 1)标准化的ID Mapping服务API。 2)创建数据抽取的API，无论是哪种存储，分析人员只要统一调这个API就可。3)可视化做了标准化的函数库和工具类。 4)Jupyter2AzkabanFlow: 可以把原本在Jupyter上写好的代码或者脚本自动转化成AzkabanFlow，解决了特征工程阶段的代码复用问题。 第三点，关于使用Tensorflow： 使用Tensorflow时，我们的选型是TensorflowOnSpark，原生的Tensorflow的分布式支持不够好，需要去指定一些节点信息，使用难度较大。 TensorflowOnSpark能够解决原生Tensorflow Cluster分布式问题，代码也很容易迁移到TensorflowOnSpark上，基本不用改。 同时利用yarn可以支持GPU和CPU混部集群，资源易复用。 第四点，关于模型交付应用： 在模型交付的问题上，我们把整个预测代码框架化了，提供了多种标准的框架供分析人员直接选用。对输出的模型文件有格式进行要求，例如：只能选择 pmml格式或者tensorflow pb格式。标准化之后，只要使用标准的预测函数库，就可以把建模人员的工作和系统开发人员的工作解藕出来。 最后分享下我们的一些经验： 第一，TensorflowOnSpark上的PS数量有限制，而且Worker和PS节点资源分配不是很灵活，都是等大。 第二，Jupyter在使用的时候，需要自己做一些改造，一些开源库版本兼容性有问题。 第三，使用PMML有性能瓶颈，一些是java对象反复重建，还有一些是格式转化损耗，具体大家可以抓取下jvm信息分析优化。 第四，在落地过程使用Spark、Hive的问题上，需要提供易于使用的诊断工具，建模人员并不是Spark、Hive的专家，不一定熟悉如何诊断优化。 第五，要把模型和特征库当成一个资产来看待，对它的价值定期做评估，要管理好它的生命周期。 第六，一些更偏底层的问题，比如: 硬件的选型可能要注意带宽、内存、GPU平衡。 最后，需要平衡技术栈增加和维护代价，避免引入太多新工具新技术，导致运维困难。 原文作者：eva7 来源：https://www.cnblogs.com/evakang/p/9324740.html （编辑：东莞站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |