引言

大数据这个概念，对于普通人来说，是一个比较模糊的概念。大数据如果指的是很大量的数据，那么很大量的标准是什么呢？我第一次真实体会到“大数据”，是有一次我在我的电脑上打开了一个500MB的Excel表格，那种绝望的感觉我至今都忘不了。表格打开之后，电脑直接卡死了，过了可能有一分钟鼠标才可以动，我拖了一下表格之后，电脑又卡死了...这是最直观的感受到“大数据”的体验，但是500MB属于大数据嘛？不同场合下可能有不同的回答，对于当时的我来说，那肯定是“大数据”了。

对于企业来说，每天生产的数据量可能是TB级别的（1TB=1024GB），甚至还能到PB级别（1PB=1024TB），企业理解的大数据是TB或者PB甚至更大数据量级的数据，这么大量的数据，放在一台电脑做分析是难上加难（想想看你的电脑有多少存储空间）。这也就催生了大数据这个概念，它的目标就是低成本且高效的处理如此巨大的数据。

大数据时代不可避免

数据存储发展

现在的电子设备配备500GB甚至1TB的存储空间是常有的事情，我们仍然会抱怨不够用。回顾一下历史上存储容量的发展史，可以说当今的存储容量，对于50年前来说，可谓是海量。从下图可以看到，60多年来硬盘尺寸在缩小，存储容量却快速增大。从MB级、GB级和TB级分三个阶段跃升。第一阶段（1956～1991年，35年时间）：硬盘容量在MB量级提升；第二阶段（1991～2007年，16年时间）：硬盘容量在GB量级提升；第三阶段（2007年以后）：硬盘容量超过了1TB，在TB量级提升。目前市场上已有容量为10TB的硬盘销售。

图片源自网络

我们可以看到，存储容量在不断的上涨，这也意味着我们对于数据存储的需求在不断上涨。

作为一个普通用户，我们并不觉得我们能消耗很多的存储，1个TB的容量足够我们用很久。但是在科研和商业领域，每天记录的数据可以说是海量，需要更有效的方式对数据进行存储。

如何组织数据

随着数据存储介质存储容量越来越大，成本越来越低，我们可以存储的数据量也越来越多，科学家们开始思考如何高效的在计算机上管理和计算数据。1979年，E. F. Codd发表的《A Relational Model of Data for Large Shared Data Banks》论文给我们带来了未来数据管理的基本思路：“用户无需知道数据在计算机中的组织形式，只需要通过简单的语句既可以查询和更新数据。数据是有关系的n元组，对数据操作也基于数据的关系。”这便是关系型数据库的理论基础，其对于数据的组织形式类型表格形式，如下图所示。

当我们把数据组织好，也收集到了大量用户的行为数据之后，下一步我们的任务就是进行数据分析。但是，随着数据量级越来越大，关系型数据库的分析能力成了瓶颈，一个简单的业务指标分析不仅计算慢，还有可能把影响到线上运行的服务。关系型数据库不是为了数据分析而生的，我们需要另寻出路。

1991年，Bill Inmon出版了《Building the Data Warehouse》，为我们带来了数据仓库（Data Warehouse）的概念。他在文中提到当前的分析体系种种问题，比如数据存储分散，不同的数据表可能相同字段有不同的含义，数据分析程序过于定制化等等，需要有一个中控一般的数据仓库能力，来集成运行环境中的相关信息，以此提供更强大、统一的数据分析能力。

2011年，James Dixon提出了一个新的大数据架构——数据湖（Data Lake）。在传统的数据仓库中，集成的数据需要预先定义好数组的组织形式，而他认为，数据不应该是预组织的模式。在实际情况中，我们可能一开始并不知道数据的价值，也没有能力回答一些还没发生的问题。所以数据湖的湖意味着将数据直接存储起来，在要回答问题的时候，通过湖里的数据组织来回答该问题。这意味着，流入数据湖的数据可以是半结构化和非结构化的数据，相比于数据仓库来说，数据组织的成本低。但是流入数据湖的数据不像数据仓库那么的干净，对于BI（Business Intelligence，商业智能）来说就不那么容易接受。

Databricks于2020年提出数据湖仓（LakeHouse）的概念，就是为了更好地解决数据湖数据质量的困境。在低成本的数据存储上提供高质量的数据。这个概念相对较新，还在接受市场的检验中。

技术还在不断的发展，还会有更多的惊喜等着我们去创造。

OLTP到OLAP

