数据的未来发展趋势是统一、灵活、易于访问

科技公司和初创公司意识到，要想成功，必须注意以下几点：

- 数据必须在整个公司内统一，甚至跨供应商和合作伙伴统一。这涉及解锁非结构化数据并打破组织和技术孤岛。

- 他们的技术栈必须足够灵活，以支持从离线数据分析到实时机器学习的用例。

- 技术栈还必须可以从任何地方访问。它必须支持不同的平台、编程语言、工具和开放标准。

为什么充分利用数据可能是一项竞争优势

每个人都知道数据很重要，但很少有公司能够从数据中提取创新的业务和客户洞见。充分利用数据意味着什么？为什么这是一个挑战？

充分利用数据意味着您可以使用数据进行产品和运营决策。所以，您不妨问自己几个问题。您是否了解客户期望的变化情况？您是否在利用数据改善客户体验？就挑战而言，不妨问问自己您的数据工程师和科学家目前把时间花在了哪里？

数据对于推动创新产品方向和用户体验以及广泛的上市决策至关重要。成功利用数据可以带来显著的竞争优势。正因如此，大多数科技公司和初创公司都面临着开展更多工作的巨大压力：大规模地进行现代化改造和运营，证明当前和未来数据费用的合理性，以及提升组织成熟度和决策能力。

但是，访问、存储、不一致的工具、合规性和安全性方面存在挑战，这使得公司难以深入开展工作以及从数据中挖掘真正的价值。

也许您继承了旧系统，并尝试与新系统结合。所有数据都应存储在一个云中吗？还是应分布在多个云中？如何对过去垂直集成的分析栈进行现代化改造，以便与可横向扩容的平台配合使用？

或者，您目前可能是对数据进行批处理或微批处理，而不是实时处理。由此产生的编排系统和调度增加了架构的复杂性，并且需要围绕争用和弹性进行维护。管理和维护批处理架构的操作开销非常昂贵，而且您仍然要在数据延迟时间上做出妥协。

如果您无法轻松访问您的所有数据，并且无法在数据到达时处理和分析数据，则会处于不利地位。现代技术栈必须是一个流式堆栈，能够跟上您的数据规模，使用最新的可用数据，并整合和理解非结构化数据。先进的分析团队通过使用 AI/机器学习来试验和操作流程，将他们的重点从运营转移到行动。

如何让数据为您服务，让您可以专注于创新

让数据为您服务意味着什么？它意味着改善客户体验、吸引新客户以及增加您的收入。从根本上说，它意味着创新能力。我们建议您根据两个原则来选择可帮助您获得这些结果的数据平台。

原则 1：简洁性和可伸缩性

目前，您可能有大量数据需要处理。也许数据正在以指数级速度增长，您希望在保持或增加投资回报率的同时跟上数据量的增长速度。也许您正在预测未来您将拥有多少数据（例如 1 TB）并设计您的系统来处理该数据量，同时知道如果增长超出这些预期，您将考虑进行整体系统迁移。或者，您可能选择了一个可以根据您的预期增长进行扩展的数据仓库，但不断增长的处理需求使其管理变得复杂。

较小的系统通常更简单。但是，您不再需要在易于使用的系统和高度可扩缩的系统之间进行选择。使用无服务器架构消除了对集群管理的需求，并使您能够处理大规模的计算和存储，因此您再也不必担心数据大小超出您的技术容量。

为了确保简单性和可伸缩性，我们建议使用无服务器数据平台。我们建议您舍弃任何需要您安装软件、管理集群或调整查询的选项。

原则 2：提高敏捷性并降低费用

任何结合计算和存储的数据管理系统都会迫使您扩容计算以应对不断增加的数据量，即使您不需要它也是如此。这可能会很昂贵，而且您可能会发现自己做出妥协，例如仅将过去 12 个月的数据存储在您的分析仓库中。您也可能选择不包含数据，因为您没有直接的用例，不过您会发现自己无法测试假设情况，因为数据不存在并且需要新的流水线才能开始。

其他系统仅起到了一半的作用，让您可以独立扩缩并支付计算和存储费用，但仍然需要您手动设置、扩缩和优化集群。要尽可能减少基础架构管理工作，请考虑使用具有增强可靠性、性能和内置数据保护的无服务器多云数据仓库（例如 BigQuery）。

