一文了解数据库vs数据仓库vs数据湖

大家好，我是K&D，一名10年以上大数据架构&研发经验从业者，目前主要从事云原生大数据方向设计，擅长云原生技术、数据架构、数据平台构建、大数据组件性能调优

以下是本文目录：

• 什么是数据库？

• 为什么会有数据仓库？

• 拆解几个OLAP核心概念

• 大数据技术架构演进过程

• 什么是数据湖？

• 数据库、数据仓库、数据湖：哪个更合适？

什么是数据库？

数据库这个概念相信大家其实都不太陌生，无论是做应用服务还是做App开发，或者说是大数据开发、运维开发都会多多少少对数据库这个定义有自己的理解。

在计算机课程刚入门时，除了最基本的编程语言之外，最最最重要的就是数据库的学习，通常都是学习Mysql或者是SqlServer（我当年的入门教程），但是当时只知道是用来存储数据的，仅仅知道一些CURD的操作，对于什么索引、视图、游标等等都不太了解，导致后来在数据库优化方面踩了不少坑，幸运的是这些在工作中都慢慢的填补了。

随着工作经验越来越多，所接触的技术栈也越来越广泛，在之后的数据库选择中，才得以了解到了更多更广泛的数据库类型，比如：

1. 客户端开发：通常会选择Sqllite数据库作为进程级别的数据存储使用，当年做window C/S应用选择的就是Sqllite

2. 服务端开发：服务端开发通常就是Mysql、SqlServer、mongodb等等这些作为主流选择，一旦涉及到性能问题之后，会做一些分库分表、数据缓存、视图、索引优化等等，优化手段都能够写好几篇文章了 ：)。

3. 缓存类型：主流地位的就是redis，至今都无法撼动其在应用级别数据缓存的影响地位。

4. 时序类型：redis也是K/V类型数据库，但是其承载数据量有限，这里的K/V类型数据库更多是大数据量下的，比如InfluxDB、OpenTSDB、Promethues等等，通常用于时间序列下的数据查询和检索，比如监控运维场景

5. 分词检索类：相比提到分词，Elasticsearch的地位没有能够与其竞争的，其高性能的数据读写，支持多个分词算法，用于关键词检索、搜索等场景遥遥领先。

当然，上面罗列的都是大众能够熟知的数据库类产品，还有一些IOT类型数据库、OLAP/OLTP类别数据库、图数据库、文档类数据库等等，种类相当繁多，基本上每一种数据库都用于解决特定场景下的某些问题，没有一个数据库是能够解决所有问题的， 所以，这也是为什么数据库类型的创业公司如此之多的原因之一。

开头有讲到，数据库起初是用于应用级别（PC端、服务端）的数据进行存储的，一般数据量都不会特别的大，最多几千万条就已经很多了，那么到时候做个分库分表、索引优化也能扛住能用，毕竟从数据量、并发量上都不太大。

所以说，起初数据库的应用场景非常简单，就是针对结构化数据存储的集合，对外提供数据的查询和检索，并且它是一种具备事务性的操作。单个数据库通常而言，一般只和单个应用程序或者业务进行关联，这时候数据库是不具备大量数据分析的能力的，如果要经常性的从业务数据库中跑很多ETL的分析查询语句，那数据库就会有很多慢SQL查询、内存会暴涨（别问我怎么知道的），压根就查询不出来。

这种基于事务性的结构化数据存储，从ACID以及数据完整性上都有一定的保障能力，我们称之为OLTP（联机事务型数据库）比如Mysql、PostgreSQL等，OLTP的特点是实现插入、更新、删除等事务的在线处理，但系统需要保证事务的完整性，满足ACID原则。支持OLTP的数据系统通常无法满足大规模数据读取与处理的需求（这种称之为OLAP），二者对数据读取的吞吐量要求相差不止一个量级。

为什么会有数据仓库？

其实，数据仓库和数据库本身在起初技术选型上面没有什么差异性，数据仓库的概念基本也是随着数据业务衍生出来的，只不过数据仓库更多的是定义了模型和集市的概念，底层的技术实现还是基于数据库的技术，最早在Hadoop还没有那么普及的时候，很多公司也有数据分析、数据模型的业务场景的，只不过那时候数据量比较小，可能仅仅一个Excel表格就能够满足，所以，当初更多的是总结出了不同业务场景下抽象出了模型架构图。

