企业官网建设流程全解析

东莞网站建设 食品厂,wordpress 增加语言包,锦州做网站多少钱,马鞍山网站设计价格如果你熟悉 Spark#xff0c;大概率会有过这样的困惑#xff1a;Spark都统治大数据领域十年了#xff0c;算子成熟、生态完善#xff0c;为什么做特征工程时#xff0c;大家还要费劲巴拉去学Ray Data、Daft这些新框架#xff1f;更不用说#xff0c;这些新框架的API大概率会有过这样的困惑Spark都统治大数据领域十年了算子成熟、生态完善为什么做特征工程时大家还要费劲巴拉去学Ray Data、Daft这些新框架更不用说这些新框架的API用的还是map、filter、groupby、join这些熟悉的老伙计。其实答案很简单同样的算子在ETL和特征工程里使用频率和玩法完全不同。那么问题来了Spark与Ray/Daft的区别到底在哪里我们又要如何对其选型01AI 时代的 Data Infra从存储中心转向计算中心很多数据工程师都踩过这样的坑用Spark做多模态特征工程明明代码没报错却越跑越卡内存爆炸、GPU利用率上不去、模型重复加载。核心痛点就在于ETL和特征工程的数据流动逻辑完全相反而Spark的设计初衷从一开始就不是为特征工程量身定做的。ETL 典型流程:原始数据 ──► Filter ──► Join ──► GroupBy ──► Sort ──► 数仓表Local Shuffle Shuffle Shuffle特征工程典型流程:原始数据 ──► Download ──► Decode ──► Model Inference ──► 特征表Local Local Local (GPU)ETLSpark 的舒适区 是Shuffle密集型任务——数据在节点间大量移动靠内存缓存加速。但特征工程是Local 密集型任务通常数据不动但需要靠GPU加速模型推理。这个差异决定了框架设计的分野。从更宏观的视角看这是一次范式转移AI 时代的 Data Infra正在从以存储为中心转向以计算为中心。Hadoop时代一切围绕 HDFS核心是移动计算比移动数据便宜Spark 时代内存缓存加速但核心仍是数据的 Shuffle 与聚合Ray/Daft 时代一切围绕 GPU数据流过计算单元模型权重才是核心资产理解了这个转移你就懂了不是Spark不好是它的优势在特征工程场景里反而成了短板。02算子的底层逻辑设计数据怎么流动在讨论 ETL 和特征工程之前我们先建立一个分类框架分类方式按数据的物理访问模式。1. Local本地数据不跨分区、无网络I/O每行数据独立处理比如给每张图片生成Embedding各算各的互不干扰代表算子map、filter、project。2. Shuffle交换数据跨分区重新分布最耗时比如Join、GroupBy需要把相同key的数据搬到同一个节点代表算子join、groupBy、sort、distinct。3. Broadcast广播小数据复制到所有节点避免重复搬运代表算子broadcast join。4. Collect收集所有数据汇总到Driver容易OOM尽量少用代表算子collect、take、show。另外补充一个关键解读Local模式的开销是纳秒到微秒级纯内存计算而Shuffle模式是毫秒到秒级要走网络、读磁盘。这就意味着如果你的任务以Local操作为主比如特征工程却用了一个优化Shuffle的框架比如Spark自然会出现各种效率问题。除此之外Local模式内部还能按行变换方式细分1:1、1:N、N:1但核心不变数据原地不动计算独立完成这正是特征工程的核心需求。理解了这些基础分类我们就可以来分析 ETL 和特征工程的算子使用模式了。03深度拆解ETL为什么会成为Spark主场下面我们分两部分结合具体场景和痛点拆解两者的差异——搞懂这部分你就知道该怎么选框架了。3.1 ETL为什么是Shuffle密集型操作分布式系统中数据按某种规则分散在多个节点上。当你需要把相同 key 的数据聚到一起时比如 Join、GroupBy就必须跨节点搬运数据——这个过程叫Shuffle。Shuffle 前: Shuffle 后:节点A: [1,a] [2,b] [1,c] 节点X: [1,a] [1,c] [1,e] ← key1 的都在这节点B: [2,d] [1,e] [3,f] ────► 节点Y: [2,b] [2,d] [2,h] ← key2 的都在这节点C: [3,g] [2,h] [3,i] 节点Z: [3,f] [3,g] [3,i] ← key3 的都在这Shuffle 是分布式计算中最昂贵的操作网络传输数据跨节点移动受带宽限制磁盘 I/O中间结果可能落盘序列化开销数据需要编码/解码ETL 之所以是 Shuffle 密集型正是因为ETL的本质是整理数据——把散乱的原始数据清洗、关联、聚合后变成结构化的数仓表供分析、报表使用过程中大量需要 Shuffle。典型ETL任务都需要大量Shuffle如下1. 多表关联Join订单表关联客户表相同customer_id的数据可能在不同节点必须Shuffle后才能关联2. 聚合统计GroupBy按日期、类目统计销售额同一天的订单分布在所有节点必须Shuffle后才能汇总3. 全局排序Sort按金额降序排列需要先确定分区边界再Shuffle重新分布数据最后分区内排序。4.清洗过滤脏数据、格式标准化、空值处理3.2 ETL 的算子使用分布根据对典型 ETL 任务的分析其算子使用分布如下Shuffle操作占60%Join、GroupBy、Sort等Local操作占30%Filter、Map等其他操作占10%。这就是为什么Spark花了大量精力优化Shuffle——比如Exchange 算子的各种优化、Sort-Merge Join vs Hash Join vs Broadcast Join 的选择、Shuffle 文件的管理和清理、Adaptive Query Execution 动态调整分区……本质都是为了适配ETL的核心需求。04特征工程为什么是Local 密集型操作4.1 如何理解特征工程特征工程的本质是提取信号——把原始数据图像、文本、音视频转换成模型能理解的数值信号Embedding向量、结构化特征或者提取结构化数据日志、表格的结构化特征数值、类别供模型训练使用。因此特征工程的算子使用分布中Local操作占80%Download、Decode、模型推理Shuffle操作仅占20%主要是特征聚合和ETL形成鲜明对比。以下是几个特征工程的典型场景1. 图像Embedding生成下载图片→解码→模型推理每张图片独立处理不需要跨节点交互Daft 代码df (daft.from_glob_path(s3://images/*.jpg).with_column(bytes, col(path).url.download())Local.with_column(image, col(bytes).image.decode())Local.with_column(embedding, embed_image(col(image)))Local GPU)2. 文本Embedding生成读取文本→批量传入模型→生成向量每条文本独立推理不需要与其他文本交互。Ray Data 代码ds ray.data.read_parquet(s3://data/texts/)ds ds.map_batches(SentenceTransformer,computeActorPoolStrategy(size4),num_gpus1,batch_size128,)3. LLM批量推理每条prompt独立生成回复靠GPU批量处理提升效率。Ray Data LLM 推理config vLLMEngineProcessorConfig(model_sourcemeta-llama/Llama-3.1-8B,batch_size64,concurrency2,)processor build_processor(config, preprocess..., postprocess...)ds processor(ds)4.2 Spark为什么不适配特征工程Spark的内存缓存设计是为结构化数据量身定做的。比如一行ETL数据user_id、name、age、amount只有50-100字节百万行也才几十MB内存缓存能大幅加速Shuffle后的迭代计算。但特征工程的数据长这样user_id | image_embedding (512维) | text_embedding (768维) | raw_image1001 | [0.12, 0.34, ...] | [0.56, 0.78, ...] | 2MB 图片特征工程的数据体积极大如果一行数据包含2MB以上的图片、512维的Embedding百万行就是2TB。而Shuffle会携带整行数据哪怕只需要user_id做keyEmbedding和图片也会被一起搬运直接占满内存。这就导致用spark处理特征工程会出现内存爆炸Spark 的内存本该用于加速计算现在被不参与计算的大体积数据占满网络拥塞Shuffle 带宽被图片、向量等数据吞噬GC压力JVM 频繁 GC性能急剧下降GPU利用率极低Spark的GPU支持是插件扩展的无法细粒度调度而且逐条推理无法发挥GPU的批量优势利用率往往低于10%模型重复加载每个Task都会重复加载模型比如LLM动辄几个GB浪费资源且耗时。这就是为什么用 Spark 做多模态特征工程会异常痛苦——它的内存模型根本不是为这种数据设计的。4.3 Ray/Daft的优势是什么针对Spark在特征工程中暴露出的各种问题Ray/Daft做出了众多优化使其在处理多模态数据时比 Spark 快 4-18 倍。首先针对Spark模型重复加载、内存浪费的问题Ray/Daft采用Actor Pool机制让模型只加载一次多个Task复用同一个Actor彻底避免重复加载带来的资源消耗大幅节省内存针对Spark GPU调度粗放、利用率低下的问题Ray/Daft支持0.5个GPU的细粒度分配即两个Actor共享一个GPU同时可显式控制batch_size让GPU利用率提升至80%以上针对Spark无法感知多模态数据语义的问题Ray/Daft内置原生多模态类型能够识别数据语义比如224x224的RGB图像进而针对性优化内存布局避免无效数据搬运。除此之外Daft相较于Spark的性能优势还有三个核心技术支撑1. 无JVM-Python序列化开销Daft采用RustArrow架构实现数据零拷贝而Spark每次调用UDF时都需要进行JVM与Python之间的序列化操作耗时严重2. 执行机制差异Daft采用流式执行模式数据可直接流过pipeline无需等待整个stage完成而Spark采用批量执行模式必须完成一个stage的所有任务才能进入下一个stage3. GPU资源管理更高效Daft通过一个进程统一管理所有GPU资源避免资源竞争而Spark多个Executor会同时竞争GPU导致资源内耗进一步降低处理效率。05ETL与特征工程的核心区别理解了业务场景的差异我们就能理解不同框架设计背后的思路。ETL与特征工程核心区别可以概括为四点1. 数据类型Spark用通用类型把图像当字节数组无语义无法针对性优化Ray/Daft有AI专用类型Image、Tensor、Embedding保留维度信息可优化内存2. 计算模型Spark是无状态Task每个Task都要重新加载模型重复消耗资源Ray/Daft是有状态Actor Pool模型只加载一次可复用3. 资源分配Spark是Executor级别GPU分配给整个Executor无法细粒度控制Ray/Daft是Task/Actor级别可分配0.5个GPU资源利用率更高4. 优化重点Spark优化Shuffle解决网络I/O、数据倾斜Ray/Daft优化LocalGPU解决模型加载、批量推理效率。06交集地带特征聚合特征工程并非完全不需要 Shuffle。最典型的就是“特征聚合”和“Point-in-Time Join”。1. 特征聚合计算用户过去7天的点击量、平均浏览时长同一个用户的行为分布在不同分区必须Shuffle后才能聚合2. Point-in-Time Join为每条样本关联“当时”的用户特征避免数据泄露需要按时间和用户ID Shuffle关联。这就是为什么现实中往往需要Spark Ray/Daft 组合使用Spark 处理 Shuffle 密集的聚合和 JoinRay/Daft 处理 Local GPU 密集的推理数据交换用Parquet格式实现两个框架的数据无缝衔接。07选型建议选型的思路其实就一句话不要试图教会大象跳舞也不要让猎豹去拉磨快速指南如下另外补充一个典型混合架构实操可用原始数据↓Spark ETL↓清洗后数据 (Parquet)↓├──────────────────┐↓ ↓Ray/Daft Embedding Spark 特征聚合(GPU 推理) (Shuffle 密集)↓ ↓└────────┬─────────┘↓特征表 (Parquet)↓模型训练作者介绍 陈彪 Zilliz Senior Staff Software Engineer 阅读推荐 教程如何用飞书Moltbot打造你的MilvusAI小助手 RAG优化不抓瞎Milvus检索可视化帮你快速定位嵌入、切块、索引哪有问题 Milvus印度最大电商平台如何打造服务两亿月活用户的商品比价系统 都有混合检索与智能路由了谁还在给RAG赛博哭坟