科技公司和初创公司意识到，要取得成功，必须具备以下条件：
- 在整个公司内，甚至在供应商和合作伙伴间，数据都必须保持统一。这涉及发掘非结构化数据的价值以及打破组织和技术孤岛。
- 他们的技术栈必须足够灵活，能够支持离线数据分析、实时机器学习等各种应用场景。
- 无论用户身处何地，都能访问他们的技术栈。技术栈必须支持不同的平台、编程语言、工具和开放标准。
每个人都知道数据很重要，但很少有公司能够从他们的数据中提取出创新的业务和客户洞见。 充分利用数据意味着什么？ 为什么说这是一项挑战？
充分利用数据意味着您可以根据数据制定产品和运营方面的决策。 您不妨问自己几个问题： 您是否了解客户的期望在发生哪些变化？ 您是否已在利用数据改善客户体验？ 就这项挑战而言，您不妨问问自己：您的数据工程师和科学家目前把时间花在了哪里？
在帮助寻找产品创新方向、改善用户体验及制定各种市场决策方面，数据发挥着至关重要的作用。 充分发挥数据的价值可以带来显著的竞争优势。 正因如此，大多数科技公司和初创公司都承受着巨大的压力，不得不做更多的事情，包括：以越来越大的规模进行现代化改造和运营，证明当前和未来的数据费用的合理性，以及提升组织成熟度和决策能力。
然而，由于访问、存储、合规性和安全性方面的难题，以及工具的不一致，公司难以深入开展工作并让数据发挥真正的价值。
也许您沿用了旧系统，并且在尝试将其与新系统结合使用。 那么，所有数据都应存储在一个云中吗？ 还是应分布在多个云中？如何对过去垂直集成的分析栈进行现代化改造，以便与可横向扩容的平台配合使用？
或者，您目前对数据采用的可能是批处理或微批处理方式，而不是进行实时处理。 由此产生的编排系统和调度增加了架构的复杂性，并且需要围绕争用和弹性进行维护。 管理和维护批处理架构会导致高昂的运维开销，而且您仍然要在数据延迟时间上做出妥协。
如果无法轻松访问您的所有数据，并且无法在数据传入时处理和分析数据，那么您将会处于不利的境地。 现代技术栈必须是一个流式堆栈，能够跟上您的数据规模，使用最新的可用数据，并能整合和理解非结构化数据。 先进的分析团队使用 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 小时内）从查询中获得结果，那么您可能会在决策中更多地使用数据。
您的数据科学家需要多长时间来进行实验？ 他们很可能需要先停止开发并将模型付诸使用，通过真实用户的反馈来评估其实验。 他们使用历史数据开发和迭代模型，然后将模型交给工程师，工程师通常会彻底重写模型以将其纳入生产系统中，并执行 A/B 测试。 然后，他们需要等待、迭代模型并再次投入生产。 这个过程涉及大量的时停时续和代码重写，并且团队之间的所有必要协作都可能引入错误。 数据科学家无法尽可能多地进行实验，因为这种实验方式需要很长时间。 这使您很难预测一个项目需要多长时间以及项目是否会成功，更不用说预测投入日常使用需要多长时间。 为了摆脱这个窘境，您需要为数据科学家提供功能强大而又熟悉的工具。 借助 Vertex AI Workbench，数据科学家可以在 Jupyter 笔记本中高效工作，同时加快训练、实验和部署速度。
如果您希望利用数据脱颖而出，则需要从所收集的数据中挖掘最大价值。 为此，您需要让数据科学团队尽可能高效地工作，不错过构建模型的机会，因为即使是简单的事务也可能会耗费太长时间或者太难执行。
预构建模型和低代码模型的质量至关重要。 Vertex AI 上的 AutoML 可在无代码环境中提供一流的 AI 模型，从而实现快速的基准化分析和优先级排序。使用您自己的数据预先构建模型（例如实体提取或 Vertex AI Matching Engine）可显著加快利用数据创造价值的速度；您也不再局限于分类或回归。
保持数据敏捷性的关键是及早且频繁地进行端到端实验。 Vertex AI Pipelines 提供实验的历史记录，以便您回顾、根据基准和端点进行比较，以及使用影子模型进行 A/B 测试。由于代码已容器化，开发系统和生产系统可使用相同的代码。 数据科学家使用 Python 工作，生产工程师则使用完全封装的容器。 两个团队都可以使用 Vertex AI Prediction 运行模型以实现标准化，从而加快实验速度。
领域专家通常可以利用 BigQuery ML 来测试某项创意的可行性，他们只需使用 SQL 训练自定义模型即可，无需额外具备传统数据科学工具的使用经验。这意味着您可以在类生产系统中进行实验，并在几天（而非几个月）内开展可行性研究。 您可以将 BigQuery ML 模型部署到 Vertex AI 中，以实现我们前面讨论的所有优势。 您可以使用 Looker 基于所有数据创建一致的数据模型，并使用 LookML 查询数据，这意味着组织中的每个人都可以创建易于阅读的报告和信息中心来探索数据模式。
为了在生产环境中实现真正的价值，系统必须能够注入、处理和传送数据，并且机器学习技术必须根据客户的具体情境实时驱动个性化服务。 但是，持续运行的生产应用需要不断地重新训练、部署模型并检查其安全性。 传入的数据需要进行预处理和验证以确保没有质量问题，然后通过超参数调节功能进行特征工程处理和模型训练。
如果想轻松编排和管理这些多阶段机器学习工作流，并以可靠的方式重复运行这些工作流，则有必要将数据科学和机器学习技术进行集成。 MLOps 工具和自动化工作流可实现快速持续交付，并可简化将模型投入生产的管理工作。我们的所有 AI 产品都有统一的工作流和词汇表，与抽象层无关。您可以轻松切换自定义模型和 AutoML 模型，因为它们采用相同的格式和技术基础。
例如，如果您要对实时无界限数据流应用异常值检测，以便打击欺诈行为，应该怎么做？ 通过使用正确的方法，您可以生成示例数据流来模拟常见的网络流量，并将其注入到 Pub/Sub 中，然后在通过DLP功能遮盖个人身份信息 (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% 是否值得迁移？还是应该考虑重写或以不同方式执行这项任务？您应该不想将所有东西按原样迁移到云中，否则您会发现自己在新的云环境中复制了本地的所有技术债务，而不是专注于数据价值。
我们已经讨论了很多关于利用数据的内容以及这样做实际上意味着什么，另外还指出了在迁移到云端数据仓库时可能需要考虑的一些因素。
如需详细了解 Google Cloud 如何帮助您利用数据分析获得显著优势、帮助您的公司降低成本，以及通过优化数据和 AI 的使用来提高工作效率，请与我们联系。
其他资源
请填写表单，我们会与您联系。 查看表单
