该作者在这方面还有点道理，但让我解释一下为什么这是组织机构所面临的难题，而实际上并不是任何技术堆栈（中间件或云或大数据）的过错。这个难题在于：寻找大数据项目的商业价值往往是一个精细活，涉及到整个复杂的组织结构。IT 部分当然可以将 POC（概念验证）作为一门科学或一项「一次性简历构建」项目而开始，但其业务线需要从一开始就参与进来，比其它任务技术类别都早。大数据并不是关于存储大量数据的基础设施的施工，而是关于如何在收集和策划的数据上创造业务分析。不管这些分析是简单而老套的商业智能（BI），还是数据科学导向的，它们都依赖于一个组织本身的文化和创新。

组织机构不仅在使用大数据来解决已有的业务难题（销售更多商品、检测欺诈、报告风险等），而且也在使用大数据分析得到的见解来快速实验新的业务模型。聪明的 CDO（首席数据官）应该知道如何拥有这种技术、创造合适的内部成本核算模型并将已有的业务线（LOB）项目纳入到数据湖（data lake）。

每个 CDO 在一开始时就要提出以下两个问题：

整个组织将要具备怎样的业务能力？

哪方面的数字转换可以通过大数据达到最优？

假设 3：对于 PB 级的大规模数据，大数据是唯一可行的技术解决方案

该作者写道：「如果你的企业没有巨量数据的问题，你真的用不着 Hadoop，所以数以百计的企业都对他们无用的 2 到 10 TB 的 Hadoop 集群感到非常失望——在这种规模上，Hadoop 技术没有任何优势。」

这并不能从实际情况上观察到，因为以下三个原因：

首先，大多数 TB 级的项目都是租用的更大规模的集群。数据湖的真正价值是在跨组织的数据库上构建，而在此之前，这么做需要高昂的成本，或者难度太大。一旦你将所有数据都集中到了一处，那么你就可以将它们混合起来，以一种前所未有的方式对其进行分析。

其次，正如我将在下面说的那样，许多玩家正在使用大数据来在操作 TB 级的数据的同时获得关键的「速度」优势。

第三，我推荐每一个客户从「小」开始，并将数据湖用作企业登陆区——用于企业常规业务运营所产生的数据。Hadoop 集群不仅可被用作廉价的存储，但也可用于执行一些重复但计算密集型的数据处理任务（数据连接、排序、分割、binning 等等），这能将企业数据仓库（EDW）从一系列繁重的工作中解脱出来。

假设 4：很难找到 Hadoop 人才

作者的话——「尽管 57% 的人认为，技术鸿沟是主要原因，这个比例也不会一夜之间发生改变。这正好与 Indeed 的发现吻合：他们追踪了『Hadoop 测试』岗位情况，2014 年中期，招聘广告百分比最高为 0.061%，但是，2016 年增至 0.087%，18 个月里增加了 43%。这些情况可能预示着，采用 Hadoop 并没有下降到那些传闻臆想所暗示的程度，不过，公司也很容易发现他们很难从公司当前团队的 Hadoop 那里实现价值，他们需要更好的专业技术人才。」

这个技术鸿沟是确实存在的且主要存在这三个领域——数据科学家、数据工程师以及 Hadoop 管理员。不过，atv，这并不是 Hadoop 独有的难题，实际上每种新技术都会有这种烦恼。公司要通过增强内部员工的的技能、与全球系统集成商（GSI）、与学术界合作来弥合这个鸿沟。实际上，从事大数据项目的前景会吸引人才加入组织。

大型组织该如何启动自己的大数据之旅？

避免跌进「大数据并不带来价值」这个坑的最佳措施是什么？

以最高级别推进大数据以及大数据商业和技术应用的讨论。大数据需要在最高级别上成为组织 DNA 的一部分，需要和其他驱动产业的主要技术一起加以讨论——比如云技术、移动技术、开发运营以及社交、API 等。

打造或者组建一支首席数据官领导下的团队。团队可以是现实的，也可是虚拟的，但都需要将组织策略纳入考虑。

建立一个卓越中心（COE：Center of Excellence）或者类似这样的联合渠道，在这里，中心团队可以就这些项目与不同的业务线合作。

作为 COE 的一部分，还要制定一个采纳最新技术的流程。

合适的监管和项目监督

找出那些能驱动大数据项目的关键业务标准，包括对期望增长加速、成本削减、风险管理以及实现竞争优势的详细分析。

让业务线参与进来，以迭代的方式发展这些能力。几乎所有成功的大数据项目都是以一种开发运营的方式得以推进的。

总结