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

不断创建的数据越来越多。IDC 研究表明，到 2025 年，全球数据量将增长到 175 ZB¹。每天生成的数据量之大令人震惊，而企业要以易于获取和利用的方式对其进行收集、存储和整理也变得愈发困难。事实上，90% 的数据专业人员表示，由于数据来源不可靠，他们的工作进度受到了影响。约 86% 的数据分析师都遇到过数据过时的问题，而超过 60% 的数据工作者每个月都会因等待工程资源来清理和准备数据而受到影响²。

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

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

在过去 20 年里，大数据为企业创造了惊人的机遇。然而，组织很难向业务用户提供相关、实用且及时的数据。研究表明，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 提供了一种功能，可让 Dataflow 和 Managed Service for Apache Spark 等其他系统像使用 Cloud Storage 一样使用 BigQuery Storage。这打破了数据仓库存储壁垒，让您能够在 BigQuery 上运行高性能数据帧。换句话说，BigQuery Storage API 可让您的 BigQuery 数据仓库像数据湖一样运作。那么，它有哪些实际用途呢？首先，我们构建了一系列连接器（例如 MapReduce、Hive、Spark），以便您可以直接对 BigQuery 中的数据运行 Hadoop 和 Spark 工作负载。除了数据仓库之外，您也不再需要数据湖！Dataflow 在批处理和流处理方面功能非常强大。现在，您可以根据 BigQuery 数据运行 Dataflow 作业，并使用来自 Pub/Sub、Spanner 或任何其他数据源的数据来丰富 BigQuery 数据。

BigQuery 可以独立扩缩存储和计算资源，并且每项资源都是无服务器的，因此可以无限扩缩，以满足不同团队、工具和访问模式的需求。上述所有应用都可以运行，而不会影响同时访问 BigQuery 的任何其他作业的性能。此外，BigQuery Storage API 还提供 PB 级网络，可在节点之间移动数据以有效处理查询请求，从而实现与内存中操作类似的性能。它还允许直接与 Parquet 和 ORC 等热门 Hadoop 数据格式以及 NoSQL 和 OLTP 数据库联合。您还可以利用嵌入在 BigQuery 中的 Dataflow SQL 提供的功能，进一步提升数据处理能力。这样，您就可以将数据流与 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 提供 Managed Service for Apache Spark

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

基于将数据湖和数据仓库融合到统一的分析数据平台的理念，还有一些其他数据解决方案也备受关注。我们看到，围绕湖仓一体和数据网格等新出现了很多概念。您可能以前听说过其中一些术语。有些并非新鲜事物，多年来一直在以不同的形式出现。不过，它们在 Google Cloud 环境中运行得非常好。我们来详细了解一下数据网格和湖仓一体在 Google Cloud 中的样子，以及它们对组织内数据共享的意义。湖仓一体和数据网格不是互斥的，而是有助于解决组织内部的不同挑战。但一个侧重于启用数据，另一个侧重于启用团队。数据网格使人们能够避免受到一个团队的瓶颈限制，从而支持整个数据栈。它在架构中以联合方式访问数据，将孤岛拆分为较小的组织部门。湖仓一体将数据仓库和数据湖结合在一起，支持不同类型和更多的数据。这实际上生成了读时架构，而不是写时架构，这是数据湖的一个特点，人们认为它能弥合企业数据仓库中的一些性能差距。另一个好处是，这种架构还借鉴了更严格的数据治理，这是数据湖通常所缺乏的。

如上所述，BigQuery 的 Storage API 可让您将数据仓库视为数据湖。在 Managed Service for Apache Spark 或类似 Hadoop 环境中运行的 Spark 作业可以使用存储在 BigQuery 上的数据，而无需通过数据仓库存储单独的存储介质。BigQuery 中与存储分离的强大计算能力支持基于 SQL 的转换，并利用这些转换不同层中的视图。这会带来 ELT 类型的方法，并实现更灵活的数据处理平台。BigQuery 采用 ELT 而非 ETL，支持将基于 SQL 的转换存储为逻辑视图。虽然将所有原始数据转储到数据仓库存储中可能会产生高昂的传统数据仓库费用，但 BigQuery 存储没有附加费用。其成本与 Google Cloud Storage 中的 Blob 存储相当。

执行 ETL 时，转换是在 BigQuery 外部进行的，可能是在一个扩缩能力不佳的工具中进行的。它最终可能会逐行转换数据，而不是并行处理查询。在某些情况下，Spark 或其他 ETL 流程可能已经过编纂，为了采用新技术而更改这些流程可能没有意义。但是，如果存在可以用 SQL 编写的转换，BigQuery 可能是执行这些转换的绝佳平台。

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

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

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

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

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

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

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

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

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

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

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

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

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

有何好处？

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

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