问题排查

不幸的是，有时事情并非如预期般顺利，您的 elasticsearch-hadoop 作业执行可能会出错：可能读取或写入了不正确的数据，作业可能花费的时间明显超出预期，或者您可能会遇到一些异常。本节试图提供帮助和提示，以进行您自己的诊断，识别问题并有望修复它。

测试 Elasticsearch 是否可以从运行作业的 Spark/Hadoop 集群访问。您的机器可能可以访问它，但实际代码不会在那里运行。如果 ES 可访问，请最小化任务数量及其批量大小；如果 Elasticsearch 负载过重，它将持续落后，GC 将启动，并最终导致其节点无响应，从而使客户端认为计算机已死机。有关更多详细信息，请参阅性能考虑部分。

很多时候，人们会在生产环境中使用其本地开发设置。仔细检查 Elasticsearch 是否可以从您的生产环境访问，检查主机地址和端口，以及运行 Hadoop/Spark 作业的机器是否可以访问 Elasticsearch (使用 curl、telnet 或您可用的任何工具)。

在生产环境中使用 localhost (即默认值) 是一种简单的配置错误。

确保在您的类路径中仅使用一个版本的 elasticsearch-hadoop。虽然这可能不明显，但 Hadoop/Spark 中的类路径是从多个文件夹组装的；此外，无法保证 JVM 首先会选择哪个版本。为了避免模糊的问题，请仔细检查您的类路径，并确保其中只有一个版本的库，即您感兴趣的版本。

遇到问题时，请尽力隔离它。这可能非常棘手，而且很多时候，这是最难的部分，因此请花时间处理它。采取小步骤，尝试以小块形式删除不必要的代码或设置，直到您最终得到一个小的示例，该示例可以暴露您的问题。

许多 Hadoop 作业本质上是批处理的，这意味着它们需要很长时间才能执行。为了更快地追踪问题，请使用一切可能的手段来加速反馈循环：使用小型/微型数据集（无需加载数百万条记录，几十条就足够了），并在开发机器上运行的 Elasticsearch 节点旁边使用本地/伪分布式 Hadoop 集群。

仔细检查您的设置，并在可能的情况下使用常量或复制配置。很容易出现拼写错误，因此请尝试通过使用属性文件或常量接口/类来减少手动配置。如果您不确定某个设置在做什么，请删除它或更改其值，并查看它是否会影响您的作业输出。

密切关注您的输入和输出；这通常更容易使用 Elasticsearch 完成（服务比作业/脚本的生命周期长，是实时的，并且可以以灵活的方式立即访问，包括命令行）。如果您的数据未持久化（在 Hadoop 或 Elasticsearch 中），请考虑临时这样做以验证您的工作流程的每个步骤。

虽然日志记录有助于发现错误和异常，但对于运行时行为，我们强烈建议对您的 Hadoop 和 Elasticsearch 集群进行适当的监控。两者都不在本章的讨论范围之内，但是有几种流行的免费解决方案值得研究。对于 Elasticsearch，我们建议使用 Marvel，这是一个由 Elasticsearch 团队创建的免费监控工具（用于开发）。监控可以深入了解集群的实际行为，并帮助您关联行为。如果无法使用监控解决方案，请使用 Hadoop、Elasticsearch 和 elasticsearch-hadoop 提供的指标来评估运行时行为。

日志记录可以使您深入了解正在发生的事情。Hadoop、Spark 和 Elasticsearch 具有广泛的日志记录机制，elasticsearch-hadoop 也是如此，但请谨慎使用：过多的日志记录可能会隐藏实际问题，因此请再次少量增加日志记录。

遇到性能问题时，请先进行一些基准测试，尽可能地隔离。不要简单地假设某个组件很慢；确保/证明它确实很慢。否则，通常情况下，人们可能会发现自己正在“修复”错误的问题（并且通常会创建一个新问题）。

索引性能在很大程度上取决于目标数据的类型及其映射。搜索也是如此，但请将查询定义添加到组合中。如前所述，请在导入/搜索大量数据之前，试验并测量数据集的各个部分，以找到您环境的最佳点。