Azure数据湖原始接入层支撑下游校验的CSV Schema推断最佳实践咨询

已有方案失效的核心原因 #

使用ADF转AVRO、Purview扫描得到全字符串字段的结果，本质是两类服务的默认设计逻辑导致的：

• CSV本身是无类型的纯文本格式，ADF内置的CSV解析器默认不会主动扫描数据样本判断真实类型，所有字段都会直接映射为string类型，哪怕转存为AVRO格式，也会沿用这个字符串映射规则，不会自动推导整数、日期等类型。
• Purview的默认CSV扫描逻辑同样不会开启高精度的类型推断，默认采样比例极低，所有列无论实际存的是数值还是文本，都会统一标记为字符串类型，生成的元数据完全无法作为后续Schema校验的依据。

Databricks（Spark）方案的选型判断 #

针对“每日批量动态接入多CSV文件、自动推断Schema供下游校验”的需求，Databricks方案是当前Azure生态下适配性最高的选择，简洁性与必要性都能满足要求：

• 简洁性：Spark CSV读取器内置了成熟的自动类型推断能力，不需要编写自定义解析逻辑，仅通过两个核心配置就能激活能力，单文件推断的核心代码量不到10行。
• 必要性：其他现有Azure原生方案都无法满足动态批量的要求：
  • ADF原生转AVRO流程需要人工为每个文件、每个列显式配置类型映射规则，遇到新增文件、列结构变动的场景必须人工调整，长期运维成本极高。
  • Purview扫描即便开启了类型推断开关，也无法支撑批量多文件的Schema统一提取，且推断精度不足，无法区分长数字编号列、0/1标志列的正确类型。
• 适配性：Spark的批量读取能力天然支持遍历目录下所有当日新增的CSV文件，按同业务分组自动合并提取Schema，完全适配每日定时管道的运行要求。

批量场景落地流程 #

整个流程可以完全集成在现有Azure管道中，不需要引入第三方服务：

• 配置ADF定时管道，每日触发Databricks作业，扫描数据湖原始接入层目录，按业务子目录对当日新增CSV做分组。
• 在Databricks作业中对每个分组的同类CSV执行读取推断，核心配置如下：

  # 自动推断CSV Schema的核心代码
  inferred_schema = (spark.read
    .option("header", "true")  # 识别首行表头为列名
    .option("inferSchema", "true")  # 激活自动类型推断
    .option("samplingRatio", 0.1)  # 提升10%的样本扫描比例，降低误判概率
    .csv(f"{CSV目录路径}/*.csv")
    .schema
  )
  

• 将推断得到的Schema，按「业务表名称、Schema版本、生成时间」三个维度，统一存入Delta格式的元数据表中，供下游Schema校验环节直接调用。
• 针对特殊列做轻量规则补全：
  • 识别列名包含"编号"、"ID"的长数字列，手动将其类型修正为string，避免自动推断将NAICS公司编号识别为整数类型
  • 每个州对应的0/1取值列，Spark会自动识别为integer类型，完全匹配目标数据格式要求，不需要额外配置。

轻量备选方案边界 #

如果后续接入的文件量极小（每日单文件、结构长期固定），可以用ADF数据流的预览功能自动识别列类型，将识别结果固化为静态Schema映射规则，但这种方式完全不支持动态批量的场景，一旦遇到批量接多文件、列结构变动的情况，就会出现校验偏差，仅适合临时场景使用，不适合长期生产管道。

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