为啥考虑引入Clickhouse：
1、单表查询性能很高（日志场景下也不需要JOIN，刚好避开了它的弱点）
2、高压缩比
目前生产环境使用的数据同步方案
1、flink对微服务的topic数据清洗后，丢到一个新的Kafka的topic里面
2、2台ck完全独立部署，使用 clickhouse_sinker去消费数据（使用supervisor保活）
3、在2台ck前面配置SLB，前端展示可以用的redash （最好还是自研个后台查询界面，可以更好地限制查询的时间范围，避免badsql把ck搞OOM了）
ck里面建表方法
step1、创建表：
实例1-2上都一样执行：
简单的做些查询上的测试
分区操作
磁盘空间占用的对比
写入性能
通过clickhouse-sinker往ck里写数据，大约在53w每分钟，约9k每秒。速度还是很赞的。同时，写入期间，ck的负载变化不大。
前端界面
前端界面不擅长，就参考专业同学的模块，改了改，大致如下：
主要是限制住了必须传开始时间和结束时间、服务的名称，这样基本上就可以限制住查询的内存占用了。
当然，有了flink后，我们还可在flink另外开一个实时统计的任务，统计每个微服务的分钟级的报错情况。这块就是偏java开发层面了。 可以看下我们架构组的同学的效果：
附录：
一些运维SQL写法
参考：https://altinity.com/blog/2020/5/12/sql-for-clickhouse-dba