查看clickhouse版本_查看clickhouse版本号

clickhouse数据压缩对比

cdn_log_realtime zstd压缩

Clickhouse 数据压缩主要使用两个方案LZ4和ZSTD

查看clickhouse版本_查看clickhouse版本号

查看clickhouse版本_查看clickhouse版本号

现在就可以在HIVE中查看数据了。

LZ4解压缩速度上会更快，但压缩率较低，

ZSTD解压缩较慢。但是压缩比例较高。

以下测试主要验证业内测试的结论，测试的zstd数据会多一点，测试不是十分严谨，仅供参考。

开发(dev) 机器数量：3 cpu：40core 内存：256G disk：2.0T10

kafka TOPIC: cdn-log-ysis-realtime。可消费数据总量363255827。数据消费4次到ck。

cdn_log_ysis_realtime lz4压缩

--指定incl

10000000000 --数据部分的小大小

zstd --压缩算法，zstd和lz4

执行sql ：SELECT table AS 表名 , sum(rows) AS 总行数 , formatReadableSize(sum(data_uncompressed_bytes)) AS 原始大小 , formatReadableSize(sum(data_compressed_bytes)) AS 压缩大小 , round((sum(data_compressed_bytes)/sum(data_uncompressed_bytes))100, 0) AS 压缩率 FROM .parts WHERE (database IN ('default') AND (table = 'cdn_log_ysis_realtime') ) GROUP BY table

执行sql ：

SELECT table AS 表名 , sum(rows) AS 总行数 , formatReadableSize(sum(data_uncompressed_bytes)) AS 原始大小 , formatReadableSize(sum(data_compressed_bytes)) AS 压缩大小 , round((sum(data_compressed_bytes)/sum(data_uncompressed_bytes))100, 0) AS 压缩率 FROM .parts WHERE (database IN ('default') AND (table = 'cdn_log_realtime') ) GROUP BY table

执行sql :select toDateTime(intDiv(toUInt32(its),6执行sql : select toDateTime(intDiv(toUInt32(its),60)60) as t, count() as t_c, g(speed) as t_v, quantile(0.99)(speed) as t_99, quantile(0.90)(speed) as t_90 , quantile(0.75)(speed) as t_75 , quantile(0.50)(speed) as t_50 , quantile(0.25)(speed) as t_25 from default.cdn_log_ysis_realtime_all where day='2020-12-17' group by t order by t_v desc0)60) as t, count() as t_c, g(speed) as t_v, quantile(0.99)(speed) as t_99, quantile(0.90)(speed) as t_90 , quantile(0.75)(speed) as t_75 , quantile(0.50)(speed) as t_50 , quantile(0.25)(speed) as t_25 from default.cdn_log_realtime where day='2020-12-25' group by t order by t_v desc

执行sql：SELECT 'ZSTD' as 压缩方式 , table AS 表名 , sum(rows) AS 总行数 , formatReadableSize(sum(data_uncompressed_bytes)) AS 原始大小 , formatReadableSize(sum(data_compressed_bytes)) AS 压缩大小 , round((sum(data_compressed_bytes)/sum(data_uncompressed_bytes)) 100, 0) AS 压缩率 FROM cluster(ctyun31, , parts) WHERE (database IN ('default') AND (table = 'cdn_log_realtime') ) GROUP BY table union all SELECT 'LZ4' as 压缩方式 , table AS 表名 , sum(rows) AS 总行数 , formatReadableSize(sum(data_uncompressed_bytes)) AS 原始大小 , formatReadableSize(sum(data_compressed_bytes)) AS 压缩大小 , round((sum(data_compressed_bytes)/sum(data_uncompressed_bytes)) 100, 0) AS 压缩率 FROM cluster(ctyun31, , parts) WHERE (database IN ('default') AND (table = 'cdn_log_ysis_realtime') ) GROUP BY table

测试不是十分严谨，ZSTD的ck表的数据多一点，但是不影响测试结果，仅做参考。

压缩能力上，ZSTD的压缩比例为 22% ，LZ4的压缩比例为 27% ，ZSTD的压缩性能更好。但是效果不是很明显。

查询能力上，冷数据查询，两者相不大。热数据方面，ZSTD为 3.884s ，而LZ4为 1.150s 。ZSTD查询时间在 3.37倍 以上，LZ4的查询能力更强。

综上所述，建议使用LZ4。

集群数据量后期预估，按当前使用lz4压缩方案，3分片1副本，计算3 5.5 100.8(按磁盘多使用80%算) 的硬盘能存储大概多少数据。

一天磁盘消耗 (10000000000/1453023308.0 84.98)/1024.0=0.57TB

能存储天数 3 5.5 10 0.8/0.57=231.57 day。

