大数据批处理流处理数据工程【免费下载链接】beamApache Beam is a unified programming model for Batch and Streaming data processing.项目地址https://gitcode.com/gh_mirrors/beam4/beam点击查看免费下载本篇指南围绕 Apache Beam 仓库中的.test-infra/terraform/google-cloud-platform/vertex-ai-featurestore模块展开介绍如何通过基础设施即代码Infrastructure-as-Code在 Google Cloud 上自动化创建 Vertex AI Featurestore包括 Featurestore、Entity Type 与 Feature 的完整定义。读完本文你将掌握该模块的三个核心文件variables.tf、featurestore.tf、synthea.tfvars的结构与用法能够自行初始化模块、编写*.tfvars变量文件并完成资源申请并理解其背后的配置语义与监控参数含义。模块定位为 Beam 测试提供 ML 特征存储Apache Beam 的仓库中维护了一套用于测试的基础设施代码Infrastructure-as-Code统一存放于 .test-infra/terraform/google-cloud-platform。这些代码使用 Terraform 为需要 Google Cloud 资源的 Apache Beam 测试预置环境每个子目录负责一类资源。其中 vertex-ai-featurestore 模块专门用于预置一个Vertex AI FeaturestoreGoogle Cloud 面向机器学习特征管理的托管服务。从仓库结构看该模块只包含 4 个文件职责非常收敛README.md模块使用说明初始化、变量文件、apply 步骤variables.tf声明模块所需的全部输入变量及其类型约束featurestore.tf定义实际要创建的 Google Cloud 资源服务启用、Featurestore、Entity Type、Featuresynthea.tfvars一份开箱即用的示例变量文件基于 Synthea 合成的医疗数据构建特征存储。这个模块是为 Beam 的集成测试场景服务的测试需要“接近生产”的 Google Cloud 环境来验证 Beam 与 Vertex AI / 健康医疗数据管道的集成。它本身不包含 Beam 管道代码而是负责把测试所依赖的云侧存储资源准备就绪。环境前提使用该模块前需要先满足 google-cloud-platform 目录的 README 中列出的要求Terraform CLI v1.2.0 及以上Google Cloud SDK并完成gcloud init与gcloud auth登录一个已启用计费billing的 Google Cloud 项目可选但强烈建议IntelliJ 或 VS Code 的 Terraform 插件便于编写与校验.tf/.tfvars文件。所有资源的申请都遵循标准的 Terraform 核心工作流init → plan/apply因此在任何子目录中操作方式一致。三步快速上手1. 初始化 Terraform 模块进入模块目录并执行初始化以拉取 Google 与 random 等 provider 插件cd .test-infra/terraform/google-cloud-platform/vertex-ai-featurestore terraform init2. 创建*.tfvars变量文件Terraform 会从*.tfvars文件读取变量值。在模块同目录下创建一个名字可自定cd .test-infra/terraform/google-cloud-platform/vertex-ai-featurestore touch vars.tfvars然后参考下文“示例变量文件”与“变量说明”两节填充内容。注意模块中project与region没有默认值必须在变量文件中显式给出否则terraform apply会交互式提示输入。3. 应用模块执行 apply 并显式指定变量文件cd .test-infra/terraform/google-cloud-platform/vertex-ai-featurestore terraform apply -var-filevars.tfvars对于变量文件中尚未设置的任何变量Terraform 会逐个提示补全。输入变量详解variables.tf模块的全部输入由 variables.tf 声明共三个变量类型说明projectstring资源将被预置到的 Google Cloud 项目必填无默认值regionstring资源预置所在的 GCP 区域必填无默认值featurestoreobjectFeaturestore 的整体配置见下方嵌套结构featurestore对象包含三层嵌套配置variable featurestore { type object({ // Featurestore 名称前缀。 name_prefix string // 配置 Featurestore 的节点数在线服务容量。 fixed_node_count number // Entity Type 配置map 的 key 即 Entity Type 名称。 entity_types map(object({ // 该 Entity Type 的 features 配置 // map 的 key 是 Feature 名称value 是数据类型 // 例如 BOOL、STRING、INT64 等。 description string features map(string) })) }) }要点说明name_prefix最终 Featurestore 的实际名称会在该前缀基础上追加随机后缀见下文featurestore.tf分析用于避免命名冲突。fixed_node_count在线服务online serving的固定节点数对应online_serving_config的容量。entity_types以 map 表达多个实体类型每个实体类型内features又是 map键为 Feature 名、值为其值类型。允许的数据类型如BOOL、STRING、INT64以 Vertex AI Featurestore API 的ValueType枚举为准。资源定义剖析featurestore.tffeaturestore.tf 完整定义了从 API 启用到 Feature 落地的整条资源链共 4 类资源彼此通过depends_on与引用建立依赖。1. 启用 AI Platform APIprovider google { project var.project } resource google_project_service required { service aiplatform.googleapis.com disable_on_destroy false }模块首先确保目标项目已启用aiplatform.googleapis.comVertex AI 的底层 API。disable_on_destroy false表示销毁该模块资源时不会顺带关闭整个项目的 API避免影响其他依赖此 API 的资源。2. 生成随机后缀resource random_string postfix { length 6 upper false special false }生成 6 位小写字母数字随机串用于 Featurestore 名称去重。3. 创建 Featurestore 本体resource google_vertex_ai_featurestore default { depends_on [google_project_service.required] name ${var.featurestore.name_prefix}_${random_string.postfix.result} region var.region online_serving_config { fixed_node_count var.featurestore.fixed_node_count } }最终名称形如synthea_ab12cd。online_serving_config.fixed_node_count直接对应变量文件中的fixed_node_count决定在线特征检索服务的吞吐容量。4. 创建 Entity Type 及其 FeatureEntity Type实体类型是特征的逻辑分组例如“患者”、“订单”。模块用for_each遍历entity_typesmap 为每个实体类型创建资源resource google_vertex_ai_featurestore_entitytype entities { depends_on [google_project_service.required] for_each var.featurestore.entity_types name each.key featurestore google_vertex_ai_featurestore.default.id description each.value.description monitoring_config { categorical_threshold_config { value 0.3 } numerical_threshold_config { value 0.3 } snapshot_analysis { disabled false monitoring_interval_days 1 staleness_days 21 } } }这里内置了**特征监控feature monitoring**配置是模块的一个关键细节分类特征阈值categorical_threshold_config分布偏移检测阈值0.3数值特征阈值numerical_threshold_config同样为0.3快照分析snapshot_analysis监控未禁用disabled false监控间隔 1 天monitoring_interval_days 1数据陈旧窗口 21 天staleness_days 21即每日对比最近快照与 21 天前的快照来捕捉漂移。Entity Type 之下的每个 Feature 通过for_each逐一创建。由于 Terraform 不支持直接在嵌套 map 上展开两层循环模块先用locals把“实体类型 × 特征”的二维配置拍平成一张表再构建以实体类型名.特征名为键的 map最后交给for_eachlocals { features flatten([ for entitytype_name, entitytype in var.featurestore.entity_types : [ for feature_name, feature_type in entitytype.features : { entitytype_name entitytype_name feature_name feature_name feature_type feature_type } ] ]) features_map tomap({ for feature in local.features : ${feature[entitytype_name]}.${feature[feature_name]} feature }) } resource google_vertex_ai_featurestore_entitytype_feature features { depends_on [google_project_service.required] for_each local.features_map name each.value[feature_name] entitytype google_vertex_ai_featurestore_entitytype.entities[each.value[entitytype_name]].id value_type each.value[feature_type] }这段flatten tomap的写法是理解该模块如何用两重嵌套 map 驱动资源创建的关键外层entity_types决定 Entity Type内层features决定每个 Entity Type 下的 Feature最终每个 Feature 通过索引表达式google_vertex_ai_featurestore_entitytype.entities[...].id挂靠到其所属的 Entity Type 上value_type则写入声明好的数据类型。示例变量文件基于 Synthea 的医疗特征存储模块自带的 synthea.tfvars 是一份可直接 apply 的完整示例。它描述的场景是基于 Synthea 生成的合成患者数据这些数据存放在 Google Cloud FHIR Store 并通过 BigQuery 流式传输FHIR-BigQuery streaming最终被建模进 Vertex AI Featurestore用于医疗相关的机器学习测试。文件开头固定了区域与 Featurestore 基础配置region us-central1 featurestore { name_prefix synthea fixed_node_count 1 entity_types { ... } }由于project在文件中未给出直接运行terraform apply -var-filesynthea.tfvars时项目 ID 会以交互提示的方式要求你输入。该示例定义了 3 个 Entity Type正好演示了BOOL与STRING两类值类型conditionsSnomed 编码的活动性疾病description按 Snomed 编码标识患者是否患有某疾病特征均为BOOL类型如snomed_10509002、snomed_105531004等覆盖数百个 Snomed 代码语义Featurestore 以“实体 ID 时间戳”为索引反映某时刻患者已知的活动性疾病(患者 id, 时间戳, 疾病标志)元组即患者在那一刻的活动性疾病集合。medicationsRxNorm 编码的活动性用药description按 RxNorm 编码标识患者是否有活动性用药特征同样全部为BOOL如rxnorm_1000126、rxnorm_108515等语义与 conditions 相同的时点索引思想(患者 id, 时间戳, 用药标志)表示该时刻已知的活动性用药。observationsLoinc 编码的观测与测量值description按 Loinc 编码标识患者的观测/测量值特征是STRING类型如loinc_10230_1、loinc_10480_2值为LOW、MID、HIGH等级语义(患者 id, 时间戳, 观测值)表示该时刻患者的最新已知观测结果。这一设计很好地展示了 Featurestore 的建模方式同一实体患者在不同实体类型下维护不同维度的时点特征——疾病标志、用药标志、观测分级——全部以id timestamp联合索引便于按时间回溯特征值为时间敏感型 ML 测试提供语义正确的训练样本。从本模块出发如何定制自己的 Featurestore在理解三个文件后你可以按以下步骤定制一套自己的特征存储拷贝或新建*.tfvars参照synthea.tfvars的骨架先设置project、region、name_prefix、fixed_node_count按业务定义entity_types每个实体类型给出descriptionfeaturesmap 中按特征名 数据类型填写注意值类型必须是 Vertex AI 的ValueType允许取值BOOL、STRING、INT64、DOUBLE等例如把snomed_xxx BOOL换成daily_orders INT64在模块目录执行cd .test-infra/terraform/google-cloud-platform/vertex-ai-featurestore terraform init terraform apply -var-file你的文件.tfvars验证与清理apply 完成后可通过terraform state list查看已创建的资源测试结束后用terraform destroy -var-file你的文件.tfvars释放资源不会影响已启用的项目级 API。总结vertex-ai-featurestore模块是 Apache Beam 测试基础设施中一个典型而完整的 Terraform 示例它以 3 个输入变量驱动 4 类云资源的创建用for_eachflatten/tomap技巧将两层嵌套 map 展开为成百上千个 Feature 资源并内建了特征漂移监控配置。无论是为 Beam 与 Vertex AI 的集成测试搭建环境还是学习如何在 Terraform 中批量建模 Google Cloud 的层次化资源这个模块都提供了可直接复用、可本地验证的参考实现。进一步阅读模块总览见 .test-infra/terraform/google-cloud-platform/README.md其余测试基础设施模块如 google-kubernetes-engine遵循相同的工作流。赞分享大数据批处理流处理数据工程【免费下载链接】beamApache Beam is a unified programming model for Batch and Streaming data processing.项目地址https://gitcode.com/gh_mirrors/beam4/beam点击查看免费下载相关推荐Apache Beam 测试基础设施的 GCP Terraform IaC 实战指南从私有 GKE 集群到 Vertex AI FeaturestoreApache Beam 测试基础设施的 GCP Terraform IaC 实战指南从私有 GKE 集群到 Vertex AI Featurestore Ap大数据批处理流处理数据工程使用 Terraform 在 Google Cloud 上为 Apache Beam 测试搭建私有 GKE 集群使用 Terraform 在 Google Cloud 上为 Apache Beam 测试搭建私有 GKE 集群 Apache Beam 的端到端测试如 Ka大数据批处理流处理数据工程Apache Beam 测试基础设施基于 Terraform 与 gcloud IAP 隧道搭建 Kafka 私有网络访问代理Apache Beam 测试基础设施基于 Terraform 与 gcloud IAP 隧道搭建 Kafka 私有网络访问代理 本文围绕 Apache Bea大数据批处理流处理数据工程上一篇MediaPipe疑难问题诊断常见错误与解决方案下一篇uWSGI安装教程pip安装、源码编译与系统包3种方式到底怎么选创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
