大数据产品的特点和要素

导语：随着近年大数据题材越来越火，每个公司每个平台都想借大数据的Volume、Variety、Value、Velocity推动自己的业务，提升自己的竞争力。其实大数据产品由来已久，今天笔者就来谈一谈大数据产品的特点和要素。

在谈论特点和要素之前，先聊聊什么是大数据产品，这是个仁者见仁智者见智的问题，由于其特点过于抽象，每次解释都很困难。业内人士问我的工作内容时还比较好回答，谦虚的时候我会说做做数据，吹牛的时候我会说跑跑模型，尤其是这几年随着大数据这个概念越来越火，往往一说到我做大数据大家就都多少有了些概念。

可对于业外人士这个问题就难解释多了，早年还在做网页搜索排序的时候，我就会经常撇开自己做的内容举电商的例子。我会说我做的事情就是决定你卖的东西能不能排在前面让别人容易搜到，而决定排名的因素有很多，比如价格、历史销售数量、好评数浏览量等等，一般这么讲对方就似乎懂了，觉得我做的事情听着靠谱。

正如很少有人正面定义大数据是什么而是每次说起大数据就是说4个V一样，更多情况我们选择从他们的一些特性刻画他们。所以，本文将要提到数据产品往往并不是一个具象的功能或者事件，他更多的是一个决策系统，指导各个功能根据不同的场景完成最佳的响应。所以搜索引擎，反作弊反欺诈系统，推荐引擎，兴趣点/主题提取系统当然都是我要讨论的大数据产品，而广义上讲的一些数据产品，比如数据词典类的黑名单白名单，报表，OLAP, ETL，数据流等等则不在讨论范围之内。

从特性上讲，我今天要谈的大数据产品往往具有概率的准确性，自适应性和闭环性等特点。

所谓 概率准确性 就是说无论如何积极的使用最新最高级的算法，无论如何实时的更新模型，无论多么努力的清洗数据总会很多bad case掺夹其中。如果以工程的角度把这些负例当bug来看，那么这个bug可是无穷无尽永远修不完的。所以数据产品往往只能做到高概率的正确，在很多场景就足够好了。之所以要强调这一点，我认为这可以说是大数据产品设计的世界观之一了。

做软件开发，网站应用开发或者是数据流等工作很多年的人对准确的定义往往更加严苛。对他们来说，自己的产品离准确度达到100%也许也总有差距，可一个产品只达到80%的准确性就沾沾自喜了实在让人难以理解。

可是”泛泛来讲”，能达到80%准确的大数据产品已经相当不错了，很多投入无数人力物力数十年的技术积累也难将准确度提高个10%。所谓“泛泛来讲”原因就是大数据产品所要解决的问题本身对准确性的定义就很难衡量，以搜索引擎为例，相关性应该是衡量搜索结果好坏的最重要标准之一，从早期的tfidf, page ranking,到后来各种plsa, lda, wordvec2等技术的引入。我们还是明显的看到各个搜索引擎的相关性是在提高了，可是相关性的准确度达到80%了么？什么又是相关性的准确性呢？所以这些事往往只能比较出现在比过去做得好，可是何为进化的终极至少目前大多讲不清楚。

自适应性 就是指大数据产品一般不是一个发行版，执行着固定的逻辑不是静态的一成不变的，而是总是随着趋势的改变、数据的积累，适应着行为的变化而自适应的反馈出相应的结论。所以大数据产品是靠数据变得鲜活起来的，自身的逻辑只是给数据提供一个骨骼，支撑各个数据在各个位置发挥自己的作用而已。

所谓 闭环性 是指大数据产品的决策会直接影响业务的表现，业务的表现会提升用户的体验，而用户体验的改善又会更新数据的特性，最终数据不同又会使产品的决策不同。

那么性质差不多讲清楚了，开始讲讲各个要素吧

数据

巧妇难为无米之炊，但是光有原始数据也肯定是不够的，除了对数据量，数据质量和数据刻画能力的要求之外（以上因素往往受业务逻辑限制），对于大数据产品来说，涉及每一个元数据必须清晰到每一个细节并且很好地进行清洗。所谓清晰的到每一个细节，就是说对每一个数据库中的column或者日志中的字段，我们都要知道详细的定义，知道每个取值的含义，进一步的最好知道详细的计算逻辑。如果只是依赖文档当然是很快的一种上手的方式，但文档更新的滞后性往往造成了一些字段含义被误解。

比如有一个字段为了节省空间是用bit的方式存储的，文档可能是这样介绍的，该字段共用了两个bit分别表示两个地区是否命中一个逻辑，1代表命中。于是就可能出现了这样一幕，我们需要取第二位对应的地域的信息的统计结果时，某位工程师写了.filter( _ >=2)这样的简单易懂的代码，对两个地域来讲这个逻辑虽然不好但是不错， 但殊不知这个文档已经过时很久，其实已经是对应了四个地域，这个条件会将很多其它情况通过过滤。