除了模型定义之外，从数据角度来看，数据仓库最早使用于多种数据源的数据进行集中存储的一个介质，从组织层面构建一个数据库仓库，然后独立的部门来进行统一提供数据报表的分析，根据业务现状提供相关数据能力支撑。

创建数据仓库是一个很繁琐的过程，需要提前规划好很多设计阶段的工作，提前检查数据结构、设定/抽象数据模型、抽取业务数据、然后进行建模分析，这些流程至今在大数据场景下依旧是没有任何实质性的改变，依旧是作为数据仓库开发者面试必备的能力之一。

拆解几个OLAP概念

上面有提到OLTP和OLAP，OLTP是联机事务处理系统，OLAP表示是联机分析处理，一个事务应用、一个分析处理，OLTP特点是简单易用、支持用户数少、存储数据量有限、面向应用服务的一种数据库，OLAP是偏向于决策分析、存储数据量比较大、支持多维度的复杂分析查询、面向主题/模型的数据仓库。

下面来拆解几个OLAP类型数据库相比OLTP类型数据库几个典型特点（为什么能够处理大数据量的原因），因为涉及的面还比较广，单单从分布式系统理论层面就有很多技术点，本文更多的从数据仓库层面来讲解几个核心设计点，如果想要了解更多，可以关注公众号KubeData，后面会陆续输出更加详细的内容讲解

01：OLAP分区技术

分区其实不算是一种技术能力，更简单的理解算是一种数据管理的方式，类比于，我们在进行数据库查询时，通常根据WHERE条件，后面加一个时间区间范围，来查询某个时间段内的数据，分区的概念其实逻辑上是一样的，只不过在数仓（Hive）里面分区是一种物理分区，不同的分区数据是在独立的HDFS目录中存储的，所以，当我们进行数据查询分析的时候，数据扫描的范围是在某个目录下，而不是整个库的全目录，比如：

select * from orders where partition = ‘2023-12’ ；

那么真实的数据存储的目录结构是

/usr/hdp/hive/warehourse/partition=2023-12

/usr/hdp/hive/warehourse/partition=2023-11

/usr/hdp/hive/warehourse/partition=2023-10

......

等等，这样的话，数据处理的数量会小很多，所以，一般情况下，在数据仓库设计中，原始数据层（src）通常会按照天来进行分区，一方面是进行数据回溯区分，另一方面就是通过分区的方式来减少每次数据处理的量级，就不会每次都加载搜索所有历史日期的数据了。

当然，分区的设定可以灵活来定义，比如可以按照Hash方式、业务线名称、数据类别等等都可以，分区处理通常也是数据仓库里面的一个小优化点。

02：OLAP多维分析

【维度】：维度这个概念对于做数仓的同学应该都不陌生，维度简单来理解就是你从那个角度来看待数据，比如我关心的是昨天订单量，那么维度就是昨天、订单ID，比如，我要看上个月的产品售卖情况，那么维度就是月份、产品名称，再简单的理解就是BI控制台中的所有下拉框的选择。

通常，我们在数仓分析等时候，绝大多数都是多维分析处理，因为作为商业智能分析系统，需要从多个层面多个维度来考量数据，从而抓出业务需要优化的点来，那个产品那个日期售卖情况比较好或者比较坏，根据这些数据结果来调整售卖策略等等，多维数据分析也叫Cube模型，就是类似一个魔方，不管我们从那个角度来看，都应该看到一些交叉多个维度聚合的值。

【指标】：上面提到维度，通过不同的维度选择所展现出来的值，就是指标，比如我关心的是昨天订单量，那么维度就是昨天、订单ID，指标值就是根据昨天的某个订单ID得到的数据值就是指标，通常来讲，指标是一个可以量化的数值。

【上卷和下钻】：这个如果你经常在电商网站选择商品的话，其实就很容易理解了，比如我们在选择商品时，默认是推送了所有品类的商品（服装、电子设备、图书、玩具等等），当我们选择服装之后呢？又会有男装、女装、童装，在选择男装之后呢？又会有衬衣、外套、羽绒服等等，那么这个过程就是一个不断下钻的过程，一直钻到最小粒度的维度为止，通常而言，这是一个由大到小、由粗到细的过程。下钻理解之后，那么上卷就是比较好理解了，上卷就是不断减少维度，逐步变大的过程，你可以把上面电商示例反过来理解就是上卷的过程，上卷通常就是由小到大、由细到粗的过程。

