性能注意事项
编辑性能注意事项编辑
由于连接器本身不会抽象 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 秒，则无需减少它。如果小于该值，您可以尝试*少量*增加它。
使用写入 Elasticsearch 的最大任务数限制编辑
对于 elasticsearch-hadoop，运行时（Hadoop 或 Spark）可以并且将会创建多个任务，这些任务将同时写入 Elasticsearch。在某些情况下，这会导致任务数量与用户计划用于 Elasticsearch 的实际数量之间不成比例（有时会高出一个或甚至两个数量级）。当处理高度可拆分的输入时，就会出现这种情况，因为这些输入很容易生成数十个或数百个任务。如果目标 Elasticsearch 集群只有几个节点，那么同时处理这么多数据可能会出现问题。
了解拒绝发生的原因编辑
在负载过高的情况下，Elasticsearch 会开始拒绝文档 - 在这种情况下，elasticsearch-hadoop 会等待一段时间（默认值为 10 秒），然后重试（默认情况下最多重试 3 次）。如果 Elasticsearch 继续拒绝文档，作业最终将失败。在这种情况下，请监控 Elasticsearch（通过 Marvel 或其他插件），并密切关注批量处理。查看被拒绝文档的百分比；拒绝一些文档是完全正常的，但如果定期出现超过 10-15% 的拒绝率，则表明集群过载。
控制重试次数和等待时间编辑
如上所述，当文档被拒绝时会发生重试。这可能是由多种原因造成的 - 索引突然激增、节点迁移等。如果您的作业由于重试失败而不断中止，则表明您的集群过载。增加重试次数*不会*解决问题，而只会掩盖问题；作业会变得非常慢（因为每次写入可能会重试多次，直到所有文档都被确认）。