Dropbox 是如何升级它的存储系统的，又遇到了哪些问题？

数据存储前沿技术

发布于 2025-10-09 10:58:10

800

文章被收录于专栏：存储公众号：王知鱼存储公众号：王知鱼

阅读收获

理解Dropbox如何通过智能路由和自研Magic Pocket，实现EB级存储的成本效益与高性能平衡。
学习批量写入与对象分块技术，优化小文件与大文件存储，提升底层存储效率并大幅降低云成本。
掌握分层加密与加密粉碎机制，构建高安全性数据保护体系，并实现合规性数据即时删除。
洞察面向AI/ML工作负载的下一代存储架构演进方向，为未来数据平台建设提供前瞻性思路。

全文概览

在海量数据时代，存储架构的演进是技术巨头持续面临的挑战。Dropbox，作为全球领先的文件同步与共享服务提供商，曾深陷S3高昂成本、厂商锁定及多系统运维的泥潭。他们如何打破困境，构建起一套兼顾成本、性能与灵活性的自研对象存储系统？

本文将深入剖析Dropbox的存储革命，揭秘其核心利器——Magic Pocket，以及其背后的四大创新。我们将看到Dropbox如何通过智能路由、批量写入、对象分块、分层加密及加密粉碎等技术，成功支撑EB级用户数据，并为AI时代的数据管理奠定坚实基础。这不仅是技术架构的升级，更是对成本效益、数据安全与未来扩展性的深远思考。

👉 划线高亮观点批注

引入新的对象存储方案之前，Dropbox 所面临的存储挑战

“Before Object Store (Pre-2020)”（对象存储出现之前，2020年前）
- 这部分描述了2020年以前的存储架构状况。
- Amazon S3 + HDFS as backbone storage：使用亚马逊S3（一种公有云对象存储服务）和HDFS（Hadoop分布式文件系统）作为公司的骨干存储系统。这表明其核心数据存储在一个混合的环境中。
- Magic Pocket for user files only：“Magic Pocket”（魔法口袋）是一个专门用于存储用户文件的系统。这很可能是一个内部自研或特定的存储系统名称。
- S3/HDFS for internal products：公司的内部产品和服务也依赖于S3和HDFS进行数据存储。
- 小结：在采用新的统一对象存储之前，该公司的存储架构是异构的、分散的，由公有云服务（S3）、大数据文件系统（HDFS）和一个专用系统（Magic Pocket）共同组成。
“Major Pain Points”（主要痛点）
- 这部分列举了上述传统存储架构带来的四个核心问题。
- Cost Inefficiency: Expensive S3 PUT/GET requests：成本效益低下，主要体现在使用S3时昂贵的PUT（上传/写入）和GET（下载/读取）请求费用。
- No Flexibility: Locked into S3 as default：缺乏灵活性，由于S3被设为默认存储选项，导致技术栈被锁定在AWS S3上，难以迁移或选择其他更优方案（厂商绑定）。
- Operational Overhead: Multiple storage systems：运维开销巨大，同时维护和管理多个不同的存储系统（S3, HDFS, Magic Pocket）增加了团队的工作复杂度和负担。
- Limited Control: No centralized policies：控制能力有限，由于系统分散，无法实施统一集中的管理策略，例如数据生命周期、访问控制、安全合规等策略。

愿景：元存储抽象层

“What We Wanted”（我们的期望）
- 这部分详细描述了新存储解决方案需要达成的目标，这些目标精确地对应了上一页提到的痛点。
- Transparent Backend Routing based on cost & access patterns：基于成本和访问模式的透明后端路由。这意味着系统需要能够智能地、自动地将数据路由到最合适的后端存储（如低成本的冷存储或高性能的热存储），而这个过程对上层应用是完全透明的，应用本身无需关心数据究竟存在哪里。这直接解决了“成本高昂”和“缺乏灵活性”的问题。
- Centralized Control for all blob traffic：对所有Blob（二进制大对象，通常指非结构化数据）流量进行集中控制。目标是建立一个统一的管理入口，以取代之前分散在多个系统中的混乱状态，从而解决“运维开销大”和“控制力有限”的问题。
- Additional Features: Encryption, monitoring, retention policies：提供额外的附加功能，如加密、监控和数据保留策略。在一个集中化的平台之上，可以轻松地实现和强制执行这些企业级的关键功能，确保数据安全与合规。
“The Birth of Object Store (2020)”（对象存储的诞生，2020年）
- 这部分宣告了解决方案的落地。在2020年，这个承载了上述愿景的新系统诞生了，并被命名为“Object Store”（对象存储）。S3也是对象存储，这里是指的对象存储架构。

