DPP依赖于算法平台的引擎服务（FeatureServer，召回引擎, 精排打分），提供“开箱即用”的召回，粗排，精排服务。采用“热加载技术”解决算法平台的工程和算法同学策略迭代效率问题，支持策略随时发布，让他们可以专注于业务逻辑，即可拥有稳定的推荐在线服务。
很高兴与大家分享现阶段 Cursor 在我的工作中的使用体验。首先是预期管理，本篇文章不会分享 x 个你可能不知道的小技巧，也不会让你拥有无需自行编码的能力，同时不涉及 Cursor 工程化方面内容。仅仅是围绕个人开发流程中的已有问题，分享如何使用 Cursor 来提升这部分的开发体验，在工作中持续保持好的节奏和状态。
得物一直重视用户体验，尤其是启动时长这一重要指标。在近期的启动时长跟进中，我们发现了在BuildingClosure 阶段的一个优化方式，成功的帮助我们降低了 1/5 的 BuildingClosure 阶段的启动耗时。Building Closure 并非工程的编译阶段（虽然它有一个building），Building Closure 是应用初次启动时会经历的阶段，因此它会影响应用的启动时长。 单就BuildingClosure阶段而言，我们观察到该阶段其中一个函数从 480ms 暴增到 1200ms 左右（PC 电脑端运行 dyld 调试统计耗时数据），我们通过优化，将耗时从1200ms降低到110ms。即使相比最开始的情况，也相当于从480ms降低到了110ms，由此可见Building Closure 优化是应用进行启动优化必不可少的一个重要手段。因此在这里我们也和各位读者进行分享，期望能够对各自项目有所帮助。
在经典的CAP理论中一致性是指分布式或多副本系统中数据在任一时刻均保持逻辑与物理状态的统一，这是确保业务逻辑正确性和系统可靠性的核心要素。在单体应用单一数据库中可以直接通过本地事务(ACID)保证数据的强一致性。 然而随着微服务架构的普及和业务场景的复杂化，原来的原子性操作会随着系统拆分而无法保障原子性从而产生一致性问题，但业务实际又需要保障一致性，为此BASE理论提出了最终一致性来解决这类问题。那么如何在跨服务、跨数据库的事务中保证数据最终一致性。
从2022年12月份OpenAI发布ChatGPT产品至今已有2年多的时间，当大家已经习惯于在对话框中与AI交互，习惯于通过各种Prompt技巧让AI更好的理解并回答我们的问题，似乎默认这就是一种比较好与AI的交互方式了。 然而，这就是我们期盼的与AI交互的形式嘛？这是一种高效的方式嘛？ 显然，这是不够的。 我们期望的是：告诉AI我们想要的目标或者任务，AI能够理解深度理解并分析我们的意图、自动的进行任务的拆解、自动的寻找可以使用的工具、自动的进行结果数据的汇总过滤、自动的呈现符合任务的展示形式。同时在任务处理过程中，可以自己完成异常的检测和修改。就如同一位优秀的同学，我们告诉他任务的目标，他可以自己寻找飞书文档、搜索网络知识、使用内部系统、自己编码验证方案可行性，并最终给一份好的解决方案。
在得物技术生态的核心地带，算法作为核心技术力量的中流砥柱，承担着推荐系统、搜索算法、AI 查验鉴别和图像识别等多个前沿且关键领域的研发重任。随着业务的快速扩展和技术的不断迭代，项目管理的重要性日益凸显。如何高效地管理算法项目，确保团队在快速变化的环境中保持高产出和高创新力，成为了我们面临的核心挑战。本文将分享得物技术部算法团队在项目管理进阶过程中的经验与思考。
我们先来探讨一个核心概念：稳定性 。想象一下，一个系统、一个物体或一个过程在受到外部干扰或内部变化时，能否如一面坚实的墙壁，屹立不倒？在信息系统的世界里，稳定性的定义就如同这面的墙壁，它确保在各种干扰面前，我们服务依旧保持可用。 然而，尽管这个定义听上去很清晰，若要用它来推动我们的稳定性建设，却显得有些模糊。因此，我们需要深入探讨如何将这一概念转化为切实可行的方法论。 我们将方法论定义为影响结果的公式，并为稳定性写下了如下公式： 稳定性 = 全局风险可见性 * 风险转化概率 * 故障可感知 * 预案可靠性 但随着实践经验的增长，再对上述公式因子进行正交分析后，我发现稳定性其实可以简化为： 稳定性 = 系统风险(概率) * 风险应对能力
通过修复历史遗留的Crash漏报问题（包括端侧SDK采集的兼容性优化及Crash平台的数据消费机制完善），得物Android端的Crash监控体系得到显著增强，使得历史Crash数据的完整捕获能力得到系统性改善，相应Crash指标也有所上升，经过架构以及各团队的共同努力下，崩溃率已从最高的万2降至目前的万1.1到万1.5，其中疑难问题占比约90%、因系统bug导致的Crash占比约40%，在本文中将简要介绍一些较典型的系统Crash的治理过程。
随着得物离线业务的快速增长，为了脱离全托管服务的一些限制和享受技术发展带来的成本优化，公司提出了大数据Galaxy开源演进项目，将离线业务从全托管且封闭的环境迁移到一个开源且自主可控的生态系统中，而离线开发治理套件是Galaxy自研体系中一个核心的项目，在数据开发IDE中最核心的就是SQL编辑器，我们需要一个SQL解析引擎在SQL编辑提供适配得物自研Spark引擎的语法定义，实时语法解析，语法补全，语法校验等能力，结合业内dataworks和dataphin的实践，我们最终选用ANTLR作为SQL解析引擎底座。
LSM-Tree（Log-Structured Merge Tree）是一种高效的键值存储数据结构，广泛应用于NoSQL数据库和大数据处理系统中。其核心思想是通过分层、有序地利用磁盘顺序写入的性能优势，优化写入操作，同时牺牲部分读取性能以换取更高的写入吞吐量。
