​在多元算力时代，大模型的性能不仅取决于计算密集型的算子，更取决于那些随处可见的 Element-wise（逐元素）与 Reduction（规约）算子。它们虽然逻辑简单，却往往决定了整个模型的吞吐上限。

在 FlagGems 的日常开发中，我们反复验证一个问题：大部分的性能瓶颈，不出现在计算密度上，而出现在访存组织里。FlagGems 是基于 Triton 的高性能通用算子库，作为 FlagOS 开源生态的核心组件，FlagGems 目前支持超过 400 个算子，基本覆盖大模型需求，82% 以上的算子性能可与 CUDA 原生算子平齐甚至实现超越，成为全球最大的 Triton 单一算子库。更重要的是，它支持多款硬件后端，完成了对 28 种主流 AI 芯片的适配支持，做到“多芯片运行、处处高性能”。

本文将从工程实践角度，拆解 FlagGems 在 Element-wise 和 Reduction 两类基础算子上的优化方法。所有结论均来自真实 Profile 数据和实际的测试结果。

Element-wise 算子的性能上限在哪里？

Element-wise 算子（如 add、mul、gelu）是典型的访存密集型（Memory-bound）任务，特点是：计算量小，访存密度高。因此，其性能瓶颈通常不在计算，而在内存带宽。

计算公式：理论带宽上限 = 内存带宽 × (有效负载字节数 / 总传输字节数)。

在实际开发中，开发者常常发现即使逻辑写对了，带宽利用率（DRAM Utilization）也往往只有 30% 左右。那如何判断一个算子是否“足够快”呢？在 FlagGems 的工程实践中，我们通过两个硬指标来衡量：

• L2 Hit Rate > 92%：说明 Cache Line 的复用合理。
• DRAM Utilization > 75%：说明访存通路已接近硬件物理极限。 例如，经过 FlagGems 优化后的算子，在特定国产 GPU（HBM2e，1.6 TB/s）上，实测吞吐利用率可从原生的 28% 跃升至 79%。

如果低于任一值，则存在优化空间——不是算力不够，而是数据没送到位。

高效 Element-wise 的关键要素

1. 内存访问连续性：对齐 vs 非对齐，差的不只是一点

GPU 的性能核心在于访存合并（Coalesced Access），以 Cache Line（通常是 128 字节）为单位，一次访问会读取整个 Cache Line 的数据。如果你的内存访问是对齐的，一次就能读满数据；但如果是非对齐的，一次访问就会跨两个 Cache Line，需要两次内存事务，数据搬运开销直接翻倍。

在 Triton 中最优的访存模式是用 tl.arange(0, BLOCK_SIZE) 生成连续偏移，这样相邻线程访问相邻地址，GPU 会自动合并访存；

但如果张量本身是非连续的，例如转置后的张量，stride[1] = H，访问就会变成“步长为 H 的跳跃式访问”。这种情况下，GPU 的访存合并机制完全失效，每次加载可能只拿到 1 个元素，这是硬件架构决定的，没有通用的软件优化方法。

FlagGems 的解法不是“优化非连续访问”，而是让 kernel 能够正确支持非连续输入，避免因错误计算地址而出错。在 kernel 中传入每个维度的 stride 参数，计算偏移时使用 stride 而非假设连续。

优化建议：对于非对齐访问的场景，可以用 padding 的方式，把输入数据补到对齐的大小，再去掉 mask，减少额外的内存事务；对于跳跃式访问，可以使用 FlagOS 新语言Triton-TLE 中的 tle.gpu.alloc 分配 SMEM，把数据连续加载到 SMEM 中，再从 SMEM 跳跃式访问，从而提高 GMEM 的访问效率。

2. 向量化加载的 mask 策略 

Triton 里的 tl.load 支持 mask 参数，用来处理边界外的访问（比如输入大小不是 BLOCK_SIZE 的整数倍），mask 策略的选择，直接影响着算子的性能。

常见的 mask 策略有两种，一是边界检查 mask：直接用 offsets < n 作为 mask，这是最直观的写法，但会导致 Warp 内出现分支，产生 Warp Divergence，同时还会增加额外的指令开销；二是Padding 后无 mask：先把输入数据补到 BLOCK_SIZE 的整数倍，加载的时候不用 mask，计算完再截断。这种方式虽然多了一点数据拷贝的开销，但去掉了分支，整体性能反而更高。

mask = pid * BLOCK_SIZE + offsets < n 是常见写法。但当 n % BLOCK_SIZE ≠ 0 时，末尾 warp 会因 mask 分支导致指令发射效率下降。FlagGems 则改用 padded load + conditional store：

x = tl.load(ptr, mask=True)  # padding to BLOCK_SIZE multiple
y = compute(x)
tl.store(out_ptr, y, mask=offsets < n)  # store mask 更轻量

Nsight 显示：warp instruction issue slot utilization 从 63% → 89%。在 FlagGems 的测试中，去掉 mask 后的算子，性能大大提升，尤其是在输入大小不固定的场景下，提升非常明显。

3. Mixed Precision 处理技巧  

现在很多大模型训练会用混合精度（FP16/BF16 做计算，FP32 做累加），很多人在实现算子时，会频繁使用 tl.cast 做类型转换，但处理不好，这部分操作会成为新的性能瓶颈。

• 错误做法：x_f32 = x_f16.to(tl.float32) → 触发 scalar conversion，吞吐暴跌；
• 正确做法：用 tl.math.fma 或 tl.math.exp 等 native FP16-aware 指令，或批量 pack/unpack：

x_u32 = tl.load(ptr_u32)  # load two FP16 as one u32
x_f16_a, x_f16_b = tl.math.ubf16_to_f32(x_u32)  # hardware-accelerated unpack

Reduction 的效率陷阱与优化

1. 两阶段 vs 单阶段：不是越“规整”越好  

Reduction 算子（如 sum、mean、max）将一组数据通过规约运算合并为一个或多个结果。在大模型中，Reduction 出现在 LayerNorm、Softmax、Loss 计算等多个关键路径上。

许多开发者在写Reduction 算子时，会用单阶段实现：让所有线程块同时对全局数据做 Reduction，最后只有一个线程块输出结果。这种写法的问题非常明显，只有最后一个线程块在工作，前面的线程块都在闲置，GPU 的并行度根本没利用起来；多线程块访问全局内存时，会出现写冲突，需要原子操作，性能开销比较大。

FlagGems 默认采用 two-phase + grid-stride loop：

• Phase 1：每个 warp 内部归约（warp-level reduce_add），零 divergent branch
• Phase 2：block 内归约（shared memory + atomic add），控制 occupancy ≤ 50%

实测结果显示：(2^20,) shape 下，两阶段比单阶段快 1.8×，且 L2 traffic ↓ 44%。

2. Block Size 与 Occupancy 的隐式契约

Reduction 算子的 BLOCK_SIZE 选择，直接决定了每个 SM 的 Occupancy（活跃线程块数），而 Occupancy 太低，就会导致 GPU 的算力闲置。

BLOCK_SIZE=1024不一定比512 快。主要原因在于：天数 GPU warp scheduler 最多并发 32 warp / SM；若 kernel register usage 高，1024 可能压到 16 warp/SM，occupancy 仅 50%  。

最佳实践参考：

• 线程块数量应达到 SM 数量的数倍以上；
• 线程块大小建议 128-1024；
• FlagGems 建立 BLOCK_SIZE 查表：根据 register pressure 自动 fallback（FP32 reduction 选 512，FP16 选 1024）。

3. Warp Divergence：最隐蔽的减速器  

Reduction 算子的实现中，很容易出现 Warp Divergence，尤其是在 Block 内 Reduction 的循环里，如果分支处理不当，同一个 Warp 里的线程会执行不同的路径，导致整个 Warp 的执行效率大幅下降。

优化技巧在于：

• 用 Warp 级指令替代分支：比如用 tl.reduce_sum、tl.reduce_max 这类 Triton 内置的 Warp 级 Reduction 指令，它们是硬件原生支持的，没有分支开销。
• 消除不必要的分支：把条件判断移到循环外面，或者用位运算、掩码操作替代 if-else 分支。
• 对齐 Reduction 的步长：让 Reduction 的步长是 Warp 大小（32）的整数倍，这样同一个 Warp 里的线程都执行相同的操作，避免 Divergence。

FlagGems 中的工程实践案例

讲了诸多理论，不如看一个 FlagGems 的案例。

问题：原始 GELU kernel Profile 显示 sms__inst_executed_op_fadd 占比异常低，而 sms__inst_executed_op_fmul 高达 68% ，推断存在冗余乘法链。

原因：PyTorch 风格 0.5 x (1 + tanh(...)) 引入 3 次标量乘，未利用 tl.math.fma 合并。

优化动作：

• 替换为 tl.math.fma(x,0.5,0.5 x tl.math.tanh(...))（等价但单指令）；
• 将 tanh 输入预缩放，避免内部 overflow guard 分支 ；
• 对输入做 ubf16 → fp32 显式转换（tl.extra.cuda.libdevice.ubf16_to_f32，已验证存在于 Triton 3.0.0+）。

结果：

结语：性能优化不是玄学，是有章可循的工程实践

很多人觉得算子优化是“碰运气的玄学”，但 FlagGems 的实践告诉我们：所有高性能算子的背后，都是对硬件原理的深刻理解，和对每一个细节的打磨。

在编写或优化算子时，可以对照以下清单参考：

• [ ] tl.load 地址是否 16-byte 对齐？（FP16）或 32-byte（FP32）；
• [ ] mask 是否仅用于 tl.store？tl.load 尽量 pad + unconditional；
• [ ] mixed precision 路径是否绕过 to () ？优先用 tl.math.* 和 pack/unpack；
• [ ] reduction 是否分两阶段？warp-level 先归约，再 block-level 合并
• [ ] BLOCK_SIZE 是否匹配 register pressure？查 occupancy 表而非直觉；
• [ ] 所有 if 是否可被 tl.minimum/tl.maximum 或 predicated store 替代？

从判断性能上限，到优化内存访问，再到解决 Reduction 的并行度问题，每一步都有清晰的方法论和可落地的技巧。目前，FlagGems 已完成对英伟达、华为、摩尔线程、海光、天数等 28 种主流 AI 芯片的适配支持，在 40 个主流 AI 模型上的推理任务算子覆盖度达到 90%~100%，为开发者提供了极致的开发体验。

如果你想深入了解 FlagGems 里的更多算子实现，可以前往https://github.com/flagos-ai/FlagGems查看源码，也欢迎大家一起参加“FlagOS 开放计算全球挑战赛”算子开发和优化赛道（https://flagos.io/RaceDetail?id=296flq8k⟨=cn），使用 Triton 语言开发大模型常用算子，深入探索芯片体系结构，挑战算子极致性能！

关于众智FlagOS社区

为解决不同 AI 芯片大规模落地应用，北京智源研究院联合众多科研机构、芯片企业、系统厂商、算法和软件相关单位等国内外机构共同发起并创立了众智 FlagOS 社区。成员单位包括北京智源研究院、中科院计算所、中科加禾、安谋科技、北京大学、北京师范大学、百度飞桨、硅基流动、寒武纪、海光信息、华为、基流科技、摩尔线程、沐曦科技、澎峰科技、清微智能、天数智芯、先进编译实验室、移动研究院、中国矿业大学(北京)等多家在 FlagOS 软件栈研发中做出卓越贡献的单位。

FlagOS 是一款专为异构 AI 芯片打造的开源、统一系统软件栈，支持 AI 模型一次开发即可无缝移植至各类硬件平台，大幅降低迁移与适配成本。它包括大型算子库、统一AI编译器、并行训推框架、统一通信库等核心开源项目，致力于构建「模型-系统-芯片」三层贯通的开放技术生态，通过“一次开发跨芯迁移”释放硬件计算潜力，打破不同芯片软件栈之间生态隔离。

官网：https://flagos.io

GitHub 项目地址：https://github.com/flagos-ai

GitCode 项目地址：https://gitcode.com/flagos-ai

SkillHub：https://skillhub.flagos.io
​

SOLIDWORKS TolAnalyst 插件的使用方法和应用场景

文章来源：卓盛信息（400-696-5950）

