使用 Google Cloud 构建现代化的统一分析数据平台

不断创建的数据越来越多。IDC 的研究表明，到 2025 年，全球数据将增长到 175 ZB¹。每天生成的数据量惊人，公司越来越难以以可访问和使用的方式收集、存储和整理数据。事实上，90% 的数据专业人士表示，不可靠的数据源拖慢了他们的工作速度。大约 86% 的数据分析师都在为过时的数据苦苦挣扎，超过 60% 的数据工作者每月都需要等待工程资源才能清理和准备数据²。

低效的组织结构和架构决策导致公司在汇总数据以及使其服务于公司之间出现差距。各公司希望迁移到云端以对其数据分析系统进行现代化改造，但单凭这一点并不能解决孤岛式数据源和脆弱处理流水线等潜在问题。必须以整体的方式做出有关数据所有权的战略决策和有关存储机制的技术决策，以便为您的组织提供更成功的数据平台。

在本文中，我们将讨论构建基于 Google Cloud 的现代化统一分析数据平台所需的决策点。

在过去二十年里，大数据为企业创造了惊人的机遇。然而，对于组织而言，向企业用户及时提供相关、可操作的数据是十分复杂的。研究表明，86% 的分析师仍然对过时的数据感到苦恼³，只有 32% 的公司认为他们从数据中实现了有形价值⁴。第一个问题是数据新鲜度。第二个问题源于难以跨孤岛集成异构的旧式系统。组织正在向云迁移，但这并不能解决较早的旧式系统的实际问题，这些系统可能采用垂直结构，以满足单个业务部门的需求。

在规划组织数据需求时，很容易过度概括和考虑单个简化的结构，该结构包含一组一致的数据源、一个企业数据仓库、一组语义和一款商业智能工具。这种方案可能适用于规模非常小且高度集中化的组织，甚至可能适用于具有自己的集成式 IT 和数据工程团队的单个业务部门。然而，在实践中，没有什么组织会如此简单，并且数据注入、处理和/或使用总是异常复杂，使情况变得更加棘手。

在与数百位客户交流的过程中，我们发现他们需要一种更全面的数据和分析方法，该平台可满足多个业务部门和用户角色的需求，并尽可能减少处理数据的冗余步骤。这不再是需要购买的新架构或一组软件组件；它要求公司评估其整体数据成熟度，并在技术升级之外进行系统性的组织调整。

到 2024 年底，75% 的企业将从 AI 小规模测试转向大规模运营，推动流式数据和分析基础设施增长到 5 倍⁵。在孤立的环境中，通过一个合理距离数据科学团队来测试 AI 是相当容易的。但是，阻止这些数据洞见发布到生产系统中的根本挑战是组织和架构方面的摩擦导致数据所有权细分。因此，纳入组织业务运营的大多数数据洞见在本质上都是描述性的，而预测分析则被赋予研究团队的职责。

数据工作很少由一个人完成；组织中有许多与数据相关的用户在数据生命周期中扮演重要角色。每个用户在数据治理、新鲜度、可检测性、元数据、处理时间安排、可查询性等方面都有不同的观点。在大多数情况下，他们使用不同的系统和软件在不同的处理阶段处理相同的数据。

我们以机器学习的生命周期为例来说明一下。数据工程师可能负责确保为数据科学团队提供最新数据，同时设置适当的安全和隐私限制条件。数据科学家可以基于来自数据工程师的黄金预汇总数据源集创建训练和测试数据集，构建和测试模型，并为其他团队提供数据洞见。机器学习工程师可能负责以不中断其他数据处理流水线的方式将模型打包部署到生产系统中。产品经理或业务分析师可能使用 Data QnA（用于分析 BigQuery 数据的自然语言界面）或可视化软件查看派生的数据洞见，也可能直接通过 IDE 或命令行界面查询结果集。由于拥有大量不同需求的用户，因此我们打造了一个压缩平台来为他们提供服务。Google Cloud 提供各种工具以满足客户的需求，无论他们身在何处，都能满足其业务需求。

在与客户谈论他们的数据分析需求时，我们经常会听到这样的问题：“我需要哪一个：数据湖还是数据仓库？”鉴于组织内数据用户和需求的多样性，这可能是一个棘手的问题，具体取决于预期用途、数据类型和人员。

