Bright LGM's Blog

在最近的一个客户项目上，为了做性能优化，我们花了大量的时间，然而最终结果还是不够理想。我们的场景是实现特征处理过程和机器学习模型线上推理服务。由于用户量巨大，我们需要做到2万的TPS，每个请求需要在30ms内返回，且每个请求中包括对1000个项目的处理过程。

我们所使用的技术栈是spring和grpc。在经过极致的代码优化及内存调优之后，运行在一台32GB内存64核CPU的服务器上，我们发现90%的请求可以在25ms完成。但是如果观察99%的分位线时，响应时间就下降到了70ms，有时候还可能超过100ms。

为什么会出现上面这么明显的波动呢？问题出在java的gc上。其实对于gc，我们已经非常仔细的做过调优了，整个过程没有full gc的发生。然而，在持续的压力测试下，java的young gc却在频繁的工作。由于处理的数据量过大，新生代的gc几乎每秒都会触发一次，每次释放5GB内存，耗时30ms左后。

在前面的文章中提到我们在一个高性能场景中尝试了rust，那么它的效果如何呢？

在这次rust的尝试中，我们实现了一个通用的特征数据处理框架，并实现了几个常用的算子。这个数据处理框架目标是实现 Spark ML pipeline 的在线计算，为机器学习模型的在线推理场景提供特征处理。

我们选用了两个rust的grpc框架对外提供服务。它们分别是grpc和tonic，前者是基于线程池的实现，后者是基于rust异步模式async/await的实现。实验过程发现两者性能相差不大，tonic稍好，快2ms左右（不到5%），这可能是由于其数据结构设计更为精简带来的。

为了更有参考性，我们直接进行端到端的测试（用grpc客户端发起请求，在客户端采集数据），并与scala版本的实现进行性能对比。下面的结果中，服务端应用均部署在同一台64核心+32GB内存的服务器上，客户端也在此服务器上发起请求。由于数据处理的逻辑一致，客户端使用同一个java版本的实现。

作为一个非专业c/c++开发人员，相信很多人跟我一样，常常会在跟c/c++打交道时碰到困难。然而，我们所使用的很多底层的库或软件，却有大量是用c/c++编写而成。所以，了解一些基本的c/c++知识对于非专业c/c++开发人员将非常有帮助。

在下面这些典型的场景中，我们可能会需要用到这些知识：

• 当由于平台需要，我们需要自己编译某些c/c++项目
• 当需要在非c/c++程序里面进行少量的c/c++开发，并与c/c++代码交互
• 遇到一些常见的库找不到、版本不兼容等问题

本文尝试总结一下基本的c/c++知识，包括常见的平台、静态库/动态库的原理、基础编译指令等。并将结合一些实例来加深理解。

作为机器学习的一个细分领域，CTR预估一直以来都是研究的一大热点。之所以成为研究的热点，是因为推荐领域巨大的商业价值。无论是我们每天通信用的微信QQ，还是我们每天搜索用的Google百度，或者是娱乐用的抖音斗鱼，广告在这些产品的收入中都占据着非常重要的组成部分，广告收入的背后是广告推荐引擎在发挥作用。除了广告，我们网上购物时的物品推荐，看新闻时的新闻推荐，听音乐时的音乐推荐等等，这些都是推荐引擎发挥作用的地方。在这些地方，推荐引擎都产生了巨大的价值。

对于如此重要的一个领域，我们做机器学习的小伙伴多多少少都需要了解一下。下面我将结合一个项目上的实际案例，来分享一下整个CTR的研究和应用情况。我将尝试尽可能用通俗易懂的语言，使得只要有一些基本的机器学习知识就能理解文章内容。文章将从应用角度出发，重点关注基本原理及工程实现而弱化更偏理论的公式推导等。

本系列文章将分为以下几个部分：