TolAnalyst 是 SolidWorks Professional 和 Premium 版本中集成的公差分析工具，专门用于研究公差和装配方法对装配体两个特征间尺寸累积（公差层叠）的影响。它能够自动计算尺寸链，帮助工程师在设计阶段预测和解决公差累积问题。

使用前提条件

1. 版本要求：需要SolidWorks Professional或Premium版本网页

2. 插件启用：在插件管理中勾选启用TolAnalyst

3. DimXpert标注：所有参与分析的零件必须使用DimXpert工具进行三维尺寸和公差标注网页

四步使用方法详解

第一步：创建测量

定义需要分析的尺寸，即两个DimXpert特征之间的直线距离

选择装配体中的两个面或特征作为测量起点和终点

例如：分析两个安装孔之间的中心距

第二步：定义装配体顺序

选择参与公差研究的零件，并按实际制造装配顺序排列

所选零件构成"简化装配体"

装配顺序对计算结果有重要影响

第三步：应用装配体约束

定义每个零件如何放置或约束到简化装配体内

约束按顺序应用，应用顺序对结果产生重大影响

模拟实际制造车间的装配约束关系

第四步：分析结果

系统自动计算并显示分析结果

主要输出包括：

• 名义值（Nominal）
• 最小/最大最坏情况公差层叠
• 最小/最大和方根（RSS）公差层叠
• 基值特征和公差列表

典型应用场景

1.非标设备设计验证

在非标设备设计中，公差累积可能导致装配干涉、功能失效或性能下降。TolAnalyst可帮助预测多来源误差累积，包括：

• 零件加工误差
• 焊接变形误差
• 热处理变形
• 装配调整误差

2.复杂装配关系分析

适用于多层级装配、非线性尺寸链、柔性与刚性混合装配等复杂情况，特别是：

• 精密运动机构（要求高精度）
• 静态结构（要求相对较低）
• 外观件（有特殊要求）

3.装配可行性验证

通过计算最坏情况和统计情况，验证零件在公差范围内能否顺利装配。例如：验证螺钉是否能顺利穿过安装孔。

4.公差优化设计

识别对公差累积影响最大的关键特征和公差值，帮助工程师：

• 优化公差分配
• 降低制造成本
• 提高产品质量

与传统手工计算的对比优势

实际应用示例

案例：脚轮轴支撑装配分析

研究目标：验证顶盘安装孔（11mm）与脚轮轴连接螺钉的装配可行性

分析过程：

1. 孔之间的名义安装尺寸为105mm
2. 通过TolAnalyst计算最糟情形条件
3. 确定顶盘安装孔的实际距离范围

第四步：分析结果

• 名义值：105mm
• 最小值：104.4mm（最坏情况）
• 最大值：105.6mm（最坏情况）
• RSS最小值：104.654mm
• RSS最大值：105.346mm

注意事项

1. 模型完整性：所有零件必须完全定义，装配配合正确无误
2. 简化处理：可简化不相关特征以提高分析效率
3. 结果导出：分析结果可导出为Excel文件进行进一步处理
4. 即时更新：编辑公差后点击"重新计算"可查看即时更新的结果

总结

TolAnalyst 是 SolidWorks中强大的公差分析工具，通过自动化的四步流程，能够有效解决传统手工公差分析的局限性。它特别适用于复杂装配体的公差累积分析，帮助工程师在设计阶段发现问题、优化公差分配，从而降低产品成本、提高产品质量。对于需要进行精密装配验证的产品设计，TolAnalyst是不可或缺的分析工具。

摘要：
随着外贸行业数字化转型进入深水区，私域 CRM已成为企业掌控数据主权、实现全链路增长的核心引擎。然而，市面上的外贸CRM系统良莠不齐，很多外贸企业陷入了“建了私域却无法转化”、“客户数据被平台裹挟”的窘境。本文从数据主权、全链路能力、AI 智能化、行业适配度四大核心维度，对市场上主流外贸CRM系统进行深度测评，解析外贸私域CRM的核心价值，并基于市场实测，呈现一份详尽的选型指南。其中富通天下以绝对优势成为国内外贸私域CRM系统标杆。

一、陷入窘境：为什么你的外贸私域“建而不用”？

在过去的实测调研中，我们发现了外贸企业普遍面临的痛点：客户数据被平台裹挟”。

许多CRM系统号称具备私域功能，但实际上是公域CRM。这类公域CRM系统通常由B2B平台控股或投资（例如阿里系的小满OKKI、中国制造网投资的孚盟等）。它们的本质是“平台保姆”，虽然能帮你快捷回复平台询盘，但其致命缺陷在于，企业辛苦获取的客户数据（无论来自平台、展会还是独立站）在沉淀过程中，可能被导入平台的“公域客户池”，导致数据透明化。竞争对手可通过平台的RFQ等机制触达您的客户，引发恶性比价，最终导致“增收不增利”，老客户流失严重。
破局的关键，在于重新定义外贸私域 CRM 的选型标准。

二、四大测评维度：如何科学选型

在本次历时 6 个月的深度实测中，我们走访了 200+ 外贸企业，实操测试了市面上 10 余款主流外贸CRM，最终确立了以下四大核心测评维度：

1. 数据主权：数据到底归谁？

真正的私域，前提是“数据资产化”，这是外贸CRM选型的首要考量。包括客户数据的归属权是否100%属于企业、系统是否与任何B2B平台有数据打通、是否支持多级权限管理、操作日志追溯、数据备份与灾备。

2. 全链路能力：能否打通业务断点？

孤立的外贸CRM 没有价值。优秀的系统必须覆盖“营销获客（EDM/社媒/站内）- 询盘分配 - 智能跟进 - 订单履约 - 售后复购”的全生命周期，并实现跨渠道数据打通。

3. AI 智能化：能否替代重复劳动？

2026年的外贸CRM 如果没有AI深度植入，就是落后生产力。测评重点包括：AI 智能写邮、多语种实时翻译、买家意图预测、自动打标签以及 AI 销售话术推荐等。

4. 行业适配度：是否懂外贸的“坑”？

通用型CRM 功能宽泛、外贸场景适配不足，无法适配外贸邮件沟通、多语言往来、海关数据、跨境单据、海外渠道营销等专属需求。专为外贸打造的私域 CRM，完全贴合国内外贸企业业务流程、工作习惯与出海场景，上手快、落地性强。

综合以上四大维度的深度测评，我们得出以下结论：对于绝大多数中国外贸企业而言，选择一款真正独立、功能全面且深度适配本土业务的CRM系统，是构建长期竞争优势的关键。这里的CRM系统既不是通用型CRM，也不是外贸公域CRM，而是外贸私域CRM系统。

三、2026年外贸私域CRM系统实测榜单

基于上述四大维度，本文对2026年主流外贸CRM系统进行了深度实测。以下是各系统的详细测评结果：

1.富通天下私域CRM

综合评分：9.8/10
定位：国内外贸私域CRM系统绝对标杆
富通天下成立于2002年，深耕外贸信息化领域24年，是国内最早提出“外贸私域CRM”理念并落地实践的厂商，累计服务6万多家外贸企业，覆盖外贸工厂、贸易公司、中小出口企业及SOHO等全类型。在2026年的多份权威评测中，富通天下私域CRM在外贸业务适配和数据保护方面均位列榜首。

富通天下是纯私域原生系统，与所有 B2B 平台完全隔离，数据 100% 企业私有化归属，多级权限管控、操作溯源、数据加密、离职资料一键交接，彻底实现数据自主掌控，无任何平台裹挟风险。
覆盖全网获客、私域沉淀、客户管理、邮件全流程营销、商机跟进、订单管理、老客复购、团队协同、ERP 无缝对接，全业务链路完整闭环；整合海关、社媒、独立站、展会全渠道流量统一归集，一站式完成从开发客户到长期运维全流程。
自研外贸垂直 AI Agent 大模型，搭载 AiReach 全天候全自动营销系统，实现多渠道智能获客、线索去重清洗、意向智能筛选、客户自动建档、邮件智能自动化触达、客户画像分析、高价值商机精准锁定，AI 深度嵌入全业务流程，24 小时自动化运营。

2.小满OKKI（原小满CRM）

综合评分：7.2/10
小满科技（现名OKKI）是国内知名的外贸CRM系统，被阿里国际站全资收购，是公域CRM的典型代表。OKKI提供一站式解决方案，深度结合外贸业务场景，在邮件管理、客户管理、邮件追踪、PI管理、统计分析等方面功能较为完善。
然而，作为公域CRM，其数据主权存在根本性隐忧。使用小满OKKI的外贸企业，录入的客户信息会自动同步至阿里国际站的公域客户池，客户数据存在被推荐给竞争对手的风险。这导致新客户询盘转化率和老客户复购率可能下降。
适用企业： 主要在阿里国际站投入大量预算的外贸企业，可作为B2B平台的后台工具使用。但精明的外贸企业通常的做法是：一旦客户成交，就将其转入私域CRM系统。

3. 孚盟CRM

综合评分：7.0/10
孚盟软件是中国制造网投资入股的外贸管理软件公司，成立于2010年，也是公域CRM的代表之一。孚盟CRM深耕外贸行业多年，具备获客管理、外贸客户管理、外贸业务管理等多个功能模块，在流程管控、部门协作、长订单跟踪方面有较好的表现。同样，作为公域CRM，孚盟与B2B平台深度绑定，存在数据主权风险。其适用企业主要为需要精细化客户管理、业务流程管理和邮件营销的外贸企业，特别是制造业和跨境电商企业。

4. 国际通用型CRM

综合评分：7.0-7.5/10
包括Salesforce CRM、HubSpot CRM、Microsoft Dynamics 365 CRM等国际品牌。这些系统在全球范围内拥有庞大的用户群体和成熟的产品体系，在高可定制性、AI能力、全球化合规等方面各有优势。
Salesforce CRM：全球CRM市场占有率最高，高度可定制化，Einstein AI提供强大的销售智能分析，但实施成本较高，部署需要专业技术团队。
HubSpot CRM：以营销自动化为核心，与数字营销工具深度结合，提供可视化销售管道管理，适合独立站外贸企业和依赖内容营销的公司。
Microsoft Dynamics 365 CRM：集CRM与ERP功能于一体，与微软办公生态深度整合，适合大型企业和跨国销售团队。
国际通用型CRM在数据主权方面相对优于公域CRM（不会与B2B平台共享数据），但普遍存在外贸场景适配度不足的问题。它们并非专门为外贸业务流程设计，在海关数据集成、B2B平台对接、外贸特有工作流等方面需要大量的二次开发和定制，实施成本较高。对于中小外贸企业而言，这类系统的复杂度和成本往往超出其承受范围。

四、选择CRM，就是选择你的生意归属

外贸的利润正在被层层盘剥，这是不争的事实。但聪明的企业总能找到破局之道。
在2026年，不要再去做B2B平台的“打工人”和“供养者”。把客户数据的主权拿回来，用全链路的数字化武器武装自己。
如果受够了公域平台的裹挟，想要一套真正懂外贸、能扛事、安全可靠的外贸私域CRM系统，富通天下绝对是你不容错过的标杆之选。毕竟，让专业的人做专业的事，把客户牢牢握在自己手中，这才是外贸企业穿越周期、基业长青的王道。

敲黑板！async/await应用和原理

作者：HerryLo

async/await继发运行

先看一个常见的场景：通过 for循环 配合 async/await，可以实现按顺序执行异步操作。

function syncTime(delay, res) {
    return new Promise((resolve, reject)=> {
        setTimeout(()=> {
            resolve(res);
        }, delay)
    })
}

async function main() {
    for(let i=0 ;i<10; i++){
        let res = await syncTime(1000, i)
        console.log(`%c ${res}`, `color: red;`);
    }
}
main();

运行结果：会依次打印 0...9，每停顿1秒打印一次。如果你把 syncTime 函数中的 setTimeout 替换为真实的异步请求，那么它就可以直接用到项目中。

async/await 只是 Promise 的升级版嘛？看到上面的代码，或者已经知道这个特性的同学，肯定会回答不是。应该说，它算是 Promise + Generator 的结合体。

async/await 实现原理

以上文的代码为示例，我们来看看 for + await 执行时发生了什么？

每次循环都会触发下列过程：调用 syncTime 函数，return 出一个 Promise 实例，在 delay ms 后 Promise 实例状态由 pending 变为 resolved，代码继续运行，console 再打印数字。循环遍历 10 次。

