用大数据失败案例的血泪教训来诉说8个不能犯的错误

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介:

近年来,大数据旋风以“迅雷不及掩耳之势”席卷全球,不仅是信息领域,经济、政治、社会等诸多领域都“磨刀霍霍”向大数据,准备在其中逐得一席之地。然而,很多公司在迈入大数据领域后遭遇“滑铁卢”。在此,本文盘点了一系列大数据失败项目,深究其原因,具有警示意义。

对数据过于相信

2008年,Google第一次开始预测流感就取得了很好的效果,比美国疾病预防控制中心提前两礼拜预测到了流感的爆发。但是,几年之后,Google的预测比实际情况(由防控中心根据全美就诊数据推算得出)高出了50%。媒体过于渲染了Google的成功,出于好奇目的而搜索相关关键词的人越来越多,从而导致了数据的扭曲。

低估大数据复杂程度

在美国有几个互联网金融公司专做中小企业贷款。但是中小企业贷款涉及的数据更复杂,而且中小企业涉及到整个行业非常特殊的一些数据,比如非标准的财务报表和不同行业、不同范式的合同,他们没有很专业的知识,是很难理解或者很难有时间把它准确挖掘出来。

当时大数据团队想用一个很完美的模型把所有的问题都解决掉,比如把市场和信贷的解决方案全部用一个模型来解决,但因为数据的复杂程度,最后证明这种方法是失败的,而且90%的时间都在做数据清理。这就说明,想通过大数据技术一下子解决所有的问题是很难成功的,而是要用抽丝剥茧、循序渐进的方式。

管理层的惰性

某家旅游公司系统通过web日志数据的挖掘来提升客户洞察。结果证明,用户在浏览网站之后,随后的消费行为模式与管理层所认为的不一致。当团队汇报此事时,管理层认为不值一提。但是,该团队并没有放弃,并通过严密的A/B测试,回击了管理层的轻视。

这个案例的最终结果,不是每个CIO都能期盼的。但是,有一点是可以确定的:做好和管理层打交道的准备,让他们充分理解大数据是什么以及相应的价值。

应用场景选择错误

一家保险公司想了解日常习惯和购买生命保险意愿之间的关联性。由于随后觉得习惯太过于宽泛,该公司将调查范畴限定到是否吸烟上。但是,工作仍然没有实质进展。不到半年,他们就终止了整个项目,因为一直未能发现任何有价值的信息。

这个项目的失败是由于问题的复杂性。在抽烟与否之间,该公司没有注意到还有大片灰色地带:很多人是先抽烟而后又戒烟了。在将问题简单化动机的驱动下,这个部分被忽略了。

问题梳理不够全面

一家全球性公司的大数据团队发现了很多深刻的洞察,并且计划通过云让全公司共享。结果这个团队低估了效率方面的损耗,由于网络拥塞的问题,无法满足全球各个分支顺畅提交数据运行分析的需求。

该公司应该仔细思考下如何支撑大数据项目,梳理所需的技能并协调各IT分支的力量进行支持。由于网络、安全或基础设施的问题,已经有太多的大数据项目栽了跟头。

缺乏大数据分析技能

一家零售公司的首席执行官不认同亚马逊规模化、扁平化的服务模式,因此让CIO构建一个客户推荐引擎。项目最初的规划是半年为期,但是团队很快认识到诸如协同过滤(collaborative filtering)之类的概念无法实现。为此,一个团队成员提出做一个“假的推荐引擎”,把床单作为唯一的推荐产品。这个假引擎的工作逻辑是:买搅拌机的人会买床单,买野营书籍的人会买床单,买书的人会买床单。就是如此,床单是唯一的、默认的推荐品。

尽管可笑,这个主意其实并不坏,默认的推荐也能给企业带来销售上的提升。但是,由于大数据相关技能的缺失,真正意义上的引擎未能实现。

提出了错误的问题

一家全球领先的汽车制造商决定开展一个情感分析项目,为期6个月,耗资1千万美元。项目结束之后,该厂商将结果分享给经销商并试图改变销售模式。然后,所得出的结果最终被证明是错误的。项目团队没有花足够的时间去了解经销商所面临的问题或业务建议,从而导致相关的分析毫无价值。

应用了错误的模型。某银行为判断电信行业的客户流失情况,从电信业聘请了一位专家,后者也很快构建了评估用户是否即将流失的模型。当时已进入评测验证的最后阶段,模型很快就将上线,而银行也开始准备给那些被认为即将流失的客户发出信件加以挽留。

但是,为了保险起见,一位内部专家被要求对模型进行评估。这位银行业专家很快发现了令人惊奇的事情:不错,那些客户的确即将流失,但并不是因为对银行的服务不满意。他们之所以转移财产(有时是悄无声息的),是因为感情问题——正在为离婚做准备。

可见,了解模型的适用性、数据抽象的级别以及模型中隐含的细微差别,这些都是非常具有挑战性的。

管理层阻力

尽管数据当中包含大量重要信息,但Fortune Knowledge公司发现有62%的企业领导者仍然倾向于相信自己的直觉,更有61%的受访者认为领导者的实际洞察力在决策过程中拥有高于数据分析结论的优先参考价值。

选择错误的使用方法

企业往往会犯下两种错误,要么构建起一套过分激进、自己根本无法驾驭的大数据项目,要么尝试利用传统数据技术处理大数据问题。无论是哪种情况,都很有可能导致项目陷入困境。