• 概览：背景，研究的问题，技术架构及演进，一个小的例子
• 传统模型：协同过滤、LR模型及其应用
• Embedding、深度学习模型及其应用
• FM与DeepFM
• DCN及其他深度模型
• 基于LSTM的模型：DIN、DIEN及DSIN
• 多任务模型

一个项目越复杂，架构的作用就越显得重要。这就跟收拾家里面的东西一样，如果我们只有为数不多的几件物品，即便我们随意摆放，也不会妨碍我们找到想要的东西。但是随着购置的物品越来越多，如果不设置一套摆放规则，那么想找到东西就可能会花费大量的时间，效率低下。在我看来，架构就像这样一套摆放东西的规则。规则设置得好，屋子里面的东西将摆放得井井有条，我们的生活不仅将更高效也将更舒适顺心。

在最近的一个项目上，我们和客户一起建设了一个机器学习平台。对于某一个机器学习项目，最重要的四个部分是特征处理，模型探索，模型训练与模型推理。构建一个平台的目的是将这四个部分中通用的能力沉淀下来。一个成功的平台可以为新的机器学习项目提供基础设施，让项目快速起步，还可以使得项目组更专注在模型优化上而提升模型迭代效率。

随着系统功能越来越多，系统的配置也越来越多，配置管理成为了一个重要的问题。做过线上运维的同学们一定对配置的复杂性有深刻体会，多少次加班都是因为一个配置不对而导致系统无法正常工作！配置问题由于难以建立有效的自动化测试而难以检测，常常使得我们不得不花费数小时甚至数天来调试才能找到配置上的问题。

对于分布式计算，这个问题变得更加突出了，熟悉分布式大数据处理的同学们对于分布式任务的复杂配置一定深有感触。分布式系统本身的复杂性常常使得单个组件的配置就有上百个。而在微服务架构流行的当下，我们的系统越来越多以分布式的形式出现，系统的配置管理问题也越来越突出。

本文尝试分享一下我们在构建机器学习平台时对于配置管理方面的设计实践。

面向对象的程序设计思想多年来一直是我们进行软件设计的有效的指导思想。由于我们天生理解大自然的机制就是面向对象的（比如我们到了某一个商店，我们会看到门店、售货员、货架、货架上的货物等等，这些都是一个一个的对象，我们认识整个商店也就是去认识商店中的每个对象。），而面向对象程序设计思想恰好与这一机制相一致，所以一个面向对象设计做得好的系统就很容易为我们所理解。

对于一个机器学习平台，应该如何实践面向对象程序设计思想呢？

面向对象的抽象

回顾前面两篇文章的内容，机器学习平台具备这样的架构：

在当下很多的应用场景中，我们常常会想要应用具有一定的灵活性，以便我们可以在线调整计算逻辑，而不需要重新发布应用。这可能也可以称为以极限的速度发布软件的方式。

AB测试可以说解决了一部分这样的需求，使得我们可以在线的针对部分用户改变应用的行为。但AB测试需要我们预先定义并实现两套逻辑，然后通过线上配置来应用不同的逻辑。显然，在可自定义的程度上，AB测试是非常弱的。如果我们想要更大规模的调整应用的逻辑，AB测试就不够了。

说起银行贷款，我们绝大多数人应该都用过这个业务。比如，我们上大学，不少人办理过国家助学贷款。看这个贷款名字，好像跟银行没什么关系。但其实办理过这个贷款的同学都知道，这个贷款是我们跟银行产生的一个借贷关系。我们需要跟银行签订贷款合同，毕业后还款也是向银行还款。只不过因为是助学性质，国家会有一定的优惠贴息。再比如，我们买房，现在房价很高，对于一个主要靠自己的收入作为买房资金来源的同学，不贷款几乎不可能。不管是商业贷款还是公积金贷款，这里面都是银行在提供贷款业务。对于个人经营需要，企业发展需要，银行贷款就更是少不了了。

以下是一组某电商应用消费数据，你能从中看出什么？

我们应该能很容易的注意到：