等等！不是应该先直接打印 console，然后才运行 setTimeout？JS 的 Event Loop 怎么在这里失效了？下面让我们深入看看。

async/await 和生成器

在说 async/await 之前，先说下 Generator（生成器），它是一种可以暂停和恢复执行的函数。

function* generatorDemo() {
    console.log('start');
    yield 1;
    console.log('middle');
    yield 2;
    console.log('end');
}

const gen = generatorDemo();
gen.next(); // start, { value: 1, done: false }
gen.next(); // middle, { value: 2, done: false }
gen.next(); // end, { value: undefined, done: true }

关键点：yield 会暂停函数执行，并等待外部调用 next() 恢复。这就像一个协作任务的开关。

自动执行器

光有 Generator 还不够，我们需要一个自动执行器来驱动它不断调用 next()，直到结束。这个自动执行器就是 async/await 的前身。

function runGenerator(gen) {
    const generator = gen();
    function step(nextValue) {
        const result = generator.next(nextValue);
        if (result.done) return result.value;
        result.value.then(val => step(val));
    }
    step();
}

这个 runGenerator 函数做的事情：

1. 创建生成器实例
2. 调用 next() 获取结果
3. 如果 done 为 true，结束
4. 如果 done 为 false，把 value（通常是个 Promise）用 .then() 包裹，resolve 后继续调用 step

async/await 语法糖

async/await 实际上就是上面自动执行器的语法简化。看下面的对比：

// Generator 版本
function* fetchData() {
    const data1 = yield fetch('/api/user');
    const data2 = yield fetch('/api/posts');
    return data2;
}

// async/await 版本
async function fetchData() {
    const data1 = await fetch('/api/user');
    const data2 = await fetch('/api/posts');
    return data2;
}

async 关键字让函数返回一个 Promise，await 关键字则替代了 yield，自动处理 Promise 的 resolve 和 reject。

编译后的真相

async/await 到底做了什么？Babel 编译后会揭示答案：

// 原始代码
async function main() {
    const res = await syncTime(1000, 1);
    console.log(res);
}

// 编译后（简化版）
function main() {
    return _asyncToGenerator(function* () {
        const res = yield syncTime(1000, 1);
        console.log(res);
    })();
}

_asyncToGenerator 就是那个自动执行器，它负责驱动 Generator 运行，直到 Promise 完成或结束。

状态切换

async 函数在执行时，会维护一个状态机：

等待中 → Promise resolve → 继续执行 → 等待中 → ...

每次遇到 await，就会暂停函数执行，等待后面的 Promise resolve 后再继续。暂停期间，调用栈是空的，JavaScript 可以去执行其他任务。

继发与并发

回到文章开头，for + await 为什么是继发执行？

async function main() {
    for(let i=0 ;i<10; i++){
        let res = await syncTime(1000, i)
        console.log(res);
    }
}

因为每次循环都在 await 处暂停，必须等当前 Promise resolve 后，才会执行下一次循环的 await。这就是继发（串行）。

如果想要并发执行，应该这样：

async function main() {
    const promises = [1,2,3,4,5].map(i => syncTime(1000, i));
    const results = await Promise.all(promises);
    console.log(results); // 一次性等所有 Promise 完成
}

Promise.all 会同时启动所有异步任务，等全部完成后一起返回结果。这就是并发（并行）。

Promise 执行流程

关于 Promise 的详细解析，可以参考另一篇文章：

Promise原理解析

Promise 的 .then() 和 async/await 本质上都是注册回调，等待 Promise 状态变更后执行。async/await 只是让写法更同步化。

async 函数返回值

async 函数必然返回一个 Promise：

async function demo() {
    return 123;
}
console.log(demo() instanceof Promise); // true

// 等价于
function demo() {
    return Promise.resolve(123);
}

如果 async 函数内部抛出异常，则会返回一个 rejected 的 Promise：

async function demo() {
    throw new Error('Oops!');
}
demo().catch(err => console.log(err.message)); // Oops!

错误处理

async/await 的错误处理用 try...catch：

async function main() {
    try {
        const res = await fetch('/api/data');
        const data = await res.json();
        console.log(data);
    } catch (err) {
        console.error('请求失败:', err);
    }
}

这比 Promise 的 .catch() 更直观，代码阅读起来和同步写法几乎一致。

捕获多个 await

async function main() {
    try {
        const user = await fetchUser();
        const posts = await fetchPosts(user.id);
        const comments = await fetchComments(posts[0].id);
    } catch (err) {
        // 三个 await 中任意一个 reject，都会进入这里
        console.error('流程异常:', err);
    }
}

async/await 踩坑

1. 平行await vs 继发await

// 继发：每个 await 等待上一个完成
const a = await fetchA();    // 等待 1s
const b = await fetchB(a);   // 等待 1s
const c = await fetchC(b);   // 等待 1s
// 总耗时：3s

// 并发：Promise.all 同时发起
const [a, b, c] = await Promise.all([fetchA(), fetchB(), fetchC()]);
// 总耗时：1s

2. await 在 forEach 中陷阱

// 错误写法
[1, 2, 3].forEach(async (item) => {
    await fetch(item); // forEach 不会等待 async 回调
});

// 正确写法：使用 for...of
for (const item of [1, 2, 3]) {
    await fetch(item);
}

3. async 回调函数

// 错误
arr.map(async (item) => {
    return await fetch(item);
}); // 返回的是 Promise[]，不是数据[]

// 正确
const results = await Promise.all(arr.map(item => fetch(item)));

参考

ES6中的Iterator迭代器

Promise原理解析

MDN: async function

ECMAScript: async function definitions

ps: 微信公众号：Yopai，有兴趣的可以关注，每周不定期更新，不断分享，不断进步

引言
随着企业数字化转型迈入深水区，“数据驱动决策”虽已成为行业共识，但理想与现实之间仍存在一道鸿沟。在大多数企业的日常经营中，这种“数字尴尬”随处可见：

销售团队每天录入海量客户数据，却没有人能快速分析出成单规律；运营同学整理了整月的活动数据，面对 Excel 却无从下手；管理者想要一份实时报表，却总要等 IT 部门排期开发……

💡 痛点一：「表格易填，分析难」
数据越积越多，但能从中挖出价值的人却寥寥无几。

💡 痛点二：「工具门槛高」
SQL 不会写，Python 不会用，Excel 透视表也搞不定。

💡 痛点三：「协作效率低」
分析结果导出后，还要手动整理成报告，跨部门分享更是困难重重。

今天，这个困扰企业多年的难题，终于有解了。

01 Data Agent：你的专属数据分析智能体

阿里云瑶池 Data Agent 与钉钉 AI 表格正式达成深度合作，推出 Data Agent 数据分析智能体插件，为所有钉钉 AI 表格用户提供"一键式"专业级数据分析服务。

什么是 Data Agent ？

它是阿里云瑶池数据库团队推出的面向企业用户的数据分析智能体。能够根据自然语言描述进行需求分析，自动完成数据理解、提出分析需求、扩展分析思路，最终通过调用工具交付分析结果。

它能同时覆盖传统 BI 分析（描述性、诊断性）和高级分析（预测性、规范性），既可以作为自然语言到 SQL 查询的转换工具（NL2SQL），也可以生成预定义报表的聊天式 BI（包括 ChatBI），是一个具备理解分析意图、规划分析路径、执行复杂任务、并生成深度洞察的自主智能系统，能稳定完成复杂、多步骤的数据分析任务。

简单来说：你只需用一句话提问，它就能帮你完成从数据洞察到报告生成的全流程。

现在，这一强大能力正式接入钉钉 AI 表格！

02 七大核心能力，覆盖全场景分析需求

Data Agent 可直接读取钉钉 AI 表格中的结构化数据，支持自然语言交互，实现：

用户无需编写公式或代码，只需用中文提问即可获得精准洞察。

03 六大核心优势，让数据分析零门槛

 
✅ 零门槛：人人都能做分析
普通员工也能像数据分析师一样使用，告别复杂的 Excel 公式和 SQL 语句。

⚡ 实时高效：秒级响应
数据更新后秒级响应，无需导出导入，分析结果即时呈现。

🔒 安全合规：数据隔离有保障
每个用户独立沙箱环境，数据安全有保障。Agent 不会使用您的数据进行模型训练。

Data Agent 构建了“身份-环境-管控”三位一体的安全体系：
访问控制：通过“安全托管”实现账号密码不落地；支持细粒度权限、自动脱敏与全程审计。
环境隔离：采用内核级沙箱与 VPC 闭环隔离，确保数据交互在闭环内完成，阻断外网威胁。
管控安全：租户级会话隔离，任务结束即销毁环境并清除数据，杜绝数据残留。

该方案实现了“账号不落地、环境全隔离、操作可审计、数据无残留”的全链路安全保障。

🔄 AI 生态打通：钉钉闭环体验
与钉钉生态紧密协作，不用申请权限，不用导出 Excel，钉钉 1 分钟超快速启用，钉钉用户可闭环实现数据分析。

🆓 免云账号登录：降低使用门槛
无需登录阿里云账号，钉钉用户即可开启免费体验（每天 30min 免费体验）。

📤 钉钉分享报告：让洞察流动起来
分析报告直接生成钉钉文档，支持跨群分享、深度协作，让数据洞察在团队中流动起来。

04 免费试用，三步开启智能分析

Step 1：打开钉钉 AI 表格
在钉钉中打开任意 AI 表格。

Step 2：搜索 Data Agent 插件
点击顶部插件搜索 → 输入「Data Agent」。

Step 3：开始对话式分析
用自然语言描述你的分析需求，坐等专业报告生成。

05 长期记忆：让 Agent 越用越懂你

您是否担心每次分析都要重复背景？Data Agent 的「长期记忆」功能让这些繁琐化为乌有。

Data Agent 不仅仅是一个工具，它更像一位具备持续学习能力的资深助理，在每一次交互过程中，会自动“做笔记”，将您的业务偏好、特定术语和历史逻辑沉淀为专属知识。这些记忆将在你后续的交互中被智能召回和应用，从而显著提升 Agent 对你业务需求的理解准确性。

为了让这种“记忆”透明且可控，我们提供了全方位的记忆管理中心：

溯源链路：支持查看记忆来源，一键追溯对话上下文，让每一条结论都有据可依。
热度洞察：通过热度值算法识别高频、核心信息，自动筛选出最懂你业务的“黄金记忆”。
精准修正：赋予用户主动干预权，支持手动编辑与订正，确保 Agent 的认知与实际业务逻辑严丝合缝。
隐私闭环：灵活的删除与遗忘机制，在提供个性化服务的同时，严守数据边界与隐私安全。

06 让数据真正成为生产力

不仅是技术上的强强联手，更是对企业数字化办公模式的一次重塑。它以极简的操作逻辑，解决了高成本、低效率、门槛高、转化难等长期困扰企业的痛点，完成了从“人工搬运报表”到“智能自动洞察”的跨越式升级。让每位用户都能在指尖释放数据潜能，将海量信息转化为驱动业务增长的精准指引，让数据真正成为驱动企业提质增效的硬核生产力。

在数字化转型的浪潮中，数据是企业最宝贵的资产。阿里云瑶池数据库与钉钉的这次深度合作，正是为了让每一位员工都能轻松驾驭数据，让智能分析能力普惠到每一个工作场景。

现在，打开你的钉钉 AI 表格，搜索「Data Agent」，开启你的智能数据分析之旅吧！

了解更多

产品详情：https://help.aliyun.com/zh/dms/data-agent-for-analytics
免费试用（每天可享 30min 免费试用）：https://agent.dms.aliyun.com/
欢迎钉钉搜索群号“105130018526” 或扫码加入钉群交流

在数字化转型的浪潮中，政企单位的办公效率得到了质的飞跃，但随之而来的安全风险也日益复杂。2026年，信息安全已不再是单一的防火墙问题，而是涉及数据主权、链路加密、身份认证及国产化适配的系统工程。对于政企单位而言，通讯系统不仅是办公工具，更是核心机密的承载流转平台。

如何在高频的日常沟通中守住安全红线？本文将从底层架构到应用层面，结合主流私有化解决方案实事求是地展开讨论。

一、 私有化部署

在讨论安全之前，必须先明确一个核心概念：数据归谁所有。