新系统存储架构

PPT的核心是阐述 Object Store的分层、解耦的智能存储网关架构。

架构模式：系统采用了一个统一前端（Front End）+ 多个可插拔后端（Backend） 的模式。前端是无状态的，负责处理逻辑；后端是实际存储数据和元数据的。
核心功能：其核心功能是抽象化和智能路由。它通过一个抽象层向应用屏蔽了后端存储的复杂性和多样性，并利用智能路由策略（基于元数据）来优化数据的存取，以实现成本和效率的最优化。
关键设计依赖：整个架构的设计深受其关键后端 “Magic Pocket” 的技术特性影响。特别是 “针对4MB对象优化” 这一限制，是驱动其智能路由做出决策的核心依据之一，体现了系统设计的务实性和针对性。后文讲展开介绍 Magic Pocket 构造原理。

===

左侧：核心组件分层 这部分从上到下描述了系统的三个关键逻辑层：

Abstraction Layer（抽象层）
- 解释：这是系统的入口和用户接口层。所有应用都与这一层交互，它负责接收请求，但本身不存储任何实际的数据对象（Blob）。
Smart Routing（智能路由）
- 解释：这是系统的核心决策逻辑。当有写入（PUT）请求时，它会根据预设策略（如成本最低）决定将数据存入哪个后端存储系统。当有读取（GET）请求时，它能精确地知道数据存在哪里，并将请求导向正确的后端。
MySQL Metadata（MySQL元数据）
- 解释：这是系统的“大脑”或索引。它使用MySQL数据库来存储元数据，其中最重要的信息就是每个数据对象（Object）被存放到了哪个后端存储系统（Placement）。智能路由层在处理读取请求时，需要查询这里的信息来定位数据。

右侧：架构示意图 这张图直观地展示了各组件之间的关系：

Object Store Front End（对象存储前端）：位于顶部的深色方框，代表了所有请求的统一入口。它包含了上述的“抽象层”和“智能路由”逻辑。
后端系统：从前端分支出四个箭头，分别指向不同的后端组件。
- Metadata DBs（元数据数据库）：对应左侧的MySQL元数据层，是独立的元数据存储。
- Blob Storage: S3：代表其中一个物理数据存储后端是Amazon S3。
- Blob Storage: MP：代表另一个物理数据存储后端是“Magic Pocket”（MP）。
- Blob Storage: etc：代表“等等”，表明这个架构具有良好的扩展性，未来可以轻松接入更多不同类型的存储后端。

Magic Pocket 存储基石

PPT的核心目的是详细介绍Magic Pocket系统，并确立其作为Dropbox公司存储基础设施基石的地位。

它揭示了Magic Pocket是一个Dropbox自研的、EB级别的海量Blob存储系统，专门用于承载其全部用户数据。该系统具备四大核心特点：海量规模（EB级容量、超60万块硬盘、百万级QPS）、高可用性（99.99%）、地理冗余（跨越北美三个区域）和硬件定制化

MP 基础架构

上半部分：三大核心指标

100+ Disks per OSD（每个OSD超过100块硬盘）
- OSD是Object Storage Device（对象存储设备）的缩写，是分布式存储中的一个基本硬件单元，通常指一台或一个机架内的存储节点。
- 这条指标说明，Magic Pocket的硬件构建块是超高密度的，每个基础单元都集成了超过100块物理硬盘。
2+ PB Storage per OSD（每个OSD管理超过2PB的存储）
- 这条指标量化了单个OSD单元的存储容量。每个单元能够管理超过2PB（Petabyte）的数据。结合上一条信息，可以推断出系统采用了单块容量非常大（例如20TB以上）的硬盘。
11 9s Durability（11个9的数据持久性）
- 数据持久性（Durability） 是衡量数据不会丢失的指标，区别于衡量系统在线时间的可用性（Availability）。11个9即99.999999999%的持久性，是业界顶级对象存储（如Amazon S3）的标准，意味着数据丢失的概率极低。

