日志系统的尽头是OLAP引擎？

本文链接：https://blog.csdn.net/u013613428/article/details/127047255

互联网企业在降本增效的压力下，越来越多地采用基于OLAP引擎的自研日志系统，以提高分析效率。这类系统适用于结构化、固定格式的日志分析，如API调用日志，但在非互联网行业，特别是传统行业中，由于日志格式多样性和复杂业务流程，OLAP引擎的日志系统可能存在局限性。自研虽能降低成本，但需谨慎评估总体拥有成本和长期发展需求，避免成为一次性项目。未来的日志系统应考虑全观测性，集成度和整体解决方案更为关键。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

降本增效主旋律下的生存之道

最近几年，互联网产业在政策抑制和市场容量接近饱和的情况下，慢慢地由野蛮生长、争抢客户的增量市场发展模式，进入了一个需要精细化运营，通过优质服务来留住客户的存量市场发展模式。能够通过创新来开辟的业务新赛道的机会和案例已经越来越稀缺。各大厂商纷纷开始高举“降本增效”的大旗，以期能够度过寒冬。

在降本增效紧箍咒的高压下，不少企业纷纷祭出“自研”这一法宝，期望减少在软硬件基础设施上的支出，或者在支出不变的情况下，能够“优化”出更有效率的系统。

层出不穷的自研日志系统2.0

而在选择哪些系统可以自研的时候，日志系统以其影响范围广、资源投入多、使用时间少（主要集中在故障排查）等特点，成了各互联网大厂自研目标的集火对象。同时，集齐天时地利人和的是，在日志系统这个领域，有一个大家都公认的标准（ELK）可以作为比较对象，只要做得比开源自建的ELK好，就能证明基线之上创造的价值；同时，在采集端和数据规范上，有正在毕业的Opentelemetry, 在存储和分析；有众多高效的开源OLAP引擎能够提供核心组件的替换；在可视化和交互层面，可以用Grafana；而且这件事情已经被证明过可行性，有现成的案例。从构建思路到解决具体问题上，也能够找到参考和帮助。这些，似乎都使得这件事情的难度大大降低，可以放心大胆的撸起袖子快上大干。

自然，也就促成了层出不穷的基于OLAP引擎的自研日志系统的案例，甚至有不少人把这种变种称为日志系统2.0。

那我们如何理解在日志分析领域出现的这种变化呢？

互联网特有的日志OLAP分析场景

上面，我们提到了在线分析处理引擎（OLAP），这是一种用于组织大型商业数据库和支持商业智能的技术。其本身主要是面对结构化数据的在线分析场景。而现今，在日志系统中采用OLAP引擎的主要原因来自于结构化的，固定格式的日志分析需求。这类日志以API的调用日志，web服务器、负载均衡、网关的access日志为主，其特点是数据的格式、字段、值相对有限而固定，对数据的使用以有限值的字段过滤与数据聚合运算为主，通过聚合统计来了解服务的运行情况，错误率，延迟率；或者是在圈选客户后，在不同维度做分类统计等，属于较为典型的OLAP分析场景。在分析过程中，并不需要对日志数据的进行复杂的全文检索。同时，因为字段固定且有限，也不会需要对大量的动态字段的支持需求。

而在业务属性上，这类日志的分析，不仅能够用于检查服务运行状态，而且还能在一定程度上支持运营决策，比较适合用来做各种仪表板和大屏，相对于其他那些出错时才会去看的日志，其表现力更强，更容易被重视。因此，如果要自研，团队会更愿意选择适合这类场景的大数据引擎去作为日志系统的底座。而OLAP引擎因为其几乎是原生的支持各种SQL特性，使得其更适合这类日志数据的分析报表生成，并且对业务分析人员更为友好，学习成本更低。

并且，这类数据的数据量很大，且与平时的业务流量呈现非常一致的相关性，数据的时间属性具有明显的潮汐特点。当业务洪峰来临，日志量急剧上升。要支撑这种类型的日志数据，就需要系统有高吞吐的写入能力。相对于以搜索引擎为主的ELK，OLAP引擎因为不需要构建倒排索引，使用强类型表达等原因，其写入速度要更为出色。

因此，结合以上原因，不难理解为什么互联网企业会选择以自研的方式，开发一套基于OLAP的日志分析系统。