从SQLFLOW开源说起，谈谈如何全面提升数据挖掘的效率？

5月6日，蚂蚁金服宣布开源机器学习工具 SQLFlow：“未来三年，AI能力会成为每一位技术人员的基本能力。我们希望通过开源 SQLFlow，降低人工智能应用的技术门槛，让技术人员调用 AI像SQL一样简单。”

SQLFLOW不是莫名其妙产生的，实际是业务驱动的产物。

数据分析师一般用SQL来进行数据挖掘，只是这类数据挖掘大多基于业务规则，而机器学习本质上也是数据挖掘的一种，但需要用更高级晦涩的语言来实现，这对于很多数据分析师来讲门槛高了点。

既然大家的最终目的相同，考虑到庞大的数据分析师群体，显然会有人会想到能不能统一下实现工具，比如对SQL进行拓展，直接支持对机器学习引擎的调用。

这种思路的开山鼻祖可不是阿里，TD最新推出的产品Teradata Vantage已经提供了强力的支持，唯一的不同就是开源和商业的区别，以下是Vantage的一段调用说明：

以下是SQLFLOW的，是不是很像？

但SQLFLOW的野心似乎更大一点，为什么？

因为其要实现两个目的：一是通过SQLFLOW对所有现存的各种SQL引擎进行抽象，屏蔽语法差异，以后你们访问HIVE，GBASE，ORACLE等等，用统一的SQLFOW就可以了。

二是对现存的机器学习、深度学习引擎进行封装，用SQLFLOW来统一调用。同时解决机器学习数据输入输出的无缝衔接问题。

SQLFLOW的使命就是：让所有的数据挖掘（含机器学习、AI等)像操作SQL那样流畅，为数据分析师（甚至业务人员）赋能，要成为数据挖掘生态的掌控者。

那么问题来了，这个真有前途吗？对于企业来讲，除了SQLFLOW，是否还有更适合自己的办法来提升数据挖掘的效率？

我们还是要遵循第一性原理，回到数据挖掘本身的流程中去寻找答案，当然SQLFLOW肯定是一种，但显然不是唯一的。

数据挖掘从训练到发布，一般可以分为以下步骤：业务分析-样本数据准备-变量选择-样本数据输入-模型训练（含模型选择和评估）-模型发布-生产数据输入-结果数据应用。

你会惊奇的发现，最具技术含量的模型训练，竟然只是其中的一个节点，八分之一而已。为了让数据挖掘的模型具备生产价值，其实需要做大量的配套工作，而且其中每一个步骤都相对独立，甚至依托不同的人员、系统或平台完成。

1、业务分析：对于业务的理解能力越强，选择的数据和变量就越有价值，这是机器学习的要点，当然极个别的场景除外，比如下棋。

大多数企业机器学习的应用场景涉及的要素基本是无法穷尽的，因此，越复杂的环境，就越需要强大的业务理解能力，现在只有人有这个能力。

2、样本数据准备：大多时候，我们需要从数据仓库（当然数据库，文件都可以）获取所需的样本数据，数据仓库的效率起到至关重要的作用，比如数据预处理，这个阶段往往耗费了大量的时间。

3、变量选择：业务分析虽然能大致圈定一些变量，但有时还是需要依赖一些更为客观的评价方法，比如IV，WOE等等，甚至需要单独建个模型来取舍变量，这个过程往往是独立的。

4、样本数据输入：需要根据变量选择的结果决定样本的最终数据，作为模型训练的数据输入。

5、模型训练：需要选择合适的数据挖掘引擎和算法（深度学习或者机器学习等等），无论是基于图形界面或是脚本；需要将样本数据输入到挖掘引擎中，无论是基于JDBC,ODBC还是文件。

一般我们以为的机器学习就特指这个过程，因为技术含量最高嘛，但实际上这个阶段花的时间并不多。

6、模型发布：需要将训练好的模型文件发布到生产环境，这又是一个完全独立的过程。

7、生产数据输入：需要基于数据仓库或大数据平台定期生成待预测的数据作为模型输入，然后获得模型预测的结果。

8、结果数据应用：将预测结果（一般是表）推送到各种应用平台，真正产生价值。

你看这些步骤既不能在一个平台完成，也不能简单的进行流程串接，其实蛮奇怪的。我们经常说一个数据挖掘70%以上在做准备工作，现实的确也是这么回事。

SQLFOW希望将4，5，6，7割裂的四个步骤用一个简单的SQL完成，从这个流程上很容易看出它的价值点，但显然SQLFOW不是唯一的优化方式。

笔者就试着用更为体系化的方式谈谈这个问题：如何全面提升数据挖掘的效率。

1、业务分析

企业要提升数据挖掘的效率，最重要的是选对人，用好人，笔者在多篇文章中（比如《数据挖掘师，要从一个人活成一支队伍》）阐述了数据挖掘对于人的要求，你不仅仅要懂点挖掘技术，更要懂业务，会分析，善沟通，在数据+AI底层基础设施做的越来越好的当下，这个趋势越来越明显了。

阿里招的大量的数据挖掘师可不是去研究什么高大上的算法和平台，大多都是要需要能基于现有平台、数据和工具的能力进行分析，从而解决一个具体的业务问题，但很多企业在数据平台上投入不少，人才引入和培养上却乏善可陈。

BAT为啥不外包建模师？显然这是由数据的特点决定的，交易成本太高了嘛。但很多企业却没有基本的数据挖掘团队，或者是完全外包给合作伙伴。

如果你希望提升数据挖掘的效率，其实最有效的方法就是找到合适的人，无他。

2、样本数据准备

假如你每次数据挖掘的变量准备、数据预处理的时间很长，就要想想是不是企业的仓库模型设计（比如宽表）出现了问题？是不是需要针对数据挖掘再建一套宽表？