下半部分：关键设计原则 (Key Design Principles)

Immutable Writes: Data never changes after write（不可变写入：数据写入后永不改变）
- 这是一项核心设计。一旦一个数据对象被写入Magic Pocket，它就不能被修改或编辑。任何对文件的“更新”操作，实际上都是写入一个全新的对象版本。这种设计大大简化了数据一致性、缓存和副本管理，是许多大规模分布式系统的共同选择。
Cold Data Optimization: Most data rarely accessed（冷数据优化：大部分数据很少被访问）
- 系统设计的出发点基于一个假设：存入系统的大部分数据都属于“冷数据”，即写入后很少会被再次读取。这个原则使得架构可以优先为存储密度和成本效益进行优化，而不是为极端的读取性能。
4MB Blob Optimization: Sweet spot for performance（4MB Blob优化：性能的最佳平衡点）
- 这条原则再次强调了之前PPT中提到的关键约束。系统在处理大小为4MB的数据块（Blob）时，性能表现（如吞吐量、IO效率）是最好的。这个“最佳点”（Sweet spot）是系统所有性能调优的核心基准。

存储 API及结构

Smart Backend Selection（智能后端选择）

这部分解释了“对象存储”系统如何智能地决定将数据存放在哪个物理后端。

S3: Global regions, legacy compatibility: 指出选择S3作为后端主要基于两个原因：
1. 全球区域覆盖：利用AWS S3遍布全球的数据中心，可以满足数据需要存放在特定地理位置（如欧洲、亚洲）的业务或合规需求。
2. 遗留系统兼容性：对于一些老的、深度绑定S3的应用，可以继续让它们无缝工作，无需进行代码改造。
Magic Pocket: Cost-efficient, high-performance: 指出选择自研的Magic Pocket作为后端的原因：
1. 成本效益高：使用内部系统可以避免S3高昂的请求费和流量费，从而降低成本。
2. 高性能：Magic Pocket是为自身业务负载量身定制的，可以在私有网络环境中提供更高的性能。
Future backends: Ready for new technologies: 指出系统的架构是面向未来的：
1. 为新技术做好准备：该架构并非封闭的，它具备良好的扩展性，未来可以根据技术发展，随时集成新的存储后端（例如，其他云厂商的服务、新型存储介质等）。这彻底解决了最初“缺乏灵活性”的痛点。

===

新架构核心优势在于：通过智能路由提供全球服务，美国境内的优先自研的MP架构，性能更好、成本更优，海外的存储需求复用AWS的全球基础设施提供近地服务。猜测 Dropbox 的这套架构，可以对外提供存储元数据服务，通过纳管不同区域的存储资源，提供统一、私有化的接入服务。

创新点一：批量写入，描述了一种为解决特定问题而设计的写入优化机制。这个问题的背景是：应用需要存储大量小文件，但底层核心存储系统（Magic Pocket）处理4MB的大文件时效率最高。

上半部分：批量写入的流程 这部分通过一个5步流程，清晰地说明了“批量写入”是如何工作的：

Enqueue PUT requests by pail（按Pail将PUT请求加入队列）：当应用发起上传（PUT）小文件的请求时，系统不会立即将其写入后端存储。而是先将这些请求按照其所属的容器（Pail）进行分组，并放入一个临时的处理队列中。
Trigger on timeout OR size threshold（基于超时或大小阈值触发）：队列的处理由两个条件之一触发。要么是等待时间超过了一个设定的阈值（超时），要么是队列中所有文件累积的大小达到了一个设定的阈值。
Concatenate multiple objects → single blob（将多个对象合并成单个Blob）：一旦触发，系统会把队列中的多个小尺寸对象（objects）合并（concatenate）成一个单一的、更大的数据块（blob）。
Write to Magic Pocket (targeting 4MB)（写入Magic Pocket，目标大小4MB）：将上一步生成的大数据块（blob）作为单次操作写入到Magic Pocket中。这一步的关键是，合并的目标大小会尽可能地接近Magic Pocket的性能最佳点，即4MB。
Store metadata with offsets（存储带有偏移量的元数据）：由于多个逻辑上的独立对象现在被物理上存储在了同一个大数据块中，系统必须在元数据数据库（MySQL）中记录下每个小对象在这个大blob里的具体位置，即它的起始位置（offset）和长度。这样，在未来读取某个小对象时，系统才知道去哪里找。

