2024 年，一个大数据从业者决定……

2024 年，一个大数据从业者决定走出围城。

不过，在正式聊【走出围城】前，先谈谈【走入】的事情。我读书时的专业是xx，毕业后顺理成章地做了几年业务开发。没过多久我就发现，随着业务的数据规模越来越大，在存储、分析方面遇到的挑战也越来越大。而当时，公司的架构师一通瞎搞，净选一些非主流的方案，外面找的所谓的“专家”也不咋靠谱，满嘴跑火车……我就萌生了“去外面看看正儿八经大数据怎么搞”的想法。

当时市面上有两家做的不错的开源、数据方向的公司：A 和 B，因为 B 离家更近一些，我果断放弃了 A。

那会正是大数据如日中天的时代，我见到了很多用户例如招行、平安、微软等的如何使用大数据技术解决自己的业务问题；看到了 cloudera 和 hortonworks 两家hadoop 发行商是如何合并，以及大数据如何开始走向疲软的；也见证了云原生数仓时代 snowflake 的上市以其股价是如何逆天的。

随后，clickhouse 如火如荼，mpp 技术又重新证明了自己，带动着数据库玩家们开始跑步进入大数据、数仓赛道。而 k8s 也逐渐成熟，云原生已然势不可挡，hadoop生态的大数据技术的正慢慢退潮……不管愿意与否，我都成为了大数据时代的亲历者、见证者与被审视者。

如今，正逢大数据技术更新换代之际，我意识到，如果不想和一些“过时”的大数据技术一样被淘汰，势必要【走出围城】，换个角度进行思考与探索，这也是我做“太可研究所”的初衷。

所以，从今天开始，我将带着自己大数据多年的从业经验和围城外的视角，与大家复盘大数据的兴衰历史，探寻那些穿越周期的技术与消失在洪流中的身影，分享对于不同技术背后的思考。

在我看来，大数据体系中最重要的的内容由四部分组成，分别是存储、计算、资源调度、数据目录 Catalog。后续我也会按照这个顺序一一探讨，今天的主角是存储技术。

Vol.1

提及存储这个词，不同背景、阅历的同学都有各自的理解，在大数据领域，存储可以分为以下几类技术分别讨论：分布式文件系统/对象存储、存储格式、数据库/数据仓库、数据湖。

这 4 类技术彼此存在着密切的关系，通常要相互配合才能构建一个完整的存储系统：

以 HDFS/S3 为代表的分布式存储作为大数据存储的基础架构，用于存储大规模的数据文件。

列式存储格式（如 Parquet 和 ORC）用于对大规模数据进行高效的存储和查询，至于为什么会使用列式存储会在后续的章节进行详细分析。

数据库/数据仓库用于存储结构化和半结构化数据，是面向业务用户的接口，内部会视情况选择合适的存储格式和分布式存储。

数据湖架构同样也是面向业务用户的接口，但与数据库不同，数据湖更强调开放的数据格式、灵活的数据访问，但交互式分析能力较弱。

其中分布式存储在其中扮演着核心的角色，通过它的演进我们可以将存储技术的发展进程串联起来。
如果以 Hadoop 的诞生作为大数据技术兴起的标志，那么，从 2007 年起，大数据存储技术便发生了巨大的变革。虽然其中的很多技术已经显得稀松平常，但这些技术的诞生实实在在地改变了技术、产品、乃至我们的生活。在这段时间，大数据存储技术经历了从传统数据库系统到云存储和分布式存储的转变，同时也涌现出了许多新的技术和工具。不妨梳理一下大数据存储技术发展的主要里程碑：

伴随着大数据存储技术几乎同步发展的，还有云存储。这两者从一开始就选择了不同的路径，彼此之间既竞争又融合，目前技术趋势已经统一在云存储、存算分离方向上，Hadoop 生态圈的一系列技术纷纷逃离 Hadoop、拥抱云原生，新兴的技术也在积极拥抱云原生，只是把 HDFS 作为一种 legacy 技术去做兼容。

Vol.2

大约 10 年前，伴随着移动互联网的野蛮生长，数据量开始飙升，最先受到这个问题困扰的是 Google。很快，Google 就发了三篇论文，但是由于种种原因 Google 也只是发了论文。后续无论是开源生态的繁荣还是云存储的市场，都和 Google 关系不大。

反倒是没什么负担的 Yahoo 内部的一拨人按照论文实现并开源了 Hadoop，Hadoop 的三驾马车 Yarn、MapReduce、HDFS。后来，资源管理的 Yarn 几乎被 k8s 取代了，分布式计算的 MapReduce 早就被 Spark 等技术淘汰了，只余下 HDFS 还在发挥着余热。

HDFS 的架构比较简单，是主从模式，早期版本通过多副本（一般是 3 副本）的方式实现了数据的高可用，后来加入了纠栅码能力节约存储资源。HDFS 还有一系列优势，例如高可靠、高容错、高吞吐、数据本地性等。然而，HDFS 还是没落了。

有这么几点原因：

