Google下一代存储：为未来设计存储解决方案
大家或许已经对GFS或Colossus有所耳闻，它们都是大规模分布式文件系统，是Google存储的基石。从Spanner、Bigtable、BigQuery，到Google搜索、广告、YouTube、照片、云等一系列产品，甚至是新兴的Gemini、训练和服务等应用，都在Colossus上稳定运行。值得一提的是，Colossus不仅能在硬盘上运行，还能支持SSD，轻松扩展到EB级存储和多Tb/s带宽。
在多年构建和运行大规模存储系统的过程中，我们认识到，现代存储系统的成功离不开几个至关重要的“超能力”。
首先，存储系统在基础层面必须具备高度的可靠性和安全性。Google作为最早提出数据中心规模计算（Datacenter as a Computer）概念的公司之一，深知如何高效利用数据中心的所有计算资源。然而，随着时间的推移，我们意识到单一数据中心已无法满足需求。我们需要从全局视角出发，将视角从单一数据中心扩展到整个区域，甚至是整个大陆。并且，能够在不同的数据中心间灵活地迁移工作负载和存储，无论是出于负载均衡还是容错考虑，这对于提升效率和管理便捷性至关重要。
其次，分离是另一个“超能力”。大家可能都了解存储与计算的分离，即在不改变存储的情况下，能够灵活地扩展计算能力。但同样重要的是性能与存储的分离，即在保持存储不变的情况下，增加计算和IO工作负载的处理能力。这样，我们就能在同一存储系统中混合使用各种工作负载，无论是高负载、中负载还是低负载，从而最大化系统的容量和性能。同时，我们还能为特定工作负载大幅增加IO量，而无需为系统上所有工作负载的峰值进行预配置。
此外，我们还强调一个单一、简洁的编程模型的重要性。这个模型应该为所有应用程序提供一个统一、强一致性的堆栈，让它们无需担心最终一致性或异步行为，无论系统性能如何。
最后，将所有存储整合为单个集群，并进行集中管理，是降低存储管理成本的关键。如果管理团队的规模必须与存储量成正比，那么管理庞大的存储量将变得不可能。
我们期望有一种方式，能让这些特性惠及所有云客户。然而，将这些功能引入云端也面临着诸多挑战。
首先，兼容性是至关重要的一环。大多数迁移到云端的应用程序无法完全重写，它们希望在迁移过程中能够继续使用熟悉的块、文件或对象API。因此，Cloud Storage系统必须灵活调整，以满足这些兼容性需求。 此外，性能也是我们关注的焦点。当云工作负载迁移时，我们必须确保提供与原生环境相匹敌的性能，无论是延迟还是吞吐量，而无需客户对应用程序进行大规模重构。 同时，我们还需要将存储管理（包括安全性和合规性）无缝地融入客户的现有工作流程中。
关于我们在存储方面的指导原则，就是要确保我们不断调整存储系统，并对在云中运行的工作负载进行优化。这其中，我们可以将工作负载分为几类来探讨：
存档存储、冷存储和备份。这些很可能是首批迁移到云端的工作负载，因为云端已经为它们提供了出色的支持。 内容存储与分发工作负载。例如静态网站托管、照片和图片存储，或是实时流视频，这些都需要在云中存储数据，并高效地将其流式传输到互联网。 数据密集型工作负载。包括分析、高性能计算，以及越来越多的人工智能训练和服务工作负载。在云端，这些工作负载可以利用大量存储和并行计算的强大能力，通过众多计算机协同处理数据。 传统企业级工作负载。例如VDI、Windows、数据库、SAP、GKE应用程序等。
在这次讨论中，我们将重点关注最后两个类别。特别是数据密集型应用程序，我们如何为其优化存储，这是我们要深入探讨的话题。
如今，拥有单一的Data Lake、Data Warehouse或Data Lakehouse概念已成为所有分析应用场景的标准做法。而Cloud Storage，特别是Google的Cloud Storage（也被称为GCS），无疑是构建Data Lakehouse的最佳存储系统。
首先，我们希望能够在一个单一的数据存储库中存放所有数据，使其成为所有数据的“唯一真实”来源。GCS能够存储这些数据，并提供强大的容错性、数据保护和可靠性，确保我们收集的数据不会丢失。
从性价比和可扩展性的角度来看，GCS展现了几乎无限的潜力。它可以轻松扩展到EB级存储和数十Tb的带宽，为分析应用程序提供了无限的可能性。同时，性价比也是关键，GCS确保我们可以根据数据的热度或冷度来存储，并有效地管理存储成本。
GCS还融入了一个丰富的API和框架生态系统，像开源框架Hadoop、Spark、Kafka都得到了良好的支持。此外，我们还与众多第三方ISV和合作伙伴，如Snowflake、Databricks、Confluent等紧密合作，同时也支持我们自家的一流产品，如BigQuery、Dataflow和Dataproc。
GCS提供了一个简单且强一致性的API，无论存储的数据层级或位置如何，用户都可以轻松使用。对于用户的数据，我们提供了全面的访问控制工具，以实现精细化的访问控制，并确保数据的谱系和治理。
然而，随着人工智能的蓬勃发展，Data Lakehouse正逐渐演变为AI Lakehouse，需要支持这些新兴的AI应用程序。这不仅仅是存储结构化和半结构化数据的问题，现在还需要存储Lakehouse中的所有非结构化数据。从性能角度来看，我们对Data Lakehouse的所有要求依然适用，但还需要实现极低的延迟，并应对大量的元数据操作。AI应用程序通常伴随着大量的框架和API，如JAX、PyTorch和TensorFlow，我们必须支持这些。数据治理依然至关重要，但同时我们还需要关注保护那些可能花费了数天、数周或数月来训练的模型。
我们的愿景是将Cloud Storage进化为Cloud AI Storage，简单来说，就是只需存储一次数据，就可以在任何地方以任何性能访问它，同时支持这个类别中的任何框架和API，并实现无限的扩展性。
让我们深入了解一下Cloud AI Storage的架构。在这个架构中，最底层是Cloud Storage，它提供了一个无限扩展的数据存储库，用于存储所有数据。更关键的是，它充当了“唯一真相”来源和统一的管理控制点，让我们能够对这个数据副本进行所有必要的管理操作。在Cloud Storage之上，我们设置了一系列缓存机制。这些缓存至关重要，因为它们不仅提升了性能，还带来了位置灵活性。同时，它们也集成了各种API，满足了分析和应用程序的需求。再往上，我们有一系列为分析优化的连接器，无论是Hadoop、Spark，还是用于AI的PyTorch、JAX和TensorFlow，都能与之无缝对接。Cloud AI Storage建立在数据处理系统和AI系统之上，无论是开源的、第三方的，还是我们的BigQuery、Vertex AI等第一方产品，都能与之兼容。
接下来，我们详细探讨一下Cloud AI Storage的工作原理，特别是其位置灵活性。在将数据存储在Cloud AI Storage时，首先要做的选择就是确定数据的存储位置。我们提供了三种位置选择。首先是区域位置，这对大多数人来说可能最为熟悉。如果你不需要从多个区域访问数据，也没有灾难恢复的需求，那么选择区域位置将是最经济、最便捷的方式。在单个区域内，你可以无限量地访问存储的数据，而且成本最低。
然而，许多客户可能面临灾难恢复的监管要求，或者担心在区域故障时数据丢失，或者需要极高的可用性。在这种情况下，我们提供了双区域存储桶选项。在双区域存储桶中，你只需要存储一次数据，我们就会将数据透明地复制到两个区域，整个过程在15分钟内完成。如果你使用的是增强型复制功能，可以保证数据的RPO不超过15分钟。值得一提的是，Google Cloud Storage是唯一提供双活灾难恢复系统的云解决方案。这意味着，一旦数据存储在一个区域中，你就可以同时从两个区域访问这些数据，并且保证数据的一致性，即使数据尚未完成复制。这样，你就可以无忧无虑地访问数据，无需担心传统的灾难恢复解决方案中的回退和故障切换系统。
此外，我们还为数据密集型应用程序提供了一个更加灵活的存储选项——带有Anywhere Cache的多区域存储桶。这个选项的工作原理是，将数据存储在两个区域中，以提供灾难恢复保护，然后可以从同一大陆的任何其他区域访问这些数据。这意味着，可以在保持数据存储位置不变的情况下，灵活地从任何区域访问数据。
那么，这是如何实现的呢？当使用Cloud多区域加Anywhere Cache时，其核心是一个GCS多区域存储桶。这是GCS的一个独特功能，它可以将数据存储在大陆内的任意两个区域中。这样，我们就能够确保一个低成本、双活的灾难恢复系统，即使一个区域出现故障，也不会导致数据丢失。同时，这些数据可以从同一大陆内的所有区域进行访问。然而，对于需要读取大量数据的数据密集型应用程序来说，成本和性能都是需要考虑的因素。这时，Anywhere Cache就派上了用场。Anywhere Cache是一个基于SSD的缓存机制，可以在所有需要访问数据的区域中配置它。缓存会自动缓存最常用的数据，这样，当虚拟机需要访问数据时，它会直接从缓存中读取，而不是从多区域存储桶中读取。这意味着访问这些数据不会产生额外的出口成本，同时还能获得更好的性能。
通过将计算和存储部署在同一区域，我们可以解锁大量的读取带宽，使得大量数据的读取成为可能，这在直接从基础存储桶中读取数据时是无法实现的。多区域加Anywhere Cache的配置为数据分析和AI应用场景解锁了一些独特的应用场景。
有些客户对于VM的规格或GPU、TPU等硬件有着独特的需求，而这些需求可能仅在大陆内的某些特定区域才能得到满足。此外，许多客户在成本控制上也十分关注，他们更倾向于使用按需付费的点实例VM，但这类VM的可用性会因区域而异。还有些客户因业务需求独特，需要将计算与其他应用程序合并，并在不同区域运行，以优化延迟。因此，他们希望计算位置能更加灵活。
无论出于何种原因，通过使用多区域加Anywhere Cache的组合，我们可以将计算资源部署在大陆内的任何位置，同时无需担心数据的复制、同步或一致性问题。更值得一提的是，这种方式还为我们提供了内置的灾难恢复保护，确保数据的安全可靠。
Christopher Ang
Software engineer
首先，给大家简要介绍一下Snap Inc.以及它的明星产品——Snapchat应用程序。
Snap Inc.作为一家技术公司，始终走在科技前沿；而Snapchat则是一款深受用户喜爱的应用，它让人们能够即时分享生活点滴，实时了解世界动态，并与朋友们尽情玩乐。到2023年底，Snapchat的全球日活跃用户数量已高达约4.14亿。Snapchat坚信，人工智能和机器学习将为我们持续创造更多价值，不仅惠及用户，也助力业务合作伙伴取得更大成功。
在Snap，我们非常重视工程团队的自主权，鼓励他们构建高效的工作流程，收集所需的日志和元数据，以支撑AI和ML工作负载。此外，我们还基于Google Dataproc和Google Cloud Dataflow构建了工具，旨在加快开发人员将管道投入生产的步伐。
现在，请看我屏幕上的内容。从左到右，这展示了一个泛化的流水线，反映了Snapchat团队正在构建的内容，以及他们如何与Google Cloud Storage紧密合作。从左侧开始，我们收集来自客户端应用（包括iOS、Android和Web版Snapchat）以及服务器端的日志和元数据，并将所有数据发送至Google Cloud Storage。接着，我们利用在Spark上运行的Dataproc作业，连接客户端与服务端的数据，形成完整的会话。随后，这些数据再次存储回GCS，并经过一个预处理流程，将其转化为机器学习模型易于处理的格式，最终用于训练模型。
在整个过程中，我们对GCS的依赖程度极高，无论是读取还是写入数据，这有时会导致时间上的瓶颈。
接下来，分享一下Snapchat在未来两到三年的发展规划。我们坚信，使用更大的数据集进行训练将提升模型性能，进而为我们的用户和广告客户或业务合作伙伴创造更多价值。为实现这一目标，我们需要以经济高效的方式进行。其中，探索不同类型的存储桶（如区域性和多区域性）以及优化管道端到端延迟，以提高模型新鲜度，都是我们努力的方向。模型新鲜度至关重要，它不仅能为用户提供更丰富的内容，还能为Snapchat的广告客户提供更深入的见解。
请看这张图，它展示了我们在2023年的现状（蓝色），以及我们希望在2024年和2025年达到的目标（红色和绿色）。左侧反映了我们在未来两年内期望实现的相对存储容量增长，从2024年开始，预计2025年将达到2023年的6.7倍。右侧则展示了我们预计的读取吞吐量和出口量增长情况，同样以2023年为基准。我们期望到2024年达到1.5倍的峰值出口吞吐量，到2025年可能达到2.3倍。
然而，在出口方面，我们面临的一个挑战是带宽资源的有限性。这意味着GCP需要时间来配置和部署硬件以满足我们的需求。同时，Snap也必须提前预测并规划我们的需求，以确保GCP能够满足我们的要求。在选择多区域和区域存储桶时，我们权衡了各自的利弊。
从多区域的角度来看，它的优势在于数据可以跨越我们所需的计算资源所在地，如GPU、TPU和裸CPU资源。但缺点也很明显，其峰值出口能力通常低于区域存储桶。而区域存储桶虽然所有数据都集中在一个区域，但一旦发生中断，将严重影响我们的管道执行能力。因此，在选择时，我们需要综合考虑这些因素。
类似地，从单一区域的角度来看，该区域基本上只有有限的计算资源。这意味着，如果我们想要将数据部署到与可用计算资源（不论是GPU还是CPU）相近的地方，会面临更大的困难和更高的成本。即便是在多区域和区域环境下，出口限制依然是一个挑战。这意味着，无论我们选择哪种类型的存储桶，一旦出口利用率出现大幅度峰值，都可能引发大量的重试操作，这将严重影响我们管道的成本效益。
针对这个问题，我们认为使用Anywhere Cache是一个不错的解决方案。Anywhere Cache的一个显著优势在于，它能够部署新的存储基础设施，而无需承担使用GCS传统存储选项时可能带来的延迟问题。这让我们能够在以前无法定位数据的区域进行扩展，现在我们可以部署数据，并利用所需的CPU、GPU、TPU来高效运行工作负载。更重要的是，这避免了我们需要手动进行任何迁移的繁琐工作，不论是从多区域迁移到区域，还是相反。
我想强调的是，存储本身并不是问题。能够存储PB或EB级别的数据并不是难题。真正的挑战在于如何快速有效地消耗这些数据，以便高效地完成工作负载。
简要总结一下我们目前的状况以及未来的发展方向。首先，我们将继续提升Snapchat的参与度，并增加业务合作伙伴的回报。为此，我们计划使用更多数据进行训练，以优化ML模型，并希望以经济高效的方式实现这一目标。最后，我们将继续与GCS合作，深入评估使用Anywhere Cache的优势和益处，特别是在受带宽限制的存储桶上。
Nathan Thomas
Senior Director of Product Management
我们正在探索的旅程，正是关于如何设计对特定工作负载尤为高效的存储方案，这也是我们描绘的下一代存储发展蓝图的一部分。刚才，我们讨论了AI/ML管道的运作情况，特别提及了Cloud Storage如何助力Snap加速其数据处理流程。但此刻，我们更想将视线转向企业级应用，共同探讨这一领域的存储需求。
在深入讨论之前，我想先让大家对现有的存储产品有个清晰的认识，毕竟我们拥有的存储产品种类繁多，可能会让大家感到有些迷茫。之前，我们已经听到了一些关于对象存储的信息。对象存储，作为我们的高规模存储解决方案，具有网络可访问性，并为Google Cloud中运行的众多大型工作负载提供了强大支持。除此之外，我们还提供块存储和文件存储服务。当提及块存储时，我们实际上是在说Hyperdisk持久性硬盘和本地SSD，它们与连接到VM的物理存储设备颇为相似。而谈到文件存储，我们则是指的文件存储NetApp和并行存储，这些都是网络附加的文件存储方案，同样与VM紧密相连。当然，对象存储则是指我们之前提到的Cloud Storage组件。
首先让我们聚焦块存储是如何支撑企业级工作负载的。企业级应用，如RDBM、SAP或大型GKE应用，它们的性能需求可谓千差万别。对于用户而言，明确应用程序所需的性能类型，并找到最适合的块存储方案，确实是一个颇具挑战性的任务。我们需要为这些工作负载找到恰到好处的IOPS、吞吐量和延迟特性。同时，确保存储的容量和规模与工作负载需求相匹配也是关键。然而，就像计算机科学领域的许多其他挑战一样，真正的难题在于如何以成本效益的方式实现这些目标。我们能否在满足性能需求的同时，保持符合业务特定要求的价格水平呢？
在解决这一问题的众多技术方案中，块存储无疑是一个常见且有效的选择。它以合理的价格提供了高性能的存储能力。但通过与客户的交流，我们发现他们在选择块存储时往往感到困惑，需要花费大量精力来确定合适的价格点。此外，块存储中容量和性能通常是相互关联的，这意味着即使付出了诸多努力，客户也可能难以获得一个既优化又高效的解决方案。
为了打破这一困境，我们推出了Google Cloud Hyperdisk。通过解耦块存储的容量和性能元素，我们成功解决了这一问题。Hyperdisk被划分为多个不同的服务层级，以满足应用程序对块存储的多样化需求。
Hyperdisk Throughput专为规模化分析和其他吞吐量密集型工作负载设计，它高度注重成本效益，是价格最为亲民的服务层级。 Hyperdisk Balanced则是一种更为通用的卷类型，适用于Google Cloud内部运行的绝大多数应用程序，同时提供出色的性能，最高可达60000 IOPS和2.4GB/s的吞吐量。 Hyperdisk Extreme则是针对高端需求的版本，为SAP HANA、高端SQL Server和Oracle部署提供卓越性能，并附带相应的SLA保证，这对于这类关键应用至关重要。 Hyperdisk ML专为处理海量数据而设计，特别适用于如训练管道等场景，这些场景需要庞大的计算集群，并快速提供所需的训练数据。借助Hyperdisk ML，您可以连接高达2500个节点，并实现1.2 Tb的吞吐量。这意味着可以迅速将这些节点添加到用于运行ML管道的计算集群中，并快速利用GPU进行计算。
对于所有这些SKU，其性能与容量已完全解耦，不再受所选VM的影响。这使得块存储的分配完全灵活，可以按需分配给应用程序。对于客户而言，这无疑是一个巨大的优势。
尽管我们拥有适合各类工作负载的卷类型、容量和性能，但我们也听到客户表达了对需要为工作负载的峰值进行规划的担忧。也就是说，他们必须确保所准备的容量能够应对一天中可能出现的最大负载。然而，实际上，平均利用率往往远低于这个峰值。客户感觉自己在容量和性能上都进行了过度规划，这对单个应用程序的性能可能会产生不良影响。但当我们考虑整个企业的工作负载时，会发现许多工作负载都处于这种配置状态，实际上过度规划的程度远超预期。客户反馈称，有时他们对块存储设备的容量和性能利用率甚至低至20%。
为了解决这一问题，我们推出了存储池（Storage pools）功能。存储池能够在环境中的一系列工作负载中聚合需求，或将容量和性能聚合到一系列即将运行的工作负载中。这可谓一举两得，因为现在我们已经为峰值进行了规划，但同时也能够在多个工作负载之间共享峰值容量，而且无需对工作负载进行任何更改即可实现这些优势。这确实是一种非常有效的成本节省方式。
存储池是基于基础卷构建的。客户可以选择Hyperdisk Extreme或Hyperdisk ML，并决定与该存储池相关联的性能和容量。现在，客户可以选择标准或硬盘的性能和容量选项。在标准情况下，存储池的规划主要是基于将在其中使用的卷的总和。而如果我们选择新的硬盘功能，会发现它更像是一种薄利多销的模式，能够带来额外的成本节省。目前，硬盘容量功能已经正式发布，而硬盘性能功能正处于预览阶段。我们收到了一些客户的反馈，称这种配置在容量方面可以节省高达50%，在性能方面则可以节省高达35%。Hyperdisk提供了合适的卷，而存储池则能够在广泛的资源范围内实际利用这些卷，这在Google Cloud内部的块存储成本方面是一个重要的改变者。
接下来，让我们讨论另一种在Google Cloud内部经历了爆炸性增长的工作负载。无论是在企业内部还是在云优先的环境下，这种工作负载都表现得尤为突出。它们是有状态的多读/写应用程序。例如，一个应用程序可能分布在数千个GKE pod中，每个pod都需要对正在使用的数据进行读写共享访问。在理想情况下，这些应用程序在发生故障转移时不应受到任何影响。如果我们看到从一个pod到另一个pod的故障转移，那么不需要进行任何PD的分离和重新连接，也不会在这方面浪费任何时间。同时，它们还需要在其中具有非中断的升级路径。针对这一问题，我们提供了Filestore for GKE作为解决方案。
虽然Filestore for GKE主要专注于将NFS卷附加到大量节点的高规模情况，但它也旨在支持广泛的企业级应用程序。与Hyperdisk一样，Filestore也提供了一系列选项，以便将性能与特定的业务需求相匹配。从Filestore Basic到Filestore Regional再到Filestore Zonal，客户可以根据需求选择适合的选项，包括从1TB到100TB的存储容量和从100Mb/s到26Gb/s的吞吐量。
尽管Filestore已经满足了众多企业客户的需求，但我们仍然听到客户表示，他们有一些工作负载，更希望看到一个与他们今天在本地环境中所使用的类似的文件方案。这可能是需要SMB共享的Microsoft Windows应用程序，也可能是关键任务的企业NFS应用程序。还可能是正在进行Google Cloud迁移的VMware工作负载。针对这些应用场景，我们最近推出了Google Cloud NetApp Volumes。
Google Cloud NetApp Volumes提供了与在托管的云服务中使用NetApp相同的体验，采用按使用量付费的方式。它拥有所有相同的基本工具和性能特征，并随着云中的增长，能够灵活扩展以匹配应用程序的需求。与之前讨论过的所有其他存储方案一样，这里同样提供了一系列性能和价格方案，以便更好地满足您的具体需求。
截至目前，有Standard、Premium和Extreme三种卷类型。最近，我们宣布了一些功能上的更新，特别对于Extreme类型。我们将吞吐量从4.5Gb/s提升至12Gb/s，增幅超过3倍。同时，我们也将卷大小增加到最大1PB，这确实为一些大型工作负载提供了更多可能性。对于Premium类型，我们将吞吐量提升至6Gb/s。
此外，我们常听到客户表示希望看到更小的卷选项，为此我们推出了Flex。Flex可以将我们的卷大小降低至1GB。很多时候，人们将本地文件迁移到云上时，有许多小卷需要迁移；现在，可以在不必在容量方面过度规划的情况下完成迁移。这些更新将在今年晚些时候推出，并在15个地区提供。
当谈到客户在Filestore中运行这些关键任务的企业级工作负载时，他们对于数据保护有一套独特的需求。他们真的希望我们能够提供全面的数据保护方案以及管理功能，并且能够满足他们在不同区域或区域内的所有RTO和RPO需求。这种保护是不可或缺的。客户需要较短的备份时间窗口，以便能够轻松快速地从各种问题中恢复，无论是应用程序数据损坏还是其他可能由用户引发的类似问题。他们还需要一种跨区高可用性的解决方案，具有非常低的RPO和RTO，适用于各种应用程序。同时，他们也需要我之前描述的那种跨区域的内置灾难恢复站点，无论是为了地理冗余还是遵守金融监管要求。通过快照、区域性硬盘和异步复制等功能，我们现在正致力于解决这些问题，并将这些功能作为Filestore和NetApp存储解决方案的一流特性来构建。这意味着它们非常简单易用，并且现在就可以立即使用。
--【本文完】---
近期受欢迎的文章：
更多交流，可添加本人微信
（请附姓名/关注领域）