写点什么

数据湖需要一次“二次手术”

2019 年 10 月 17 日

数据湖需要一次“二次手术”

棒球运动当中有着“投手之痛”这样一个专用表达,指的是投手即使身有伤病也必须进行投球——无论是手臂酸痛、关节僵硬、水泡还是肌肉拉伤,都无法阻止比赛的正常进行。而这些投手拥有着极其坚毅的意志,即使身体上存在种种问题,他们有仍然能够投出速度极快、令击球手防不胜防的好球。


但在其他更为复杂的场景下,人类同样有可能被迫完成某项任务,而其中的难处使得参与者在有意或者无意之间利用不良习惯应对类似的“痛苦”。如此一来,一个问题就变成了多个问题,直至整个系统彻底崩溃——输掉比赛、错过赛季。事实上,数据湖经历的也基本就是这样一个过程!


“2016 年,Gartner 公司估计有 60%的大数据项目遭遇失败。”而在一年之后,Gartner 分析师 Nick Heudecker 表示原本 60%这一比例“估计得太过保守”,并进一步将失败率定为近 85%。时至今日,在他看来情况也仍然没有好转。


不少早期的数据湖项目始于 CIO 决定引入 Hadoop,将大量数据加载至 Hadoop 环境当中,聘用一些数据科学家,然后坐等奇迹的发生……坐等奇迹的发生……奇迹的发生……然后就没有然后了。


现在看来,这些数据湖正在“走向失败”——也导致整个数据湖领域步步趋向“二次手术”,其中的原因有以下两点:


  • 当原始数据湖技术无法继续满足目标时,IT 组织也不可能继续前进。

  • 在启动数据湖项目时,很多组织往往缺乏深厚的业务背景知识与可量化的业务价值。


数据湖经济学

经济学的核心,涉及价值的产生、消费与转移,其同时也是商业领域最强大的力量所在。让我们先来看看一个最基本的经济概念,并考虑这个新概念如何为数据湖的“二次手术”提供操作框架。


在第一堂经济学课程中,我们先来介绍沉没成本这个概念。沉没成本是指已经发生且无法收回的成本。我爸爸对此有个通俗的解释,,就是“拿钱打水漂”(我爸爸曾经建议我不要再 1968 年的〈怒 III〉街机游戏上投币)。为了做出明智的商业决策,组织应该只考虑即将做出的决策会带来的成本变化,而直接忽略沉没成本。


在技术世界当中,这意味着即使大家购买了特定技术并以此为基础完成了培训,在接下来的决策时同样应该忽略与此前购置、实施与培训技术相关的成本。


在数据湖(以及数据科学)的世界中,技术总是来了又去。因此,越早将这些技术投资视为沉没成本,大家做出的商业决策就越高效。在关于现代数字化企业的《一次性技术时代已经来临(Disposable Technology: A Concept Whose Time Has Come)》一文中,我们可以提取出两条最核心的教训:


  • 教训一:努力保持组织的一致性,从而发现、捕捉并运营企业数据当中所隐含的客户、产品及运营价值的新来源。

  • 教训二:不要采用任何有碍教训一的严苛技术架构。


通过积极的开源架构策略,现代化数字企业逐渐意识到自己的目标不在于建立技术架构,而是通过业务实现数据的货币化。


解决方案:在继续制定新的数据湖决策的同时,不要将大量金钱与时间耗费在构建原始(或者说失败的)数据湖身上。


但是,不了解沉没成本并不是最大的经济学失误,接下来还有更严重的。现在,我要向大家介绍我个人提出的另一个经济学概念——吸血鬼困境理论(我正在积极为此争取诺贝尔经济学奖~)。这一理论,是指组织很难彻底“放弃”过时的技术,进而导致“吸血鬼困境”。换言之,IT 部门无法做出要不要清退(或者说「杀死」)无用技术的决定,其中当然也包括大家最喜爱的数据仓库设施啦。在这种情况下,此类技术将继续存在,并慢慢从更重要的技术方案手中夺取财务与人力资源。


事实上,计算机协会已经为这类无法鼓起勇气消除不相关、过时技术的组织建立起业务模型,并将其认定为一类典型的代表性问题。


解决方案:清退就完事了……清除数据湖中不相关的技术以及多余数据,借以释放人力与财力,从而专注于支持那些对组织业务战略更具价值的技术与数据源。


创造新的经济价值来源

