Feast HDFS Registry将特性注册表存储在 Hadoop 分布式文件系统上的配置与实践【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feastFeast 的 Registry 是特性仓库中所有对象数据源、特征视图、特征服务等的元数据目录其默认实现是本地文件但在大数据团队中注册表往往需要与 Hadoop 集群同址存放便于统一运维与权限管理。本文以仓库文档 docs/reference/registries/hdfs.md 为主体完整覆盖 HDFS Registry 的前置条件、认证模型与feature_store.yaml配置示例并结合 HDFSRegistryStore 的源码实现与集成测试讲解其读写流程、参数默认值与适用边界帮助你在 Hadoop 环境中正确接入并评估该注册表后端的并发局限。一、HDFS Registry 是什么HDFS registry 支持将 Feast 对象的protobuf 序列化表示数据源、特征视图、特征服务、实体等存储在 Hadoop Distributed File SystemHDFS中。注册表的本质是一个 Protobuf 文件这一点在 Registry 组件文档 中有明确说明文件型注册表将 Feast 元数据以 Protobuf 形式序列化为单个文件可被其他语言程序读取但官方不承诺内部结构的兼容性。需要先明确适用边界文档原文指出虽然 HDFS registry可以用于生产但文件型注册表存在固有局限——修改注册表中的任何单个字段都需要重写整个注册表文件。在多个并发写入者的场景下例如同时为多个特征视图或多个时间区间运行 materialization这带来两类风险数据丢失风险并发写导致后写覆盖先写写入瓶颈所有变更必须串行化注册表写入成为吞吐瓶颈。这一判断在源码中同样可以找到印证registry.py 中关于特征视图版本 pin/revert 路径的注释明确写道“file registry is last-write-wins for true concurrent races……For multi-client environments, use the SQL registry”。因此若团队存在多客户端并发写入需求应优先考虑 SQL Registry。二、前置条件文档给出的硬性要求Hadoop 3.3已安装环境变量HADOOP_HOME已设置。这两项要求源于底层依赖实现基于pyarrow.fs.HadoopFileSystem它通过 JNI 调用宿主机上的 Hadoop 客户端库因此 Feast 进程所在机器必须能访问到 Hadoop 客户端环境。三、认证与用户配置HDFS Registry 的关键差异点这是 HDFS registry 与对象存储类 registryS3/GCS最大的不同务必理解feature_store.yaml中不支持直接指定 HDFS 用户或 Kerberos 凭据。它完全依赖运行 Feast 的进程所能访问的 Hadoop 与系统环境配置。文档说明pyarrow.fs.HadoopFileSystem默认继承底层 Hadoop 客户端库的认证涉及以下环境变量与配置文件HADOOP_USER_NAMEKRB5CCNAMEKerberos 票据缓存hadoop.security.authenticationcore-site.xml与hdfs-site.xml中的其他相关属性换句话说认证策略由进程所在节点的环境决定而不是由 Feast 配置决定。这在实践上意味着使用 simple 认证时写入 HDFS 的文件 owner 通常是HADOOP_USER_NAME或当前系统用户多个服务账号共享同一个注册表文件时需要注意文件权限使用 Kerberos 时Feast 进程持有的票据KRB5CCNAME指向的 ccache决定了它是否有权限读取/写入注册表路径票据过期会导致读写失败。四、配置示例与参数详解文档给出的标准配置如下# feature_store.yaml project: feast_hdfs registry: path: hdfs://[YOUR NAMENODE HOST]:[YOUR NAMENODE PORT]/[PATH TO REGISTRY]/registry.pb cache_ttl_seconds: 60 online_store: null offline_store: null逐项参数说明结合 RepoConfig 源码参数说明registry.path必须以hdfs://scheme 开头格式为hdfs://namenode:port/path/to/registry.pb。源码 hdfs_registry_store.py#L29-L36 中通过urlparse解析 URIscheme 不为hdfs时直接抛ValueErrorport 缺省时默认8020NameNode RPC 端口registry.cache_ttl_seconds本地缓存注册表 proto 的 TTL单位为秒。repo_config.py 中该字段类型为StrictInt默认值 600设为 0 表示每次读取都回源 HDFSregistry.cache_mode可选字段默认sync另有thread模式表示以cache_ttl_seconds为间隔做后台异步刷新。该字段对 HDFS 后端同样生效因为缓存逻辑在 Registry.init中与具体 store 解耦registry.registry_store_type可选的显式指定 store 类型。留空时 Feast 按path的 scheme 自动选择registry.py#L79-L85 的映射表将hdfsscheme 路由到HDFSRegistryStore不支持的 scheme 会报出 Supported schemes are file, s3, gs and hdfs注意 registry.py 中的REGISTRY_STORE_CLASS_FOR_SCHEME映射表gs、s3、file含空 scheme 及 Windows 盘符路径、hdfs四种 scheme 分别路由到对应实现hdfs即指向feast.infra.registry.contrib.hdfs.hdfs_registry_store.HDFSRegistryStore。因此只要path写对了 scheme就无需额外指定 store 类型。五、源码纵深HDFSRegistryStore 的读写流程完整实现位于 hdfs_registry_store.py共约 120 行是理解“注册表如何落到 HDFS 文件”的最佳入口。5.1 构造与依赖检查def __init__(self, registry_config: RegistryConfig, repo_path: Path): try: from pyarrow.fs import HadoopFileSystem except ImportError as e: from feast.errors import FeastExtrasDependencyImportError raise FeastExtrasDependencyImportError( pyarrow.fs.HadoopFileSystem, str(e) )要点依赖在构造函数内惰性导入缺失时抛出FeastExtrasDependencyImportError明确提示缺少pyarrow.fs.HadoopFileSystem——这就是第二节前置条件在代码层的落地随后校验 URI scheme 必须为hdfs以HadoopFileSystem(hostname, port or 8020)建立连接路径部分转为PurePosixPath保存。5.2 读取get_registry_protodef get_registry_proto(self): registry_proto RegistryProto() if _check_hdfs_path_exists(self._hdfs, str(self._path)): with self._hdfs.open_input_file(str(self._path)) as f: registry_proto.ParseFromString(f.read()) return registry_proto raise FileNotFoundError( fRegistry not found at path {self._uri.geturl()}. Have you run feast apply? )先通过_check_hdfs_path_exists调用get_file_info判断是否为FileType.NotFound确认文件存在不存在时抛FileNotFoundError并提示 “Have you runfeast apply?”——上层 Registry.init会捕获该异常记录 “Registry file not found. Creating new registry.” 并立即commit()创建新注册表。所以HDFS 上第一次feast apply会自动创建注册表文件无需手工预置。5.3 写入update_registry_proto → _write_registrydef _write_registry(self, registry_proto: RegistryProto): registry_proto.version_id str(uuid.uuid4()) registry_proto.last_updated.FromDatetime(_utc_now()) dir_path self._path.parent if not _check_hdfs_path_exists(self._hdfs, str(dir_path)): self._hdfs.create_dir(str(dir_path), recursiveTrue) with self._hdfs.open_output_stream(str(self._path)) as f: f.write(registry_proto.SerializeToString())三个关键行为值得注意每次写入都更新version_id新的 UUID与last_updated时间戳可作为注册表“最近一次变更”的审计线索父目录不存在时自动递归创建create_dir(..., recursiveTrue)因此path中可以放心写尚未存在的路径层级写入方式是open_output_stream全量写入序列化后的整个 proto 字节流——这正是文档所述“改一个字段要重写整个文件”的机制根源也是并发写场景下 last-write-wins 行为的技术成因。5.4 删除与项目级元数据teardown()调用delete_file删除注册表文件对应feast teardown清理流程set_project_metadata/get_project_metadataHDFS 后端实现了项目级自定义元数据接口将 JSON 键值对序列化后存入Registry.project_metadata的project_uuid字段并整体写回。上层 Registry.set_project_metadata 通过hasattr探测 store 是否实现该接口未实现则抛NotImplementedError——HDFS 后端属于已实现该能力的一档。六、集成测试证据如何在 CI 中验证 HDFS Registry仓库的 test_universal_registry.py 提供了hdfs_registryfixture展示了端到端验证的完整套路可直接借鉴到自己的测试环境使用 Docker 容器bde2020/hadoop-namenode:2.0.0-hadoop3.2.1-java8与bde2020/hadoop-datanodeHadoop 3.2.1组成名为feast-hdfs-cluster的临时集群NameNode 等待日志标记为namenode.NameNode: NameNode RPC upDataNode 等待successfully registered with NN超时 120 秒DataNode 通过CORE_CONF_fs_defaultFShdfs://namenode:8020指向 NameNode就绪后通过pyarrow.fs.HadoopFileSystem创建/feast目录并写入一个空文件作为初始注册表hdfs://ip:port/feast/registry.db该 fixture 被参数化进通用注册表测试lazy_fixture(hdfs_registry)与其他后端跑同一套注册表读写断言说明 HDFS 后端的 API 行为与 file/s3/gcs 等后端保持一致。需要注意测试镜像是 Hadoop 3.2.1而文档建议生产使用Hadoop 3.3两者不冲突CI 验证的是协议行为生产建议面向客户端兼容性。七、生产使用建议与局限小结结合文档与源码HDFS Registry 的适用画像与注意事项可以归纳为适用已运行 Hadoop 集群、希望注册表与离线数据同集群管理、写入方基本串行如 CI/CD 单一发布通道的团队不适用/需谨慎多客户端并发apply、并发 materialization 同时触发注册表写入的高并发场景——文件型注册表是 last-write-wins应改用 SQL registry配置纪律认证靠进程环境HADOOP_USER_NAME、KRB5CCNAME、core-site.xml/hdfs-site.xmlKerberos 环境下要确保 Feast 进程持有有效票据缓存调优cache_ttl_seconds默认 600 秒控制多进程间看到彼此变更的延迟窗口跨节点多实例部署时可配合cache_mode: thread使用避免长驻进程长期持有过期注册表快照观测每次写入刷新version_id与last_updated可用于排查“注册表到底是谁最后一次写的”。参考路径文档docs/reference/registries/hdfs.md、Registry 组件、注册表索引实现hdfs_registry_store.py、registry.py、repo_config.py测试test_universal_registry.py【免费下载链接】feastThe Open Source Feature Store for AI/ML项目地址: https://gitcode.com/GitHub_Trending/fe/feast创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
