新一代计算架构-Ray+Duckdb

场景

数据
利用duckdb，简单接入数据，快捷解析json，sql查询数据的特点，通过将 规则沉淀为SQL
方便随时查看，同时降低门槛。
面对的问题： 针对上百个 数据包 的数据，解析和查询比较快，但 数据包 达到上万的情况下，解析比较慢，用时超过4小时
希望达成效果：
1万个数据包，执行时间控制在1小时

了解当前-技术方案

01. 结合了 DuckDB、Ray 和 FastAPI 的开源无服务器（Serverless）分布式 SQL 查询引擎
https://github.com/kristianaryanto/Quack-Cluster
02.Quack 协议 关注的是单服务器的多人协同、并发读写和轻量远程连接，
Ray 关注的是跨多台机器的横向扩展和分布式并行计算
duckdb2.0 的异步读写能力

方案设计

方式比较
数据解析---> 小批量数据分别处理---> 处理结果合并
数据解析---> 所有数据合并位一个---> 数据处理结果
01.数据合并和结果合并的区别

02.增量的方式--记录状态-记录数据
数据解析可以加一道ETL
001. ETL链路，定期（如每天）将清洗、转换后的、归因分析所需的数据，以Parquet列式格式导出，并同步到S3对象存储中
将多个文件合并为一个文件
002.文件更新监控（检测变化）--Python：watchdog 库 或者查询数据库更新数据
s3 对象存储的更新--服务通知

变化--新增--修改--删除 --列式存储 + 向量化执行
baseline： 新增--追加parquet
删除--删除parquet
修改--修改parquet

架构分层

接入层: 数据任务-面向业务用户和数据科学家
GitLab Pipeline
首先执行代码质量检查与单元测试，验证逻辑正确性；
随后根据代码特性自动打包依赖环境，并将任务部署至 Ray 集群
核心层: Ray + duckdb
Ray集群实现了统一的计算抽象
duckdb： DuckDB通过本地存储来预加载数据集
存储层: 采用本地存储 S3存储

部署运行方式：

01 代码功能实现
02. 自动化代码审查
03. CI/CD 代表持续集成和持续交付 镜像
并行化优化

方案实现

LLM + agent 开发实现
提示词

方案

01.串行
单机串行-功能
02.原生并发 concurrent.futures.ThreadPoolExecutor
单机多进程 multiprocessing ProcessPoolExecutor 单机 CPU 密集数值计算、数据处理
单机多线程 threading ThreadPoolExecutor 纯 IO 密集、单机、短脚本
单机协程 asyncio 超高并发 IO
03.框架分布式
celery--异步框架
Dask --分布式计算
ray -- 为大规模任务而生
Ray 分布式框架内部使用 ‌MessagePack‌ 作为核心序列化协议，用于在节点间高效传输 Python 对象、任务参数和返回结果

计算引擎

01.MapReduce（2004）--> Hive（2008）
02.Spark（2009-2014）---> Flink（2014）
03.Paimon Fluss -StarRocks 湖仓一体
开放表格式 Iceberg、Hudi、Paimon、Delta Lake
04. BI->AI Ray — AI 原生分布式计算
AI 数据湖 同一张表同时管理结构化数据、半结构化 JSON、非结构化音视频、向量 Embedding
云原生与 Serverless 化

参考

9亿数据归因分析跑进15秒：携程智能归因系统如何用 Ray+DuckDB 破解算力危机