从这篇文章开始，笔者打算写一个系列《clickhouse专栏》，它的全称是ClickStream，DataWareHouse，简称ClickHouse。从全称中的“DataWareHouse”可以看出，clickhouse的定位是数据仓库。那么“数据仓库”和“数据库”有什么区别呢？理解这一点非常重要。了解了两者的区别后，就可以在其合适的应用场景中正确使用clickhouse了。一、OLTP和OLAP在理解“数据仓库”和“数据库”的区别之前，我们需要先解释一下两个名词，即：OLTP和OLAP。OLTP（on-linetransactionprocessing）联机事务处理：通常是指面向传统应用服务的关系型数据库。用户通过Web界面对数据库中的数据进行实时的“增、删、改、查”操作。包含核心的基本事务处理逻辑。用户对性能有很高的要求。用户点击界面后，要求最短响应时间在5秒以内（一般3秒以内），需要支持比较高的用户并发。OLTP的数据操作通常是面向一条或几条小数据，比如：用户下单操作用户的购物车、支付记录、积分记录等小量数据。OLAP（On-LineAnalyticalProcessing）联机分析处理：面向应用，主要是进行复杂的数据分析操作，侧重于决策支持，通过图形化报表显示直观易用的数据分析结果。对响应时间要求比较宽松，数据分析过程通常不支持用户高并发，但数据分析结果支持用户高并发访问。OLAP通常面向批量数据操作，批量导入和分析数据。OLAP系统通常与ETL（提取、转换、加载）系统结合使用。理解了以上两个数据，剩下的就简单多了。数据库通常面向OLTP操作，数据仓库通常面向OLAP操作。OLTP侧重于保存和改变数据的当前状态，而数据仓库侧重于保存数据的历史归档。例如：用户银行转账，OLTP数据库重点管理用户活期账户余额，以及转账过程中打入对方账户金额的数据一致性；而OLAP数据仓库则侧重于记录谁进行了转账，转了多少钱，转了哪里。历史上用户是什么时候转账的，是月初还是月底？一个月转几次？二、数据仓库的特点以下是数据仓库的一些典型特点：注重记录数据变化的过程，而不是数据的当前状态。多读，少写，大表宽表批量数据，不更新或很少更新，不支持事务一些工作经验比较少的朋友看了这些文章会说：“这不是特点，是缺点！”.不更新或者很少更新，读多写少都是场景。大而宽的表破坏了数据库设计范式。不支持事务是什么数据库？其实在OLAP场景下，这些恰恰是其为了保证数据分析的性能而特殊设计的特点。我举几个例子：比如某云厂商会定期收集服务器运行指标，比如内存使用率、CPU使用率等。这些指标是批量采集，批量存储的。一旦存储，它们将不会被修改。通常情况下，内存指标不用建表，CPU使用率不用建表，而是同一个机房??的服务器建表。该表包含了时间维度上的各种指标。比如查询内存使用率>80，CPU使用率>70的服务器时，两张表之间不会有关联查询，只能查询一张宽表，数据分析的性能会大大提高改善。不支持事务，通常OLAP系统是不支持事务的，因为事务会在一定程度上影响数据操作的性能。数据入库后，需要对这些指标进行不断的分析和挖掘，也就是多读少写，基本上是一次批量写入，后续进行读数据操作。又如：实时的股票交易数据，关注的是记录数据变化的过程，而不是数据当前的状态。所有股票的所有历史数据一旦进入数据仓库，就不会被修改。可以进行量化的股票交易分析。又如：用户商品点击数据、用户操作行为数据、用户网页浏览时间数据等，这些数据都是用户分析所需要的数据，一旦存储就不会被修改。可以分析用户的买卖意愿。事实上，这种类型的数据还有很多其他类型。这类数据的特点是：数据量大，产生后不会改变（那个时间尺度的数据不会改变）。因此，数据仓库通常面向高吞吐量的历史数据归档，不进行更新和删除操作。数据归档后，通常只面向数据的查询和分析。3、数据库和数据仓库的结合通常是一个比较大的应用服务系统，它既包括数据库又包括数据仓库。数据库为用户进行在线交易处理，处理用户界面的实时操作。数据仓库的数据面向决策管理，提供数据和图形报表，提供各种数据分析和决策。上图是一个典型的数据库和数据仓库共存的应用服务场景。互联网用户通过应用服务产生用户行为，对数据库进行OLTP操作。应用服务将用户的操作行为发送给消息队列，消息队列将数据导入数据仓库。数据库中的数据可以通过ETL进行提取、处理、转换，并集成到数据仓库中。决策分析系统主要对数据仓库进行数据分析。数据分析结果可以反馈到数据库，并为互联网用户提供通过应用服务查看数据分析结果的能力。决策分析系统同时，为应用服务的决策管理者，提供数据分析和决策支持能力。推荐阅读仅限于博客文章的长度。更多精彩内容我就不一一列举了。推荐阅读《原创精品视频及配套文档：springboot-已录制97节(免费)》等
