《数据密集型应用系统设计2》--数据系统对比：OLAP/OLTP，数仓/数据湖/数据湖屋

这篇文章是《数据密集型应用系统设计2》读书笔记的一部分。
目前包含的文章有：

• [数据系统对比]：本文
• 数据的存储与查询
• 数据复制与数据分片
• 事务一致性和隔离性

数据密集型应用设计这本书介绍了分布式应用中使用的各种组件的基本原理，包括如何衡量系统性能、数据库存储与索引、复制和分片、事务、一致性等内容。通过这本书可以大致了解不同组件的基本原理和多种实现方案，进而便于我们进行技术选型。

数据系统对比与基本概念

在开始选型和实现之前，首先我们要确定我们所要设计的系统的大致特征。数据系统可以从多个角度对比

• 在线操作系统（OLTP），还是分析系统（OLAP）：前者通常是数据的产生方，通常进行点查询，数据操作的数量少、延迟低，比如购物网站的用户下单、支付时产生的数据；后者通常在额外的数据副本上进行，进行大批量的范围查询，数据操作的数量大、延迟高，比如购物网站数据科学家可以在长达一年的订单数据上进行分析，找到某种商品销量的季节性特征。
• 基于云（cloud）的方案，还是自己管理（self-host）服务资源：
  • 基于云：有时候也称为PaaS（Platform as a service），IaaS等，简而言之就是租用云服务提供商的云服务。云服务提供商比如阿里云等可以提供开箱即用的服务器或者数据库等服务，开箱即用意味着在很短时间（<1h）内就可以开始使用，同时提供完善的安全、管理、扩缩容、多区域部署等功能。
  • 自己管理：自己购买服务器、安装数据库等基本软件，自己申请IP地址、域名等网络资源……
  • 混合方案：通常公司都是混合云和自己管理的方案，比如将繁杂的硬件网络管理任务交给云服务商，而自己管理应用程序等核心功能。
• 分布式系统还是单节点系统：分布式系统具有很强的横向扩展能力，通过添加机器就可以提高系统容量，但是系统复杂性较高；单节点系统通常在一台机器上运行所有组件，好排查问题但是性能上限很低。

后续会详细介绍OLTP&OLAP系统的对比和概念，其它对比角度由于较好理解，故而略去。

OLTP vs OLAP

基本概念

通常在找工作时学习的八股都是OLTP系统的组件和特性，这是因为OLTP和产品功能直接相关，发展得最早、岗位最多。通常我们提到以下一些词时，都是在描述OLTP系统：高并发、双11、抢票、后端开发、点查询。但随着产品功能逐渐完善，产品的重心就逐渐成为发掘用户行为，找到下一步的发展方向。这时OLAP相关的操作就开始增多了。OLAP通常和以下一些词相关：分析、数据工程师、大数据、报表、离线、批处理。

最开始的数据处理系统都以OLTP为主，因为OLTP是应用运行必须的组件。随着时间的发展，各家公司不仅要让产品能运行，还需要分析用户行为来指导产品设计，以在未来的竞争中占据上风，因此分析的需求也逐渐增加，慢慢演化出了OLAP系统。

最早开始OLTP和OLAP都在同一套存储中进行，但是这样会造成很多问题，比方说OLAP的大批量操作会影响OLTP系统性能。所以慢慢地，就将OLTP系统产生的数据传输到OLAP的专用组件中处理，发展出了数据仓库(Data Warehouse)，数据湖(Data Lake)，数据湖屋等(Data Lake House)等不同的OLAP系统。

关于OLTP系统，由于大家都了解得比较多，不过多赘述。除了《数据密集型应用设计》笔记这种系统性介绍的系列之外，我有一些与特定知识相关的文章，如果希望深入了解可以参考一下：

• 缓存-变更事件捕捉、更新策略、本地缓存和热key问题_本地缓存更新
• 深入理解事务一致性和隔离性

而OLAP系统的概念比较多，因此接下来介绍OLAP系统的大致发展历程。与OLAP系统相关的文章有：

• 维度建模工具箱 提纲与总结：主要介绍数仓建模的方法论
• Apache Iceberg：TBD
• Pinot：TBD

OLAP的三个发展阶段

我们通常会听到一些和OLAP有关的概念，从系统层面上说主要有数据仓库、数据湖、数据湖屋。这一节我们详细介绍这三种OLAP系统的概念

数据仓库

广义的数据仓库可以指的是数据存储、处理、展示的一整套解决方案，既是数据的“仓库”，也可以一站式地处理数据；而狭义的数据仓库指的是从OLTP数据库中分离出来，单独处理OLAP负载的组件。当提到数据仓库时，需要明白它代表的到底是哪种含义。我们这里说的是狭义的数据仓库定义。