下半部分：影响与收益 (Impact) 这部分总结了“批量写入”机制带来的三大好处：

Fewer PUT requests = major cost savings（更少的PUT请求 = 大幅的成本节省）：通过将成百上千次的小文件写入合并为一次大文件写入，极大地减少了对后端存储的写入操作次数。这不仅能节省类似S3按次收费带来的成本，也能提升内部存储系统的I/O效率。
Optimized for Magic Pocket 4MB constraint（针对Magic Pocket的4MB限制进行了优化）：这是该创新的核心目的。它巧妙地解决了“上层应用写小文件”和“底层存储偏好大文件”之间的矛盾，确保写入到Magic Pocket的数据块都是性能最优的尺寸。市场上针对对象存储读写优化的中间件有不少，JuiceFS/Alluxio 都是很好的产品。
Cache optimization for GETs（为GET请求优化了缓存）：这是一个附带的性能提升。当用户请求读取（GET）其中一个小文件时，系统会从Magic Pocket读取整个4MB的大数据块到缓存中。如果用户紧接着请求访问同一个数据块中的其他小文件，这些请求就可以直接从缓存中得到满足，无需再次访问后端存储，从而提高了读取性能和缓存命中率。

创新点二：分层加密

PPT的核心是介绍了系统采用的 “分层加密”（或称“信封加密”）安全架构 ，以实现静态数据的强力保护和高效管理。

该架构的核心思想是用密钥来加密密钥。它使用唯一的BEK来加密每个数据对象，然后使用更高阶的、带版本的KEK来加密所有的BEK。

这种设计带来了两大关键价值：

极高的安全性：通过将数据、数据密钥、主密钥三者分离，构建了深度防御体系。
极高的运维效率：使得密钥轮换这一关键安全操作变得极其高效和可行，因为它避免了对海量数据本身的重加密，解决了大规模存储系统在密钥管理上的核心痛点。

创新点三：用于删除的加密粉碎

左侧：挑战 (The Challenge)

这部分描述了在他们的系统中，实现数据删除所面临的两大难题：

Compliance: Data must be purged within deadline（合规性：数据必须在规定期限内被清除）：许多数据保护法规（如GDPR）要求，当用户请求删除其数据时，必须在严格的时间限制内将其永久删除。传统的物理删除过程可能很慢，难以满足合规要求。
Batching Problem: Can't batch DELETEs safely（批量写入带来的问题：无法安全地批量处理删除）：这直接关联到了“创新点一：批量写入”。由于多个独立的小对象被打包存放在一个大的物理数据块（Blob）中，当需要删除其中一个小对象时，系统不能简单地删除整个物理数据块，因为这会破坏属于其他用户的其他对象。执行“读-改-写”操作（即读取整个大文件，移除其中一小部分，再写回一个新文件）在他们这种规模下是极其低效和昂贵的。

右侧：解决方案：加密粉碎 (Solution: Crypto-Shredding)

这部分阐述了如何利用加密技术来巧妙地解决上述挑战：

Simply wipe object metadata (including encrypted BEK)（仅擦除对象元数据，包括加密后的BEK）：当收到删除请求时，系统的核心操作不是去动后端存储（Magic Pocket）里的物理数据。而是直接在元数据数据库（MySQL）中，删除该对象对应的元数据记录。这条记录中包含了最重要的信息——加密该对象的、独一无二的加密密钥（BEK）。
No KEK = No data access（没有密钥 = 无法访问数据）：（此处原文的“No KEK”应为“No BEK”更能准确表达意思）。一旦包含BEK的元数据被删除，与之对应的那个加密数据对象就成了一串无法解密的、毫无意义的乱码。因为解密的“钥匙”被永久销毁了，数据在密码学的意义上被“粉碎”了，从而达到了永久删除的效果。
Synchronous compliance via MySQL（通过MySQL实现同步合规）：删除一条数据库记录是一个非常快速、同步（Synchronous） 的操作。这意味着系统可以在收到删除请求的瞬间就完成元数据的擦除，从而立即满足合规性要求，因为数据在这一刻起就变得不可访问了。
Asynchronous space reclamation（异步的空间回收）：物理数据块虽然还在硬盘上，但已成为无人能访问的“垃圾数据”。系统可以通过一个独立的、异步（Asynchronous） 的后台垃圾回收（Garbage Collection）进程，在业务不繁忙的时候，定期扫描并清理那些已经没有任何有效对象引用的物理数据块，从而回收磁盘空间。

