• Clickhouse 的部署与监控管理 • Clickhouse 的应用实践 iData 目录 部署与监控管理 一切以用户价值为依归 3 1 4 部署与监控管理 1 高内存，廉价存储： 单机配置: Memory128G CPU核数24 SATA20T，RAID5 万兆网卡 一切以用户价值为依归 5 部署与监控管理 1 生产环境部署方案： Distributed Table iData大数据分析：多维分析，画像分析能力 n DataMore大数据实时决策能力 一切以用户价值为依归 17 业务应用实践 iData 2 新大数据分析引擎2.0 业界传统 大数据分析 引擎 大数据分析引擎&存储 Analytical Engine & Database 大数据仓库 Hadoop Data Lake 计算引擎 MR & Spark Data Warehouse OLTP Big RPC DataNode 基于位图的分布式计算引擎 API Server Scheduler SQL-Parser QueryOptimier Column1 DataNode Column2 Column3 ColumnN Column1 DataNode Column2 Column3 ColumnN bitmap 画像下钻分布式计算引擎 多维 提取 iData大数据分析引擎

苏宁科技集团.大数据中心.杨兆辉 1 关亍我  苏宁科技集团大数据中心架构师  曾就职亍中兴通讯10+years ，从事大规模分布式系统研发  10+years C++、Java、Go编程经验，熟悉大数据架构、解决方案  ClickHouse Contributor  Github: https://github 精确去重计数性能测试 6 ClickHouse在苏宁使用场景  OLAP平台存储引擎 -- 存储时序数据、cube加速数据，应用亍高基数查询、精确去重场景。  运维监控 -- 实时聚合分析监控数据，主要使用物化视图技术。  用户画像场景 -- 标签数据的存储、用户画像查询引擎。 7 Contents 苏宁如何使用ClickHouse ClickHouse集成Bitmap 用户画像场景实践 8 Bitmap位存储和位计算 每个bit位表示一个数字id，对亍40亿个的用户id，只需要40亿bit位， 约477m大小 = （4 * 109 / 8 / 1024 / 1024） 但是如果使用上述的数据结构存储单独一个较大数值的数字id，会造成空间上的浪费，例如 仅存储40亿一个数值也需要477m的空间。也就是说稀疏的Bitmap和稠密的占用空间相

Kylin，Ingite，MongoDB，Hbase 不断的研究，实践； 全球敏捷运维峰会 广州站 ClickHouse 的特点 优点： 1. 数据压缩比高，存储成本相对非常低； 2. 支持常用的SQL语法，写入速度非常快，适用于大量的数据更新； 3. 依赖稀疏索引，列式存储，cpu/内存的充分利用造就了优秀的计算能力， 并且不用考虑左侧原则； 缺点： 1. 不支持事务，没有真正的update/delete； 虚拟集群最少两台机器在不同的机房； Ø 数据独立，多写，相互不干扰； Ø 数据读取通过应用程序做负载平衡； Ø 灵活创建不同的虚拟集群用于适当的场合； Ø 随时调整服务器，新增/缩减服务器； 分布式： k8s的集群式部署 全球敏捷运维峰会 广州站 采用ClickHouse后平台的查询性能 system.query_log表，记录已经 执行的查询记录 query：执行的详细SQL，查询相关记录可以 左右表join的时候要注意数据量的变化； • 是否采用分布式； • 监控好服务器的cpu/内存波动/`system`.query_log； • 数据存储磁盘尽量采用ssd； • 减少数据中文本信息的冗余存储； • 特别适用于数据量大，查询频次可控的场景，如数据分析，埋点日志系统； 全球敏捷运维峰会 广州站 StarRocks应用小结 • 发挥分布式的优势，要提前做好分区字段规划； • 支持

能力的时序数据库产品 高性能并发读写 • 千万数据点并发实时写入 • 引入辅助索引，加快数据检索 速度 低成本存储 • 列式存储结合高效的编码 • Delta、XOR 等适合时序场景的压缩算法 • 通过 Rollup 功能，对历史数据做聚合，减少数据量 稳定可扩展 • 分布式架构 • 数据多副本存储 • 服务高可用 Thanks For You