上面讲完了数据的组织模式，接着我们从另一种角度来看大数据的场景，数据的处理模式。处理模式主要分为OLTP（Online Transaction Processing，在线事务处理）和OLAP（Online Analytical Processing，在线分析处理），分别关注数据的更改和数据的分析。

早期，在关系型数据库理论的支持下，OLTP（Online Transaction Processing，在线事务处理）成为了电子商务的一种主要模式。电子商务系统的设计，基本就是前端应用负责提供页面操作，搭配后端服务负责数据计算逻辑，再加上数据库支持数据存储和修改的模式，这一套下来就是最标准的OLTP业务。OLTP讲究的是数据处理高效和稳定，就比如一个电商系统，用户的下单一定要顺滑，支付金额数据也不能出问题。

到了20世纪80年代，随着互联网的发展，商业数据就已经突破了TB甚至是PB级别。OLTP关注的大都是近期的部分业务，所有可以有一些技术手段保障数据处理的可靠高效。但是对业务数据分析的话，则需要对历史很长一段时间内所有数据进行统计，很多企业面临如何分析这种量级数据的困境。数据资产被认为是21世纪的石油，能够从数据从发现问题就具备了更多主动权。面对这种困境，E. F. Codd在1993年提出了OLAP（Online Analytical Processing，在线分析处理）概念。OLAP关注于在线大规模数据的分析能力。E. F. Codd提到“企业的兴衰取决于其信息系统的复杂程度和处理速度，以及使用这些系统分析和综合信息的能力。企业需要执行更复杂分析的需求正在增长。”

围绕着OLTP和OLAP的相关技术仍在不断的更新，也是系统设计里常被人津津乐道的话题。

谷歌的三篇论文

直到21世纪初，围绕大数据的很多思考，仍然停留在理论上。谷歌在2003年先后发表的三篇大数据领域开创性论文，为大数据相关技术的落地提供了重要指导。这三篇论文在大数据背景下，分别从如何存储数据、如何计算数据以及组织数据为我们带来了思路。

如何存储数据

要存储TB、PB级别的数据，存储介质的费用是一个很大的问题。要提出一个让市场认可方案，对涉及到的设备的性能和成本要求一定是要做到尽可能的低。2003年，谷歌发表了《The Google File System》就给出了思路：在廉价的商业设备上建立一个数据可分布式存储、操作性能高效的文件系统。

核心是分而治之的思想。假如你有一个1TB的文件，那么谷歌文件系统要做的就是，按照64MB为一个文件块进行拆分，再按文件块的形式存储到谷歌文件系统里。谷歌文件系统是由很多运行的服务器组成，每个服务器管理部分文件块。由于为了防止因单个廉价的存储设备出故障，倒是其存储的数据完全丢失，每一个文件块还需要有3个备份，存在不同的存储设备中。

看看下面这张图架构图可以加深一下理解。谷歌文件系统的架构是由客户端（client）、一个主节点（master）和多个块服务器（chunkserver）组成。存储在谷歌文件系统的文件会被分割成固定大小的文件块（chunk，64MB），每个文件块由主节点分配全局唯一不变的块标识（chunk handler），文件块会被存储在块服务器的本地磁盘上，通过块标识和读取范围来进行读写操作。为了保证服务的可靠性，同一个块会有3个分布在不同块服务器的副本做备份。

有了这套文件系统，我们就有能力应对大数据的存储了。

如何计算数据

光把数据存起来，没法使用数据来进行分析，那这些数据也没有什么价值。对于大数据的分析，难点就在于数据太大了，一台服务器根本无法计算。既然一台无法计算，那就多加几台。2004年，谷歌发表了论文《MapReduce: Simplified Data Processing on Large Clusters》也给出了相应的思路：将数据计算分成Map和Reduce两步，将计算任务分散到每个服务器去计算。

核心的思想依然是分而治。我们都喜欢用word count任务来举例，word count任务就是统计文件中每一个词出现的次数。假如你有一个1TB的文件，要统计里头每个词出现的次数，首先类似谷歌文件系统，这1TB的文件需要先拆分成小文件，这些小文件存储在不同服务器上。接下来告诉这些服务器，对其上的小文件进行单词统计。然后将统计的结果进行汇总即可。汇总的数据也可能是一个超大的文件，所以依然会被拆分成小文件存储。

