clickhouse官方文档_Siem落地方案：初识clickhouse

简述

首先，ELK是支持SIEM，一开始我也是用ELK进行数据收集、数据展示和数据分析，但是逐渐到后面，有一些功能需求使用查询语句是非常复杂，虽然ELK提供云SIEM，但是作为动手能力非常强的人(穷)，就有放弃ELK这个想法。

后来某大佬说clickhouse非常香，于是就开始去了解这个东西。

clickhouse(以下简称CH)是列式数据库，作为数据库小白，当然要查询一下与传统行式数据库的区别，看起来好像列式数据库很厉害。

下图是官方对于行式和列式数据库查询的对比，可以看到行式是扫描全表，而列式数据库是直接找到相关列的数据，查询速度不言而喻。

说明一下，应用场景不同采用的架构方案不同。为什么CH会适合做SIEM呢？咱们看看官方对于CH功能特点描述

OLAP场景的关键特征

• 大多数是读请求(siem展示就是查询语句去查询，所以大多数是读请求)

• 数据总是以相当大的批(> 1000 rows)进行写入(成千上万服务器的日志量存储怕不止1千行吧)

• 不修改已添加的数据(siem就是要日志存储，要修改他数据干嘛)

• 每次查询都从数据库中读取大量的行，但是同时又仅需要少量的列(查询特定列的大量行内容)

• 宽表，即每个表包含着大量的列(对的，有大量的字段，这边字段有上百个)

• 较少的查询(确实不多，siem展示的SQL也不超过几百条查询语句)

• 对于简单查询，允许延迟大约50毫秒(这个是允许的，相对于ES查询，这个真香)

• 列中的数据相对较小：

  数字和短字符串(例如，每个URL 60个字节)

• 处理单个查询时需要高吞吐量(每个服务器每秒高达数十亿行)

• 事务不是必须的(不用做事务操作)

• 对数据一致性要求低(这块还没有研究，目前没这个需求，以后出现再补回来)

• 每一个查询除了一个大表外都很小

• 查询结果明显小于源数据，(数据被过滤或聚合后能够被盛放在单台服务器的内存中)

那么按照这些关键特征，很满足咱们对于siem存储和查询的功能，接下来就实战看看是不是如此。

安装

官方有yum源，可以直接通过yum进行安装。

导入仓库地址信息

sudo yum install yum-utilssudo rpm --import https://repo.clickhouse.tech/CLICKHOUSE-KEY.GPGsudo yum-config-manager --add-repo https://repo.clickhouse.tech/rpm/stable/x86_64

安装CH服务端和客户端。

sudo yum install clickhouse-server clickhouse-client

安装之后，启动服务

/etc/init.d/clickhouse-server start

使用客户端进行进去，默认是走9000端口通信，并且没有密码认证

实战

CH核心是数据引擎，也就是table处理方法，我这边使用TinyLog和MergeTree，前者存储数据量最好不能过百万，用来做一些表的对比和记录；后者是可以做基于时间的时序数据库，用来后面grafana展示使用的。具体的细节可以参考这边文章：ClickHouse 快速入门开发

我这边补充一下细节，测试发现CH不支持存储过程，假如要写递归功能，抱歉不支持。不过CH定义了递归功能，针对于找爸爸的功能(子ID找父ID)，说实话这个功能还是有缺陷的，测试发现，量大会出现找爸爸错误。

CH查询语句跟MYSQL差不多，大体上是一致的，不同的地方可以翻文档查

按照官方文档，我下载了他们脱敏的数据库，导入进去，有两个表。

查看其中一个表结构，都有133个列

我这边测试机器是双核8G虚拟机，查询速度3亿行数据，需要1分钟，因为列式数据库是吃内存的，所以内存越大查询速度越快。

查询两个列，可以看到速度简直无敌

聚合查询也是如此

精彩推荐