其实，OLAP还有很多其它概念，比如星型模式、雪花模型、大宽表、拉链表、维度建模等等一些设计范式，还有一些关于数据仓库的技术架构实现，比如MOLAP、ROLAP、MPP计算引擎、预处理计算等等，后面我们再进行详细讲解，因为本文不是主要介绍数据仓库细节，所以就不多加描述了，更多的让大家了解一些数仓基本概念。

MOLAP、ROLAP、MPP并行计算、预处理技术我会放在单独的文章中输出，

大数据技术架构演进

在大数据混部的第一篇文章中，有讲到大数据架构的演进过程，这里有兴趣的可以看一下大数据混部中介绍，这里我摘取核心内容，在讲解一下，便于我们后面理解数据湖（其实上一篇也简单提到了数据湖）。

在以离线数据仓库架构为代表的大数据处理中通常是以Hive、MapReduce、SparkSQL、FlinkCore等批处理技术，来做一些ETL的处理和离线分析作业，通过数据采集器将数据导入到离线数据仓库中，然后再进行数仓分层和建模，来满足大批量数据的定期处理需求，通常架构图如下：

随着整个大数据技术的发展，以Sparkstream为中心的微批处理技术逐步满足了当时大部分的实时性场景需求，于是，大数据团队基本上都在将一些离线计算作业迁移到微批处理中，比如原来T+1（T代表当天）才能够看到的报表数据，通过微批处理之后，几秒钟就可以看到了，而且还能实时在大屏中滚动着用户付费金额等信息，那老板们看着是相当得意。

于是乎，在这个时候大数据架构发生了微妙的变化，当初由图一的纯离线计算架构，慢慢的延伸出一条以微批计算的

处理链路，同时在整个数据处理架构中通过分布式消息队列Kafka来做中间数据的传输，这种架构我们也称之为Lamda架构

在Lambda架构中，基本上对于准实时作业和离线作业都在混跑在同一套集群中的，当时一方面是没有拆分集群的诉求，因为大部分都是在原有集群上演变来的，不会有什么资源干扰，另一方面当时Hadoop Yarn功能还没那么丰富，还不支持联邦调度和标签队列的配置，这些基础功能不满足的话，上面计算任务很难做到拆分，当然单独拆分一套集群出来是一种做法。

既然提到了Lamda架构了，那就再简单介绍一下Kappa架构，Kappa架构应该是当下应用最广泛的一种架构模式，它的诞生主要是大家对实时性的需求越来越多，而且随着千人千面、万物推荐、广告营销类场景下这种架构可以满足80%以上的实时场景，与此同时，大数据团队就开始探索如果将离线数据仓库改为实时数据仓库那效率岂不是提升了一大截，于是，以Flink为代表的批流一体计算引擎结合以Kafka和Pulsar为代表的高性能分布式消息队列引擎，开始大规模的实行实时数仓，基本架构如下：

从上面两种架构图来对比，可以看到Lambda和Kappa架构的区别就在于流处理这块，Lambda是流处理+批处理，Kappa是完全流处理模式，同时，这两种架构在部分的场景下也可以混合来使用，比如说去掉了微批处理，由流处理结合批处理这时候就可以同时处理离线数仓和实时数仓的场景，基本的架构设计如下：

其实，细心的观察会发现，在整个架构演进过程中不仅仅是离线、实时两个计算场景的演进，在存储层也在不断演进，从最开始的单纯离线数仓以结构化存储为主、后来实时+离线数仓存储以流+结构化存储为主，再后来计算和存储分离，计算层更加轻量化，而且计算天然是无状态的，存储可以灵活的选择不同的介质，所以，整个数据存储以半结构化、结构化为主。

什么是数据湖？

上面简单聊了一下数据库，稍微介绍了一下数据仓库的内容，因为篇幅原因很多东西就不再一一展开介绍了，读者朋友如果有兴趣的话，可以关注本号，后续会持续输出相关内容

数据湖概念算是近些年比较火热的概念了，关于数据湖的定义网上有很多，这里摘抄自aws关于数据湖的一段定义：

数据湖是一个集中式存储库，允许您以任意规模存储所有结构化和非结构化数据。您可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析 – 从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策

注意上面定义中几个核心关键词：存储库、所有结构和非结构化数据、支持不同类型的分析、多种不同的分析场景

