几年前，Hadoop被吹捧为资料仓库的替代品，这显然是 无稽之谈。本文旨在提供Hadoop / HDFS作为分析平台的特性和缺点的客观总结，并将这些与基于云的Snowflake资料仓库进行比较。

Hadoop：一种基于档案的分散式架构

首先由Doug Cutting在Yahoo!开发 然后从2012年起开始开源，Hadoop在昂贵的MPP装置上作为分析工作负载（资料仓库应用程序）的可能替代品获得了相当大的吸引力。

虽然在某些方面类似于数据库，Hadoop分散式档案系统（HDFS）不是具有相应工作负载，读取一致性和并发管理系统的数据库。虽然Hadoop与MPP数据库有许多相似之处，包括其多节点可伸缩性，对列资料格式，SQL的使用和基本工作流管理的支援，但存在许多差异，包括：

没有ACID合规性： 与Snowflake不同，Snowflake支援多个并发读取一致性读取和更新以及ACID合规性，HDFS只是编写不可更改或允许更改的不可变档案。要更改档案（大多数情况下），您必须将其读入，并在应用更改时将其写出。这使得HDFS更适合于非常大量的资料转换，但是对于即席查询来说是一个糟糕的解决方案。

HDFS适用于大型资料集： 与将资料储存在可变长度微分割槽上的Snowflake不同，HDFS将资料分解为固定大小（通常为128Mb）的块，这些块在三个节点上进行复制。这使得它对于小资料档案（1GB以下）来说是一个糟糕的解决方案，其中整个资料集通常储存在单个节点上。但是，雪花可以轻松处理微小的资料集和太字节。

HDFS不具有弹性可扩充套件性： 尽管可以（通过停机时间）向Hadoop丛集新增其他节点，但只能增加丛集大小。这与Snowflake相比较差，Snowflake可以 在几毫秒内立即从单个节点丛集扩充套件到128个节点的庞然大物，然后快速缩减甚至完全暂停计算资源。

Hadoop非常复杂：Hadoop 最大的唯一缺点可能是传奇的部署，配置和维护成本。这与Snowflake相比较差，无需部署硬件或安装和配置软件。自动捕获统计资讯，并由复杂的基于成本的查询工具使用， DBA管理 几乎为零。

下图说明了Hadoop / HDFS平台中的关键元件。它说明了如何 配置名称节点 以记录跨群集分布的资料的物理位置。

虽然这可以在大量（多TB）批处理查询中提供出色的效能，但下图说明了为什么它对于通用资料管理来说是一个糟糕的解决方案。

上图说明了服务层 如何 管理并发，工作负载和事务管理。与Hadoop解决方案不同，Snowflake资料储存与计算处理完全分开，这意味着可以动态增加或减少群集大小。

上述解决方案还支援Virtual Warehouse和Services层的内建快取层。这使得Snowflake成为大量查询处理的合适平台，从PB级资料处理到仪表板上的亚秒级查询效能。

下表提供了Hadoop和Snowflake主要功能的简单并排比较：

大多数希望Hadoop取代其企业​​资料仓库的人都非常失望。

Hadoop提出的主要优势是能够管理结构化，半结构化（JSON）和非结构化文字，并支援 读取模式。这意味着可以简单地载入和查询资料而无需考虑结构。

虽然Hadoop无疑是视讯，声音和自由文字处理的唯一平台，但这只是资料处理的一小部分，Snowflake对JSON提供完全原生支援，甚至支援SQL内部的结构化和半结构化查询。

结论

由于未能捕获重要的MPP数据库市场份额，Hadoop被吹捧为Data Lake的推荐平台 - 一个原始业务资料的不可变资料储存。虽然这可能是重新利用现有Hadoop丛集的合适平台，但它确实具有与 MPP解决方案相同的 缺点，可能会过度配置计算资源，因为每个节点都会增加计算和储存容量。有争议的是，基于云的物件资料储存（例如Microsoft Blob Store或Amazon S3）是资料湖的更好基础，利用计算和储存的分离来避免过度配置。但是，由于Snowflake支援实时资料提取和本机JSON支援，这是一个更好的资料湖平台。

Hadoop确实有可行的未来可能是使用Apache Kafka和Spark，Storm或Flink 进行 实时资料捕获和处理，尽管目标目标几乎肯定是数据库，Snowflake是资料仓库的明显赢家。

然而，作为MPP数据库的替代品，Hadoop远远低于所需的效能，查询优化和低延迟，Snowflake是当今市场上最好的资料仓库平台。