尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

OpenMetadata Storage Service 元数据管道配置指南:Manifest、过滤与覆盖策略

OpenMetadata Storage Service 元数据管道配置指南:Manifest、过滤与覆盖策略 OpenMetadata Storage Service 元数据管道配置指南Manifest、过滤与覆盖策略【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadataOpenMetadata 的 Storage Service对象存储服务元数据摄取管道Metadata Pipeline负责将 S3、GCS、Azure Blob 等对象存储中的容器Container及其数据文件结构、分区信息、标签等元数据同步到 OpenMetadata 目录中。本篇指南以 UI 中 Storage 服务的元数据管道配置文档metadata.md为骨架逐项讲解容器过滤、Debug 日志、默认 ManifestdefaultManifest、元数据覆盖、重试与失败策略等全部配置项并结合仓库内的 JSON Schema 与 Python 摄取源码深入说明每个参数在底层是如何被解析和执行的。读完本文你将能够独立为 Storage 服务配置一套精确、可控、可排障的元数据摄取管道。配置入口与数据流概览Storage 服务的元数据管道配置在 OpenMetadata UI 中通过向导表单呈现其字段定义来源于 JSON Schema storageServiceMetadataPipeline.json{ title: StorageServiceMetadataPipeline, description: StorageService Metadata Pipeline Configuration., type: object, properties: { containerFilterPattern: { $ref: ../type/filterPattern.json#/definitions/filterPattern }, storageMetadataConfigSource: { oneOf: [ ... ] }, markDeletedContainers: { type: boolean, default: true }, overrideMetadata: { type: boolean, default: false }, includeTags: { type: boolean, default: false }, defaultManifest: { type: string, uiFieldType: code, format: json, default: null } }, additionalProperties: false }摄取时管道配置文件会被解析为StorageServiceMetadataPipeline对象交给摄取源执行。核心入口在 storage_service.py源初始化时会先做连接测试然后尝试加载全局 Manifest随后按容器逐个产出CreateContainerRequest写入 OpenMetadata 服务端。下面各节逐项说明 UI 中出现的每一个配置。容器过滤模式Container Filter PatternContainer Filter Pattern用于控制哪些容器参与元数据摄取包含Include与Exclude两组正则表达式列表Include包含在Include字段中列出正则表达式OpenMetadata 将只摄取名称匹配其中任意一个正则的容器其余容器全部排除。例如只想摄取名称以demo开头的容器可填写^demo.*。Exclude排除在Exclude字段中列出正则表达式OpenMetadata 将排除名称匹配其中任意一个正则的容器其余容器全部纳入。例如要排除名称中含demo的容器可填写.*demo.*。该字段在 Schema 中直接复用 filterPattern.json 定义的filterPattern含includes、excludes两个字符串数组因此与其他连接器的过滤模式语法保持一致。值得注意的一个底层细节containerFilterPattern不仅作用于直接列举的容器还会被应用到 Manifest 条目解析出的dataPath上。在 storage_service.py 的filter_manifest_entries中管道级过滤规则会统一作用于每个桶的 Manifest 条目这意味着你可以在管道上写一条全局规则例如excludes: [_SUCCESS]就同时作用于所有桶的 Manifest而无需逐个编辑 Manifest 文件。同一方法中还会默认跳过 Spark/Delta 内部工件_SUCCESS、_delta_log、_temporary、_spark_metadata、.tmp等避免它们污染目录。启用调试日志Enable Debug Logs开启Enable Debug Log开关后摄取进程的日志级别会被设置为 debug。你可以在该服务Service的Ingestion 标签页中查看这些日志用于深挖执行过程中遇到的错误。从配置角度看日志级别对应 workflow.json 中logLevels枚举DEBUG/INFO/WARN/ERROR默认INFO并通过workflowConfig.loggerLevel注入默认INFO。日常排障建议先保持默认级别运行出现异常后再开启 Debug 复查 Ingestion 标签页中的完整堆栈与请求细节排障完成后记得关闭避免产生大量日志。默认 ManifestDefault Manifest三级优先级回退defaultManifest是管道配置中优先级最低的回退 Manifest仅在全局storageMetadataConfigSource与桶级openmetadata.json都未提供对应条目时才被使用。它的典型价值在于管理员可以在管道配置中先播种一份初始 Manifest同时允许桶的所有者之后自行上传各自的 Manifest 文件实现自助式治理。优先级从高到低全局storageMetadataConfigSource如果配置了该桶自身的openmetadata.jsonManifest 文件管道配置中的defaultManifest。这一优先级顺序在源码中有明确实现storage_service.py 的_resolve_manifest_entries方法依次尝试全局 Manifest按containerName过滤、桶级文件_load_metadata_file、管道级defaultManifest同样按containerName过滤命中即返回。与桶级 Manifest 的 Schema 差异匹配规则与桶级openmetadata.json相同但 Schema 因所在位置不同而有区别在defaultManifest中每个条目必须包含containerName因为管道级回退可能面向多个桶在桶级openmetadata.json中文件本身已归属单个桶因此containerName不是必需的。每个条目可接受字面量dataPath或 glob 风格模式*匹配单个路径段、**匹配任意深度、?匹配单个字符。defaultManifest示例注意必须包含containerName{ entries: [ { containerName: analytics-prod, dataPath: data/*/events/*.parquet, structureFormat: parquet, autoPartitionDetection: true }, { containerName: analytics-prod, dataPath: logs/**/*.json, structureFormat: json } ] }条目字段详解defaultManifest的条目结构定义于 manifestMetadataConfig.jsoncontainerName与dataPath为必填项其余字段可选字段含义默认值containerName数据所在顶层容器名管道级 Manifest 必填必填dataPath相对容器的字面量路径或 glob 模式必填structureFormat用于 Schema 推断的期望文件格式留空则按文件扩展名自动推断启用 Unstructured Data 时忽略nullunstructuredData为true时匹配 glob 的文件按独立容器编目不做 Schema 抽取适用于图片、文档等非表格文件falseunstructuredFormats字面量 dataPath 的旧版选项要按非结构化编目的扩展名列表如 png、pdf、jpg新配置推荐用unstructuredData globnullseparatorCSV 等分隔符文件的列分隔符nullisPartitioned数据是否分区falseautoPartitionDetection为true且 dataPath 为 glob 时自动从匹配路径检测 Hive 风格分区列如year2024/month01字面量路径忽略此选项falseexcludePathsglob 发现时要跳过的路径段路径含其中任一段的文件被忽略未设置时应用常见默认值_delta_log、_temporary、_spark_metadata、.tmp、_SUCCESSnullexcludePatternsglob 发现时要排除的 glob 模式列表nullpartitionColumns显式分区列定义name/dataType 必填dataTypeDisplay/description 可选提供后覆盖自动检测nulldepth数据文件所在的存储路径层级深度0解析与容错机制源码视角defaultManifest在 UI 中是一段 JSON 字符串Schema 中uiFieldType: code、format: json摄取源会把它解析成ManifestMetadataConfig对象。解析逻辑位于 storage_service.py 的_parsed_default_manifest未设置 / 空字符串静默返回None不产生告警JSON 语法错误记录 WARNING含行号、列号与错误信息并将告警写入工作流状态回退 Manifest 被忽略Schema 校验失败记录 WARNING含 Pydantic 逐字段错误详情回退 Manifest 被忽略。也就是说即使defaultManifest写得有问题管道也不会直接失败而是降级为无回退 Manifest并在 Ingestion 标签页暴露原因方便定位。glob 展开当前仅 S3 支持当条目的dataPath是 glob 模式时摄取源会将其展开为具体的元数据条目实现在expand_entrystorage_service.py字面量路径直接透传保持向后兼容glob 展开依赖list_keys列出对象键目前仅 S3 实现了该能力storage_service.py 注释明确说明 GCS 与 Azure 尚为后续计划未实现前这些云厂商的 glob 模式只会记录告警而不匹配任何对象字面量路径仍可正常工作glob 展开会应用excludePaths与excludePatternsautoPartitionDetection为真时调用detect_hive_partitions从匹配路径检测 Hive 风格分区列未显式设置structureFormat时通过infer_structure_format依据首个匹配文件的扩展名推断格式推断失败则跳过该条目并告警展开过程按条目隔离异常expand_entriesstorage_service.py单条目失败不会阻断其余条目失败原因会记录到工作流状态。全局 Manifest 与桶级 Manifest 的加载全局 ManifeststorageMetadataConfigSource支持NoMetadataConfigurationSource无全局 Manifest、本地文件、HTTP、S3、ADLS、GCS 六种来源。加载逻辑在 storage_metadata_config.py 中以singledispatch按配置类型分发统一解析为ManifestMetadataConfig读取失败抛StorageMetadataConfigException在 storage_service.py 中被捕获并降级为无全局 Manifest。桶级 ManifestS3 摄取源在_load_metadata_files3/metadata.py中读取桶根目录下的openmetadata.json文件名为常量OPENMETADATA_TEMPLATE_FILE_NAME openmetadata.json见 storage_service.py。文件缺失按预期处理INFOJSON 语法错误或 Schema 校验失败分别给出带行号/字段细节的 WARNING并同步到工作流状态。覆盖元数据Override MetadataOverride Metadata开关控制是否用从源端获取的元数据覆盖 OpenMetadata 服务端已有的元数据开启源端获取的元数据将覆盖并替换 OpenMetadata 中已存在的元数据关闭源端元数据不会覆盖 OpenMetadata 服务端已有值仅当某个字段在 OpenMetadata 中尚无值时才会被更新。该开关仅对description描述、tags标签、owner所有者和displayName显示名这类字段生效。Schema 中该字段默认值为falsestorageServiceMetadataPipeline.json即默认行为是保守更新——不覆盖用户已在 OpenMetadata 中维护的人工元数据。当多人协作治理元数据时建议保持关闭避免源端往往无描述信息清空人工填写的内容。重试次数Number of Retriesretries指定工作流在失败时的重试次数。该配置作用于整个摄取工作流的执行层面在底层OpenMetadata 摄取端与服务器通信的 HTTP 客户端同样具备重试机制——client.py 中self._retry self.config.retry记录实例级重试预算且每次请求可单独覆盖retries为0或负数时表示不重试client.py重试等待时间按retry_wait_base * (total_retries - retry 1)递增退避client.py。配置建议对网络抖动敏感的远端存储服务可设置 13 次重试若希望失败后立即暴露问题并触发告警可设为 0。失败即报错Raise on ErrorRaise on Error决定工作流遇到处理错误时是标记为失败还是吞掉异常继续执行开启工作流在遇到处理错误时被标记为失败关闭避免抛出异常工作流可继续运行。该字段在 workflow.json 的workflowConfig中定义默认值为true。同一配置块还提供了successThreshold成功阈值默认90取值范围 0100即使未开启抛错当成功处理的记录比例低于阈值时管道仍会被标记为失败。生产环境建议保持默认开启让异常及时暴露在管道的运行历史与告警中仅在明确希望部分成功也算成功的探索性场景下才关闭。配置建议小结配置项推荐取值适用场景Container Filter Patternincludes/excludes按需填写正则只摄取相关容器、排除临时桶或 Spark 工件Enable Debug Logs排障时开启平时关闭深挖摄取错误Default Manifest桶级openmetadata.json缺失时的播种方案条目务必带containerName管理员初始种子 桶主自助治理Override Metadata默认关闭保护人工维护的 description/tags/owner/displayNameNumber of Retries03网络抖动容忍度Raise on Error默认开启让失败可见、可告警以上所有配置均可在 Storage 服务详情的 Ingestion 标签页中创建/编辑管道时完成配置保存后即可触发摄取并在运行历史中查看日志与状态。若需进一步了解 Manifest 的文件级用法可继续阅读 manifestMetadataConfig.json 与桶级加载实现 s3/metadata.py。【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表