一天数据1000亿

ClickHouase读写HDFS

按照提示，修改gemfile：

先在ClickHouse建本地表，并造测试数据备用

先在HDFS创建数据的目录

将数据从account__src（存储在CK中） 导到 account__hdfs（如上，配置jdbc连接信息即可。存储在HDFS中）

这样就成功将ClickHouse的数据导出到HDFS中了。

注意事项：

直接用刚刚从CK导出的数据

这样就可以了。

分别查看不同机器的压缩比例为了验证数据，在HDFS中增加一个文件。

在ClickHouse中查看发现数据多了一倍

droppartitionclickhouse是异步么

编译：

droppartitionclickhouse是异步么是异步的。它是计算机程序中的一个命令。据相关资料查询显示该命令是异步执行的，可以通过查看表.mutations来查看命令的是否执行。clickhouse默认是不支持实时删除表中的数据，数到HDFS上查看一下据的删除通常是热数据（第二次查询）异步进行。

测试ClickHouse中写入Parquet格式数据到Hive

clickhouse不同压缩算法测试对比，LZ4。

先在HDFS创建目录

DB::Exception: Allocator: Cannot mmap 64.00 MiB., errno: 12, strerror: Cannot allocate memory.

在CK创建外部引擎表在CK创建表

创建CK表成功

看到数据啦

执行查询语句

数据出来啦！！

clickhouse-FREEZE分区作

参考文档：

1，冻结表

注意：生产环境一般都是使用多磁盘存储策略，硬链接不是默认的/var/lib/clickhouse/shard/路径，是集群配置的多磁盘存储路径与store文件夹平级的路径，如我这边就是 /data/clickhouse 路径。

注意：生产环境会有多个路径，都需要拷贝备份，注意记住path路径中的md5值。

3，备份文件到其他的目录（将路径也拷贝了，方便记住md5clickhouse不支持设置多数据目录，为了提升数据io性能，可以挂载虚拟券组，一个券组绑定多块物理磁盘提升读写性能；多数查询场景SSD盘会比普通机械硬盘快2-3倍。值）

4，清空表建立好上面的分布式表之后就能读集群所有的数据了。我这里贴一下user表的所有数据。数据（未破坏表元数据信息）

5，restore表数据

注意：PART 和 PARTITION的区别。拷贝备份的数据到store路径下，切记md5路径要和之前的一样，但是磁盘可以随机选一个。查询数据，可以发现数据已经恢复。

6，删除s结束hard目录下的文件。

alter table xxxx freeze 基本上没啥人会这样玩，而且要作集群，机器一多就。。。比较麻烦 ！！！一般是那种自动化的运维工具，这个功能还是可以用用。

数据服务平台

还有一点需要指出，虽然CK是分布式存储，但是在执行聚合运算的时候，仍然是在单机上，所以会比较消耗内存。

对于外部用户(分析师，项目团队)来说，报表/元数据是重要的，通过这两个系统，可以很容易的知道数据的基本情况以及统计结果。

对于内部用户(数据团队)来说，调度系统/质量是必不可少的，调度系统可以让任务准时的完成，质量可以保证提前发现数据问题。

展示出来的数据才有意义。所以要把分析结果正确合理的展示出来，表格，图标，热力图，漏斗图，对于不同的数据用合适的方式展示出来，让数据理解起来更容易。

除了研发之外，分析师，数据pm，都需要自己查看数据。而离线/实时两种数据场景中，需要使用比如mysql/hi231.57/10=23.1day。ve/kylin/druid/clickhouse等工具，对于用户来说，需要知道这四种平台的使用方法，所以需要一个统一的系统，除了例行报表的数据/图表展示之外，还要做到屏蔽不同数据引擎，让用户在一个界面轻易的查多个平台甚至跨平台的数据。

保证任务的稳定执行。

众多计算逻辑，包括hql，Ja程序，python程序，spark程序，需要在一定条件下顺序执行，可能是时间驱动:每天3点开始执行，可能是条件驱动:上游任务都执行完再进行当前步骤。在这个背景下，调度系统就产生了。

数据的说明书。

描述数据的数据，包括表的基本信息(表层级，说明，字段内容，建表语句，存储位置等)，数据信息(数据示例，数据类型，枚举值列举举例，数值盒图展示)，增长信息(日新增条数，数据量级)，数据血统(数据流转路径)等。通过查看元数据系统，就可以知道表的详情以及作用。

我们无法保证数据不会出问题，但是我们一定要先发现问题并排查原因。不要等项目发现问题了找我们问，这样就会比较被动。

通过以下方面对数据进行检查。

在工具平台的一天数据100亿共同努力下，更好的处理/使用数据，提供良好的数据服务。

