Bright LGM's Blog

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

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

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

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

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

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

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

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

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

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

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

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

在最近的一个客户项目上，为了做性能优化，我们花了大量的时间，然而最终结果还是不够理想。我们的场景是实现特征处理过程和机器学习模型线上推理服务。由于用户量巨大，我们需要做到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左后。

作为我们使用最广泛的CI/CD工具Jenkins，它对于Pipeline as Code的支持却并不能算友好。在多个项目中使用之后，我发现它存在的主要问题有：

• Groovy语言的学习成本
• 调试低效
• 灵活性差

Groovy语言相对而言还是比较小众的。其设计为一种动态类型的语言，这给编译器、IDE的类型推断带来了困难，从而导致较弱的自动代码提示。除此之外，由于Groovy可以在没有歧义的情况下省略括号和行尾分号，并且如果最后一个参数是一个闭包则可以将其写在函数调用之后，这就导致了相对比较怪异的语法出现。比如，刚接触Groovy的人可能不太能一下子理解下面这段代码的工作原理：

1
2
3
4

a(1) {
    something(123)
    someother id: 1, message: "test"
}

昨天和项目组的几个小伙伴去爬山。这次爬山坐标深圳梧桐山。从西北门进山，我们沿着蜿蜒的公路一路而上，历时三小时登顶。下山时不想原路返回，故意选了另一条路。从山上往下看，这条路陡峭得很。不过，对于几个血气方刚的男性，这条路正好。因为大家都觉得上山太简单不过瘾，想挑战一下高难度。于是我们一致同意换路而行。我们走的这条路就是凌云道。

说起凌云道这条路，真是名副其实。它不仅几乎呈垂直高度下降，而且台阶较窄仅有半脚宽。路两边树丛虽然茂盛，但是都不高大，山下的情形总是能进入眼帘。我一向有点恐高，在这垂直高度近1千米地方往下看，还真是心里有点慌。刚开始下山，小伙伴们见此山势，纷纷停下脚步拍照。得几张无P图片如下，大家可以感受一下：

有一个技术人员都知道的很老的段子。如果我们想将一个技术论坛搞火起来，那么我们只需要发一篇帖子“php是世界上最好的语言”。虽然是很老的段子，但是就算现在我也常常能听到有人谈论它。很有意思的一个段子。

不仅仅是在论坛中，在我们日常的团队合作中，其实也常常有这样的事情。回忆一下我的 Code Review 活动，是不是常常有某一行代码引起了大家的广泛讨论，把整个会议给“搞火”了？大家可能就一个问题讨论很久，争执不下。

对于这样的讨论，如果大家能心平气和，互相理解，可能能较快的达成一致。但是事实上常常会出现这样的情况，双方争论很久争执不下，后来可能有人说，“这你都不知道啊”，或者“这我理解不了，你这里明显有问题”，或者“你说的都好，我用我的方式”，或者“你这里就明显是在#define true=false”等等。在这样的讨论中，我们比较容易情绪化（可能没有情绪化这么严重，但是这里姑且先用这个词），最后本来应该心平气和的讨论演变成了针对某个个人的互怼，或者直接拒绝交流。一旦情况变成这样，那么不仅讨论效率会大大下降，而且常常在相互心中产生芥蒂，影响后面的高效合作。

我时常在项目中听到一些经验稍欠缺的开发人员在Code Review时这么讲：

这里为了方便测试我抽取了一个纯函数，这个函数包含了主要的业务逻辑，测试覆盖率也比较高，我们可以认为这一部分质量不错。
使用这个函数的地方由于集成度高不好测试，我们就不做自动化测试了。

他的代码可能写成下面这样：

1
2
3
4
5
6
7
8
9
10

// some_file.ts
function someEasyToTestMethod() {
    ...
}

class A {
    someMethod() {
        someEasyToTestMethod();
    }
}

随着微服务和DDD的兴起，领域这个词逐渐成为了一个大家每天讨论中的高频词。对于经验稍欠缺的同学们，刚接触领域这个词，总会感觉有点神秘。到底什么算是一个领域呢？我们经常在谈论领域模型、领域服务、领域事件、领域边界等等，如果对领域概念没有一个清晰的认识，在接受这些相关概念上想必也会遇到阻碍。本文将结合我个人的理解以及一些实践经验来谈谈对这个概念的理解，希望能帮助大家更好的认识领域，进而更好的理解和运用相关的概念，最终更好的指导软件开发实践。

中台的概念从阿里17年开始提出来就快速成为了年度IT热词。阿里这样体量的企业的成功无疑论证了中台建设的正确性，让大家对于中台这样的解决方案跃跃欲试。而阿里顺理成章成为了中台的最好代言人，大家学习中台的榜样。那么什么是中台？事实上，对于中台的定义大家也一直在探讨中。阿里内部业务系统有其独有的特点，诞生其中的中台自然也带着阿里独有的特征，这一点从《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》这本书中我们也能读出来。直接复制阿里的中台方案真的能解决广大企业中的共性问题吗？可能未必，这应该也是当前大家关于数据中台有着各种各样的解读的原因。