发布于: Nov 30, 2022
【概要】在这个博客中，我们将带领大家了解 TalkingData 部署的模型，以及他们是如何利用 DJL 在 Apache Spark 上实现生产环境部署深度学习模型。
用户行为分析式机器学习的一项成熟应用，TalkingData 是一家总部在北京的数据智能服务提供商，通过提供数据智能产品和服务，来帮助企业获得对消费者行为、偏好和倾向的洞察。TalkingData 的一项重要服务是基于机器学习的用户行为分析：通过分析用户信息，可以为用户提供更具有价值的广告。比如有一个汽车经销商想要为想买车的用户投放最近的促销信息，他可以通过这个产品来找到在未来三个月有买车倾向的用户群，进而定向投放广告。最开始，TalkingData 的模型是基于 XGBoost 构建的。后来随着技术演进和精度要求的提升，TalkingData 研发部门进一步开发了基于深度学习模型的应用。经过实验以及测试论证，他们的数据科学家成功用 PyTorch 将模型的 recall rate（recall rate 是模型在阈值下是否能够提供推理的比例）提升了 13%。换句话说，相比于传统机器学习模型，他们的深度学习模型在基于相同的精度情况下可以带来更多的深度学习推理结果。
但是 TalkingData 在大规模部署深度学习应用中遇到了很大的挑战：模型需要每天对数亿的数据进行深度学习推理。为了能够更高效地进行大规模计算，他们使用了基于 Apache Spark 的大规模分布式架构来快速批量推理。可是，由于 Spark 主要是基于 JVM 的框架，使用 Python 应用 (PySpark) 进行深度学习推理往往会造成内存溢出问题。因为基于 JVM 本身的内存管理很难去对一个 Python 的进程产生影响。在过去，因为 XGBoost 对于 Java 的支持，TalkingData 可以使用 XGBoost Java API 在 Spark 平台进行部署。现今使用了 PyTorch，由于没有一个很好设计的 Java API，以及各种内存溢出问题，他们没有办法在 Apache Spark 上调用 PyTorch 模型进行推理任务。这导致了他们被迫转向使用一个 GPU 的实例来单独进行深度学习推理，这种方案大大增加了后期维护成本。
通过这篇文章，TalkingData 发现了 Amazon Web Services 基于 Java 开发的深度学习框架 DJL (Deep Java Library) 可以很好的解决上述的困境。在这个博客中，我们将带领大家了解 TalkingData 部署的模型，以及他们是如何利用 DJL 在 Apache Spark 上实现生产环境部署深度学习模型。这个解决方案最终将之前的生产架构简化，一切任务都可以在 Apache Spark 轻松运行，总时间也减少了 66%。从长远角度上，这也显著节省了维护成本。
该模型为一个用于推断活跃用户是否有可能购买汽车的二分类模型，使用的特征来自于嵌入 TalkingData SDK 的应用收集的数据。在将原始数据聚合和处理的过程中，特征不可避免地会成为稀疏的分类特征。当 TalkingData 使用传统的机器学习模型（例如逻辑回归和 XGBoost）时，这些简单的模型在从这些稀疏的特征中学习的过程中很容易过拟合。 另外，考虑到数以百万计的训练数据可以支持更复杂，更强大的模型，TalkingData 将其模型升级为了 DNN（深度神经网络）模型。
在合规性前提下，TalkingData 模型将用户信息、用户应用信息和广告事件作为输入。用户信息包括设备名称和设备型号，用户应用信息包含嵌入 SDK 的应用包名，广告事件信息是用户参与的广告活动信息。这些不同域的输入根据时间聚合，然后预处理成分类特征，预处理包括标记化（tokenization）和规范化（normalization）。 受 Wide and Deep learning 和 YouTube Deep Neural Networks 的启发，首先将分类特征根据预先生成的映射表映射到对应的索引，截断或添补为固定长度，然后再输入到 PyTorch DNN 模型。模型基于对应每个域的词嵌入进行训练。嵌入 (embedding) 是一种用数值向量表征分类变量的方法：用于降低稀疏的分类变量维度。例如，百万维的类别特征可以用几百维的向量表征，实现模型特征的降维。然后对不同域的嵌入简单的求平均，再拼接成固定长度的向量，喂入前馈神经网络。在训练过程中，最大训练轮数设置为 40，提前停止轮数设置为 15。与 Spark XGBoost 模型相比，DNN 模型在测试集上的 AUC（Area under the ROC Curve）提升了 6.5%，期望精确度下的召回提升了 26%。考虑到 TalkingData 巨大的数据量，DNN 模型的结果很不错 。
虽然模型的效果很令人满意，但是部署深度学习模型成为了很大的困难。由于生产环境中主要的代码都是基于 Scala 的，直接部署 PyTorch 在 Scala 上面临着内存溢出的挑战：JVM 的资源回收系统无法看到 C++ 所使用的资源 (底层 PyTorch API)。为了避免频繁的任务失败问题，最终 TalkingData 选择使用了单独开启一个 GPU 的实例来做离线的大数据推理任务。
但是，这个解决方案没有很好的解决下面几个问题
- 性能问题：下载和上传数据需要花费大约 30 分钟时间
- 单点故障问题：无法使用类似于 Spark 的多点计算功能。推理任务完全在一个单 GPU 的机器上进行，如果出现任务失败，那 GPU 本身没有回退机制可以良好应对。
- 维护问题：生产环境中需要同时维护 Scala 和 Python 两个环境
- 扩展问题：如果数据量再增大一些，单 GPU 的处理性能可能不足。
总体的数据量大约几百 GB。总体任务在上述框架下需要 6 个多小时才可以完成，比 TalkingData 预期的时间超出两倍。这个设计最终成为了整个生产环节的性能瓶颈。
相关文章