公有云办公产品虽然便捷，但其数据存储在服务商的机房中。对于政企单位，尤其是军工、金融及政府部门，这种“托管”模式天然存在数据受控权缺失的隐患。

1. 物理层面的完全掌控

真正的安全始于物理隔离。政企单位首选的通讯方案必须支持私有化部署。以喧喧为例，其核心逻辑就是将服务器程序直接安装在单位自有的机房或私有云中。这意味着所有的聊天记录、文件资料、组织架构信息都存储在单位内部的磁盘上。

这种部署模式解决了两个核心问题：一是规避了公有云服务商可能存在的内部人员越权查看风险；二是确保了在极端情况下（如外部断网），内部通讯系统依然能够依靠内网环境正常运行，保障指挥调度的连续性。

2. 闭环管理的数据留痕

在私有化环境下，数据审计不再受制于第三方接口。政企单位可以根据审计要求，对所有的通讯历史进行自助式的管理与备份。实事求是地讲，这种管控力是任何公有云产品通过协议保障都无法完全替代的。

二、 不透明与高强度的双重护航

在数据传输过程中，如何防止“中间人攻击”或包嗅探？

1. 闭源协议的防御价值

目前市面上很多开源通讯协议虽然灵活，但也意味着其漏洞对全世界公开。喧喧在设计上采取了底层通讯协议不开放的策略。这种设计在政企安防中具有实际意义：它极大地提高了外部攻击者通过扫描特定协议漏洞进行渗透的难度。

2. 高级加密标准（AES）的实战应用

在2026年的安全语境下，我们必须摒弃那些未经广泛验证的特种加密方式，回归到国际公认的稳固算法。政企通讯系统应统一采用高级加密标准（AES）对传输链路进行加固。

喧喧在处理每一条消息、每一个文件分片时，都会进行高强度的加密处理。即使数据包在传输路径中被截获，由于缺乏密钥，攻击者拿到的也只是一堆毫无意义的乱码。这种基于标准算法的严谨性，比宣传噱头更能保障政企单位的长治久安。

三、 身份与权限

安全风险往往源于内部，尤其是身份冒用或权限越界。

1. 严格的准入机制

政企系统不应支持开放注册。所有的账号必须通过后台统一分配，并与组织架构深度挂钩。喧喧支持与禅道等项目管理系统的组织架构同步，这意味着人员的入职、调岗、离职能实时反映在通讯权限上，从源头上杜绝了离职人员长期逗留在内部群聊的风险。

2. 功能层面的权限隔离

并非所有的沟通都需要被所有端看到。政企单位往往需要针对不同级别的人员设置不同的功能权限。例如：

• IP登陆限制： 按照 IP 段限制用户登录来源 IP，只有在预设的IP地址范围内的用户才能登录系统，提升服务安全性，有效阻止外部攻击者的尝试。
• 通讯全加密： 所有通话均采用高级加密标准，确保聊天消息和文件在传输过程中得到安全加密，防止数据泄露，保障您的通信隐私。
• 消息审计： 在符合保密规定的前提下，系统应具备可追溯的消息审计能力，确保每一句指令、每一份文件都有据可查。

四、 国产化适配

对于政府机关和事业单位，信息安全与国产化替代（信创）密不可分。如果通讯软件只能跑在特定国外的操作系统或芯片上，那么这种安全性本身就是不完整的。

1. 全栈适配的重要性

一套合格的政企通讯系统，必须能够完美兼容国产化的基础设施。 在实际应用案例中（如市财政信息管理中心、国家统计局调查总队等），喧喧展示了其对国产计算平台的高度适配。无论是麒麟、统信等操作系统，还是龙芯、鲲鹏等国产处理器，通讯软件必须做到低功耗、高响应，且无兼容性漏洞。

2. 软硬件一体化的协同

安全不是孤立的软件。喧喧支持专网部署，并能与内部已有的复杂办公系统进行一体化集成。通过将零散的业务系统集成到一个受控的平台，减少了员工在多个系统间切换导致的信息泄露风险。

五、 团队能力与实事求是的稳定性

安全不仅是代码问题，更是研发团队的责任心问题。

政企单位在选择IM系统时，应考察产品背后的研发底蕴。喧喧所属的禅道团队在管理软件领域积累了十余年经验，这种经验体现在软件的“稳”上。对于军工、金融行业而言，软件崩溃一次可能导致重大的决策延误。

1. 轻量化带来的高稳定性

很多政企通讯软件为了追求功能丰富，集成了大量的冗余模块，导致系统臃肿、内存泄漏。喧喧反其道而行之，采用轻量化架构，即使在配置较低的国产服务器上也能稳定带起数千人的并发请求。这种对性能的克制，本质上是对安全和稳定性的另一种守护。

六、 2026年政企安全防范的新挑战

随着人工智能和量子计算的发展，政企通讯安全面临新的挑战：

1. AI欺诈防御： 系统需要集成更先进的身份验证（如动态密钥、多重因子认证）。
2. 大数据的安全脱敏： 在进行通讯数据分析时，如何确保个人隐私与单位机密的剥离。

结语

政企内部通讯的安全保障，没有捷径可走。它需要单位从“租房者”心态转变为“房东”心态，通过私有化部署夺回数据主权；它需要研发团队摒弃花哨的噱头，在协议层、加密层、权限层做扎实的苦功夫。

喧喧在这一领域的表现，实事求是地为我们提供了一个范本：不张扬，但足够稳固；不开放底层协议，但支持灵活的应用扩展。对于追求极致安全与国产化适配的政企单位而言，回归私有、回归受控，才是信息安全的长久之道。

为什么企业上线工单系统后，反而更忙了？

在很多企业推进IT服务管理的过程中，工单系统被视为“基础能力”。通过统一入口收集需求、记录处理过程，理论上可以提升效率与透明度。但在实际落地中，不少IT团队却发现一个问题：工单数量迅速增长，处理压力反而更大。ManageEngine卓豪 将为您解答这些问题！

例如，以前通过微信或电话沟通的问题，现在全部转化为工单；用户更容易提交需求，但处理能力并没有同步提升；一些原本可以快速解决的小问题，也被流程“放大”。这些变化，使IT团队陷入持续被动应对的状态。

这种情况并不意味着工单系统本身存在问题，而是使用方式存在偏差。

问题根源：工单系统只是“记录工具”，而不是“管理工具”

在一些企业中，工单系统的作用仅限于记录问题与处理过程，而缺乏对流程、优先级与资源的管理。这种情况下，系统只是将原本分散的需求集中起来，并没有优化处理方式。

例如，所有工单都进入同一队列，没有清晰的分类与优先级；分配依赖人工判断，容易出现不均衡；重复问题不断出现，但缺乏沉淀与复用机制。这些问题都会导致效率下降。

当工单系统无法提供管理能力时，就很难真正改善现状。

用户体验变化：为什么“提交更容易”反而带来压力？

工单系统的一个重要特点，是降低了用户提交需求的门槛。用户可以随时随地提交问题，这在提升体验的同时，也会增加需求数量。如果没有相应的筛选与分类机制，IT团队很容易被大量低价值请求淹没。

例如，一些简单问题本可以通过知识库解决，但用户仍然选择提交工单；重复问题没有被有效识别，导致重复处理。这些情况都会增加不必要的工作量。

因此，在提升入口便捷性的同时，也需要建立有效的分流机制。

ServiceDesk Plus 如何帮助企业“管住工单”？

通过ServiceDesk Plus，企业可以从流程、自动化与知识管理等多个方面优化工单处理。例如，通过分类与优先级规则，实现自动分配；通过知识库减少重复问题；通过SLA与报表分析提升整体效率。

这种综合能力，使工单系统从“记录工具”转变为“管理平台”，从而真正帮助IT团队减轻压力。

在下一部分中，我们将深入分析：如何从源头减少无效工单，让IT从“被动处理”走向“主动管理”。

从源头减少工单：为什么“少做工单”比“快做工单”更重要？

在多数企业中，IT团队往往将重点放在“如何更快处理工单”，例如提升响应速度、增加人手或优化分配机制。但如果不从源头减少无效需求，工单数量只会持续增长，最终形成恶性循环。因此，真正有效的策略，是在提升处理效率的同时，减少不必要的工单。

例如，通过分析历史数据，可以发现大量重复问题，如密码重置、基础软件安装或常见故障处理。这些问题如果通过知识库或自助服务解决，就无需进入工单流程，从而显著降低工作量。

这种“前移处理”的思路，是工单管理从被动走向主动的重要一步。

常见问题（FAQ）

1. 工单系统是否会增加工作量？
   如果缺乏优化机制，可能会出现这种情况。
2. 如何减少重复工单？
   通过知识库与自助服务实现。
3. 自动化是否可以解决所有问题？
   不能，需要与流程与数据结合使用。
4. 如何进一步了解工单管理优化？
   可以参考ITSM解决方案获取更多信息。

2025 年 12 月 13 日，VeloxCon China 2025 在北京成功举办。作为 Velox 项目首次在中国举办的线下技术大会，汇聚了来自Meta、IBM、蚂蚁集团、阿里云、腾讯、小米、小红书等企业的数十位核心贡献者与一线工程师。

大会通过 18 场演讲将 Velox 置于真实业务场景之中，系统展示了其在架构演进、AI 数据处理、湖仓加速、流批融合等方向的最新实践。这些分享不仅直面性能、稳定性与兼容性等落地挑战，也反应了开发者社区对构建可靠、可扩展、可协同的数据基础设施的共同探索，彰显了中国开发者在全球高性能分析生态中的工程深度与协作广度。

夯实底座，突破能力边界
会议伊始，Velox 项目联合发起人 Pedro 发表开幕致辞。他回顾了 Velox 开源项目的发展历程，从项目启动、开源发布到建立技术治理结构，展示了 Axiom 架构、GPU 支持、PyVelox 等关键进展，强调了社区协作与工程严谨性是项目持续演进的核心动力。他特别提到，Velox 已建立了正式的技术治理机制，并迎来来自 IBM、Intel、NVIDIA、Microsoft 等多家企业的新增维护者，标志着项目正迈向更加开放和可持续的阶段。

在明确了社区与架构演进的总体方向后，大会议题迅速深入到如何利用 Velox 构建高性能计算引擎的具体实践中。阿里云 EMR Serverless Spark 技术负责人周克勇系统阐述了“可组合性”在数据计算领域的实践。他详细解析了阿里云如何深度集成并贡献于 Apache Celeborn、Paimon、Velox 及 Gluten 等开源组件，通过模块化组装构建出高性能湖仓一体引擎。他指出，基于该架构，阿里云 EMR Serverless Spark 成功创造了 TPC-DS 100TB 规模性能测试的世界新纪录，实现性能翻倍与性价比大幅提升。

接着，Meta 软件工程师 Masha Basmanova 阐述了现有查询引擎在跨语言通信、优化器能力与开发体验上面临的挑战，并介绍了基于 C++ 的统一前端框架 Axiom。该框架将 SQL 解析、逻辑优化与物理执行融为一体，通过内置的强大优化器与 Velox 运行时无缝对接，能够实现更高效、可扩展的查询处理。演讲最后，她积极展示了 Axiom 的开源路线图，并欢迎全球开发者加入，共同推动该项目的演进。

强大的执行框架，最终需要服务于极具挑战性的数据场景，特别是爆发式增长的 AI 数据。Meta 软件工程师孟晓烜则在之后的演讲中，深入阐述了应对AI训练数据规模激增与成本挑战的解决方案。他重点介绍了 Meta 如何通过数据归一化技术剥离重复特征，并构建可索引的序列存储系统。依托 Velox 技术栈，团队在训练数据的加载、生成与探索三大环节实现了端到端优化，显著提升了处理效率与资源利用率。

在 Meta 多位工程师从框架演进、可组合架构、数据标准化等角度深入分享后，蚂蚁集团高级技术专家黄叶伟也从企业落地实践层面分享了基于 Velox 的 Spark 加速实践。他重点介绍了基于 Gluten 与 Velox 构建的向量化引擎如何通过任务级 Fallback、Spill 优化、Shuffle 优化等关键技术，在混合部署场景下显著提升 Spark 性能与稳定性。他表示，该方案目前已实现日均数十万任务覆盖，平均节省资源超30%，并将在算子优化与架构扩展方面持续演进。

