本文由 简悦 SimpRead 转码， 原文地址 www.toutiao.com
这篇文章我们不比较哪个更牛，应该选哪个，而是从软件背后去分析用户需求是什么? 先科普一下日志分析软件历史: 方案 A:Local Storage +
ES 和 ClickHouse 都是开源火得不行的软件，日志分析究竟该用哪个一直争论不休。这篇文章我们不比较哪个更牛，应该选哪个，而是从软件背后去分析用户需求是什么？有没有更好的方法来解这个问题。
方案 A：Local Storage + Pssh 扫描派（代表作：跳板机上各种脚本）
在 Unix 设计哲学中，没有什么是不能用管道完成的。十年前没有大数据概念的时候，日志对研发而言就是随时抛弃，偶尔查问题需用一用。因此设定一定大小回滚策略 + Pssh 就是最不折腾的选择，所以我们在跳板机上经常能看到各种封装的 shell 脚本，只需要几个参数就能快速检索。方法简单粗暴，带来的局限性也挺多，例如磁盘坏数据丢失、速度慢、对线上有性能影响等。非集中式日志检索技术随着大数据兴起，使用场景逐步在萎缩。
方案 B：Central Storage + Inverted Index 派（代表作：ES）
说起 ES 不得不提到背后 Lucene，Lucene 实际是一个比 Hadoop 还早的爷爷辈软件，因为他们的作者是同一个人。Lucene 是一个面向搜索引擎的倒排库，可以直接用来索引文档并提供接口来进行查询。但 Lucene 本身是一个 Lib，离直接使用还有部分集成工作，之后 Apache 陆续有了 Solr、Nutch 等项目来帮助 Lucene 发展，但依然是不温不火好几年。2012 年 ES 诞生后，通过优秀 Restful API，分布式部署等机制把 Lucene 使用推向一个新高度。而之后 ELK（Logstash + Kibana）组合把在日志易用性上大大加速。ES 特点是通过 O（1）索引，快速在海量数据上拿到结构，相比暴力扫描的方法，倒排索引速度和扫描数据量不是线性相关的。
我们来看看 ES 成本模型，ES 模式是通过预处理生成索引，把之后检索变成常数级操作。ES 存储构成为：原始数据（正排）、倒排索引（Inverted Index）、列存储（DocValue）3 种类型。数据流入时需要消耗部分机器来对数据进行编码，但在查询时只需要消耗少量的资源便可快速找到数据。之后无论多少次查询，实际成本几乎是不变的。但带来的副作用是数据膨胀，例如 AWS 在 ES 使用建议上，一般推荐预留 2-3 倍的空间来应对数据存储（在 2 Replica 情况下）。
方案 C：Central Storage + Column Storage + MR 派（代表作：Hive）
Hadoop 出现提供了 HDFS 分布式存储引擎，而 Hive/Spark 等 MR 引擎为了加快执行速度，天然集成了 Column Storage（列存储类型），Column Storage 对于类型固定的列有良好的压缩率，例如可以通过 Delta、Dictionary 等编码技术压缩原始数据大小，当查询时通过 Histogram 进行快速跳转。Column Storage 对 OLAP 计算很友好，数据量小又能做启发式搜索。ES 在五年前也推出了 Column Storage 类似的 Doc Value 技术，可以通过 ES API 来对列数据进行分析。
Column Storage 一般会搭配一个计算引擎，基于 MR 的 Hive、Spark 提供基于磁盘的外排能力，除了执行速度慢一些之外，几乎能够胜任所有的 SQL92 查询分析需求。
方案 D：Central Storage + Column Storage + MPP 派（代表作：ClickHouse）
MR 方案可以通吃从小到大的各类场景，但带来的缺点是速度不够快，并发不高，不适合实时性高的场景。之后 Druid、Presto 等 MPP 引擎诞生通过内存来代替磁盘交换，把 Query 执行速度大大提升。最近 2 年 ClickHouse 横空出世吸引了不少粉丝，ClickHouse 秉承俄罗斯人的简单粗暴出奇迹特点，把用 Hand Craft 计算发挥得淋漓尽致。虽然 ES 也在向 OLAP 领域进军，ClickHouse 未来也会做倒排索引，但这背后存在一个不争的事实。日志分析除了日志的 TP，也会有少量的 AP 情况需要混合考虑。
Hive 和 MPP 成本模型如下，数据写入一般需要前端机对数据进行转换，在读取时需要对数据进行排序过滤等，消耗一部分计算资源。
方案 E：Central Storage + 扫描类（代表作：Grafana-Loki）
扫描压缩后的原始数据，看起来像是 “返璞归真” 的技术退化。但似乎又是一种顺应时代的做法。这个方案典型的代表是 Grafana 旗下 Loki。Grafana 因为没有存储技术的积累，因此光脚不怕穿鞋的，直接出了一个将日志直存对象存储 + 扫描方案。这个背后的理由也说的过去，云存储是未来是能够保证持续间隔竞争力的，而大部分日志是写多读少的，在一些场景下慢一些似乎也没什么差别。
Loki 方案占据存储成本极少，原始数据会以压缩方式写入，同时也可以通过列存 (Parquet) 来存储数据，以加快分析速度。当查询时解压缩原始数据，进行过滤，最后拿到结果。由于受限单机引擎，在查询速度、分析能力上比不过 ES、Hive、ClickHouse 等方案，但胜在便宜。如果数据只是偶尔查一查，要啥自行车呢。
综合对比
我们把上述方案做一个对比，如下：
- 存储成本：Loki 存储是裸数据，经过压缩后理论上空间是最小的。ES 存储内容最多，因此存储成本比较高。而 Hive、ClickHouse 因只有列存，相对较小（对于比较随机的纯文本数据，列存理论上和字符串压缩接近）。
- 分析能力：Hive 支持完整 SQL92，并且没有计算量的限制，分析能力最强。ClickHouse 支持的是有限 SQL 集，对常见的场景足够用。接下来是 ES、Loki 最弱。
- 查询速度：在建立索引情况下，ES 是当之无愧的王者。基于 MPP 引擎的 ClickHouse 次之（对于带计算的分析，ClickHouse 是最强的）。
- 分析成本：Loki 最高，读取数据后大部分工作都需要外围完成。
- 查询成本：ES 读取数据量最少，因此最优，接下来是 ClickHouse，Hive 和 Loki。
从需求角度而言，是否有一种更综合架构？
为什么会有这么多的选择呢？主要是由二个因素决定的：处理需求 vs 实现成本。我们先从需求出发，看看业务需要什么？
对 Nginx、App 访问日志而言，一般有如下典型用途：
- 第一阶段（数据产生 1 分钟内）：程序要看到实时业务，运营客服人员需要查看轨迹定位问题。这种场景一般都在小时内， 查询频率比较高。
- 第二阶段（数据产生 1-2 小时左右）：业务需要洞察数据，一般都是小时级或天级别。查询频率一般，往往也都是针对于聚合后的数据。
- 第三阶段（一天后）：审计需要，业务需要看趋势数据。查询频率比较低，往往是点查（例如回溯一个历史问题）。
第一阶段：实时性和延时更重要
这个阶段数据实时性变得无比重要，例如用户付款投诉时，我们需要快速通过 TraceId 来定位后台的用户行为。我们需要根据业务访问的 QPS、下单率等快速在日志中找到错误日志。需要根据业务流量情况、趋势来调度资源。
典型的访问如下：
这个阶段大部分分析都是集中在最近 5 分钟时间内的数据，这些数据会被频繁访问到，并且 Query 条件变化范围会非常大。比较典型组合是 TSDB/NoSQL/SQL + ES + ClickHouse，存储和计算成本会稍微大一些，但比起线上关键业务而言花一些钱还是值得的。
第二阶段（天级）：比拼分析能力
第二个阶段业务需求会更复杂，这个阶段主要面向的是精细化需求。例如从延时、成功率等指标去度量接口稳定性，服务质量等。运营根据数据对比来发现群体特征，用来构筑质量体系等。运营会根据数据来确定投放、牵引等策略。
这个阶段访问模式包含两种：
第三阶段（月级）：比拼成本
这个阶段数据的访问往往两极分化：趋势型分析，一般可以通过预处理技术提前降低数据量来解决。大规模数据的统计、大规模数据中查找极小部分数据。后者一般发生的概率非常低，但每次几乎都是突发需求，如果能在较短的延时内获得结果对体验是最好的。
定量分析：
- 存储成本
原始数据量为 X，倒排索引的数据量为原始数据的 a 倍，列存储空间为原始数据的 b 倍，需要预留的空间（例如 redo log、reserved space）为 c 倍，每 GB 介质成本是 e，为了保证可靠性，需要的副本是 d。
存储成本为 Y=X (a+b+c) de，经过我们对不同存储计算，每 GB 成本范围在 3.12 元 / GBMonth -> 0.05 元 / GB*Month 之间。当然这个背后查询延时与 IOPS 也是不同的，例如成本更高方案可以支持 1000 次 / S IOPS，而低成本方案只能做到 5 次 / S，在多人使用情况下可能会被打爆。
- 计算 / 处理成本
做个简单的计算，可以分解为，需要处理 X GB 原始数据，需要消耗的资源。在业务模式固定场景下，我们可以根据处理费用，查询费用计算出需要消耗的计算资源，例如 100Core、50GB 内存，最大化降低计算成本。
在有一些特殊场景下，例如突然遍历几个 TB 数据，计算、查询某个结果情况下，需要额外计算机器 + 提供额外 IOPS 能力。
从以上定量分析我们可以得到：
- 不同类型的方案，本质上是 IOPS、Latency、成本三个因素的平衡。
- 三个因素不同的比例，满足各个阶段业务需求，是否需要实时性、访问频率如何、IOPS 如何，突发性怎么样。
- 不同方案之间，可以通过数据同步工具（例如 Kafka）来迁移。
阿里云如何解决这个问题？
日志分析是一个如此通用的需求，在阿里、蚂蚁金服内部也有这样一套基础设施 - SLS（日志服务），支撑数万工程师每日十几亿次的分析需求，涉及研发支撑（DevOps）、大数据运维（AIOps）、大数据安全（SecOps）、成本分析与增长（BusinessOps）等场景。
SLS 解决以上问题主要思路如下：
- 一套统一数据访问接口
ES、Hbase、MySQL、ClickHouse、Hive 都有自己的 API，为了能够对接不同的应用场景，为了使用得在上层做大量的开发工作。当目标系统发生变化时，我们需要数据迁移工具，例如 Kafka、Flink 等进行数据 ETL 与转化。
而在 SLS 设计中，数据的查询分析都通过 SQL 进行（也能通过标准 JDBC 访问），这样无论是查询时序数据、Log、Trace 数据都能快速拿到结果，最大程度上支持 DevOps 工具、上层业务创新。
更多参考：
- 从运维和 SRE 角度看监控分析平台建设
- Serverless 存储 + 计算设计，低成本弹性能力
SLS 提供统一存储与计算能力，相对其他方案：
- 默认提供 N 副本（对用户透明），保证可靠性。热数据存储单价为 0.35 元 / GB*Month，冷数据存储单价仅为 1/3（即将上线），超过 6 个月数据，在使用不变情况下可以设置为冷存储降低成本。
- 写入按量收费，无预留收费，可以精确规划成本。
- 查询分析免费（99.9% 情况下），每秒钟可以提供千级 IOPS 查询能力，几十 IOPS 分析能力（相当于能并发 Hive/ClickHouse 查询），无需预留资源。
- 当因业务需要突发大数据查询场景时（0.1% 情况），可以申请独立计算资源加速，而无需数仓方案等待几十分钟出结果。
更多参考：
- SLS SQL：融合 ElasticSearch 和 ClickHouse 的极速查询分析能力
- 提供 BuildIn 内部数据流动，降低成本
素材及格式整理：IT 运维技术圈
来源： https://zhuanlan.zhihu.com/p/396211457
小编有话说
➤推荐服务：
向下滑动查看更多
点击【IT 面试精选 】查看全网最权威的一线大厂面试真题及面试经验，每天更新哦!
点击【IT 路边社】查看实时更新的 IT 新闻资讯
点击【互联网资料存储站】获取全网最全运维流程文档、表格、脚本、架构、等保资料等 点击【安全加固】获取最新安全加固脚本
点击【一键 iptables 脚本】获取 iptables 自动设置脚本
回复【加群】群满啦!~ 添加波哥微信拉您进群