写给大数据从业者：数据科学的5个陷阱与缺陷

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

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

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

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

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

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

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

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

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!