从“数据说话”，”DT 时代”，到 “数据中台”，“数据驱动”，数据体系的不断演进正在持续的改变大家的工作与决策方式；正在不断的革新大家的思维方式；同时也产生了新的商业逻辑，新的发展机会。

目前数据科学自身的概念还在不断的变革，各家公司的实践者们一边摸索，一边获利；一边总结，一边布道；当然同时还参杂着很多凑热闹的同志把概念折腾的更加模糊。所以数据科学本身的能力边界，方法论体系，最佳实践等等还没有完善的建立起来，有很多问题没有办法很好的回答。由此就会产生一些迷信和误会，”强行数据“，”随意数据“，”政治正确数据“等等情况比较常见, 无论是实际的操作层面，还是方法层面，都存在着一些不小的误会。这也是小编打算总结一下在数据科学实践中存在的陷阱与缺陷的缘由。

陷阱与缺陷 1：数据科学的"科学”在哪?

数据科学是我们常常说起的一个词，也是形容我们日常工作的一个词，但当我们说起的时候，内心就会有些心虚，就光看到数据了，“科学”在哪里？如果没有”科学“的部分，我们的产出的结论会不会有问题？

这是一个最常见的问题，数据科学的从业者们，不知道什么是”科学“。所以江湖上才会有 SQL Boy, SQL Girl 的称呼。

一个常见的问题是数据指标之间的相关性到底是不是真的相关？做数据分析往往能看到很多有趣的相关性，比如最近几个月买了拖鞋的用户，看起来有更大的可能性在最近一个月复购另外一个商品。但是，这个相关性到底是不是真的存在，还是只是偶然的巧合？我们的分析报告很容易对这个问题视而不见。但如果这个相关性本身经不起推敲，它又如何来指导我们的工作呢？数据分析报告难道要靠运气来驱动业务发展么？

就算我们有不错的统计基础，给每个假设都加上了假定值，往往还很容易把相关性与因果性给搞混。两个事情相关，并不能得出结论说他们之间互为因果。我们需要通过因果分析的方法，为数据之间的相关性提出符合业务逻辑和商业逻辑的解释。

如果数据分析遗漏了因果分析这个过程，就会得出一些奇怪的结论。比如，我们发现较大的用户，买的鞋子一般也是大号。如果缺乏基于业务逻辑的因果分析我们可能会这样指导运营工作：为了让用户的脚变大，我们应该多卖大号的鞋子给他们。

但有的时候，我们很难直接的分析出数据之间的因果关系，很难直观的得出结论，这个时候，我们需要借助科学实验，帮我们更深入的理解我们的业务。

陷阱与缺陷 2：操纵，误导，数据的民主化不足

数据民主化在国外的数据社区讨论的很多，国内聊的比较少。数据科学家们通过黑魔法制造出一些模型来，然后告诉业务同学该怎么决策，告诉高层业务指标完成的好不好。数据的能力被限制在某一个专业团队，但它的产出却又跟业务紧密相关，这些未知会给业务人员和管理层带来恐惧与不安，数据团队给的结论会不会有可能是被操纵的？会不会有意无意的误导？这些问题会很容易让团队之间滋生不信任。

所以数据民主化不足带来的一个重要问题就是信任问题，那该怎么解决？

在一次产技共创会中，有同事提出，要跟业务“谈恋爱”。对于眼下的现实，这确实是解决信任问题的一个好办法。阿里的曾经的数据总监也曾说过类似的话：数据同学要会"混，通，晒"，跟业务同吃同行，建立信任，才能互相成功。但这终究不是一个可规模化和标准化的解决方案 。

陷阱与缺陷 3：数据预测未来不是理所当然，预测的成功不仅是算法模型

老板们经常会把算法能力简单化：预测的不准？找两个 NB 的算法专家做个模型就能搞定！遗憾的是，现实并不这么简单，你可能找 100 个 NB 的算法专家都没用。

有人见过用算法来预测下一轮双色球中奖号码的么？有人用算法来预测接近混沌状态的股市涨落么？作为一个旁观者，你能利用算法来预测意甲的每场比赛成绩么？

有的业务问题本身是无法预测的，因为它跟过去没有关系（比如双色球）；有的业务问题预测成本很高，短时间内无法做出有价值的模型（比如预测股市，预测比赛等），需要考虑投入与回报。事实上，很多算法的成功落地应用，不光是需要有合适的模型，还需要大量维度的数据作为生产资料，更关键的是要有一个完善，可靠的算法工程体系。而后者，往往会被决策者忽略。

决策者在考虑利用算法模型去预测未来时，他需要想明白 投入与产出，组织需要投入的不止是 几位算法大神就行，还需要建设完善的数据基础体系，还需要建设完善的算法工程体系。决策者如果期望数据和算法能发挥突破性的效应，需要有魄力把成本投入到自己目光不能及的地方，比如基础数据体系，比如算法工程。

陷阱与缺陷 4：空中楼阁 - 基础设施与基础能力的不完备

这个问题比较抽象，对于 BI/ 算法 / 数据产品的同学而言，可能不好理解。不过大家只需要记住：数据的最底层，摇摇欲坠，并不坚实，同样需要一个团队精心守护。

大家在兴奋的玩耍数据，利用数据来驱动业务前进的时候，如果回头望望做数据基础建设的同学，如果他们告诉你其实你在用的数据能不能真的算出来、有没有算对，他们也没多少信心的时候，你会不会觉得心惊肉跳，会不会觉得人生其实有些虚无？如果大家有机会采访下各个互联网公司，可以问问他们被抱怨最多或者故障最多的技术团队是哪个？相信答案都比较一致：“大数据基础团队”。

这当然并不是因为大数据基础行业的从业者敬业精神不足或者能力不足。而是因为大数据体系其实并没有一个非常坚实的工程基础。如果有对数据工程基础感兴趣的小伙伴，可以翻翻睿帆科技相关产品的资料，相信你一定会得到答案，这里咱们就不展开了。

数据的基础设施可靠性不足：数据的采集系统，数据的存储系统，数据的计算系统，数据的分析引擎，这些服务的可靠性相比其他的在线服务低一大截。

计算模型不完备和广泛的误解：大数据的计算有两个模型：流计算、批计算。两个模型对应的基础设施各自独立发展，谁也不理谁。虽然，实时计算、离线计算在很多现实场景中，存在着一致性，但本质上，它们是两回事。甚至很多从业者也无法清晰的分清楚这些基本概念，把实时计算和流计算等同，这给数据工作带来了巨大的困扰。

为了适配这两个计算模型，很多组织团队会有独立的流计算团队和批处理团队；会有实时数仓和离线数仓，会有实时指标和离线指标等等。这些数仓和指标的研发人员存在着割裂，数仓建设方法论、指标定义也不尽相同。维护成本和解释成本都很高，出错几率也很大。很常见的情况是一个业务的数据需求，往往需要拆解成实时和离线两个方案，共同去实现。这个糟糕的局面没有变得更好。

许多大公司都在尝试做批流融合，但融合两种完全不同的计算模型，是一件不美好的事情，直觉上也不大对。由于历史原因，实时的数据往往需要依赖流计算模式来产生，从而产生了实时计算 == 流计算的误会。而融合实时数据与离线计算，解决起来就容易很多 。而流处理也需要走向更适合它的场景。

其实能总结的问题远不止这些，为了将数据科学的炼金术转化为真金，企业必须让数据科学为业务带来有形的价值。他们不能只专注于实验，而是将数据科学作为业务模式的组成部分，并与公司的优先事项保持一致。如果你遵循上述的方法，乐章将再次奏响，数据科学将不会成为一场骗局。