大数据时代：

工程师们应该如何应对大数据时代的到来

2016年2月2号晚上，旅美科技协会硅谷分会邀请到“今日头条”的技术副总裁杨震原先生到硅谷做客，请他聊一聊自己眼中的大数据时代和数据背后的故事。杨震原先生介绍了工程师在大数据时代应该如何拥抱变革、改变思路等一系列值得我们思考和学习的事情。诠释“今日头条”都是如何根据各种收到的数据进行调整产品的。在大数据越来越多、硬件进步速度减慢、应用越来越多的情况下，我们尤其是工程师应该如何应对？

工程师们如何应对大数据时代的到来

先给大家讲网上段子。我们把大数据比作什么呢?高中生的初夜!问问大家，有谁的初夜是在高中的呢?凡是举手的人都有做大数据的潜力，现在每个人都在讨论大数据，就像高中生都在讨论性，你做过吗?没有人做过，每个人都以为自己做过，每个人都声称自己做成，这是一个很有意思的事情，用这个来比喻大数据非常的恰当。

其实从一点就能感知大数据在身边，我们每个人都在使用手机，手机上的传感器是越来越多，也越来越快，除了录拍照，医疗的传感器加入后就可以知道你的心跳、地理位置等都会被记录下来。

       而我们要把以前没有办法记录的数据都要记录下来，以前无法分析的数据都要去进行分析。比如大家的点击行为，所有的交互行为，所有行为的时长，都记录下来。之前采样的目的就是用最少的数据得到最多的信息。当我们可以获得海量数据的时候，它就没有什么意义了。数据处理技术已经发生了翻天覆地的改变，但我们的方法和思维却没有跟上这种改变。 但是在很多领域，从收集部分数据到收集尽可能多的数据的转变已经发生了。如果可能的话，我们会收集所有的数据，即“样本=总体”。

       再给大家举一个例子，这是一个按钮平均触摸的时间分布，差不多是在44-112毫秒，每个按钮触摸时间是不一样的，大家觉得这个信息有用吗?也许没有什么用，但有一个研究机构表明，从一个用户接触的时间和面积的分布，我们可以推断用户按这个按钮时的情况。比如说一篇文章放了一个按钮，通过这个按钮的行为就知道有多少人是喜欢还是讨厌，像这样的记录很多人是之前没有想过的。

       还有个美国的研究机构实验，通过手指来按压摄像头，就是把手机做在线的课程，手机的背后都有LED灯，把灯打开之后用手指遮挡住摄像头和灯可以记录你的心跳，甚至知道血液颜色的变化，间接获得心跳图。这样就可以知道学生是否在看这个图，是不是感兴趣还是开小差。

      回到今日头条，对于阅读行为，我们以前会记录每篇文章在头条阅读的时间，而现在我们换一种记录方法去看某一页停了多少秒，又停留了多少秒，我们会把这个序列记录下来，可以推断这个用户是否读懂这个文章。这些行为的记录都是非常有价值的，在新的时代大家要去知道以前不能够记录的东西，没有用的东西，当这些都记录下来，未来某一天都会很有用的。

       我们的分析的方法发生了变化，主要两方面因素，第一，产品应用越来越广泛了，有场景能够去用到这些数据;第二，我们分析数据的方法也越来越多。举例：搜索展示量与点击数是千亿量级的，在早期大家怎么样来用?就是要点击调权，如果说一个问题点击的次数很高就往前排，当分析方法没有那么进步的时候我们就用这种方法来做，这个方法有局限性，对于这一块有效，但是对于频次低的就没有效了。

       现在随着神经网络算法发展，系统可以去训练100亿、甚至1000亿的用户浏览、点击行为数据，去主动学习用户查询与文章题目的内在关联，我们取得的收益是什么呢?整个团队34%的收益来自与这个项目，这是非常重大的改进，就是通过了计算方法的变化，使得我们能够去分析这么大规模的数据。

       再举一个今日头条阅读时长变化的数据，我们为什么可以改进阅读时长呢?我们通过数据的分析，把用户的行为数据全部都记录下来了，我们知道用户点了什么内容，将用户的行为和行为特征进行组合，最后仅30天的数据就达到了1.5PB，这样的数据对今日头条来说需要大量计算资源才能够处理。

       通过充分的对数据的使用提高了用户的使用时长，更多的数据、更多的分析方法和应用的领域，这些就构成了大数据时代。

我们来看一下系统的硬件在最近几年的变化。2005年到2015年CPU在计算性能的提升区域，从2010年开始性能提升的曲线没有那么的高了。单靠CPU能耗比的提升速度是在显著衰减的，所以说摩尔定律已经宣告失效了，工程师依靠硬件红利的时代已经结束了。

       数据越来越多，应用越来越多，硬件进步的趋势减慢，这就构成了大数据时代工程师面临的挑战。如何面对?

      我的应对思路是，工程师要变成一个个全栈研发，要通过更加广泛的学习，成为全栈研发才是未来的解决之道。当局部可以大幅度的改进时，更细的分工才会显示出优势，否则只有全栈综合考量才能找到突破点。