自助 洞察 预警 消息 交互 Agenda. 数据分区 01 / 一级索引&二级索引 02 / 数据存储 03 / 数据标记 04 / 表引擎 表引擎，是ClickHouse设计实现中的一大特色。可以说正是由表引擎，决定了一张 数据表最终的性格，它拥有何种特性、数据以何种形式被存储以及如何被加载。 ClickHouse拥有非常庞大的表引擎体系，截至到目前(19.14.6)，共拥有合并树、 [SETTINGS name=value, 省略...] 分区键 排序键 主键 index_granularity = 8192 索引粒度 MergeTree的存储结构 数据以分区的形式被组织 , PARTITION BY 各列独立存储, 按ORDER BY 排序 一级索引, 按PRIMARY Key 排序 数据分区 数据的分区规则 l 不指定分区键 如果不使用分区键，既不使用PARTITION MergeTree只需要12208行索引标 记就能为1亿行数据记录索引。 索引粒度 基于索引粒度，将数据标记成多个小的区间 index_granularity，默认8192 索引数据的生成规则 依照索引粒度生成索引，紧凑存储,惜字如金。 PRIMARY KEY ID 索引的查询过程 假如现在有一份测试数据，共192行记录。其中，主键ID为String类型， ID的取值从A000、A001、A002，按顺序增长，直至A192为止。

v Map隐式列将每个Key存储为独⽴列 v Map隐式列查询时只读取需要的隐式列 Bulkload v 原⽣写⼊⽅式消耗ClickHouse Server资源，影响查询性能 v 实时写⼊任务长期占⽤资源，故障恢复的时间和运维成本较⾼ v 基于中间存储的Bulkload⽅案降低ClickHouse Server压⼒ Bulkload v 基于中间存储的Bulkload可以降低ClickHouse ckHouse Server压⼒ v 基于中间存储的Bulkload受HDFS和⽹络稳定性影响，且传输成本较⾼ v 直达ClickHouse的Bulkload稳定性，性能都更佳 Unique Engine v ⽬标：⽀持UpSert，Delete操作，提升查询性能 v 设计：delete on insert Unique Engine v write-write冲突依靠table level Elastic To ClickHouse迁移，降本增效 v OTEL标准化⽇志采集 v 统⼀scheme⽀持 日志 v ClickHouse较ES写⼊吞吐量提升近10倍 v ClickHouse存储成本为ES的1/3 日志 v ClickHouse中采⽤分表，统⼀schema的设计 v ⽇志查询采⽤类似ES语法，降低⽤户迁移成本 用户行为数据分析 概述 v 基于ClickHouse构建B站⽤户⾏为数据分析产品：北极星

众安集智平台与clickhouse 02 集智平台 X-Brain AI 开放平台 计算框架 Hadoop, JStorm, Spark Streaming, Flink 离线/实时任务监控 数据、模型存储 Hive, HBase, Clickhouse, Kylin 数据接入 消 息 中 间 件 模型、 算法 模版 机器学习平台 Antron 机器人平台 X-Insight 数据洞察平台 全生命周期管理 追溯与可重现 洞察平台架构 Why Clickhouse? Clickhosue 性能 高效的数据导入和查询性能 开源 低成本，免费 压缩比 高度的数据压缩比，存储成本更小 面向列 真正的面向列存储， 支持高维度表 易观开源OLAP引擎测评报告 洞察数据模型+Clickhouse 使用效果 CHAPTER 使用ck对百亿数据的探索 03 背景 我们希望对保单、 rows/s • 用到六块硬盘的io：6*140=840mb/s • io吞吐量加倍时，对于冷数据的处理速度是之前的~180% 28 ClickHouse 百亿数据性能测试与优化 • 硬盘存储升级 • 高效云盘 --> SSD + RAID0 • 140MBps --> ~600MBps, ~4x • 升级后 • ~250s --> ~69s，~3.62x l 数据加热后 ～69s

部分复杂累时查询30S内完成 集群现状 我们遇到的问题 关于机器的配置 早期集群机器配置16核64G 一块1.7T本地SSD 问题： 1：内存限制，对于一些大的查询会出现内存不够问题 2：存储限制，随着表越来多，磁盘报警不断 3：cpu限制 64G对于一些大表(每天600亿+)的处理，很容易报错，虽然有基于磁盘解决方案，但是会影响速度 clickhouse的数据目录还不支持多个数据盘，单块盘的大小限制太大 据Part都在 zookeeper上面有个节点与之对应以及表的元数据信息等等. 解决： 1：zookeeper机器的snapshot文件和log文件最好分盘存储(推荐SSD)提高ZK的响应 2：zookeeper的snapshot文件存储盘不低于1T 3：做好zookeeper集群和clickhouse集群的规划，可以多套zookeeper集群服务一套clickhouse集群 3.1：zooke