性能考量

由于连接器本身不会抽象化 Elasticsearch，也不是有状态的（不会在作业之间保持任何状态，只进行批量写入 - 见下文），因此在考虑性能时，应该关注 Elasticsearch 本身及其行为。

请注意，一般来说，我们建议不要更改太多设置，尤其是在 Elasticsearch 端，因为默认设置在大多数情况下都足够好。随着每次发布，Elasticsearch 在其环境方面变得更加“智能”，并自动调整自身（例如 HDD 与 SDD）。

除非您真的知道自己在做什么，并且有实际结果显示了改进（即真实基准测试），否则不要盲目调整，仅仅因为某处的博客或帖子告诉您这样做。我们遇到过太多次系统由于一些本应起到相反作用的错误配置而性能不佳的情况。

请注意，系统（甚至在分布式系统中）的第一要务是尽可能拥有一个稳定、可预测的环境。虽然失败是必然的（这不是“是否”的问题，而是“何时”的问题），但也应牢记系统在压力下的稳定性。对硬件慷慨一些，从小步开始 - 如果一个系统在小负载下都无法充分运行，那么它在压力下肯定会落后。始终应将稳定性放在第一位，性能放在第二位。没有稳定性，就不可能有高性能的系统。

请记住这一点，不要调整设置，希望它会自动提高性能。这就是为什么为了获得可靠的结果，始终要进行测量，以查看您所做的更改是否产生了预期的影响。

elasticsearch-hadoop 执行跨所有目标资源分片的并行读取。它依赖于 滚动，这在返回查询结果方面是尽可能高效的。如果读取性能不是最优的，首先尝试直接查询 Elasticsearch，看看查询有多耗时。《Elasticsearch 文档》是一个很好的起点，例如提高性能页面；类似的查询可能会返回相同的结果，但成本可能不同。

如果查询效率低下，请尝试以更优化的方式重写它。有时更改数据结构（例如添加新字段或将其非规范化）可以显著提高查询性能，因为需要进行的计算更少。

请注意，通常，结果的数量不会影响连接器或 Elasticsearch 本身的性能。连接器不会一次读取所有结果，而是分块读取并将它们传递给消费者。因此，通常大小会成为消费者方面的问题，具体取决于它是否尝试缓冲来自连接器的结果，或者是否可以简单地迭代或流式传输它们。

一个常见的问题是增加分片的数量是否会提高读取性能。如果这意味着横向扩展，即更好地将数据分布到多个节点（理想情况下位于多台机器上），那么它确实会提高性能。如果不是这种情况，分片最终会位于同一节点，从而位于同一台机器上；硬件仍然相同，只是对数据进行了虚拟分区。

这可以提高客户端的消费并行性（更多分片意味着更多任务可以同时从 Elasticsearch 读取数据），但是从 Elasticsearch 的角度来看，没有实际的收益，因此查询性能很可能保持不变。

提高写入性能的一个关键方面是确定 Elasticsearch 可以舒适地摄取的最大数据速率。这取决于许多变量（数据大小、硬件、当前负载等），但一个好的经验法则是批量请求的处理时间不要超过 1-2 秒。

由于 elasticsearch-hadoop 执行并行写入，因此务必牢记这一点，这一点适用于 Hadoop/Spark 在运行时创建的所有任务。

请记住，elasticsearch-hadoop 允许用户配置每个任务批量写入 Elasticsearch 的条目数量和大小。也就是说，假设有 T 个任务，配置为 B 字节和 N 个文档（其中 d 是平均文档大小），则给定时间点批量写入请求的最大数量可以是 T*B 字节或 T*N 个文档（以字节为单位为 T*N*d）- 以先到者为准。

因此，对于具有 5 个任务的作业，使用默认值（1mb 或 1000 个文档）意味着批量大小最大为 5mb/5000 个文档（分布在各个分片上）。如果处理时间超过 1-2 秒，则无需减小它。如果处理时间少于 1-2 秒，则可以尝试以小步幅增加它。

在 elasticsearch-hadoop 的情况下，运行时（Hadoop 或 Spark）可以并且将会创建多个任务，这些任务将同时写入 Elasticsearch。在某些情况下，这会导致任务数量在用户计划用于 Elasticsearch 的数量与实际数量之间不成比例（有时甚至高出一个或两个数量级）。当处理高度可拆分的输入时，尤其会出现这种情况，这些输入很容易生成数十或数百个任务。如果目标 Elasticsearch 集群只有几个节点，那么一次处理这么多数据很可能会出现问题。

在负载过大的情况下，Elasticsearch 开始拒绝文档 - 在这种情况下，elasticsearch-hadoop 会等待一段时间（默认为 10 秒），然后重试（默认最多 3 次）。如果 Elasticsearch 继续拒绝文档，则作业最终将失败。在这种情况下，请监控 Elasticsearch（通过 Marvel 或其他插件）并关注批量处理。查看被拒绝的文档的百分比；有一些文档被拒绝是完全可以的，但是如果定期出现高于 10-15% 的情况，则很好地表明集群已过载。

如上所述，当文档被拒绝时会发生重试。这可能是由于多种原因造成的 - 索引突然激增、节点重新定位等。如果您的作业因重试失败而不断中止，则很好地表明您的集群已过载。增加重试次数不会使问题消失，而只会将其隐藏起来；作业将非常缓慢（因为很可能每次写入都会重试多次，直到所有文档都被确认）。