在之前IT时代，有人去做CPU，有人去做UI的改进，大家的分工非常的细，比如说像以前做手机，从硬件，芯片，操作系统，交互，应用每一个都要去关注和打磨，这种很细的分工还能前进是因为每一块都有大幅提升空间。而现在CPU过一年就淘汰了，手机一年已经更新换代了，如果我们还是保持更细的分工不能够把握整体提高，这要求我们必须要不断学习才能够带来突破。

       从CPU指令集到操作系统，从Hadoop到统计原理，从机器学习到产品应用，只有通过学习才能够找到突破点。下面举三个例子来详细说明。

(一)系统工程和细节的交叉点

第一个例子，先介绍背景：今日内容推荐很重要的一部分就是针对你可能感兴趣的候选集进行排序，这部分核心就是建模，将用户各种组合偏好记录下来。哪些keyword表达了该用户的特点。

头条的推荐算法分两层。最上面一层，一个大的推荐模型，就是说模型做决策依据的维度，包括性别、年龄、兴趣等都是维度，我们有数百亿特征，涵盖你能想到的一切可以帮助做判断的信息，这个还在不断的增加，还有一层就是推荐召回模型。

那如何解决特征爆炸的问题。这个问题在机器学习领域解决思路有多种，比如通过Sample数据，1 可以L1正则，2 稀疏化特征，3 特征过滤，4 Hash，5 做16 bit的压缩。

这里讲特征过滤怎么做：我们有3T的Uniq Key，任务就是去统计并过滤掉频次在8次以下的Key。很直观的方法就是使用Hadoop去掉低频的，因为你偶尔看到一个词，大量的都是低频的，而劣势就是无法流式计算，当把这个做完，就超过了模型的时间。

我们来看第二个方案，内存的HASH表，当走过一遍数据，维护一个内容的表。每次去查一下，如果说出来6次了，现在第7次了，我们把超过了7次的全部都统计下来，其他的都扔掉，这里有一个就是规模问题，一个HASH的结构，一个Key要占用40 bytes，40 bytes会有指针消耗和对齐问题。如果我们有200台机器，单机需要600G的内存，现在很多的机器都不支持这个内存，那么怎么样来做?

方案三是谷歌在用的一个方法，使用的是Bloom Counter，不要求完全精准过滤。其实就是用多bit的Bloom Filter，我们又叫做Counting Filters。频次是小于等于7，需要3bit，在冲突率约1.5%的情况下，需要6次探测，单bit bloom filter大约是8.66bit。但我不喜欢Bloom Counter 这个结构，因为它对CPU非常不友好，大范围随机访问，远远大于真正计算的时间。有没有更好的做法呢?

我们用了很简单的方法，效果非常好。就是开放地址的Hash ，但不是冲突了之后直接放下一个，基本情况是最大的填充率50%，Key大小 16bit，单机30G内存，冲突率和Bloom Counter想到。这里需要注意一下，我们去查一个东西的时候，就是一个表的指针，之后用第二个函数来算，如果说找到冲突之后，我们就用到一个Hash。这个HASH函数与普通的不同，是一个有损的HASH ，这个有多大的好处呢?它是Bloom Counter性能的6倍，因为它只需要一次访存，这个事情就使得我们对模型训练的时间，总体提高到了原来的2倍，当我们在万兆的网卡上，不到20个小时都可以传完，而这些都和工程相结合起来，找到结合点的时候就把规模进行提升，这些提升所带来的效果是很大的。

(二)理论研究和实践的结合

第二个例子是理论研究和实践的结合。

特别是做在线学习，应用LR(Logistic Regression)是最广泛的。但是批量处理超大规模的数据集和在线数据流时就遇到了问题，离线机器学习方法在每次迭代计算的过程中，需要把全部的训练数据加载到内存中计算(计算全局梯度)，传统batch算法中每次迭代对全体训练数据集进行计算(计算全局梯度)，优点是精度和收敛还可以，缺点是无法有效处理大数据集(此时全局梯度计算代价太大)，且没法应用于数据流做在线学习。

对于一个LR Model来讲，使用不同的学习速率、正则项系数导致收敛的效果是不同的。这当中初始的学习速率还是会带来很大的影响。除了Weight的参数之外，还有学习率、L1等的超参数。总之手工调参是非常困难的问题。

由于头条的训练样本很大，不同特征之间的频次相差非常大，有多大的?会相差7个数量级，有些频次是几千万次，而有的出现频次只有20、30次。所以针对不同类型的特征我们有不同的超参数。特征的类型我们是按照特定的规则来分有上百个，每个特征的类型都有正则率和特征参数，这样我们就几百个参数，这个是没有办法调整的，这个事情是不能够训练的，这是一个很痛苦的问题，有什么解决的方法呢?