除了费用和管理，您还需要考虑敏捷性。数据发生变化时，您需要多长时间才能注意到并做出反应？当您使用的软件或工具有新版本时，您需要多长时间才能掌握它的新功能？实现更高敏捷性的途径是选择需要较少培训或指导并且适用于各种工作负载的灵活工具。

您必须优化对 Redshift 等系统的查询以提高效率。这限制了您可以进行的实验量，因此您只能在怀疑可能存在问题时提取和拉取数据。由于缺乏计算/存储分离以及优化数据仓库的需要，您做出的妥协会让您处于不利地位。

使用 BigQuery 等产品时，您无需提前规划查询，也不需要将数据集编入索引。分离的存储和计算让您可以安心存放数据，而不必担心它会增加您的查询成本，并且您的数据科学家可以进行实验，而不必担心集群或调整数据仓库的大小来通过临时查询尝试新的想法。

您已了解简单、可伸缩、灵活、经济实惠的平台如何让您处于创新的有利位置。现在，我们将探讨数据如何帮助您实现这一目标。

实时制定数据驱动的决策

企业的运营速度不断加快。客户的期望也发生了变化。过去您可以在三天内核对交易或批准退货，现在则必须立即提供回复。更快、更及时的决策导致对流式传输的需求增加。

您需要能够实时捕获数据，并使这些数据可供业务团队进行低延迟查询。此外，您还需要确保流式传输流水线具有可扩缩性、弹性和较低的管理开销。这是您的团队能够实时应对业务变化的唯一途径。BigQuery 原生支持注入流式数据，并且使数据可立即使用 SQL 进行分析。除了 BigQuery 简单易用的 Streaming API 之外，Dataflow 使您可以管理季节性和高峰工作负载，避免超支。

打破数据孤岛

许多组织最终创建了孤岛，因为它们在部门和业务单位之间单独存储数据，每个团队都拥有自己的数据。这意味着无论何时您想要进行跨部门的分析，您都必须弄清楚如何打破这些孤岛，可能通过运行提取 (ETL) 流水线来获取数据并将其放入您的数据仓库。但是拥有数据的部门通常没有动力维护流水线；随着时间的推移，这些数据会过时，存储的数据会变得更加过时、更没用。

除了组织孤岛之外，目前的许多公司都采用了基于部门偏好、能力调整和监管压力的多云战略。这些公司还经常处理存在于本地的旧数据湖和数据仓库投资。当今的多云、混合云环境要求在管理和访问孤立数据方面更加复杂。

迁移到具有通用控制结构（有时称为数据结构脉络或数据网格）的分布式仓库可提高您跨部门、云和本地系统访问高质量数据的能力。这可以解决产品性能或客户行为等业务问题，并使您能够即时查询数据。

BigQuery 提供了这种数据网格的技术基础 - 整个组织的用户都可以管理、保护、访问和共享数据资产和数据分析，无论组织中的谁拥有数据。例如，您可以将所有数据存放到 BigQuery 中，并提供可重用的函数、具体化视图，甚至可以在不移动任何数据的情况下训练机器学习模型。这意味着即使是非技术领域专家（以及有权限的合作伙伴和供应商）也可以使用电子表格和信息中心等熟悉的工具轻松访问和使用 SQL 来查询数据。

在这里，“中心辐射”是一个恰当的类比。BigQuery 是包含数据的中心。辐条包括报告工具、信息中心、机器学习模型、Web 应用、推荐系统等，它们可从 BigQuery 实时读取数据，而无需复制数据。例如，Looker 可帮助您直观呈现数据并将其集成到用户的日常工作流中。这种方法可以同时提高数据的可用性、安全性和质量。

简化对您的所有数据的访问

从历史上看，非结构化和半结构化数据适合数据湖，而结构化数据适合数据仓库。这种分离造成了技术孤岛，使得跨越格式鸿沟变得困难；您会将所有数据存储在数据湖中，因为它更便宜且更易于管理，然后将数据移动到仓库，以便您可以使用分析工具来提取数据分析。

日益流行的“湖仓一体”将这两种结构合并为一个存储所有类型数据的统一环境；您可以将 BigQuery 同时用作数据仓库和数据湖。通过 BigQuery 的 Storage API，您可以直接访问存储以支持通常与数据湖关联的工作负载。由于数据可以存储在 BigQuery 中作为唯一可靠来源，因此需要创建和维护的副本变少。您可以通过存储在逻辑视图中的 SQL 转换来执行下游处理，而无需移动数据。

