数据工程数据集成ETL后端大数据【免费下载链接】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点击查看免费下载Airbyte 仓库中的source-mantle是一个完全由 YAML 清单manifest驱动的声明式连接器用于通过 Mantle API 拉取客户customers与订阅subscriptions两类数据流。本文以该连接器目录下的 README.md 为主线结合同目录的 manifest.yaml、metadata.yaml 与 acceptance-test-config.yml深入讲解声明式连接器的架构组成、请求认证、游标分页、增量同步与配置方式帮助你掌握阅读和复用 Airbyte 低代码连接器的完整方法。什么是 Airbyte 声明式Declarative连接器source-mantle的 README 开头明确说明这是一个使用Connector Builder连接器构建器构建的声明式连接器其底层配置格式遵循Low-Code CDK低代码连接器开发套件。与手写 Python/Java 连接器不同声明式连接器不需要编写执行逻辑代码而是通过一份 YAML 清单manifest来描述如何请求 API、如何解析响应、如何增量同步由 Airbyte CDK 的通用运行时统一解释执行。从仓库内的 manifest.yaml 可以看到连接器的类型声明与描述version: 6.48.15 type: DeclarativeSource description: This connector use the Mantle API to get customers and subscriptions streamstype: DeclarativeSource表明它走的是声明式来源Source运行路径version是 manifest 结构版本号当前仓库为 6.48.15由低代码 CDK 负责向前兼容解析description一句话点出连接器的核心职责调用 Mantle API 获取 customers 与 subscriptions 两个数据流。该连接器属于纯清单manifest-only形态metadata.yaml 的tags字段中language:manifest-only与cdk:low-code两个标签直接印证了这一点。它运行在 Airbyte 提供的source-declarative-manifest基础镜像之上见 metadata.yaml。连接器全貌目录结构与关键文件source-mantle是一个精简的 manifest-only 连接器仓库内只包含以下 5 个文件文件作用README.md连接器说明与开发指引manifest.yaml连接器核心逻辑流定义、认证、分页、增量同步、Schemametadata.yaml发布元数据镜像、阶段、权限、定义 ID 等acceptance-test-config.yml连接器验收测试CAT配置icon.svg连接器图标README 中提到的CONTRIBUTING.md连接器专项排障与测试说明目前在该目录中并不存在因此本文将以 manifest、metadata 与验收测试配置为主体展开分析。数据流与 Schemacustomers 与 subscriptions连接器的数据能力完全由 manifest.yaml 中的streams列表决定共两个流streams: - $ref: #/definitions/streams/customers - $ref: #/definitions/streams/subscriptions两个流都通过$ref引用definitions/streams下预定义的流对象这是低代码 manifest 的标准组织方式先集中定义再在顶层声明引用便于复用与维护。customers 流客户主数据customers 流通过GET v1/customers拉取 Mantle 客户数据其 Schemamanifest.yaml覆盖了典型的客户管理域字段身份与联系人id主键、name、email、domain、contacts联系人数组业务属性industry、countryCode、tags、customFields、test是否测试客户财务指标last30Revenue近 30 天收入、lifetimeValue生命周期价值、averageMonthlyRevenue月均收入电商集成shopifyDomain、shopifyShopId、billingAddress应用安装信息appInstallations数组包含安装的应用详情app、platformId、installedAt、uninstalledAt、评价reviews、订阅subscription、流失预测churnPrediction、churnPredictionLabel等时间戳createdAt、updatedAt、firstInteractionAt。Schema 中id与updatedAt被标记为必填required这与后续主键与增量游标的设计一一对应。subscriptions 流订阅数据subscriptions 流通过GET v1/subscriptions拉取订阅记录其 Schemamanifest.yaml聚焦订阅域标识与状态id必填、active、frozenAt、canceledAt、activatedAt计费金额total、subtotal、presentmentTotal、presentmentSubtotal展示币种金额计划信息嵌套对象plan包含计划名称、金额、interval计费周期、trialDays试用天数、flexBilling、currencyCode、customerTags、shopifyPlans等明细行lineItems数组每行含amount、planId、currencyCode、presentmentAmount等时间点createdAt必填、trialStartsAt、trialExpiresAt、currentPeriodStart、currentPeriodEnd、billingCycleAnchor。两个流的 Schema 都开启了additionalProperties: truemanifest.yaml意味着未来 Mantle API 新增字段时连接器仍可正常接收而无需同步修改 Schema兼顾了健壮性与后续演进空间。认证与请求配置Bearer Token 直连连接器通过 Mantle 开放 APIhttps://api.heymantle.com/拉取数据metadata.yaml 的allowedHosts也限定只允许该域名防止请求被重定向到其他主机。manifest.yaml 中定义了一个被两个流共用的基础请求器base_requesterbase_requester: type: HttpRequester url_base: https://api.heymantle.com/ authenticator: type: BearerAuthenticator api_token: {{ config[\api_key\] }}type: HttpRequester是低代码 CDK 的标准 HTTP 请求组件url_base指定 API 根地址两个流分别在其后拼接v1/customers与v1/subscriptions路径authenticator使用BearerAuthenticator将配置项api_key以 Bearer Token 形式注入请求头。{{ config[api_key] }}是低代码模板语法运行时从用户配置中取值。两个流通过$ref: #/definitions/base_requester复用该请求器避免重复声明认证逻辑——这是 manifest 中定义一次、多处引用的典型实践。分页策略基于游标的 CursorPaginationMantle API 的分页采用游标cursor机制manifest.yaml 中 customers 流的DefaultPaginator配置如下paginator: type: DefaultPaginator page_size_option: type: RequestOption field_name: take inject_into: request_parameter page_token_option: type: RequestOption field_name: cursor inject_into: request_parameter pagination_strategy: type: CursorPagination page_size: 100 cursor_value: {{response[cursor]}} stop_condition: {{ response.hasNextPage is false }}各配置项的含义page_size_option将每页大小作为请求参数take注入 URL query stringinject_into: request_parameterpage_token_option将游标值作为请求参数cursor注入请求参数pagination_strategyCursorPagination策略从响应体 JSON 的cursor字段{{response[cursor]}}提取下一页游标stop_condition当响应中hasNextPage为false时停止翻页page_sizecustomers 流每页 100 条subscriptions 流同样使用 CursorPagination但page_size提高到 10000见 manifest.yaml适合订阅数据量较大的场景。该分页模式与仓库内 分页文档 描述的游标分页范式一致从响应中取出游标、放入下一请求、依据结束条件终止循环直到数据取完。增量同步DatetimeBasedCursor 按时间窗口拉取两个流都配置了基于时间戳的增量同步incremental sync这是数据管道避免全量重拉的常用手段。customers基于 updatedAt 的增量customers 流的增量配置manifest.yamlincremental_sync: type: DatetimeBasedCursor cursor_field: updatedAt start_datetime: type: MinMaxDatetime datetime: {{ config[\start_date\] }} datetime_format: %Y-%m-%dT%H:%M:%SZ datetime_format: %Y-%m-%dT%H:%M:%S00:00 start_time_option: type: RequestOption field_name: minUpdatedAt inject_into: request_parameter cursor_datetime_formats: - %Y-%m-%dT%H:%M:%S00:00cursor_field: updatedAt以记录的更新时间作为增量游标字段Schema 中已将其列为必填start_datetime起始时间取自配置项start_date由MinMaxDatetime组件负责解析与边界约束start_time_option每次请求将游标时间以参数minUpdatedAt注入请求参数实现只拉取更新于该时间之后的数据datetime_format/cursor_datetime_formats声明了 API 返回时间格式%Y-%m-%dT%H:%M:%S00:00与游标比较格式。subscriptions按天步进 回溯窗口 结束时间subscriptions 流的增量配置manifest.yaml更复杂引入了多个实用参数incremental_sync: type: DatetimeBasedCursor step: P1D cursor_field: createdAt end_datetime: type: MinMaxDatetime datetime: {{ now_utc().strftime(%Y-%m-%dT%H:%M:%SZ) }} datetime_format: %Y-%m-%dT%H:%M:%SZ start_datetime: type: MinMaxDatetime datetime: {{ config[\start_date\] }} datetime_format: %Y-%m-%dT%H:%M:%SZ datetime_format: %Y-%m-%dT%H:%M:%S.%fZ end_time_option: type: RequestOption field_name: endDate inject_into: request_parameter lookback_window: PT1H start_time_option: type: RequestOption field_name: startDate inject_into: request_parameter cursor_granularity: PT0.001S cursor_datetime_formats: - %Y-%m-%dT%H:%M:%S.%fZ关键参数解析cursor_field: createdAt以创建时间作为游标Schema 中createdAt为必填step: P1D按天切分时间窗口避免单次请求覆盖过大时间范围导致 API 压力或超时end_datetime动态取当前 UTC 时间{{ now_utc()... }}并通过end_time_option以参数endDate注入请求start_time_option起始时间以参数startDate注入请求lookback_window: PT1H每次同步回溯 1 小时弥补同步执行期间新写入记录被跳过的时间缝隙保证数据不遗漏cursor_granularity: PT0.001S游标最小比较粒度为 1 毫秒适配带毫秒的时间戳格式%Y-%m-%dT%H:%M:%S.%fZ。这套时间窗口 回溯窗口 动态结束时间的组合与仓库内 增量同步文档 描述的DatetimeBasedCursor设计目标完全一致用可配的步进与回溯参数平衡请求次数与数据完整性。连接检查与配置规格Spec连通性检查连接器的 check 逻辑manifest.yaml采用CheckStreamcheck: type: CheckStream stream_names: - customers即通过实际请求 customers 流来验证api_key是否有效、网络是否可达。这是声明式连接器中最常见的连通性检查方式——不额外编写探活代码直接用数据流本身当作心跳。用户配置项manifest.yaml 中的spec定义了用户在 Airbyte UI 中需要填写的内容spec: type: Spec connection_specification: type: object $schema: http://json-schema.org/draft-07/schema# required: - api_key - start_date properties: api_key: type: string order: 0 title: API Key airbyte_secret: true start_date: type: string order: 1 title: Start date format: date-time pattern: ^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}Z$ additionalProperties: true两个必填配置项配置项类型说明api_keystringMantle API 密钥airbyte_secret: true表示在 UI 中加密存储、不回显明文start_datestring增量同步的起始时间格式为YYYY-MM-DDTHH:MM:SSZ由正则pattern约束例如2025-01-01T00:00:00Zorder字段控制字段在 UI 表单中的展示顺序api_key 在前、start_date 在后additionalProperties: true则允许未来增加新配置项而不破坏兼容性。发布元数据镜像、阶段与注册metadata.yaml 记录了连接器的发布与运维信息镜像信息dockerRepository: airbyte/source-mantledockerImageTag: 0.0.38定义 IDdefinitionId: da48299b-4afa-46b4-bb9d-e1ade37e7169连接器唯一标识阶段与支持releaseStage: alpha、supportLevel: community、许可证 MIT注册范围registryOverrides中 OSS 与 Cloud 均开启enabled: true即同时可在自托管版与 Airbyte Cloud 使用连接器类型connectorSubtype: api、connectorType: source基础镜像基于airbyte/source-declarative-manifest:7.33.0带 sha256 摘要锁定保证可复现构建外部参考externalDocumentationUrls指向 Mantle API 参考文档。开发与测试本地运行与验收测试README 的 Development 部分强调本地开发与测试遵循 Airbyte 的本地连接器开发流程。结合仓库内的 acceptance-test-config.yml 可以看到该连接器的测试策略connector_image: airbyte/source-mantle:dev acceptance_tests: spec: tests: - spec_path: manifest.yaml connection: bypass_reason: This is a builder contribution, and we do not have secrets at this time discovery: bypass_reason: This is a builder contribution, and we do not have secrets at this time basic_read: bypass_reason: This is a builder contribution, and we do not have secrets at this time incremental: bypass_reason: This is a builder contribution, and we do not have secrets at this time full_refresh: bypass_reason: This is a builder contribution, and we do not have secrets at this time几点值得注意spec 测试通过spec_path: manifest.yaml直接从 manifest 校验连接器规格无需额外文件其余测试全部 bypassconnection、discovery、basic_read、incremental、full_refresh 均因这是 Builder 贡献的连接器当前没有可用密钥而跳过。也就是说在提供真实api_key之前该连接器的运行时行为真实拉取数据无法被自动化验收测试覆盖这是 alpha 阶段连接器常见状态connector_image: airbyte/source-mantle:dev测试针对本地构建的 dev 镜像执行符合 Airbyte 连接器验收测试CAT的标准配置方式。对于想要在本地验证该连接器行为的开发者README 给出的路径是先在本仓库内构建airbyte/source-mantle:dev镜像再配合 Airbyte 的本地连接器开发工具运行spec、check、discover、read等命令并确保配置中提供有效的 Mantleapi_key与start_date。小结从一份 manifest 读懂整个连接器source-mantle是 Airbyte 低代码连接器形态的一个完整范例没有一行执行代码全部逻辑沉淀在 manifest.yaml 中。阅读它的顺序可以作为理解任何声明式连接器的通用方法论先看type与description确认连接器类型与职责再看streams列表明确提供哪些数据流逐个流拆解requesterURL、认证、paginator分页策略与参数名、record_selector响应提取路径、incremental_sync游标字段、时间窗口、回溯策略回到spec确认用户需要提供哪些配置最后用metadata.yaml与acceptance-test-config.yml判断连接器的发布状态与测试覆盖情况。对于需要对接 Mantle 数据客户、订阅、收入指标或希望以零代码方式快速构建 API 连接器的开发者source-mantle的 manifest 是一份可以直接复用的参考模板——修改url_base、path、field_path与 Schema即可派生出一个全新的声明式来源连接器。赞分享数据工程数据集成ETL后端大数据【免费下载链接】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点击查看免费下载相关推荐Airbyte 低代码 CDK 构建 Missive 源连接器基于 manifest.yaml 的声明式连接器全解析Airbyte 低代码 CDK 构建 Missive 源连接器基于 manifest.yaml 的声明式连接器全解析 导读 本文以 Airbyte 开源仓库中数据工程数据集成ETL后端大数据Airbyte Oncehub 源连接器实战指南基于声明式 manifest 的低代码 ELT 数据接入Airbyte Oncehub 源连接器实战指南基于声明式 manifest 的低代码 ELT 数据接入 本文围绕 Airbyte 仓库中的 Oncehub数据工程数据集成ETL后端大数据Airbyte Uptick 连接器深度解析基于低代码 CDK 的声明式数据同步实现Airbyte Uptick 连接器深度解析基于低代码 CDK 的声明式数据同步实现 Uptick 是一款面向现场服务管理Field Service Man数据工程数据集成ETL后端大数据创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
数据工程数据集成ETL后端大数据【免费下载链接】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点击查看免费下载Airbyte 仓库中的source-mantle是一个完全由 YAML 清单manifest驱动的声明式连接器用于通过 Mantle API 拉取客户customers与订阅subscriptions两类数据流。本文以该连接器目录下的 README.md 为主线结合同目录的 manifest.yaml、metadata.yaml 与 acceptance-test-config.yml深入讲解声明式连接器的架构组成、请求认证、游标分页、增量同步与配置方式帮助你掌握阅读和复用 Airbyte 低代码连接器的完整方法。什么是 Airbyte 声明式Declarative连接器source-mantle的 README 开头明确说明这是一个使用Connector Builder连接器构建器构建的声明式连接器其底层配置格式遵循Low-Code CDK低代码连接器开发套件。与手写 Python/Java 连接器不同声明式连接器不需要编写执行逻辑代码而是通过一份 YAML 清单manifest来描述如何请求 API、如何解析响应、如何增量同步由 Airbyte CDK 的通用运行时统一解释执行。从仓库内的 manifest.yaml 可以看到连接器的类型声明与描述version: 6.48.15 type: DeclarativeSource description: This connector use the Mantle API to get customers and subscriptions streamstype: DeclarativeSource表明它走的是声明式来源Source运行路径version是 manifest 结构版本号当前仓库为 6.48.15由低代码 CDK 负责向前兼容解析description一句话点出连接器的核心职责调用 Mantle API 获取 customers 与 subscriptions 两个数据流。该连接器属于纯清单manifest-only形态metadata.yaml 的tags字段中language:manifest-only与cdk:low-code两个标签直接印证了这一点。它运行在 Airbyte 提供的source-declarative-manifest基础镜像之上见 metadata.yaml。连接器全貌目录结构与关键文件source-mantle是一个精简的 manifest-only 连接器仓库内只包含以下 5 个文件文件作用README.md连接器说明与开发指引manifest.yaml连接器核心逻辑流定义、认证、分页、增量同步、Schemametadata.yaml发布元数据镜像、阶段、权限、定义 ID 等acceptance-test-config.yml连接器验收测试CAT配置icon.svg连接器图标README 中提到的CONTRIBUTING.md连接器专项排障与测试说明目前在该目录中并不存在因此本文将以 manifest、metadata 与验收测试配置为主体展开分析。数据流与 Schemacustomers 与 subscriptions连接器的数据能力完全由 manifest.yaml 中的streams列表决定共两个流streams: - $ref: #/definitions/streams/customers - $ref: #/definitions/streams/subscriptions两个流都通过$ref引用definitions/streams下预定义的流对象这是低代码 manifest 的标准组织方式先集中定义再在顶层声明引用便于复用与维护。customers 流客户主数据customers 流通过GET v1/customers拉取 Mantle 客户数据其 Schemamanifest.yaml覆盖了典型的客户管理域字段身份与联系人id主键、name、email、domain、contacts联系人数组业务属性industry、countryCode、tags、customFields、test是否测试客户财务指标last30Revenue近 30 天收入、lifetimeValue生命周期价值、averageMonthlyRevenue月均收入电商集成shopifyDomain、shopifyShopId、billingAddress应用安装信息appInstallations数组包含安装的应用详情app、platformId、installedAt、uninstalledAt、评价reviews、订阅subscription、流失预测churnPrediction、churnPredictionLabel等时间戳createdAt、updatedAt、firstInteractionAt。Schema 中id与updatedAt被标记为必填required这与后续主键与增量游标的设计一一对应。subscriptions 流订阅数据subscriptions 流通过GET v1/subscriptions拉取订阅记录其 Schemamanifest.yaml聚焦订阅域标识与状态id必填、active、frozenAt、canceledAt、activatedAt计费金额total、subtotal、presentmentTotal、presentmentSubtotal展示币种金额计划信息嵌套对象plan包含计划名称、金额、interval计费周期、trialDays试用天数、flexBilling、currencyCode、customerTags、shopifyPlans等明细行lineItems数组每行含amount、planId、currencyCode、presentmentAmount等时间点createdAt必填、trialStartsAt、trialExpiresAt、currentPeriodStart、currentPeriodEnd、billingCycleAnchor。两个流的 Schema 都开启了additionalProperties: truemanifest.yaml意味着未来 Mantle API 新增字段时连接器仍可正常接收而无需同步修改 Schema兼顾了健壮性与后续演进空间。认证与请求配置Bearer Token 直连连接器通过 Mantle 开放 APIhttps://api.heymantle.com/拉取数据metadata.yaml 的allowedHosts也限定只允许该域名防止请求被重定向到其他主机。manifest.yaml 中定义了一个被两个流共用的基础请求器base_requesterbase_requester: type: HttpRequester url_base: https://api.heymantle.com/ authenticator: type: BearerAuthenticator api_token: {{ config[\api_key\] }}type: HttpRequester是低代码 CDK 的标准 HTTP 请求组件url_base指定 API 根地址两个流分别在其后拼接v1/customers与v1/subscriptions路径authenticator使用BearerAuthenticator将配置项api_key以 Bearer Token 形式注入请求头。{{ config[api_key] }}是低代码模板语法运行时从用户配置中取值。两个流通过$ref: #/definitions/base_requester复用该请求器避免重复声明认证逻辑——这是 manifest 中定义一次、多处引用的典型实践。分页策略基于游标的 CursorPaginationMantle API 的分页采用游标cursor机制manifest.yaml 中 customers 流的DefaultPaginator配置如下paginator: type: DefaultPaginator page_size_option: type: RequestOption field_name: take inject_into: request_parameter page_token_option: type: RequestOption field_name: cursor inject_into: request_parameter pagination_strategy: type: CursorPagination page_size: 100 cursor_value: {{response[cursor]}} stop_condition: {{ response.hasNextPage is false }}各配置项的含义page_size_option将每页大小作为请求参数take注入 URL query stringinject_into: request_parameterpage_token_option将游标值作为请求参数cursor注入请求参数pagination_strategyCursorPagination策略从响应体 JSON 的cursor字段{{response[cursor]}}提取下一页游标stop_condition当响应中hasNextPage为false时停止翻页page_sizecustomers 流每页 100 条subscriptions 流同样使用 CursorPagination但page_size提高到 10000见 manifest.yaml适合订阅数据量较大的场景。该分页模式与仓库内 分页文档 描述的游标分页范式一致从响应中取出游标、放入下一请求、依据结束条件终止循环直到数据取完。增量同步DatetimeBasedCursor 按时间窗口拉取两个流都配置了基于时间戳的增量同步incremental sync这是数据管道避免全量重拉的常用手段。customers基于 updatedAt 的增量customers 流的增量配置manifest.yamlincremental_sync: type: DatetimeBasedCursor cursor_field: updatedAt start_datetime: type: MinMaxDatetime datetime: {{ config[\start_date\] }} datetime_format: %Y-%m-%dT%H:%M:%SZ datetime_format: %Y-%m-%dT%H:%M:%S00:00 start_time_option: type: RequestOption field_name: minUpdatedAt inject_into: request_parameter cursor_datetime_formats: - %Y-%m-%dT%H:%M:%S00:00cursor_field: updatedAt以记录的更新时间作为增量游标字段Schema 中已将其列为必填start_datetime起始时间取自配置项start_date由MinMaxDatetime组件负责解析与边界约束start_time_option每次请求将游标时间以参数minUpdatedAt注入请求参数实现只拉取更新于该时间之后的数据datetime_format/cursor_datetime_formats声明了 API 返回时间格式%Y-%m-%dT%H:%M:%S00:00与游标比较格式。subscriptions按天步进 回溯窗口 结束时间subscriptions 流的增量配置manifest.yaml更复杂引入了多个实用参数incremental_sync: type: DatetimeBasedCursor step: P1D cursor_field: createdAt end_datetime: type: MinMaxDatetime datetime: {{ now_utc().strftime(%Y-%m-%dT%H:%M:%SZ) }} datetime_format: %Y-%m-%dT%H:%M:%SZ start_datetime: type: MinMaxDatetime datetime: {{ config[\start_date\] }} datetime_format: %Y-%m-%dT%H:%M:%SZ datetime_format: %Y-%m-%dT%H:%M:%S.%fZ end_time_option: type: RequestOption field_name: endDate inject_into: request_parameter lookback_window: PT1H start_time_option: type: RequestOption field_name: startDate inject_into: request_parameter cursor_granularity: PT0.001S cursor_datetime_formats: - %Y-%m-%dT%H:%M:%S.%fZ关键参数解析cursor_field: createdAt以创建时间作为游标Schema 中createdAt为必填step: P1D按天切分时间窗口避免单次请求覆盖过大时间范围导致 API 压力或超时end_datetime动态取当前 UTC 时间{{ now_utc()... }}并通过end_time_option以参数endDate注入请求start_time_option起始时间以参数startDate注入请求lookback_window: PT1H每次同步回溯 1 小时弥补同步执行期间新写入记录被跳过的时间缝隙保证数据不遗漏cursor_granularity: PT0.001S游标最小比较粒度为 1 毫秒适配带毫秒的时间戳格式%Y-%m-%dT%H:%M:%S.%fZ。这套时间窗口 回溯窗口 动态结束时间的组合与仓库内 增量同步文档 描述的DatetimeBasedCursor设计目标完全一致用可配的步进与回溯参数平衡请求次数与数据完整性。连接检查与配置规格Spec连通性检查连接器的 check 逻辑manifest.yaml采用CheckStreamcheck: type: CheckStream stream_names: - customers即通过实际请求 customers 流来验证api_key是否有效、网络是否可达。这是声明式连接器中最常见的连通性检查方式——不额外编写探活代码直接用数据流本身当作心跳。用户配置项manifest.yaml 中的spec定义了用户在 Airbyte UI 中需要填写的内容spec: type: Spec connection_specification: type: object $schema: http://json-schema.org/draft-07/schema# required: - api_key - start_date properties: api_key: type: string order: 0 title: API Key airbyte_secret: true start_date: type: string order: 1 title: Start date format: date-time pattern: ^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}Z$ additionalProperties: true两个必填配置项配置项类型说明api_keystringMantle API 密钥airbyte_secret: true表示在 UI 中加密存储、不回显明文start_datestring增量同步的起始时间格式为YYYY-MM-DDTHH:MM:SSZ由正则pattern约束例如2025-01-01T00:00:00Zorder字段控制字段在 UI 表单中的展示顺序api_key 在前、start_date 在后additionalProperties: true则允许未来增加新配置项而不破坏兼容性。发布元数据镜像、阶段与注册metadata.yaml 记录了连接器的发布与运维信息镜像信息dockerRepository: airbyte/source-mantledockerImageTag: 0.0.38定义 IDdefinitionId: da48299b-4afa-46b4-bb9d-e1ade37e7169连接器唯一标识阶段与支持releaseStage: alpha、supportLevel: community、许可证 MIT注册范围registryOverrides中 OSS 与 Cloud 均开启enabled: true即同时可在自托管版与 Airbyte Cloud 使用连接器类型connectorSubtype: api、connectorType: source基础镜像基于airbyte/source-declarative-manifest:7.33.0带 sha256 摘要锁定保证可复现构建外部参考externalDocumentationUrls指向 Mantle API 参考文档。开发与测试本地运行与验收测试README 的 Development 部分强调本地开发与测试遵循 Airbyte 的本地连接器开发流程。结合仓库内的 acceptance-test-config.yml 可以看到该连接器的测试策略connector_image: airbyte/source-mantle:dev acceptance_tests: spec: tests: - spec_path: manifest.yaml connection: bypass_reason: This is a builder contribution, and we do not have secrets at this time discovery: bypass_reason: This is a builder contribution, and we do not have secrets at this time basic_read: bypass_reason: This is a builder contribution, and we do not have secrets at this time incremental: bypass_reason: This is a builder contribution, and we do not have secrets at this time full_refresh: bypass_reason: This is a builder contribution, and we do not have secrets at this time几点值得注意spec 测试通过spec_path: manifest.yaml直接从 manifest 校验连接器规格无需额外文件其余测试全部 bypassconnection、discovery、basic_read、incremental、full_refresh 均因这是 Builder 贡献的连接器当前没有可用密钥而跳过。也就是说在提供真实api_key之前该连接器的运行时行为真实拉取数据无法被自动化验收测试覆盖这是 alpha 阶段连接器常见状态connector_image: airbyte/source-mantle:dev测试针对本地构建的 dev 镜像执行符合 Airbyte 连接器验收测试CAT的标准配置方式。对于想要在本地验证该连接器行为的开发者README 给出的路径是先在本仓库内构建airbyte/source-mantle:dev镜像再配合 Airbyte 的本地连接器开发工具运行spec、check、discover、read等命令并确保配置中提供有效的 Mantleapi_key与start_date。小结从一份 manifest 读懂整个连接器source-mantle是 Airbyte 低代码连接器形态的一个完整范例没有一行执行代码全部逻辑沉淀在 manifest.yaml 中。阅读它的顺序可以作为理解任何声明式连接器的通用方法论先看type与description确认连接器类型与职责再看streams列表明确提供哪些数据流逐个流拆解requesterURL、认证、paginator分页策略与参数名、record_selector响应提取路径、incremental_sync游标字段、时间窗口、回溯策略回到spec确认用户需要提供哪些配置最后用metadata.yaml与acceptance-test-config.yml判断连接器的发布状态与测试覆盖情况。对于需要对接 Mantle 数据客户、订阅、收入指标或希望以零代码方式快速构建 API 连接器的开发者source-mantle的 manifest 是一份可以直接复用的参考模板——修改url_base、path、field_path与 Schema即可派生出一个全新的声明式来源连接器。赞分享数据工程数据集成ETL后端大数据【免费下载链接】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点击查看免费下载相关推荐Airbyte 低代码 CDK 构建 Missive 源连接器基于 manifest.yaml 的声明式连接器全解析Airbyte 低代码 CDK 构建 Missive 源连接器基于 manifest.yaml 的声明式连接器全解析 导读 本文以 Airbyte 开源仓库中数据工程数据集成ETL后端大数据Airbyte Oncehub 源连接器实战指南基于声明式 manifest 的低代码 ELT 数据接入Airbyte Oncehub 源连接器实战指南基于声明式 manifest 的低代码 ELT 数据接入 本文围绕 Airbyte 仓库中的 Oncehub数据工程数据集成ETL后端大数据Airbyte Uptick 连接器深度解析基于低代码 CDK 的声明式数据同步实现Airbyte Uptick 连接器深度解析基于低代码 CDK 的声明式数据同步实现 Uptick 是一款面向现场服务管理Field Service Man数据工程数据集成ETL后端大数据创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