提出错误的问题

数据科学非常复杂,其中包含专业知识门类(需要深入了解银行、零售或者其它行业的实际业务状况);数学与统计学经验以及编程技能等等。很多企业所雇用的数据科学家只了解数学与编程方面的知识,却欠缺最重要的技能组成部分——对相关行业的了解,因此最好能从企业内部出发寻找数据科学家。

缺乏必要的技能组合

这项理由与“提出错误的问题”紧密相关。很多大数据项目之所以陷入困境甚至最终失败,正是因为不具备必要的相关技能。通常负责此类项目的都是IT技术人员——而他们往往无法向数据提出足以指导决策的正确问题。

与企业战略存在冲突

要让大数据项目获得成功,大家必须摆脱将其作为单一“项目”的思路、真正把它当成企业使用数据的核心方式。问题在于,其它部门的价值或者战略目标有可能在优先级方面高于大数据,这种冲突往往会令我们有力无处使。

大数据孤岛

大数据供应商总爱谈论“数据湖”或者“数据中枢”,但事实上很多企业建立起来的只能算是“数据水坑儿”,各个水坑儿之间存在着明显的边界——例如市场营销数据水坑儿与制造数据水坑儿等等。需要强调的是,只有尽量缓和不同部门之间的隔阂并将各方的数据流汇总起来,大数据才能真正发挥自身价值。

在大数据技术之外遇到了其它意外状况。数据分析仅仅是大数据项目当中的组成部分之一,访问并处理数据的能力同样重要。除此之外,常常被忽略的因素还有网络传输能力限制与人员培训等等。

回避问题

有时候我们可以肯定或者怀疑数据会迫使自身做出一些原本希望尽量避免的运营举措,例如制药行业之所以如此排斥情感分析机制、是因为他们不希望将不良副作用报告给美国食品药品管理局并承担随之而来的法律责任。

在这份理由清单中,大家可能已经发现了一个共同的主题:无论我们如何高度关注数据本身,都会有人为因素介入进来。即使我们努力希望获取对数据的全面控制权,大数据处理流程最终还是由人来打理的,其中包括众多初始决策——例如选择哪些数据进行收集与分析、向分析结论提出哪些问题等等。

为防止大数据项目遭遇失败,引入迭代机制是非常必要的。使用灵活而开放的数据基础设施,保证其允许企业员工不断调整实际方案、直到他们的努力获得理想的回馈,最终以迭代为武器顺利迈向大数据有效使用的胜利彼岸。


本文作者:佚名

来源:51CTO

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
1月前
|
分布式计算 关系型数据库 MySQL
大数据-88 Spark 集群 案例学习 Spark Scala 案例 SuperWordCount 计算结果数据写入MySQL
大数据-88 Spark 集群 案例学习 Spark Scala 案例 SuperWordCount 计算结果数据写入MySQL
49 3
|
1月前
|
分布式计算 监控 大数据
大数据-131 - Flink CEP 案例:检测交易活跃用户、超时未交付
大数据-131 - Flink CEP 案例:检测交易活跃用户、超时未交付
65 0
|
1月前
|
消息中间件 关系型数据库 MySQL
大数据-117 - Flink DataStream Sink 案例:写出到MySQL、写出到Kafka
大数据-117 - Flink DataStream Sink 案例:写出到MySQL、写出到Kafka
136 0
|
1月前
|
存储 分布式计算 算法
大数据-106 Spark Graph X 计算学习 案例:1图的基本计算、2连通图算法、3寻找相同的用户
大数据-106 Spark Graph X 计算学习 案例:1图的基本计算、2连通图算法、3寻找相同的用户
60 0
|
1月前
|
SQL 分布式计算 NoSQL
大数据-164 Apache Kylin Cube优化 案例1 定义衍生维度与对比 超详细
大数据-164 Apache Kylin Cube优化 案例1 定义衍生维度与对比 超详细
28 1
大数据-164 Apache Kylin Cube优化 案例1 定义衍生维度与对比 超详细
|
1月前
|
分布式计算 大数据 Linux
大数据体系知识学习(二):WordCount案例实现及错误总结
这篇文章介绍了如何使用PySpark进行WordCount操作,包括环境配置、代码实现、运行结果和遇到的错误。作者在运行过程中遇到了Py4JJavaError和JAVA_HOME未设置的问题,并通过导入findspark初始化和设置环境变量解决了这些问题。文章还讨论了groupByKey和reduceByKey的区别。
29 1
|
1月前
|
消息中间件 存储 druid
大数据-156 Apache Druid 案例实战 Scala Kafka 订单统计
大数据-156 Apache Druid 案例实战 Scala Kafka 订单统计
40 3
|
1月前
|
存储 大数据 分布式数据库
大数据-165 Apache Kylin Cube优化 案例 2 定义衍生维度及对比 & 聚合组 & RowKeys
大数据-165 Apache Kylin Cube优化 案例 2 定义衍生维度及对比 & 聚合组 & RowKeys
35 1
|
1月前
|
消息中间件 druid 大数据
大数据-153 Apache Druid 案例 从 Kafka 中加载数据并分析(二)
大数据-153 Apache Druid 案例 从 Kafka 中加载数据并分析(二)
32 2
|
1月前
|
消息中间件 分布式计算 druid
大数据-153 Apache Druid 案例 从 Kafka 中加载数据并分析(一)
大数据-153 Apache Druid 案例 从 Kafka 中加载数据并分析(一)
54 1