预处理脚本卡在map阶段主因是输入未真正并行：单大文件或不可切分压缩格式导致串行；UDF性能差因序列化开销，应优先用内置函数；校验宜采样或元数据驱动；YARN被Kill需调memoryOverhead而非仅增内存。
预处理脚本卡在 map 阶段不动？先确认数据分片是否真正并行
大数据同步前跑预处理，常见假象是“脚本在跑”，实际只有单线程在啃一个超大文件。spark 或 flink 里 map 看似并行，但若输入路径没被正确切分（比如只给了单个 /data/raw/log.json 而非 /data/raw/*.json），整个 stage 就会退化成串行。
- 检查输入源：用
hadoop fs -ls /path确认文件数量和大小，单文件 >2GB 基本别指望自动分片 - 强制分片：Spark 中改用
spark.read.textFile(...).repartition(200)，别依赖默认分区数 - Flink 用户注意：
FileInputFormat默认按块切分，但若文件压缩格式是.gz（不可切分），整个文件只能由一个 task 处理——换.snappy或.zstd
UDF 在预处理中越写越慢？替换成向量化操作
用 Python 写 pandas_udf 或 SQL 里嵌套 udf() 处理字段清洗，数据量一过千万就明显拖慢。本质是 JVM/Python 进程间序列化开销 + 解释执行瓶颈。
- 优先用内置函数：
regexp_replace()、date_format()、coalesce()替代手写逻辑 - 字符串拆分不用
udf(lambda x: x.split('|')[0])，改用split(col('raw'), '\|')[0] - 真要复杂逻辑？PySpark 3.3+ 用
pandas_udf(returnType=..., functionType= PandasUDFType.SCALAR)，且确保pd.options.mode.chained_assignment = None关闭警告开销
同步前校验耗时太久？跳过全量扫描，改用采样 + 元数据驱动
为防脏数据阻塞后续同步，有人习惯加一步 df.filter(...).count() 校验。但这个动作会触发全 DAG 执行，尤其当上游是 Hive 表且没统计信息时，等于重算一遍。
- 用采样代替全量：
df.sample(0.01).filter(...).count() * 100，误差可控且快 100 倍 - Hive 表直接查元数据：
DESCRIBE FORMATTED table_name拿numRows，或用ANALYZE TABLE ... COMPUTE STATISTICS提前固化 - 校验逻辑下沉到存储层：Parquet 文件自带
min/max页脚统计，用spark.read.option('pushDownPredicate', 'true')让过滤下推
预处理脚本总在 YARN 上被 Kill？内存配置不是越大越好
看到 Container Killed，第一反应是调大 spark.executor.memory，结果更糟——JVM GC 时间飙升，反被 NodeManager 当作僵死进程干掉。
- 关键参数是
spark.executor.memoryOverhead：设为executor.memory的 30%~40%，尤其处理 JSON/XML 解析时堆外内存吃得多 - 关闭无谓缓存：
spark.sql.inMemoryColumnarStorage.enabled=false，预处理阶段一般不需要列存加速 - 小文件合并陷阱：用
coalesce(50)比repartition(50)更轻量，避免 shuffle 引发的额外内存峰值
预处理不是越“重”越稳，而是越贴近下游同步器的 schema 和分区策略，越不容易在边界处掉链子。比如 Kafka 同步要求每条记录带 __ts_ms 字段，那预处理就该在最后一步才生成它，而不是一上来就加一堆中间时间戳字段——多一次序列化，就多一分延迟风险。
