做网站设计的公司柳州,wordpress开启mu,网站建设毕业设计 任务书,wordpress新建页面慢来源 | AI 前线作者 | 陈炬#xff0c;责编 | Carol出品 | CSDN云计算#xff08;ID#xff1a;CSDNcloud#xff09;导读#xff1a; 这篇分享主要总结了数据从业人员在实践中可能遇到的陷阱与缺陷。跟其他新起的行业一样#xff0c;数据科学从业人员需要不停的去考虑现… 来源 | AI 前线作者 | 陈炬责编 | Carol出品 | CSDN云计算IDCSDNcloud导读 这篇分享主要总结了数据从业人员在实践中可能遇到的陷阱与缺陷。跟其他新起的行业一样数据科学从业人员需要不停的去考虑现在考虑未来需要不断的斟酌工作方法的合理性正确性。思索不断才能前行。注文中斜字体表明该内容具有比较强烈的主观判断并不是行业共识。最近看新闻发现数据科学专业已经是北京大学高考入学门槛最高的专业了其实Data Science 这个词性感了快十年了对互联网行业而言相当于性感了一个世纪。从“数据说话””DT 时代”到 “数据中台”“数据驱动Data Drive/Data Driven)”数据体系的不断演进正在持续的改变大家的工作与决策方式正在不断的革新大家的思维方式同时也产生了新的商业逻辑新的发展机会。1976 年Pascal 作者 Nikalus Wirth 曰Algorithms Data Structures Programs.就像之前的“SOA”“云计算”等概念一样目前数据科学自身的概念还在不断的变革各家公司的实践者们一边摸索一边获利一边总结一边布道当然同时还参杂着很多凑热闹的同志把概念折腾的更加模糊。所以数据科学本身的能力边界方法论体系最佳实践等等还没有完善的建立起来有很多问题没有办法很好的回答。由此就会产生一些迷信和误会”强行数据“”随意数据“”政治正确数据“等等情况比较常见, 无论是实际的操作层面还是方法层面都存在着一些不小的误会。这也是我打算总结一下在数据科学实践中存在的陷阱与缺陷的缘由。这篇分享是根据我自己的工作经验和对相关资深同事的访谈总结而成。它的正确性受限于我个人的认知水平和目前行业的发展水平它整理了一些目前可能存在的问题但未必是长久的道理。希望大家读的时候批判性的看待。抛砖引玉如果有不同想法欢迎大家跟我随时沟通与验证结论本身也可以随时更新。数据质量杀死自动 / 智能决策网易严选的很多业务比如风控业务核心驱动力是数据及算法。我们在风控业务起步的时候就建立了数据算法驱动风控的方法体系所以能保证很小的团队3 个人来支撑严选几十个内外部风险场景每天执行百万次风险决策。当然这是数据驱动自动决策 / 智能决策带来的力量。成功的美好或许会让你按耐不住的想把很多业务运转方式转型过来但遗憾的是数据质量保障的缺失会让这一切变成随时会倒塌的空中楼阁事实上绝大部分组织对数据质量的理解 支撑不了更加自动和智能的决策场景。强行转型与减员增效会让他们原本稳定的业务接近崩溃。严选风控出现过几次大的故障都跟数据质量紧密相关。今年 8 月份的时候风控在执行每周误判巡检的时候发现整体疑似误判率增加了 4 倍。最终定位原因是设备号相关的日志内容有些异常。从而导致了相当一部分用户的行为签到操作被错误的执行了拦截。这是一个很有意思的案例。一些关键的决策比如用户是不是坏人某个商品要采购多少量可能会依赖于很不被重视的某个线上日志的一小部分内容。我们的整个质量保障体系很难把视角投入到某个具体应用的某个日志字段在高压力下会不会出错在传统的应用服务质量保障理念里日志字段的某个偶尔的小错误没人会把它当作 Bug开发人员更不会去关注。但如果你一旦把 数据当作了生产资料如果我们不对应用质量保障的理念和工具进行革新你的大量的数据分析报告训练好的算法模型做出的决策可能很不可靠因为你的生产资料本身就是垃圾而古语有言Garbage in , garbage out。还有一个惊人的现状是大量用于生产数据的复杂 SQL 并没有进行真正的测试甚至大量的数据系统并不存在一个所谓的测试环境。我们很难像测试线上服务比如订单系统那样去测试数据生产过程的正确性。那么这样通过几万行甚至几十万行严选SQL 生产出来的数据到底能不能用这个问题其实很难回答。数据的可靠性是组织在转型数据驱动过程中一个非常大的陷阱。大家都在讨论数据质量的重要性但是内心又默默觉得这个事情比较低级。因此我们很少见到有团队会把大量聪明的大脑投入到数据质量的保障上。除了资源投入的缺失很多数据团队对数据质量的认知也是各不相同。我曾经跟一位在数据行业从业 15 年为某知名公司数据体系做出巨大贡献的前辈做过一次深入的沟通聊起数据质量”你觉得数据质量是什么“ 他的回答是“数据质量真正需要考虑的是指标一致性。”。瞧瞧就算是非常资深的同行他的认知还是不够完整按他对数据质量的理解数据的支撑能做到报表给人看这个层面就很完美了要落地到战术层落地到线上自动决策基本不可行因为数据质量的故障难以像线上程序故障一样快速修复它是一个持续污染的过程。数据做为智能决策的输入是动态变化的。它没法像代码的依赖那样做静态分析它的依赖层次动态而不稳定。数据科学的科学”在哪?数据科学是我们常常说起的一个词也是形容我们日常工作的一个词但当我们说起的时候内心就会有些心虚就光看到数据了“科学”在哪里如果没有”科学“的部分我们的产出的结论会不会有问题这是一个最常见的问题数据科学的从业者们不知道什么是”科学“。所以江湖上才会有 SQL Boy, SQL Girl 的称呼。一个常见的问题是数据指标之间的相关性到底是不是真的相关我们做数据分析往往能看到很多有趣的相关性比如最近几个月买了拖鞋的用户看起来有更大的可能性在最近一个月复购另外一个商品。但是这个相关性到底是不是真的存在还是只是偶然的巧合False Postive我们的分析报告很容易对这个问题视而不见。但如果这个相关性本身经不起推敲它又如何来指导我们的工作呢数据分析报告难道要靠运气来驱动业务发展么就算我们有不错的统计基础给每个假设都加上了 P Value, 我们往往还很容易把相关性与因果性给搞混。两个事情相关并不能得出结论说他们之间互为因果。我们需要通过因果分析的方法为数据之间的相关性提出符合业务逻辑和商业逻辑的解释。如果数据分析遗漏了因果分析这个过程就会得出一些奇怪的结论。比如我们发现较大的用户买的鞋子一般也是大号。如果缺乏基于业务逻辑的因果分析我们可能会这样指导运营工作为了让用户的脚变大我们应该多卖大号的鞋子给他们。但有的时候我们很难直接的分析出数据之间的因果关系很难直观的得出结论这个时候我们需要借助科学实验帮我们更深入的理解我们的业务。如何去做科学实验我结合滴滴谢梁大神的观点谢梁数据科学中的“科学”总结如下通过对数据的敏锐度和业务的熟悉程度发现和定义问题提出结构化可量化的假设设计验证实验。科学与实验是紧密关联的。在严选和很多公司我们往往利用实验来判断方案的好坏。但是其实实验更多的是用于帮助我们验证假设帮我们更加深入的理解我们的用户著名实验公司今天头条 CEO 说更多的时候AB 测试帮助我们理解用户而不是帮助我们决策。设计一个好的实验并不容易需要根据假设梳理出要验证的指标样本集可控制的因子往往是流量。设计实验需要极强的专业性。收集与分析数据。分析数据并不仅仅是直观的去看趋势的高低。分析数据首先需要对业务的主要指标及其相关性有清晰的概念需要把指标之间的相关因子量化甚至可计算。我认为是先有结构化、系统化、量化的体系再有数据分析。所幸的是结构化的体系我们可以用系统和服务来支撑。我们团队今年主要在设计与研发的 DIS 系统严选数据智能平台一个主要目标就是解决这个问题。分析人员需要专业的量化分析能力、统计学能力。操纵误导数据的民主化不足 数据民主化在国外的数据社区讨论的很多国内聊的比较少。数据科学家们通过黑魔法制造出一些模型来然后告诉业务同学该怎么决策告诉高层业务指标完成的好不好。数据的能力被限制在某一个专业团队但它的产出却又跟业务紧密相关这些未知会给业务人员和管理层带来恐惧与不安数据团队给的结论会不会有可能是被操纵的会不会有意无意的误导这些问题会很容易让团队之间滋生不信任。所以数据民主化不足带来的一个重要问题就是信任问题那该怎么解决严选在一次产技共创会中有同事提出要跟业务“谈恋爱”。对于眼下的现实这确实是解决信任问题的一个好办法。阿里的曾经的数据一把手车品觉老师也说过类似的话数据同学要会混通晒跟业务同吃同行建立信任才能互相成功。但这终究不是一个可规模化和标准化的解决方案 。去年我们在考虑 2019-2020 年严选数据平台发展的时候想了很久这个问题。如何去降低数据使用的门槛让一切更直观和更容易解释我们开展的一些项目SQL on AI, Data Intelligence System(DIS)算法平台等一个共同的目标是 降低数据使用门槛并通过产品的方式固化甚至可视化数据分析过程。数据预测未来不是理所当然预测的成功不仅是算法模型 老板们经常会把算法能力简单化预测的不准找两个 NB 的算法专家做个模型就能搞定遗憾的是现实并不这么简单你可能找 100 个 NB 的算法专家都没用。有人见过用算法来预测下一轮双色球中奖号码的么有人用算法来预测接近混沌状态的股市涨落么作为一个旁观者你能利用算法来预测意甲的每场比赛成绩么有的业务问题本身是无法预测的因为它跟过去没有关系比如双色球有的业务问题预测成本很高短时间内无法做出有价值的模型比如预测股市预测比赛等需要考虑投入与回报。事实上很多算法的成功落地应用不光是需要有合适的模型还需要大量维度的数据作为生产资料更关键的是要有一个完善可靠的 算法工程体系。而后者往往会被决策者忽略。决策者在考虑利用算法模型去预测未来时他需要想明白 投入与产出组织需要投入的不止是 几位算法大神就行还需要建设完善的数据基础体系还需要建设完善的算法工程体系。决策者如果期望数据和算法能发挥突破性的效应需要有魄力把成本投入到自己目光不能及的地方比如基础数据体系比如算法工程。空中楼阁 - 基础设施与基础能力的不完备 这个问题比较抽象对于 BI/ 算法 / 数据产品的同学而言可能不好理解。不过大家只需要记住数据的最底层摇摇欲坠并不坚实同样需要一个团队精心守护。大家在兴奋的玩耍数据利用数据来驱动业务前进的时候如果回头望望做 Data Infra 的同学如果他们告诉你其实你在用的数据能不能真的算出来、有没有算对他们也没多少信心的时候你会不会觉得心惊肉跳会不会觉得人生其实有些虚无如果大家有机会采访下各个互联网公司可以问问他们被抱怨最多或者故障最多的技术团队是哪个相信答案都比较一致“大数据基础团队”。包括严选的前面几年这个情况也非常严重当然现在也没好多少。数据故障频出数据产出排期长、节奏慢、不稳定等情况都很常见很多时候我们是用睡觉时间在做人肉保障。每每回想起来都会心惊。这当然并不是因为大数据基础行业的从业者敬业精神不足或者能力不足。而是因为大数据体系其实并没有一个非常坚实的工程基础。数据的基础设施可靠性不足数据的采集系统数据的存储系统数据的计算系统数据的分析引擎这些服务的可靠性相比其他的在线服务低一大截。数据平台每天的定时数据计算服务比如 Hive或者 spark成功率如果有 98%已经算是很不错了而线上服务系统如果可靠率长期在 98% 以下相关团队的同学很难坚持一年不被优化。就算数据成功的被计算出来了我们的分析引擎比如 impala查询成功率也长期低于 95% 以下在严选这个数据还要更差一些impala 的查询失败或者超时几乎每天都有不少。计算模型不完备和广泛的误解大数据的计算有两个模型StreamingBatch。两个模型对应的基础设施各自独立发展谁也不理谁。同时由于信息流转的速度问题也有人把这两个模型称为实时计算和离线计算。虽然Streaming 实时计算Batch 离线计算在很多现实场景中存在着一致性但本质上它们是两回事。甚至很多从业者也无法清晰的分清楚这些基本概念把实时计算和流计算等同这给数据工作带来了巨大的困扰。为了适配这两个计算模型很多组织的 Data Infrastructure 团队会有独立的流计算团队和批处理团队会有实时数仓和离线数仓会有实时指标和离线指标等等。这些数仓和指标的研发人员存在着割裂数仓建设方法论、指标定义也不尽相同。维护成本和解释成本都很高出错几率也很大。很常见的情况是一个业务的数据需求往往需要拆解成实时和离线两个方案共同去实现。这个糟糕的局面没有变的更好。LinkedIn、Uber、阿里等等公司都在尝试做批流融合严选也在尝试我们在做计算资源管理和调度层面的融合。但是融合两种完全不同的计算模型是一件不美好的事情直觉上也不大对。我觉得现实的业务问题可能并不是聚焦在批流两种计算模型的不兼容上而是聚焦在实时和离线两个时间维度上的不兼容。由于历史原因实时的数据往往需要依赖流计算模式来产生从而产生了实时计算 流计算的误会。而融合实时数据与离线计算解决起来就容易很多 。而流处理也需要走向更适合它的场景。其实能总结的问题远不止这些比如我们会担心“算法替代思考会不会伤害组织的远见”、“大规模依赖 A/B 测试做决策可能会导致运营策略的短视” 等等。作者介绍 陈炬网易严选数据平台及风控部负责人。目前主要负责数据平台智能决策平台数据工程算法工程及严选风险控制等相关工作。十余年从业经验参与负责过网易自研的 MR 计算系统网易大规模分布式小文件存储系统网易邮箱多级存储系统网易严选网易邮箱等通信网络层协议等。个人主要关注在大规模分布式系统分布式存储网络协议数据科学等方向。推荐阅读利用丁香园数据生成疫情分布地图R语言| 博文精选
2020云计算是四强争霸还是赢家通吃
PHP 8 能有多快
“夸夸机器人”App来了变身百万粉丝大V48万人给你的帖子点赞
2019年度区块链安全复盘总结
在家办公我比上班还累你信吗
真香朕在看了猛戳“阅读原文”填写中国远程办公-调查问卷
