1.2 Elasticsearch的典型接入方式

基本了解了Elasticsearch后，本节将探讨适合接入Elasticsearch的几种典型方式，帮助大家明确Elasticsearch的正确接入方法。

1.2.1 将Elasticsearch作为数据源

Elasticsearch很适合读多写少的数据分析型应用程序，如果你参与过OLAP数据分析相关的项目，由于数据仓库本身就具有读多写少的特性，对事务管理的要求也不高，在这种情况下，考虑到Elasticsearch本身具备数据存储的能力，可以作为数据源，使应用程序的绝大多数读写操作都在Elasticsearch中进行，如图1.1所示。

图1.1 直接用Elasticsearch作为数据源

1.2.2 给已有系统添加Elasticsearch

如果你已经有一个软件系统，它使用了MySQL或者HBase数据库，但是随着数据量的不断加大，你可能会感觉MySQL的查询速度越来越难以接受，也可能由于业务逻辑越来越复杂，而感觉HBase的检索方式不够丰富。这时候你可以考虑把那些查询速度慢或者业务逻辑复杂的数据接入Elasticsearch，使用时你需要把相关表的历史存量数据一次性导入Elasticsearch，当增量数据写入数据库时，也往Elasticsearch中写一份，这样就能够保证两边的数据是同步的，如图1.2所示。

图1.2 给已有系统添加Elasticsearch

注意：当关系数据库或NoSQL数据库能够满足实际需要的查询请求时，则没有必要接入Elasticsearch。实际上，关系数据库和NoSQL数据库的主键查询速度本身就很快，能够满足部分场景的需要，可以用它们分担一些查询请求，减小Elasticsearch的压力。另外，写入Elasticsearch的字段数目并不强制要求与数据库的一致。只有实际需要检索、分析和前端展示的字段才必须写入Elasticsearch。在Elasticsearch中写入字段数目过多的文档对性能而言是一种拖累，并且会浪费资源。

1.2.3 使用Elastic Stack

提到Elasticsearch的接入方式，怎么能不讲官方的Elastic Stack呢？除了使用应用程序写入Elasticsearch，你还可以使用官方提供的数据采集工具Logstash或者第三方的ETL工具把数据写入Elasticsearch。这些工具除了能用来采集数据库的数据，还可以用来采集线上的日志数据、系统的运维监控指标数据，功能十分丰富。Elastic Stack的组件Kibana提供了一个友好的图形界面，可以用来管理和可视化分析Elasticsearch的数据，整个技术栈的数据流如图1.3所示。

图1.3 Elastic Stack 的数据流

Logstash是早期的数据采集、转换工具，你只需要编写配置文件就可以很方便地把各种数据写入Elasticsearch。但是由于Logstash运行时比较耗资源，于是官方又推出了一系列命名包含beat的轻量级数据采集器，统称为Beats，相当于把Logstash的数据采集功能分包给Beats工具完成。既可以把Beats采集的数据汇聚到Logstash后再写入Elasticsearch，也可以直接采集数据然后写入Elasticsearch。

目前为止，Beats家族的成员主要有以下几种，种类还在不断增多。

（1）Filebeat：用于采集各类日志文件，可以读取并传送日志的行，支持断点续传。

（2）Metricbeat：用于采集各种软硬件的运维监控数据，例如CPU、内存、MySQL等运行时的指标数据。

（3）Packetbeat：用于采集各种网络协议产生的流量数据，通过分析这些数据你可以及时发现网络存在的问题和其运行状态。

（4）Winlogbeat：用于采集Windows系统的事件日志，可以用来实时分析Windows系统中产生的各种事件。

（5）Heartbeat：能够监测指定的服务是否可用并能将监测结果采集到Elasticsearch中进行分析。

（6）Auditbeat：用于采集Linux审计框架的事件数据，通过采集并监控用户的行为数据和关于系统进程的数据，能够识别出系统潜在的风险和安全问题。