• 如果您知道需要分析哪些数据集，清楚了解其结构，并有一系列需要解答的已知问题，那么您很可能在看数据仓库
• 另一方面，如果您需要通过多种数据类型发现数据、不确定需要运行哪些类型的分析、想要寻找机会进行探索而不是呈现数据洞见，并且您具备有效管理和探索此环境的资源，则数据湖可能更适合您的需求

不过，做决定还远远不够，下面我们来看一下每种组织在组织上面临的一些挑战。数据仓库通常难以管理。在过去 40 年中表现良好的旧式系统已经被证明非常昂贵，并且在数据新鲜度、扩缩和高成本方面带来了许多挑战。此外，它们无法轻松提供 AI 或实时功能，除非事后才支持该功能。这些问题不仅存在于本地旧数据仓库中，我们甚至在新创建的云端数据仓库中也看到了这一点。尽管许多企业都宣称能够提供集成式 AI 功能，但实际上却并未提供。这些新数据仓库本质上是相同的旧环境，但迁移到了云端。数据仓库用户往往是分析师，通常在特定的业务部门供职。他们可能会对额外的数据集有所想法，这有助于丰富他们对业务的了解。他们可能对分析、数据处理和商业智能功能要求的改进有一些想法。

然而，在传统组织中，他们通常无法直接接触数据所有者，也不能轻松影响决定数据集和工具的技术决策者。此外，由于他们与原始数据是分开的，因此无法测试假设，也无法推动对基础数据的更深入的理解。数据湖也有自己的挑战。理论上，它们费用低、易于扩缩，但我们许多客户在其本地数据湖中发现了不同的情况。规划和预配足够的存储空间可能既昂贵又困难，尤其是对于数据量高度可变的组织而言。本地数据湖可能很脆弱，而且维护现有的系统需要时间。在许多情况下，原本负责开发新功能的工程师转而负责数据集群的维护和馈送工作。直言不讳地说，他们是在维护价值，而不是创造新价值。总体而言，许多公司的总拥有成本高于预期。不仅如此，治理难以跨系统解决，尤其是在组织的不同部分使用不同的安全模型时。结果，数据湖变得孤立和细分，难以跨团队共享数据和模型。

数据湖用户通常更靠近原始数据源，并且可以使用用于探索数据的工具和功能。在传统组织中，这些用户往往专注于数据本身，并且经常与企业的其他部门保持着合理的距离。这种脱节意味着业务部门错失了寻找能够推动其业务目标实现更高收入、更低成本和更低风险以及抓住新机遇的数据洞见的机会。考虑到这些利弊，许多公司最终选择了混合方法，即设置数据湖以将部分数据转移到数据仓库，或者数据仓库设有侧数据湖以进行额外的测试和分析。但是，由于多个团队会制作自己的数据架构来满足各自的需求，对中央 IT 团队而言，数据共享和保真度变得更加复杂。与拥有不同目标的独立团队（即一个团队探索业务，另一个了解业务）不同，您可以将这些职能部门及其数据系统结合起来，形成一个良性循环，对业务的深入了解推动定向探索，而该探索可以推动团队更好地了解业务。

您可以在 Google Cloud 上单独构建数据仓库或数据湖，但不必二选一。在很多情况下，我们的客户使用的底层产品是相同的，他们的数据湖和数据仓库实现之间的唯一区别是所采用的数据访问政策。事实上，这两个术语已经开始整合成一组更为统一的功能（一个现代化的分析数据平台）。我们来看看这在 Google Cloud 中的运作方式。

BigQuery Storage API 提供了将 BigQuery Storage（如 Cloud Storage）用于 Dataflow 和 Dataproc 等许多其他系统的功能。这样可以打破数据仓库存储墙，并在 BigQuery 上运行高性能数据框架。换言之，BigQuery Storage API 可让 BigQuery 数据仓库发挥数据湖的作用。那么它有哪些实际用途呢？首先，我们构建了一系列连接器（例如 MapReduce、Hive、Spark），以便您可以直接对 BigQuery 中的数据运行 Hadoop 和 Spark 工作负载。除了数据仓库外，您不再需要数据湖！Dataflow 具备极其强大的批处理和流处理功能。目前，您可以针对 BigQuery 数据运行 Dataflow 作业，使用来自 Pub/Sub、Spanner 或任何其他数据源的数据丰富这些数据。