这几个概括性的语句，我觉得基本含括了数据湖的定义（至少从我个人理解层面），那我们就要思考一下了，为什么突然出现数据湖呢？数据库满足应用服务了、数据仓库满足了大批量数据分析了，OK，稍加总结思考一下，我们从两点来看：

第一：数据湖定义的是存储+非结构化+更多场景需求，存储就不多说了，本质上也是一种数据存储类型，非结构化和更多场景需求在于，我们前面提到的数据库和数据仓库满足的更多是业务场景，单个企业内部的运营系统，再或者就是应用推荐、广告分析这种偏向于特定属性的场景。

但是，对于物联网数据、车联网数据、人工智能和机器学习类数据，这种结构化属性非常弱，数据有着大量的字段定义，而且随时都在发生变化，这种场景下要进行分析梳理，而且要保留长周期的数据内容，方便进行长久数据的机器学习训练，数据仓库显然是满足不了的。

第二：存储成本的压力问题，数据仓库的数据目前大多数还是以HDFS这种分布式文件系统的方式存储在本地的，随着不断增长的数据规模，日益增长的业务场景（AI、机器学习）下多模态分析俨然已经成了某种主流场景，所以需要一种低成本、廉价的存储系统来解决存储成本问题和多模态业务分析问题，而这时候基于对象存储会慢慢成为主流的存储介质（或者其他基于对象存储衍生出来的一系列存储介质），对象存储的成本存储相比于本地存储一方面是不需要考虑副本数的问题，另一方面对象存储的单位价格相比云盘价格要低7-10倍，也不需要担心存储空间扩容、缩容的问题，通过按量付费的方式用多少收取多少钱，也可以将存储进行归档冷存，这样更加进一步的降低了存储成本。

数据库、数据仓库、数据湖如何选择？

在实际工作中，我们应该如何选择使用OLTP数据库还是OLAP数据仓库还是数据湖呢？有些同学会追求时髦前沿技术，不管业务需求是什么样的，直接就上数据湖架构，这样其实是一种不负责任的表现，单纯的以自己实践为主，业务需求为次的行为。这时候就需要架构师来评估具体业务的场景以及未来发展（2-3年）来看，最适合的架构模型是哪种，而不是直接就上新技术，一般技术在2-3年会有一个迭代周期，你无法保证现在选择的技术栈未来看就是最优的。那么我建议从以下几个方面来进行选择：

【数据结构类型】

有多少数据源、数据的格式、结构的可预测性、数据一致性等等都是重要的考虑因素。数据湖接受非结构化数据，而数据仓库只接受来自多个来源的结构化数据。当只有单一的结构化数据源并且在规模上有限制时，数据库的性能最好，反之，如果是非结构化的数据源并且规模上无法评估时，数据湖会比较好。

【数据处理类型】

数据管理策略中包括理解数据模型是什么以及何时需要定义数据模型的过程。数据湖提供了存储原始数据(包括所有元数据)的灵活性，并且在提取要分析的数据时可以应用模式。数据库和数据仓库需要将原始数据转换为预先确定的结构(也称为写时模式)的ETL过程。

【数据存储成本】

大数据为企业提供了商业价值，但是企业也会考虑整个数据管理的成本，随着数据量的不断增加，存储成本也相应增加。数据湖在成本上是最有效的，因为它以原始形式存储，而数据仓库在处理和准备要存储的数据以供分析时占用更多的存储空间。数据库可以根据需要向上或向下扩展。

【数据最终使用者】

无论最终用户是业务分析师、数据科学家还是业务操作人员，都将决定什么对公司有意义。如果主要用例是为运营团队提供业务洞察和报告，则数据仓库将满足他们的需求，但设置和存储数据的成本较高。数据科学家可能更喜欢数据湖，因为他们想深入研究新的人工智能和机器学习算法，并喜欢访问结构化和非结构化数据的混合。业务分析师可能精通SQL，并且只需要为业务的一部分创建趋势报告，因此关系数据库是最好的选择。

【开源社区】

对于目前我们绝大多数人选择的都是基于开源软件生态来构建的，对于不同的开源软件背后都有对应的社区支持，不同技术社区从活跃度、技术架构、支持力度等等都不同。数据湖之所以流行，是因为Hadoop的广泛采用，以及来自公司使用的各种系统和实时数据流的非结构化数据的增加。要考虑的另一个技术方面是当数据源和结构发生变化时更新系统的可访问性和保真度。更新关系数据库和数据仓库的成本更高，而使用数据湖进行更改则很简单。

---