SLS SQL：融合ElasticSearch和ClickHouse的极速查询分析能力
日志常用于监控告警/问题调查等场景。通常而言，开发者在机器上操作日志的时候，常用的命令一个是grep，grep用于从日志中过滤出关键字；另一个命令是awk，可以做一些简单的计算。因而搜索和计算是日志上必须具备的能力。
在云原生时代，伴随着大量服务器的部署，上机器调查问题成为不可能；更别提各种容器的使用，想查看日志更不可能。因此需要把日志集中存储，并且提供查询和分析的能力。
一些开源软件为日志的查询和分析提供了解决方案。例如elasticsearch提供了搜索日志的功能，可以通过关键字搜索日志，使用的语法是自定义的SPL语法，有一定的学习门槛。尽管elasticsearch有聚合能力，但是能力非常有限，只能支持部分聚合场景，不能支持SQL全集。
clickhouse提供了分析日志的能力。clickhouse的日志分析速度非常强悍，在benchmark上表现非常优秀。但是由于clickhouse没有倒排索引，因此在搜索场景表现不佳。
我们都知道，在日志场景，搜索和分析是分不开的。大部分场景下，都是先搜索出部分日志，再进行聚合，类似grep ｜ awk的方式。因此，第一个问题是：怎么有效利用查询+分析这个特性加速计算呢？如果采用开源方案，就得部署ES+CK两套系统，成本加倍，运维人力也加倍。
第二个问题，开发者自建ELK集群，clickhouse集群，读写不分离，在业务高峰期，首先要保障数据写入的可靠性。在高峰期，如果有查询的需求，会对系统造成很大压力，影响系统稳定性，导致数据写入异常。数据能写入，却不能查，白白浪费存储成本。因此，这个问题就是，如何在支持高吞吐写入的同时，有能支撑高并发的查询分析？
第三个问题，关于自建集群的数据写入/查询分析的弹性能力。业务存在高峰和低谷，有的业务周末是高峰期，有的业务晚上是高峰期，像12306这种业务一年才一次高峰期。准备资源需要按照高峰期的业务需求来准备，到低谷时，资源会产生巨大的浪费。尤其对于查询分析这种场景，往往一次查询需要扫描大量数据，调用大量资源才能完成计算。因此查询分析对于弹性的能力要求更高。
为了满足日志场景这种搜索+分析的需求，SLS支持查询分析，推出特有的融合搜索+分析的能力，在语法上，采用这样的格式：
搜索 ｜ SQL分析
用户首先执行搜索，在搜索结果之上，再进行SQL的分析。其中SQL计算部分支持ANSI SQL，SQL全集。
1：一套系统融合ES+CK的查询和分析的能力，避免数据搬迁，在一份数据上就可以完成查询和分析，节省存储和带宽成本。
2：多租户大资源池，支持PB级别数据吞吐，同时也能支撑查询分析的高并发调用。
3：多租户大资源池，无需预留资源，若query计算复杂度较高/扫描的数据量较多，则可瞬间弹性分配大量资源出来。
4：性能上，在秒级别分析十亿到百亿日志，在20秒级别分析千亿日志。
5：SLS提供两种SQL计算实例，以应对不同的分析需求：
5.1 普通的需求使用免费的普通计算实例
5.2 针对千亿级别数据的计算需求，通过按量付费的独享实例完成
4.1 功能上对比：SLS融合了查询和分析能力
类别 | 小类 | ES | ClickHouse | SLS | |
查询 | 文本查询 | 索引查询 | 支持 | 支持 | |
分词 | 支持 | 支持 | |||
中文分词 | 支持 | 支持 | |||
前缀 | 支持 | 支持 | |||
后缀 | 支持 | ||||
WildCast | 支持 | 支持 | |||
数值查询 | long | 支持 | 支持 | ||
double | 支持 | 支持 | |||
Nested查询 | Json | 支持 | 支持 | ||
Geo查询 | Geo查询 | 支持 | 支持 | ||
IP查询 | IP查询 | 支持 | 支持，并且支持IP转换国家省市运营商，经纬度 | ||
上下文查询 | 上下文查询 | 支持 | |||
上下文过滤 | 支持 | ||||
分析 | 分析语言 | SPL | SQL | SQL | |
API接口 | API/SDK | API/SDK/JDBC | |||
通用聚合 | avg/sum/max/min等 | 支持 | 支持 | 支持 | |
bucketing | 支持 | 支持 | 支持 | ||
Metric | 支持 | 支持 | 支持 | ||
Matrix | 支持 | 支持 | 支持 | ||
PipeLine | 有限支持 | 支持 | 支持 | ||
数学统计 | 支持 | 支持 | |||
转换函数 | 时间日期 | 支持 | 支持 | ||
数学计算 | 支持 | ||||
类型转换 | 支持 | 支持 | |||
IP地理转换 | 部分支持 | 支持 | |||
同比环比 | 支持 | ||||
安全检测 | 支持 | ||||
Json | 支持 | 支持 | |||
正则式 | 支持 | ||||
URL | 支持 | ||||
逻辑和比较函数 | 支持 | 支持 | |||
二进制和位运算 | 支持 | 支持 | |||
lambda函数 | 支持 | ||||
字符串函数 | 支持 | 支持 | |||
地理和空间函数 | 支持 | 支持 | |||
电话号码函数 | 支持 | ||||
GroupBy | Agg | 支持 | 支持 | 支持 | |
Having | 支持 | 支持 | |||
Join | 支持 | ||||
窗口函数 | 支持 | ||||
机器学习 | 周期检测 | 支持 | |||
异常检测 | 支持 | 支持 | |||
相关性分析 | 支持 | ||||
频繁集 | 支持 | ||||
聚类 | 支持 | ||||
回归 | 支持 | 支持 | |||
贝叶斯 | 支持 |
5.1 SLS vs ClickHouse查询性能对比
CK环境：
8核32G , 600G ESSD
单节点
双副本版
147元/天
SLS测试环境：
张家口集群
SATA盘
测试语句：共采用9种不同的SQL
延时对比：越低越好
对比结果：
有4/9个查询，SLS延时低于clickhouse。但鉴于SLS采用的SATA盘，ClickHouse采用SSD，因而可以说SLS的性能和ClickHouse平分秋色。
在CPU密集型计算上(数据量少，计算复杂度高)，ClickHouse具有优势。
在IO密集型(即海量数据)，或者带有filter条件的SQL上，SLS具有优势。
在成本上可以分成两块内容，第一是购买资源的成本；第二是运维投入的人力成本。
6.1 SLS vs ClickHouse SQL查询成本对比
在5.1章节中9个测试中，不同SQL的成本如下：
查询成本对比：
SLS在5/9个查询中，费用成本占优。
6.2 SLS vs ClickHouse 存储成本对比
ClickHouse使用的是ESSD，费用是 1元/GB/月。
SLS的存储成本是0.35元/GB/月。
6.3 SLS vs (ElasticSearch + ClickHouse)运维成本
SLS作为云原生服务，免去了用户运维的人力投入成本
Elastic + ClickHouse | SLS | |
运维成本 | 投入人力运维/监控 | 免运维，0成本 |
容量规划 | 提前根据业务量采购资源 | 秒级别弹性扩展 |
参数调优 | 需要了解内部实现才能调优 | 调优问题交给SLS |
读写是否相互影响 | 大查询会影响数据写入可靠性 | 读写分离，互不影响 |
查询分析弹性能力 | 计算存储共享集群，计算能力受限 | 计算存储分离，计算能力可弹性扩展 |
从上述章节的对比中可以看出，ElasticSearch 和ClickHouse，每一个都可以单独在对比中和SLS平分秋色。而SLS同时融合了ES的查询能力和Clickhouse的分析能力。当用户同时需要查询和分析能力的时候，需要维护两套系统，成本加倍；而使用SLS，用户可以在一套系统上，一半的成本就可以同时完成查询和分析的需求。同时SLS节省了用户运维的压力，无需客户关心内部细节，只需放心使用即可。
SLS独享实例是为了满足用户对于大规模日志的查询需求而推出的低成本/大规模分析能力。一般而言，SLS普通的SQL能力就能过满足用户的需求了：在秒级别就能分析十亿到百亿级别日志，而且是免费使用。一些客户他们对SQL能力有更高的要求：
要求能够分析千亿级别日志
15个并发不能满足需求，要求提升到100以上
要求独享资源，不受其他用户的影响
为了满足以上这些需求，SLS退出了独享实例，帮助用户低成本分析日志。
独享实例，在能力上：
采用计算存储分离技术，计算资源不再受限于shard个数，可以根据数据量横向扩展
独享资源，提供高达100的并发分析能力
在成本上，通过以下4项手段，最大限度节省用户开支：
按量付费，而非按照预留资源付费。
按照实际使用的核付费，而非按照预留水位上限付费。
按照CPU时间付费，query在执行过程中的等待时间不计入费用。
可以设置水位上限，限制最大的核心数，防止个别query调用太多资源带来surprise的账单
1 控制台使用方法
在SLS控制台查询分析页面，可以直接输入SQL进行分析。如果需要分析大规模数据，可以点击图标
2 API/SDK使用方法
SDK调用GetLogs接口，参数query代表输入的SQL，如果要开启独享实例，有两种方法：
参数powerSql为true代表开启独享实例。
在query中设置session参数，格式为
* | set session parallel_sql=true; select ...即在竖线｜后边，select前边加上set session parallel_sql=true; 即可。
3 JDBC使用方法
JDBC中如果要使用独享实例，首先要执行set session parallel_sql=true; 然后再执行你的分析SQL即可。
总结和试用
本文介绍了查询和分析常见的解决方案以及其对比。对日志分析感兴趣的朋友们，欢迎点击“https://sls.aliyun.com/”，有各种日志的demo供把玩。也欢迎加群勾兑日志分析的最佳实践！
进一步参考
论坛分享视频：
https://developer.aliyun.com/live/246820
SLS（日志服务）云原生观测分析平台
https://www.aliyun.com/product/sls
SLS新版告警文档首页
https://help.aliyun.com/document_detail/207609.html
欢迎钉钉扫群加入阿里云-日志服务（SLS）技术交流, 获得第一手资料与支持
更多SLS的系列直播与培训视频会同步到微信公众号与B站，敬请留意
为您推荐（持续更新）