BigQuery 可以独立扩缩存储和计算，并且每种服务都是无服务器的，可以无限扩缩以满足不同团队、工具和访问模式的需求。上述所有应用都可以在不影响同时访问 BigQuery 的任何其他作业的性能的情况下运行。此外，BigQuery Storage API 还提供 PB 级网络，在节点之间移动数据以满足查询请求，从而有效地实现与内存中操作类似的性能。它还允许直接与热门的 Hadoop 数据格式（如 Parquet 和 ORC）以及 NoSQL 和 OLTP 数据库联合。您可以更进一步，利用 Dataflow SQL（内嵌在 BigQuery 中）提供的功能。这样，您就可以将数据流与 BigQuery 表或文件中的数据联接起来，有效创建 lambda 架构，从而注入大量批量数据和流式数据，同时提供服务层来响应查询。借助 BigQuery BI Engine 和物化视图，您可以更轻松地在此多用途架构中提高效率和性能。

无服务器数据解决方案对于让您的组织摆脱数据孤岛并进入数据洞见和行动的领域来说必不可少。我们的所有核心数据分析服务都是无服务器且紧密集成的。

变更管理通常是将任何新技术融入组织中最困难的方面之一。Google Cloud 致力于为开发者和企业用户提供熟悉的工具、平台和集成服务，无论客户身处何地，都能满足他们的需求。我们的使命是通过数据驱动的创新，提高您的组织进行数字化转型和重新构想业务的能力。Google Cloud 不会受制于特定供应商，而是为公司提供选择，使他们能够简单、轻松地与本地环境、其他云产品甚至边缘集成，从而打造真正的混合云：

• BigQuery Omni 无需将数据从一个环境移植到另一个环境，无论环境如何，都可以对数据进行分析
• Apache Beam 是 Dataflow 上利用的 SDK，可为 Apache Spark 和 Apache Flink 等运行程序提供可转移性和可移植性
• 对于希望运行 Apache Spark 或 Apache Hadoop 的组织，Google Cloud 提供了 Dataproc

大多数数据用户关心的是他们拥有什么数据，而不是数据所在的系统。最重要的是能够适时访问他们需要的数据。因此在大多数情况下，平台类型对用户来说无关紧要，只要他们能够使用熟悉的工具访问最新的可用数据 - 无论他们是探索数据集、管理数据存储区中的来源、运行临时查询，还是为高管级利益相关方开发内部商业智能工具。

继续将数据湖和数据仓库整合到统一分析数据平台的理念之后，还有一些其他数据解决方案越来越受欢迎。例如，我们看到很多关于湖仓一体和数据网格的概念不断涌现。您以前可能听说过其中一些术语。有些并非新鲜事物，多年来一直在以不同的形式出现。但是，它们在 Google Cloud 环境中会运行得非常好。我们来详细了解一下 Google Cloud 中的数据网格和湖仓一体是什么样子的，以及它们对组织内的数据共享意味着什么。湖仓一体和数据网格不是互斥的，而是有助于解决组织内部的不同挑战。但一个支持数据，另一个支持团队。数据网格可帮助用户避免因一个团队遇到瓶颈，从而实现整个数据栈。它在架构中以联合方式访问数据，将孤岛拆分为较小的组织部门。湖仓一体将数据仓库和数据湖结合在一起，支持不同类型和更多的数据。这有效地导致了读取模式而非写入时模式，该功能是数据湖的一项功能，被认为可以缩小企业数据仓库中的某些性能差距。作为一个额外的好处，该架构还借用了更严格的数据治理，这是数据湖通常不具备的。

如上所述，BigQuery 的 Storage API 可让您将数据仓库视为数据湖。在 Dataproc 或类似 Hadoop 环境中运行的 Spark 作业可以使用存储在 BigQuery 中的数据，而无需通过从数据仓库中获取存储空间来实现单独的存储媒介。与 BigQuery 中的存储分离的庞大计算能力实现了基于 SQL 的转换，并利用了这些转换不同层的视图。进而引入 ELT 类型的方法，并实现更敏捷的数据处理平台。BigQuery 采用 ELT 而非 ETL，支持将基于 SQL 的转换存储为逻辑视图。使用传统数据仓库将所有原始数据转储到数据仓库存储空间可能很昂贵，但 BigQuery 存储并没有附加费用。它的费用与 Google Cloud Storage 中的 blob 存储费用相当。