在这一块我们是有创新的。大家想一下，超参数的本质是什么?就是要去寻找过拟合和训练不足之间的最佳的平衡点，我们训练是在一个训练集之中去做优化，在线上的集合之中去测试，而这两个数据集的分布是不同的，超参数优化主要用在自动搜索模型的参数，要做到在上线的情况下最优。我们把数据分为训练集验证集和测试集，我们在训练集之中去优化参数，在验证集中去优化超参数，目标是降低验证集的Loss(简单的在线梯度下降很难产生真正稀疏的解，稀疏性在机器学习中是很看重的事情，尤其我们做工程应用，稀疏的特征会大大减少predict时的内存和复杂度)，这是更加的接近线上的分布，我们找到最优点，同时这个方法是服务做好的。

在FTRL(Follow-The-Regularized-Leader 算法由Google在2013年KDD上发表)下，超参是可以导的，这是最有意思的事情。这个L1正则项梯度，这个是可以求出来的，对L2的正则项也是可以求出来的，所以我们就有自动调参的流程，来算出更新，然后在验证集中去验证，用到这些相应的方法，如何去把验证集去进行训练，这是有讲究的，如果验证集太近和太远都是不好的，这些都是细节的问题。

学习中的验证怎么调?

做这一块最头痛的事情就是调参，但是我可以把几百个参数变成只有几个——参数可以调了，这个事情我们已经把它实现了并且在头条上全面的上线了，取得了什么效果呢?就是我们的离线评估AUC有2.2个绝对百分点的收益，在线的CTR有7.5个相对百分点的收益，这是非常重大的改进。

这个项目不仅仅有一个很好的实际效果，在算法的领域上也有一定的突破，我们之后也打算把这个整理一下，在期刊上去发一个Paper。

(三)算法和产品，UI的结合

第三个例子，算法和产品，UI的结合。头条不仅仅有文章还有视频，视频的低质内容的控制是很重要的，我们有很多的办法去改进这个问题，比如一些账号去评级，通过账号订阅的比例，效果都不好，之后我们用了一个很简单办法，效果会大幅度的提升，我们在视频播放的列表页放出了顶踩按钮，通过简单的加入顶踩的数据的统计，会对低质的打击效果明显提高。这就是一个很简单的，就是和产品结合，技术的方案就是要解决问题。你有简单的方法去解决问题这才是更有意义的创新。

就是做A/B测试，把实验对象随机分组，把一个或多个测试组的表现与对照组比较，进行测试。

怎么做A/B测试，第一步我们线上流量进行分流，正常用户还是走正常的流量，一部分流量我们要保证样本无偏，通过科学方法去划分出一些流量做实验，还要进行分组，分出对照组和实践组，对照组和线上的策略完全一样，实验组我们做一些小小的改变。

比如头条网页版的首页，新版加了一个链接，老版加了一个任务评论。我们看哪个好呢?通过A/B测试的方式，一部分人看到新版的结果，一部分是老版效果。事后统计分析，看到底哪个版本效果好。

还有叫做双盲交叉验证。它是说在评估一项数据的时候，我可以把一部分样本抽样，让其他人再评估一下。根据抽样数据评估的一致性来判断该评估的可靠性怎么样，比如你审一些黄色反动的文章，机器做得再好，必须有人来把关。

我们看一下交叉验证在头条是怎么实现的。交叉验证用的最多的场景涉及到人工运营的场景，在头条刚才提到有些业务需要人工的评估。因为你文章如果分类分不准的话，可能就会影响你的推荐。有很多东西要人去审的，审核和评估都有一个问题，什么问题呢?它依赖人。

大家印象中人比机器靠谱的，从大的面上来说，机器比人更靠谱，机器不求回报。在互联网公司，审核和评估投入这块肯定比工程师低很多，这就造成两个后果，第一个就是审核人员敬业或者他的能力上可能跟工程师相比，他会有一定的差距，这是客观存在的。因为我们的人力成本也比较低。

第二个就是他的流动性可能比较大，另外标准经常变来变去。我们一定要用机器去监控人的工作怎么样，需要有一个预警。这块我们需要引入一个双盲的交叉验证，帮助我们去看这些运营同学他们工作的稳定性怎么样，同时去激励不断提升自己的判断力，得到机器更好的评估。

数据实验是怎么分析的，先把数据拿过来，再做日志处理，存到日志，发到服务端，这需要一个很好的数据可视化的系统，因为出来数字，大家看着也不方便。给产品经理给高层老板看一堆数字很烦，看曲线就好了。

最后在大数据领域还有哪些技术可以交叉呢?

比如说硬件的交叉，在新的硬件领域还有非常多创新的点。比如说现在的传感器的技术，比如说神经网络很多的做法是嵌入到芯片之中去的，分布式架构和机器学习算法的交叉，商业智能分析与新算法的交叉，这是一种用语言来画图做引擎，和我们做一些编译器和新的语言都有关系，有一些交叉。

这些交叉是诞生新想法非常重要的一部分。最重要的一个交叉就是什么呢?把技术和人们的需求的痛点相结合，进而产生更多的产品，所以每个创业者是更棒的创新家。在大数据的时代下，有太多的需要学习的，现在最难的就是找到优秀的工程师，这说明工程师的不可替代性和行业的繁荣，我想这就是工程师的时代也是在座每一个人的机会!