【转载】写给大数据从业者

转载来源：https://blog.csdn.net/r6Auo52bK/article/details/101043146

这篇文章是在大数据周刊的博客里看到的，个人觉得文中提及的几项，确实是实际的数据工作中的痛点。下面的内容是做了摘选，如果朋友们想看原文，可以去大数据周刊的博客阅读原文。

陷阱与缺陷 1：数据质量杀死自动 / 智能决策

网易严选的很多业务，比如风控业务，核心驱动力是数据及算法。我们在风控业务起步的时候就建立了数据算法驱动风控的方法体系，所以能保证很小的团队（3 个人）来支撑严选几十个内外部风险场景，每天执行百万次风险决策。当然，这是数据驱动自动决策 / 智能决策带来的力量。成功的美好，或许会让你按耐不住的想把很多业务运转方式转型过来，但遗憾的是，数据质量保障的缺失会让这一切变成随时会倒塌的空中楼阁！事实上，绝大部分组织对数据质量的理解 支撑不了更加自动和智能的决策场景。强行转型与减员增效会让他们原本稳定的业务接近崩溃。

严选风控出现过几次大的故障都跟数据质量紧密相关。今年 8 月份的时候，风控在执行每周误判巡检的时候发现整体疑似误判率增加了 4 倍。最终定位原因是设备号相关的日志内容有些异常。从而导致了相当一部分用户的行为（签到操作）被错误的执行了拦截。

这是一个很有意思的案例。一些关键的决策：比如用户是不是坏人？某个商品要采购多少量？可能会依赖于很不被重视的某个线上日志的一小部分内容。我们的整个质量保障体系很难把视角投入到某个具体应用的某个日志字段在高压力下会不会出错？在传统的应用服务质量保障理念里，日志字段的某个偶尔的小错误，没人会把它当作 Bug，开发人员更不会去关注。但如果你一旦把 数据当作了生产资料，如果我们不对应用质量保障的理念和工具进行革新，你的大量的数据分析报告，训练好的算法模型，做出的决策可能很不可靠，因为你的生产资料本身就是垃圾，而古语有言：Garbage in , garbage out。

还有一个惊人的现状是，大量用于生产数据的复杂 SQL 并没有进行真正的测试，甚至，大量的数据系统并不存在一个所谓的测试环境。我们很难像测试线上服务（比如订单系统）那样去测试数据生产过程的正确性。那么这样通过几万行，甚至几十万行（严选）SQL 生产出来的数据到底能不能用？这个问题其实很难回答。

数据的可靠性是组织在转型数据驱动过程中一个非常大的陷阱。

大家都在讨论数据质量的重要性，但是内心又默默觉得这个事情比较低级。因此，我们很少见到有团队会把大量聪明的大脑投入到数据质量的保障上。

除了资源投入的缺失，很多数据团队对数据质量的认知也是各不相同。我曾经跟一位在数据行业从业 15 年，为某知名公司数据体系做出巨大贡献的前辈做过一次深入的沟通，聊起数据质量，”你觉得数据质量是什么？“ 他的回答是：“数据质量，真正需要考虑的是指标一致性。”。瞧瞧，就算是非常资深的同行，他的认知还是不够完整，按他对数据质量的理解，数据的支撑能做到报表给人看，这个层面就很完美了，要落地到战术层，落地到线上自动决策基本不可行（因为数据质量的故障难以像线上程序故障一样快速修复，它是一个持续污染的过程）。

数据做为智能决策的输入，是动态变化的。它没法像代码的依赖那样做静态分析，它的依赖层次动态而不稳定。

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

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

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

严选在一次产技共创会中，有同事提出，要跟业务“谈恋爱”。对于眼下的现实，这确实是解决信任问题的一个好办法。阿里的曾经的数据一把手车品觉老师也说过类似的话：数据同学要会"混，通，晒"，跟业务同吃同行，建立信任，才能互相成功。

但这终究不是一个可规模化和标准化的解决方案 。去年，我们在考虑 2019-2020 年严选数据平台发展的时候，想了很久这个问题。如何去降低数据使用的门槛，让一切更直观和更容易解释？我们开展的一些项目，SQL on AI, Data Intelligence System(DIS)，算法平台等，一个共同的目标是 降低数据使用门槛，并通过产品的方式固化甚至可视化数据分析过程。

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

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

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

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

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

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

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

大家在兴奋的玩耍数据，利用数据来驱动业务前进的时候，如果回头望望做 Data Infra 的同学，如果他们告诉你其实你在用的数据能不能真的算出来、有没有算对，他们也没多少信心的时候，你会不会觉得心惊肉跳，会不会觉得人生其实有些虚无？如果大家有机会采访下各个互联网公司，可以问问他们被抱怨最多或者故障最多的技术团队是哪个？相信答案都比较一致：“大数据基础团队”。包括严选的前面几年，这个情况也非常严重（当然现在也没好多少）。数据故障频出，数据产出排期长、节奏慢、不稳定等情况都很常见，很多时候我们是用睡觉时间在做人肉保障。每每回想起来，都会心惊。

这当然并不是因为大数据基础行业的从业者敬业精神不足或者能力不足。而是因为大数据体系其实并没有一个非常坚实的工程基础。

数据的基础设施可靠性不足：数据的采集系统，数据的存储系统，数据的计算系统，数据的分析引擎，这些服务的可靠性相比其他的在线服务低一大截。数据平台每天的定时数据计算服务，比如 Hive，或者 spark，成功率如果有 98%，已经算是很不错了，而线上服务系统，如果可靠率长期在 98% 以下，相关团队的同学很难坚持一年不被优化。就算数据成功的被计算出来了，我们的分析引擎，比如 impala，查询成功率也长期低于 95% 以下，在严选这个数据还要更差一些，impala 的查询失败或者超时，几乎每天都有不少。

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

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

LinkedIn、Uber、阿里等等公司都在尝试做批流融合，严选也在尝试，我们在做计算资源管理和调度层面的融合。但是，融合两种完全不同的计算模型，是一件不美好的事情，直觉上也不大对。我觉得现实的业务问题可能并不是聚焦在批流两种计算模型的不兼容上，而是聚焦在实时和离线两个时间维度上的不兼容。由于历史原因，实时的数据往往需要依赖流计算模式来产生，从而产生了实时计算 == 流计算的误会。而融合实时数据与离线计算，解决起来就容易很多 。而流处理也需要走向更适合它的场景。