执行 ETL 时，转换是在 BigQuery 之外进行，而且可能在不能扩缩的工具中进行。它最终可能逐行转换数据，而不是并行执行查询。在某些情况下，Spark 或其他 ETL 流程可能已经编码，并且为了新技术而更改它们可能没有意义。但是，如果可以使用 SQL 编写转换，则 BigQuery 可能是进行转换的好地方。

此外，所有 Google Cloud 组件（例如 Composer、Data Catalog 或 Data Fusion）都支持此架构。它为不同用户角色提供了一个端到端层。减少运营开销的另一个重要方面是利用底层基础设施的功能。以 Dataflow 和 BigQuery 为例，它们都在容器上运行，让我们可以管理正常运行时间和后台机制。一旦扩展到第三方和合作伙伴工具，当他们开始探索类似功能（例如 Kubernetes）时，它的管理和可移植性就会变得更简单。这样可以降低资源和运营开销。此外，您还可以通过 Cloud Composer 利用监控信息中心来提升可观测性，从而实现卓越运营。您不仅可以通过将存储在 Cloud Storage 和 BigQuery 中的数据整合在一起来构建数据湖，而无需执行任何数据移动或复制操作，而且我们还提供了额外的管理功能来管理您的数据源。Dataplex 提供一个集中管理层来协调 Cloud Storage 和 BigQuery 中的数据，从而实现湖仓一体。这样，您就可以根据业务需求整理数据，不再受数据存储方式或存储位置的限制。

Dataplex 是一种智能数据结构脉络，可让您以合适的性价比来分布数据，同时让所有分析工具安全地访问这些数据。它提供以元数据为主导的数据管理及内置的数据质量和治理功能，让您可以减少花在基础设施边界和低效问题上的时间、信任您拥有的数据，并腾出更多时间从这些数据中发掘价值。此外，它还提供集成式分析体验，将 Google Cloud 与开源技术的精华整合在一起，让您可以快速、大规模地管理、保护、集成和分析数据。最后，您可以制定一个分析策略，以增强现有架构并满足财务治理目标。

数据网格建立在跨数据仓库和数据湖的悠久创新基础之上，并且拥有强大的可伸缩性能支付模式、API、DevOps 以及与 Google Cloud 产品的紧密集成。通过这种方法，您可以有效地创建按需数据解决方案。数据网格将数据所有权分散给网域数据所有者，每个网域数据所有者负责以标准方式提供数据作为产品。数据网格还有助于组织的不同部分与不同位置的分布式数据集之间的通信。在数据网格中，从数据中发掘价值的责任联合给最了解数据的人；换言之，创建数据或将数据引入组织的人员也必须负责根据其创建的数据将消耗性数据资产创建为产品。在许多组织中，由于在整个组织中反复提取和转换数据，但没有对新创建的数据明确的所有权责任，因此建立“单一可信来源”或“权威数据源”是一项挑战。在数据网格中，权威数据源是由来源网域发布的数据产品，具有一位明确指定的数据所有者兼管理者（负责这些数据）。

总而言之，数据网格有望实现面向网域的分散数据所有权和架构。这是通过具有联合计算和访问层来实现的，就像我们在 Google Cloud 中提供的一样。此外，如果您的组织希望获得更多功能，则可以使用 Looker 等工具，它可以提供统一的层来对数据进行建模和访问。Looker 的平台提供了仅含单个窗格的界面，方便您访问最真实、最新版本的公司数据和业务定义。通过这种统一的业务视图，您可以选择或设计数据体验，确保用户和系统以最契合自己需求的方式获得数据。这非常适用，因为可让数据科学家、分析师甚至业务用户通过单一语义模型访问他们的数据。数据科学家仍然要访问原始数据，但无需数据移动和复制。

我们将在 BigQuery 等工作负载产品的基础上构建其他功能，以简化数据集的创建和管理。Analytics Hub 提供了创建私有数据交换平台的功能。在交换平台上，交换管理员（又称为数据管理者）向公司内部的特定个人或群组以及外部业务合作伙伴或买方的特定个人或群组授予了在交换平台上发布和订阅数据的权限。

