1.5 开启云数据湖之旅

笔者曾与数百名客户讨论他们的大数据分析方案，并帮助他们完成了部分云数据湖之旅。这些客户有不同的动机和需要解决的问题：一些客户是云新手，希望迈出数据湖的第一步；一些客户已经在云上实现了数据湖支持一些基本方案，但不确定下一步该怎么做；有些是云原生客户，他们希望将数据湖作为其应用程序架构的一部分；还有一些公司已经在云上成功地实施了数据湖，并希望利用数据的力量来提供与同行和竞争对手相比更高级别的差异化价值。如果总结从所有这些对话中学到的东西，那么基本上归结为两件关键的事情：

• 无论你对云的了解程度如何，都可以为公司的未来设计数据湖。

• 立即根据你的需求做出实施选择！

这听起来太显而易见且太笼统了。但是，在本书的其余部分，我为设计和优化云数据湖提供的框架和指南将假设你不断针对以下两个问题进行检查：

1.推动数据湖决策的业务问题是什么？

2.当我解决了这个问题时，我还能做些什么来区分我的业务与数据湖？

来看一个具体的例子。促使客户实施云数据湖的一个常见场景是，支持其Hadoop集群的本地硬件即将到期。此Hadoop集群主要由数据平台和BI团队使用从其本地事务存储系统摄取的数据来构建智能仪表盘和多维数据集，公司需要决定是购买更多硬件并继续维护其本地硬件，还是投资大家都在谈论的云数据湖（它承诺弹性扩展、更低的拥有成本，还可以利用更多功能和服务，以及1.4节介绍的所有其他优点）。当这些客户决定迁移到云时，受硬件使用寿命的限制，需要在硬件寿命结束时完成迁移，因此他们选择直接迁移策略，采用现有的本地实施并将其移植到云中。这是一种非常好的方法，特别是考虑到这些是服务于关键业务功能的生产系统。但是，这样做后，客户很快意识到以下三点：

• 甚至需要付出更多努力才能直接提升和改变它们的实施。

• 如果意识到云的价值，并希望添加更多场景，则会受到其设计选择（例如，安全模型、数据组织等）的约束，这些选择最初假设在数据湖上运行一组BI场景。

• 在某些情况下，直接迁移架构最终在成本和维护方面都更加昂贵，从而有悖初衷。

这很令人惊讶。这些意外主要源于本地系统和云系统之间的架构差异。在本地Hadoop集群中，计算和存储是位于同一位置且紧密耦合的，而在云上，其想法是拥有一个对象存储/数据湖存储层，例如，Amazon S3、Azure Data Lake Store（ADLS）和Google Cloud Storage（GCS），并且有大量的计算选项可供选择，如IaaS（配置虚拟机并运行自己的软件）或PaaS（例如，Azure HDInsight、Amazon EMR等），如图1-6所示。在云上，你的数据湖解决方案本质上是用乐高积木构建的结构，可以是IaaS、PaaS或SaaS产品。

我们已经看到了计算存储解耦架构在独立扩展和降低成本方面的优势。但是，这要求云数据湖的架构和设计遵循这种解耦的架构。例如，在云数据湖实现中，计算系统通过网络系统与存储系统通信，而不是本地调用。如果不对此进行优化，则会影响成本和性能。同样，一旦完成主要BI方案的数据湖实施，你就可以通过启用更多方案、引入不同的数据集或对数据湖中的数据进行更多数据科学探索性分析，从而从数据湖中获得更多价值。同时，你希望确保数据科学探索工作不会意外删除你的数据集，因为这些数据集为销售副总裁每天早上都希望看到的智能仪表盘提供支持。你需要确保现有的数据组织和安全模型可确保这种隔离和访问控制。

将这些惊人的机会与你必须迁移到云的原始动机（即你的本地服务器使用寿命即将结束）联系起来，你需要制定一个计划，帮助满足时间表，同时为在云上取得成功做好准备。迁移到云数据湖涉及两个目标：

• 关闭本地系统。

• 在云上取得成功。

大多数客户最终只关注第一个目标，并在不得不重新构建应用程序之前陷入巨额技术债务。当考虑云数据湖架构时，确保你的目标是：

• 将数据湖迁移到云。

• 实现数据湖现代化，以适应云架构。

这两个目标将齐头并进，帮助你确定一个能够满足企业不断增长的业务规模和需求的健壮的架构。

要了解如何实现这两个目标，你需要了解云架构是什么、实施的设计注意事项是什么，以及如何优化数据湖的规模和性能。第2～4章将详细讨论这些问题。书中还将重点提供一个框架，帮助读者考虑云数据湖之旅的各个方面。