ClickHouse北京Meetup ClickHouse Best Practice @Sina
•
3 gostaram•996 visualizações
ClickHouse在新浪的最佳实践 PPT发布于ClickHouse2018北京Meetup
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a ClickHouse北京Meetup ClickHouse Best Practice @Sina
Semelhante a ClickHouse北京Meetup ClickHouse Best Practice @Sina (20)
ClickHouse北京Meetup ClickHouse Best Practice @Sina
- 2. 19台服务器器 300亿/天 数据量量 800w/天 有效查询 平均查询时间 200ms 核⼼心监控查询平均40ms 存量量数据1.5万亿 截⽌止2018年年09⽉月03⽇日
- 3. • Why ClickHouse • How it works • Best practice Content
- 5. Big Data AIOps Data Science Visualization Analytics APP Net DB LB Back End Monitoring MySQL DBA 数据分析 AIOps About Me
- 6. ⽹网络 主机 负载均衡 数据库 Web About Data APP CDN 云存储 DNS •我们做什什么数据？ •量量级 •实时性 •查询需求 •接⼊入
- 9. •数据分析 产⽣生洞洞⻅见 •探索未知纬度与组合 About Data 图：某CDN质量量数据 gif动图 CDN1 CDN2
- 17. 俄罗斯搜索巨头Yandex开源 列列式存储 集群 超⾼高性能 压缩 驱动丰富 SQL 线性扩展 PB级别 OLAP 统计函数 updated in real time 跨数据中⼼心 异步复制 最终⼀一致 Why ClickHouse
- 21. Why ClickHouse 对⽐比 ES⽅方案 CK⽅方案 Hive⽅方案 数据接⼊入 较多开源插件 ⾃自研 ⾃自研 实时性 准实时 准实时 离线 数据查询 DSL语⾔言 SQL⽀支持有限 ⽀支持复杂SQL 执⾏行行快 SQL规范，但是很慢 硬件成本 CPU密集型 CPU密集型 需要Hadoop⽣生态 存储成本 资源占⽤用多 ES的1/24 资源占⽤用⼀一般 通⽤用性 ⽐比较通⽤用 需要定义schema 需要定义schema 原始数据 ⻓长期保留留成本⾼高 特殊场景需要预聚合 提供物化视图 内部聚合 可⻓长期保留留
- 22. How it works •CK架构 Data Storage MergeTree ReplicatedMergeTree ReplacingMergeTree SummingMergeTree Log Memory Buffer Client PHP JDBC Python Golang Data Type SQL ODBC Cluster Access Quotas Kafka Distributed MaterializedView Node.js R Scala Julia Rust C++ Perl Ruby .NET HTTP Functions
- 23. • 列列式存储，异步merge，集群模式 • 向量量引擎+SIMD，超越tight loop • ⽀支持有限的delete操作 • 数据压缩，减少IO • 不不⽀支持事务 • 引擎给⼒力力 How it works •CK为什什么这么快？
- 24. How it works 类似LSM Tree，但是没有内存表，不不记录事务⽇日志 •MergeTree的Merge 图：LSMTree原理理图、LevelDB原理理图
- 25. How it works •MergeTree的Merge •block •part •partition Partition Parts Parts Parts 图：ClickHouse Merge示意图
- 27. base_table dist_table base_table dist_table base_table dist_table 读取真实数据 读 聚合返回 ck-xx.sina.com.cn 读取真实数据 How it works 集群⼯工作⽅方式 图：ClickHouse集群配置 图：ClickHouse集群读数据示意图
- 28. ZK base_table base_table base_table base_table How it works 数据复制 多源、多主、多向复制 数据‘互通有⽆无’ ⾃自带检测机制 ⾃自带同步机制（物理理复制） 依赖ZK ⾮非多数派写 图：ClickHouse数据复制示意图
- 29. 1-1 1-2 1-3 1-4 Cluster 1 N-1 N-2 N-3 N-4 Cluster N …… How it works 图：ClickHouse数据复制示意图 •令⼈人苦恼的复制架构
- 30. •令⼈人苦恼的复制架构 How it works 34⻚页PPT掌握ClickHouse的数据复制 图：ClickHouse数据复制示意图
- 31. Best practice CK架构 暂时不不使⽤用复制架构，仅使⽤用分⽚片架构 多个⼩小集群架构 scale out, not scale up 监控 基于Prometheus+clickhouse_exporter进⾏行行监控 关注读写量量、merge情况 增加基于system库的数据展示 管理理 备份 sql_top⼯工具，定位性能瓶颈 慢查询kill⼯工具 配置⽂文件备份 表结构备份
- 32. Best practice 图：ClickHouse SQL实时监控⼯工具 gif动图
- 36. 11 12 13 14 Cluster 1X 31 Cluster 3X 41 42 43 Cluster 4X 33 34 35 32 36 Best practice 37 38 44 45 46 47
- 38. Best practice 硬件 OS 参数 应⽤用 1. 合理理的硬件配置，⻅见后⽂文 2. 全内存数据，要考虑内存条的数量量 1. 强制部分内存空闲 2. 禁⽤用swap 3. 开启超线程 1. 调⼤大后台merge线程数：background_pool_size 2. 其他参数能明确的尽量量明确，不不要⽤用默认值 3. 调⼤大连接数、最⼤大并发查询数 4. 调⼤大⽤用户最⼤大可⽤用内存数 5. 开启query_log 6. ⽇日志trace级别 7. 启⽤用集群DDL 1. 使⽤用Golang驱动写数据 2. batch insert 5-10w起步 2. 禁⽌止业务select * 3. 合理理设置主键
- 39. CPU 内存 磁盘 E5-2650 v4 超线程 = 48core 8*16G = 128G 12*4T Raid5 = 40T ⽹网卡 双千兆bond0 = 2000Mbps Best practice
- 40. CPU 内存 磁盘 E5-2650 v4 超线程 = 48core 8*16G = 128G 12*4T Raid5 = 40T ⽹网卡 双千兆bond0 = 2000Mbps 不不要低于这个型号 内存条数也很关键 确保IO性能：1. 磁盘数量量 2. Raid 条带⼤大⼩小 写⼊入量量⼤大，注意带宽跑满 Best practice
- 41. Best practice •数据⽂文件10GB •32G内存 VS 128G内存 图：Intel CPU内部架构示意图
- 43. Best practice • 物化视图 • 内部的pipeline • 极⼤大提速 • 统计压⼒力力放在平时 • 注意多写带来的压⼒力力 • 原始表可以为NULL • 选择合适的物化视图引擎 原始数据表 数据写⼊入 物化视图1 物化视图2 物化视图3 idc, domain, http_code select ts, domain, count(*) group by ts, domain select ts, http_code, count(*) group by ts, http_code select ts, count(*) group by ts 图：物化视图逻辑图
- 44. Best practice • 映射类的数据怎么办？ • 放⼊入宽表：浪费空间 • 单独建表：需要join，不不利利于维护 • 字典 • File/HTTP/ODBC • MySQL/PG/MongoDB/ClickHouse/MS-SQL • 举例例 • 数仓中存储中⽂文，⽅方便便分析师查看 • MySQL中存储ISO-Code映射关系 • 查询时，映射为ISO-Code来绘制地图 • 避免条件过滤中，使⽤用词典 图：MySQL表字典数据 type为软删除标记
- 45. Best practice • 系统库 • 进程 • 复制状态 • Merge状态 • 数据表统计 • 集群 • query log 图：统计merge情况 图：clusters详情
- 46. Best practice • 系统库 • 进程 • 复制状态 • Merge状态 • 数据表统计 • 集群 • query log 图：统计压缩⽐比
- 47. Best practice • 系统库 • 进程 • 复制状态 • Merge状态 • 数据表统计 • 集群 • query log 图：统计part数量量、容量量
- 48. Best practice • 系统库 • 进程 • 复制状态 • Merge状态 • 数据表统计 • 集群 • query log 图：query log分析
- 49. 回写MySQL 直接查MySQL数据 Limit 10 by date 直接查数据⽂文件Best practice INSERT INTO FUNCTION mysql('host:port', 'db', 'tb', 'user', 'passwd', 1) SELECT xxx CREATE TABLE xxxx ENGINE = MergeTree ORDER BY id AS SELECT * FROM mysql('host:port', 'db', 'tb', 'user', 'password') clickhouse-client --query="SELECT partition, count() AS number_of_parts, formatReadableSize(sum(bytes)) AS sum_size FROM xxx WHERE xxxxx ;" --external --file=test.sql --name=parts --structure='partition UInt16,name String,table String,engine String' -h 127.0.0.1 GROUP BY xxxx ORDER BY xxxx LIMIT 10 BY date, city;
- 50. 其他问题 Best practice 1. 写分布式表，对端本地表被删，导致数据来回重传 2. 多parts下，mlocate的updatedb进程，造成⾼高IO 3. 多次OOM 4. hang死 5. 版本混跑，出现乱码
- 51. Best practice • Q1：DB::Exception: DDL background thread is not initialized • Q2：DB::Exception: Memory limit (for query) exceeded • Q3：DB::Exception: Unknown table function mysql • Q4：DB::Exception: Merges are processing significantly slower than inserts • Q5：Kafka引擎 • Q6：HDFS数据导⼊入 • Q7：多磁盘 • Q8：数据更更新、⾃自定义分区 • Q9：写分布式表带来的⼀一个问题：连接数暴暴增 • Q10：ClickHouse最⼤大⽀支持多少并发 • Q11：扩/缩容问题
- 55. “⼯工具选的好，下班回家早”