log

日志分析发展¹

Local Storage + Pssh Scan 跳板机上各种脚本，使用 shell 封装脚本查询；
Central Storage + Inverted Index 典型代表 ElasticSearch ； Lucene + Restful API + ELK(Logstash + Kibana) + Distribution； Raw Data + Inverted Index + DocValue
Central Storage + Column Storage + MR 典型代表 Hive ； Column Storage + Delta, Dictionary + Histogram； HDFS, OLAP
Central Storage + Column Storage + MPP 典型代表 ClickHouse ； MPP(Druid, Presto) + Hand Craft
Central Soraage + Scan 典型代表 Grafana + Loki

TP & AP

对比¹：

存储成本：Loki 存储是裸数据，经过压缩后理论上空间是最小的。 ES 存储内容最多，因此存储成本比较高。而 Hive, ClickHouse 因只有列存，相对较小（对于比较随机的纯文本数据，列存理论上和字符串压缩接近）。
分析能力：Hive 支持完整 SQL92 ，并且没有计算量的限制，分析能力最强。 ClickHouse 支持的是有限 SQL 集，对常见的场景足够用。接下来是 ES, Loki 最弱。
查询速度：在建立索引情况下， ES 是当之无愧的王者。基于 MPP 引擎的 ClickHouse 次之（对于带计算的分析， ClickHouse 是最强的）。分析成本： Loki 最高，读取数据后大部分工作都需要外围完成。
查询成本： ES 读取数据量最少，因此最优，接下来是 ClickHouse, Hive 和 Loki 。

第一阶段（数据产生 1 分钟内）：程序要看到实时业务，运营客服人员需要查看轨迹定位问题。这种场景一般都在小时内，查询频率比较高；在出问题后查询频率较高，需要对全部日志进行快速查询。
第二阶段（数据产生 1 - 2 小时左右）：业务需要洞察数据，一般都是小时级或天级别。查询频率一般，往往也都是针对于聚合后的数据；要求分析能力，百万次的特征查询或几十次 / 天的数据透视。
第三阶段（一天后）：审计需要，业务需要看趋势数据。查询频率比较低，往往是点查（例如回溯一个历史问题）。着重考虑成本，查询频率比较低。

原始数据量为 X，倒排索引的数据量为原始数据的 a 倍，列存储空间为原始数据的 b 倍，需要预留的空间（例如 redo log, reserved space ）为 c 倍，每 GB 介质成本是 e，为了保证可靠性，需要的副本是 d。

存储成本 Y = X × (a + b + c) × d × e ，不同架构的成本在 0.05 - 3.12 Yuan/GB·Month 。

查询成本在固定场景下可以确定需要消耗的资源，在突发场景下单独考虑。

日志是一种半结构化数据，由特定的代码生成的。（也可以是结构化数据，如 JSON）。

预处理 -> 聚类 -> 模板获得 -> 模式融合