数据仓库最主要的特点是，延续了SQL数据库的“关系模型”(ration model)，也就是说数据模型(data model)依然没有任何变化，只能处理结构化(structed)数据。这样就造成了数据仓库能存储、分析的数据有限，很难处理半结构化数据（比如JSON）和非结构化数据（比如纯文本、视频音频）。比方说，在目前的AI时代，如果想要分析用户的对话信息；想处理用户发送的图片等，这些信息就不适合用数据仓库存，通常还得辅助其他的文件存储（比方说对于图片，存储的是url而不是图片本身）。

除了数据模型之外，数据仓库还有一些缺点，比如底层数据存储格式通常是私有的、与执行引擎强耦合，很难与第三方软件集成；计算和存储节点通常也捆绑在一起，不能根据负载类型独立调整存储或计算节点的数量。但是也正由于这种强耦合，数据仓库的性能通常很高，而且更好提供原子操作功能。

数据湖

数据湖就是类似于HDFS这样的文件存储（File store, 有时也叫object store/blob store）系统，就像一个网盘一样（只是像，但实现绝对完全不同）。既然是文件存储系统，那就能存储各种各样的文件格式，不论是结构化数据、JSON还是录音，图片等。但是应该也看得出来，数据湖只不过提供了存储，而解析文件，分析数据等，都需要额外的程序才能进行（数据仓库起码可以直接执行SQL来计算指标）。所以很难说相对于数据仓库来说，数据湖到底是一种正向的进步，还是一种倒退。它们更像是互相补充的关系。

在数据湖刚萌芽时（基本就是google发布GFS论文的时候），网络传输速率比较低，通常会在持有数据的节点上运行计算程序，也就是说每个节点既要存储数据，也要负责所存数据的计算。因此最初一代的的数据湖系统的存储和计算引擎也是相互耦合（但是起码用户可以自定义逻辑来处理非结构化数据），比如第一代HDFS系统，用户需要使用HDFS提供的Map-Reduce接口来编写数据处理逻辑；后续发展出的Hive计算引擎，也是利用Map-Reduce编程模型来在HDFS上跑SQL。

随着软件技术的进步和网络传输速率的飞速发展，专门负责计算的引擎也开始流行，比如Spark、Flink等，都可以从各种各样的数据源中读取数据并转化为内部格式进行高效处理，最后写回存储引擎。由于计算程序不会跑在存储节点之上，计算节点和存储节点之间的数据传输都要依靠网络。

虽然数据湖强调什么数据都能处理，但是结构化数据的存储也有很大发展，比如出现了像parquet这样的列存储格式，它在OLAP场景下可以提供比行存格式更好的性能。

数据湖屋

这个词的中文翻译很拗口，因为它是俩英文单词拼一起的结果。数据仓库是Warehouse，数据湖是Data lake，数据湖屋有点像是运行在数据湖上的数据仓库，用户可以利用自带的SQL引擎高效处理结构化数据，也可以使用自己喜欢的工具（比如pyspark）处理非结构化数据。所以这俩词拼一起，出现了data lake house这个词。英文中有很多把俩词拼一起成为新词的情况，比如大家熟悉的早午餐(Brunch)。

不过话说回来，虽然理论上数据湖屋可以处理非结构化数据，但是其功能重心还是结构化数据的处理，因为非结构化数据都是用户自己编写的逻辑，也没有可优化的空间对吧？所以在常见的数据湖屋系统，如微软的Fabric中，通常对于非结构化数据的处理只会介绍“在一个地方处理所有类型的数据”，而对结构化数据则提供了从实时计算、SQL分析、报表集成等一条龙的解决方案。

为了支持“全都要”（All in One）的口号，除了存储和计算引擎，数据湖屋通常还有以下几个部分，以支持在数据湖这种文件存储系统之上运行SQL计算：

• 数据目录：存储了数据湖屋中有哪些表，表的格式、表的存储路径等。这样存储引擎通过查询数据目录，就可以找到表底层的文件，进而将执行的SQL语句转化成对文件的读写。
• 表格式：表是关系模型中的抽象概念，SQL对表进行读写，最终还是要转化为对实际文件的读写。因此在执行SQL和读写文件之间，还需要定义表格式。常见的开源表格式有Delta Lake，Iceberg等，它们基于Parquet文件来构建表。其中Iceberg可以通过原文件+记录变更的方式，来给通常不支持随机插入/修改的文件格式之上加上增删改查功能；也可以记录额外metadata（比如哪些范围的数据存储在哪个文件中），来帮助存储引擎根据查询语句来减少读取的文件块，进而提高性能。

OLAP发展阶段总结

从上面可以看到，这三种组件各有特征，因此不要被一些比如“XX将要成为历史，XX才是未来”这样的观点误导，至少目前来看每种方式都有其存在的理由，并没有哪种方案可以完全取代另一种方案——即使某种方案在性能上完胜，那在大规模使用时还要考虑“成本”这一因素，比如SSD性能上秒杀HDD，但是SSD的价格也是HDD的好多倍，因此在数据中心中，HDD还是占据主要地位。在我们团队的一些项目中，我们选择了ClickHouse数据仓库来做实时计算，因为它支持实时计算DISTINCT COUNT。我们通常要先明确系统的功能需求，再确定要使用哪种方案。