尧图网站建设 
Airbyte Weatherstack Source 连接器深度指南基于声明式 Manifest 的低代码天气数据接入【免费下载链接】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 仓库中的 Weatherstack 数据源连接器展开介绍其以 Declarative Manifest声明式/低代码方式实现的架构、四大数据流、配置参数与本地测试方法。读完本文你将掌握该连接器从manifest.yaml到运行时行为的完整工作方式并能在自己的数据管道中正确配置和接入实时、预报与历史天气数据。连接器概览零代码的天气数据源Weatherstack 连接器位于仓库 airbyte-integrations/connectors/source-weatherstack 目录是一个典型的DeclarativeSource声明式数据源它没有手写的 Python 或 Java 取数逻辑全部行为由一份 manifest.yaml 声明驱动由 Airbyte 的 Low-Code CDK也称 Connector Builder 底层运行时解释执行。其元数据metadata.yaml显示连接器类型source子类型api镜像airbyte/source-weatherstack版本1.1.14发布阶段alpha支持级别为社区community许可ELv2技术标签cdk:low-code、language:manifest-only即纯清单manifest-only连接器运行时基于基础镜像airbyte/source-declarative-manifest:6.51.0。连接器面向 Weatherstack API一款天气数据服务通过一次同步即可拉取当前天气、天气预报、历史天气与地点自动补全四类数据。架构剖析manifest.yaml 的声明式设计打开 manifest.yaml可以看到一个标准 DeclarativeSource 的四大构成definitions可复用的流定义、streams实际暴露给用户的数据流、spec连接配置的 JSON Schema与schemas各流的输出 Schema。每个数据流都由三块核心部件组成1. 请求器HttpRequester所有流共用url_base: https://api.weatherstack.com/仅path不同http_method均为GET请求参数通过request_parameters使用 Jinja 模板语法从用户配置中取值例如query: {{ config[query] }}、access_key: {{ config[access_key] }}历史流还会带上historical_date: {{ config[historical_date] }}。2. 重试策略CompositeErrorHandler每个流都挂载了组合错误处理器内部是DefaultErrorHandler并配置了WaitTimeFromHeader退避策略读取响应头Retry-After来决定等待时长——这意味着当 Weatherstack API 返回限流或服务端错误时连接器会依据服务端给出的重试时间自动退避而不是立即失败。3. 记录选择器RecordSelector统一使用DpathExtractor且field_path: []取 JSON 根路径即把 API 返回的整个响应对象作为一个 Airbyte 记录输出不做嵌套拆分。Schema 由InlineSchemaLoader内联在 manifest 中定义。连接配置详解三个必填参数连接器的用户配置定义在spec.connection_specification中共三个必填参数required列表含义与约束如下参数类型必填说明access_keystring是Weatherstack API 访问密钥用于鉴权标记为airbyte_secret: true在 UI 中会以密文形式存储与展示querystring是要查询的地点支持城市名、IP、经纬度lat,lon或邮编专业版及以上套餐可用分号分隔查询多个地点。示例值New York、London、98101historical_datestring是启用历史天气接口所需的日期格式YYYY-MM-DD通过pattern: [0-9]{4}-[0-9]{2}-[0-9]{2}强校验默认值2000-01-01。注意历史接口仅付费账户支持一个可复制的参考配置可见 integration_tests/sample_config.json{ query: London, access_key: abc, historical_date: 2000-01-01 }关于 is_paid_account 的版本变更早期的连接器配置中还有一个is_paid_account布尔字段用于指示账户是否为付费账号。从 metadata.yaml 的breakingChanges.1.0.0记录可见1.0.0 版本已移除该配置项未付费账户无法访问的数据流在读取时直接返回空而不再依赖用户手动声明。因此使用当前版本时无需也不应再提供该字段sample 配置中残留的is_paid_account仅为历史测试数据。四大数据流与输出 Schema连接器暴露了四个数据流全部支持full_refresh同步模式见 configured_catalog.json流名称API 端点path用途current_weathercurrent指定地点的实时天气forecastforecast未来天气预报historicalhistorical指定日期historical_date的历史天气location_lookupautocomplete地点自动补全查询返回候选地点列表通用数据字段current_weather / forecast / historical三类天气流共享相同的主体 Schema字段如下requestobjecttype、query、language、unit回显本次请求参数locationobjectname、country、region、lat、lon、timezone_id、localtime、localtime_epoch、utc_offsetcurrentobject实时观测数据包括observation_time、temperature气温、weather_code、weather_icons图标 URL 数组、weather_descriptions文字描述数组、wind_speed、wind_degree、wind_dir风向、pressure气压、precip降水量、humidity湿度、cloudcover云量、feelslike体感温度、uv_index紫外线指数、visibility能见度。其中forecast流额外包含forecast对象字段historical流额外包含historical对象字段这两个子对象在 Schema 中定义为宽松的 object 类型实际内容随 API 响应返回。地点查询流location_lookup结构与天气流不同顶层为request仅含query与results两个字段以及results数组数组元素为name、country、region、lon、lat、timezone_id、utc_offset。适合在配置数据管道前先做地点解析与校验。连接检查与同步流程连接器的check配置为CheckStream指定stream_names: [current_weather]——即连接检查通过实际发起一次current_weather流读取来完成若能用给定access_keyquery成功取回实时天气则判定连接成功。这一设计避免了额外的鉴权探针端点直接复用主数据流验证凭证有效性。同步时每个流先由HttpRequester组装GET {url_base}{path}?query...access_key...请求经过CompositeErrorHandler的退避重试后响应根对象经DpathExtractor直接产出为记录再按内联 Schema 完成字段类型约束与空值null兼容处理。本地开发与自动化测试该连接器的测试资产集中在 integration_tests 目录测试编排由 acceptance-test-config.yml 定义共五个阶段spec以manifest.yaml为 spec 来源校验连接器声明的连接配置结构connection使用secrets/config.json真实凭证不入库验证连接成功同时使用 invalid_config.json含非法日期9999-99-99验证连接失败路径discovery基于真实凭证执行一次 Schema 发现basic_read按 configured_catalog.json 读取四个流的基础数据full_refresh验证全量刷新模式。acceptance.py 提供了连接器验收测试的占位 fixtureabnormal_state.json 则用于测试异常状态构造了非法日期状态下的容错行为。需要说明的是metadata.yaml 中当前仅启用了unitTests套件acceptance 测试套件被注释禁用原因标注为No / Low airbyte cloud usage即云端用量低、收益有限。因此本地验证时可参照 README.md 的指引查看 Airbyte 官方本地连接器开发文档或使用仓库根目录的 poe_tasks.toml / airbyte-ci 工具链触发测试。使用建议与注意事项付费能力边界forecast与historical依赖 Weatherstack 的付费套餐能力。当前版本的设计是拿不到就返回空流因此配置付费账户后请留意流是否真的有数据返回以免误判为同步异常多地点查询若使用专业版及以上套餐可在query中用分号拼接多个地点一条连接即可拉取多个城市的天气限流处理依赖Retry-After响应头的退避策略意味着同步耗时可能被拉长调度频率较高的场景应预留足够超时时间Schema 演进forecast、historical、location_lookup均声明了additionalProperties: trueAPI 新增字段时无需升级连接器即可随记录透传便于兼容未来 API 变化。参考资源连接器入口文档source-weatherstack/README.md声明式定义全文manifest.yaml发布与版本信息metadata.yaml验收测试配置acceptance-test-config.yml测试样例sample_config.json、invalid_config.json、configured_catalog.json【免费下载链接】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 Weatherstack Source 连接器深度指南：基于声明式 Manifest 的低代码天气数据接入
Airbyte Weatherstack Source 连接器深度指南基于声明式 Manifest 的低代码天气数据接入【免费下载链接】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 仓库中的 Weatherstack 数据源连接器展开介绍其以 Declarative Manifest声明式/低代码方式实现的架构、四大数据流、配置参数与本地测试方法。读完本文你将掌握该连接器从manifest.yaml到运行时行为的完整工作方式并能在自己的数据管道中正确配置和接入实时、预报与历史天气数据。连接器概览零代码的天气数据源Weatherstack 连接器位于仓库 airbyte-integrations/connectors/source-weatherstack 目录是一个典型的DeclarativeSource声明式数据源它没有手写的 Python 或 Java 取数逻辑全部行为由一份 manifest.yaml 声明驱动由 Airbyte 的 Low-Code CDK也称 Connector Builder 底层运行时解释执行。其元数据metadata.yaml显示连接器类型source子类型api镜像airbyte/source-weatherstack版本1.1.14发布阶段alpha支持级别为社区community许可ELv2技术标签cdk:low-code、language:manifest-only即纯清单manifest-only连接器运行时基于基础镜像airbyte/source-declarative-manifest:6.51.0。连接器面向 Weatherstack API一款天气数据服务通过一次同步即可拉取当前天气、天气预报、历史天气与地点自动补全四类数据。架构剖析manifest.yaml 的声明式设计打开 manifest.yaml可以看到一个标准 DeclarativeSource 的四大构成definitions可复用的流定义、streams实际暴露给用户的数据流、spec连接配置的 JSON Schema与schemas各流的输出 Schema。每个数据流都由三块核心部件组成1. 请求器HttpRequester所有流共用url_base: https://api.weatherstack.com/仅path不同http_method均为GET请求参数通过request_parameters使用 Jinja 模板语法从用户配置中取值例如query: {{ config[query] }}、access_key: {{ config[access_key] }}历史流还会带上historical_date: {{ config[historical_date] }}。2. 重试策略CompositeErrorHandler每个流都挂载了组合错误处理器内部是DefaultErrorHandler并配置了WaitTimeFromHeader退避策略读取响应头Retry-After来决定等待时长——这意味着当 Weatherstack API 返回限流或服务端错误时连接器会依据服务端给出的重试时间自动退避而不是立即失败。3. 记录选择器RecordSelector统一使用DpathExtractor且field_path: []取 JSON 根路径即把 API 返回的整个响应对象作为一个 Airbyte 记录输出不做嵌套拆分。Schema 由InlineSchemaLoader内联在 manifest 中定义。连接配置详解三个必填参数连接器的用户配置定义在spec.connection_specification中共三个必填参数required列表含义与约束如下参数类型必填说明access_keystring是Weatherstack API 访问密钥用于鉴权标记为airbyte_secret: true在 UI 中会以密文形式存储与展示querystring是要查询的地点支持城市名、IP、经纬度lat,lon或邮编专业版及以上套餐可用分号分隔查询多个地点。示例值New York、London、98101historical_datestring是启用历史天气接口所需的日期格式YYYY-MM-DD通过pattern: [0-9]{4}-[0-9]{2}-[0-9]{2}强校验默认值2000-01-01。注意历史接口仅付费账户支持一个可复制的参考配置可见 integration_tests/sample_config.json{ query: London, access_key: abc, historical_date: 2000-01-01 }关于 is_paid_account 的版本变更早期的连接器配置中还有一个is_paid_account布尔字段用于指示账户是否为付费账号。从 metadata.yaml 的breakingChanges.1.0.0记录可见1.0.0 版本已移除该配置项未付费账户无法访问的数据流在读取时直接返回空而不再依赖用户手动声明。因此使用当前版本时无需也不应再提供该字段sample 配置中残留的is_paid_account仅为历史测试数据。四大数据流与输出 Schema连接器暴露了四个数据流全部支持full_refresh同步模式见 configured_catalog.json流名称API 端点path用途current_weathercurrent指定地点的实时天气forecastforecast未来天气预报historicalhistorical指定日期historical_date的历史天气location_lookupautocomplete地点自动补全查询返回候选地点列表通用数据字段current_weather / forecast / historical三类天气流共享相同的主体 Schema字段如下requestobjecttype、query、language、unit回显本次请求参数locationobjectname、country、region、lat、lon、timezone_id、localtime、localtime_epoch、utc_offsetcurrentobject实时观测数据包括observation_time、temperature气温、weather_code、weather_icons图标 URL 数组、weather_descriptions文字描述数组、wind_speed、wind_degree、wind_dir风向、pressure气压、precip降水量、humidity湿度、cloudcover云量、feelslike体感温度、uv_index紫外线指数、visibility能见度。其中forecast流额外包含forecast对象字段historical流额外包含historical对象字段这两个子对象在 Schema 中定义为宽松的 object 类型实际内容随 API 响应返回。地点查询流location_lookup结构与天气流不同顶层为request仅含query与results两个字段以及results数组数组元素为name、country、region、lon、lat、timezone_id、utc_offset。适合在配置数据管道前先做地点解析与校验。连接检查与同步流程连接器的check配置为CheckStream指定stream_names: [current_weather]——即连接检查通过实际发起一次current_weather流读取来完成若能用给定access_keyquery成功取回实时天气则判定连接成功。这一设计避免了额外的鉴权探针端点直接复用主数据流验证凭证有效性。同步时每个流先由HttpRequester组装GET {url_base}{path}?query...access_key...请求经过CompositeErrorHandler的退避重试后响应根对象经DpathExtractor直接产出为记录再按内联 Schema 完成字段类型约束与空值null兼容处理。本地开发与自动化测试该连接器的测试资产集中在 integration_tests 目录测试编排由 acceptance-test-config.yml 定义共五个阶段spec以manifest.yaml为 spec 来源校验连接器声明的连接配置结构connection使用secrets/config.json真实凭证不入库验证连接成功同时使用 invalid_config.json含非法日期9999-99-99验证连接失败路径discovery基于真实凭证执行一次 Schema 发现basic_read按 configured_catalog.json 读取四个流的基础数据full_refresh验证全量刷新模式。acceptance.py 提供了连接器验收测试的占位 fixtureabnormal_state.json 则用于测试异常状态构造了非法日期状态下的容错行为。需要说明的是metadata.yaml 中当前仅启用了unitTests套件acceptance 测试套件被注释禁用原因标注为No / Low airbyte cloud usage即云端用量低、收益有限。因此本地验证时可参照 README.md 的指引查看 Airbyte 官方本地连接器开发文档或使用仓库根目录的 poe_tasks.toml / airbyte-ci 工具链触发测试。使用建议与注意事项付费能力边界forecast与historical依赖 Weatherstack 的付费套餐能力。当前版本的设计是拿不到就返回空流因此配置付费账户后请留意流是否真的有数据返回以免误判为同步异常多地点查询若使用专业版及以上套餐可在query中用分号拼接多个地点一条连接即可拉取多个城市的天气限流处理依赖Retry-After响应头的退避策略意味着同步耗时可能被拉长调度频率较高的场景应预留足够超时时间Schema 演进forecast、historical、location_lookup均声明了additionalProperties: trueAPI 新增字段时无需升级连接器即可随记录透传便于兼容未来 API 变化。参考资源连接器入口文档source-weatherstack/README.md声明式定义全文manifest.yaml发布与版本信息metadata.yaml验收测试配置acceptance-test-config.yml测试样例sample_config.json、invalid_config.json、configured_catalog.json【免费下载链接】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），仅供参考