Clickhouse在采油厂数据湖技术生态中的应用前景

摘要：在数据量日益增长的当下，传统数据库的查询性能已满足不了业务需求。近年来大量开源架构为探索流批一体实时数仓的大数据研发工程师提供了丰富的资源，同时也增加了工程师在学习成本、框架的多样化和复杂度等方面选择合适工具的难度。此情景下，整合开源框架、工具、库、平台势在必行。该文引入Clickhouse数据库管理系统，并在数字化油田构建实时数仓的建设中构想其应用前景。

关键词：OLAP;大数据;Clickhouse

中图分类号：TP3        文献标识码：A

文章编号：1009-3044（2022）21-0015-03

开放科学（资源服务）标识码（OSID）：

油田开发中后期，开采成本日益上升，为了降本增效以及提高整个企业的安全状况，物联网及数据工程师考虑依靠数据驱动油田，将大数据技术用于监控设备性能和环境条件。通过使用制造业和工程行业的先进技术，架设于设备上的传感器可以收集现场操作中的数据，并用于保障原油平稳安全生产的可行性分析[1]。未来数字化建设考虑数据中台，将原本存在各关系型数据库、实时历史数据库、非结构化数据库等的数据实时接入数据区域湖，区域湖再将不同类型的数据模型进行归一化处理，并且在数据分析平台提供统一的查询入口，再由油藏、采油工程师找到数据背后有价值的信息，在大数据中预测分析，指导生产。

而今，大量开源架构为探索流批一体实时数仓的大数据研发工程师提供了丰富的资源，同时也增加了工程师选择合适工具的难度，主要体现在学习成本、框架的多样化和复杂度。如Kafka、HDFS、Spark、Hive等大数据生态技术经过组合才能产生最后的分析结果。此情景下，整合开源框架、工具、库、平台势在必行。

面向智慧油田的数据管控体系主要研究在“采”“存”“管”“用”四个方面。

“采”：数据变更抓取系统，解决多源异构数据一致性的问题。相较于专注流程控制和中间处理过程灵活性但不追求性能的传统数据提取转换和加载系统而言，数据变更抓取系统对实时性要求比较高。

“存”“管”：数仓分层存储和维度表管理均由数据湖承担。

“用”：一个思路是将聚合分析计算由数据分析引擎承担。相较于Flink、Spark或者Storm，它的优点是自由度高，可以满足实时分析需求，减轻实时计算部分的聚合处理压力;缺点是必须要求消息队列中保存存量数据，且因为是将计算部分的压力转移到了查询层，对查询引擎的吞吐和实时摄入性能要求较高。

本文主要对基于数据分析引擎的云数据库管理系统Clickhouse在“用”的方面即查询分析方面做深入探讨。

1 Clickhouse概述

1.1 Clickhouse发展迅猛

Yandex在2016年6月15日开源了一个数据分析的数据库管理系统，即ClickHouse，它是分布式实时分析型列式存储数据库管理系统，主要用于数据分析领域。开源时间虽短，但是社区热度高，跑分超过很多流行的商业数据库软件。各个大厂纷纷跟进大规模使用。今日头条内部用ClickHouse来做用户行为分析，内部一共几千个ClickHouse节点，单集群最大1200节点，总数据量几十PB，日增原始数据300TB左右。腾讯内部用ClickHouse做游戏数据分析，并且为之建立了一整套监控运维体系。携程内部从2018年7月开始接入试用，目前80%的业务都跑在ClickHouse上。每天数据增量十多亿，近百万次查询请求。快手内部也在使用ClickHouse，存储总量大约10PB，每天新增200TB，90%查询小于3秒[2]。

1.2 为什么需要ClickHouse

为何ClickHouse获得了如此广泛的关注，得到了社区的青睐，也得到了诸多厂商的应用呢？

企业目前使用的传统关系型数据库在数据规模比较小、索引大小适合内存、数据缓存命中率足够高的情形下能正常提供服务。但残酷的是，这种理想情形最终会随着业务的增长走到尽头，查询会变得越来越慢。虽然可通过纵向扩展数据库来解决问题，通过增加更多的内存或者订购更快的磁盘等，但这只是拖延解决实质问题。

在未来数字化油田的实时数仓工作中，日志量剧增，虽然经过数仓的分层以及数据汇总层通用维度指标可以进行预计算，但有些个性化的分析场景还是需要直接编写程序或数据库查询语句，这种情况下hive SQL、spark SQL的查询性能也无法满足需求[4]。

（1）数据时效性：传统方案中只能拿到次天数据，但想要获得及时的实时数据，复合指标、多维度指标生成需要整个数据链路提供实时数据。

（2）通用指标体系：传统方案中只能针对每个分析对象创建一个结果表，但想要获得每个分析对象可支持所有指标，需要更适合的数据模型支持更多的分析对象[5]。

（3）灵活的数据分析：传统方案中只能“选择”“连接”“分组”，但想要获得无限制的交互式分析，获得自定义维度，需要跨数据库查询能力。

（4）大宽表：传统方案中窄表严格按照数据库设计三范式。这么设计为的是尽量减少数据冗余，但是缺点是修改一个数据可能需要修改多张表。为了查询性能的提高与便捷，在业务、数据提取转换和加载、指标属性、数据来源等角度来看，让高度内聚的属性、描述、度量放在一张逻辑上的数据库表中，这对于刷新效率、容错能力、扩展能力都是一个很大的挑战。以空间换时间，便于训练迭代、减少表关联数量，修改少量数据时不需要改多张表[6-7]。

