作为公司数据资产的重要组成部分，日志在系统的可观察性、网络安全和数据分析方面扮演着关键角色。日志记录是故障排除的首选工具，也是提升系统安全性的重要参考。日志还是一个宝贵的数据源，通过对其进行分析，可以获取指导业务增长的有价值信息。
日志是计算机系统中事件的顺序记录。一个理想的日志分析系统应该是：
- 具备无模式支持。 原始日志是非结构化的自由文本，基本无法直接进行聚合和计算，因此，在将日志用于数据库或数据仓库进行分析之前，需要将其转化为结构化的表格形式（这个过程称为“ETL”）。如果发生日志模式更改，需要在ETL流程和结构化表中进行一系列复杂的调整。为了应对此情况，可以使用半结构化日志，主要采用JSON格式进行记录。在这种格式的日志中，可以相对容易地添加或删除字段，而日志存储系统会相应地调整其模式。
- 低成本。 日志数据庞大且持续不断生成。一个相当大的公司每年会产生10~100 TB的日志数据。基于业务或合规要求，应该保留半年或更长时间的日志。这意味着需要存储以PB为单位的日志大小，成本相当可观。
- 具备实时处理能力。 日志应该实时写入，否则工程师将无法及时捕捉故障排查和安全追踪中的最新事件。此外，良好的日志系统应该提供全文搜索功能，并能快速响应交互式查询。
1 基于Elasticsearch的日志分析解决方案
数据行业内常用的日志处理解决方案是ELK技术栈：Elasticsearch、Logstash和Kibana。该流程可分为五个模块：
- 日志收集：Filebeat收集本地日志文件并将其写入Kafka消息队列。
- 日志传输：Kafka消息队列收集和缓存日志。
- 日志转换：Logstash过滤和转换Kafka中的日志数据。
- 日志存储：Logstash以JSON格式将日志写入Elasticsearch进行存储。
- 日志查询：用户通过Kibana可视化搜索日志或通过Elasticsearch DSL API发送查询请求。
图片
ELK堆栈具有优秀的实时处理能力，但也存在一些问题。
1.1 缺乏无模式支持
Elasticsearch中的索引映射定义了表的结构，包括字段名称、数据类型以及是否启用索引创建。
图片
Elasticsearch还拥有自动根据输入的JSON数据添加字段到映射的动态映射机制。这提供了某种程度的无模式支持，但这还不够，因为：
- 动态映射在处理脏数据时经常会创建过多的字段，从而中断整个系统的运行。
- 字段的数据类型是不可变的。为了确保兼容性，用户通常将数据类型配置为"文本"，但这会导致比二进制数据类型（如整数）慢得多的查询性能。
- 字段的索引也是不可变的。用户无法为特定字段添加或删除索引，因此经常为所有字段创建索引，以便在查询中方便地进行数据过滤。但是太多的索引需要额外的存储空间，并减慢数据摄入速度。
1.2 分析能力不足
Elasticsearch拥有独特的领域特定语言（DSL），与大多数数据工程师和分析师熟悉的技术栈非常不同，所以存在陡峭的学习曲线。此外，Elasticsearch相对封闭的生态系统，在与BI工具集成方面会遇到一些阻力。最重要的是，Elasticsearch仅支持单表分析，滞后于现代OLAP对多表连接、子查询和视图的需求。
图片
1.3 高成本和低稳定性
Elasticsearch用户一直在抱怨计算和存储成本。根本原因在于Elasticsearch的工作方式。
- 计算成本：在数据写入过程中，Elasticsearch还执行计算密集型操作，包括倒排索引的创建、分词和倒排索引的排序。在这些情况下，数据以每个核心约2MB/s的速度写入Elasticsearch。当CPU资源紧张时，数据写入需求往往会在高峰时段被拒绝，进一步导致更高的延迟。
- 存储成本：为了加快检索速度，Elasticsearch存储原始数据的正排索引、倒排索引和文档值，消耗了更多的存储空间。单个数据副本的压缩比仅为1.5:1，而大多数日志解决方案的压缩比为5:1。
随着数据量和集群规模的增长，保持稳定性会成为另一个问题：
- 在数据写入高峰期：集群在数据写入高峰期容易超载。
- 在查询期间：由于所有查询都在内存中处理，大型查询很容易导致JVM OOM（内存溢出）。
- 恢复缓慢：对于集群故障，Elasticsearch需要重新加载索引，这对资源消耗很大，因此恢复过程可能需要几分钟。这对于服务可用性的保证是一个挑战。
2 更具成本效益的方案
在反思基于Elasticsearch的解决方案的优点和局限性后，Apache Doris开发人员对Apache Doris进行了日志处理的优化。
- 增加写入吞吐量： Elasticsearch的性能受到数据解析和倒排索引创建的限制，因此改进了Apache Doris在这些方面的性能：通过SIMD指令和CPU向量指令加快了数据解析和索引创建的速度；然后移除了在日志分析场景中不必要的数据结构，例如正排索引，以简化索引创建过程。
- 减少存储成本： 移除了正排索引，这部分数据占据了索引数据的30%。采用了列式存储和ZSTD压缩算法，从而实现了5:1到10:1的压缩比。考虑到大部分历史日志很少被访问，引入了分层存储来分离热数据和冷数据。超过指定时间段的日志将被移动到存储成本更低的对象存储中。这可以将存储成本降低约70%。
Elasticsearch的官方测试工具ES Rally进行的基准测试显示，Apache Doris在数据写入方面比Elasticsearch快约5倍，在查询方面快约2.3倍，并且仅消耗Elasticsearch使用存储空间的1/5。在HTTP日志的测试数据集上，它实现了550 MB/s的写入速度和10:1的压缩比。
图片
下图显示了一个典型的基于Doris的日志处理系统的样貌。它更加全面，从数据摄取、分析到应用，都可以更灵活地使用：
- 数据导入：Apache Doris支持多种日志数据的摄入方式。可以通过使用Logstash的HTTP输出将日志推送到Doris，可以在将日志写入Doris之前使用Flink预处理日志，或者可以通过常规加载和S3加载从Flink或对象存储中加载日志到Doris中。
- 数据分析：可以把日志数据放入Doris，并在数据仓库中进行跨日志和其他数据的联接查询。
- 应用：Apache Doris兼容MySQL协议，因此可以把各种数据分析工具和客户端集成到Doris中，例如Grafana和Tableau。还可以通过JDBC和ODBC API将应用程序连接到Doris。这里计划构建一个类似于Kibana的系统来可视化日志。
图片
此外，Apache Doris具有更好的无模式支持和更用户友好的分析引擎。
2.1 原生支持半结构化数据
首先，在数据类型上进行优化。通过矢量化优化了字符串搜索和正则表达式匹配的文本性能，性能提升了2~10倍。对于JSON字符串，Apache Doris将其解析并存储为更紧凑和高效的二进制格式，可以加快查询速度4倍。还为复杂数据添加了一种新的数据类型：Array Map。它可以将连接的字符串进行结构化，以实现更高的压缩率和更快的查询速度。
其次，Apache Doris支持模式演化。这意味着可以根据业务变化调整模式。可以添加或删除字段和索引，并更改字段的数据类型。
Apache Doris提供了轻量级的模式更改功能，因此开发人员可以在几毫秒内添加或删除字段：
-- 添加列。结果会在毫秒级返回。
ALTER TABLE lineitem ADD COLUMN l_new_column INT;还可以仅为目标字段添加索引，以避免不必要的索引创建带来的开销。在添加索引后，默认情况下，系统将为所有增量数据生成索引，并且可以指定需要索引的历史数据分区。
-- 添加倒排索引。Doris会为以后的所有新数据生成倒排索引。
ALTER TABLE table_name ADD INDEX index_name(column_name) USING INVERTED;
-- 为指定的历史数据分区构建索引。
BUILD INDEX index_name ON table_name PARTITIONS(partition_name1, partition_name2);2.2 基于SQL的分析引擎
基于SQL的分析引擎确保数据工程师和分析师能够在短时间内轻松掌握Apache Doris，并将其在SQL方面的经验应用到这个OLAP引擎中。借助SQL的丰富功能，用户可以执行数据检索、聚合、多表连接、子查询、UDF、逻辑视图和物化视图，以满足自身需求。
Apache Doris具备MySQL兼容性，可以与大数据生态系统中的大多数GUI和BI工具集成，使用户能够实现更复杂和多样化的数据分析。
