Spark怎么快接Redis，踩过的坑和实操分享一点经验

直接上干货，我用 Spark 读写 Redis，主要是两个路子：一是用 Redis 官方自己出的那个 Spark-Redis 库，二是用第三方写的,或者自己手写一些连接代码。

先说官方库（Spark-Redis），这听起来最省事，像 spark.read.redis() 这种写法，看起来和读写 JDBC 数据库差不多，但坑马上就来了，第一，文档和社区支持比较弱，版本兼容性是个大问题，你 Spark 升个级，可能这库就不工作了，报的错能让你找半天，第二，它封装得太“好”了，很多底层参数调起来不顺手，连接池的大小、超时时间、重试策略，这些对性能至关重要的东西，它给的选项有限，有一次线上任务突然变慢，查到最后发现是连接池不够用，任务在等 Redis 连接,调它的配置参数费了老大劲。

所以更多时候，我们选择第二种：自己控制连接。 核心就是用 foreachPartition 或者 mapPartitions 这类操作，为什么？因为 Redis 连接是不能被序列化后在不同机器、不同线程之间传来传去的，你必须在每个计算节点内部，在每个分区里，自己去创建连接，在 foreachPartition 里面，先建立一个本地的 Redis 连接池（比如用 Jedis 或者 Lettuce），然后对这个分区里的一批数据，复用这个连接池去读写，这样做，一个分区用一个连接池，效率高,也避免了连接泄露。

踩过最疼的坑，就是序列化和数据结构。 Spark 默认的序列化方式，和 Redis 存数据的方式，是两码事，你不能直接把一个 Spark 的 DataFrame 对象往 Redis 里扔，你需要把数据转换成 Redis 支持的结构，String、Hash、Sorted Set，举个例子，如果你要把一个用户画像表存进去快速查询，很可能把用户ID作为 key，把画像的各个字段作为一个 Hash 来存，这里的关键是，设计好你的 Key，要避免单个 Key 对应的 Value 过大（比如一个巨大的 JSON 字符串），这会让 Redis 操作变慢，也容易阻塞，也要避免产生海量的小 Key（比如给每一行数据生成一个随机的 Key），这会撑爆内存，我们的经验是，能用 Hash 聚合一批数据，就用 Hash,并设置合理的过期时间。

另一个大坑是数据倾斜。 如果你根据某个字段做 Key，而这个字段分布极不均匀（比如80%的数据都集中在几个Key上），Spark 处理那几个分区时，会慢得要死，因为所有压力都打到 Redis 的同一个分片（如果集群化了）或同一个连接上，解决方案是在 Spark 端做一次重分区，或者在设计 Key 时加入一个随机前缀，把压力打散，读的时候再用范围查询聚合，但这招要慎用,会增加复杂度。

实操经验分享几点：

1. 连接管理是生命线：一定要用连接池，并且确保在任务结束或出错时正确关闭，我们见过因为代码异常导致连接没关，最后把 Redis 连接数打满,整个服务瘫痪的案例。
2. 批量操作是王道：坚决不要一条数据一条数据地读写，用 foreachPartition 拿到一批数据后，尽量使用 Redis 的 Pipeline 或者 MSET、HMSET 这样的批量命令，性能提升是几十倍上百倍的，我们有一次优化，把逐条插入改成 Pipeline 批量插入,运行时间从2小时缩短到5分钟。
3. 读写分离与集群：如果数据量大，Redis 肯定是集群模式，写代码时要能处理集群的拓扑，或者通过代理访问，读写压力大的话，考虑从从节点读,但要注意主从同步的延迟问题。
4. 监控和失败重试：必须监控 Spark 作业运行时的 Redis 连接指标、错误率，网络是不稳定的，重要的操作一定要有重试机制，但重试次数和间隔要合理,避免雪崩。
5. 测试！测试！测试！：一定要在和生产环境配置相似的测试环境，用全量数据跑一遍，很多问题（比如内存溢出、超时）只在大数据量下才会暴露。

Spark 接 Redis 想快，核心思想就两条：一是“分而治之”，在 Spark 端做好分区和批量；二是“客随主便”，老老实实按照 Redis 喜欢的方式（数据结构、批量命令）去组织数据。 官方库可以快速试水，但真要上生产，尤其是大规模、高性能的场景，自己精细控制连接和操作，虽然麻烦点,但更靠谱。