首先先给你吃个定心丸：针对你现在4万行的数据集，用row_number() OVER (ORDER BY 1)加行号过滤的分页方案完全是合理的。4万行哪怕全量shuffle到单个节点做排序，在Spark 1.6.3里也不会有明显的性能瓶颈——毕竟数据总量撑死也就4万*3KB=120MB左右，单节点处理这个量级的排序毫无压力。

不过你担心的「ORDER BY会把所有数据集中到单一节点」这个点确实是对的，这个方案的隐患在于数据量未来增长后的扩展性：如果后续数据集涨到几十万甚至几百万行，单节点排序就会成为性能瓶颈，甚至可能导致OOM。下面给你几个优化方向：

优化方案1：如果不需要严格全局顺序，改用LIMIT + OFFSET #

如果你的分页不需要保证全局固定的顺序（比如只是后台导出、浏览数据，不依赖稳定的排序逻辑），直接用Spark SQL的LIMIT和OFFSET会更简单：

SELECT * FROM (
  -- 你的3表关联查询逻辑
  SELECT t1.*, t2.col, t3.val FROM table1 t1 JOIN table2 t2 ON t1.id = t2.id JOIN table3 t3 ON t1.id = t3.id
) AS joined_data
LIMIT 100 OFFSET 0; -- 第一页，OFFSET随页码变化

Spark 1.6.3对LIMIT+OFFSET的处理是先扫描前OFFSET+LIMIT条数据，然后丢弃前面的OFFSET条。对于4万行的数据集，这个操作的性能和row_number方案差不多，但避免了显式的全局排序开销。

优化方案2：用分区排序替代全局排序（推荐） #

如果业务上可以接受按某个业务字段分区后分页（比如按用户所属区域、数据日期等），可以把row_number()的窗口改成带分区的：

SELECT * FROM (
  SELECT 
    *,
    row_number() OVER (PARTITION BY partition_col ORDER BY 1) AS row_num
  FROM (
    -- 你的3表关联查询逻辑
    SELECT t1.*, t2.col, t3.val FROM table1 t1 JOIN table2 t2 ON t1.id = t2.id JOIN table3 t3 ON t1.id = t3.id
  ) AS joined_data
) AS numbered_data
WHERE row_num BETWEEN 1 AND 100 AND partition_col = 'xxx'; -- 指定分区后取分页

这种方式下，Spark会先按partition_col把数据shuffle到多个节点，每个节点只处理自己分区内的数据排序和行号生成，完全避免了单节点集中数据的问题。如果需要跨分区分页，可以先统计每个分区的行数，再计算需要从哪些分区取数据。

优化方案3：预缓存/预存储关联结果 #

如果这个分页查询是高频执行的，建议把3表关联后的结果先缓存起来，或者写入Hive的中间表：

• 缓存方式：在Spark代码里对关联后的DataFrame调用cache()或persist(StorageLevel.MEMORY_AND_DISK)，后续分页查询直接基于缓存的DataFrame执行；
• 存储方式：把关联结果写入Hive表CREATE TABLE joined_result AS SELECT ...，分页时直接查这个表，避免每次重复执行关联逻辑。

优化方案4：针对全局排序的极端情况优化（数据量未来暴增时） #

如果必须保证全局严格顺序，且未来数据量会大幅增长，可以试试以下方式：

1. 先对关联后的结果按某个字段repartition成多个分区，比如repartition(10, sort_col)，这样每个分区内的数据是局部有序的；
2. 然后在每个分区内生成局部行号，再通过累加每个分区的行数，计算出目标分页对应的分区范围，最后从对应分区取数据并合并。
   不过这个方法实现起来比较复杂，适合数据量百万级以上的场景，你当前的数据集暂时不需要考虑。

总结一下：当前数据集用row_number方案完全没问题，若要提前布局扩展性，优先考虑分区排序或预存储结果。

内容的提问来源于stack exchange，提问作者andrew.butkus