计算机处理能力，云存储容量和使用率以及网络连接性在不断提升，而这一切正在使大多数公司当前的数据泛滥成潮——大量详细信息川流不息，如客户的个人资料、销售数据、产品规格，处理步骤等等。各种不同格式和不同来源的数据相继产生，包括物联网设备、社交媒体网站、销售系统和内部协作系统。
尽管为简化关键业务信息的收集，存储和评估而设计的工具和技术的数量有所增加，但许多公司仍不确定如何更好地处理这些数据。业务领导者和IT领导者指出，他们因应对这一切而应接不暇——数量庞大且种类繁多，信息遍历内部和外部网络的速度以及管理所有这些业务智能的成本。渐渐地，他们要承担更加复杂的任务：从所有这些业务信息中获取重要的洞察。
这些高管必须大规模且快速地扩展数据管理方面的基础设施。在这方面，有一类新兴的数据管理技术的前景十分广阔——数据湖。这些存储平台旨在保存，处理和分析结构化和非结构化数据。它们往往与传统的企业数据仓库(EDW)结合使用，但总的来说，它们的运营成本比企业数据仓库要低。之所以能节省成本是因为这些公司可以使用价格低廉且易于获得的硬件，同时也因为它们不需要在归纳时对数据集编制索引，也不需要做存储方面的准备工作。数据以其本机格式(native format)保存并且仅在需要时才进行重新配置。关系数据库也必须得到管理，可以将其当作数据湖平台的一部分进行管理，但这只是为了让最终用户更轻松地访问某些数据源。
数据湖有很多特点备受各大公司青睐。由于数据以“原始”格式加载，而不是在进入公司系统时进行预先配置，因此它们的使用方式不仅限于基本的采集。例如，有这样一群数据科学家，他们并不确切知道自己在寻找什么，但他们可以快速查找和访问数据而无需考虑格式。诚然，对希望创建可靠的高级分析程序的数据科学家来说，一个得到完善维护和管治的“原始数据区”简直就是金矿。随着这些公司不再满足于小型试点项目而纷纷扩大数据湖的使用范围，它们或许能够为业务用户建立“自助”选项，从而可以生成自己的数据分析和报告。
但是，要做到这几点十分耗时且复杂——将数据湖与技术体系结构的其他要素集成，为全公司的数据湖的使用制定合适的规则，确定能为部署数据湖提供各种必要支持的产品、人才和能力并从中实现商业利益。例如，这些公司往往缺乏某些数据管理方法方面的专业知识，而这就需要找到精通新兴数据流技术(例如Flume和Spark)的员工。
在许多情况下，这些公司纷纷放慢脚步。它们转而依靠升级技术架构的久经考验的方法，例如，参与有关最佳设计，产品和供应商的冗长的内部讨论，如果没有制定一个合适的解决方案，那就不急于创建数据湖解决方案。同时，他们也会错失部署支持数字销售和市场营销以及新产品开发的高级分析程序的机会。
公司应该在数据湖的设计和部署中采用敏捷方法——先试行一系列技术和管理方法并对其进行测试和完善，然后才能获得最佳的数据存储和访问流程。这样做的公司可以跟上快速变化的数据监管和合规标准的要求，例如，于2018年5月生效的《通用数据保护法规》。也许更为重要的是，它们比竞争对手更快使市场获得分析驱动的洞察，同时大大降低了管理数据架构的成本和复杂性。
数据湖开发的各个阶段
- 着陆区和原始数据区。在第一阶段，数据湖是与核心IT系统分开创建的，数据湖可作为低成本且可扩展的“纯捕获”环境。数据湖是公司技术栈中的一个稀薄的数据管理层，这一层可以无限期存储原始数据，然后再备用于计算环境中。组织可以部署数据湖而不会对现有的体系结构产生什么影响。如果公司不希望产生数据沼泽，那么它们早期就需要强有力的治理，包括严格的数据标记和分类。
- 数据科学环境。在下一阶段，组织可以开始更积极地将数据湖用作实验平台。数据科学家可以轻松且快速地访问数据并且可以致力于运行数据实验并分析数据，而不是仅仅专注于数据的收集。在这样一个沙箱(sandbox)中，他们可以使用未做任何更改的数据来创建分析程序的原型。他们可以在数据湖旁边部署一系列开源且商业化的工具，从而创建所需的测试平台。
- 为数据仓库减轻负载。再下一阶段，数据湖已开始与现有的企业数据仓库(EDW)集成。只要利用与数据湖有关的低存储成本，公司就可以容纳“冷”(很少使用，休眠或不活动的)数据。它们可以使用这些数据来生成洞察而不必担心迫近或超出存储限制，也不必大幅增加传统数据仓库的大小。同时，公司可以在现有的企业数据仓库中持续高强度地提取关系数据，而这些企业数据仓库可以处理这些关系数据。它们可以将强度较低的提取和转换任务迁移到数据湖，例如，“大海捞针”式的搜索，在这种搜索类型中，数据科学家需要清除数据库以查找传统索引结构无法支持的查询。
- 数据操作的关键组成部分。一旦公司进入了部署和开发这一阶段，流经公司的许多信息很可能正在通过数据湖。数据湖成了数据基础设施的核心部分，取代了现有的数据集市或运营数据存储并实现了数据即服务。企业可以充分利用数据湖技术的分布式特性及其处理计算密集型任务的能力，例如执行高级分析或部署机器学习程序所需的任务。有些公司可能决定在数据湖之上创建数据密集型应用程序(例如，性能管理仪表板)。或者它们可以实施应用程序编程接口，以便无缝地将从数据湖资源中获得的洞察与从其他应用程序中获得的洞察无缝地结合起来。
公司将数据湖从简单的着陆区(landing zone)扩展到数据基础设施的关键组件所需的时间和能力将因其目标和出发点而异。在发展的各个阶段，公司都需要研究与这些因素相关的复杂问题——数据集的大小和种类，数据管理中的现有功能，业务部门中的大数据专业知识水平以及IT组织中的产品知识。例如，当前环境中的分析工具有多复杂?公司是使用传统的开发工具和方法，还是使用较新的工具?公司通常需要多少个并发数据用户?工作负载是否得到动态管理?最终用户需要多长时间才能访问数据?在数据湖开发流程的各个阶段，公司可能会被各种细节弄得焦头烂额并失去动力。IT组织或业务部门的领导者不可避免地要去处理其他“紧急”项目。
但是，当IT和业务领导者根据敏捷开发模型回答这样那样的问题时，他们就可以加快数据湖从“科学项目”到完全集成了数据基础架构的组件的过程。根据我们的经验，敏捷方法有助于公司在数月(而非数年)的时间内从数据湖中获得优势。快速取得成果并证明近期的影响，这有助于使IT领导者和业务领导者参与并专注于数据管理方面的问题，从而限制这样的需求——未来的返工和与数据填充以及对管理和访问数据湖相关的协议进行无休止的调整。敏捷方法可以使IT和业务主管意见一致。这种协作不仅对于确定数据湖的技术路线至关重要，而且对创建有利于数据的工作环境以及基于数据洞察抓住新的商机都是至关重要的。
建立数据湖：敏捷方法
大多数组织都了解在软件开发环境中对敏捷方法的需求。但鲜有组织在数据管理的环境中应用敏捷。通常，IT组织会牵头审核潜在的技术和方法来创建数据湖，而很少听取业务部门的意见。在敏捷方法中，IT领导者和业务领导者共同概述和解决相关技术和设计问题。例如，企业是使用一揽子解决方案来创建数据湖，还是将其托管在云端(使用私有服务器、公共服务器或混合异地服务器)?如何填充数据湖，即哪些数据集将流入数据湖，什么时候流出数据湖?理想情况下，数据湖的填充应该基于使用的轻重缓急并分多次完成，而不是一次性花大量的精力来连接数据湖内所有的相关数据流。
实际上，最成功的数据湖先行企业正在使用“业务支持(business back)”的方法来设计数据湖，而不是首先考虑技术因素。这些先行者正在确定业务部门可以从数据湖中获得最大价值的方案，然后将这些方案纳入存储解决方案的设计(或重新设计)和部署决策中。然后，这些公司将根据需要用特定组或用例的数据来渐渐填充数据湖。公司没有全力采用一种指定的解决方案，而是试行了不同提供商的两个或三个最终候选方案，以评估其产品的实际性能，集成的简易性和可扩展性。
这种灵活的部署方法可以确保尽早发现性能或实施方面的难题。这还包含了业务部门的反馈。随着数据湖的填充，分析和存储技术的变革以及业务需求的发展，这也为敏捷开发团队腾出了修改流程和数据管理协议的空间。
随着数据湖渐渐从试验项目转变为数据体系结构的核心元素，业务和技术领导者必须重新考虑其治理策略。具体来说，随着数据在数字世界中得到快速收集和使用，这些领导者必须学会在这两者之间取得平衡——传统数据监管的刚性与对灵活性的需求。在敏捷的治理方法中，企业可以在新的资源进入数据湖时进行充分地监督，从而避免传统数据仓库所需的一些更严格的工程实践，然后根据业务需求确定最佳规则和流程以寻求最佳解决方案。例如，即使某类数据的业务案例仍在确认中，数据科学家仍可以自由地研究数据。同时，如果用例没有坚实的根基，一线用户很可能会面临更严格的管控。
但是，至少，公司应该指定某些人来负责管理数据集和流程，以便明确职责并快速做出与数据源和访问权限有关的决策。由于数据不是预先构造的，因此公司还希望捕获流入数据湖中的所有数据源(在数据湖本身内或在单独的注册表中)的元数据并为所有利益相关者维护一个中央数据目录。此外，公司在使用数据管理协议时可能需要重新配置访问权限，同时要牢记与保存个人身份信息有关的各种法规要求和隐私问题。数据负责人必须将这些访问权限传达给所有的利益相关者。
一家全球银行的转型
我们不妨思考一下一家跨国银行是如何在其数据湖开发中应用敏捷原则的。该银行一直面对几个关键的数据难题：低质量的业务信息、没有足够的专家来管理不同格式的数据集、陈旧的数据仓库技术以及千余个数据源。这个系统混乱不堪。该银行必须将传入的数据集输入到四个数据仓库层(输出传递、标准格式、主题层和应用程序层)以及在创建任何可用的报告之前，它都必须对这些层进行结构化。
除了这些技术难题之外，银行的业务和IT领导者并没展开合作，这加剧了该公司的数据问题。数据存储于隔离的系统中，因此重要的业务信息往往一直无法得到使用。但是，由于业务部门和IT部门之间的协调和沟通不畅，它们要求访问某些数据集时无法得到快速响应。它们将数据管理视为“IT的工作”;业务领导者对这个话题讳莫如深，因此极力表达他们的数据需求。
该银行的高管们担心失去客户，这在一定程度上归因于该公司无法熟练地管理数据。他们决定使用数据湖技术来尝试简化数据集的提取，结构化和传递。为了跟上软件开发人员的工作速度，该公司使用了敏捷开发模型并分阶段推出了数据湖项目。
高管们召集了一个由业务部门和IT组织的课题专家组成的敏捷的数据团队，此举的目的是先本着提高数据质量和数据访问的目的考虑各种用例的业务影响，然后再确定公司就哪些领域对数据湖进行初步访问。
实施敏捷的数据团队对业务用户进行了深入的访谈以确定现有数据管理实践中的各种痛点和机遇。该团队计划在为期四个月的窗口期内发布大量新的数据服务和应用程序——此举是为了实施新的数据管理工具，与业务部门一起开发数据交付服务并根据客户的反馈意见完善流程。启动敏捷数据项目的最初几个月里，该银行就能够将与特定业务用例相关的数据加载到一个公共环境中并发现为业务部门提供服务所需的关键数据元素。
业务取得了引人注目的成果，这些成果使该银行在接下来数月将数据湖的使用范围扩展到其他领域。从预先为所有数据按结构编排到只为已得到使用的数据记录后端的过程，这样的转变十分重要。银行能够打破数据孤岛。如今，银行可以在一个地方找到系统的信息，而且员工能够访问各种各样的数据(人口、地理、社交媒体等)，从而无死角地查看客户。业务部门和IT部门之间的协作得到了加强，员工和客户的满意度也得到了提升。
有越来越多的公司在试验数据湖，它们希望在信息流中获得固有优势，因为这些信息流易于访问，而且其存储成本要比传统仓库中的数据便宜。但是，与任何新技术的部署一样，这些公司将需要重新构想各种系统，流程和治理模式。安全协议，人才库和企业体系结构的创建将不可避免地存在问题，这些问题不仅可以确保技术栈内部的灵活性，还可以确保业务职能的灵活性。我们的经验表明，采用敏捷方法实施数据湖有助于公司快速且高效地学习新事物。