作为连接 Spark 生态与原生加速的关键中间层，Apache Gluten 的进展同样备受关注。来自 IBM 的莫芮与周渊聚焦 Apache Gluten与 Velox 的深度集成，阐述了其如何在大数据分析中驱动创新。他们介绍，Gluten 在保持对 Spark/Flink 作业透明加速能力的同时，正逐步增强对多后端引擎和复杂业务场景的适配能力。目前，该方案已在 Pinterest、顺丰科技及多个内部集群完成规模化验证，有效支撑了从日志分析到物流调度等多样化负载的性能提升与成本优化。

随着向量化加速在通用场景日趋成熟，针对特定存储格式的深度优化成为新的效能突破口。腾讯大数据开发工程师陈锦海分享了微信基于 Velox 加速 lceberg 湖仓分析的优化与实践，重点介绍了原生分桶方案。据他介绍，该方案通过动态识别表元信息自动设置分区数，能有效缓解 AQE 引发的写入倾斜，结合空闲资源灰度发布策略，可保障大规模作业的稳定上线。

扎根场景，释放协同效能
午餐后的议程更加聚焦 Velox 在真实业务中的集成深度与生产韧性，回应了开发者们对兼容性、稳定性与端到端效能等规模化落地的核心关切。
小米计算平台计算引擎负责人王胜杰分享了公司在 Spark 向量化升级中的规模化落地经验。面对业务迁移中的兼容性与稳定性挑战，他表示，小米通过自动兼容校验、双跑结果比对及内存异常感知的三级资源升级机制，已成功推动向量化改造在数十万作业中平稳落地。

面对海量数据挑战，全球科技公司也在探索相似的演进路径。Meta 软件工程经理 Stanley Yao 在演讲中分享了公司基于 Velox 推进 Spark 向量化改造的整体策略。他表示，团队通过从定制化方案到开源架构的持续演进，已实现关键业务管线向 Gluten（Flare）的平稳迁移，并获得显著的效率提升。未来，Meta 计划进一步扩大该架构的应用规模。

在 CPU 向量化趋于普及的同时，利用异构硬件挖掘更高性能成为新的前沿。IBM 研究院资深软件工程师 Zoltán Arnold Nagy 展示了基于 Velox 与 Presto 的 GPU 加速数据处理方案。他介绍道，Velox 通过与 cuDF 集成，可在 GPU 上高效执行算⼦，并针对多 GPU 分布式场景优化通信与数据交换。此外，为突破 I/O 瓶颈，团队正在探索结合 GPUDirect 存储与缓存层的加速策略。

对性能与稳定性的追求，也驱动着查询引擎架构本身的融合与创新。Meta 软件工程师谭家梁与大家分享了 Native Presto-on-Spark 的规模化应用。该架构以 Presto 查询优化、Spark 资源调度与容错机制以及 Velox 原生向量化执行为核心，实现了性能与可靠性的显著提升。他表示，目前该方案已在生产环境中取得成效，并将在未来持续推进全栈原生化演进。

对于国内庞大的云上业务，Velox 同样在支撑着关键数据服务平台。 阿里云高级工程师王彬与范阿冬系统介绍了Velox在阿里云日志服务中的深度集成与应用。他们指出，基于 Velox 构建的高性能查询引擎，通过混合执行、表达式下推、自动增量物化视图及免 Schema 分析等核心技术，可显著提升平台在处理海量实时数据时的查询效率与资源利用率。他们还强调，该架构不仅为日志分析、智能运维等场景提供了稳定支撑，也为面向 AI 的云原生数据平台演进奠定了坚实基础。

除了通用的日志与湖仓分析，Velox 也在向更垂直的时序数据场景渗透。腾讯高级工程师李兆龙分享了基于 Velox 构建云原生时序数据库的落地经验。他表示，通过在 Velox 中实现时序数据去重优化与存储写入增强，系统在应对高频写入与实时查询场景时，可显著提升吞吐效率与响应性能。目前该方案已有效支持物联网、实时监控等业务场景，未来还将进一步完善缓存与压缩机制，持续优化时序数据处理的整体效能。

IBM 软件工程师刘平接着分享了 Velox 在 Iceberg 数据写入能力上的突破性进展。他表示，目前 Velox 对 Iceberg 的支持以读取为主，其写入功能的完善将填补该方向的关键能力空白，为基于 Presto 与 Spark 的数据湖架构提供更统一、高效的数据摄入层。这一进展也标志着 Velox 正从查询加速向数据全链路处理拓展。

接着，来自阿里云的毕岩与周滔分享了 Velox 与 Apache Paimon 深度集成的解决方案，为提升引擎与存储的协同效率提供了另一种集成思路。在他们看来，现有方案存在表类型支持受限、缺乏可移植性等瓶颈， 但可以建立 C++ 原生 Paimon 库，通过其统一的数据协议与插件化设计，使 Paimon 能够被 Velox、StarRocks 等多种计算引擎直接高效调用，从而提升数据读写性能，并为湖仓格式的跨引擎协同提供新的基础支撑。

在批处理场景之外，流计算框架的向量化也正成为新的热点。蚂蚁集团技术专家刘勇介绍了基于 Velox 为 Flink 构建的统一向量化执行引擎 Flex。他表示，Flink 作为流批一体架构的核心，其原生向量化能力的补足至关重要。Flex 通过将 Velox 的高性能算子能力引入 Flink，同时结合自动化验证、可视化计划与精细化回退机制，现已实现了作业性能的显著提升，并支撑多条核心业务链路平稳运行。

随着 Velox 赋能的应用场景日益广泛和复杂，确保其在不同引擎和版本间的整体质量与可靠性变得至关重要。Meta 软件工程师 Eric Liu 阐述了在 AI 数据基础架构下，保障 Velox 多引擎版本可靠性的系统化方法。他指出，面对不同引擎与存储格式交织带来的复杂性，关键在于建立跨引擎测试框架与合成数据工厂。这一实践能有效提前发现全栈潜在问题，从而确保底层变更在大规模生产环境中的稳定与高效。

针对向量化引擎中窗口运算符内存溢出的典型难题，来自英特尔的贾柯分享了她的见解。她认为，通过为 Velox 引入流式窗口处理机制，可使计算随数据到达逐步执行并即时释放内存，从而从架构层面化解多数场景下的内存风险，显著提升复杂查询的稳定性。

最后，小红书 Native Engine 团队技术负责人魏秀利也分享了向量化引擎在公司业务中规模化落地的经验。据他介绍，通过将写入异步化并构建原生 Avro 读取能力，小红书在不增加业务复杂度的前提下，成功缓解了端到端延迟，印证了“执行与存储协同优化”在湖仓场景中的关键价值。

从底层执行引擎的持续创新，到日志分析、湖仓写入、流批融合等复杂场景的稳定运行，在本届 VeloxCon China 上，我们看到 Velox 的技术价值已在真实业务中不断被验证和拓展。同时我们也很高兴看到中国开发者成为这一进程的重要推动者。期待未来有更多志同道合者加入 Velox 开源社区，共建高性能分析基础设施。weibo.com/ttarticle/p/show?id=2309405290444279382147 weibo.com/ttarticle/p/show?id=2309405290444732366863 weibo.com/ttarticle/p/show?id=2309405290445097271533 weibo.com/ttarticle/p/show?id=2309405290445638336736 weibo.com/ttarticle/p/show?id=2309405290446007173241 weibo.com/ttarticle/p/show?id=2309405290446380728330 weibo.com/ttarticle/p/show?id=2309405290446749564933 weibo.com/ttarticle/p/show?id=2309405290447177646313 weibo.com/ttarticle/p/show?id=2309405290447731294276

Photoshop（简称PS）是Adobe公司开发的专业图像编辑软件，它的主要功能是进行数字图像处理、照片修饰、图形设计和创意合成。如果你需要进行照片后期处理、平面设计、网页设计、数字绘画或任何与图像相关的工作，那Photoshop绝对是你必须掌握的专业工具。

Photoshop提供了全面的图像编辑工具和强大的创意功能，让用户能够实现从简单的照片调整到复杂的视觉特效的各种需求。软件支持图层、蒙版、滤镜、调整图层等核心概念，这些功能组合使用可以创造出无限可能的视觉效果。无论是专业设计师、摄影师、艺术家，还是普通用户，Photoshop都能提供相应的工具和解决方案。

Photoshop在创意产业中占据主导地位，广泛应用于广告设计、出版印刷、影视后期、游戏美术、UI设计等领域。软件的学习资源丰富，有大量的教程、插件和社区支持。

PS下载

Photoshop安装包下载地址（Windows+MacOS 安装包，另含多套 PS 使用教程，全是干货）：
https://pan.quark.cn/s/be38afdc9026
https://pan.xunlei.com/s/VOq4vUVV5p5m-HXpN_DjKYjWA1?pwd=ussx#

PS安装

Photoshop的安装过程非常简单，全程只需要傻瓜式操作，下面我详细说明一下安装步骤，我安装的是 Photoshop 2025：
1）下载  Photoshop 2025.rar 压缩包文件，解压后得到下图的文件夹：

2）找到 Set-up.exe 可执行程序，双击启动安装。

3） 选择安装位置，默认安装路径通常是"C:\Program Files\Adobe"。如果你想安装到其他磁盘，可以点击文件夹按钮自定义安装路径。建议安装到非系统盘，比如D盘，以避免占用系统盘空间。

4）等待安装完成，当提示"Photoshop 2025 已经成功安装"时，表示安装完成。你可以点击"启动"按钮立即启动Photoshop，或者稍后从开始菜单或桌面快捷方式启动。

PS基础使用

安装完成后第一次启动Photoshop，你会看到主界面包含菜单栏、选项栏、工具栏、面板和工作区等部分。

1）基本操作

要开始工作，首先需要创建新文档或打开现有图像。在"文件"菜单中选择"新建"可以创建空白画布，设置尺寸、分辨率、颜色模式等参数。选择"打开"可以导入各种格式的图像文件，如JPEG、PNG、TIFF、RAW等。

Photoshop的核心概念是图层。每个图层可以包含不同的图像元素，图层之间可以独立编辑而互不影响。图层面板显示了所有图层的堆叠顺序，你可以通过拖动调整图层顺序，通过眼睛图标控制图层可见性。

2）主要工具

工具栏包含了Photoshop的所有主要工具，按功能分组：

• 选择工具：矩形选框、椭圆选框、套索工具、快速选择工具、魔棒工具等，用于选择图像中的特定区域。
• 裁剪和切片工具：裁剪工具、切片工具等，用于调整画布大小和分割图像。
• 修饰工具：修复画笔、仿制图章、橡皮擦、模糊工具等，用于修复照片缺陷和进行局部调整。
• 绘画工具：画笔工具、铅笔工具、渐变工具等，用于绘制和填充颜色。
• 文字工具：横排文字、直排文字等，用于添加和编辑文本。

• 形状工具：矩形工具、椭圆工具、多边形工具等，用于创建矢量形状。

  3）调整功能

  Photoshop提供了多种图像调整功能，可以通过"图像"菜单或调整图层应用：

• 色阶和曲线：调整图像的整体色调和对比度。
• 色相/饱和度：调整图像的颜色属性。
• 色彩平衡：调整图像的颜色平衡。
• 亮度/对比度：调整图像的明暗和对比。

这些调整可以创建为调整图层，这样调整效果是非破坏性的，可以随时修改或删除。

对于新手用户，建议先从简单的照片调整开始练习，如裁剪、亮度调整、颜色校正等，Photoshop提供了丰富的学习资源。

PS常见使用问题

Photoshop运行缓慢或卡顿怎么办？这个问题通常与硬件配置或软件设置有关。首先检查电脑是否满足Photoshop的最低系统要求，特别是内存和显卡。在Photoshop的"首选项"中，可以调整性能设置：增加内存使用量，设置合适的暂存盘（建议使用SSD），启用图形处理器加速。关闭不必要的面板和文档，减少同时打开的文件数量。定期清理Photoshop的缓存文件和历史记录。

Photoshop无法打开某些图像文件怎么办？首先确认文件格式是否受支持，Photoshop支持大多数常见图像格式。如果文件损坏，尝试使用其他软件打开或修复。检查文件扩展名是否正确，有时文件可能被错误命名。对于RAW格式照片，确保安装了最新的Camera Raw插件。某些特殊编码的文件可能需要额外的解码器或插件。

