美团是如何应用Spark处理大数据的？( 二 ) _Spark

文章插图

由于Hive表中的数据量一般较大，使用单机程序读取数据和写入Tair效率比较低，因此部分业务方决定使用Spark来实现这套逻辑。最初由业务方的工程师各自用Spark程序实现从Hive读数据，写入到Tair中(以下简称hive2Tair流程)，这种情况下存在如下问题：
每个业务方都要自己实现一套逻辑类似的流程，产生大量重复的开发工作;
由于Spark是分布式的计算引擎，因此代码实现和参数设置不当很容易对Tair集群造成巨大压力，影响Tair的正常服务。
基于以上原因，我们开发了Spark版的hive2Tair流程，并将其封装成一个标准的ETL模板，其格式和内容如下所示：

文章插图

source用于指定Hive表源数据，target指定目标Tair的库和表，这两个参数可以用于调度系统解析该ETL的上下游依赖关系，从而很方便地加入到现有的ETL生产体系中。
基于Spark的用户特征平台
在没有特征平台之前，各个数据挖掘人员按照各自项目的需求提取用户特征数据，主要是通过美团的ETL调度平台按月/天来完成数据的提取。
但从用户特征来看，其实会有很多的重复工作，不同的项目需要的用户特征其实有很多是一样的，为了减少冗余的提取工作，也为了节省计算资源，建立特征平台的需求随之诞生，特征平台只需要聚合各个开发人员已经提取的特征数据，并提供给其他人使用。特征平台主要使用Spark的批处理功能来完成数据的提取和聚合。
开发人员提取特征主要还是通过ETL来完成，有些数据使用Spark来处理，比如用户搜索关键词的统计。
开发人员提供的特征数据，需要按照平台提供的配置文件格式添加到特征库，比如在图团购的配置文件中，团购业务中有一个用户24小时时段支付的次数特征，输入就是一个生成好的特征表，开发人员通过测试验证无误之后，即完成了数据上线;另外对于有些特征，只需要从现有的表中提取部分特征数据，开发人员也只需要简单的配置即可完成。

文章插图

在图中，我们可以看到特征聚合分两层，第一层是各个业务数据内部聚合，比如团购的数据配置文件中会有很多的团购特征、购买、浏览等分散在不同的表中，每个业务都会有独立的Spark任务来完成聚合，构成一个用户团购特征表;特征聚合是一个典型的join任务，对比MapReduce性能提升了10倍左右。第二层是把各个业务表数据再进行一次聚合，生成最终的用户特征数据表。
特征库中的特征是可视化的，我们在聚合特征时就会统计特征覆盖的人数，特征的最大最小数值等，然后同步到RDB，这样管理人员和开发者都能通过可视化来直观地了解特征。另外，我们还提供特征监测和告警，使用最近7天的特征统计数据，对比各个特征昨天和今天的覆盖人数，是增多了还是减少了，比如性别为女这个特征的覆盖人数，如果发现今天的覆盖人数比昨天低了1%(比如昨天6亿用户，女性2亿，那么人数降低了1%*2亿=2万)突然减少2万女性用户说明数据出现了极大的异常，何况网站的用户数每天都是增长的。这些异常都会通过邮件发送到平台和特征提取的相关人。
Spark数据挖掘平台
数据挖掘平台是完全依赖于用户特征库的，通过特征库提供用户特征，数据挖掘平台对特征进行转换并统一格式输出，就此开发人员可以快速完成模型的开发和迭代，之前需要两周开发一个模型，现在短则需要几个小时，多则几天就能完成。特征的转换包括特征名称的编码，也包括特征值的平滑和归一化，平台也提供特征离散化和特征选择的功能，这些都是使用Spark离线完成。
开发人员拿到训练样本之后，可以使用Spark mllib或者Python sklearn等完成模型训练，得到最优化模型之后，将模型保存为平台定义好的模型存储格式，并提供相关配置参数，通过平台即可完成模型上线，模型可以按天或者按周进行调度。当然如果模型需要重新训练或者其它调整，那么开发者还可以把模型下线。不只如此，平台还提供了一个模型准确率告警的功能，每次模型在预测完成之后，会计算用户提供的样本中预测的准确率，并比较开发者提供的准确率告警阈值，如果低于阈值则发邮件通知开发者，是否需要对模型重新训练。
在开发挖掘平台的模型预测功时能我们走了点弯路，平台的模型预测功能开始是兼容Spark接口的，也就是使用Spark保存和加载模型文件并预测，使用过的人知道Spark mllib的很多API都是私有的开发人员无法直接使用，所以我们这些接口进行封装然后再提供给开发者使用，但也只解决了Spark开发人员的问题，平台还需要兼容其他平台的模型输出和加载以及预测的功能，这让我们面临必需维护一个模型多个接口的问题，开发和维护成本都较高，最后还是放弃了兼容Spark接口的实现方式，我们自己定义了模型的保存格式，以及模型加载和模型预测的功能。