Airbyte destination-azure-blob-storage 连接器贡献指南测试配置与自定义输出格式扩展【免费下载链接】airbyteOpen-source data movement for ELT pipelines and AI agents — from APIs, databases files to warehouses, lakes, and AI applications. Both self-hosted and Cloud.项目地址: https://gitcode.com/gh_mirrors/ai/airbyte本指南基于destination-azure-blob-storage连接器的 CONTRIBUTING.md即贡献者笔记整理而成。该文档面向连接器的开发者聚焦两大主题如何调整验收测试Acceptance Tests所用的格式配置以及如何为该连接器新增一种输出格式。读完本文你将掌握该连接器在 Kotlin CDK 体系下的配置约束、测试入口以及从格式枚举到 writer 实现再到验收测试的完整扩展链路。一、连接器与文档定位destination-azure-blob-storage是一个将数据写入 Azure Blob Storage 的目标连接器属于 Airbyte 的 Java/Kotlin 目标连接器家族。从当前源码看它的代码组织如下入口 main 函数通过AirbyteDestinationRunner.run(*args)启动连接器配置规格 AzureBlobStorageSpecification声明账号、容器、认证方式与格式等配置项运行配置 AzureBlobStorageConfiguration将用户配置组装为可执行配置Writer 与 ObjectLoader负责实际写入Checker负责连接检查check 命令。而 CONTRIBUTING.md 正是该连接器目录下的“连接器专属贡献说明”——README 也明确说明连接器特有的测试与排障指引记录在各自的 CONTRIBUTING.md 中见 连接器 README。值得注意的是仓库中的 AGENTS.md 与 CONTRIBUTING.md 内容一致AGENTS.md 是给 AI Agent 阅读的镜像说明两处内容可互为参考。二、测试配置如何调整验收测试的格式参数文档首先强调了一个关键约束验收测试中使用的格式配置是可以修改的但修改后的配置必须遵循src/main/resources/spec.json定义的 schema。具体来说你可以修改验收测试使用的格式配置例如文档中的命名约定AzureBlobStorageJsonlDestinationAcceptanceTest.getFormatConfig只要该配置符合spec.json即可。这意味着不得引入 spec 之外的配置键。getFormatConfig返回的配置对象最终会作为连接器配置注入测试流程若包含 spec.json 未声明的字段将导致校验失败格式相关配置与连接器声明保持一致。format字段在 AzureBlobStorageSpecification 中默认实现为JsonFormatSpecification()测试中若改用 CSV 等其他格式同样要遵循 spec 的约束。从当前源码结构看这一“格式配置”体系已经由 Kotlin CDK 的ObjectStorageFormatConfiguration承担——在 AzureBlobStorageConfiguration.kt 中objectStorageFormatConfiguration由pojo.toObjectStorageFormatConfiguration()从用户配置转换而来测试完全可以通过构造不同的 format 配置来覆盖不同格式的写入路径。2.1 测试中可覆盖的配置维度结合 AzureBlobStorageConfiguration 与 AzureBlobStorageClientSpecification验收测试的格式配置可以触及以下维度配置项说明默认值azure_blob_storage_endpoint_domain_nameAzure Blob Storage 端点域名blob.core.windows.netazure_blob_storage_account_name存储账号名空由用户提供azure_blob_storage_container_name容器名空由用户提供azure_blob_storage_shared_access_signatureSAS 共享访问签名与账号密钥二选一无azure_blob_storage_account_key账号密钥与 SAS 二选一无azure_tenant_id/azure_client_id/azure_client_secretAzure AD 服务主体认证参数无azure_blob_storage_spill_size单个 blob 目标大小MB达到后切分新对象0 表示不适用500format输出格式JSON/CSV 等JSON例如在 AzureBlobStorageCheckTest.kt 中测试通过AzureBlobStorageTestUtil构造了账号密钥AccountKey与 SAS 两类配置并分别以JsonFormatSpecification()和CSVFormatSpecification()组合出多组成功用例以及一组“Bad hostname”失败用例——这正是“修改格式配置但遵循 spec 约束”的典型实践。2.2 写入行为相关参数测试观察点虽然这些参数多为内部配置但了解它们有助于理解验收测试的断言对象。在 AzureBlobStorageObjectLoader.kt 中可以看到numPartWorkers分区写入并行度默认 2旧版文件传输模式下为 1numUploadWorkers上传并行度默认 5maxMemoryRatioReservedForParts为分片预留的内存比例默认 0.4若同步流中包含文件型数据则降为 0.2见 AzureBlobStorageConfiguration.ktobjectSizeBytes目标对象大小默认 200 MBpartSizeBytes分片大小默认 10 MB路径模式${NAMESPACE}/${STREAM_NAME}/文件名模式{date}_{timestamp}_{part_number}{format_extension}名称经toAzureBlobSafePath转换以保证 Azure 兼容。验收测试中文件对象数量、命名、分块行为的断言都与上述参数相关。三、添加一种新的输出格式六步扩展流程CONTRIBUTING.md 的核心内容是给出了为连接器新增输出格式的六步操作清单。下面结合当前仓库源码逐条展开说明每一步的具体含义与实现位置。第 1 步在AzureBlobStorageFormat中添加枚举值文档约定新增格式时先在AzureBlobStorageFormat枚举中注册一个新的枚举值。这一枚举的作用是充当“格式分派”的标识——后续的配置构造、writer 选择都以它为入口。说明在当前仓库的源码中格式枚举与格式配置抽象已由 Kotlin CDK 的对象存储模块io.airbyte.cdk.load.command.object_storage.ObjectStorageFormatConfiguration及其子类如JsonFormatSpecification、CSVFormatSpecification承担测试代码中已直接使用这些 CDK 类型见 AzureBlobStorageCheckTest.kt。因此在当前实现中“新增格式”对应的是新增一个ObjectStorageFormatSpecification的实现类文档中的AzureBlobStorageFormat是这一抽象在早期版本中的等价物。第 2 步更新spec.json声明新的格式配置spec.json是连接器的配置规格文件位于src/main/resources/spec.json当前仓库中该文件为构建期由注解生成源码中由 AzureBlobStorageSpecification 的JsonSchemaTitle、JsonProperty、JsonPropertyDescription、JsonSchemaInject等注解驱动。新增格式时必须在 spec 中声明对应配置字段否则平台侧无法渲染该格式的配置表单连接器启动时的配置校验会拒绝未声明字段这也是第 2.1 节“配置必须遵循 spec.json”约束的来源。第 3 步更新AzureBlobStorageFormatConfigs构造新格式配置文档约定AzureBlobStorageFormatConfigs负责把 spec 中的格式配置构造成内部可用的格式配置对象。在当前实现中这一职责落在 AzureBlobStorageConfigurationFactory.makeWithoutExceptionHandling 上它调用pojo.toObjectStorageFormatConfiguration()将用户配置转换为objectStorageFormatConfiguration并同时组装azureBlobStorageClientConfiguration、objectStorageCompressionConfiguration当前使用NoopProcessor即不做压缩处理等。新增格式后需要保证这一转换逻辑能识别并构造新的格式配置。第 4 步在io.airbyte.integrations.destination.azure_blob_storage下创建新的包文档约定每个输出格式拥有独立子包与格式相关的 writer、配置类都放在其中保持模块边界清晰。当前主包为io.airbyte.integrations.destination.azure_blob_storage源码位于 src/main/kotlin测试位于 src/test-integration/kotlin。第 5 步实现一个AzureBlobStorageWriter可继承BaseAzureBlobStorageWriter文档约定writer 负责把目标流数据写入 Azure Blob Storage新增格式时实现AzureBlobStorageWriter并可复用BaseAzureBlobStorageWriter的公共逻辑。从当前源码看AzureBlobStorageWriter 实现了DestinationWriter接口核心方法是createStreamLoader(stream)它委托给ObjectStorageStreamLoaderFactoryAzureBlob, *创建对应流的StreamLoader——也就是说写入能力的通用逻辑分片、并行上传、对象命名由 CDK 对象存储层提供格式差异主要体现在格式配置如 JSON 与 CSV 的序列化方式不同。新增格式时重点在于保证格式配置、序列化处理器与StreamLoader正确装配。第 6 步为新增格式添加验收测试文档约定新增格式必须配套验收测试测试类可继承AzureBlobStorageDestinationAcceptanceTest早期命名的目标连接器验收测试基类。从当前仓库源码结构看测试体系已演化为面向新 CDK 的集成测试类例如AzureBlobStorageWriteTest.kt通过多次实例化AzureBlobStorageWriteTest覆盖不同格式与配置组合的写入场景AzureBlobStorageCheckTest.kt覆盖 check 命令的成功/失败用例JSON、CSV × AccountKey、SASAzureBlobStorageSpecTest.kt 与 AzurePathSpecificationTest.kt分别校验 spec 合法性如 sync modes 支持OVERWRITE与APPEND、支持增量同步见 AzureBlobStorageSpecificationExtension与路径/命名规则。验收测试的价值在于在本地无法访问真实 Azure 环境时可通过 sample_secrets/config.json 模板与测试工具类AzureBlobStorageTestContainer、AzureBlobStorageTestUtil、AzureBlobStorageDataDumper搭建测试数据与容器环境。四、扩展工作的自检清单结合上文新增输出格式时可对照以下清单逐项确认格式标识已注册枚举或 CDK 格式规格类spec.json/spec 注解已声明新格式配置字段且测试配置未超出 spec 约束配置工厂AzureBlobStorageConfigurationFactory能构造新格式配置新格式代码位于io.airbyte.integrations.destination.azure_blob_storage下的独立子包WriterAzureBlobStorageWriter/BaseAzureBlobStorageWriter与 CDK 的ObjectStorageStreamLoaderFactory正确装配格式序列化行为符合预期已新增验收测试继承既有验收测试基类或采用当前测试体系的AzureBlobStorageWriteTest模式并覆盖 check、write、spec 校验与路径规范四个维度。五、总结destination-azure-blob-storage的 CONTRIBUTING.md 虽然篇幅简短却精准地概括了该连接器开发的两条主线以 spec.json 为唯一约束的测试配置实践以及从格式注册到验收测试的六步扩展流程。结合当前仓库源码可以看到这一扩展模式如今已被 Kotlin CDK 的对象存储抽象体系ObjectStorageFormatConfiguration、ObjectStorageStreamLoaderFactory等进一步体系化——理解了本文的配置约束与扩展步骤你既能安全地调整验收测试覆盖新的格式组合也能按既有约定为连接器添加全新的输出格式并通过完善的测试矩阵保证写入、检查、路径与格式行为的一致性。【免费下载链接】airbyteOpen-source data movement for ELT pipelines and AI agents — from APIs, databases files to warehouses, lakes, and AI applications. Both self-hosted and Cloud.项目地址: https://gitcode.com/gh_mirrors/ai/airbyte创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Airbyte destination-azure-blob-storage 连接器贡献指南：测试配置与自定义输出格式扩展
Airbyte destination-azure-blob-storage 连接器贡献指南测试配置与自定义输出格式扩展【免费下载链接】airbyteOpen-source data movement for ELT pipelines and AI agents — from APIs, databases files to warehouses, lakes, and AI applications. Both self-hosted and Cloud.项目地址: https://gitcode.com/gh_mirrors/ai/airbyte本指南基于destination-azure-blob-storage连接器的 CONTRIBUTING.md即贡献者笔记整理而成。该文档面向连接器的开发者聚焦两大主题如何调整验收测试Acceptance Tests所用的格式配置以及如何为该连接器新增一种输出格式。读完本文你将掌握该连接器在 Kotlin CDK 体系下的配置约束、测试入口以及从格式枚举到 writer 实现再到验收测试的完整扩展链路。一、连接器与文档定位destination-azure-blob-storage是一个将数据写入 Azure Blob Storage 的目标连接器属于 Airbyte 的 Java/Kotlin 目标连接器家族。从当前源码看它的代码组织如下入口 main 函数通过AirbyteDestinationRunner.run(*args)启动连接器配置规格 AzureBlobStorageSpecification声明账号、容器、认证方式与格式等配置项运行配置 AzureBlobStorageConfiguration将用户配置组装为可执行配置Writer 与 ObjectLoader负责实际写入Checker负责连接检查check 命令。而 CONTRIBUTING.md 正是该连接器目录下的“连接器专属贡献说明”——README 也明确说明连接器特有的测试与排障指引记录在各自的 CONTRIBUTING.md 中见 连接器 README。值得注意的是仓库中的 AGENTS.md 与 CONTRIBUTING.md 内容一致AGENTS.md 是给 AI Agent 阅读的镜像说明两处内容可互为参考。二、测试配置如何调整验收测试的格式参数文档首先强调了一个关键约束验收测试中使用的格式配置是可以修改的但修改后的配置必须遵循src/main/resources/spec.json定义的 schema。具体来说你可以修改验收测试使用的格式配置例如文档中的命名约定AzureBlobStorageJsonlDestinationAcceptanceTest.getFormatConfig只要该配置符合spec.json即可。这意味着不得引入 spec 之外的配置键。getFormatConfig返回的配置对象最终会作为连接器配置注入测试流程若包含 spec.json 未声明的字段将导致校验失败格式相关配置与连接器声明保持一致。format字段在 AzureBlobStorageSpecification 中默认实现为JsonFormatSpecification()测试中若改用 CSV 等其他格式同样要遵循 spec 的约束。从当前源码结构看这一“格式配置”体系已经由 Kotlin CDK 的ObjectStorageFormatConfiguration承担——在 AzureBlobStorageConfiguration.kt 中objectStorageFormatConfiguration由pojo.toObjectStorageFormatConfiguration()从用户配置转换而来测试完全可以通过构造不同的 format 配置来覆盖不同格式的写入路径。2.1 测试中可覆盖的配置维度结合 AzureBlobStorageConfiguration 与 AzureBlobStorageClientSpecification验收测试的格式配置可以触及以下维度配置项说明默认值azure_blob_storage_endpoint_domain_nameAzure Blob Storage 端点域名blob.core.windows.netazure_blob_storage_account_name存储账号名空由用户提供azure_blob_storage_container_name容器名空由用户提供azure_blob_storage_shared_access_signatureSAS 共享访问签名与账号密钥二选一无azure_blob_storage_account_key账号密钥与 SAS 二选一无azure_tenant_id/azure_client_id/azure_client_secretAzure AD 服务主体认证参数无azure_blob_storage_spill_size单个 blob 目标大小MB达到后切分新对象0 表示不适用500format输出格式JSON/CSV 等JSON例如在 AzureBlobStorageCheckTest.kt 中测试通过AzureBlobStorageTestUtil构造了账号密钥AccountKey与 SAS 两类配置并分别以JsonFormatSpecification()和CSVFormatSpecification()组合出多组成功用例以及一组“Bad hostname”失败用例——这正是“修改格式配置但遵循 spec 约束”的典型实践。2.2 写入行为相关参数测试观察点虽然这些参数多为内部配置但了解它们有助于理解验收测试的断言对象。在 AzureBlobStorageObjectLoader.kt 中可以看到numPartWorkers分区写入并行度默认 2旧版文件传输模式下为 1numUploadWorkers上传并行度默认 5maxMemoryRatioReservedForParts为分片预留的内存比例默认 0.4若同步流中包含文件型数据则降为 0.2见 AzureBlobStorageConfiguration.ktobjectSizeBytes目标对象大小默认 200 MBpartSizeBytes分片大小默认 10 MB路径模式${NAMESPACE}/${STREAM_NAME}/文件名模式{date}_{timestamp}_{part_number}{format_extension}名称经toAzureBlobSafePath转换以保证 Azure 兼容。验收测试中文件对象数量、命名、分块行为的断言都与上述参数相关。三、添加一种新的输出格式六步扩展流程CONTRIBUTING.md 的核心内容是给出了为连接器新增输出格式的六步操作清单。下面结合当前仓库源码逐条展开说明每一步的具体含义与实现位置。第 1 步在AzureBlobStorageFormat中添加枚举值文档约定新增格式时先在AzureBlobStorageFormat枚举中注册一个新的枚举值。这一枚举的作用是充当“格式分派”的标识——后续的配置构造、writer 选择都以它为入口。说明在当前仓库的源码中格式枚举与格式配置抽象已由 Kotlin CDK 的对象存储模块io.airbyte.cdk.load.command.object_storage.ObjectStorageFormatConfiguration及其子类如JsonFormatSpecification、CSVFormatSpecification承担测试代码中已直接使用这些 CDK 类型见 AzureBlobStorageCheckTest.kt。因此在当前实现中“新增格式”对应的是新增一个ObjectStorageFormatSpecification的实现类文档中的AzureBlobStorageFormat是这一抽象在早期版本中的等价物。第 2 步更新spec.json声明新的格式配置spec.json是连接器的配置规格文件位于src/main/resources/spec.json当前仓库中该文件为构建期由注解生成源码中由 AzureBlobStorageSpecification 的JsonSchemaTitle、JsonProperty、JsonPropertyDescription、JsonSchemaInject等注解驱动。新增格式时必须在 spec 中声明对应配置字段否则平台侧无法渲染该格式的配置表单连接器启动时的配置校验会拒绝未声明字段这也是第 2.1 节“配置必须遵循 spec.json”约束的来源。第 3 步更新AzureBlobStorageFormatConfigs构造新格式配置文档约定AzureBlobStorageFormatConfigs负责把 spec 中的格式配置构造成内部可用的格式配置对象。在当前实现中这一职责落在 AzureBlobStorageConfigurationFactory.makeWithoutExceptionHandling 上它调用pojo.toObjectStorageFormatConfiguration()将用户配置转换为objectStorageFormatConfiguration并同时组装azureBlobStorageClientConfiguration、objectStorageCompressionConfiguration当前使用NoopProcessor即不做压缩处理等。新增格式后需要保证这一转换逻辑能识别并构造新的格式配置。第 4 步在io.airbyte.integrations.destination.azure_blob_storage下创建新的包文档约定每个输出格式拥有独立子包与格式相关的 writer、配置类都放在其中保持模块边界清晰。当前主包为io.airbyte.integrations.destination.azure_blob_storage源码位于 src/main/kotlin测试位于 src/test-integration/kotlin。第 5 步实现一个AzureBlobStorageWriter可继承BaseAzureBlobStorageWriter文档约定writer 负责把目标流数据写入 Azure Blob Storage新增格式时实现AzureBlobStorageWriter并可复用BaseAzureBlobStorageWriter的公共逻辑。从当前源码看AzureBlobStorageWriter 实现了DestinationWriter接口核心方法是createStreamLoader(stream)它委托给ObjectStorageStreamLoaderFactoryAzureBlob, *创建对应流的StreamLoader——也就是说写入能力的通用逻辑分片、并行上传、对象命名由 CDK 对象存储层提供格式差异主要体现在格式配置如 JSON 与 CSV 的序列化方式不同。新增格式时重点在于保证格式配置、序列化处理器与StreamLoader正确装配。第 6 步为新增格式添加验收测试文档约定新增格式必须配套验收测试测试类可继承AzureBlobStorageDestinationAcceptanceTest早期命名的目标连接器验收测试基类。从当前仓库源码结构看测试体系已演化为面向新 CDK 的集成测试类例如AzureBlobStorageWriteTest.kt通过多次实例化AzureBlobStorageWriteTest覆盖不同格式与配置组合的写入场景AzureBlobStorageCheckTest.kt覆盖 check 命令的成功/失败用例JSON、CSV × AccountKey、SASAzureBlobStorageSpecTest.kt 与 AzurePathSpecificationTest.kt分别校验 spec 合法性如 sync modes 支持OVERWRITE与APPEND、支持增量同步见 AzureBlobStorageSpecificationExtension与路径/命名规则。验收测试的价值在于在本地无法访问真实 Azure 环境时可通过 sample_secrets/config.json 模板与测试工具类AzureBlobStorageTestContainer、AzureBlobStorageTestUtil、AzureBlobStorageDataDumper搭建测试数据与容器环境。四、扩展工作的自检清单结合上文新增输出格式时可对照以下清单逐项确认格式标识已注册枚举或 CDK 格式规格类spec.json/spec 注解已声明新格式配置字段且测试配置未超出 spec 约束配置工厂AzureBlobStorageConfigurationFactory能构造新格式配置新格式代码位于io.airbyte.integrations.destination.azure_blob_storage下的独立子包WriterAzureBlobStorageWriter/BaseAzureBlobStorageWriter与 CDK 的ObjectStorageStreamLoaderFactory正确装配格式序列化行为符合预期已新增验收测试继承既有验收测试基类或采用当前测试体系的AzureBlobStorageWriteTest模式并覆盖 check、write、spec 校验与路径规范四个维度。五、总结destination-azure-blob-storage的 CONTRIBUTING.md 虽然篇幅简短却精准地概括了该连接器开发的两条主线以 spec.json 为唯一约束的测试配置实践以及从格式注册到验收测试的六步扩展流程。结合当前仓库源码可以看到这一扩展模式如今已被 Kotlin CDK 的对象存储抽象体系ObjectStorageFormatConfiguration、ObjectStorageStreamLoaderFactory等进一步体系化——理解了本文的配置约束与扩展步骤你既能安全地调整验收测试覆盖新的格式组合也能按既有约定为连接器添加全新的输出格式并通过完善的测试矩阵保证写入、检查、路径与格式行为的一致性。【免费下载链接】airbyteOpen-source data movement for ELT pipelines and AI agents — from APIs, databases files to warehouses, lakes, and AI applications. Both self-hosted and Cloud.项目地址: https://gitcode.com/gh_mirrors/ai/airbyte创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考