大数据之-clickhouse

最新推荐文章于 2024-07-01 21:32:30 发布

duyf

最新推荐文章于 2024-07-01 21:32:30 发布

阅读量3k

点赞数

文章标签： big data 大数据 hadoop spark

本文链接：https://blog.csdn.net/dyfvsgtxi/article/details/122687383

版权

Clickhouse原理解析
- OLAP常见架构
  - OLAP名为联机分析（豆腐分析）
    - 下钻（豆腐下钻）
      - 从“省”下钻到“市”
    - 上卷（豆腐上卷）
      - 从“市”汇聚成“省”
    - 切片(豆腐切片)
      - 将一个或多个维度设为单个固定值，然后观察剩余的维度
    - 切块（豆腐切块）
      - 将商品维度固定成“足球”“篮球”和“乒乓球”
    - 旋转（豆腐旋转）
      - 旋转立方体的一面，如果要将数据映射到一张二维表，那么就要进行旋转，这就等同于行列置换。
  - ROLAP
    - 直接使用关系模型构建，数据模型常使用星型模型或者雪花模型。
  - MOLAP
    - 使用多维数组的形式保存数据，其核心思想是借助预先聚合结果
  - HOLAP
    - 这种思路可以理解成ROLAP和MOLAP两者的集成
- LSM
  - 首先，会在内存中构建出一棵小树，构建完毕即算写入成功（这里会通过预写日志的形式，防止因内存故障而导致的数据丢失）（景区多个门口排队，进入景区，每个人都有凭证）
  - 其次，小树在构建的过程中会进行排序，这样就保证了数据的有序性（基于个头排序）
  - 最后，当内存中小树的数量达到某个阈值时，就会借助后台线程将小树刷入磁盘并生成一个小的数据段。在每个数据段中，数据局部有序（进入游戏项目1继续按个头排队）
- ClickHouse不适用的场景
  - 不支持事务
  - 不擅长根据主键按行粒度进行查询
  - 不擅长按行删除数据
  - 并发不高
  - 大表join
- 核心特性
  - 在线查询
  - 完备的DBMS功能
    - DDL（数据定义语言）
    - DML（数据操作语言）
    - 权限控制
    - 数据备份与恢复
    - 分布式管理
  - 列式存储与数据压缩
    - 网络带宽\|/
    - 磁盘IO\|/
  - 向量化执行引擎
    - 向量化执行，需要利用CPU的SIMD指令
    - ClickHouse目前利用SSE4.2指令集实现向量化执行
  - 多样化的表引擎
  - 多线程与分布式
    - 支持分区（纵向扩展，利用多线程原理）
    - 支持分片（横向扩展，利用分布式原理）
  - 多主架构
  - 数据分片与分布式查询
- clickhouse的架构设计
  - Column与Field（字段和单值）
  - DataType（数据类型）
    - 序列化
    - 反序列化
  - Block与Block流（数据块）
    - 数据对象
      - Column
    - 数据类型
      - DataType
    - 列名称
  - Table（表）
  - IStorage接口（表引擎）
    - IStorageSystemOneBlock（系统表）
    - StorageMergeTree（合并树表引擎）
    - StorageTinyLog（日志表引擎）
  - Parser与Interpreter（解析）
    - Parser分析器负责创建AST对象
    - Interpreter解释器则负责解释AST，并进一步创建查询的执行管道
  - Functions与Aggregate Functions（函数）
    - 普通函数和聚合函数
  - Cluster与Replication（集群和副本）
    - ClickHouse的1个节点只能拥有1个分片
    - 分片只是一个逻辑概念，其物理承载还是由副本承担的
- 客户端访问接口ClickHouse
  - CLI（Command Line Interface）即命令行接口
    - TCP传输层
  - JDBC
    - HTTP应用层
- ClickHouse的数据类型
  - 基础类型
    - 数值类型
      - Int
      - Float
      - Decima
    - 字符串类型
      - String
      - FixedString
        空字符填充
      - UUID
        格式为8-4-4-4-12
    - 时间类型
      - DateTime
      - DateTime64
      - Date
  - 复合类型
    - 数组
    - 元组
    - 枚举
    - 嵌套
  - 特殊类型
    - Nullable
      - 基础数据类型可以是Null值
    - Domain
      - IPv4
      - IPv6
