故障排除

不幸的是，有时事情不会按预期进行，并且您的 elasticsearch-hadoop 作业执行可能会出错：可能会读取或写入不正确的数据，作业可能花费的时间比预期的长得多，或者您可能会遇到一些异常。本节尝试提供帮助和技巧，以进行自己的诊断、识别问题并希望解决问题。

测试从运行作业的 Spark/Hadoop 集群是否可以访问 Elasticsearch。您的机器可能可以访问它，但这并不是实际代码运行的位置。如果可以访问 ES，请最大程度减少任务数量及其批量大小；如果 Elasticsearch 过载，它将继续落后，GC 将启动，最终其节点将变得无响应，导致客户端认为机器已死机。有关更多详细信息，请参阅性能注意事项部分。

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

在生产环境中使用localhost（即默认值）仅仅是一种错误配置。

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

遇到问题时，请尽最大努力将其隔离。这可能非常棘手，而且很多时候，这是最难的部分，因此请花点时间。循序渐进，尝试逐步消除不必要的代码或设置，直到最终得到一个小型示例来暴露您的问题。

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

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

仔细查看您的输入和输出；这通常使用 Elasticsearch 更容易做到（服务比作业/脚本存活时间长，是实时的，并且可以通过灵活的方式立即访问，包括命令行）。如果您的数据未持久化（在 Hadoop 或 Elasticsearch 中），请考虑暂时执行此操作以验证工作流程的每个步骤。

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

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

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

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