易用性很重要 - 如果您可以在 30 秒内而不是 30 分钟或 3 小时内从查询中获得结果，那么您可能会在决策中更多地使用数据。

使用 AI/机器学习更快地进行实验，并让工作负载运行起来

您的数据科学家需要多长时间来进行实验？最可能的情况是，他们需要停止开发并将模型付诸使用，以通过真实用户来评估实验。他们使用历史数据开发和迭代模型，然后将模型交给工程师，工程师通常会完全重写模型以将其纳入生产系统中，并执行 A/B 测试。然后，他们需要等待、迭代模型并再次投入生产。这个过程涉及大量的时停时续和代码重写，并且团队之间的所有必要协作都可能引入错误。数据科学家无法尽可能多地进行实验，因为这种实验方式需要很长时间。这使您很难预测一个项目需要多长时间以及项目是否会成功，更不用说预测投入日常使用需要多长时间。要改善此状况，您需要为数据科学家提供功能强大而又熟悉的工具。借助 Vertex AI Workbench，数据科学家可以在 Jupyter 笔记本中高效工作，同时加快训练、实验和部署速度。

如果您真的有必要根据数据进行区分，则需要从所收集的数据中挖掘最大价值。为此，您需要让数据科学团队尽可能高效地工作，不错过构建模型的机会，因为即使是简单的事务也会耗费很长时间或者太难。

预构建模型和短代码模型的质量至关重要。Vertex AI 上的 AutoML 可在无需代码的环境中提供一流的 AI 模型，从而实现快速的基准化分析和优先级排序。在您自己的数据上预先构建模型（例如实体提取或 Vertex AI 匹配引擎）可显著加快数据创造价值的速度；您不再局限于分类或回归。

保持数据敏捷性的关键是及早且频繁地进行端到端实验。Vertex AI Pipelines 提供实验的历史记录，可让您回顾、与基准和端点进行对比并使用影子模型进行 A/B 测试。由于代码是容器化的，因此可以在开发系统和生产系统之间使用相同的代码。数据科学家使用 Python 工作，生产工程师获得完全封装的容器。两个团队都可以使用 Vertex AI Prediction 运行模型以实现标准化，从而加快实验速度。

领域专家通常可以利用 BigQuery ML，通过仅使用 SQL 训练自定义模型来测试想法的可行性，而无需额外的传统数据科学工具使用经验。这意味着，您可以在类似于生产的系统中进行实验，并在几天（而非几个月）内开展可行性研究。BigQuery ML 模型可以部署到 Vertex AI 中，实现我们前面讨论的所有优势。您可以使用 Looker 在所有数据的基础上创建一致的数据模型，并使用 LookML 查询数据，这意味着组织中的每个人都可以创建易于阅读的报告和信息中心来探索数据模式。

为了在生产环境中实现真正的价值，系统必须能够注入、处理和传送数据，并且机器学习必须根据客户的环境实时驱动个性化服务。但是，持续运行的生产应用需要不断地重新训练、部署和检查模型以确保安全性。传入的数据需要进行预处理和验证以确保没有质量问题，然后进行特征工程和使用超参数调节的模型训练。

集成的数据科学和机器学习对于轻松编排和管理这些多阶段机器学习工作流以及重复可靠地运行工作流至关重要。MLOps 工具和自动化工作流可实现快速持续交付和简化生产模型的管理。我们的所有 AI 产品都有统一的工作流和词汇表，与抽象层无关。您可以轻松切换自定义模型和 AutoML 模型，因为它们采用相同的格式和技术基础。

例如，如果您要对实时无界限数据流应用异常值检测，以便打击欺诈行为，该怎么办？使用正确的方法，您将生成示例数据流来模拟常见的网络流量，并将其注入到 Pub/Sub 中，然后在通过数据泄露防护功能遮盖个人身份信息 (PII) 后使用 BigQuery ML K-means 聚类在 BigQuery 中创建并训练异常值检测模型。接下来，您将使用 Dataflow 将模型应用于实时数据以进行实时检测，并使用 Looker 创建信息中心、提醒和操作来处理已识别的事件。