分布式物化视图在clickhouse如何实现？

数据平台包括两个方面，一个是架构平台，包括各种系统的搭建与维护，例如hdfs/hive/spark等，另一个就是这次要是的，服务平台。

物化视图在数据层面做指标大宽表有着举足轻重的作用，分布式物化视图是对物化视图存储的数据进行分布式读取。

之前我们有一个介绍过物化视2，查看表分区磁盘分布图的文章，详情请点击：clickhouse物化视图的应用，这里我们已经介绍过物化视图是什么，如何使用。

下面我们这里来介绍一下分布式物化视图的使用。我们这里使用的是分布式clickhouse集群。版本是：20.3.10.75，下面我们就来详解分布式物化视图在clickhouse的使用。

1：首先我们还是来建立三个表。

2：分别在不同的插入数据，我这里有两个，我们每个插入2条数据。 1如下：

2如下发现数据问题。：

3：插入完数据之后，我们去每个查询，因为我们需要读所有的数据，则我们需要建一下分布式表来读数据。下面是建分布式表的语句。

4：上面是基础的数据表，这里我们开始建物化视图表。下面的sql是把用户表，用户信息表，绑定表进行组合成大宽表，下面的脚本我们是在每个上存了一份快照，实际业务中我们是写数据到一个，不会一份数据存多份。我这里做例子就这么使用。

好了，到这里我们已经可以通过物化视图分布式表读每个的物化视图了，业务中我们基于物化视图来做大宽表，读取物化视图分布式表是非常常见的。我之前记得之前clickhouse物化视图在微信的应用这篇文章也是比较类似。

总结 ：

Logstash同步Hive和Clickhouse

工作中我们遇到了把Hive数据同步到Clickhouse的业务需求，一开始我们写Spark任务，用SparkSQL读Hive，再用JDBC写入到Clickhouse。

后来，随着要同步的表越来越多，每次都写Spark任务，成本就显得有些高了。于是，写了一个通用的Spark任务，指定Hive表、字段，指定Clickhouse表、字段，每次指定不同的参数。

再后来，业务越来越复杂，不仅是简单的同步，而是要支持更复杂的SQL，结果进行数据类型转换、值转化等，然后再插入Clickhouse。

这不是ETL要干的事儿吗？！

当然，继续增强之前的Spark，完全可以实现这个功能。但是说到ETL，不是有专业强冷数据（次查询）大的Logstash吗，为什么要重复造轮子？

经过一番调研，还真有人写了Logstash插件，用来导出数据到Clickhouse： logstash-output-clickhouse

输出端搞定了，输入端怎么搞呢？很建达，用JDBC插件就可以了。

需要说明的是，相关的jar包比较多，需要给全了，否则会有各种ClassNotFoundException。完整的jar列表为：

这些jar与hive环境版本一致，我们用的是CDH版，所以都是从CDH目录下找到的jar。

Clickhouse插件使用说明参考：

主要说下安装过程。

说明文档里说的 bin/logstash-plugin install logstash-output-clickhouse 方式，没有安装成功，所以只能自己编译安装。

先clone源码，然后进入源码根路径：

此时，若没有安装ruby环境，按照提示安装一下，再编译。

安装数据仓库建设，数据使用的辅助/后盾。：

此时，如果logstash版本是5.x，可能会遇到一个错误：

修改logstash-mixin-_client的版本：

原来是>6且<7，改成>5且在对应的分区目录shard下创建一个 linux 硬链接，不影响源表的读写，不占用额外的磁盘空间 ，也正因为如此切记不要修改文件权限，否则会破clickhouse的原始数据。<6。

然后，再次编译、安装，就可以了。

按照文档中的使用说明，配置Clickhouse连接信息即可：

这部分工作可以放在filter里处理，各种filter插件就不说了，参考logstash文档吧。

clickhouse的listen.xml为什么不存在

在/etc/metrika.注意：当前作的前提是没有破坏表的元数据，如果元数据破坏，需要拷贝到clickhouse的指定目录下，我这边是在 /ssd2/clickhouse/metadata。xml

版本不再使用listen.xml配置TCP。从clickhouse19.14.0.3版本开始，clickhouse将使用默认的配置文件（/etc/clickhouse-server/config.xml）来配置TCP，而不再使用listen.xml文件。clickhouse的listen.xml文件是用于配置TCP监新版clickhouse提供了一个实验性的功能，那就是我们可以将clickhouse伪装成mysql的一个备库去实时对齐mysql中的数据，当mysql库表数据发生变化时会实时同步到clickhouse中；这样就省掉了单独维护实时spark/flink任务读取kafka数据再存入clickhouse的环节，大大降低了运维成本提升了效率。听器的，它通常位于clickhouse-server的config目录下。