可以借助下面这个图来更直观的理解一下MapReduce过程。MapReduce是一个思想，把计算能力打散了。一台机器算不了，那我们就把任务拆分了，分散到多台去做计算，最终把结果一汇合就是我们想要的结果。这样既把计算能力分散，同时还减少了网络传输数据的成本，一举两得。

暂时无法在飞书文档外展示此内容

论文对MapReduce过程进行了更详细的解释，整体过程简单来说1初始化程序；2分配map/reduce任务；3执行map任务；4在本地存储map任务的中间数据；5reduce任务拉取map任务中间数据后执行reduce任务，6将结果写入文件里；

有了MapReduce的思想，我们就具备了能够对大数据进行简单的计算分析能力了。

如何管理数据

相比于前两个能力，谷歌于2006年发表的论文《Bigtable: A Distributed Storage System for Structured Data》属于锦上添花的能力。BigTable借助了谷歌文件系统作为底层的数据存储能力，在其之上，构建了性能更强分布式存储系统。它不像关系型数据库严格限定了表结构，而是可以动态的调整数据格式。

关键的几个概念就是行，列族和时间戳。行用于标识一行的数据，如com.cnn.www。列族则列式存储的核心，列族通常是列：限定词组成，也就像下面anchor是其中一列，它的限定词有cnnsi.com和my.look.ca，限定词可以随意增加，因此列式存储数据可以动态的调整。时间戳是用于数据版本记录。

从理论到落地

有了谷歌3篇论文的理论基础，开源市场开始跃跃欲试，潘多拉之盒已经打开。

Hadoop崛起

说到大数据，基本上都会带一嘴Hadoop，Hadoop生态为大数据提供了很多很多有价值的工具。Hadoop更重要的贡献，就在于它最早完整实现了上面提到的谷歌文件系统、MapReduce和BigTable，并免费开源。

其中HDFS对标Google File System，MapReduce对标MapReduce，HBASE对标BigTable，观察这些组件的架构，可以看到他们基本上和谷歌论文提到的架构一致。

Hadoop架构

HBase数据表格

技术的潮流始终在变更，当时的弄潮儿MapReduce如今看来有些过时。令人庆幸的是，Hadoop不仅仅是一个支持MapReduce的中间件，围绕MapReduce搭建的生态系统反而脱离了MapReduce，变成了更通用的技术组件。直到现在，Haddop生态中的HDFS、YARN、Hive、Zookeeper等项目仍然是市场的宠儿。

Spark闪耀

Hadoop给我们一个实现大数据处理的案例，但是大数据处理是不是只有这么一种模式？有没有更好的模式我们还没有发现呢？Spark给了我们另一个答案。

2014年一篇测试Spark和Hadoop对100TB数据排序任务的性能对比中，Spark仅用了Hadoop1/10的资源，但速度却比Hadoop快了3倍。Spark论文开篇就提到了当前当前其他框架存在的问题，即他们对于内存的利用严重不足。已Hadoop举例，MapReduce任务中每个任务计算的数据都会存储到HDFS上，每个任务执行都要读写磁盘导致的性能的裂化。

Spark是如何利用内存的？他们提出了一个RDD（Resilient Distributed Datasets，弹性分布式数据集）的概念，（吐槽一下这个名字，很难知道它到底想说些什么），RDD存储在内存，是一个只读的分布式数据模型。也就是把要计算的数据和计算的结果都存到内存中。

与此同时，Spark的编程模式不再是MapReduce的思路，而是Transformation和Action。Transformation是将一个RDD转化成另一个RDD，也就是数据的转换。Action则是将一个RDD计算成一个结果值或者存储到磁盘中。这么划分操作模式是为了更好的容错，如果一个RDD出现了故障，Spark可以知道通过哪些Transformation来恢复这个RDD。

一个小小的思想改变，却在性能上有了很大的提升，节省了大量的时间和资源，还省了不少电。更重要的是，这让Hadoop看起来有些过时了。

批处理困境

我们看到了Hadoop和Spark在大数据领域作出的贡献，当然在这个领域中肯定是不止有两个技术组件，只不过他们凭借自己出色的能力脱颖而出。然而人们不满足于当前的大数据处理模式，因为数据处理起来太慢了。为什么说慢呢？从上面的介绍可以看出来，Hadoop和Spark都是对数据分批进行操作，也就是批处理。但是在部分现实的场景中，对于数据实时的处理要求更高，如果数据都要堆积直到满足一个批次的数量时才会被处理，那延迟肯定是高的。

能不能更实时的完成数据处理呢？

数据处理再快一点

