互联数据资源、为组织数字资产管理运营、数据探索、分析赋能！ 数据汇聚 专业的数据资源管理 自助分析 价值挖掘 多维探索 灵活 快速 自助 洞察 预警 消息 交互 Agenda. 数据分区 01 / 一级索引&二级索引 02 / 数据存储 03 / 数据标记 04 / 表引擎 表引擎，是ClickHouse设计实现中的一大特色。可以说正是由表引擎，决定了一张 数据表最终的性 e)最 为强大，在生产环境绝大部分场景中都应该使用此系列的表引擎。 只有合并树系列的表引擎才支持主键索引、数据分区、数据副本和数据采样这些特 性，同时也只有此系列的表引擎支持ALTER相关操作。 合并树家族 其中MergeTree作为家族中最基础的表引擎，提供了主键索引、数据分区、数据副 本和数据采样等所有的基本能力，而家族中其他的表引擎则在MergeTree的基础之 上各有所长。 MergeTree的名称由来 MergeTree的名称由来 MergeTree在写入一批数据时，数据总会以数据片段的形式写入磁盘，且数据 片段不可修改。为了避免片段过多，ClickHouse会通过后台线程定期合并这 些数据片段，属于相同分区的数据片段会被合成一个新的片段。这种数据片 段往复合并的特点也正是合并树的名称由来。 MergeTree的创建方式 CREATE TABLE [IF NOT EXISTS] [db_name.]table_name

5. 将A_ temp_temp rename成 A_temp; 非传统： 在第2步采用： ALTER TABLE A REPLACE PARTITION 分区名 FROM A_temp 全球敏捷运维峰会 广州站 针对ClickHouse的保护机制 1. 被动缓存； 2. 主动缓存； 全球敏捷运维峰会 广州站 ClickHouse集群架构 以上信息可以简单对比SQL执行效果 全球敏捷运维峰会 广州站 采用ClickHouse后平台的查询性能 全球敏捷运维峰会 广州站 ClickHouse应用小结 • 数据导入之前要评估好分区字段； • 数据导入时根据分区做好Order By； • 左右表join的时候要注意数据量的变化； • 是否采用分布式； • 监控好服务器的cpu/内存波动/`system`.query_log； • 数据存储磁盘尽量采用ssd； 减少数据中文本信息的冗余存储； • 特别适用于数据量大，查询频次可控的场景，如数据分析，埋点日志系统； 全球敏捷运维峰会 广州站 StarRocks应用小结 • 发挥分布式的优势，要提前做好分区字段规划； • 支持各种join，语法会相对clickhouse简单很多； • 一个sql可以多处用； • 建立好守护进程以及节点监控； 全球敏捷运维峰会 广州站 THANK YOU！

高效云盘，最大IO吞吐量 140MBps 以事业部、入库时间作双分区导入数据 遇到的问题 导入效率： • 原有导入数据方式在百亿级数据下会报Too many partitions for single INSERT block的问题 • 数据导入慢 原因： • ck-loader-mr方式对大数据量场景支持不够友好 • 单次插入分区过多 解决方法： 使用clickhouse原生insert ~600MBps, ~4x • 升级后 • ~250s --> ~69s，~3.62x l 数据加热后 ～69s -- > 18s ，～3.8x • ToDos • 优化数据导入流程 • 支持多分区，支持指定主键 • 常用字段加热 29 常用分析性能的命令分享 • linux命令 • top：查看系统cpu使用率，内存使用率等 • iotop：查看系统进程占用io情况 • iostat

background_pool_size 2：一个Insert Request，涉及N个分区的数据，在磁盘上就会生成N个数据目录，merge跟不上 3：一个目录，一个zxid，zookeeper集群的压力大，插入速度严重变慢 解决： 1：增大background_pool_size治标不治本 2：设置分区的时候需要思考，数据的特性需要了解 我们遇到的问题 查询过程中clickhouse-server进程挂掉