Spark从HBase取数并写入Elasticsearch的性能问题求助

我之前经手过类似的十亿级HBase到Elasticsearch的同步任务，踩过不少性能坑，给你分享几个经过生产环境验证的优化方案，分HBase读取和ES写入两个核心环节拆解：

• 精准扫描范围与过滤下推：既然是按日期范围拉取，一定要把日期过滤逻辑下推到HBase的Scan层面，通过setStartRow和setEndRow限定行键范围（如果你的行键包含日期前缀的话，这是最优解）；同时只读取需要的列，用addColumn指定列族和列，避免全列扫描；如果有其他过滤条件，优先用HBase原生Filter（比如SingleColumnValueFilter），减少从HBase拉到Spark的数据量。
• Scan参数调优：调整setCaching（比如设为2000-5000）和setBatch（根据单条数据的列数，比如列数多就设小一点，比如50-100），这两个参数能大幅减少Spark与HBase之间的RPC调用次数；另外一定要开启setCacheBlocks(false)，因为Spark是批量读取场景，不需要HBase的块缓存，反而会占用缓存资源影响其他业务。
• Spark并行度与资源匹配：Spark的分区数要和HBase的Region数量匹配，一般设为Region数的1.5-2倍，比如HBase有20个Region，Spark分区设30-40；同时调整spark.executor.cores（比如每个executor设3-5核）和spark.executor.instances，让每个executor处理的分区数合理，避免单个executor过载或资源闲置。
• HBase-Spark Connector选型与使用：尽量用官方维护的最新版connector（比如适配Spark 3.x的版本），避免用老旧版本的兼容性问题；如果用DataFrame，一定要定义精准的Schema，只映射需要的列，不要自动推断全表Schema；优先用JavaHBaseContext的hbaseRDDAPI直接读取，比通过Spark SQL间接读取的性能更高。

• 批量写入参数调优：Spark-ES connector的批量配置是核心，设置es.batch.size.entries为10000-50000（根据单条数据大小调整，比如单条1KB的话可以设5万），es.batch.size.bytes设为5-10MB；同时关闭自动刷新，设置es.batch.write.refresh: false，等所有批次写完后再手动调用ES的_refreshAPI，减少ES的磁盘IO开销。
• 并行度与ES集群能力匹配：Spark的写入分区数不要超过ES集群能承受的并发数，一般每个ES节点最多支持2-4个并发写入线程，比如ES有3个节点，Spark分区设6-12个；另外给Spark executor分配足够的内存（比如spark.executor.memory设为8-16G），避免批量缓存数据时OOM。
• ES集群临时优化（写入期间）：如果有权限调整ES集群，写入期间可以做这些临时优化：
  • 把索引的index.refresh_interval设为-1，关闭自动刷新
  • 暂时关闭副本写入（设置index.number_of_replicas: 0），写完后再恢复
  • 确保索引的主分片数等于ES节点数的整数倍（比如3个节点设3或6个主分片），让分片均匀分布在节点上
• Spark-ES Connector其他参数：设置es.http.timeout为30000-60000ms，es.http.retries为3-5次，避免网络波动导致批量写入失败；如果你的数据有唯一ID，用es.mapping.id指定文档ID，避免ES自动生成ID的额外开销；如果是增量同步，设置es.write.operation: upsert，只更新变化的数据。

• 序列化优化：Spark启用Kryo序列化，设置spark.serializer: org.apache.spark.serializer.KryoSerializer，并注册HBase和ES相关的类，减少数据在网络传输和内存中的占用。
• 监控与瓶颈定位：用Spark UI查看每个stage的耗时、数据量，定位是读取慢还是写入慢；用HBase的Master UI查看Region的请求负载，用ES的Kibana监控写入的吞吐量和延迟。
• 小批量验证：先拿100万条数据测试优化后的配置，验证性能提升后再放大到全量数据，避免直接跑全量出问题。

内容的提问来源于stack exchange，提问作者Alchemist