现代工程界普遍认为，数据库系统大致可以分为联机事务处理（OLTP）和联机分析处理（OnlineAnalyzeProcess，OLAP）两种针对不同领域的数据库，OLAP数据库也称为数据仓库。在产品上，有面向OLTP的数据库，如MySQL、PostgreSQL、Oracle等，也有面向OLAP的数据库，如Hive、Greenplum、HBase、ClickHouse等，也有统一的尝试TiDB和OceanBase两种HATP（HybirdAnalyzeTransactionProcess）系统。表1-1列出了OLAP和OLTP之间的一些比较。近年来，随着技术的发展，OLAP和OLTP的界限也越来越模糊。几年前，OLAP数据库不支持事务。近年来，出现了一些支持简单事务的OLAP引擎。ClickHouse也将简单的事务支持包含在Roadmap中。另外，随着分布式技术的发展，一些OLTP数据库也可以处理更大的数据，甚至厂商推出的HATP数据库直接打破了两者的界限。▼表1-1OLAP与OLTP比较OLAPOLTP使用数据仓库事务数据库，数据容量大，小到PB级、GB级，有的可达TB级。交易能力弱（或没有）。分析并发数低，数据质量比较低，数据来源比较低。各个业务数据库和业务系统OLAP和OLTP的功能越来越一致，以至于在某些场景下，OLAP和OLTP可以相互替代。这是否意味着原来的分类方法失败了呢？将来是否不需要数据仓库或事务数据库？ClickHouse的极致性能优化能否促进OLAP与OLTP的融合？回答这些问题需要弄清楚OLAP和OLTP分类的性质。OLTP数据库在进行数据库设计时使用实体-关系模型（Entity-RelationshipModel，E-R模型，简称ER模型）。ER模型的建模过程中有一个非常重要的归一化过程。规范化的目的是通过一系列手段使数据库设计符合数据规范化（NormalForm，NF）的原则。简单地说，归一化就是将数据表从低范式转变为高范式的过程。一般来说，OLTP中数据通常被归一化为第三范式（3NF）。1.数据的三种范式范式的概念在标准化过程中经常用到。数据库理论中有6个范式。下面选取三种常用的范式进行简单介绍，以方便读者理解后续内容。1.第一范式第一范式是指表中的每个属性都是不可分的，满足上述条件就满足第一范式。表1-2给出了一个不满足第一范式的例子。由于本例中的标签词还可以细分为性别、年龄、是否为VIP用户等多个属性，因此不满足第一范式。▼表1-2不满足第一范式的用户标签表2、第二范式第二范式是建立在第一范式基础上的。当表中的所有属性都由主键的所有部分唯一确定时，满足两种范式。表1-3给出了一个不满足第二范式的例子。在此示例中，用户ID和标签ID构成主键。标签名这两个属性只依赖于标签ID，用户所在的位置只依赖于用户ID。这些属性都不依赖于由用户ID和标签ID组成的主键。因此，不满足第二范式。删除标签名称和用户位置可以使表满足第二范式。▼表1-3不满足第二范式的用户标签表3、第三范式第三范式是基于第二范式的。当表中的属性不依赖于除主键外的其他属性时，即满足第三范式。范例。表1-3中，sourcename不满足第三范式，因为sourcename依赖于sourceID，所以需要删除sourceID。表1-3标准化后的合格数据表应如表1-4和表1-5所示。▼表1-4合格用户标签表▼表1-5合格用户信息表4.所有第零范式不满足第一范式的情况称为第零范式。表1-2显示了其中一种情况。数据库理论中对零范式没有严格的定义。由于作者在本书的写作过程中经常使用零范式的模型设计，所以在本书中，除非特别说明，零范式是指存在Map或A类数组结构的表。这种“第零范式”的表设计具有一定的实际意义，笔者的作品中也经常使用这种设计。灵活应用这种第零范式可能会产生意想不到的结果。2、标准化的意义一般要求在设计业务数据表时，至少需要设计第三范式，避免数据冗余。从表1-3中不难发现标签名和源名的冗余。冗余不仅增加了数据量，更重要的是，冗余的存在会影响数据库事务，降低数据库事务性能。表1-6显示了一个不合格的表设计。请注意最后两列。很明显这是一个不满足第三范式的设计。表中最后一列“requirespermission”用于设置数据权限，表中的数据表示第一行和第三行需要admin权限才能查看。正常情况下是没有问题的。如果业务发生变化，需要将授权级别“2-非公开”权限同时更改为admin和manager。对于这种需求，如果采用表1-5的设计，需要进行全表扫描，修改数据表中所有授权级别为2的数据，会严重降低数据库的性能。▼表1-6影响事务性能的表结构数据库规范化的意义在于通过规范化减少冗余，提高数据库事务性能。正是基于这样的考虑，在数据库表的设计中，需要对数据表进行标准化。3.标准化的局限性任何架构都有其优势，但也必然有其局限性。这同样适用于规范化数据表。规范化的数据表可以减少冗余，从而提高事务性能。同时，规范化的数据表无法支持分析。以表1-3至表1-5为例，表1-4和表1-5为表1-3归一化后的合格用户标签表。如果需要根据用户所在城市进行年龄分布统计，不能单独使用表1-4。表1-4和表1-5必须连接（join）得到新的表进行分析。在大多数数据库系统中，与查询相比，连接操作的过程相对缓慢。4.数据仓库建模的本质通过前面的分析，我们可以得出一个推论：高范式表适合事务处理，低范式表适合分析处理。从中，我们可以得出数据仓库建模的本质：反规范化。数据仓库建模本质上是一个反规范化过程，将规范化的数据从原始业务数据库中恢复到一个低范式的过程中进行快速分析。在实际建模过程中，数据仓库经常提到的宽表，本质上是一种低范式表。宽表将所有关联的列整合到一张表中，以供日后分析。这样做的好处是所有相关信息都在这个宽表中。理论上，分析不需要join操作。由于可以直接进行相关分析，提高了分析速度。这样做的缺点是数据冗余，难以支持交易能力。大多数数据仓库都是基于低正态数据集进行优化的。读者在使用OLAP引擎时一定要时刻牢记这一点，避免直接使用OLTP数据库中的原始高正态数据进行OLAP分析，否则可能会影响分析效果。不太好。相反，应该通过反规范化的过程将高规范化数据集还原为低规范化数据集，然后通过OLAP进行分析。5、OLTP和OLAP的底层数据模型OLAP和OLTP的本质区别在于底层数据模型的不同。OLAP更适合低范式的数据表，而OLTP更适合高范式的数据表。不管它们的功能是否越来越相似，只要它们的底层数据模型不同，它们之间的差异就会一直存在，结构决定功能。ClickHouse是一个面向OLAP的数据仓库。很多优化都是面向低范式数据模型的，而高范式数据模型并没有得到很好的优化。甚至在某些场景下，ClickHouse的join能力会成为整个系统的瓶颈。ClickHouse更适合处理低范式数据集，尤其是第零范式数据集。ClickHouse对第零范式数据集做了更多的优化。6.维度建模在使用OLAP进行数据分析时，需要对原始数据进行维度建模，然后进行分析。在维度建模理论中，数据仓库是基于事实表和维度表构建的。在实际运行中，一般采用ODS（OperationalDataStore，操作数据存储）层、DW（DataWarehouse，数据仓库）层、ADS（ApplicationDataService，应用数据服务）层三层结构。1、ODS层ODS层一般作为业务数据库的镜像。在项目中，数据仓库工程师通常会使用数据抽取工具（如Sqoop、DataX等）将业务库的数据复制到数据仓库的ODS层进行后续建模。ODS层的数据结构与业务数据库保持一致。之所以建立ODS，是因为通过复制一份数据到ODS层，可以避免建模过程中直接访问业务数据库，从而影响业务数据库，避免影响线上业务。2、DW层将数据导入到ODS层后，可以对ODS层的数据进行清洗和建模，最终生成DW层的数据。生成DW层的本质就是本章提到的反规范化过程。由于ODS中的数据本质上是业务数据库的副本，所以ODS中的数据属于高标准数据，不适合做OLAP分析。这也导致需要在OLAP分析之前将高范式ODS数据反规范化为低范式数据。低范式数据作为DW层的数据对外提供分析服务。在反规范化的时候，可能会产生一些中间结果，而这些中间结果也可以存储在DW层，所以有时在DW中又会细分，分为DWD（DataWarehouseDetails，数据仓库明细）层，DWM（数据仓库Middle，数据仓库middle）层，DWS（DataWarehouseService，数据仓库服务）层三个更细分的层次。ODS层的数据清洗后存储在DWD层。DWD层本质上是一个去除脏数据的高质量、低标准的数据层。DWD层中的数据聚合形成宽表，保存在DWM层中。DWM层已经是一个低范式数据层，可以用于OLAP分析。在某些场景下，DWM层的数据可以重新聚合，以支持更复杂的业务。此时需要将生成的数据保存在DWS层。在三个细分的DW层中，并不是所有的场景都需要完整。DW层的本质是对高范式数据进行反规范化，生成低范式数据的过程。读者只需掌握这个核心即可。在实际的维度建模过程中，根据业务的实际需求进行建模。没有必要在所有场景都死板地遵循DWD层、DWM层、DWS层三层。建筑学。3.ADS层ADS层保存数据结果供业务使用。DW层的数据可用于OLAP分析，但分析过程通常较慢，不能支持实时业务需求。所以需要引入ADS层作为缓存向上支撑业务。同样，ADS层也不是必须的，需要根据实际业务来选择。ClickHouse的高性能计算引擎可以在一定程度上替代ADS层。ADS层数据本质上是面向业务且高度业务化的数据。可以认为是基于DW层的分析结果，很多时候是指标、标签等的计算结果。本书后续内容中使用术语ADS时，如无特殊说明，是指基于DW层分析的业务结果。本文节选自《ClickHouse性能之巅：从架构设计解读性能之谜》，经发布者授权发布。作者简介：陈峰，资深大数据专家和架构师，ClickHouse技术专家，地扑科技（2B领域独角兽）合伙人兼首席架构师。
