Hadoop与数据湖的关系
1、Hadoop时代的落幕
十几年前，Hadoop是解决大规模数据分析的"白热化"方法，如今却被企业加速抛弃。曾经顶级的Hadoop供应商都在为生存而战，Cloudera于2021年10月8日完成了私有化过程，黯然退市
从数据湖方向发力的Databricks，却逃脱了"过时"的命运，于2021年宣布获得16亿美元的融资。另一个大数据领域的新星------云数仓Snowflake，2020年一上市就创下近12年来最大IPO金额，成为行业领跑者
行业日新月异，十年时间大数据的领导势力已经经历了一轮更替。面对新的浪潮，我们需要做的是将行业趋势和技术联系起来，思考技术之间的关联和背后不变的本质
Hadoop与Cloudera的潮起潮落详见文章：传送门
2、Databricks和Snowflake做对了什么
Hadoop和数据湖都是2006年开始兴起的概念。为什么同时期兴起，经历十多年发展，Hadoop逐渐衰落，数据湖反而迎来了热潮？
网络上有个说法："公有云玩家"以零成本赠送Hadoop产品，加速了Hortonworks和Cloudera等厂商的衰落。但像 nowflake这样的新兴企业，它最大的合作伙伴却是AWS等云厂商。作为云厂商的生态系统合作伙伴，Snowflake推动了大量Amazon EC2/S3的销售
在我们看来，Hadoop只是数据湖的一种实现，而新一代数据湖通过拥抱云计算和开源社区，经历了新生
Databricks和Snowflake都抓住了OLAP的数据分析场景，基于兴起的云技术在数据存储和数据消费之间构建了新的中间数据抽象层（Data Virtualization），即屏蔽了底层系统的异构性，又提供了远超Hadoop生态系统的用户体验。这是他们能够成功的根本原因
在云计算的背景下，计算存储相分离的设计概念逐渐清晰，促进了现代数据湖和数据仓库的架构在数据存储和数据消费端的进一步解耦以及业界标准接口的规范化，这使得开源社区通过这些标准接口贡献新技术的发展成为可能
同时，公有云计算平台的出现，某种程度上加速了数据的垄断和计算需求的集中，推动业界对于数据以及数据处理做出更明确的需求定义，针对性地投入开源项目，以社区这种更灵活开放的方式促进技术发展，再反哺公有平台的进化和发展
传统的关系型数据库，如Oracle、DB2、MySQL、SQL Server等采用行式存储法，而一些新兴分布式数据库所采用的列式存储相较于行式存储能加速OLAP工作负载的性能，这已经是众所周知的事实
但在我们看来，更加革命性的变化是列式存储格式的标准化。Parquet和ORC的列式存储格式都是2013年发明的，随着时间的推移，它们已经被接受为业界通用的列式存储格式。数据是有惯性的，要对数据进行迁移和格式转换都需要算力来克服惯性；而数据的标准化格式意味着用户不再被某一特定的OLAP系统所绑定（Locked In），而是可以根据需要，选择最合适的引擎来处理自己的数据
第二大突破性技术是分布式查询引擎的出现，如SparkSQL、Presto等。随着数据存储由中心式向分布式演进，如何在分布式系统之上提供快速高效的查询功能成为一大挑战，而众多MPP架构的查询引擎的出现很好地解决了这个问题。SQL查询不再是传统数据库或者数据仓库的独门秘籍
在解决了分布式查询的问题之后，下一个问题是，对于存储于数据湖中的数据，很多是非结构化的和半结构化的，如何对它们进行有效地组织和查询呢？
在2016到2017年之间，Delta Lake、Iceberg、Hudi相继诞生。这些类似的产品在相近的时间同时出现，表明它们都解决了业界所亟需解决的问题。这个问题就是，传统数据湖是为大数据、大数据集而构建的，它不擅长进行真正快速的SQL查询，并没有提供有效的方法将数据组织成表的结构。由此，在缺乏有效的数据组织和查询能力的情况下，数据湖就很容易变成数据沼泽（Data Swamp）
利用云基础架构，是Databricks和Snowflake成功的关键
如果仔细了解一下Databricks和Snowflake的发展历程，可以发现两者的出发点有所不同。Databricks是立足于数据湖，进行了向数据仓库方向的演化，提出了湖仓一体的理念；而Snowflake在创建之初就是为了提供现代版的数据仓库，近些年来也开始引入数据湖的概念，但本质上说它提供的还是一个数据仓库
Snowflake利用云技术革新了传统数据仓库。它提供了一个基于公有云的、完全托管的数据仓库，把传统的软硬件一体的消费模式改造为了软件服务的模式（SaaS）
无论是存储还是计算，Snowflake都利用了公有云提供的基础设施，从而使任何人都可以在云端使用数据仓库服务
另一方面，传统的数据湖在数据分析上存在不足，不能很好地提供OLAP场景的支持。因此，Databricks通过Delta Lake提供的表结构和Spark提供的计算引擎，构建了一套完整的基于数据湖的OLAP解决方案。Databricks的愿景是基于数据湖提供包括AI和BI在内的企业数据分析业务的一站式解决方案
与Snowflake相似的是，Databricks也充分利用了云基础架构提供的存储和计算服务，在其上构建了入门成本低、定价随使用而弹性扩展的软件服务方案
3、Hadoop与对象存储（OSD）
近年来，存储正在经历新一轮革命：从Hadoop到对象存储（OSD）
数据湖和Hadoop并不是竞争关系。作为一种架构，数据湖会将其它技术整合到一起，而Hadoop则成为了一种可以用来构建数据湖的组件。换句话说，Hadoop和数据湖的关系是互补的，在可预见的未来，随着数据湖继续流行，Hadoop还将继续存在
然而，数据湖会抛弃Hadoop吗？有可能。因为作为一种综合性技术架构，除了Hadoop HDFS外，数据湖还可以选择"对象存储"作为它的核心存储
现在越来越多的，像Databricks、Snowflake这样的数据平台类创业公司选择采用对象存储作为存储的核心
从头开始搭建一个分布式存储很难。所谓"计算出了问题大不了重试，而数据出了问题则是真出了问题"。所以很多数据平台类的公司如Databricks、Snowflake等都会借着计算存储分离的趋势，选择公有云提供的存储服务作为它们的数据和元数据存储，而公有云上最通用的分布式存储就是对象存储
对象存储详解见文章：传送门
4、Databricks与Snowflake为什么选择对象存储
为什么Databricks与Snowflake会选择采用对象存储作为存储的核心？
从技术角度来说，首先，对象存储即为非结构化存储，数据以原始对象的形式存在。这点贴合数据湖对于先存储原始数据，再读取完整数据信息后续分析的要求
其次，对象存储拥有更先进的分布式系统架构，在可扩展性和跨站点部署上，比传统存储更具优势。由于对象存储简化了文件系统中的一些特性，没有原生的层级目录树结构，对象之间几乎没有关联性，因此对象存储的元数据设计能更为简单，能够提供更好的扩展性。此外，数据湖业务往往也需要底层存储提供多站点备份和访问的功能，而绝大部分对象存储原生支持多站点部署。通常用户只要配置数据的复制规则，对象存储就会建立起互联的通道，将增量和/或存量数据进行同步。对于配置了规则的数据，你可以在其中任何一个站点进行访问，由于跨站点的数据具备最终一致性，在有限可预期的时间内，用户会获取到最新的数据
第三，在协议层面，由AWS提出的S3协议已经是对象存储事实上的通用协议，这个协议在设计之初就考虑到了云存储的场景，可以说对象存储在协议层就是云原生的协议，在数据接口的选择和使用上更具灵活性
第四，对象存储本身就是应云存储而生，一开始起家的用户场景即为二级存储备份场景，本身就具备了低价的特性
因此，对象存储是云时代的产物，支持原始数据存储、分布式可扩展、高灵活性、低价，都是对象存储之所以被选择的原因
5、对象存储面临的挑战
新一代数据平台的基本架构都是存算分离，即计算层和存储层是松耦合的。计算层无状态，所有的数据、元数据以及计算产生的中间数据都会存储于存储层之中。这一架构的优势包括更好的扩展性（计算、存储独立扩展），更好的可用性（计算层的失效不影响存储，因此能够很快恢复），以及更低的成本。为了适应存算分离的架构，对象存储本身也需要进一步发展
想要适应存算分离的大趋势，不是简单地把现有存储对接到计算层就可以完成的，存储本身要经历新一轮架构革命才能更好地服务于计算层
在架构之外，数据平台型业务也给对象存储的特性提出了若干新的挑战
第一个挑战是数据分析型业务所需要的性能要远高于数据备份的场景，对象存储需要能够提供与计算需求相匹配的大带宽与低延时。另一方面，对象存储还需要根据业务场景来优化性能
第二个挑战来自于数据分析所包含的众多元数据操作。因此对象存储不仅要能够提供大带宽，还要在处理小对象和元数据操作，同时提供足够的性能。这就比较考验对象存储的元数据管理能力
第三个挑战是对象存储如何兼顾性能和成本。数据湖中存储了庞大的企业数据，但在任一时间点，可能只有一小部分数据是被数据分析业务所需要的。如果所有数据都放在性能最优的物理介质上（比如非易失性内存），那么成本将变得过高，失去了云存储的经济性，而如果在对象存储的前端再加一层Cache层，无疑也会增加整个系统的复杂度。因此如何有效识别冷热数据，并将它们分区放置是对象存储需要解决的问题
第四个挑战是对象存储如何与开源生态相结合。现阶段比较成熟的在数据湖之上提供表结构的开源产品是Delta Lake、Iceberg和Hudi。同时从应用场景上来说，在传统的离线数据分析场景之外，实时数据分析的业务场景正在增加。