流式处理

在离线数据处理中，是通过批处理来完成大数据的处理。随着企业的发展，越来越多公司希望数据处理能够更加的实时且高效，而不是隔一段时间才能看到数据处理的结果。如何能更快一点？

我们重新思考一下数据的组织形式，对于批处理来说，数据是有边界的（bounded），比如每批数据是64MB，那我们就会有一个64MB的存储数据块来存放这些数据，等数据块存满之后，才会去处理。而这个边界是我们人为划分出来的边界，在现实中的很多场景，数据是没有边界的（unbounded），比如地铁乘车的人流，我们应该怎么去定义边界？每分钟，每小时还是每天？定义边界反而成为了不严谨的事情，倒不如抛开边界这个框架，把数据的组织方式类比成一条河流，是一个无边界并随时间不停流动的数据流。

就像下面这张图，bounded stream（有边界的数据流）就是我们认为定义的数据边界，而实际上，这些数据应该被认为是unbounded stream（无边界的数据流）更加合适。

如果我们直接处理数据流，是不是可以做到实时的获取结果呢？

Storm风暴

2011年开源的Storm模式相对简单，数据如同水流一样，那就把数据处理的水管接入到水流上。因此Storm的处理模式如下，spout是流入数据的入口，bolt则对数据加工，整个构成了一个Storm拓扑结构。Storm拓扑结构中每一个任务是始终运行的，支持了其实时处理数据的能力。

同时Storm提供时间窗口的能力，可以统计一定时间范围内的数据，如果过去10秒内的成交量等。

Flink小松鼠

Flink的执行流程相比于Storm可以明显看到多了一个状态。Storm属于无状态计算框架，即每一条数据都认为是独立的，互不影响。而Flink提到，有一些操作是需要跨多条数据进行，因此需要记录相关的信息，这就是状态的含义。如需要聚合每分钟的成交量，那么聚合过程中的信息就属于状态。状态机制给开发者提供了便利，使用Storm则需要开发者自己实现状态管理。

流批一体

流处理实时性这么好，那我们只保留流处理能力是不是就可以了。当然不是的，流处理和批处理适用的场景不一样。批处理更适合做如“统计过去5年内每个月成交量”这种跨度长、数据量级巨大的任务。而流处理更适合对数据实时性有要求的场景，比如“过去5秒的成交量”。

我们已经提到了流处理、批处理，既然都是在做数据处理，是不是有一个工具可以统一起来？不少团队开始做流批一体化，比如flink。

数据管理

数据仓库

在最开头我们介绍了数据仓库，在企业内把数据集成起来，统一输出业务数据和业务指标，更高效的制作报表，制定决策。数据仓库也有相应的规范体系，比如数据仓库分层，不同层的数据关注不同的数据质量和数据权限。

目前比较火热的数据仓库还要属Hive和ClickHouse。

Hive小象蜜蜂

Hadoop提供了HDFS存储大数据，MapReduce分析大数据，但是都需要一定的编程能力才能够使用。而大部分大数据从业者是数据分析师，比起编程他们更熟悉SQL。Hive对Hadoop的能力进行了包装，提供了类似SQL的HiveSQL能力，只要会写SQL就能够非常容易的进行大数据分析。

当提交一个HiveSQL，Hive引擎会将HiveSQL解析成MapReduce任务并执行，这极大的提高了生产力！

ClickHouse

同样是数据仓库，ClickHouse有着不同的理念。通常我们对数据进行计算的时候，只会对数据的几列进行计算，比如说今天的营业额是多少，只需要累加金额数据那一列就足够了。以往的行式存储，为了几列数据，会把相应的行数据都扫描再提取对应的列。ClickHouse是一个列式存储模式的关系型数据库，同一列的数据存储在相近的位置，那么提取同一列的速度会明显优于行式存储。这种差异也取决于服务不同的应用场景。

数据湖

数据湖因其数据的灵活性理念，备受市场关注。目前数据湖相关的产品不多，比较有热度的要属Hudi。

Hudi

Hudi作为数据湖的热门产品，被越来越多公司使用。前面提到的Hive，常作为h+1，t+1的数据仓库，但对于近实时数据存储不是首选的组件，因为其数据更新非常低效。Flink等流式计算引擎关注的是计算而不是存储。近实时的大数据同步存储没有一个好的解决方案，这时候Hudi出现了。Hudi的upsert机制解决了数据更新的问题，使其更好的进行数据更新和增量同步。