- 数据字典
  - 内置字典
  - 外部扩展字典
- MergeTree原理（找书模型）
  - MergeTree的存储结构
    - checksums.txt：校验文件，使用二进制格式存储
      - 完整性
      - 正确性
    - columns.txt：列信息文件，使用明文格式存储
    - count.txt：计数文件，使用明文格式存储
    - primary.idx：一级索引文件，使用二进制格式存储
    - [Column].bin：数据文件
      - LZ4压缩格式
    - [Column].mrk：列字段标记文件，使用二进制格式存储
      - 标记文件与稀疏索引对齐，又与.bin文件一一对应
    - partition.dat与minmax_[Column].idx
  - 一级索引（按书名字母排序引导牌）
    - 稀疏索引
      - 在稠密索引中每一行索引标记都会对应到一行具体的数据记录。而在稀疏索引中，每一行索引标记对应的是一段数据，而不是一行
      - primary.idx内的索引数据常驻内存
    - 索引粒度
      - 一级索引和数据标记的间隔粒度相同（同为index_granularity行）
      - 数据文件也会依照index_granularity的间隔粒度生成压缩数据块
    - 索引数据的生成规则
      - 1 8192
      - 57 80
      - =>>>5780
    - 索引的查询过程
      - MarkRange（数据治理开头是sjzl）
        mark = 0 1 2
        row = 1 2 3
        ==>markrange [0,1]:[1,2]
      - 生成查询条件区间（比如找数据治理书）
        id=2 ===> [2,2]
      - 递归交集判断
        除8
      - 合并MarkRange区间
  - 数据标记 (对齐排序，引导牌、记录书柜号和几排几行)
    - 数据标记的生成规则
      - mark
      - 压缩块偏移量
      - 解压后偏移量
    - 数据标记的工作方式
      - 读取压缩数据块
      - 读取数据
  - 数据存储（书柜）
    - 压缩数据块
      - 头信息
        压缩算法类型1byte
        压缩后的数据大小4byte
        压缩前的数据大小4byte
      - 压缩数据
        大小范围
        按压缩前大小，控制在64KB～1MB
        压缩数据块最终的大小
        单个批次数据size
        继续获取下一批数据
        单个批次数据64KB
        直接生成压缩数据块
        单个批次数据size>1MB
        截断
  - 数据分区 (图书分类)
    - 数据的分区规则
      - 不指定分区键
        all_0_0_0
      - 使用整型
        1_0_0_0
      - 使用日期类型
        20100101_0_0_0
      - 使用其他类型
        hash128_0_0_0
    - 分区目录的命名规则
      - PartitionID_MinBlockNum_MaxBlockNum_Level
- MergeTree系列表引擎
  - MergeTTL和多路径存储
    - 数据TTL
      - 表
      - 列
    - 多路径存储策略
      - 默认策略
        单磁盘
      - JBOD策略
        多磁盘
      - 轮询策略
        HOT/COLD策略
  - ReplacingMergeTree
    - 功能
      - 数据去重
    - 特点
      - orderby去重
      - 分区内去重
      - 合并生效
  - SummingMergeTree
    - 数据汇总
  - AggregatingMergeTree
    - 数据聚合
  - CollapsingMergeTree
    - 折叠表
      - 以增代删
        有序
  - VersionedCollapsingMergeTree
    - 高级折叠表
      - 以增代删
        无序