Photoshop的工具或功能无法使用怎么办？首先检查当前工作模式，某些工具在特定模式下不可用。检查图层状态，某些操作需要选择正确的图层或创建选区。查看工具选项栏的设置，某些工具可能有特殊限制或模式。如果问题涉及特定功能，检查是否安装了必要的插件或扩展。尝试重置Photoshop首选项：在启动时按住Alt+Ctrl+Shift（Windows）或Option+Command+Shift（macOS）。

Photoshop的字体显示不正常怎么办？首先检查字体是否已正确安装在系统中。在Photoshop的"文字"菜单中，可以查看可用字体列表。如果字体显示为灰色或缺失，可能需要重新安装字体。某些字体可能有特殊授权限制，只能在特定应用程序中使用。检查字符编码设置，特别是处理多语言文本时。还可以尝试清除字体缓存：在Creative Cloud应用程序中修复Photoshop安装。

PS下载安装教程总结

Photoshop作为行业标准的图像编辑软件，在数字创意领域发挥着不可替代的作用。通过系统学习Photoshop的使用方法，用户可以实现从基础照片调整到复杂视觉创作的各种需求。

对于摄影师，Photoshop提供了专业的照片后期处理工具，可以提升图像质量、修复缺陷、创造艺术效果。对于设计师，软件的图层、蒙版、矢量工具支持复杂的设计项目和创意表达。对于艺术家，数字绘画和合成功能开启了新的创作可能性。对于普通用户，基础编辑功能可以满足日常的图像处理需求。

掌握Photoshop的使用技巧需要时间和实践，但投入是值得的。一个熟练的Photoshop用户可以在更短的时间内完成更高质量的工作，实现更复杂的创意构想。无论是职业发展还是个人兴趣，Photoshop技能都能带来显著的价值和满足感。

本文图文并茂记录购买Vultr供应商的VPS，通过shell脚本的方式，快速部署一个属于自己的VPN，从而实现逛GitHub自由...

1. 什么是VPS？和现在的云服务器的区别

VPS就是Virtual Private Server，虚拟专用服务器

• 对比于现在的火山引擎、腾讯云、阿里云等云服务器而言，VPS可以理解为迷你版的云服务器
• 依托于服务器虚拟化技术，可以把一个配置高的服务器，虚拟切割成好几台配置低的服务器 比如16核32G的可以切成两台8核16G，这样就可以卖给两个用户，减少资源闲置多挣米
• 但是对比云服务器和VPS，前者可以智能灵活调度（成百上千台服务器组成的服务器资源池子） 而VPS就是一台物理服务器的切割，相当于我们租赁了一个小单间
• 所以，云服务器挂了，智能调度会立刻新启用一台虚拟服务器，备份并重新启动相关服务 但是，VPS要是挂了，因为是小单间模式嘛，高可用是无法做到位的
• 所以，学习Linux、搭个小网站、个人VPN购买便宜的VPS就够用了
• 不过公司业务、需要高可用、随时要扩容，就得选真正的云服务器了

无论VPS还是云服务器，都是物理意义上的服务器上的一部分，不存在两个物理服务器各出一半

2. 买VPS服务器做相应配置

VPS服务器供应商不少，不赘述，笔者买的是Vultr，还不错

官网：https://www.vultr.com/zh/

至于购买步骤流程，可以参考这个文章：https://zhuanlan.zhihu.com/p/701057606

建议，提前准备好一个VISA信用卡哦

服务器配置如下图参考

第一步——选配置

第二步——选择操作系统（防火墙规则【相当于云服务器的安全组概念】）

第三步——创建实例，等待一会

第四步——有了自己的公网ip了，可以ssh链接了

第五步——防火墙组设置

使用udp搭配443端口（要放开哦，要不然无法连接VPN服务）

3. 执行一键部署VPN脚本

部署脚本是setup-hysteria.sh这个文件，名字无所谓，主要是内容如下：

PASSWORD="password123" 是示例，实际上可以设置复杂一些，在搭配fail2ban这样可以保证服务器安全不被爆破

#!/bin/bash
set -e

# 注意，要赋予此脚本执行权限：chmod +x setup-hysteria.sh
# 然后在执行：./setup-hysteria.sh

# ==================== 配置变量（按需修改） ====================
PASSWORD="password123"
LISTEN_PORT="443"
MASQUERADE_URL="https://www.bing.com"
CERT_DAYS="365"
HY_VERSION="v2.8.1"
# ============================================================

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'

echo -e "${GREEN}========================================${NC}"
echo -e "${GREEN}   Hysteria ${HY_VERSION} VPN 服务器安装   ${NC}"
echo -e "${GREEN}          Ubuntu 22.04 专用           ${NC}"
echo -e "${GREEN}========================================${NC}"

if [[ $EUID -ne 0 ]]; then
    echo -e "${RED}错误：请使用 root 用户执行此脚本 (sudo ./script.sh)${NC}"
    exit 1
fi

echo -e "${YELLOW}[1/7] 更新系统并安装依赖...${NC}"
apt update -qq
apt install -y -qq wget curl openssl ufw

echo -e "${YELLOW}[2/7] 创建目录结构...${NC}"
mkdir -p /etc/hysteria /etc/ssl/hysteria

echo -e "${YELLOW}[3/7] 生成 SSL 证书（有效期${CERT_DAYS}天）...${NC}"
openssl req -x509 -newkey rsa:4096 -nodes \
    -keyout /etc/ssl/hysteria/key.pem \
    -out /etc/ssl/hysteria/cert.pem \
    -days ${CERT_DAYS} \
    -subj "/CN=www.bing.com"

chmod 644 /etc/ssl/hysteria/key.pem
chmod 644 /etc/ssl/hysteria/cert.pem
echo -e "${GREEN}✓ 证书权限已设置为 644${NC}"

echo -e "${YELLOW}[4/7] 创建配置文件 /etc/hysteria/config.yaml ...${NC}"
cat > /etc/hysteria/config.yaml << YAML
listen: :${LISTEN_PORT}

tls:
  cert: /etc/ssl/hysteria/cert.pem
  key: /etc/ssl/hysteria/key.pem

auth:
  type: password
  password: ${PASSWORD}

masquerade:
  type: proxy
  proxy:
    url: ${MASQUERADE_URL}
    rewriteHost: true

quic:
  initStreamReceiveWindow: 8388608
  maxStreamReceiveWindow: 8388608
  initConnReceiveWindow: 20971520
  maxConnReceiveWindow: 20971520
YAML