《阿里巴巴大数据实践-大数据之路》这本书就提到了数据挖掘中台的价值，如下图示意，其中FDM层用于存储在模型训练常用的特征指标，IDM层面向个体存储通用性强的结果数据。

以前笔者还心存疑虑，现在觉得还是有一定的必要性，因为当前数据挖掘的工作越来越多，建模师各自为战、疯狂取数的局面越加明显，而现有的数据仓库模型设计并不能很好的支撑。

以下是阿里的关于电商购买预测中数据准备的一个案例，我们可以从中获得一些启示。

影响某个用户对某个品牌是否购买的特征有哪些呢？

首先是用户对品牌的关注，譬如：点击、发生过购买行为，收藏和假如过购物车，而在这些因素中，关注的行为离现在越近，即将购买的可能性就越大，所以我们会关注最近3天、最近一周、最近1个月、最近2个月、最近3个月和有记录的所有时间的情况，于是有了如下一些特征。

• 最近3天点击数、购买数、收藏数和加入购物车次数
• 最近1周点击数、购买数、收藏数和加入购物车次数
• 最近1个月点击数、购买数、收藏数和加入购物车次数
• 最近2个月点击数、购买数、收藏数和加入购物车次数
• 最近3个月点击数、购买数、收藏数和加入购物车次数
• 全部点击数、购买数、收藏数和加入购物车次数

有了关注时间段细分的关注次数还不够，还希望知道该数值的变化率，来刻画该关注的持续程度，我们还可以构造如下特征：

• 最近3天点击数变化率（最近3天点击数/最近4-6天点击数）、购买数变化率、收藏数变化率、加入购物车次数变化率
• 最近1周点击数变化率（最近1周点击数/上周点击数）、购买数变化率、收藏数变化率、加入购物车次数变化率
• 最近1月点击数变化率（最近1月点击数/上月点击数）、购买数变化率、收藏数变化率、加入购物车次数变化率

诸如此类还有很多，这么复杂的特征变量设计不应该是每次做数据挖掘的时候去临时生成，而应该沉淀下来，这就是数据挖掘中台的价值吧，当然开始的时候做几张为数据挖掘服务的宽表也许就有不错的性价比。

3、样本（生产）数据输入输出

很多企业中的商业挖掘引擎作为一个独立的平台存在，而数据存储往往是另一种平台，比如GBASE,HIVE，ORACLE等等，要进行交互涉及到大量的数据导入导出操作，同时带来适配性的问题。

模型训练的时候你感觉自己是个建模师，而要进行数据的导入导出时又感觉自己是个工程师，以前基于单机的版本还能应付，现在训练和预测的数据都是基于海量数据的，一旦出现工程类问题完全不知所措，原因就是两者要求的技能其实不同。

比如有位建模同事曾经搭了个Python的训练环境，发现从HIVE导数据到这个训练环境特别慢，最终核实是JDBC的原因，其实直接同步HDFS的文件就可以了，但这个数据建模师并不清楚。

SQLFLOW通过封装屏蔽了这些技术问题，做的比较彻底，但有利也有弊，就好比一体机一样，在提供便利的同时也降低了灵活性，比如很多机器学习的算法并不是简单的预测，其结果的表达用SQL并不合适。

笔者曾经在《如何打造敏捷的数据挖掘能力？》上提供过一种折中简单的方法，比如将企业的数据管理平台与R，Python直接打通，挖掘引擎在训练的时候可以直接调用数据管理平台对应的表，训练的结果则直接发布到数据管理平台进行生产。

对于数据建模师来讲，这种集成省略了导入导出的面上操作，可以用较小的代价带来较大的效益。

毕竟一般企业哪有能力去打造什么SQLFOW这种武器，即使免费使用，周边平台和人员的适应成本也是很高的，比如HIVE推广了很多年还有不少人不适应，开源的东西投入的隐形成本有时比商业还高。

无论如何，解决数据挖掘引擎的快速输入输出问题的确是提升效率的一个关键。

4、模型训练

要提升模型的训练效率，业界给出了很多方向，一种是尽量可视化，通过先进的图形用户界面来傻瓜式的完成模型的训练，阿里推出的机器学习平台 PAI 就是一种，比如托拽基础 AI 组件来构造复杂的模型和数据流，下图给出了示例。

但这种模式显然不如SQLFLOW灵活，比如SQLFLOW更容易存档、Code Review、分享知识、集思广益、高效率迭代等等。

另一种就是探索自动建模的方法，比如自动调参，以下是笔者了解的一些方法，大家有兴趣可以自行百度：

• 算法和算法超参数保持不变，改变Input，即在生产中根据最新的预测结果和实际结果重新训练模型，同时让这个过程自动化，当然这只是一种设想。

• 算法保持不变，改变Input和算法超参数，又称为超参优化，auto-sklearn是一种方法，在给定一个数据集和期盼最小化的指标（如auc,logloss等）的情况下，autosklearn完全可以出给适当的模型和对应的输入超参，使得对应的指标在指定数据集下最小，比如决策树中树的数量和深度等等。

• 全部改变，在最新的数据上搜索最优的算法及算法超参数，auto-keras是一种方法，其提供了一系列函数来自动搜索深度学习模型的网络和超参数。

除了上面提到的，相信你还能发现更多提升的方法，但无论如何，这些仅仅是提升数据挖掘效率的“术”。但你的“术”再好，如果没有天时地利人和的配合，也很难有所作为，毕竟大多数公司没有阿里这种环境。

即使在大数据、人工智能如火如荼的现在，能否拥有良好的数据文化、能否找到一个正确的方向、能否获得上级的持续支持、能否发现足够多的应用场景、能否具备快速迭代的环境，很大程度上决定了数据分析师的成败。