为什么选择功能全面的数据仓库方案至关重要

我们已经讨论了 BigQuery 和 Redshift，但这些不是唯一的数据仓库选项。另外，还有其他数据分析产品（例如 Snowflake 和 Databricks）可在所有三大云平台上运行。那么，如果您选择 BigQuery，是否会有云锁定问题？

首先要注意的是，使用 BigQuery，您不会局限于仅分析存储在 Google Cloud 中的数据。借助 BigQuery Omni，您可以从 Google Cloud 控制台无缝查询 Amazon S3 和 Azure Blob Storage 中的数据。

但现实情况是，如果您使用 Snowflake 或 Databricks，那么从 AWS 迁移到 Google Cloud 或从 Google Cloud 迁移到 AWS 的费用较低。不过，迁移到其他数据仓库的费用如何呢？如果您想从 Snowflake 迁移到 BigQuery，或者从 Databricks 迁移到 EMR，费用如何？您仍然需要支付切换费用；这只是另一种场景而已。

因为在任何情况下都会产生切换费用，所以您最终希望选择能够长期为您工作的工具或平台。您需要根据指定平台的特征、目前的费用以及未来增加创新功能的速率做出选择。当您选择 Snowflake 时，您就是在打赌一家专注于数据仓库的公司将在该领域为您提供更快的创新速度。当您选择 BigQuery 时，您将依靠一家以发明许多数据和 AI 技术而闻名的公司继续在整个平台上进行创新。

我们相信，一个已完全集成的创新平台可以更好地推动创新。当 Google Kubernetes Engine (GKE) 等代管式服务产品使容器映像加载速度变得更快时，这有助于无服务器 Spark 更好地工作，并且由于无服务器 Spark 可以对 BigQuery 中的数据进行操作，因此它使得 BigQuery 对您更有价值。当您使用平台（而不是个别产品）时，创新的速度会更快。

如何充满信心地迁移数据

迁移数据需要多长时间？六个月？两年？工作量有多大？是否值得？

如果您从一个云迁移到另一个云，这可能比从本地迁移到云更容易，因为无论如何您通常都会在本地拥有更多的技术深度，专注于您的目标，这通常类似于“我的创新速度如何？”这样的问题。

思考您想做但目前没有做的所有创新工作，然后设置新项目并转移进行这些创新需要的数据。我们可以帮助您构建这些新用例，并镜像您需要的数据源。在一段时间内，您将处于混合环境中，许多用例在本地运行，但由从本地环境或其他云提供商实时或批量镜像的数据驱动。

第二个考虑因素是费用。您正在运行的 Teradata 实例成本很高。我们看到客户通过改用 BigQuery 将费用降低了一半，而且这些迁移比过去容易得多，因为自动化评估工具和自动化 SQL 转译器可以转换您的绝大多数脚本。我们提供虚拟化方式，让您的客户端能够在实际与 BigQuery 通信时认为是在与 Teradata 通信。我们可以通过多种方法帮助您进行迁移，而无需关闭所有服务；您可以使用这些迁移工具迁移费用高昂的 Teradata 和 Hadoop 工作负载。

第三个考虑因素是 ERP 系统，例如 SAP、Salesforce 系统和 Oracle。如果您希望优化供应链、对潜在客户评分或检测欺诈行为，则能够将分析工作负载连接到 ERP 系统非常重要。我们可以使用第三方连接器从这些系统获取数据，然后利用连接器在云端基于这些数据构建 AI 驱动的现代用例。

执行这些任务的顺序取决于您的具体情况。如果您是一家初创公司，则可以从创新入手，然后进行费用优化，最后充分利用现有的流水线和连接器。如果您的企业主要依赖于供应链，您可以从 ERP 连接器开始。无论以什么顺序执行这三个任务，您都会发现您已将大量宝贵的数据资产迁移到了云中。现在看看剩余的资产，并考虑是否值得迁移。我们通常发现答案是否定的，在迁移真正必要的 70%-80% 的工作负载后，您需要开始进行艰难的决策。剩下的 20%–30% 是否值得迁移，还是应该考虑重写或以不同方式迁移？您肯定不希望将所有东西按原样迁移到云中，否则您会发现自己在新的云环境中复制了本地的所有技术债务，而不是专注于数据价值。