- 副本和分片
  - 副本
    - 功能
      - 数据备份
      - 提高负载
        分摊查询
        读写分离
    - 特点
      - 依赖zookeeper
        INSERT
        ALTER
      - 表级别的副本
      - 多主架构
      - Block数据块
        128*8192
      - 原子性
        block要么全部成功，要么全部失败
      - 唯一性
        hash摘要
        block内顺序
        数据行
        数据大小
    - ZooKeeper内的节点结构
      - 元数据
        metadata
        主键
        分区键
        采样表达式
        columns
        列名称
        数据类型
        replicas
        副本名称
      - 判断标识
        leader_election：用于主副本的选举工作
        MERGE
        MUTATION操作
        ALTER DELETE
        ALTER UPDATE
        blocks
        Hash信息摘要
        partition_id
        block_numbers
        分区顺序=partition顺序
        Merge按序
        quorum
        当至少有quorum数量的副本写入成功后，整个写操作才算成功
      - 操作日志
        log
        INSERT
        MERGE
        DROP PARTITION
        mutations
        ALERT DELETE
        ALERT UPDATE
        replicas/{replica_name}
        queue：任务队列
        log_pointer
        最后一次执行的log日志下标信息
        mutation_pointer
        最后一次执行的log日志下标信息
    - Entry
      - LogEntry
        source replica
        指令来源副本
        block_id
        当前分区的BlockID
        partition_name
        当前分区目录的名称
        type
        get
        下载分区
        merge
        合并
        drop partition
        删除分区
      - MutationEntry
        source replica
        指令来源副本
        commands
        ALTER DELETE
        ALTER UPDATE
        mutation_id
        MUTATION操作的版本号
        partition_id
        当前分区目录的ID
    - INSERT的核心执行流程
      - 创建副本实例
        创建第一个副本实例
        初始化所有的ZooKeeper节点，·在/replicas/节点下注册自己的副本
        启动监听任务，监听/log日志节点
        参与副本选举，选举出主副本，选举的方式是向/leader_election/插入子节点，第一个插入成功的副本就是主副本
        创建第二个副本实例
        /replicas/节点下注册自己的副本实例
        启动监听任务，监听/log日志节点
        参与副本选举，选举出主副本
      - 向第一个副本实例写入数据
      - 由第一个副本实例推送Log日志
        由执行了INSERT的副本向/log节点推送操作日志
      - 第二个副本实例拉取Log日志
      - 第二个副本实例向其他副本发起下载请求
      - 第一个副本实例响应数据下载
      - 第二个副本实例下载数据并完成本地写入
    - MERGE的核心执行流程
      - 由主副本来制定
        创建远程连接，尝试与主副本通信
        主副本接收通信
        由主副本制定MERGE计划并推送Log日志
        各个副本分别拉取Log日志
        各个副本分别在本地执行MERGE
    - MUTATION的核心执行流程
      - 推送MUTATION日志
      - 所有副本实例各自监听MUTATION日志
      - 由主副本实例响应MUTATION日志并推送Log日志
      - 各个副本实例分别拉取Log日志
      - 各个副本实例分别在本地执行MUTATION
    - ALTER的核心执行流程
      - 修改共享元数据
      - 监听共享元数据变更并各自执行本地修改
      - 确认所有副本完成修改
  - Distributed表引擎
    - 1）ZooKeeper内的节点结构
      - clickhouse/task_queue/dd
        /query-[seq]/active：临时保存当前集群内状态为active的节点
        /query-[seq]/finished
    - 2）DDLLogEntry日志对象的数据结构
      - query记录了DDL语句
      - hosts记录了指定集群的hosts主机
    - 3）initiator记录初始化host主机的名称，hosts主机列表的取值来自于初始化host节点上的集群
- 外部存储类型
  - HDFS
  - MySQL
  - JDBC
  - Kafka
  - File
  - 内存类型
    - Memory表引擎
    - Set
      - 数据不会丢失，当数据表被重新装载时，文件数据会再次被全量加载至内存
      - 只能作为IN查询的右侧条件被查询使用
    - Join
    - Buffer
  - 日志类型
    - TinyLog
  - 接口类型
    - Dictionary
    - Distributed
- SQL优化规则
  - 1、count优化
    - count() 和 count(*) 且没有过滤条件，会使用system.tables 的 total_rows
  - 2、消除子查询重复字段
  - 3、谓词下推:
    - 当 group by 有 having 子句，但是没有 with cube、with rollup 或者 with totals 修饰的时候，having 过滤会下推到 where 提前过滤
  - 4、聚合计算外推
    - select sum(id * 2) === > select sum(id)*2
  - 5、删除重复的 group （orde\limit）by key

duyf

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
大数据之-clickhouse

Clickhouse原理解析 OLAP常见架构 OLAP名为联机分析（豆腐分析）下钻（豆腐下钻）从“省”下钻到“市” 上卷（豆腐上卷）从“市”汇聚成“省” 切片(豆腐切片) 将一个或多个维度设为单个固定值，然后观察剩余的维度切块（豆腐切块）将商品维度固定成“足球”“篮球”和“乒乓球” 旋转（豆腐旋转）旋转立方体的一面，如果要将数据映射到一张二维表，那么就要进行旋转，这就等同
复制链接

扫一扫