本公众号自开办以来，访问量最高的一直是"从今日头条的招聘广告浅谈推荐引擎"一文，这多少还是得感谢百万美元的标题党。本文发布没有几天，今日头条官方也做了自己系统用户画像部分的架构演讲，同时另一家日本的今日头条SmartNews（很难说谁抄谁，只能说个性化新闻阅读殊途同归）也在Slideshare上介绍了自家的原生广告（Native Ad）架构，所以就一并趁热打铁再跟进一篇小品文。
首先来看看SmartNews是如何弄他们自己的广告系统架构。至于为什么没有接入其他Ad Exchange我猜测除了不想肥水流外人田之外，另一方面可能也是SmartNews对普通DSP公司的技术实力没什么信心吧——毕竟在新闻中嵌入广告是个很影响用户体验的事情，如果该广告跟用户偏好又没什么关联，那真得有可能是得不偿失——渣浪在这上面的教训足够深刻。
从演示材料上来看，SmartNews是一家很有追求的机器学习公司，这表现在广告系统里的几个核心问题：
CTR/CVR预估
创意优化
预算控制Budget smoothing
Ad allocation optimization
用户画像
都是致力解决的问题，可惜的是，演示材料并未透露算法细节。本文在这里也没打算普及以上概念，不过做个小广告先，对广告技术感兴趣的同学可以购买由刘鹏和王超合著的“计算广告学”（即将出版），对广告技术问题都有清晰的描述，扯远了，来看系统架构图：
在交互式日志分析中，SmartNews选择的是构建于AWS S3之上的EMR，进一步的分析查询则采用可以直接访问HDFS的Presto。广告投放过程，利用Hivemall+EMR存放训练好的模型，DynamoDB存放用户画像数据以确保低延迟。模型的训练选择为Yarn+Hive+Spark，因此算法想必也是Spark MLLib里的大路货。
总体上干货比较少，唯一值得称道的地方在于SmartNews的整个infrastructure都构建在AWS上，做为一个大数据公司，敢于在云上构建自己的基础架构，这必须拥有优秀的研发团队，类似的例子还有Netflix。这样做的好处是显而易见的，因为可以大大降低运维团队的开销，从而所有的工程师团队只专注于自己的业务和算法。至于上面的几个层面的算法本身如何设计，持续关注本公众号肯定会有收获。
接下来再看看今日头条的演讲。在算法模型描述上着力点主要在用户特征的选取和去噪上。用户特征的定义主要分为几类：
人群特征：包括性别，年龄，地域
行为特征：新闻分类，新闻来源，关键词，命名体等。
针对特征的处理，可以想象到一定会加入点击加权以及未点击惩罚等处理手段，并且还需要考虑按照时间进行衰减。
尽管算法模型新意不多，但在系统架构上有几个数字令人印象深刻：存放用户画像的存储引擎吞吐量达到了1.2M qps，需要大批量写入用户数据，如果采用糙猛的批处理方法，那么针对每个用户的画像每天都需要根据该用户过去两个月的偏好重新计算并全部写入存储引擎，这意味着需要计算500T的日志大小（还是压缩后数据），结果很可能是当天的偏好在2天之后才写入到用户画像里，这显然是不可接受的。因此头条的做法是变批处理为流式增量作业，以10分钟为固定间隔更新用户画像，并对历史档案做时间衰减，同时批处理方法会定期使用以修正流处理增量算法引入的模型偏差。面对如此大的访问量，头条自己攒了一套存储引擎：拿twemproxy + rocksdb 来做主从结构，在硬件上为让rocksdb最大化发挥效果，磁盘完全采用SSD，并且为延长SSD使用寿命，还手动调整rocksdb的策略使得尽可能不发生merge操作——关于这一点本公众号会在以后的文章里专门叙述，这里只需要知道rocksdb这种存储引擎的LSM Tree结构，因为不得不引入反复的数据merge操作来提升读性能但却会引入写放大，结果在今日头条这种写入数量巨大的场景下SSD的寿命就会被大大影响，所以开发人员不得不牺牲部分读性能来获得SSD的尽可能少损耗，具体做法是：确保LSM Tree只工作在最低的2层——话说对于存储引擎这码事，确实不能眼光总局限在非B-Tree既LSM-Tree的常规视角，这么巨大的写入和读取，显然应当考虑Fractal Tree结构啊，当然这是题外话了。
拿这两份干货不多的slide点评凑一篇文章着实不太容易，不过它们都算前文的补充叙述。前段日子国内分别举办了Qcon 2015和DTCC数据库大会，其中今日头条的slide就是来自前者，本号会选取部分有价值的内容在后续进行点评 。
