首页 文章 精选 留言 我的

精选列表

搜索[三大系统],共10000篇文章
优秀的个人博客,低调大师

Skyeye 云智能制造办公系统低代码框架 - Saas v3.17.8 发布

Skyeye 云智能制造,智能制造一体化,采用 SpringBoot+ UNI-APP + Ant Design Vue 的低代码平台开发模式。包含 50 多种电子流程,CRM、PM、ERP、MES、ADM、OA、EHR、AI、项目、商城、财务、多班次考勤、薪资、招聘、云售后、论坛、问卷、报表设计、工作流、Saas 等功能。打造全网首套低代码、功能最全的智能制造行业供应链一体化管理软件 官方网站 开发文档 视频教程 功能点 Skyeye云【源代码】针对 {Skyeye 会员} 开源。拿到源码后可进行学习、毕设、企业等使用。 Skyeye 云智能制造 v3.17.8 发布 ,发布内容如下: Skyeye 云已加入 Dromara 社区 业务对象适配 Saas 进展 100% VUE 版开发 生命周期管理绑定到业务对象完成 表格布局新增列的链接配置功能 所有业务对象支持流程信息的配置 移动端布局页面适配生命周期 统一接口权限管控适配到业务对象 修复上个版本得 bug 新增React版本项目,用于开发React语言得 Skyeye 云管理端 源代码只对 Skyeye 会员开放 Skyeye 具备低代码、快捷开发、可视化设计、微服务等特点,方便客户二次开发,极大的提高了开发效率。 项目地址: Gitee: https://gitee.com/doc_wei01/skyeye https://gitee.com/dromara/skyeye GitCode: https://gitcode.com/doc_wei/erp-pro https://gitcode.com/doc_wei/skyeye-oa PC 端效果图 效果图 效果图 移动端效果图 效果图 效果图 效果图 效果图

优秀的个人博客,低调大师

社区搜索离线回溯系统设计:架构、挑战与性能优化|得物技术

