大数据文摘出品
编译: 李雷, 栾红叶
数据科学这一名词流行了这么长时间, 对于很多企业来说仍然是熟悉而又陌生的词汇.
对于积极向布局数据科学应用的企业来说, 如何避免走弯路是始终追求的目标.
Blue Yonder, 一个成立于 2008 年的大数据分析平台, 用他 8 年的数据科学经验告诉你, 什么是真正的数据科学, 有哪些弯路可以不走.
正如 Blue Yonder 创始人在采访中说到:"在这八年里, 我们经历了不少痛苦的教训, 尤其是在数据科学应用方面."
以下是采访原文, 请欣赏!
数据科学
我相信许多人都知道什么是数据科学, 但我想分享一下我个人对它的理解: 数据科学的目的是构建自动化的数据驱动运营决策支持系统.
根据这么严格的定义(你也许会有异议), 数据科学的唯一目便成了决策的支持和自动化. 那么 "运营决策" 是什么?
它是指企业需要频繁定期进行的大量决策, 这些决策对业务 KPI(关键绩效指标)有直接影响, 其结果也需要在短时间内进行评估.
企业可能需要作出以下决策, 例如: 各种产品明天的最佳定价是多少或发送给供应商 X 的下一个订单中各产品的最佳定价是多少.
由于人们经常在不经意间受到影响, 因此在大多数情况下, 自动决策胜于人类的运营决策, 并且自动决策可以显著提高业务流程的效率.
人类决策偏见列表:
https://en.wikipedia.org/wiki/List_of_cognitive_biases#Decision-making.2C_belief.2C_and_behavioral_biases
所有这一切实际上意味着, 数据科学对于运营决策的意义就像工业机器人对于制造业那样. 正如机器人可以自动执行重复的生产任务一样, 数据科学也可以自动执行重复的运营决策.
DevOps 与数据科学
DevOps 工作流程旨在克服传统 IT 组织中由于开发团队和运营团队相互独立而导致的普遍冲突问题. 开发团队希望开发新功能并希望新功能尽早上线, 而运营团队负责系统的稳定性, 因为所有变更都会带来风险. 他们需要尽可能地阻止新功能上线.
在这场冲突中, 两个团队都忽略了以稳定可靠的新功能为客户创造价值这一共同目标.
开发人员和运营团队之间的冲突只是组织结构不合理导致的其中一种情形, 对于按功能划分的其他组织机构也存在相同的问题.
在许多公司里, 数据科学也被困在类似的 "功能团队孤岛" 中. 更详细的解释, 我建议阅读这篇《什么是 DevOps》
相关链接: https://theagileadmin.com/what-is-devops/
数据科学 - 麻烦制造者
有个虚构的段子, 但却透着真实的无奈. 两位管理人员在一次会议上相遇, 其中一位经理问道,"你们公司是不是已经开始使用数据科学决策分析了?" 另一位回答说:"我们的数据科学家团队已经成立一年了, 但什么时候可以开始分析还遥遥无期呢."
为了更好地理解为什么许多数据科学工作的进展缓慢, 我们需要看一下用数据科学进行自动化业务决策的典型工作流程.
下面的工作流程示例是以零售行业为例, 同样也适用于其他行业.
(1) 从各种来源提取各种必要的数据:
内部数据源, 如 ERP,CRM 和 POS 系统, 或来自在线商店的数据.
外部数据, 如天气或公众假期数据
(2) 提取, 转换和加载数据:
关联数据源
聚合并转换数据,
用 "一张大表" 关联所有数据
(3) 机器学习和决策制定:
使用历史数据来训练机器学习模型
(4) 对于决策, 使用当前的最新数据
由此产生的决策被送回 ERP 系统或其他数据仓库
这些步骤基本上涉及业务的方方面面, 并且需要深入集成到业务流程中, 以创建有效的决策系统.
然而这也是迄今为止数据科学决策分析工作最大的麻烦. 为了整合数据科学, 就需要改变核心业务流程, 而改变核心业务流程却是一项艰巨的任务.
数据科学本质上是贪婪的
没有数据科学家会说 "目前的数据库规模足够明年用的了."
人们通常觉得数据科学家都是贪婪的, 因为他们似乎对可用资源有着不切实际的想法. 但实际上, 数据科学本身才是贪婪的.
总的来说, 以下因素会使数据科学项目的结果更准确:
更多属性("列")
更多历史数据("行")
更独立的数据源(例如, 天气, 金融市场, 社交媒体......)
更复杂的算法(例如, 深度学习)
综上, 这不是数据科学家的问题! 原则上, 他们有权提出这些要求. 幸运的是, 我们有方法来解决资源短缺问题, 我将在稍后进行论证.
另一个问题是低估了决策的绝对数量. 比如一家拥有 100 个店铺和 5,000 种产品的小型超市连锁店的每日补货量预测, 补货算法需要 14 天的日预测数据才能进行分析. 那实际意味着每天需要计算, 处理和存储 7 百万个预测数据.
由于建立一个有效的机器学习模型需要许多不同的数据源, 部门之间可能会引入新的共通性和纠结. 整个公司必须在公共标识符 (common identifiers) 和数据类型 (data types) 上达成一致.
以前, 断开链接的子部分需要与它们的数据流保持同步. 比如, 一个自动的日常补货系统可能要依赖营销部门的促销数据和商店的库存数据. 所有必要的数据需要在一天中的固定时间获取, 这样才方便系统设计决策并及时发送给供应商.
数据科学家 VS 公司的其他人
现在回到 DevOps 上来, 这一运动旨在克服开发人员和运营团队之间潜在的偏差.
如果你试图在一个单独的地方与数据科学家团队一起构建自动化决策系统, 那么就会不可避免地出现以上这种问题.
由于数据科学与其他部分的不可分离和对数据的贪婪, 其团队很难成功地将一个系统与其他具有不同绩效体制的团队进行合作.
为了防止或解决这些问题, 我们必须接受 DevOps 模式的基本原则:
调整所有团队的目标, 使他们在工作上不至于产生 "冲突", 而是努力实现共同目标.
拆除部门之间的墙, 建立跨职能团队
根据用户附加值的估量, 改进决策方式并分配资源和功能
关于承诺
决策是任何公司成功的核心. 因此, 在引入数据科学时, 整个公司, 包括所有的领导层和部门, 都需要接受并重视.
运用数据科学进行自动化决策是价值流的重要组成部分. 这很可能意味着, 你需要改变既定的流程, 重组团队, 重新考虑公司的组织架构.
此外, 想要成功执行这些措施, 你需要获得必要的认可. 每个人都需要知道为什么会有这些改变, 并且还要支持这些决策. 如果没有这种诚挚的诺言, 自动化决策就不可能会成功执行.
相关链接:
https://www.datascience.com/blog/stakeholder-buy-in-for-data-science-product
反过来, 你的数据科学工作必须着重于真正的附加值: 一个是需要评估执行成本, 包括技术债务成本, 复杂性的累积, 纠结的增加等; 另一方面也要将其与改进后的预期收益进行比较.
数据科学从来不是一个以自我为目标的团队.
相关链接: https://www.datascience.com/blog/agile-data-science)
拆除数据科学的自我壁垒
DevOps 的一个关键目标就是使团队团结以实现公司的共同目标, 并且也要拆毁不同团队之间的壁垒. 因为, 如果把数据科学家分到一个单独的小组, 安排在一个单独的房间里, 这将会是一条通往失败的必经之路.
相关链接:
https://www.datascience.com/blog/centralized-data-science
相反, 如果我们将数据科学家安排到一个跨职能的团队中, 这将有助于构建一个端到端的完整决策系统, 并有助于使其工作与公司目标保持一致. 一旦每个部门都连接起来, 数据科学家的工作就不会与其他部门相矛盾.
相反, 这种决策系统的成功将变成公司的共同利益. 以共同努力为特点的整体优化就能够实现一个共同目标, 这将会取代以自我为中心和不一致的目标为特征的局部优化.
这个跨职能团队和其他的团队一样致力于相同的质量标准, 在质量, 弹性或稳健性方面没有任何妥协的余地.
相反, 由于自动化决策具有较高的风险, 我们需要采用更高的标准. 同时, 遵循 "精益思想" 的方法, 创造一个既便宜又安全的实验环境.
用奥卡姆剃刀与贪婪作斗争
有一个解决问题的原则叫做奥卡姆剃刀(Occam's razor), 也就是:" 在相互竞争的假说中, 应该选择假设最少的." 在数据科学领域, 我们可以将这个原则重新表述为:
如果两个数据科学模型的结果是兼容的, 那么就采用资源覆盖面较小的模型.
这条简单的规则为我们提供了如何建立数据科学模型的明确指导, 解决了数据科学固有的贪婪性问题.
如果不测量生成值并在整个实现周期中应用此原则, 您可能会面临成本激增, 回报有限的问题.
相关链接:
https://www.datascience.com/blog/lessons-from-a-canceled-data-science-project
所以, 必须要确保数据科学家致力于这一重要原则, 因为与数据科学家对抗是非常困难的. 他们有数据和专业知识来提出难以提出异议的论点.
创造一种尽可能简单的, 但又失必要的复杂的效率文化.
这同样适用于不同数据源的使用. 在数据安全领域, 有一个 "需要知道"(need to know)的原则, 即只有需要访问的人才能访问数据.
也就是在数据科学的应用中, 我们需要衡量所额外添加的数据源的价值, 如果改进不够显著, 无法证明额外数据的相关性, 那么就要严格清除这些数据源.
结语
数据科学也就是用来支持和自动化决策的. 对大多数公司来说, 这变得比以往任何时候都重要. 由于它是一个决策系统, 所以必须成为业务流程的核心. 这一事实带来了一系列严重的问题, 特别是文化性质的问题, 可能是灾难性的.
没有诚意的尝试往往会导致时间和金钱的浪费, 同时还加重了数据科学作为麻烦制造者的声誉.
将数据科学进行合理的整合是一个不可忽视的转折点. 用 DevOps 模式来接受数据科学, 测量重要的 KPIs, 从实验中学习, 并不断改进流程. 这是一条真正成为数据驱动公司的道路.
作者 Twitter: https://twitter.com/sebineubauer
相关报道:
https://www.datascience.com/blog/why-is-it-so-hard-to-put-data-science-in-production
[本文是 51CTO 专栏机构大数据文摘的原创译文, 微信公众号 "大数据文摘( id: BigDataDigest)"]
戳这里, 看该作者更多好文
来源: http://zhuanlan.51cto.com/art/201903/593926.htm