这一页技术要结合上一页的加密设计来理解，核心思想是构建密文元数据存储在mysql中，底层数据需要解码后的元数据才能访问，从而抽象了数据删除的底层操作-即元数据是数据身份编码，只需要对其进行操作即可。这个技术是有原创性的，对于数据保护和联邦治理都有价值。

创新点四：对象分块

左侧：问题 (The Problem)

这部分描述了在引入“对象分块”之前，系统在处理大文件时遇到的困境：

Magic Pocket optimized for 4MB（Magic Pocket针对4MB进行了优化）：再次强调了底层核心存储系统的基本特性，即处理4MB大小的文件时性能最佳。
Many objects > 4MB (logs, artifacts, media)（许多对象大于4MB，如日志、构建产物、媒体文件）：指出现实业务中存在大量尺寸远超4MB的大文件，例如日志文件、软件构建的中间产物、音视频等媒体文件。
Original solution: Route large objects to expensive S3（最初的解决方案：将大对象路由到昂贵的S3）：描述了他们最初的应对方法。智能路由层会识别出这些不适合存入Magic Pocket的大文件（MP本质上是为小文件写入而设计的优化系统，对大文件的写入需要额外设计），并将它们转而存入Amazon S3。这样做虽然解决了技术适配问题，但却导致了高昂的存储成本。

中间：分块解决方案 (Chunking Solution)

这部分详细阐述了“对象分块”的具体技术实现：

Break large objects into 4MB chunks（将大对象切分成4MB的块）：这是核心思想。当一个大文件被上传时，对象存储的前端逻辑会自动将其切割成一系列标准大小为4MB的数据块（chunks）。
Store chunks in Magic Pocket（将分块存储在Magic Pocket中）：切割后的每一个4MB数据块，现在都完美符合Magic Pocket的最佳性能尺寸，因此可以被高效地存入这个成本更低的内部存储系统中。
Parallel reconstruction at read time（在读取时并行重构）：当用户需要读取原始的大文件时，系统会同时（并行）去获取组成该文件的所有4MB数据块，然后在前端将它们按正确顺序重新组装成完整的文件，再返回给用户。并行读取可以大大提高大文件的下载速度。
Deterministic keys: No extra metadata needed（确定性密钥：无需额外元数据）：这是一个非常精巧的优化设计。“确定性密钥”意味着每个小数据块的名称（或key）都可以通过一个固定的算法，基于原始文件名和它在文件中的序号计算出来。因此，系统不需要在元数据数据库中额外存储一张列表来记录这个大文件包含了哪些小数据块。当需要读取时，只需根据算法就能推算出所有需要获取的数据块的名称。这极大地简化了系统设计，并避免了元数据存储的膨胀。

JuiceFS 同样采取分片重构的方式存储，差异之处在于 JuiceFS 需要维护分片后的元数据信息，而 Dropbox 通过确定性密钥省去了分片的元数据维护，因为数据分片重构，存储在MP的数据一定程度上也是私有化的。

右侧：收益 (Benefits)

这部分总结了这项创新带来的显著好处：

All data hits Magic Pocket's sweet spot（所有数据都命中了Magic Pocket的最佳性能点）：通过“批量写入”处理小文件和“对象分块”处理大文件，系统最终实现了无论原始文件大小如何，所有写入到Magic Pocket的物理数据块都是最优的4MB大小，最大化了后端存储的效率。
Millions in annual S3 cost savings（每年节省数百万美元的S3成本）：这是最直接的业务价值。通过将大文件从昂贵的S3迁移到成本效益更高的自研系统Magic Pocket，公司每年节省了巨额的云服务开销。

AI时代的演进：未来方向

