Siem落地方案:初识clickhouse – 作者:陌度

简述

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

1598339716.png!small

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

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

图片[2]-Siem落地方案:初识clickhouse – 作者:陌度-安全小百科

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

Row oriented

Column oriented

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

OLAP场景的关键特征

  • 大多数是读请求(siem展示就是查询语句去查询,所以大多数是读请求
  • 数据总是以相当大的批(> 1000 rows)进行写入(成千上万服务器的日志量存储怕不止1千行吧
  • 不修改已添加的数据(siem就是要日志存储,要修改他数据干嘛
  • 每次查询都从数据库中读取大量的行,但是同时又仅需要少量的列(查询特定列的大量行内容
  • 宽表,即每个表包含着大量的列(对的,有大量的字段,这边字段有上百个
  • 较少的查询(确实不多,siem展示的SQL也不超过几百条查询语句)
  • 对于简单查询,允许延迟大约50毫秒(这个是允许的,相对于ES查询,这个真香
  • 列中的数据相对较小: 数字和短字符串(例如,每个URL 60个字节)
  • 处理单个查询时需要高吞吐量(每个服务器每秒高达数十亿行
  • 事务不是必须的(不用做事务操作
  • 对数据一致性要求低(这块还没有研究,目前没这个需求,以后出现再补回来)
  • 每一个查询除了一个大表外都很小
  • 查询结果明显小于源数据,(数据被过滤或聚合后能够被盛放在单台服务器的内存中

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

安装

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

导入仓库地址信息

sudo yum install yum-utils
sudo rpm --import https://repo.clickhouse.tech/CLICKHOUSE-KEY.GPG
sudo 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端口通信,并且没有密码认证

1598343260.png!small

实战

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

我这边补充一下细节,测试发现CH不支持存储过程,假如要写递归功能,抱歉不支持。不过CH定义了递归功能,针对于找爸爸的功能(子ID找父ID),说实话这个功能还是有缺陷的,测试发现,量大会出现找爸爸错误。
CH查询语句跟MYSQL差不多,大体上是一致的,不同的地方可以翻文档查
按照官方文档,我下载了他们脱敏的数据库,导入进去,有两个表。
1598344410.png!small
查看其中一个表结构,都有133个列

1598344241.png!small

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

1598344584.png!small

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

1598344733.png!small

聚合查询也是如此

1598344800.png!small

来源:freebuf.com 2020-08-25 16:42:32 by: 陌度

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论