Elasticsearch 本身的定位并不是一个日志分析系统。如何应用 Elasticsearch 做日志分析呢？
2018 年 10 月 6 日，Elastic 公司上市，这也是开源软件领域为数不多成功上市的公司。Elastic 公司以开源搜索产品 Elasticsearch 而闻名。
Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎，被全球众多知名公司使用，有各种各样的场景用例。当应用在 Uber、Instacart 和 Tinder 时，它使骑手与附近的司机配对，为在线购物者提供相关的结果和建议，或者匹配他们可能喜欢的人；当应用在传统 IT、运营和安全部门时，它被用于聚合定价、报价和商业数据，每天处理十亿日志事件，为数千个设备和关键数据提供网络安全操作。
那么，Elasticsearch 和日志分析技术又能擦出怎样的火花呢？它本身的定位并不是一个日志分析系统，用于日志分析中，它能发挥什么作用？要做何优化和改进？市场上还有哪些开源搜索引擎？与它们相比，Elasticsearch 有哪些优缺点？InfoQ 采访到了日志易技术副总裁黎吾平，请他聊聊 Elasticsearch 与日志分析的二三事。
黎吾平： 日志在计算机系统中是一个非常广泛的概念，任何程序都有可能输出日志：操作系统内核、各种应用服务器等。日志的内容、规模和用途也各不相同。这里仅列举几个场景。
在 Web 或者 App 中，很多时候采用日志来记录用户的访问行为。通过日志可对服务的访问量进行分析，对系统进行改进，对用户进行画像分析，后续可用于广告、推荐等业务等。
很多企业内部软件中，会记录用户的所有操作行为，这部分日志可用于用户审计或企业安全的目的。
此外，对于开发或者运维人员，查日志可以算得上是故障分析、监控告警等等场景的第一选择。
黎吾平： 在数据规模比较小的情况下，可以使用单机的脚本进行处理，这种方法简单快速，但当对日志进行多种不同的分析的时候，可能会导致大量重复的代码，用于进行数据解析和清洗，这个时候可能使用更合适的方法——比如采用数据库。
使用数据库来进行日志分析，一个很重要的点就是如何将各种异构的日志文件导入到的数据库中，因为数据库首先需要按照固定格式创建表结构——这个过程通常称为 ETL。当数据导入后，可以采用大家熟悉的 SQL 进行日志的各种分析。
对于数据规模比较大的情况，一般会使用分布式技术。分布式的方式之一是采用 hadoop 存储日志数据，后续采用 MapReduce 的 job 或者 spark 等进行分析。如果希望采用 SQL 的方案来分析，可以采用 Hive 这些类似数据库的系统。这类系统适合于批量的进行分析。如果需要实时分析则需要引入一些实时的处理系统。
还有一种基于搜索引擎的方案日志的分析，目前国内就出现了很多基于 Elasticsearch 进行日志分析的用法，行业内也有一些商用的产品。如国外 Splunk、Sumo Logic，国内的日志易。
InfoQ：日志分析中，大家最常遇到的问题有哪些？有什么解决方法？
黎吾平：日志分析最大的问题是字段抽取复杂。首先对所有日志进行字段抽取的工作量很大，其次日志会随着产品版本更新发生变化，而且日志入库时很难预知后续的分析对字段的需求。因此需要一个功能强大且易用的日志抽取功能，以及搜索时按需临时抽取字段的能力。
其次是需要灵活可配置的分析能力。 如果每次分析都需要写代码进行，工作量大而且使用的门槛比较高。对于数据库的方案可以采用 SQL，一些商用的产品都推出了自己的语言，比如 SPL（Search Processing Language）。
另外几个常见的问题就是实时性和性能问题。随着日志数据量的增长，想要实时监控分析数据，就必然会影响系统性能。这二者的平衡与优化，主要受运维工作经验的影响。
黎吾平： 日志分析中的搜索引擎主要用于数据的读写：即实时的接收最新产生的日志数据，并进行索引，以实时或者准实时的方式提供给用户进行搜索和统计分析。
搜索引擎相比较一些类似数据库的系统，主要特点是：支持全文检索，搜索更快，处理数据的性能更强，实时性也非常好。
InfoQ：日志分析中，常用的搜索引擎有哪些，Elasticsearch 有什么优点？
黎吾平： 开源搜索引擎项目主要有 Apache 社区的 Solr、雅虎开源的 Vespa、LinkedIn 开源的 Sensei 和 Elasticsearch 等。Elasticsearch 目前应该可以说是广泛应用于日志的分析，目前不少国内的公司，包括互联网的公司都在使用。
在日志分析领域，Elasticsearch 的优点主要表现为灵活易用、插件扩展、准实时搜索、具有一定的统计分析功能上。比如说，Elasticsearch 支持大量的 Aggregation、丰富的 Restful 接口。还有就是，Elasticsearch 社区活跃，很多问题能够在社区里快速解决。
InfoQ：匹配日志分析场景，为什么需要对 Elasticsearch 进行改进？做了哪些方向的改进？
黎吾平： 首先，日志易一直以来是 ES 的深度用户。不少客户的数据量非常大，所部署的产品集群规模达到上百台机器，每天新产生的数据数十 TB，我们的产品大都是部署在用户的生产环境，相比较自己公司内部使用 ES，故障处理、功能调试要困难的多，所以我们对功能、性能、稳定性的要求是非常高的。
日志易对 Elasticsearch 进行主要自以下方面入手：
一是针对 Elasticsearch 功能、性能、稳定性的优化。Elasticsearch 实际使用过程中，出现的问题较多。比如 Elasticsearch 中不允许出现字段类型冲突。在索引时，Elasticsearch 要检查新的字段在整个集群内是否存在类型冲突，这会导致入库时数据堆积、集群卡死。这要求根据具体的使用场景，针对 ES 进行优化：有 Mapping 更新逻辑、增加长期索引存储、优化多存储路径时 Shard 分配逻辑等。此外，还改进优化了 Elasticsearch
调用的 Lucene 搜索库，涉及数百个源代码文件，过万行源代码。
二是日志搜索引擎的专业化。Elasticsearch 本身的定位是一个通用的搜索引擎，而不一个专用的日志分析系统，因此也有很多的功能并不是日志分析需要的。比如说，日志是不可变的，日志基本不需要相关性。事实上，因为 Elasticsearch 要面对更广泛的使用场景，之前提到的一些优点，背后是隐含着限制条件的。
日志易的日志搜索引擎，大幅提升了日志搜索的性能。这里列举一下搜索引擎主要的改进：
字段冲突的优化。Elasticsearch 是 schemaless，less 不是 no，实际上依然会有字段冲突的问题。这点在格式经常变动的日志数据上，问题非常显著。日志易在这块做了自己的处理。
统计分析和 RESTful 接口的改进。 可谓”成也萧何败也萧何”，Elasticsearch 所提供的统计分析和 RESTful 接口，一旦面临复杂的需求分析，用户可能就要陷入 JSON 地狱。当然，在这点上，日志易也做出了相应的处理。
实时性和性能也是大规模集群的改进优化重点。 我们重新开发的引擎在 Replica 策略、Segment 合并策略、消重策略、DocValues 统计上，都做了不同程度的改造优化。
想要共同探讨 Elasticsearch 优化经验的朋友，欢迎在 11 月份的上海，于 InfoQ 主办的 CNUTCon 全球运维技术大会日志处理专题论坛与我交流。
InfoQ：近期，Elasticsearch 上市了，你怎么看待它的前景？
黎吾平：Elasticsearch 近期在纽交所上市，可以说是开源软件领域为数不多成功上市的公司，上市以后，Elasticsearch 在品牌影响力、资金实力、人才吸引上都会更进一步提升。随之而来是更大的投入，这肯定会提高搜索引擎在技术社区的影响力，也提高 IT 技术人员对基于搜索引擎的日志分析技术的认可。这个领域的未来应该会持续繁荣，我也期待有更多的新场景涌现出来。
