虽然 Apache Hadoop 以前都是使用 HDFS 的，但是当 Hadoop 的文件系统的需求产生时候也能使用 S3。之前的工作经历中的大数据集群存储都是用HDFS，当前工作接触到对象存储S3，在实践中比较两者的不同之处。
HDFS 依赖本地的存储只能横向扩展，增加一个存储区域就意味着不仅要加一个更大的硬盘驱动器来扩充节点，并且还要在集群上面加更多的机器。这是可行的，但是相比 S3 花费更多并且更加复杂。
S3 能根据存储的数据自动地扩展，根本不需要改变任何东西。甚至可用的空间是几乎无限的（至少对 Amazon 没有限制）。
对比：S3 表现更加优异
对HDFS数据持久性的统计模型表明，在一个很大的 4000 个节点的集群（16 PB 的总存储 250,736,598 个 block 副本）上面，丢失一个block的数据（默认是 64MB）的概率是 24 小时内 5.7 x 10 - 7，365 天内是 2.1 x 10 - 4。然而，对于仅仅只含有几十个实例的大多数集群来说，丢失数据的概率要高得多。
S3 为每个对象提供 99.999999999% 的年持久性，意味着每 10,000,000 年每10,000 个对象中只有一个会丢失。（详情见 S3 FAQ），它甚至可以更好。此外大数据集群中的 HDFS 依赖机器，恢复数据者备份数据都强依赖集群机器。S3 存储不依赖集群机器，数据存在另外一套单独的体系中。
对比：S3表现更加优异
为了确保数据的完整性，HDFS 默认存储数据的每个块的三个副本。这意味着需要的 HDFS 存储空间是实际数据的 3 倍，并花费相应的成本。虽然数据复制不是必须的，只是存储一个拷贝将消除 HDFS 的耐久性，并可能导致数据丢失。
亚马逊照顾备份数据 S3上 的，所以该空间的 100％ 是可用的并且只花费相应的价钱。 S3 还支持存储压缩文件，这大大减少了所需以及该法案的空间。
对比：S3表现更加优异
HDFS 的表现是非常棒的。数据被存储和运行在提高存取和处理速度相同的机器上面。
不幸的是 S3 还比不上 HDFS。等待时间是明显更高和数据吞吐量较低。然而，Hadoop 作业通常是由 chains 的 mapreduce 作业和中间数据存储到 HDFS 和本地文件系统比读写亚马逊 S3 你能够得到的节点的本地磁盘的吞吐量。
我们最近进行了一些测试，TestDFSIO，一个 hadoop 的读/写测试程序，在一个有 m1.xlarge 实例，每个节点有四个短暂的磁盘设备集群上。结果证实， HDFS 性能更好。
| 操作 | HDFS on Ephemeral Storage | Amazon S3 |
|---|---|---|
| Read | 350 mbps/node | 120 mbps/node |
| Write | 200 mbps/node | 100 mbps/node |
有人认为 HDFS 是不是安全的，但事实并非如此。Hadoop 通过 Kerberos 提供用户身份认证和通过 Hadoop 的文件系统权限提供了授权。YARN、Hadoop的最新版本，它能做得更好通过一个称为 federations 的新功能 - 将集群分成几个命名空间防止用户访问一个不属于他们的数据。数据可以通过 SSL 安全地被上传到 Amazon 的实例。
S3 内置了安全性。它支持用户身份验证，以控制谁可以访问数据，起初只 bucket 和 objects 的所有者能做操作。更多的权限可以通过 bucket 策略和访问控制列表（ACL）授予用户和组。数据可以被加密，并通过 SSL 安全地上传。
对比：HDFS数据权限比S3控制要好
尽管 HDFS 可以存储任何大小的文件，它具有存储非常小的文件（它们应该被连接或统一到 Hadoop 的档案）的问题。此外，保存的某一集群上的数据仅提供给该集群的机器上，并且不能被集群外的实例使用。
S3 没有这样的限制。在 S3 上的文件有一些限制，比如单次上传文件限制在 5GB 内，不支持 Parquet 或 ORC 文件直接读写，HDFS 支持 Parquet 或 ORC。
对比：HDFS表现更好