在即将到来的大数据时代，面临的难题有三：计算和存储的成本、流水线式工作流程、高峰每秒查询率、95%的查询时间[5]。如果需求是解决怎样方便快捷地查询出结果，需要一个数据分析引擎。

1.3 ClickHouse建设架构

快是Clickhouse的最大优势，还有集群的扩展能力，相比hadoop套件也更容易部署，其核心都是围绕如何在数据分析场景下做到极致的快，在存储结构和计算并行上都有巧妙的设计[8]。

1.3.1 OLAP场景的特点

读多于写：

不同于事务处理场景，在原地进行大量增加、删除、修改操作，数据分析场景通常更加关注写入吞吐，要求海量数据能够尽快导入完成。一旦导入完成，历史数据往往作为存档，不会再做更新、删除操作。将数据批量导入后，再进行任意维度的灵活探索、制作报表等。

数据一次性写入后，业务人员需要尝试从各个角度对数据进行分析，发现业务变化的趋势。在反复试错、不断调整、持续优化的过程中，数据的读取次数多于写入次数。这就要求底层数据库为这个特点做专门设计，而不是盲目采用传统数据库的技术架构。

在数据分析场景中，通常存在一张或是几张多列的宽表（例如M科室做产能区块投产效果查询库，需要连续多年跟踪月产量，X科室做数据回迁视图时需要多表联合查询）。对数据分析处理时，选择其中的少数几列作为维度列、其他少数几列作为指标列，然后对全表或某一个较大范围内的数据做聚合计算。这个过程会扫描大量的行数据，但是只用到了其中的少数列，而聚合计算的结果集小得多。

1.3.2 ClickHouse存储层

ClickHouse从数据分析场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据分享、数据划片、数据生存时间、主备复制等丰富功能。以上功能共同为ClickHouse极速的分析性能奠定了基础。

1）列式存储

与行存将每一行的数据连续存储不同，列存将每一列的数据连续存储。相比于行式存储，列式存储在分析场景下有着许多优良的特性。

（1）在行存模式下，数据按行连续存储，所有列的数据都存储在一个数据块中，不参与计算的列在输入输出时也要全部读出，读取操作被严重放大。而列存模式下，只需要读取参与计算的列即可，极大地减低了输入输出消耗，加速了查询。

（2）同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本。更高的压缩比意味着更小的数据规模，从磁盘中读取相应数据耗时更短。高压缩比意味着同等大小的内存能够存放更多数据，系统缓存效果更好。

官方数据显示，通过使用列存，在某些分析场景下，能够获得100倍甚至更高的加速效应。

2）主键索引

ClickHouse支持主键索引，它将每列数据按照索引粒度（默认8192行）进行划分，每个索引粒度的开头第一行被称为一个标记行。主键索引存储该标记行对应的主键的值。

对于where条件中含有主键的查询，通过对主键索引进行二分查找，直接定位到对应的索引粒度，避免了全表扫描从而加速查询。

但是值得注意的是：ClickHouse的主键索引与MySQL等数据库不同，它并不用于去重，即便主键相同的行也可以同时存在于数据库中。要想实现去重效果，需要结合具体的表引擎ReplacingMergeTree、CollapsingMergeTree、VersionedCollapsingMergeTree实现。

3）数据TTL

在数据分析场景中，数据的价值随着时间流逝而不断降低，多数业务出于成本考虑只会保留最近几个月的数据，ClickHouse通过TTL提供了数据生命周期管理的能力。

1.3.3 ClickHouse计算层

ClickHouse在计算层做了非常细致的工作，竭尽所能榨干硬件能力，提升查询速度。它实现了单机多核并行、分布式计算、向量化执行与SIMD指令集、代码生成等多种重要技术。

1）多核并行

ClickHouse将数据划分为多个分片，每个分片再进一步划分为多个索引粒度，然后通过多个CPU核心分别处理其中的一部分来实现并行数据处理。在这种设计下，单条查询就能利用整机所有CPU。极致的并行处理能力极大地降低了查询延时。

2）分布式计算

除了优秀的单机并行处理能力，ClickHouse还提供了可线性拓展的分布式计算能力。ClickHouse会自动将查询拆解为多个任务下发到集群中，进行多机并行处理，最后汇聚结果。

3）向量化执行与SIMD指令集

ClickHouse不仅将数据按列存储，而且按列进行计算。传统事务分析数据库通常采用按行计算，原因是事务处理中以单元点查询为主，数据库查询语句计算量小，实现这些技术的收益不够明显。但在数据分析场景下，单个查询语句所涉及计算量可能极大，将每行作为一个基本单元处理会带来严重的性能损耗。

1.3.4 ClickHouse建设

依据数据的流向将ClickHouse的应用架构划分为4个层级：

1）数据接入层

提供了数据导入相关的服务及功能，按照数据的量级和特性抽象出三种ClickHouse导入数据的方式。

方式一：数仓应用层小表导入

这类数据量级相对较小，且分布在不同的数据源如hdfs、es、hbase等，这时提供基于DataX自研的TaskPlus数据流转+调度平台导入数据，单分区数据无并发写入，多分区数据小并发写入，且能和线上任务形成依赖关系，确保导入程序的可靠性。

方式二：离线多维明细宽表导入

这类数据一般是汇总层的明细数据或者是用户基于Hadoop生产的大量级数据，基于Spark开发了一个导入工具包，用户可以根据配置直接拉取hdfs或者hive上的数据到ClickHouse，同时还能基于配置查询语句对数据进行提取转换和加载处理，工具包会根据配置集群的节点数以及ClickHouse集群负载情况对本地表进行高并发的写入，达到快速导数的目的。