echo -e "${YELLOW}[5/7] 使用官方脚本安装 Hysteria ${HY_VERSION} ...${NC}"
bash <(curl -fsSL https://get.hy2.sh/) --version ${HY_VERSION}

echo -e "${YELLOW}[6/7] 配置防火墙 (ufw)...${NC}"
ufw allow ${LISTEN_PORT}/udp
echo -e "${GREEN}已允许 UDP ${LISTEN_PORT} 端口${NC}"

echo -e "${YELLOW}[7/7] 重启 Hysteria 服务并应用配置...${NC}"
systemctl stop hysteria-server || true
systemctl start hysteria-server
systemctl enable hysteria-server
sleep 3

if systemctl is-active --quiet hysteria-server; then
    SERVER_IP=$(curl -s ifconfig.me)
    echo -e "\n${GREEN}========================================${NC}"
    echo -e "${GREEN}✓ Hysteria 部署成功！${NC}"
    echo -e "${GREEN}========================================${NC}"
    echo -e "${YELLOW}服务状态：${NC}$(systemctl status hysteria-server --no-pager | grep "Active:")"
    echo -e "${YELLOW}端口监听：${NC}"
    ss -tulnp | grep ":${LISTEN_PORT}" | grep -v grep || echo "  等待端口监听..."
    echo ""
    echo -e "${GREEN}客户端连接信息：${NC}"
    echo -e "  服务器地址：${SERVER_IP}:${LISTEN_PORT}"
    echo -e "  密码：${PASSWORD}"
    echo -e "  协议：Hysteria ${HY_VERSION}"
    echo ""
    echo -e "${YELLOW}常用管理命令：${NC}"
    echo -e "  查看状态: systemctl status hysteria-server"
    echo -e "  查看日志: journalctl -u hysteria-server -f"
    echo -e "  重启服务: systemctl restart hysteria-server"
    echo -e "  停止服务: systemctl stop hysteria-server"
else
    echo -e "${RED}服务启动失败！查看错误日志：${NC}"
    journalctl -u hysteria-server -n 20 --no-pager
    exit 1
fi

然后，把这个·setup-hysteria.sh·脚本丢到服务器上（ssh链接）比如笔者是放在var目录下的

root@vultr:/var# ls
backups  crash  local  log   opt  setup-hysteria.sh  spool
cache    lib    lock   mail  run  snap               tmp

然后 chmod +x setup-hysteria.sh 给权限，再 ./setup-hysteria.sh 就可以一键部署好vpn服务了

如下日志图：

查看服务状态也是在运行的

root@vultr:/var# systemctl status hysteria-server
● hysteria-server.service - Hysteria Server Service (config.yaml)
     Loaded: loaded (/etc/systemd/system/hysteria-server.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2026-04-21 14:17:33 UTC; 2min 34s ago
   Main PID: 8156 (hysteria)
      Tasks: 7 (limit: 1001)
     Memory: 5.9M
        CPU: 57ms
     CGroup: /system.slice/hysteria-server.service
             └─8156 /usr/local/bin/hysteria server --config /etc/hysteria/config.yaml

Apr 21 14:17:33 vultr systemd[1]: Started Hysteria Server Service (config.yaml).
Apr 21 14:17:33 vultr hysteria[8156]: 2026-04-21T14:17:33Z        INFO        server mode
Apr 21 14:17:33 vultr hysteria[8156]: 2026-04-21T14:17:33Z        INFO        server up and running        {"listen": ":443"}
root@vultr:/var#

至此，我们的VPS服务器上的VPN服务就部署好了，接下来，我们在自己的本机电脑上，使用一些客户端工具，就可以使用VPN服务了

3. 使用clash-verge-rev进行订阅VPN服务（通过配置文件的方式）

首先安装clash-verge-rev，这个软件客户端：https://github.com/clash-verge-rev/clash-verge-rev

如下图：

然后准备一个conf.yaml文件，内容如下：

• 注意：server: 64.176.80.218 就是 VPS服务器的ip
• password: "password123" 也就是服务器的VPN的密码
• 等，不赘述
• 和 ！！！setup-hysteria.sh 这个文件里面配置信息要对上！！！
• rule-providers也可以根据个人情况，适当修改

# ========== 代理节点配置 ==========
proxies:
  - name: "VPS-Hysteria2"
    type: hysteria2
    server: 64.176.80.218
    port: 443
    password: "password123"
    sni: www.bing.com
    skip-cert-verify: true
    # 以下为可选优化参数
    up: "100 Mbps"
    down: "500 Mbps"

# ========== 规则集配置（可选，用于增强分流）==========
rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400

  icloud:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/icloud.txt"
    path: ./ruleset/icloud.yaml
    interval: 86400

  apple:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/apple.txt"
    path: ./ruleset/apple.yaml
    interval: 86400

  google:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/google.txt"
    path: ./ruleset/google.yaml
    interval: 86400

  proxy:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt"
    path: ./ruleset/proxy.yaml
    interval: 86400

  direct:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/direct.txt"
    path: ./ruleset/direct.yaml
    interval: 86400

  gfw:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/gfw.txt"
    path: ./ruleset/gfw.yaml
    interval: 86400

  tld-not-cn:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/tld-not-cn.txt"
    path: ./ruleset/tld-not-cn.yaml
    interval: 86400

  telegramcidr:
    type: http
    behavior: ipcidr
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/telegramcidr.txt"
    path: ./ruleset/telegramcidr.yaml
    interval: 86400

  cncidr:
    type: http
    behavior: ipcidr
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/cncidr.txt"
    path: ./ruleset/cncidr.yaml
    interval: 86400

  lancidr:
    type: http
    behavior: ipcidr
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/lancidr.txt"
    path: ./ruleset/lancidr.yaml
    interval: 86400

  applications:
    type: http
    behavior: classical
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/applications.txt"
    path: ./ruleset/applications.yaml
    interval: 86400

# ========== 代理组配置 ==========
proxy-groups:
  - name: "🚀 节点选择"
    type: select
    proxies:
      - "VPS-Hysteria2"
      - "DIRECT"

  - name: "🎬 流媒体"
    type: select
    proxies:
      - "VPS-Hysteria2"
      - "DIRECT"

  - name: "🤖 AI服务"
    type: select
    proxies:
      - "VPS-Hysteria2"
      - "DIRECT"

# ========== 规则配置 ==========
rules:
  # ===== 1. 规则集分流（如果不想用可以删除本块）=====
  - RULE-SET,applications,DIRECT
  - RULE-SET,icloud,DIRECT
  - RULE-SET,apple,DIRECT
  - RULE-SET,google,🚀 节点选择
  - RULE-SET,proxy,🚀 节点选择
  - RULE-SET,direct,DIRECT
  - RULE-SET,lancidr,DIRECT
  - RULE-SET,cncidr,DIRECT
  - RULE-SET,telegramcidr,🚀 节点选择

  # ===== 2. 国内网站强制直连 =====
  # 通用规则
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - GEOSITE,CN,DIRECT

  # 常见国内网站关键词
  - DOMAIN-KEYWORD,baidu,DIRECT
  - DOMAIN-KEYWORD,taobao,DIRECT
  - DOMAIN-KEYWORD,alipay,DIRECT
  - DOMAIN-KEYWORD,qq,DIRECT
  - DOMAIN-KEYWORD,weixin,DIRECT
  - DOMAIN-KEYWORD,bilibili,DIRECT
  - DOMAIN-KEYWORD,bytedance,DIRECT
  - DOMAIN-KEYWORD,zhihu,DIRECT
  - DOMAIN-KEYWORD,jd,DIRECT
  - DOMAIN-KEYWORD,meituan,DIRECT
  - DOMAIN-KEYWORD,douyin,DIRECT
  - DOMAIN-KEYWORD,pinduoduo,DIRECT

  # 局域网与保留地址
  #- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  #- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  #- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  #- IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  #- IP-CIDR,100.64.0.0/10,DIRECT,no-resolve
  #- IP-CIDR,17.0.0.0/8,DIRECT,no-resolve

  # ===== 3. AI 服务走代理 =====
  # OpenAI
  - DOMAIN-KEYWORD,openai,🤖 AI服务
  - DOMAIN-SUFFIX,openai.com,🤖 AI服务
  - DOMAIN-SUFFIX,chatgpt.com,🤖 AI服务
  - DOMAIN-SUFFIX,ai.com,🤖 AI服务
  - DOMAIN-SUFFIX,oaistatic.com,🤖 AI服务
  - DOMAIN-SUFFIX,oaiusercontent.com,🤖 AI服务
  - DOMAIN-KEYWORD,chatgpt,🤖 AI服务

  # Anthropic (Claude)
  - DOMAIN-SUFFIX,anthropic.com,🤖 AI服务
  - DOMAIN-SUFFIX,claude.ai,🤖 AI服务

  # Google (Gemini/Bard/DeepMind)
  - DOMAIN-SUFFIX,gemini.google.com,🤖 AI服务
  - DOMAIN-SUFFIX,bard.google.com,🤖 AI服务
  - DOMAIN-SUFFIX,deepmind.google,🤖 AI服务
  - DOMAIN-SUFFIX,deepmind.com,🤖 AI服务
  - DOMAIN-SUFFIX,ai.google.dev,🤖 AI服务
  - DOMAIN-SUFFIX,generativeai.google,🤖 AI服务
  - DOMAIN-SUFFIX,proactivebackend-pa.googleapis.com,🤖 AI服务
  - DOMAIN-KEYWORD,generativelanguage,🤖 AI服务

  # Meta (Llama)
  - DOMAIN-SUFFIX,meta.ai,🤖 AI服务
  - DOMAIN-SUFFIX,llama.com,🤖 AI服务
  - DOMAIN-SUFFIX,llama.meta.com,🤖 AI服务

  # 其他海外AI服务
  - DOMAIN-SUFFIX,perplexity.ai,🤖 AI服务
  - DOMAIN-SUFFIX,pplx.ai,🤖 AI服务
  - DOMAIN-KEYWORD,perplexity,🤖 AI服务
  - DOMAIN-SUFFIX,x.ai,🤖 AI服务
  - DOMAIN-KEYWORD,grok,🤖 AI服务
  - DOMAIN-SUFFIX,poe.com,🤖 AI服务
  - DOMAIN-SUFFIX,you.com,🤖 AI服务

  # Hugging Face (AI模型社区)
  - DOMAIN-SUFFIX,huggingface.co,🤖 AI服务
  - DOMAIN-SUFFIX,hf.co,🤖 AI服务

  # 平台/聚合类AI服务
  - DOMAIN-SUFFIX,openrouter.ai,🤖 AI服务
  - DOMAIN-SUFFIX,together.ai,🤖 AI服务

  # Cursor AI 编辑器
  - DOMAIN-SUFFIX,cursor.com,🤖 AI服务
  - DOMAIN-SUFFIX,cursor.sh,🤖 AI服务
  - DOMAIN-SUFFIX,cursor-cdn.com,🤖 AI服务
  - DOMAIN-SUFFIX,workos.com,🤖 AI服务
  - DOMAIN-SUFFIX,challenges.cloudflare.com,🤖 AI服务

  # Amazon Kiro / Amazon AI 服务
  - DOMAIN-SUFFIX,kiro.dev,🤖 AI服务
  - DOMAIN-SUFFIX,amazonkiro.com,🤖 AI服务
  - DOMAIN-KEYWORD,kiro,🤖 AI服务
  - DOMAIN-SUFFIX,aws.amazon.com,🤖 AI服务
  - DOMAIN-SUFFIX,amazonaws.com,🤖 AI服务
  - DOMAIN-SUFFIX,bedrock.aws,🤖 AI服务
  - DOMAIN-KEYWORD,amazonbedrock,🤖 AI服务
  - DOMAIN-SUFFIX,q.aws.amazon.com,🤖 AI服务
  - DOMAIN-SUFFIX,codecatalyst.aws,🤖 AI服务
  - DOMAIN-SUFFIX,sagemaker.aws,🤖 AI服务

  # 国内AI服务 (默认直连，如需走代理请取消注释并修改策略)
  # - DOMAIN-SUFFIX,deepseek.com,DIRECT
  # - DOMAIN-SUFFIX,yiyan.baidu.com,DIRECT
  # - DOMAIN-SUFFIX,tongyi.aliyun.com,DIRECT
  # - DOMAIN-SUFFIX,doubao.com,DIRECT
  # - DOMAIN-SUFFIX,chatglm.cn,DIRECT
  # - DOMAIN-SUFFIX,xinghuo.xfyun.cn,DIRECT
  # - DOMAIN-SUFFIX,kimi.moonshot.cn,DIRECT
  # - DOMAIN-SUFFIX,yuanbao.tencent.com,DIRECT

  # ===== 4. 流媒体走代理 =====
  - DOMAIN-KEYWORD,youtube,🎬 流媒体
  - DOMAIN-KEYWORD,netflix,🎬 流媒体
  - DOMAIN-KEYWORD,disney,🎬 流媒体
  - DOMAIN-KEYWORD,hbo,🎬 流媒体
  - DOMAIN-KEYWORD,hulu,🎬 流媒体
  - DOMAIN-KEYWORD,spotify,🎬 流媒体
  - DOMAIN-KEYWORD,twitch,🎬 流媒体
  - DOMAIN-SUFFIX,googlevideo.com,🎬 流媒体
  - DOMAIN-SUFFIX,ytimg.com,🎬 流媒体
  - DOMAIN-SUFFIX,ggpht.com,🎬 流媒体
  - DOMAIN-SUFFIX,fastly.com,🎬 流媒体

  # ===== 5. 其他常用国外服务走代理 =====
  - DOMAIN-KEYWORD,github,🚀 节点选择
  - DOMAIN-SUFFIX,github.com,🚀 节点选择
  - DOMAIN-SUFFIX,github.io,🚀 节点选择
  - DOMAIN-SUFFIX,githubassets.com,🚀 节点选择
  - DOMAIN-SUFFIX,githubusercontent.com,🚀 节点选择
  - DOMAIN-KEYWORD,google,🚀 节点选择
  - DOMAIN-KEYWORD,twitter,🚀 节点选择
  - DOMAIN-KEYWORD,facebook,🚀 节点选择
  - DOMAIN-KEYWORD,instagram,🚀 节点选择
  - DOMAIN-KEYWORD,reddit,🚀 节点选择
  - DOMAIN-KEYWORD,telegram,🚀 节点选择
  - DOMAIN-KEYWORD,whatsapp,🚀 节点选择
  - DOMAIN-KEYWORD,zoom,🚀 节点选择
  - DOMAIN-KEYWORD,slack,🚀 节点选择
  - DOMAIN-KEYWORD,notion,🚀 节点选择

  # ===== 6. 最终兜底规则 =====
  # 所有未被上述规则匹配的流量，默认走代理节点
  - MATCH,🚀 节点选择

然后，在clash的订阅这里，新建、Local、随便起个名字，再上传刚刚准备好的订阅conf.yaml配置文件

然后，点击上图的保存按钮，再右键使用之，就订阅好了

而后开启代理

在clash里面也能看到我们的ip已经变成了新加坡了

至此，VPN搞定完毕，就可以正常访问github，用谷歌搜索学习代码知识啦

2025 年 12 月 13 日，VeloxCon China 2025 在北京成功举办。作为 Velox 项目首次在中国举办的线下技术大会，汇聚了来自Meta、IBM、蚂蚁集团、阿里云、腾讯、小米、小红书等企业的数十位核心贡献者与一线工程师。

大会通过 18 场演讲将 Velox 置于真实业务场景之中，系统展示了其在架构演进、AI 数据处理、湖仓加速、流批融合等方向的最新实践。这些分享不仅直面性能、稳定性与兼容性等落地挑战，也反应了开发者社区对构建可靠、可扩展、可协同的数据基础设施的共同探索，彰显了中国开发者在全球高性能分析生态中的工程深度与协作广度。

夯实底座，突破能力边界
会议伊始，Velox 项目联合发起人 Pedro 发表开幕致辞。他回顾了 Velox 开源项目的发展历程，从项目启动、开源发布到建立技术治理结构，展示了 Axiom 架构、GPU 支持、PyVelox 等关键进展，强调了社区协作与工程严谨性是项目持续演进的核心动力。他特别提到，Velox 已建立了正式的技术治理机制，并迎来来自 IBM、Intel、NVIDIA、Microsoft 等多家企业的新增维护者，标志着项目正迈向更加开放和可持续的阶段。

在明确了社区与架构演进的总体方向后，大会议题迅速深入到如何利用 Velox 构建高性能计算引擎的具体实践中。阿里云 EMR Serverless Spark 技术负责人周克勇系统阐述了“可组合性”在数据计算领域的实践。他详细解析了阿里云如何深度集成并贡献于 Apache Celeborn、Paimon、Velox 及 Gluten 等开源组件，通过模块化组装构建出高性能湖仓一体引擎。他指出，基于该架构，阿里云 EMR Serverless Spark 成功创造了 TPC-DS 100TB 规模性能测试的世界新纪录，实现性能翻倍与性价比大幅提升。

接着，Meta 软件工程师 Masha Basmanova 阐述了现有查询引擎在跨语言通信、优化器能力与开发体验上面临的挑战，并介绍了基于 C++ 的统一前端框架 Axiom。该框架将 SQL 解析、逻辑优化与物理执行融为一体，通过内置的强大优化器与 Velox 运行时无缝对接，能够实现更高效、可扩展的查询处理。演讲最后，她积极展示了 Axiom 的开源路线图，并欢迎全球开发者加入，共同推动该项目的演进。

强大的执行框架，最终需要服务于极具挑战性的数据场景，特别是爆发式增长的 AI 数据。Meta 软件工程师孟晓烜则在之后的演讲中，深入阐述了应对AI训练数据规模激增与成本挑战的解决方案。他重点介绍了 Meta 如何通过数据归一化技术剥离重复特征，并构建可索引的序列存储系统。依托 Velox 技术栈，团队在训练数据的加载、生成与探索三大环节实现了端到端优化，显著提升了处理效率与资源利用率。

在 Meta 多位工程师从框架演进、可组合架构、数据标准化等角度深入分享后，蚂蚁集团高级技术专家黄叶伟也从企业落地实践层面分享了基于 Velox 的 Spark 加速实践。他重点介绍了基于 Gluten 与 Velox 构建的向量化引擎如何通过任务级 Fallback、Spill 优化、Shuffle 优化等关键技术，在混合部署场景下显著提升 Spark 性能与稳定性。他表示，该方案目前已实现日均数十万任务覆盖，平均节省资源超30%，并将在算子优化与架构扩展方面持续演进。

作为连接 Spark 生态与原生加速的关键中间层，Apache Gluten 的进展同样备受关注。来自 IBM 的莫芮与周渊聚焦 Apache Gluten与 Velox 的深度集成，阐述了其如何在大数据分析中驱动创新。他们介绍，Gluten 在保持对 Spark/Flink 作业透明加速能力的同时，正逐步增强对多后端引擎和复杂业务场景的适配能力。目前，该方案已在 Pinterest、顺丰科技及多个内部集群完成规模化验证，有效支撑了从日志分析到物流调度等多样化负载的性能提升与成本优化。

随着向量化加速在通用场景日趋成熟，针对特定存储格式的深度优化成为新的效能突破口。腾讯大数据开发工程师陈锦海分享了微信基于 Velox 加速 lceberg 湖仓分析的优化与实践，重点介绍了原生分桶方案。据他介绍，该方案通过动态识别表元信息自动设置分区数，能有效缓解 AQE 引发的写入倾斜，结合空闲资源灰度发布策略，可保障大规模作业的稳定上线。

扎根场景，释放协同效能
午餐后的议程更加聚焦 Velox 在真实业务中的集成深度与生产韧性，回应了开发者们对兼容性、稳定性与端到端效能等规模化落地的核心关切。
小米计算平台计算引擎负责人王胜杰分享了公司在 Spark 向量化升级中的规模化落地经验。面对业务迁移中的兼容性与稳定性挑战，他表示，小米通过自动兼容校验、双跑结果比对及内存异常感知的三级资源升级机制，已成功推动向量化改造在数十万作业中平稳落地。

面对海量数据挑战，全球科技公司也在探索相似的演进路径。Meta 软件工程经理 Stanley Yao 在演讲中分享了公司基于 Velox 推进 Spark 向量化改造的整体策略。他表示，团队通过从定制化方案到开源架构的持续演进，已实现关键业务管线向 Gluten（Flare）的平稳迁移，并获得显著的效率提升。未来，Meta 计划进一步扩大该架构的应用规模。

在 CPU 向量化趋于普及的同时，利用异构硬件挖掘更高性能成为新的前沿。IBM 研究院资深软件工程师 Zoltán Arnold Nagy 展示了基于 Velox 与 Presto 的 GPU 加速数据处理方案。他介绍道，Velox 通过与 cuDF 集成，可在 GPU 上高效执行算⼦，并针对多 GPU 分布式场景优化通信与数据交换。此外，为突破 I/O 瓶颈，团队正在探索结合 GPUDirect 存储与缓存层的加速策略。

对性能与稳定性的追求，也驱动着查询引擎架构本身的融合与创新。Meta 软件工程师谭家梁与大家分享了 Native Presto-on-Spark 的规模化应用。该架构以 Presto 查询优化、Spark 资源调度与容错机制以及 Velox 原生向量化执行为核心，实现了性能与可靠性的显著提升。他表示，目前该方案已在生产环境中取得成效，并将在未来持续推进全栈原生化演进。

对于国内庞大的云上业务，Velox 同样在支撑着关键数据服务平台。 阿里云高级工程师王彬与范阿冬系统介绍了Velox在阿里云日志服务中的深度集成与应用。他们指出，基于 Velox 构建的高性能查询引擎，通过混合执行、表达式下推、自动增量物化视图及免 Schema 分析等核心技术，可显著提升平台在处理海量实时数据时的查询效率与资源利用率。他们还强调，该架构不仅为日志分析、智能运维等场景提供了稳定支撑，也为面向 AI 的云原生数据平台演进奠定了坚实基础。

除了通用的日志与湖仓分析，Velox 也在向更垂直的时序数据场景渗透。腾讯高级工程师李兆龙分享了基于 Velox 构建云原生时序数据库的落地经验。他表示，通过在 Velox 中实现时序数据去重优化与存储写入增强，系统在应对高频写入与实时查询场景时，可显著提升吞吐效率与响应性能。目前该方案已有效支持物联网、实时监控等业务场景，未来还将进一步完善缓存与压缩机制，持续优化时序数据处理的整体效能。

IBM 软件工程师刘平接着分享了 Velox 在 Iceberg 数据写入能力上的突破性进展。他表示，目前 Velox 对 Iceberg 的支持以读取为主，其写入功能的完善将填补该方向的关键能力空白，为基于 Presto 与 Spark 的数据湖架构提供更统一、高效的数据摄入层。这一进展也标志着 Velox 正从查询加速向数据全链路处理拓展。

接着，来自阿里云的毕岩与周滔分享了 Velox 与 Apache Paimon 深度集成的解决方案，为提升引擎与存储的协同效率提供了另一种集成思路。在他们看来，现有方案存在表类型支持受限、缺乏可移植性等瓶颈， 但可以建立 C++ 原生 Paimon 库，通过其统一的数据协议与插件化设计，使 Paimon 能够被 Velox、StarRocks 等多种计算引擎直接高效调用，从而提升数据读写性能，并为湖仓格式的跨引擎协同提供新的基础支撑。

在批处理场景之外，流计算框架的向量化也正成为新的热点。蚂蚁集团技术专家刘勇介绍了基于 Velox 为 Flink 构建的统一向量化执行引擎 Flex。他表示，Flink 作为流批一体架构的核心，其原生向量化能力的补足至关重要。Flex 通过将 Velox 的高性能算子能力引入 Flink，同时结合自动化验证、可视化计划与精细化回退机制，现已实现了作业性能的显著提升，并支撑多条核心业务链路平稳运行。

随着 Velox 赋能的应用场景日益广泛和复杂，确保其在不同引擎和版本间的整体质量与可靠性变得至关重要。Meta 软件工程师 Eric Liu 阐述了在 AI 数据基础架构下，保障 Velox 多引擎版本可靠性的系统化方法。他指出，面对不同引擎与存储格式交织带来的复杂性，关键在于建立跨引擎测试框架与合成数据工厂。这一实践能有效提前发现全栈潜在问题，从而确保底层变更在大规模生产环境中的稳定与高效。

针对向量化引擎中窗口运算符内存溢出的典型难题，来自英特尔的贾柯分享了她的见解。她认为，通过为 Velox 引入流式窗口处理机制，可使计算随数据到达逐步执行并即时释放内存，从而从架构层面化解多数场景下的内存风险，显著提升复杂查询的稳定性。

最后，小红书 Native Engine 团队技术负责人魏秀利也分享了向量化引擎在公司业务中规模化落地的经验。据他介绍，通过将写入异步化并构建原生 Avro 读取能力，小红书在不增加业务复杂度的前提下，成功缓解了端到端延迟，印证了“执行与存储协同优化”在湖仓场景中的关键价值。

从底层执行引擎的持续创新，到日志分析、湖仓写入、流批融合等复杂场景的稳定运行，在本届 VeloxCon China 上，我们看到 Velox 的技术价值已在真实业务中不断被验证和拓展。同时我们也很高兴看到中国开发者成为这一进程的重要推动者。期待未来有更多志同道合者加入 Velox 开源社区，共建高性能分析基础设施。weibo.com/ttarticle/p/show?id=2309405290320475848730 weibo.com/ttarticle/p/show?id=2309405290320828432386 weibo.com/ttarticle/p/show?id=2309405290321235017780 weibo.com/ttarticle/p/show?id=2309405290427158233202 weibo.com/ttarticle/p/show?id=2309405290427510292586 weibo.com/ttarticle/p/show?id=2309405290427867070839 weibo.com/ttarticle/p/show?id=2309405290428219129971 weibo.com/ttarticle/p/show?id=2309405290428571451429 weibo.com/ttarticle/p/show?id=2309405290429099933759

随着工业4.0与智能制造的深入推进，设备维护模式正经历从传统的事后维修与预防性维护向预测性维护的范式转移。本文阐述万界星空AI驱动预测性维护的技术原理、架构体系及实施路径，通过多源数据融合与深度学习算法，解决传统维护模式中成本高、效率低、响应滞后的痛点，为企业构建可量化、可落地的设备健康管理体系提供理论依据与实践指导。
传统维护模式的局限性与挑战
在当前的工业制造场景中，设备的高可用性是保障产能与交付的核心。然而，传统维护策略普遍面临“三缺”困境：缺数据、缺预判、缺效率。

事后维修模式依赖于设备功能失效后的被动响应。据行业统计，非计划停机造成的生产损失往往是常规维护成本的数倍，且突发故障常引发连锁反应，导致核心部件不可逆损坏。预防性维护虽引入了周期性干预机制，但基于固定时间表的维护策略忽视了设备实际工况（如负载、环境、磨损速率）的差异性，导致“过度维护”造成的资源浪费与“维护不足”引发的漏检风险并存。

预测性维护的技术解构：数据驱动的科学范式
预测性维护并非基于经验的模糊预测，而是建立在严密的数学逻辑与工程实践基础上的科学体系。其核心在于利用物理感知与数字算法的深度融合，实现设备全生命周期的状态感知与趋势预判。

多维感知与数据治理
高精度预测的前提是全维度的状态感知。系统通过部署工业物联网传感器，采集振动、温度、电流、压力等关键物理量。其中，高频振动数据（采样率可达10kHz以上）能够捕捉轴承、齿轮等旋转部件的早期微弱故障特征。同时，系统需融合环境数据（温湿度、粉尘）、工艺参数（转速、负载）及历史运维记录，构建多源异构数据湖，为算法模型提供高质量的训练样本。

算法模型与特征工程
预测性维护的“大脑”由多层次算法构成：
信号处理层： 利用快速傅里叶变换、小波变换等技术，将时域信号转换为频域特征，精准提取故障特征频率。
机器学习层： 采用随机森林、支持向量机等算法，对已知故障模式进行分类识别；利用孤立森林等无监督学习算法进行异常检测，识别未知故障。
深度学习层： 运用长短期记忆网络、卷积神经网络等模型处理时序数据，捕捉设备性能退化的长期依赖关系，实现剩余使用寿命的精准预测，误差可控制在15%以内。

实施路径：从单点突破到体系化闭环
企业落地预测性维护需遵循“评估-建设-建模-验证-推广-管理”的六步法，确保技术投入转化为实际生产力。

现状评估与优先级划分
依据设备关键度（故障对生产的影响）、维修复杂度及数据基础，建立设备分级矩阵。优先选择高价值、高故障率的瓶颈设备（如关键机床、风机）作为切入点。

数据底座建设
构建“端-边-云”协同的基础设施。边缘计算节点负责高频数据的实时清洗与初步推理，降低云端传输延迟；云端平台负责海量数据存储、模型训练与全局管理。

场景化建模与验证
采用“小步快跑”策略，选取典型设备进行试点。通过历史故障数据回溯训练，设定故障预警准确率、提前期等关键指标，验证模型在实际工况下的鲁棒性。

管理体系重构
技术落地必须伴随管理流程的变革。建立“预警-派单-维修-反馈”的闭环工作流，将预测结果直接转化为可执行的工单，并纳入绩效考核，实现从“人找故障”到“故障找人”的转变。

价值验证与行业实践
实证数据显示，成熟的预测性维护体系可显著优化运营指标。在某汽车零部件制造案例中，通过部署振动监测与LSTM寿命预测模型，企业实现了非计划停机时间减少65%，设备综合效率提升17%，年均维护成本降低近40%。在钢铁行业，针对高炉风机的预测性维护系统通过融合工艺与振动数据，实现了连续两年无非计划停机，避免了数亿元的潜在停产损失。

结语
AI驱动的预测性维护是工业设备管理从经验主义向数据主义转型的必然产物。它摒弃了“黑箱”式的玄学猜测，代之以透明、可解释、可验证的技术路径。对于制造企业而言，构建这一体系不仅是技术升级，更是重塑核心竞争力的战略选择。