第一阶段：Current AI Opportunities（当前AI机遇）

这部分列举了当前可以基于现有对象存储平台直接赋能的AI应用场景。
- Natural language search（自然语言搜索）：利用AI模型对存储在系统内的海量非结构化数据进行语义搜索。
- Content summarization（内容摘要）：调用AI模型自动为长文档或数据集生成摘要。
- Knowledge management systems（知识管理系统）：在对象存储之上构建企业知识库，利用AI进行知识的组织、索引和问答。
小结：在当前阶段，对象存储主要作为AI应用的数据湖（Data Lake），为上层AI应用提供数据养料。

第二阶段：Planned Enhancements（规划中的增强功能）

这部分列举了计划为现有对象存储平台增加的核心功能，使其从一个单纯的存储底座向一个更智能的数据平台演进。
- Lambda Functions: Object writes/modifications（Lambda函数：响应对象写入/修改）：计划引入Serverless（无服务器）计算能力。当有对象写入或修改时，可以自动触发一段代码（Lambda函数）执行，例如自动提取元数据、图片识别、数据清洗转换等，实现“存储即计算”。
- Database Backend: Cassandra/RocksDB on Object Store（数据库后端：在对象存储之上支持Cassandra/RocksDB）：计划将对象存储作为数据库的后端。即让Cassandra或RocksDB这类数据库系统将它们的数据文件（如SSTable）直接持久化到对象存储中，实现数据库的存算分离。
- Third-party Integration: Apache Pinot, Loki（第三方集成：Apache Pinot, Loki）：计划与主流的开源数据系统进行深度集成，例如支持作为实时分析数据库Pinot和日志系统Loki的存储后端，扩展其生态。

第三阶段：SkyVault-Inspired Next-Gen Storage（受SkyVault启发的下一代存储）

这部分描绘了公司的终极愿景：打造一个全新的下一代存储系统。
- Open-source cloud-native key-value store（开源的云原生键值存储）：目标是构建一个核心为Key-Value模型的、为云环境而生的（Cloud-Native）新系统，并可能将其开源。
- Compute-storage separation using Object Store foundation（使用现有对象存储作为基础，实现存算分离）：这个新系统将采用先进的存算分离架构，而其存储层（Storage）将直接构建在当前成熟的对象存储平台之上。
- Target: AI/ML workloads, feature stores, analytics（目标：AI/ML负载、特征存储、分析）：新系统的目标客户非常明确，就是为了满足AI/ML训练、特征存储（Feature Store）和大规模数据分析等高性能、高并发的新兴工作负载。

影响与成果

第一栏：Cost Savings（成本节省）

这部分聚焦于项目带来的直接财务回报：

Millions saved annually from S3 optimization（通过S3优化，每年节省数百万美元）：这主要得益于“对象分块”等技术，将原本需要存储在昂贵S3上的大文件，转移到了成本更低的自研系统Magic Pocket中。
HDFS deprecation = additional millions（弃用HDFS = 额外的数百万美元节省）：通过将HDFS上的工作负载迁移到新的对象存储平台，公司得以淘汰老旧的HDFS集群，从而节省了相关的硬件、电力和运维人力成本。
Reduced API costs via batching（通过批量写入降低API成本）：这直接对应“批量写入”创新点。通过将大量小文件的写入请求合并，显著减少了API调用次数，从而节省了按次计费的API费用。

第二栏：Technical Achievements（技术成就）

这部分总结了项目在工程技术上实现的核心突破：

Unified storage interface across backends（跨后端的统一存储接口）：实现了S3兼容的API作为唯一入口，为开发者屏蔽了底层存储（S3, Magic Pocket等）的差异性和复杂性。
Flexible routing based on cost/requirements（基于成本/需求的灵活路由）：实现了智能数据路由，系统可以根据预设策略，自动将数据放置到最合适的存储后端。
Enhanced security with granular encryption（通过精细化加密增强安全性）：通过“分层加密”技术，为每个对象都提供了独立的加密密钥，实现了极高的安全性。
Compliance ready with instant deletion（通过即时删除满足合规性）：通过“加密粉碎”技术，实现了数据的瞬时、永久性逻辑删除，轻松满足了严格的数据保护合规要求。