ClickHouse和虚拟引擎

ClickHouse

ClickHouse的概述

ClickHouse是一个开源的用于联机分析(OLAP)的列式数据库管理系统(DBMS)。

OLAP场景的关键特征

  • 大多数是读请求
  • 数据总是以相当大的批(> 1000 rows)进行写入
  • 不修改已添加的数据
  • 每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列
  • 宽表，即每个表包含着大量的列
  • 较少的查询(通常每台服务器每秒数百个查询或更少)
  • 对于简单查询，允许延迟大约50毫秒
  • 列中的数据相对较小： 数字和短字符串(例如，每个URL 60个字节)
  • 处理单个查询时需要高吞吐量（每个服务器每秒高达数十亿行）
  • 事务不是必须的
  • 对数据一致性要求低
  • 每一个查询除了一个大表外都很小
  • 查询结果明显小于源数据，换句话说，数据被过滤或聚合后能够被盛放在单台服务器的内存中

很容易可以看出，OLAP场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同， 因此想要使用OLTP或Key-Value数据库去高效的处理分析查询场景，并不是非常完美的适用方案。例如，使用OLAP数据库去处理分析请求通常要
优于使用MongoDB或Redis去处理分析请求。

ClickHouse的来源

ClickHouse最初是一款名为Yandex.Metrica的产品，主要用于WEB流量分析。ClickHouse的全称是Click Stream,Data WareHouse，简称ClickHouse。也是战斗名族俄罗斯([Russia)的第二款强大开源的高性能产品之一。

ClickHouse应用领域

ClickHouse非常适用于商业智能领域，除此之外，它也能够被广泛应用于广告流量、Web、App流量、电信、金融、电子商务、信息安全、网络游戏、物联网等众多其他领域。

ClickHouse优点

https://clickhouse.tech/docs/en/introduction/distinctive-features/

  • 支持完备的SQL操作
  • 真正的列式存储与数据压缩
  • 向量化（列的一部分）执行引擎
  • 关系型模型(与传统数据库类似)
  • 丰富的表引擎
  • 并行处理
  • 在线查询
  • 数据分片

ClickHouse缺点

  • 不支持事务。为啥不支持事务？因面向列
  • 不擅长根据主键按行粒度进行查询（虽然支持），故不应该把ClickHouse当作Key-Value数据库使用。
  • 不擅长按行删除数据（虽然支持）

ClickHouse表引擎分类

引擎分类 引擎名称
MergeTree系列 MergeTree 、ReplacingMergeTree 、SummingMergeTree 、 AggregatingMergeTree CollapsingMergeTree 、 VersionedCollapsingMergeTree 、GraphiteMergeTree
Log系列 TinyLog 、StripeLog 、Log
Integration Engines Kafka 、MySQL、ODBC 、JDBC、HDFS
Special Engines Distributed 、MaterializedView、 Dictionary 、Merge 、File、Null 、Set 、Join 、 URL View、Memory 、 Buffer

注意：在所有的表引擎中，最为核心的当属MergeTree系列表引擎，这些表引擎拥有最为强大的性能和最广泛的使用场合。对于非MergeTree系列的其他引擎而言，主要用于特殊用途，场景相对有限。而MergeTree系列表引擎是官方主推的存储引擎，支持几乎所有ClickHouse核心功能。

ClickHouse表引擎作用

  • 决定表存储在哪里以及以何种方式存储
  • 支持哪些查询以及如何支持
  • 并发数据访问
  • 索引的使用
  • 是否可以执行多线程请求
  • 数据复制参数

ClickHouse表引擎之Log系列表引擎

应用场景

Log系列表引擎功能相对简单，主要用于快速写入小表(1百万行左右的表)，然后全部读出的场景。即一次写入多次查询。

Log系列表引擎的特点

共性特点

  • 数据存储在磁盘上
  • 当写数据时，将数据追加到文件的末尾
  • 不支持并发读写，当向表中写入数据时，针对这张表的查询会被阻塞，直至写入动作结束
  • 不支持索引
  • 不支持原子写：如果某些操作(异常的服务器关闭)中断了写操作，则可能会获得带有损坏数据的表
  • 不支持ALTER操作(这些操作会修改表设置或数据，比如delete、update等等)

区别

  • TinyLog

    TinyLog是Log系列引擎中功能简单、性能较低的引擎。它的存储结构由数据文件和元数据两部分组成。其中，数据文件是按列独立存储的，也就是说每一个列字段都对应一个文件。除此之外，TinyLog不支持并发数据读取。

  • StripLog支持并发读取数据文件，当读取数据时，ClickHouse会使用多线程进行读取，每个线程处理一个单独的数据块。另外，StripLog将所有列数据存储在同一个文件中，减少了文件的使用数量。

  • Log支持并发读取数据文件，当读取数据时，ClickHouse会使用多线程进行读取，每个线程处理一个单独的数据块。Log引擎会将每个列数据单独存储在一个独立文件中。

ClickHouse表引擎之MergeTree系列引擎

在所有的表引擎中，最为核心的当属MergeTree系列表引擎，这些表引擎拥有最为强大的性能和最广泛的使用场合。对于非MergeTree系列的其他引擎而言，主要用于特殊用途，场景相对有限。而MergeTree系列表引擎是官方主推的存储引擎，支持几乎所有ClickHouse核心功能。

应用场景

ClickHouse非常适用于商业智能领域，除此之外，它也能够被广泛应用于广告流量、Web、App流量、电信、金融、电子商务、信息安全、网络游戏、物联网等众多其他领域。

MergeTree表引擎

MergeTree在写入一批数据时，数据总会以数据片段的形式写入磁盘，且数据片段不可修改。为了避免片段过多，ClickHouse会通过后台线程，定期合并这些数据片段，属于相同分区的数据片段会被合成一个新的片段。这种数据片段往复合并的特点，也正是合并树名称的由来。

MergeTree作为家族系列最基础的表引擎，主要有以下特点：

  • 存储的数据按照主键排序：允许创建稀疏索引，从而加快数据查询速度
  • 支持分区，可以通过PARTITION KEY语句指定分区字段。
  • 支持数据副本
  • 支持数据采样

ReplacingMergeTree表引擎

上文提到MergeTree表引擎无法对相同主键（排序键）的数据进行去重，ClickHouse提供了ReplacingMergeTree引擎，可以针对相同主键的数据进行去重，它能够在合并分区时删除重复的数据。

值得注意的是，ReplacingMergeTree只是在一定程度上解决了数据重复问题，但是并不能完全保障数据不重复。

总结

  • 如何判断数据重复

ReplacingMergeTree在去除重复数据时，是以ORDERBY排序键为基准的，而不是PRIMARY KEY。

  • 何时删除重复数据

在执行分区合并时，会触发删除重复数据。optimize的合并操作是在后台执行的，无法预测具体执行时间点，除非是手动执行。

  • 不同分区的重复数据不会被去重

ReplacingMergeTree是以分区为单位删除重复数据的。只有在相同的数据分区内重复的数据才可以被删除，而不同数据分区之间的重复数据依然不能被剔除。

  • 数据去重的策略是什么

如果没有设置[ver]版本号（ver为数字，日期类型字段），则保留同一组重复数据中的最新插入的数据；如果设置了[ver]版本号，则保留同一组重复数据中ver字段取值最大的那一行。

  • optimize命令使用

一般在数据量比较大的情况，尽量不要使用该命令。因为在海量数据场景下，执行optimize要消耗大量时间

SummingMergeTree表引擎

按排序键汇总指定列。该引擎继承了MergeTree引擎，当合并 SummingMergeTree 表的数据片段时，ClickHouse 会把所有具有相同排序键的行合并为一行，该行包含了被合并的行中具有数值数据类型的列的汇总值，即如果存在重复的数据，会对对这些重复的数据进行合并成一条数据，类似于group by的效果。

推荐将该引擎和MergeTree 一起使用。例如，将完整的数据存储在 MergeTree 表中，并且使用 SummingMergeTree 来存储聚合数据。这种方法可以避免因为使用不正确的主键组合方式而丢失数据。

如果用户只需要查询数据的汇总结果，不关心明细数据，并且数据的汇总条件是预先明确的，即GROUP BY的分组字段是确定的，可以使用该表引擎。

总结

  • SummingMergeTree是根据什么对两条数据进行合并的

用ORBER BY排序键作为聚合数据的条件Key。即如果排序key是相同的，则会合并成一条数据，并对指定的合并字段进行聚合。

  • 仅对分区内的相同排序key的数据行进行合并

以数据分区为单位来聚合数据。当分区合并时，同一数据分区内聚合Key相同的数据会被合并汇总，而不同分区之间的数据则不会被汇总。

  • 如果没有指定聚合字段，会怎么聚合

如果没有指定聚合字段ENGINE=SummingMergeTree(聚合字段)，则会按照非主键的数值类型字段进行聚合

  • 对于非汇总字段的数据，该保留哪一条

如果两行数据除了排序字段相同，其他的非聚合字段不相同，那么在聚合发生时，会保留最初的那条数据，新插入的数据对应的那个字段值会被舍弃。下面新插入的被舍弃

AggregatingMergetree表引擎

按排序键自定义聚合。

该表引擎继承自MergeTree，可以使用 AggregatingMergeTree 表来做增量数据统计聚合。如果要按一组规则来合并减少行数，则使用 AggregatingMergeTree 是合适的。AggregatingMergeTree是通过预先定义的聚合函数计算数据并通过二进制的格式存入表内。

与SummingMergeTree的区别在于：SummingMergeTree对非主键列进行sum聚合，而AggregatingMergeTree则可以指定各种聚合函数。

CollapsingMergeTree表引擎

折叠合并树，CollapsingMergeTree就是一种通过以增代删的思路，支持行级数据修改和删除的表引擎。它通过定义一个sign标记位字段，记录数据行的状态。

  • 如果sign标记为1，则表示这是一行有效的数据；

  • 如果sign标记为-1，则表示这行数据需要被删除。

当CollapsingMergeTree分区合并时，同一数据分区内，sign标记为1和-1的一组数据会被抵消删除。

每次需要新增数据时，写入一行sign标记为1的数据；需要删除数据时，则写入一行sign标记为-1的数据。

VersionedCollapsingMergeTree表引擎

版本折叠合并树。上面提到CollapsingMergeTree表引擎对于数据写入乱序的情况下，不能够实现数据折叠的效果。VersionedCollapsingMergeTree表引擎的作用与CollapsingMergeTree完全相同，它们的不同之处在于，VersionedCollapsingMergeTree对数据的写入顺序没有要求，在同一个分区内，任意顺序的数据都能够完成折叠操作。VersionedCollapsingMergeTree使用version列来实现乱序情况下的数据折叠。

ClickHouse与mysql简单对比

  1. MySQL单条SQL是单线程的，只能跑满一个core，ClickHouse相反，有多少CPU，吃多少资源，所以飞快.
  2. ClickHouse不支持事务，不存在隔离级别。ClickHouse的定位是分析性数据库，而不是严格的关系型数据库.
  3. MySQL是行存储，ClickHouse是列存储，后者在count()这类操作天然有优势
  4. 在IO方面，MySQL需要大量随机IO，ClickHouse基本是顺序IO。对IO基本没有太高要求，当然，磁盘越快，上层处理越快，但是99%的情况是，CPU先跑满了（数据库里太少见了，大多数都是IO不够用）

ClickHouse为什么快

列式数据库更适合于OLAP场景(对于大多数查询而言，处理速度至少提高了100倍)

输入/输出

  1. 针对分析类查询，通常只需要读取表的一小部分列。在列式数据库中你可以只读取你需要的数据。例如，如果只需要读取100列中的5列，这将帮助你最少减少20倍的I/O消耗。
  2. 由于数据总是打包成批量读取的，所以压缩是非常容易的。同时数据按列分别存储这也更容易压缩。这进一步降低了I/O的体积。
  3. 由于I/O的降低，这将帮助更多的数据被系统缓存。

性能

  1. 单个大查询的吞吐量

    吞吐量可以使用每秒处理的行数或每秒处理的字节数来衡量。如果数据被放置在page cache中，则一个不太复杂的查询在单个服务器上大约能够以2-10GB／s（未压缩）的速度进行处理（对于简单的查询，速度可以达到30GB／s）。如果数据没有在page cache中的话，那么速度将取决于你的磁盘系统和数据的压缩率。例如，如果一个磁盘允许以400MB／s的速度读取数据，并且数据压缩率是3，则数据的处理速度为1.2GB/s。这意味着，如果你是在提取一个10字节的列，那么它的处理速度大约是1-2亿行每秒。

    对于分布式处理，处理速度几乎是线性扩展的，但这受限于聚合或排序的结果不是那么大的情况下。

  2. 处理短查询的延迟时间
    如果一个查询使用主键并且没有太多行(几十万)进行处理，并且没有查询太多的列，那么在数据被page cache缓存的情况下，它的延迟应该小于50毫秒(在最佳的情况下应该小于10毫秒)。 否则，延迟取决于数据的查找次数。如果你当前使用的是HDD，在数据没有加载的情况下，查询所需要的延迟可以通过以下公式计算得知： 查找时间（10 ms） * 查询的列的数量 * 查询的数据块的数量。

  3. 处理大量短查询的吞吐量
    在相同的情况下，ClickHouse可以在单个服务器上每秒处理数百个查询（在最佳的情况下最多可以处理数千个）。但是由于这不适用于分析型场景。因此我们建议每秒最多查询100次。

  4. 数据的写入性能
    我们建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。当使用tab-separated格式将一份数据写入到MergeTree表中时，写入速度大约为50到200MB/s。如果您写入的数据每行为1Kb，那么写入的速度为50，000到200，000行每秒。如果您的行更小，那么写入速度将更高。为了提高写入性能，您可以使用多个INSERT进行并行写入，这将带来线性的性能提升。

虚拟化数据引擎

但是由于ANSI SQL仅提供了一种标准，各个数据管理系统在此基础上逐渐发展成具有自身特点的SQL方言，并且差异愈加明显。数据分析人员需要针对不同的数据管理系统学习使用特定的SQL方言，无疑增加了使用成本。除了存在SQL方言的问题，多种数据源联合查询也提高了数据分析的门槛。目前广泛使用的解决方案是通过构建数据仓库，将各个孤立的数据源中的数据整合到数据仓库中，即抽取（Extract）、转换（Transform）、加载（Load）。但是随着数据量的不断增长，数据仓库的规模逐渐增大，ETL所需的人力成本、时间成本、软件与硬件成本逐渐上升。并且由于ETL需要花费一定时间，由此造成了T+1的数据分析模式，在强调商业智能（BI）的今天，显然是不够及时的。并且随着业务的不断增长，可能需要联结多个数据仓库的数据进行分析，此时数据仓库在某种意义上已经成为了数据孤岛。

开源数据虚拟化引擎openLooKeng

华为正式宣布开源数据虚拟化引擎openLooKeng，开源社区官网（https://openlookeng.io）同步上线。openLooKeng致力于为大数据用户提供极简的数据分析体验，让用户像使用“数据库”一样使用“大数据”。

2019年11月19日，华为宣布开源数据虚拟化引擎HetuEngine（开源版本的HetuEngine叫openHetu），今日，openHetu正式更名为openLooKeng，HetuEngine更名为LooKengEngine。openLooKeng是一款开源的高性能数据虚拟化引擎。提供统一SQL接口，具备跨数据源/数据中心分析能力以及面向交互式、批、流等融合查询场景。同时增强了前置调度、跨源索引、动态过滤、跨源协同、水平拓展等能力。

随着大数据技术的应用和发展，数据种类越来越多，数据分布越来越广，查询场景也越来越复杂，这使得大数据使用更加困难。为了改善大数据的易用性，华为发起数据虚拟化引擎openLooKeng开源项目，旨在解决上述问题：

  • 统一SQL接口访问多种数据源
  • 免数据搬迁，在数据所在地对数据进行处理，并且支持跨数据中心、跨云处理
  • 面向交互式、批、流等融合查询的场景（第一个版本支持交互式查询场景）

此外，该项目还提供了Coordinator AA高可靠、可扩展的数据源connector框架等能力，让用户及大数据解决方案伙伴更方便的使用openLooKeng。

openLooKeng使用了业界著名的开源SQL引擎Presto来提供交互式查询分析基础能力，并继续在融合场景查询、跨数据中心/云、数据源扩展、性能、可靠性、安全性等方面发展，让数据治理、使用更简单。

Greenplum数据虚拟化框架PXF

PXF（Greenplum Platform Extension Framework）作为Greenplum数据虚拟化的解决方案。PXF提供了连接器，使你可以访问存储在Greenplum数据库以外的源中的数据。这些连接器将外部数据源映射到Greenplum数据库外部表，提供跨异构数据源的并行、高吞吐量数据访问和联合查询。

GPDB集群包含一个master节点（master node）和多个segment主机（segment host）。GPDB segment主机上的PXF客户端进程为对外部表进行查询的每个segment实例分配工作线程。多个segment主机的PXF代理与外部数据存储并行通信。

HDFS是Apache Hadoop主要使用的分布式存储机制。当用户或应用程序在引用HDFS文件的PXF外部表上执行查询时，Greenplum数据库master节点会将查询分派给所有segment主机。每个segment实例都与在其主机上运行的PXF代理联系。当它收到来自segment实例的请求时，PXF代理将：

  • 分配一个工作线程以处理来自某个segment的请求。

  • 调用HDFS Java API，从HDFS NameNode请求有关HDFS文件的元数据信息。

  • 将HDFS NameNode返回的元数据信息提供给segment实例。

Facebook分布式查询引擎Presto

Presto是Facebook开源的、完全基于内存的分布式SQL查询引擎，适用于交互式分析查询，数据量支持GB到PB字节。Presto是运行在多台服务器上的分布式系统。完整安装包括一个coordinator和多个worker。此外还有一项discovery.uri，默认情况下该发现服务是内置在coordinator中的。coordinator和worker都会注册到discovery server。coordinator可以知道worker的数量，以便分配工作，而worker可以识别出coordinator。由客户端提交查询，从Presto命令行CLI提交到coordinator。coordinator进行解析，分析并执行查询计划，然后分发处理队列到worker。

  • coordinator（master）负责meta管理、worker管理、query的解析和调度。

  • worker则负责计算和读写。

  • discovery server，通常内嵌于coordinator节点中，也可以单独部署，用于节点心跳。

360跨数据源查询引擎QuickSQL

Quicksql是一款跨计算引擎的统一联邦查询中间件，用户可以使用标准SQL语法对各类数据源进行联合分析查询。其目标是构建实时或离线全数据源统一的数据处理范式，屏蔽底层物理存储和计算层，最大化业务处理数据的效率。同时能够提供给开发人员可插拔接口，由开发人员自行对接新数据源。

Quicksql包含三层结构：

  • 语法解析层：负责 SQL 语句的解析、校验、优化、混算 SQL 的切分以及最终生成 Query Plan；

  • 计算引擎层：负责Query Plan路由到具体的执行计划中，将Query Plan解释为具体的执行引擎可识别的语言；

  • 数据存储层：负责数据的提取、存储；

Quicksql希望可以屏蔽不同数据管理系统中SQL方言，不用考虑不同数据源之间的隔离性，根据需求选择最为合适的查询计划。

posted @ 2023-04-03 11:11  edclol  阅读(155)  评论(0)  编辑  收藏  举报