数据库流处理后端数据工程【免费下载链接】risingwaveEvent streaming platform for agentic AI. Continuously ingest, transform, and serve event streams in real time, at scale.项目地址https://gitcode.com/gh_mirrors/ri/risingwave点击查看免费下载导读RiseDev 是 RisingWave 仓库中内置的一体化开发工具面向开发者它是一个能自动构建并拉起全部组件的游乐场面向部署场景它是一个配置生成器面向普通用户它也能启动一个最小化的本地环境。本文将带你完整掌握./risedev的使用方法如何一键启动集群、调试单个组件、自定义场景与配置并深入到risedevtool的源码实现讲清risedev.yml的模板展开、变量展开、通配符展开与组件注入四大阶段让你既能熟练使用也能无障碍地为 RiseDev 本身贡献代码。RiseDev 是什么根据仓库中的官方文档 src/risedevtool/README.mdRiseDev 在不同角色面前扮演不同身份开发时它是一个游乐场playground自动完成所有组件的构建与引导bootstrap部署时它是一个配置生成器config generator为每个服务生成命令行参数与配置文件对最终用户它可以启动一个最小化的本地 playground 环境快速体验 RisingWave。整套工具由位于仓库根目录的 risedev 脚本入口与 src/risedevtool核心实现构成。risedev本身是一个 bash 包装脚本负责安装cargo-binstall与cargo-make并把所有命令透传给cargo make执行risedevtool则是用 Rust 编写的配置解析、展开与各服务任务的具体实现。使用级指南如何用 RiseDev 启动与调试集群一键启动集群与运行 e2e 测试在仓库根目录下最简单的用法是./risedev d # 默认开发模式 ./risedev other modes # 指定其他场景 ./risedev k # 杀掉整个集群默认场景default会启动一个包含meta-node、compute-node、frontend的最小集群如未配置额外对象存储meta 元数据默认落在内存中。RiseDev 会自动下载并配置这些服务——第一次运行时risedev脚本还会先执行cargo make configure-if-not-configured触发配置向导见 risedev。除默认场景外官方文档还列举了常用模式场景模式组件构成ci-3cn-1fe3 个 compute-node meta-node 1 个 frontend MinIOci-3cn-3fe3 个 compute-node meta-node 3 个 frontend MinIOci-1cn-1fe1 个 compute-node meta-node 1 个 frontend MinIOdev-compute-node1 个 compute-node由用户自行管理 MinIO prometheus meta frontend例如./risedev dev ci-3cn-1fe ./risedev dev ci-1cn-1fe实际可用的场景远比上述更多。翻阅 risedev.yml 的profile段可以看到仓库内置了fullMinIO Postgres 元数据 双 compactor Prometheus/Grafana Kafka Lakekeeper、for-ctl配合 risectl 使用的最小配置、full-benchmark、ci-backfill-3cn-1fe等数十个配置元数据后端还支持memory/sqlite/postgres/mysql多种选择分别对应meta-1cn-1fe-sqlite、meta-1cn-1fe-pg-backend、meta-1cn-1fe-mysql-backend等场景。调试单个组件user-managed 模式日常开发中常遇到只想调试一个组件却需要拉起其他所有组件让它能跑起来的场景例如单独调试 compute-node。此时使用dev子命令./risedev dev dev-compute-node你会看到类似输出✅ tmux: session risedev ✅ minio: api http://127.0.0.1:9301/, console http://127.0.0.1:9400/ .. compute-node-5688: waiting for user-managed service online... (you should start it!) .. dev cluster: starting 5 services for dev-compute-node...关键点在于dev-compute-node场景中 compute-node 被标记为user-managed: trueRiseDev 会等待你自己启动这个组件——既可以用cargo run在命令行启动也可以挂在 CLion 等调试器下断点调试其余组件meta-node、frontend、MinIO 等则由 RiseDev 自动托管。类似的调试场景还有dev-frontendfrontend 由用户管理、dev-metameta-node 由用户管理、dev-compactorcompactor 由用户管理它们与默认场景的区别仅仅是目标组件被标记为user-managed定义见 risedev.yml。配置文件 risedev.yml场景的本质是组件步骤列表risedev.yml定义了所有可用场景。以ci-3cn-1fe为例实际完整定义见 risedev.ymlprofile: ci-3cn-1fe: - use: compute-node port: 5687 exporter-port: 1222 - use: compute-node port: 5688 exporter-port: 1223 - use: compute-node port: 5689 exporter-port: 1224 - use: meta-node - use: frontendRiseDev 会按顺序启动这 5 个服务。use指定服务类型port: 5687等字段则覆盖该类型的默认配置默认值定义在template段例如 compute-node 默认端口为 5688、exporter 端口为 1222见 risedev.yml。如果不需要某个服务或想调整启动顺序直接增删或调整步骤即可。例如只要两个 compute-nodeprofile: ci-3cn-1fe: - use: compute-node port: 5687 exporter-port: 1222 - use: compute-node port: 5688 exporter-port: 1223 - use: meta-node - use: frontend如果某些组件如 Prometheus、Grafana不想下载可以运行交互式配置工具./risedev configure其余一切配置各服务间如何互相连接、Prometheus 抓取哪些目标、meta 如何感知 compute-node 等都由 RiseDev 自动生成无需手工维护。添加自定义场景profile 与用户场景文件在risedev.yml的profile段下新增一个键值即可新增内置场景。但更推荐的方式是利用risedev-profiles.user.yml——该文件在首次运行时自动生成设计上不受版本控制专门用于存放个人自定义场景。配置解析逻辑会在加载risedev.yml后合并该文件若出现重名 profile 会直接报错见 src/risedevtool/src/config.rs。此外profile 还支持两个与steps平级的可选字段config-path为 RisingWave 组件指定额外的 TOML 配置文件如src/config/ci.tomlenv为整个场景注入环境变量如RUST_LOG: info,risingwave_storage::hummockoff、ENABLE_PRETTY_LOG: true。官方文档同时提醒config-path必须放在 profile 顶层、与steps平级不能写进某个use步骤内部否则会被配置展开器直接拒绝见 src/risedevtool/src/config/use_expander.rs。日志与产物都在哪里RiseDev 的所有产物存放在仓库根目录的.risingwave文件夹日志目录中包含所有组件的运行日志RiseDev 用tmux管理所有组件执行tmux a即可附加到名为risedev的 tmux 会话看到后台运行的所有组件每次启动执行的全部命令会记录在.risingwave/log/risedev.log中便于排查启动问题。开发级指南RiseDev 内部机制组件准备cargo-make 任务编排RiseDev 使用cargo-make完成组件下载与构建。首次启动时会弹出配置向导config wizard询问需要下载哪些组件默认开发环境要求安装全部组件。向导把选择结果写入环境文件risedev-components.user.env典型内容为RISEDEV_CONFIGUREDtrue ENABLE_MINIOtrue ENABLE_BUILD_RUSTtrue之后 cargo-make 读取这份环境文件决定是否执行某个任务步骤。实际运行时的输出类似[cargo-make] INFO - Skipping Task: check-risedev-configured [cargo-make] INFO - Running Task: download-minio [cargo-make] INFO - Running Task: download-mcli [cargo-make] INFO - Skipping Task: download-grafana [cargo-make] INFO - Skipping Task: download-prometheus [cargo-make] INFO - Running Task: build-risingwave由于环境文件中没有设置ENABLE_PROMETHEUS_GRAFANAdownload-grafana、download-prometheus被跳过而ENABLE_MINIOtrue与ENABLE_BUILD_RUSTtrue则触发下载 MinIO / mcli 与构建 RisingWave。所有下载组件、拷贝配置、构建 RisingWave的步骤都以 cargo-make 的 TOML 配置描述分散在 src/risedevtool/*.toml如 risedevtool/risedev-components.toml 定义了configure/configure-if-not-configured任务与根目录 Makefile.toml 中。入口脚本 risedev 会在首次运行时通过cargo binstall cargo-make~0.37自动安装 cargo-make并把./risedev args原样转发为cargo make --allow-private args。配置展开器Config Expanderrisedev.yml简洁而强大要修改配置格式或为 RiseDev 贡献代码就必须理解它的展开机制。核心源码位于 src/risedevtool/src/config。ConfigExpander::expand的完整流水线见 src/risedevtool/src/config.rs依次执行加载根目录risedev.yml全局配置若存在则合并risedev-profiles.user.yml取出目标 profile 的config-path、env、stepsUseExpander模板展开→DollarExpander变量展开→IdExpander通配符展开→ProvideExpander组件注入最后deserialize将展开后的 YAML 反序列化为ServiceConfig列表。RiseDev 支持的use类型非常丰富在反序列化时按字符串分发见 config.rs除 RisingWave 自身的meta-node、compute-node、frontend、compactor外还包括minio、sqlite、postgres、mysql、kafka、pulsar、pubsub、redis、clickhouse、mongodb、elasticsearch、opensearch、nats、mqtt、schema-registry、lakekeeper、moto、moat等周边依赖组件以及opendal、aws-s3等存储后端。获取 VS Code 悬停提示JSON SchemaRiseDev 配置文件的 JSON Schema 定义在 src/risedevtool/schemasrisedev.json、risedev-profiles.user.json、profile.json。在.vscode/settings.json中加入以下配置即可在编辑risedev.yml与risedev-profiles.user.yml时获得字段悬停提示与校验yaml.schemas: { src/risedevtool/schemas/risedev.json: risedev.yml, src/risedevtool/schemas/risedev-profiles.user.json: risedev-profiles.user.yml }模板展开Template Expandingrisedev.yml有template与profile两个顶层段template定义每个组件的默认配置profile定义场景。以下面为例template: compute-node: address: 127.0.0.1 port: 5688 exporter-address: 127.0.0.1 exporter-port: 1222 id: compute-node-${port} provide-minio: minio* user-managed: false profile: ci-3cn-1fe: - use: compute-node port: 5687 exporter-port: 1222UseExpander会把 profile 中的use: compute-node替换为模板中该类型的完整配置再用用户提供的字段覆盖模板中的同名默认值源码实现见 use_expander.rs。展开结果为template: compute-node: address: 127.0.0.1 port: 5688 exporter-address: 127.0.0.1 exporter-port: 1222 id: compute-node-${port} provide-minio: minio* user-managed: false profile: ci-3cn-1fe: - use: compute-node address: 127.0.0.1 exporter-address: 127.0.0.1 id: compute-node-${port} provide-minio: minio* user-managed: false port: 5687 exporter-port: 1222可以看到模板中的port5688与exporter-port1222被用户提供的 5687 / 1222 覆盖本例恰好相同而模板未定义的键如可选字段也会被保留拼接若最终无法反序列化为合法的ServiceConfig会被拒绝。变量展开Variable Expanding展开到 profile 层后${port}这类变量由DollarExpander处理实现见 dollar_expander.rs。它用正则\$\{(.*?)\}匹配变量的取值优先查找当前 YAML map 中的同名字段找不到时再回退到extra_info外部传入的附加变量ci-3cn-1fe: - use: compute-node address: 127.0.0.1 exporter-address: 127.0.0.1 id: compute-node-${port} provide-minio: minio* user-managed: false port: 5687 exporter-port: 1222展开后ci-3cn-1fe: - use: compute-node address: 127.0.0.1 exporter-address: 127.0.0.1 id: compute-node-5687 provide-minio: minio* user-managed: false port: 5687 exporter-port: 1222id: compute-node-${port}中的${port}取当前 map 的port: 5687得到compute-node-5687。这也是 template 中id: compute-node-${port}的默认写法能自动生成唯一实例 ID 的原因。通配符展开Wildcard Expanding*通配符由IdExpander基于场景内所有组件的 id 列表展开实现见 id_expander.rs。例如 frontend 配置frontend: address: 127.0.0.1 port: 4567 id: frontend provide-compute-node: compute-node* provide-meta-node: meta-node* user-managed: false对ci-3cn-1fe有 3 个 compute-node展开为- use: frontend address: 127.0.0.1 port: 4567 id: frontend provide-compute-node: [compute-node-5687, compute-node-5688, compute-node-5689] provide-meta-node: [meta-node-5690] user-managed: false实现上IdExpander先把*前后部分拼成正则^前缀(.*)后缀$再逐一匹配场景中所有 id命中的 id 组成字符串数组。仓库自带单测覆盖了通配匹配与多实例匹配两种情形见 id_expander.rs。组件注入Component Provision最后ProvideExpander把所有provide-*字段展开为对应组件的完整配置实现见 provide_expander.rs。上一步得到的 id 数组此时会被替换为按 id 找到的完整服务配置同时从被注入的配置中剥离其自身的provide-*字段以避免无限嵌套- address: 127.0.0.1 port: 4567 id: frontend provide-compute-node: - address: 127.0.0.1 exporter-address: 127.0.0.1 id: compute-node-5687 user-managed: false use: compute-node port: 5687 exporter-port: 1222 - address: 127.0.0.1 exporter-address: 127.0.0.1 id: compute-node-5688 user-managed: false use: compute-node port: 5688 exporter-port: 1223 - address: 127.0.0.1 exporter-address: 127.0.0.1 id: compute-node-5689 user-managed: false use: compute-node port: 5689 exporter-port: 1224至此frontend 拿到了完整的 compute-node 列表地址、端口、exporter 端口等后续生成前端连接参数、Prometheus 抓取配置、meta-node 注册信息等就有了全部依据。基于这份展开后的配置RiseDev 会为每个服务生成启动所需的命令行参数或配置文件——这一层由 src/risedevtool/src/config_gen 实现其中包含 prometheus_gen.rs、grafana_gen.rs、tempo_gen.rs 等针对监控组件的配置生成器。例如 Prometheus 的抓取目标、Grafana 的数据源、Tempo 的链路采集地址都由这些生成器基于展开后的ServiceConfig计算得出。RiseDev Service按顺序启动与存活检查RiseDev 开发集群读取展开后的配置按步骤顺序启动所有服务任务运行在 tmux 会话中。启动过程的关键约束每个服务的启动任务实现位于 src/risedevtool/src/task包括 compute-node、meta-node、frontend、compactor、minio、kafka、prometheus、grafana、mysql、postgres、redis、pulsar、mqtt 等几十个具体服务的启动逻辑启动每个服务后RiseDev 都会执行**存活检查liveness check**并检查程序返回码确保服务真正进入可用状态如task_tcp_ready_check.rs、task_kafka_ready_check.rs、task_db_ready_check.rs、task_redis_ready_check.rs等 readiness 任务所有由 RiseDev 执行过的命令都可以在.risingwave/log/risedev.log中找到user-managed组件如dev-compute-node场景中的 compute-node不会被 RiseDev 启动而是等待用户自行启动后通过存活检查确认上线。从源码看 RiseDev 的整体结构目录 / 文件仓库根相对路径职责risedev入口脚本安装 cargo-binstall / cargo-make转发cargo make处理 SIGINTrisedev.yml场景profile与组件模板template的权威定义内置全部 CI 与开发场景src/risedevtool/src/config.rsConfigExpander加载 / 合并 YAML串联四个展开器反序列化为ServiceConfigsrc/risedevtool/src/configuse_expander/dollar_expander/id_expander/provide_expander四阶段展开实现src/risedevtool/src/config_gen为 Prometheus / Grafana / Tempo 等生成配置src/risedevtool/src/task各服务启动任务与 readiness 检查任务src/risedevtool/src/service_config.rs各服务反序列化后的强类型配置结构src/risedevtool/schemasrisedev.yml与用户场景文件的 JSON Schemasrc/risedevtool/*.tomlcargo-make 任务定义下载组件、构建等Makefile.toml根级 cargo-make 任务编排小结RiseDev 的设计思路可以概括为一句话一份声明式 YAML场景 模板经过模板展开 → 变量展开 → 通配符展开 → 组件注入四步标准化处理反序列化为强类型服务配置再生成各服务启动参数最后由 tmux 托管、按序拉起并做存活检查。日常使用时你只需记住三个命令——./risedev d启动、./risedev profile选场景、./risedev k停止要调试单个组件时把对应组件标记为user-managed并用./risedev dev profile启动其余部分即可。需要更深入地扩展场景时将自定义配置写入risedev-profiles.user.yml或者直接阅读 src/risedevtool 的源码与单测理解四个展开器的行为后再动手修改配置格式。赞分享数据库流处理后端数据工程【免费下载链接】risingwaveEvent streaming platform for agentic AI. Continuously ingest, transform, and serve event streams in real time, at scale.项目地址https://gitcode.com/gh_mirrors/ri/risingwave点击查看免费下载相关推荐RisingWave 开发环境搭建与开发集群启动指南从源码编译到 RiseDev 实战RisingWave 开发环境搭建与开发集群启动指南从源码编译到 RiseDev 实战 本篇指南围绕 RisingWave 开发者文档中的《How to bu数据库流处理后端数据工程RisingWave 仓库开发指南从架构全景到 RiseDev 构建、测试与 PR 提交流程RisingWave 仓库开发指南从架构全景到 RiseDev 构建、测试与 PR 提交流程 RisingWave 是一个 Postgres 兼容的流式数据库数据库流处理后端数据工程Atlantis Webhook Secrets 安全机制详解从生成、配置到源码级验证原理Atlantis Webhook Secrets 安全机制详解从生成、配置到源码级验证原理 Atlantis 作为 Terraform Pull RequesDevOpsCI/CD基础设施上一篇LimiX部署实战从Docker到分布式推理的完整解决方案下一篇如何高效使用跨平台实时通信库libdatachannel实战指南与优化技巧创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考