但是,导致大多数数据湖“失败”的根本问题,在于组织无法利用其中的数据引导并推动数据货币化工作。也就是说,人们无法借此发现新的客户、产品与运营价值来源(具体请参见图一)。



图一:CIO 面临的各项主要挑战


如果不清楚自己希望从数据湖身上获取怎样的商业价值、又有哪些元素应从数据湖中被清除出去(例如目标用例是什么、应根据哪些指标来衡量工作进展与成功程度、该用例需要哪些决策作为支撑等等),组织将无法判断哪些数据源更为关键、而哪些数据源并不重要。因此,IT 组织会默认将大量不必要的数据加载至数据湖当中,从而产生大量未经整理且无法供业务体系实际应用的数据。


但好消息是,一旦正确指定了高优先级数据源,IT 组织便可以利用 DataOps 将数据沼泽转化为数据金矿。DataOps 正是其中提高数据货币化工作效率与效果的关键所在。它使我们的数据科学团队能够探索各类变量与指标,借此更好地预测性能,同时不致因数据聚合、清洁、集成、协调、准备、管理以及发布等流程的存在而不堪重负。关于 DataOps 以及数据科学在推动数据货币化方面的共生作用,请参阅博文《DataOps 是什么,它对数据货币化价值又为何至关重要(What is DataOps and Why It’s Critical to the Data Monetization Valu…)》一文(参见图二)。



图二:数据货币化价值链


Hitachi Vantara 数据湖“二次手术”中的经验教训

没错,Hitachi Vantara 在这场数据湖简史当中也是亲历者之一——他们采购了 Hadoop 方案,将大量数据加载到环境当中,聘用了不少数据科学家,然后等待着奇迹的发生……但是,Hitachi Vantara 的故事与其他失败案例之间的唯一区别,就是公司拥有一位富有远见的 CIO——Renee Lahti。在一位好友的指点之下,Renee 意识到她原本的数据湖方法注定会失败。这时候,就需要进行“二次手术”。


Renee 先后通过重新设置数据湖技术平台,以及确定有助于调整工作执行的业务合作伙伴,开始了这场针对数据湖的“二次手术”(内部代号为「香槟项目」,看到这是要提前庆祝胜利啊)。在这场以实现商业价值为目标的努力中,这位重要的合作伙伴正是公司首席营销官 Jonathan Martin。最后,数据科学数字化价值支持(DVE)流程也由此建立起来。


我给大家透露一点这场“香槟行动”中的故事:


  • 组织 DVE 愿望研讨会,旨在发现、验证、评估并确定各个用例的优先级,同时在市场营销、财务、运营、销售以及 IT 事务之间建立一致性,并利用数据湖为其中的数据科学活动提供基础。

  • 选择优先级最高的用例(新产品引入定位),并通过我们的 DVE 价值证明方法对其进行研究(考量一系列数据工程与数据科学工作)。

  • 利用新产品引入代理,开发、测试并验证三套分析模型(分别对应购买意向、客户忠诚度推荐引擎以及生存模型)。

  • 将这些评分纳入销售、产品与支持系统当中,从而确保 Hitachi Vantara 能够将支持重点放在那些可以从新产品中获取最佳收益的客户群体,并思考其原因(基于客户使用模型与服务历史记录)。


但根据我的个人观察,仅使用 3 个数据源,我们就能让实现高达 90%的模型预测准确性。是的,只需要 3 个即可!这项研究的重要意义在于,组织并不需要将数十甚至数百套数据集加载至数据湖中,以进一步推动数据货币化进程。相反,只要组织对其希望解决的问题拥有深刻的了解,那么即使考虑到初步使用数据方面的效率与效果限制,单纯面向三套最重要的数据集进行数据清洁、完整性评估与填充操作,已经足以带来令人满意的产出。


现在,我们能不能进一步改善设计,从而继续利用这三个数据源提高模型准确性?当然可以,而这正是 IT 部门需要重点关注的主要数据改进方向。


但这又带来了另一个有趣的问题:我们能否通过合并更多数据源的方式,提高模型的准确性?有可能,但在对分析模型进行改进的同时,我们也需要考虑引入新数据源所带来的成本与边际价值权衡问题。换句话说,我们是应该继续投入资源以改善现有模型与数据支持能力,还是将这部分资源分配给新的用例(我们至少还有 10 个用于市场营销的其它模型)?这无疑是一项重要的商业决策。


总结

