上回说到,我决定走出大数据的围城,用另一种视角审视与复盘行业。
文章发出后收到很多读者的反馈,其中呼声比较高的一条是希望我能聊聊大数据的行业前景与思考。针对这个问题,后面我会分享一些自己的经验与思考,同时,也会邀请来自各个大厂及正在相关方向创业的朋友做客太可研究所(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文章来源:https://www.toymoban.com/news/detail-788903.html
-
Comparison of Data Lake Table Formats | Dremio Blog文章来源地址https://www.toymoban.com/news/detail-788903.html
到了这里,关于还在做 Hadoop 生态?那我祝你一帆风顺的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!