发布、发现和订阅共享资产，包括开源格式，由 BigQuery 的可伸缩性提供支持。发布方可以查看汇总的使用情况指标。数据提供方可以通过数据、数据洞见、机器学习模型或可视化工具触达企业 BigQuery 客户，并利用 Cloud Marketplace 使其应用、数据洞见或模型实现创收。这也类似于通过 Google 管理的交换平台管理 BigQuery 公共数据集的方式。通过访问独特的 Google 数据集、商业/行业数据集、公共数据集或者您的组织或合作伙伴生态系统的精选数据交换平台，推动创新。

虽然从头开始打造全新的数据平台听起来不错，但我们深知，并不是每家公司都具备这样做的条件。大多数公司都在处理现有的旧系统，这些系统需要迁移、移植或修补，直到被替换掉。我们曾在客户数据平台历程的每个阶段与其合作，现在提供了相关解决方案来满足您的具体需求。

我们看到的客户迁移通常分为三类：迁移并更换平台、迁移并重新安置和全面现代化改造。对于大多数企业来说，我们建议从迁移并更换平台开始，因为这项迁移影响重大，而且能够尽可能减少中断和风险。借助此策略，您可以将旧数据仓库和 Hadoop 集群中的数据迁移到 BigQuery 或 Dataproc。迁移数据后，您可以优化数据流水线和查询以提高性能。借助迁移并更换平台这种迁移策略，您可以根据工作负载的复杂程度分阶段执行此操作。对于具有集中式 IT 和多个业务部门的大型企业客户，鉴于其复杂性，我们建议采用此方法。

我们最常见的第二种迁移策略是进行全面现代化改造。这彻底打破了过去的局面，因为您将完全采用云原生方法。它在 Google Cloud 上以原生方式构建，但由于您需要一次性更改所有内容，因此如果您有多个大型旧环境，迁移速度可能会变慢。

彻底的旧换新需要重写作业和更改不同的应用。但是，与其他方法相比，这种方法还具有更高的速度和敏捷性，并且长期总拥有成本最低。这是因为两个主要原因：您的应用已经优化，无需改造；而迁移数据源之后，您就不必同时管理两个环境。这种方法最适合旧环境很少的数字原生企业或依托工程的组织。

最后，最保守的方法是迁移并重新安置，我们建议将其作为短期战术性解决方案来将数据资产迁移到云端。您可以迁移并重新安置您的现有平台，并像以前一样继续使用它们，只不过是在 Google Cloud 环境中使用。这适用于 Teradata 和 Databricks 等环境，可降低初始风险并允许应用运行。但这会将现有孤岛环境引入到云中，而不会实现其转型，所以您无法获得在 Google Cloud 上以原生方式构建的平台的性能益处。不过，我们可以帮助您完全迁移到 Google Cloud 原生产品，这样您就可以利用互操作性，并在 Google Cloud 上创建完全现代化的分析数据平台。

我们认为，基于 Google Cloud 构建的分析数据平台的独特之处在于其开放、智能、灵活和紧密集成的特点。市场上有许多解决方案提供的战术性解决方案可能让人感到舒适和熟悉。然而，这些方法通常只提供短期解决方案，并且会随时间推移不断使组织和技术问题复杂化。

Google Cloud 显著简化了数据分析工作。您可以利用云原生的无服务器方法将存储与计算分离开来，并在几分钟内分析 GB 级到 PB 级的数据，从而发掘数据中隐藏的潜能。这让您能够消除规模、性能和费用方面的传统限制，从而提出有关数据的任何问题并解决业务问题。这样一来，您就可以通过一个可信的数据结构脉络更轻松地在整个企业范围内将数据洞见付诸应用。

有何好处？

• 让您完全专注于分析，而不是基础设施
• 为数据分析生命周期的每个阶段解决问题，从注入到转换和分析，再到商业智能等
• 奠定了坚实的数据基础，以便将机器学习技术付诸应用
• 使您的组织能够利用卓越的开源技术
• 可扩缩规模来满足您企业的需求，尤其是在您增加数据使用量来推动业务和完成数字化转型时

基于 Google Cloud 构建的现代统一分析数据平台可为您提供数据湖和数据仓库的最佳功能，却又能更紧密地集成到 AI 平台中。您可以自动处理数十亿流处理事件的实时数据，最多在数毫秒内即可提供数据洞见，以响应不断变化的客户需求。我们业界领先的 AI 服务可以优化您的组织决策和客户体验，帮助您缩小描述性分析和规范分析之间的差距，且无需组建新团队。您可以通过内置的自动化智能技术提升现有技能，扩大 AI 的影响。