一、项目背景 在社区场景中,我们积累了丰富的用户互动数据。这些历史互动信息对CTR/CVR预估建模具有重要参考价值,用户的每次互动都反映了其特定维度的偏好特征。当前,已在多个业务实践中验证,基于用户历史互动特征进行未来行为预测是有效的。用户互动序列越长,包含的偏好特征就越丰富,但同时也带来了更大的技术挑战。 目前社区搜索领域已经在序列建模方向取得了一些应用成果,显著提升了搜索效率,但在该方向上仍有优化空间,主要体现在: 算法精排模型现状:长周期的用户互动特征尚未被充分利用,现有模型仅使用了基础标识信息,泛化能力有待提升。我们计划引入SIM方案来增强个性化序列建模能力,推动搜索效率提升。 迭代效率优化:当前互动特征优化依赖于实时数据采集链路,新增特征需要长时间数据积累(2个月以上)才能验证效果。我们计划建设用户特征离线回溯服务,降低算法优化对实时数据的依赖,加快项目迭代速度,提高实验效率。 离线回溯主要解决迭代效率问题,本文重点探讨在社区搜索场景下开发离线回溯,并做离线一致性验证过程中发现的一些问题,针对这些问题做了哪些优化措施及思考。 二、架构设计 全局架构 序列产出流程链路 ※ 在线流程链路 在线链路通过实时数仓提供全量表和实时流两种数据源,在特征平台下构建1w长度的实时用户画像,召回阶段SP,将画像传给SIM引擎,在引擎中完成对用户序列hard/soft search等异步加工,最终传给Nuroe,完成在线序列dump落表。 ※ 离线流程链路 离线链路通过仿真在线的处理逻辑,利用请求pv表和离线数仓提供的10w原始序列,模拟在线序列10w->1w->100的过程,最终产出离线回溯序列。 最终通过在线/离线全链路数据的一致性验证,确认全流程数据无diff(或diff可解释),序列流程可靠性达标,可交付算法团队用于模型训练。 序列产出全局架构 在线架构 在线侧抽象GSU模块支持社区搜索和增长搜索等多场景复用。该模块在QP(Query Processing)阶段后,通过外调基于DSearch构建的SIM引擎进行用户序列处理。SIM引擎内完成hard/soft search等用户序列加工,在精排阶段前获取topk序列特征及对应sideinfo,并将其透传给精排模块,最终实现用户序列的落表存储。 在线通用GSU模块 离线链路 数据产出三阶段 ※ 原始序列预处理阶段 通过收集一个用户,按照 [月初ts+1w, 月末ts] 将序列进行预处理。 ※ pv表合并序列表阶段 按照user_id将画像和pv表合并,将每个request_id的数据按照request_time过滤处理。 ※ 用户序列加工阶段 完成hard/soft search等用户序列加工逻辑处理,包括对长期序列按照相似度过滤,对短期序列按照时间过滤等。 离线回溯链路图 三、问题与挑战 在离线回溯开发阶段,主要面临以下挑战。 挑战 ※ 任务执行问题 任务频繁失败或执行效率低下,数据规模达单表数TB级别,且序列分布不均,部分长尾用户序列过长导致严重数据倾斜; ※ 一致性校验阶段问题 异常类型复杂多样,累计发现25+种异常原因,导致数据diff形态复杂,一致性原因分析困难。修复链路冗长,涉及问题修复、在线索引重建、数据累计和离线数据回补,单次修复周期约需一周。 四、从踩雷到填坑的实战记录 离线任务运行耗时长的问题 问题说明 初步方案运行时存在两大问题: 1.任务处理延迟显著,单个任务运行3-8小时。 2.任务处理无法运行成功频繁OOM。 任务执行慢 任务频繁OOM 解决方案 ※ 方案优化 任务执行慢主要是有长尾用户打满10w长序列,出现数据倾斜问题甚至oom。 通过对链路优化,先将原始10w长序列做预处理,由于回溯一般按照一个月跑数据,可以利用pv表先统计有哪些有效用户,对有效用户按照 【月初ts+1w, 月末ts】截取原始序列,获取相对较短的预处理队列。 任务倾斜 原始序列预处理 ※ ODPS任务性能调优 a. 按照CPU :MEM=1 : 4 调整计算和存储的比例,可以最大化利用资源,因为我们申请的资源池都是按照这个固定比例来的。 资源没有最大化使用 b. 在固化计算/存储比例参数后,可以通过xxx.split.size 和 xxx.num 共同调优。xxx.split.size可以实现输入分片大小,减少oom机会。xxx.num可以实现扩大并发数,加快任务的执行(xxx代表mapper、reducer、joiner几个阶段)。 分批次完成阶段处理 c. 减少自定义UDF使用。在离线任务中有部分逻辑比较复杂,可能需要数据平铺、聚合、再内置函数等。最好的使用原则是内置函数>“数据平铺+内置函数”>自定义UDF。由于自定义UDF运行在Java沙箱环境中,需通过多层抽象层 (序列化/反序列化、类型转换),测试发现大数据量处理过程性能相对最差。 一致性验证归因难的问题 问题说明 在线/离线全链路数据的一致性验证过程中,由于按照天级全量dump序列,需要验证15个序列,每个序列diff量在10w~50w不等,这种多序列大规模的diff问题人工核验效率太慢。 解决方案 ※ 整体diff率分析 通过统计全序列diff率并聚类分析高diff样本,定位共性根因,实现以点带面的高效问题修复。 ※ diff归因工具 通过建立数据diff的归因分类体系(如排序不稳定、特征穿越等),并标注标准化归因码,实现对diff问题的快速定位与根因分析,显著提升排查效率。 归因码分类 ※ 重复度统计工具 由于在线受当时环境的影响,离线回溯无法100%复现原始序列,一致性差异在所难免。我们通过聚焦主要特征并统计其重复度,结合「diff率+重复度」双维度评估方案,为算法决策提供量化依据,有效减少无效迭代。 重复度统计 现状梳理不足的问题 问题说明 由于前期对业务场景理解不足(如用户行为模式、异常数据、测试账户等),部分潜在问题未在开发阶段充分识别,直至数据一致性验证时才集中暴露,导致需紧急调整数据处理逻辑。由于单次全链路修复需3-5天,进而对项目进度造成一定延迟。 问题case1:滑动图片:离线回溯数据分析时发现序列中大量重复且占比很高,后确定为滑动图片行为 解决方案:对滑动图片操作连续多次修改为只记录第一次 问题case2:合并下单:测试购买序列有id重复,实时数仓反馈购买有合并下单的情况,ts会相同 解决方案:为了保持离线回刷数据稳定性,将序列按照ts/id双维度排序 问题case3:异常数据:有行为时间戳超过当前时间的异常数据 解决方案:数仓对异常数据丢弃 问题case4:测试账户:数据不规范导致数据diff 解决方案:测试账户数据忽略 问题case5:query问题:取归一化后还是原始的query、空字符串问题 解决方案:query为空过滤修复 问题case6:数据穿越问题:画像原始数据request_time取neuron时间导致 解决方案:在线修改request_time获取时间,离线回溯前置3s 修复周期长的问题 问题说明 数据问题的完整修复流程包含三个阶段,全流程通常需要5-7个工作日完成。 ※ Diff归因阶段(1-3日) 需要定位数据差异的根本原因,区分是数据异常、处理逻辑错误还是业务规则变更导致 涉及多团队协作排查(数据/算法/工程) 复杂问题可能需要多次验证 ※ 问题修复阶段(1-3日) 根据归因结果修改代码逻辑或数据处理流程 可能涉及历史数据修正 ※ 数据迭代阶段(2-3日) 在线画像引擎部署新数据 累计在线数据 离线画像回补数据 解决方案 受限于初期人力投入,我们在当前方案基础上通过多轮版本迭代逐步完成数据一致性验证。后续将通过工具升级(数据边界划分+自动化校验框架)和数据采样策略,实现验证到修复的阶跃式提升。 ※ 数据边界划分 现行方案离线链路都是算法工程来维护,排查链路太长,需要数据源有稳定的保障机制。后续将划分数据边界,各团队维护并保障数据模块在离线的一致性。 数据边界划分 ※ 全链路采样方案减少验证时间 离在线一致性验证方面耗时较长,主要在于数据量太大,在数仓构建、特征平台构建、累计数据等流程消耗大量的时间,如果全链路先针对少量用户走通全链路,能快速验证流程可行性。 采样方案 平台基建的问题 问题说明 首次构建序列建模体系,由于缺乏标准化基础设施,被迫采用烟囱式开发模式,导致多链路验证复杂且问题频发。 平台待建能力 特征平台排序功能不足,只支持单一字段排序,不支持多字段联合排序,导致排序结果不稳定。 特征平台过滤功能限制,仅支持毫秒级时间戳过滤。 索引构建效率低,个性化行为序列表数据量过大(3TB),导致索引构建压力大,初始构建耗时约28小时。升级至FS3集群后,构建时间降至12小时左右,最短至7小时,但仍未达理想效率。 五、展望与总结 后续我们将深入研究行业内的优秀解决方案,并结合我们的业务特性进行有针对性的优化。 例如,我们会尝试实施离在线数据与逻辑一致性方案,这种方案包括以下几个特点: 数据一致性:离线与在线共用同一套原始画像,能够解决数据源不一致导致的差异问题。 逻辑一致性:离线与在线都调用GSU服务,实现统一的序列逻辑处理,避免逻辑差异。 技术架构复杂性:新方案带来了新的技术挑战,比如在线处理10万序列可能引发的I/O问题、离在线的sim引擎采用存算一体和存算分离架构。 综上,没有绝对完美的技术方案,最终都是在成本、性能和效率多方面权衡后的相对最优解。 离在线数据与逻辑一致性方案 本次特征回溯虽面临性能与数据对齐等挑战,但团队通过攻坚积累了经验,为特征平台后续特征回溯工具化打下基础,也期待能为后续算法模型迭代带来质的飞跃。 往期回顾 1.从 “卡顿” 到 “秒开”:外投首屏性能优化的 6 个实战锦囊|得物技术 2.从Rust模块化探索到DLB 2.0实践|得物技术 3.eBPF 助力 NAS 分钟级别 Pod 实例溯源|得物技术 4.正品库拍照PWA应用的实现与性能优化|得物技术 5.汇金资损防控体系建设及实践 | 得物技术 文 / 野雨 关注得物技术,每周更新技术干货 要是觉得文章对你有帮助的话,欢迎评论转发点赞~ 未经得物技术许可严禁转载,否则依法追究法律责任。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册