第一，运维过于复杂。这不单单是 HDFS 的问题，是整个 Hadoop 体系的问题。举个例子：Hadoop 生态喜欢把配置文件分发到客户端，这就导致想要做配置变更、集群扩容、升级非常麻烦。此外，在搭建 HDFS 集群时，需要提前规划好集群的容量，否则后期扩容时会非常棘手。

第二，扩展性问题，尤其是 NameNode 的扩展性。由于 NameNode 是单点（虽然有主从模式保证高可用），而且整个文件系统的元数据都会存在 NameNode 的内存里，如果在集群搭建时给 NameNode 没有充足的内存资源，会使得整个集群文件量上限很低，也会严重影响 HDFS 的吞吐。而且 NameNode 作为集群的核心几乎不能出问题，否则整个文件系统会不可用，而 HDFS 是大数据生态的核心，一旦不可用，整个大数据系统就会停止工作。

第三，也是往往被人忽略的一个原因，那就是开发者的使用体验。开发者需要很懂 HDFS 的原理、配置，甚至早期只能使用 MapReduce 框架才能写出合格的程序，这非常劝退想把 HDFS 用好的开发者。

之前我们也提到云存储是跟大数据同时代兴起的技术，云存储产品包含对象存储、文件存储、块存储等技术，但在大数据/数据库体系里被拿来替换 HDFS 的，就是以 S3 为代表的对象存储。

从 2006 发布开始，S3 就以其低成本、可扩展性、高可用性、管理使用简单的特点吸引了很多应用开发者使用，用来存储图片、视频、文档等非机构化数据。随着 AWS 等云厂商的发力，开发了一系列软件包用来替换 HDFS，以及其真的能解决很多 HDFS 的痛点，尤其是随着存储成本进一步降低，存算分离的概念逐渐深入人心，像 HDFS 这类存算混合的方案渐渐没有了新引力。近几年很多新兴的云原生数据库、消息中间件直接就将对象存储作为了其存储介质，跨过了分布式文件系统这个过渡阶段。

当然 S3 也有其不可回避的各种问题：

第一，查询延迟性能问题。由于要跨网络并且使用的是 Http 协议访问，很容易造成延迟过高。

第二，早期版本的最终一致性问题。具体表现是写完一个文件后无法立刻查到，要等多久才能查到也是无法预期的，这造成了很多产品迟迟无法从 HDFS 生态迁移到 S3，在 2021 年时 S3 终于发布了新版本尝试了最终一致性的问题。

第三，限流问题。S3本质上是一个 SaaS 云服务，出于自保护、成本、收费的考虑，有一系列限流的规则，可能会出现用着用着突然系统变慢了的情况。这就需要开发者在使用时小心规避这类坑。

第四，不是一个完整的 POSIX 文件系统。当然，S3 在设计之初也没想过要支持完整的 POSIX 接口，只是大数据和数据库的开发者会不自觉地把之前的习惯带到云原生存储的使用上。习惯的力量是可怕的，像文件 rename、list 目录、获取目录大小这些在文件系统上轻量级的操作，使用 S3 之后会很慢。

第五，各个云厂商的接口很割裂。虽然各个云厂商都有类似 AWS S3的对象存储接口，但是每个都有自己的特色，切换云厂商的时候势必要针对性的适配。

以上这些问题也都有相应的解决方案，例如 JuiceFS 希望解决延迟、最终一致性、文件系统这类问题；OpenDAL 想帮助开发者屏蔽各个云厂商的差异；Alluxio 想帮助用户加速文件访问等。

现在回过头来看，S3 能战胜 HDFS 的原因有很多：存储价格下降、云厂商的大力推动、扩展性方面的原因，但最大的问题还是成本。保有一套 HDFS 系统不仅需要购买大量的物理机器，还要维护一个专业的运维团队，最终效果也不一定多好，对于很多公司来讲不是一个划算的事，相反按需购买、价格透明、可用性高达 11 个 9 的对象存储成为了更优的选择。

讲到这里，相信各位对于分布式文件系统/对象存储已经有了更深的了解，在后续的文章中我将继续详解存储格式、数据库/数据仓库、数据湖，可以期待一下（微信关注 【太可研究所】（techinstitute）了解更多）。

引用

• https://www.techtarget.com/searchdatamanagement/definition/Hadoop-Distributed-File-System-HDFS

• https://www.programsbuzz.com/article/limitations-hdfs

• https://www.enterprisestorageforum.com/management/object-storage-vs-posix-storage-something-in-the-middle-please/

• https://www.integrate.io/blog/storing-apache-hadoop-data-cloud-hdfs-vs-s3/

• https://jethro.io/hadoop-hive

• https://www.tutorialspoint.com/hbase/hbase_overview.htm

• https://data-flair.training/blogs/hbase-pros-and-cons/

• https://blog.cloudera.com/apache-hbase-i-o-hfile/

• https://www.databricks.com/discover/data-lakes

• https://www.dremio.com/blog/comparison-of-data-lake-table-formats-apache-iceberg-apache-hudi-and-delta-lake/