写给大数据从业者：数据科学的5个陷阱与不足
发布时间：2022-01-03 10:46:25 所属栏目：大数据 来源：互联网
导读：最近看新闻，发现数据科学专业已经是北京大学高考入学门槛较高的专业了，其实Data Science 这个词性感了快十年了，对互联网行业而言，相当于性感了一个世纪。 从数据说话，DT 时代，到 数据中台，数据驱动（Data Drive/Data Driven)，数据体系的不断演进正在
|
有的业务问题本身是无法预测的，因为它跟过去没有关系（比如双色球）；有的业务问题预测成本很高，短时间内无法做出有价值的模型（比如预测股市，预测比赛等），需要考虑投入与回报。事实上，很多算法的成功落地应用，不光是需要有合适的模型，还需要大量维度的数据作为生产资料，更关键的是要有一个完善，可靠的 算法工程体系。而后者，往往会被决策者忽略。 决策者在考虑利用算法模型去预测未来时，他需要想明白 投入与产出，组织需要投入的不止是 几位算法大神就行，还需要建设完善的数据基础体系，还需要建设完善的算法工程体系。决策者如果期望数据和算法能发挥突破性的效应，需要有魄力把成本投入到自己目光不能及的地方，比如基础数据体系，比如算法工程。 陷阱与缺陷 5：空中楼阁 - 基础设施与基础能力的不完备 这个问题比较抽象，对于 BI/ 算法 / 数据产品的同学而言，可能不好理解。不过大家只需要记住：数据的最底层，摇摇欲坠，并不坚实，同样需要一个团队精心守护。 大家在兴奋的玩耍数据，利用数据来驱动业务前进的时候，如果回头望望做 Data Infra 的同学，如果他们告诉你其实你在用的数据能不能真的算出来、有没有算对，他们也没多少信心的时候，你会不会觉得心惊肉跳，会不会觉得人生其实有些虚无？如果大家有机会采访下各个互联网公司，可以问问他们被抱怨最多或者故障最多的技术团队是哪个？相信答案都比较一致：“大数据基础团队”。包括严选的前面几年，这个情况也非常严重（当然现在也没好多少）。数据故障频出，数据产出排期长、节奏慢、不稳定等情况都很常见，很多时候我们是用睡觉时间在做人肉保障。每每回想起来，都会心惊。 这当然并不是因为大数据基础行业的从业者敬业精神不足或者能力不足。而是因为大数据体系其实并没有一个非常坚实的工程基础。 数据的基础设施可靠性不足：数据的采集系统，数据的存储系统，数据的计算系统，数据的分析引擎，这些服务的可靠性相比其他的在线服务低一大截。数据平台每天的定时数据计算服务，比如 Hive，或者 spark，成功率如果有 98%，已经算是很不错了，而线上服务系统，如果可靠率长期在 98% 以下，相关团队的同学很难坚持一年不被优化。就算数据成功的被计算出来了，我们的分析引擎，比如 impala，查询成功率也长期低于 95% 以下，在严选这个数据还要更差一些，impala 的查询失败或者超时，几乎每天都有不少。 计算模型不完备和广泛的误解：大数据的计算有两个模型：Streaming，Batch。两个模型对应的基础设施各自独立发展，谁也不理谁。同时，由于信息流转的速度问题，也有人把这两个模型称为实时计算和离线计算。虽然，Streaming & 实时计算；Batch & 离线计算，在很多现实场景中，存在着一致性，但本质上，它们是两回事。甚至很多从业者也无法清晰的分清楚这些基本概念，把实时计算和流计算等同，这给数据工作带来了巨大的困扰。 为了适配这两个计算模型，很多组织的 Data Infrastructure 团队会有独立的流计算团队和批处理团队；会有实时数仓和离线数仓，会有实时指标和离线指标等等。这些数仓和指标的研发人员存在着割裂，数仓建设方法论、指标定义也不尽相同。维护成本和解释成本都很高，出错几率也很大。很常见的情况是一个业务的数据需求，往往需要拆解成实时和离线两个方案，共同去实现。这个糟糕的局面没有变的更好。 LinkedIn、Uber、阿里等等公司都在尝试做批流融合，严选也在尝试，我们在做计算资源管理和调度层面的融合。但是，融合两种完全不同的计算模型，是一件不美好的事情，直觉上也不大对。我觉得现实的业务问题可能并不是聚焦在批流两种计算模型的不兼容上，而是聚焦在实时和离线两个时间维度上的不兼容。由于历史原因，实时的数据往往需要依赖流计算模式来产生，从而产生了实时计算 == 流计算的误会。而融合实时数据与离线计算，解决起来就容易很多 。而流处理也需要走向更适合它的场景。 其实能总结的问题远不止这些，比如我们会担心“算法替代思考，会不会伤害组织的远见？”、“大规模依赖 A/B 测试做决策，可能会导致运营策略的短视” 等等。 （编辑：无锡站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |