还在做 Hadoop 生态？那我祝你一帆风顺

上回说到，我决定走出大数据的围城，用另一种视角审视与复盘行业。

文章发出后收到很多读者的反馈，其中呼声比较高的一条是希望我能聊聊大数据的行业前景与思考。针对这个问题，后面我会分享一些自己的经验与思考，同时，也会邀请来自各个大厂及正在相关方向创业的朋友做客太可研究所（techinstitute），相信届时可以解答各位的一些困惑。

言归正传，在上篇文章中，我带领大家梳理了存储的定义、发展历程及分布式文件系统/对象存储技术。今天我将继续分享存储的其他关键技术——存储格式、数据库/数据仓库、数据湖，忘记前文的朋友可点击《2024 年，一个大数据从业者决定……》 复习。话不多说，存储技术 2.0 篇，直接开盘！

Vol.1

有了分布式存储解决了能不能存的问题之后，下一步就是怎么存的问题。使用哪种存储格式，取决于用户的使用场景，没有一个放之四海皆准的结论。正所谓没有没用的格式，只有没用的场景。

在早期大数据生态中，大家都是用纯文本例如 csv 存储数据，甚至有不少同学使用自己拼接的字符串存储，相当野蛮。这就带来了很多显而易见的问题，例如存储效率不高，没有很好地使用压缩，读取时性能差，文件缺乏解释性很难复用。

所以，2013年左右，当时两家著名的 Hadoop 发行商 Cloudera、Hortonworks 相继推出了自己的列式存储格式 parquet 和 orc, Cloudera、Hortonworks 这两家公司的恩怨也随着 Hadoop 技术的退火消散在了历史中，他们恩怨纠葛需要单独写一篇文章来讲。

列式存储的优势现在看来也不是什么高科技的东西，但是在当时确实大大加速了分析效率。列存的优势是压缩率更高、查询时可以裁剪、支持灵活的 schema、对并行计算友好。

当然，列存也不是全是优点，例如不适合频繁的更新、不支持随机访问、写入性能差等，这就让列存天然地适合分析场景，所以列存现在成了几乎所有 OLAP 数据库、数据湖的标配，但 OLTP 数据库几乎不会使用列存。

无论是文本格式的 csv 还是列存的 parquet，都是开放、标准的存储格式，有大量的生态兼容，小 A 生成的 parquet 文件交给小 B 使用，是完全没问题的。但是大量的数据库、数据仓库出于性能、稳定性、兼容性等种种原因会使用自己独有的存储格式，这些文件只能通过对应的数据库读取，用户只能通过数据库的 API 访问数据。这也就是数据库和数据湖两类技术本质上的不同，一个更强调性能，一个更强调开放。

Vol.2

HBase 是 Hadoop 生态中绕不过去的技术，虽然从现在视角来看，它有这样那样的问题。

HBase 是构建在 HDFS 之上的数据库，数据模型类似于 Google 的 Bigtable，旨在提供对大量结构化数据的快速随机访问。HBase 的历史可以追溯到 2006 年 11月，当时 Google 发布了 BigTable 的论文。2007 年 2 月，HBase 的最初原型做创建。同年 10月，第一个可用的 HBase 与 Hadoop 0.15.0 一起发布。2008 年 1 月，HBase 成为 Hadoop 的子项目。2010 年 5 月，HBase 成为 Apache 的顶级项目。

从上述过程不难看出 HBase 和 Hadoop 深深地绑在了一起，是一荣俱荣、一损俱损的关系。Hadoop 生态有的问题像运维复杂、扩展困难、故障排查难等，HBase 一样不少，甚至 HBase 的存在会加重这些问题。但是，在 10 年代的前几年几乎没有更好的方案，能够同时满足高速查询、写入、海量数据、可扩展这些能力。

再结合之前讨论的存储格式，很多同学肯定会好奇：HBase 既能满足高速的写入又能高速的查询，它用了什么格式。像 HBase 这类数据库一般会采用 KV 的存储格式，但又不是简单的 KV，而是自定义了一套 HFile 存储格式，并配套了一个存储引擎，包含索引、compaction、标记删除、内存表和磁盘数据管理等。虽然 HBase 技术逐渐式微，但它的设计理念深深的影响了其它分布式数据库，甚至现在还有几家云厂商把 HBase 魔改版本对外售卖。

与 HBase 同时代的还有 Cassandra，Cassandra 不在 Hadoop 体系内，是一个自成体系的数据库，实现了 Google BigTable 的论文。其最初由Facebook开发并开源，旨在解决大规模数据存储和处理的需求，具有高可用性、高性能和分布式的特点。2008 年开源，随后成为 Apache 软件基金会的顶级项目。

在 2010 年代的前几年，如果想找一个高扩展、高可用、又没那么在乎 ACID 和 SQL 接口的数据库，且不想维护 Hadoop 集群，Cassandra 是一个很好的选择，直到今天仍有许多大型互联网公司和企业在广泛使用，包括 Facebook、Instagram、Netflix、eBay 和 Twitter 等，比较有意思的一点是 Cassandra 在海外知名度还不错，在国内几乎没有声音。

相比于 HBase 的主从结构，Cassandra 的设计受到了 Google 的 Bigtable 和亚马逊的 Dynamo 论文的启发，采用了分布式架构和基于列的数据模型。Cassandra 使用了 P2P 的架构，整个集群没有 master 节点，基于 Gossip 协议实现的对等集群。这种设计的结果是放弃了强一致性，选择了可用性。此外,如果客户端想读到最新的数据需要满足 W+R>N 的条件，这里 W 是写入的副本数，R 是读的副本数，N 是集群的节点数。

2012 年，Google 发布了 Spanner 论文，随后 NewSQL 这个品类开始进入技术圈的视野，先后有两款产品分别是 CockroachDB 和 TiDB，这些新产品完全跟 Hadoop 体系没有关系，尝试使用新的思路解决大数据中结构化数据的存储问题，同时 NewSQL 又再次把 SQL 带回了正轨，再次证明了 SQL 才是结构化数据的真爱。至此，大数据和数据库两个生态开始互相竞争又融合，SQL 也再次成为了数据接口的标准。

Vol.3

大数据和数据库融合之后为结构化数据指明了方向，但大数据的范畴并不仅仅只有结构化数据处理的需求。

AI 技术的持续火热，使得大量半结构、非结构化的数据亟待处理。此外，AI 的数据使用场景并不仅仅是简单的求和、最大最小值这类的数值计算，而是更复杂的神经网络、矩阵、向量计算，这类场景几乎不可能用 SQL 表达，一定是通过 Python 或其他语言的代码来实现。而且 AI 的计算往往不是使用 CPU 而是用 GPU，这与数据库的设计又是南辕北辙。除了 AI 之外，分析领域也在快速发展，更灵活的数据使用方式需求量也越来越大，这就催生了数据湖技术。

数据湖技术从下到上依次是 对象存储 --> 存储格式 --> 开放的表格式 --> Catalog --> 计算引擎 和 存储引擎。其中最重要的就是开放的表格式技术和 Catalog，有了这两者其他计算引擎就能很自由的对数据湖进行操作。

目前主流的数据湖表格式有 3 个：Hudi、Iceberg、Delta Lake。三者各有优劣，有很多文章都对他们进行过详细的对比，参见 Comparison of Data Lake Table Formats | Dremio Blog。

无论哪项技术都对接了现有的 Spark、Flink、Doris、Clickhouse 等主流的计算引擎和 OLAP 数据库。尽管开放的表格式(Open Table Format)相对于列式存储(Column based Data Format)，从技术视角只是多了一层元数据和基于时间戳的事务管理，这个小小的创新却带来了质的飞跃。

在 Hive 的年代，数据库的元数据信息都存在 Hive 的 metastore 里，也就是存在 MySQL 里，可想而知随着数据表、分区、列、视图、用户等等这些元数据信息的爆炸，MySQL 就撑不住了。另一方面，当访问元数据的并发量增加 MySQL 的单点瓶颈也会凸显。而开放的表结构优势是把元数据和数据放在一起，使得数据可以自解释，把元数据也视为一类大数据，这样大大扩展了系统的容量，元数据服务不再是瓶颈，开发者也可以更自由地访问。

从数据湖技术的发展不难看到，有时候一些技术的小创新，如果找对了场景，可以释放相当大的应用场景。

Vol.4

至此，我们已经回顾完大数据存储技术的历史及其代表技术。持续不断地有新技术涌现，无疑对技术、产品、业务有着更大的价值，与此同时，有些技术也随着新事物的诞生而逐渐没落。

对于一线的开发者而言该如何选择？架构师在纷繁的技术栈里又该如何抉择？

没人可以给出一个标准答案，我们只能从历史中尝试总结一些规律，来帮助更多人做出选择：

• 云存储已经成为了事实标准，如果现在还有新人投入到 Hadoop 生态圈里，我只能送出真诚的祝福，并祝他一帆风顺。
• 开放大于封闭，目前来看没有一个技术能完全解决所有用户的所有问题，那么无论是哪种技术、哪种方案都要把生态、集成作为重点考察的指标。
• 分布式数据库和大数据融合，这两者的界限已经越来越模糊，机会还有很多。
• 与 AI 结合的场景还有广阔的空间，结构化数据处理已经卷成红海，而AI更注重非结构化、半结构化数据的场景，还有很大的空白，向量数据库这一细分品类的出现就是很好的例子。
• 批流结合，大数据技术中批数据和流数据有时是两套架构，甚至两套技术栈，很割裂，现在已经有很多产品想将两者融合，给用户提供统一的使用体验。

引用

• What is HDFS? Hadoop Distributed File System overview
• Limitations of HDFS
• Object Storage vs. POSIX Storage | Enterprise Storage Forum
• Storing Apache Hadoop Data on the Cloud - HDFS vs. S3 | Integrate.io
• Hadoop Hive and 11 SQL-on-Hadoop Alternatives | Jethro
• HBase - Overview
• HBase Pros and Cons | Problems with HBase - DataFlair
• Apache HBase I/O - HFile - Cloudera Blog
• Introduction to Data Lakes | Databricks
• Comparison of Data Lake Table Formats | Dremio Blog