数据湖可以也应该成为一套“创造协作价值的平台”,负责帮助组织确定并区分那些可引导及推动的全新客户、产品与运营价值来源,并对相关用例进行优先级排序。但是,千万不要长期使用过时的技术平台与货币方法来缓解所谓“投手之痛”。此外,接受沉没成本以及“吸血鬼困境”等相关经济学概念,勇于放手前进,并将“二次手术”视为数据湖运营中的新常态。


只要能做到这几点,完成过渡并痛饮庆功酒将只是时间问题!


本文要点总结:


  • 正如职业运动员在面临“投手之痛”时,往往会利用不良习惯加以缓解,并最终严重影响效果与职业生涯一样;在创造不良习惯以缓解系统架构层面中的内在问题时,IT 组织也会遭遇相同的综合症甚至是后遗症。

  • 在数据湖的世界中,我们发现很多 IT 组织都试图“熬过结构质量与定位质量双重低下的艰难发展阶段”。但结果就是,这种几乎没救了的数据湖在“二次手术”中很可能彻底毁掉 CIO 的职业道路。

  • 数据湖“二次手术”解决方案的起点,应该是了解一些基本的经济学概念——包括沉没成本与“吸血鬼困境”。

  • 实现数据湖项目成功的关键是什么?投入时间解决潜在的技术问题(不要以消极的态度忍受「投手之痛」),并在组织内部就数据湖能够在哪里以怎样的方式引导并获取新的客户、产品与运营价值来源达成共识。


原文链接:


The Data Lake Chronicles: Pitching Through Pain, Vampire Indecisions and Second Surgeries


2019 年 10 月 17 日 16:571481

评论

发布
暂无评论
发现更多内容

万字破解云原生可观测性

谭建

云原生 APM 可观测性 链路追踪 Skywalking

Block底层原理探析

Damien

ios 源码分析

改变

一把梭

生活 随笔

Web3极客日报#131

谢锐 | Frozen

区块链 创业 独立开发者 技术社区 Rebase

我所想的跨平台开发:小程序+App+Web

曾伟@喵先森

flutter 小程序 微信小程序 跨平台

OKR实践中的痛点(3):破3旧,迎3新!

大叔杨

OKR Scrum 敏捷 敏捷开发 绩效

为什么最该祝自己劳动节快乐

石君

劳动 劳动节 励志

容器日志采集利器:Filebeat深度剖析与实践

傅轶

Kubernetes 容器 云原生 日志 Filebeat

如何表达自己的感情?

zkh

科技 vs 隐私:瘟疫下“以健康为名”会将我们推向何方?

陶乐思

Web3极客日报 #132

谢锐 | Frozen

区块链 创业 独立开发者 技术社区 Rebase

论十三

十三

张小龙 的 22 年和微信的 8 年

池建强

微信 张小龙

为什么开源是基础软件的未来

顾钧

开源 基础软件

消息队列Kafka - 基本应用

Java收录阁

kafka

HTTP的德性

十三

游戏夜读 | 2020周记(4.10-4.17)

game1night

以物理学思维破解分布式系统的本质

常平

分布式

如何成为一个靠谱的人

熊斌

个人成长 团队协作

Firefox浏览器背后的力量,Mozilla基金会的“生财”之道

赵新龙

firefox 开源 基金会

没有了手机的诺基亚,过得远比你想象的要好

赵新龙

微软 手机 上市 诺基亚

Web3极客日报 #133

谢锐 | Frozen

区块链 技术社区 Rebase

消息队列Kafka - 原理分析

Java收录阁

kafka

Disruptor 高效的秘密-Sequencer

Rayjun

Java 并发编程 Disruptor

Java并发编程系列——常用并发工具类

孙苏勇

Java Java并发 并发编程 多线程

重要:Kafka第3篇之一条消息如何被存储到Broker上

z小赵

kafka

苟富贵,勿相忘

十三

Web3极客日报#130

谢锐 | Frozen

区块链 创业 独立开发者 技术社区 Rebase

面向兴趣编程 - 一条微博和一个小程序的故事

遇见

小程序 微信小程序 副业 面向兴趣编程

《我是余欢水》与《一个叫欧维的男人决定去死》

十三

思考如何节省时间,节省出时间进行思考

伯薇

思考 时间管理 思考力 工作效率 提升效率

演讲经验交流会|ArchSummit 上海站

演讲经验交流会|ArchSummit 上海站

数据湖需要一次“二次手术”-InfoQ