所以每个数据项在知道定义之后，统计其最大，最小，null的数量，分布情况是一个基本而且必须的过程，如果有条件最好画一个一目了然的histgram或者boxplot更好。然后看每一项根据这个定义是不是可以解释。数据清洗的过程当然是基于了对每一个字段的理解深刻进行的。一个大公司往往会有专门的团队对于核心数据进行清理，即使这样，数据清理所占的工作量依然是巨大的，而对一个从raw data开始的大数据产品数据清理的工作量甚至可能会超过总工程量的80%

人

人也是我认为最重要的一条。而对于人的特性中我并不认为最重要的是技能或者背景，更多的我认为是怀疑和求是的精神。我和很多各种水平，各种背景的数据工程师工作过，有的可以对一些比较复杂的机器学习算法的每个细节侃侃而谈，有的甚至连线性回归的关键指标都讲不出来，但实际上从对一个产品的贡献度来讲后者未必低于前者。

所以一个不错的数据工程师，会机器学习算法当然好，但最重要的是有怀疑和求是的精神。我认为做数据，其实就是在抽象对世界的一个认知，讲真理什么的就讲远了，但是我们要不停的考虑数据的可解释性，策略结论的合理性，反面样例存在的原因。既要不停的用一般的common sense去度量每一步的数据，又要依赖数据工具和各种metrics去公正的评估策略的结果，还要相信数学模型得到的结论不停修正自己的世界观。

数据流的自动化搭建

这里所讲的数据流并不是单纯的数据采集清洗以及存储的过程，还包括了自动挖掘，特征提取，模型训练和模型发布上线的过程。这个因素给人的印象似乎和前面谈的不一致，这好像是在说纯工程上的问题。但在一些场景之下，数据模型的高速迭代对业务来说就是一个非常重要的改进。曾经在做一个项目里预估模型时，单是从每天更新一次的模型提高到了一天四次更新，在各方面线上表现就有了明显的提升。

所以在项目的初期，也许确实没有必要做到高频的更新，但设计中应该涵盖对这种时效的提升考虑。比如只要做大机器够多,MR数量够多，模型更新的频次就能增加，这样就算可以接收的设计。如果能利用一些data streaming技术如spark来做实时机器学习那就更牛了，可是也要具体场合具体分析，如果每天的业务量本身就有限，又何必搞那么复杂，过犹不及。但是无论如何，无论是data pipeline还是模型分布，中间任何一个环节需要人手工做某些事情是绝对不能忍受的。

重视线下和线上评估的设计

线下评估省钱省力省时间，可是线上才是检验真理的唯一标准，这也引入了三个问题，线上模型表现和线下训练数据处理的一致性，线上实验平台设计以及线下评估的不断完善。这三个问题每一个都可以展开讲很久，都是值得我们不断努力改善的方向。

选择适合的算法

这个只简单讲两句，未必复杂的高级的算法就是好的，未必别人的最佳实践就是可以复制的。选择算法的时候，对于自己精通的算法，即使简单只要用的恰当也许效果也相当不错，当然我们也不能故步自封在已知的领域，不停尝试新的技术也是推动大数据产品不停进化的动力。

明确方向和目标

之所以讲了这么多点才讲到似乎应该第一个讲的需求分析，就是大数据产品的不确定性决定的。要解决的问题虽然明确，但是解决的方法却不是唯一的，而且很可能是需要不停探索尝试才能解决的。我们每做一个原型，每做一个分析的时候只要不停的问自己，这个数据说明了什么，这个数据是否有用，这个方向是否可能跟要解决的问题在某个维度有一个小的夹角，这些工作都可能成为后来非常有意义甚至是决定性的因素。

人工干预

讲到这个点的时候，我犹豫了很久，因为这个点就像是要向大家介绍一个会给自己带来某些好处的劣习一样。一切大数据产品的最终形态应该是由数据和模型来阐述它自己而没有任何人工的因素。

我所经历的好多比较大的项目也都是在向着这个方向努力，可是不得不说，对于业务刚刚上线的时候，简单暴力的人工规则往往效果极佳，所以很多项目都是到了人工干预不再见效的时候才开始引入机器学习的模型，到目前为止我无法判断这是不是最佳实践，毕竟当初开开心心加入的规则在去除的时候则是万般艰难，各种规则的叠加造成了牵一发而动全身。但一开始就能做到毫无人工干预，让模型来解释自己是否又太过理想呢。

本文作者：单忆南（点融黑帮），现任数据产品团队资深数据工程师。 职业生涯一直从事大数据产品相关工作，曾参与过页面搜索引擎，搜索广告，电商垂直搜索引擎等项目。

End.