DataY DataX Nifi DolphinScheduler轻量数据平台如何把技术栈做减法过去几年我们习惯用「堆组件」的方式解决数据问题同步用 DataX编排用 Nifi调度用 DolphinScheduler计算用 Spark/Flink存储用 Hive/HDFS查询用 ClickHouse……组件越堆越多平台越来越重最后发现真正被数据量难住的场景没多少先被技术栈难住的团队倒不少。DataY 想做的是把这件事重新做一遍用一套自研的流批一体集成框架、一套自研的分布式调度、一个轻量数据湖把 DataX Nifi DolphinScheduler 的能力收进一个 JAR。一、数据平台的「军备竞赛」正在拖垮大多数团队先看一张很多团队都似曾相识的架构清单环节常见选型背后还要带上数据同步DataX、Sqoop、Flink CDC任务机、调度器、驱动包、版本兼容流程编排Nifi、AirflowZooKeeper、元数据库、Web 服务任务调度DolphinScheduler、AzkabanMaster/Worker 集群、注册中心、告警批流计算Spark、FlinkYARN/K8s、Checkpoint 存储、资源队列数据存储HDFS、Hive、Hudi、IcebergNameNode、Metastore、小文件治理查询分析ClickHouse、Doris、StarRocks多副本集群、扩容、慢查询治理元数据/权限Atlas、Ranger又一套服务、又一套账号体系这套架构本身没有错。错的是把它当成所有团队的默认答案。大厂做这套东西是因为数据量真的到了 PB 级、并发真的到了成百上千、组织真的需要隔离。但大量中小企业、业务部门、区域团队面对的是另一道题数据量在 GB 到几十 TB 之间时效要求是分钟级、小时级而不是毫秒级用数的人不多但每个人都希望「今天提需求明天就能看数」团队里没有专职大数据工程师更养不起一个平台运维组。于是就会出现一种荒诞的对比业务数据只有 200G平台组件先占了 200G 内存。这不是技术问题是架构错配。而错配的代价远不止几台机器部署复杂每个组件都有自己的安装方式、配置文件、版本矩阵和踩坑文档链路断裂数据从 A 组件流到 B 组件状态、权限、口径各存一份出了问题很难端到端定位资源浪费为了「高可用」每个组件都至少三副本小团队的实际负载却长期低于 10%人才门槛高招一个能同时玩转 Spark、Flink、DolphinScheduler、Hive 的人成本远高于业务本身创新被拖慢想接一个 MySQL、做一个日报先要过一遍平台立项、资源申请、组件选型。技术栈本该是手段最后却成了目的。二、先想清楚一个数据平台到底需要几套技术栈把花哨的概念剥掉数据平台的需求其实只有五句话进得来把分散在各处的数据稳定、增量、实时地接进来算得动能清洗、关联、聚合能按业务口径加工调得准任务按时间、按依赖可靠地跑失败能重试状态可追踪存得下有一个成本可控、查询够快的存储底座用得上业务能自助取数AI 能直接理解和操作。这五件事真的需要五套独立的技术栈吗DataY 的判断是不需要。我们给 DataY 的定位只有一句话DataY DataX Nifi DolphinScheduler注意这个「等于」不是把三个开源项目打包在一起而是用同一套运行时重新实现这三类能力像 DataX 一样把数据从源头搬到目标像 Nifi 一样用组件和连线编排数据流像 DolphinScheduler 一样做定时调度、依赖调度和实例管理。区别在于它们不再是三个进程、三套元数据、三种部署方式而是一个引擎、一个平台、一个 JAR。三、第一块积木自研流批一体数据集成框架DataY 的底座叫DataY Core它要解决的是「数据怎么进来、怎么加工、怎么出去」。1. 用 DAG 描述数据流而不是写一堆同步脚本一个 DataY 任务本质上是一张有向无环图{units:[{.id:in,.name:MySQLBinlogInput,table:orders},{.id:sql,.name:StreamSqlUnit,sql:select * from orders where status PAID},{.id:out,.name:DuckLakeWrite,table:dwd_orders}],connections:[{sourceId:in,targetId:sql},{sourceId:sql,targetId:out}]}units是组件负责「读、算、写、路由」connections是连线决定数据流向引擎负责拓扑排序、并发执行、队列传递、失败中断和状态恢复。同一份任务定义既可以在 Web 画布上拖出来也可以作为 JSON 交给 Core 独立执行或者嵌入到其他 Java 应用里。2. 流和批共用一套组件很多平台的「流批一体」是两套引擎套一个壳批走 Spark流走 Flink最后用调度器拼起来。DataY 的做法更直接流和批从第一天就共用同一套组件模型和运行时。批处理一次读取一段数据跑完即结束流处理CDC 组件持续产生变更事件下游组件持续消费中间的 SQL 加工、字段转换、Join、路由、写入全部复用同一批算子。这意味着今天用StreamJdbcInput做全量同步明天换成MySQLBinlogInput做实时同步下游加工逻辑不用重写同一个StreamSqlUnit既能处理一批历史数据也能处理持续的增量事件调试时可以用同一套画布、同一套日志、同一套状态管理。3. 不是「能跑」而是「跑得稳」一个数据集成框架真正的难点从来不是把数据读出来而是这些工程细节背压上下游速度不一致时用有界队列阻塞上游而不是把内存打爆并发每个组件可以单独配置并发数按算子瓶颈扩缩增量状态记录同步位点失败后从断点恢复而不是每次全量重跑自动建表源表结构变化时自动做 DDL 转换减少手工维护状态存储单机用本地文件集群用 MinIO 共享增量状态可观测每个组件的日志、处理条数、异常链都能定位到具体节点。这些能力不性感但决定了一个平台能不能上生产。4. 内嵌 DuckDB把「计算引擎」也省掉传统链路里数据同步完之后还要把数据交给 Spark/Flink 做加工。DataY 直接把DuckDB嵌进引擎列式存储、向量化执行、多线程用标准 SQL 做清洗、关联、聚合不需要额外部署计算集群单机就能跑出足以覆盖大多数业务场景的性能。于是一套 DataY Core 同时承担了「DataX 的同步」和「Nifi 的编排」还顺带把轻量计算做完了。四、第二块积木自研分布式调度单机和集群同一套代码数据进来了下一步是「按时、按依赖、可靠地跑」。DataY 的调度系统没有另起一套庞大集群而是把调度能力做进了平台本身1. master / worker 分离但不强制分离通过一个配置项development.mode同一个程序可以扮演不同角色模式调度执行依赖 Redis适用场景standalone有有否单机、开发、边缘节点master有无是只做调度多副本部署worker无有是只做执行水平扩展单机不需要 Redis也不需要额外组件需要扩容时改一个配置就能拆成集群。同一套代码不用维护两个版本。2. Cron、DAG、依赖、重试一个都不少Cron 定时调度精确到秒DAG 工作流编排父子任务自动拓扑排序依赖未满足时进入WAITING由补偿任务定时恢复支持手动触发、上线/下线、停止、失败重跑实例状态全程跟踪APPENDING / RUNNING / WAITING / SUCCESSFUL / FAILED / TIMEOUT / INTERRUPTED记录执行节点、开始/结束时间、执行消息。底层用 Quartz 做时间触发内核上面的分布式协调、角色编排、事件分发、依赖恢复全部自研。该复用的复用该自己掌控的自己掌控。3. 任务可以跑在容器里和调度进程隔离当 ETL 任务依赖复杂、内存占用大时可以切换成 Docker 执行模式任务在独立容器中执行跑完即销毁调度进程不被任务依赖和内存拖垮任务 jar、驱动目录、日志目录通过挂载共享仍然复用同一套任务定义和状态存储。对小团队来说这比维护一个 YARN 集群轻得多。五、第三块积木轻量数据湖把 Hadoop 那一套也省掉数据加工完总得有个地方存。传统方案是 HDFS Hive Metastore Hudi/Iceberg再配 Spark 读写。这套组合能力很强但组件多、运维重、小文件治理麻烦对中小数据量并不划算。DataY 的选择是1. DuckDB单机上的「列式数仓」进程内嵌无需独立服务列存 向量化 多线程直接读 Parquet/CSV也能挂载对象存储对 GB 到 TB 级分析场景性能足够部署成本几乎为零。2. DuckLake把数据湖做成「文件 目录」DataY 支持写入DuckLake数据以 Parquet 文件落在本地或对象存储如 MinIO元数据由 catalog 管理支持append / update / replace / overwrite等写入模式计算与存储解耦存储可以按需扩展不需要 HDFS、不需要 Hive Metastore、不需要另起 Spark 集群。对于「数据要留、查询要快、成本要低」的团队这是一条比 Hadoop 轻得多的路径。3. 需要更大规模时随时外挂DataY 不排斥更强的引擎需要高并发点查和实时分析可以把结果流式加载到 Doris / ClickHouse需要更大规模的数据湖可以继续用对象存储 DuckLake需要接回传统数仓也可以通过 JDBC 组件双向同步。轻量不是封闭而是默认简单需要时再长。六、三块积木拼起来2 核 4G 跑通全链路把集成、调度、存储拼在一起DataY 的整体形态是这样┌─────────────────────────────────────────┐ │ DataY Web │ │ 数据源 / ETL 画布 / 调度 / 建模 / 问数 │ └──────────────────┬──────────────────────┘ │ ┌──────────────────▼──────────────────────┐ │ DataY Core │ │ 流批一体组件 DAG · CDC · SQL · 自动建表 │ │ 增量状态 · 背压 · 并发 · 失败恢复 │ └──────────────────┬──────────────────────┘ │ ┌────────────────────────┼────────────────────────┐ │ │ │ ┌────────▼────────┐ ┌─────────▼─────────┐ ┌────────▼────────┐ │ 业务数据库 │ │ 内嵌 DuckDB │ │ DuckLake │ │ MySQL/PG/Oracle │ │ 轻量计算/数仓 │ │ Parquet 对象存储│ └─────────────────┘ └───────────────────┘ └─────────────────┘部署只需要三步gitclone https://github.com/yuyuejia/dataycddatay mvn clean package-DskipTestsjava-jardatay-web/target/*.jar--DATAY_AI_API_KEYsk-xxxxxxxxx浏览器打开http://localhost:8080默认账号admin/admin。一套最小可用的数据平台从「数据接入 → 数据加工 → 任务调度 → 数据建模 → 指标问数」的完整链路2 核 4G 就能跑起来。对比一下传统方案维度传统组合DataY组件数量同步、编排、调度、计算、存储、查询各一套一个 JAR内嵌引擎与存储最小资源十几台机器、上百 GB 内存起步2 核 4G部署方式每个组件单独安装、配置、联调一条命令启动元数据各组件各存一份平台统一管理扩容每个组件分别扩调度 master/worker 按角色扩存储按需扩运维门槛需要专职大数据工程师后端/数据开发即可维护技术栈做减法能力做加法这是 DataY 最核心的设计哲学。七、AI 原生不是加一个聊天框而是让 Agent 直接操作平台如果说前面的三块积木解决的是「平台能不能轻」那么 AI 原生解决的是「平台能不能被 AI 真正用起来」。DataY 没有在右上角挂一个只会聊天的机器人而是把 AI 放进三个位置1. 管道里的 AI大模型成为一个数据算子LlmComponent是 ETL 画布上的一个普通节点和 Join、Filter、SQL 同级按行调用 OpenAI 兼容接口模型返回 JSON就把字段合并进当前行返回普通文本就写入llm_result字段继续往下传支持重试、超时、并发控制。于是「用户评价 → 问题分类 → 结构化字段 → 数仓事实表」可以是一条完整的流批一体管道而不是「导出数据 → 调外部 AI 服务 → 再导回来」的断链流程。2. 语义层的 AI模型只翻译不发明口径智能问数答不准通常不是模型不够强而是数据侧缺少业务语义。DataY 用维度建模 指标管理把口径沉淀下来维度普通维度、层级维度、时间维度指标原子指标绑定事实表衍生指标用${指标编码}引用业务限定固化条件问数时模型只负责把自然语言翻译成「指标 维度 限定 时间范围」SQL 由平台生成。这样带来的直接结果是AI 问数、指标面板、报表用的是同一套口径。3. 平台里的 AI通过 MCP 让 Agent 直接操作平台DataY 提供 MCP 端点/mcp/datay把平台对象和指标能力暴露给 Claude Desktop、Cursor 等 AI 客户端工具覆盖数据源创建、更新、删除、测试连接、浏览 schema/表/字段、执行查询ETL 任务创建、更新、试跑、立即执行、上线/下线、查看实例数据模型创建维度/事实模型、保存字段、生成 DDL、物化落表指标指标清单、语义检索、维度取值、指标取数、指标增删改查。一句话描述的任务Agent 可以自己拆成调用序列「把 MySQL 订单库接进来建一个每天 2 点同步到 DuckLake 的 ETL 任务 先试跑看看数据没问题再上线。」 datasource_create → datasource_tables → datasource_columns etl_task_create → etl_task_debug → etl_task_run etl_task_instances → etl_task_online建模、落表、问数同样可以自动化data_model_create → data_model_materialize → query_metric_data4. 能力越大边界越要清楚让 Agent 操作平台最怕的是「权限靠提示词」。DataY 的做法是把边界做进系统传输层鉴权Bearer Token非法直接 401租户隔离X-Tenant-Id/X-Tenant-Code校验归属跨租户数据不可见数据权限复用页面同一套 RBAC 与行级范围写开关allow-mutating-toolsfalse一键降级为只读但问数不受影响不暴露任意 SQL指标问数只提供受控的查询工具模型不能临时发明口径出参裁剪数据源永不返回密码任务列表不返回完整设计图。一句话总结模型负责翻译与推理平台负责口径、权限、状态和幂等。这才是 AI 原生而不是 AI 外挂。八、DataY 的边界它不是万能药写到这里必须说清楚 DataY 不适合什么PB 级数据湖仓如果你已经有成熟的大数据团队和 PB 级数据继续用 Spark/Flink/Iceberg 体系更合适超大规模实时计算毫秒级、百万级并发的流计算仍然应该交给 Flink 这类专业引擎强多租户、强隔离的大型集团平台需要更重的资源调度与治理体系DataY 的轻量反而是约束。DataY 真正适合的是中小企业、业务部门、区域团队的第一套数据平台需要快速把数据接进来、跑起来、看起来的项目边缘节点、开发测试环境、SaaS 产品的内嵌数据能力想用 AI Agent 自动化数据工程流程但不想先养一个大数据团队的组织。我们不认为「轻」能取代「重」但认为大多数团队一开始并不需要那么重。九、写在最后把数据平台还给大多数人过去十年数据平台的能力一直在变强但使用门槛也在变高。我们见过太多团队业务还没跑起来先花了三个月搭平台数据还没到 TB先买了一堆服务器报表还没做几张先招了一个大数据团队。DataY 想反着来能用一个 JAR 解决的不拆成十个服务能用内嵌引擎解决的不另起一个集群能用一套调度解决的不引第三套协调系统能让 Agent 直接做的不让用户点二十个页面。DataY DataX Nifi DolphinScheduler但它不是三个工具的拼盘而是把这三类能力重新设计成一套运行时自研流批一体数据集成框架负责「进得来、算得动」自研分布式调度框架负责「调得准、跑得稳」轻量数据湖 DuckLake负责「存得下、查得快」AI 原生能力负责「用得上、可自动化」。产品首页http://datay.yuyuejia.com.cn/开源仓库https://github.com/yuyuejia/datay如果这篇文章对你有帮助欢迎点赞、在看、转发给正在被数据平台折腾的同事。也欢迎在评论区聊聊你们团队现在用了几套数据组件