SparkSQL关联Rest接口数据的方案选择及UDF限流方法咨询

临时表数据源方案 #

• 适用场景：Rest接口支持全量/批量拉取、返回的全量数据量不大的场景
• 优势：
  • 拉取数据的过程可以单独做流量控制，不会对Rest服务造成突发高压力
  • Hive侧关联是纯离线计算，不需要在SQL执行阶段发起外部调用，性能稳定，不会出现接口超时导致的作业失败问题
  • JSON数据可以提前做清洗、格式校验后再入库，关联逻辑简单，出错概率低
  • 实现成本低，只需要单独写个拉取脚本，将接口返回的JSON清洗后写入临时Hive表，再和目标表做普通Join即可
• 劣势：如果Rest接口只支持按主键查询、不支持全量拉取，或者全量数据量极大拉取成本很高，该方案无法落地

UDF方案 #

• 适用场景：需要按Hive表每行的主键/参数动态调用Rest接口查询返回结果的场景
• 优势：不需要提前拉取全量数据，只查询需要用到的字段对应的接口数据，适合接口不支持全量拉取的场景
• 劣势：SQL执行时会发起大量并发接口调用，容易打挂下游Rest服务，也容易因为接口波动导致作业失败

选型结论：优先选临时表数据源方案，只要接口支持全量/批量拉取，这个方案的稳定性、运维成本都远低于UDF方案。只有当接口只能按行参数查询、没法批量拉取全量数据的时候，再考虑用UDF方案。

• 方案1：UDF内置单机限流
  用Guava的RateLimiter做单机限流，提前根据作业的并发度计算好单进程的限流阈值：比如你要控制总RPS不超过100，作业并发度是20，那每个UDF实例的RateLimiter就设为5QPS。注意该方案要配合Hive作业的并发参数（比如mapreduce.job.maps、tez.am.container.reuse.enabled等）一起调整，避免容器动态扩缩容导致总RPS超过阈值。
• 方案2：批量调用+间隔控制
  不要每行数据都调用一次接口，在UDF中做本地缓存攒批，攒够N条（比如100条）后批量调用支持批量参数的Rest接口，调用完成后sleep固定间隔再处理下一批。该方案不仅能降低RPS，还能减少连接建立的开销，接口调用性能会高很多。
• 方案3：并发度限制
  直接调整Hive作业的执行并发度，比如把Map任务数或者Reduce任务数降到你能接受的范围：比如接口最大支持20QPS，你把Map任务数设为20，每个Map task每秒只发1次请求，总RPS就能控制在20以内。这是最简单的限流方法，不需要改UDF代码。
• 额外注意点：
  • UDF里一定要加重试、降级逻辑，接口超时或者返回错误的时候不要直接抛异常导致作业失败，可以返回空值或者默认值，避免因为接口波动影响作业稳定性
  • 尽量开启任务容器复用，避免频繁创建新的UDF实例导致限流策略失效

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