随着得物业务规模的不断增加，推荐业务也越来越复杂，对推荐系统也提出了更高的要求。我们于2022年下半年启动了DGraph的研发，DGraph是一个C++项目，目标是打造一个高效易用的推荐引擎。推荐场景的特点是表多、数据更新频繁、单次查询会涉及多张表。了解这些特点，对于推荐引擎的设计非常重要。通过阅读本文，希望能对大家了解推荐引擎有一定帮助。为什么叫DGraph？因为推荐场景主要是用x2i(KVV)表推荐为主，而x2i数据是图(Graph)的边，所以我们给得物的推荐引擎取名DGraph。
你会如何总结你的工作内容？ “CURD”，这是不少业务开发者对自己工作内容，做出的“哲学级别”总结，不乏调侃和乏味之意。实际上，过来人都清楚，这和业务开发面临的复杂性和挑战不在一个层次。 一般情况下，互联网核心业务可以大体分为两类，其一是基础功能性业务，其二是围绕基础功能，刺激增长类业务。以直播为例，可以分为： 核心功能类：如送礼打赏、PK连麦等互动消费业务。 增长类：通过精细化运营等方式，以刺激核心业务增长(消费)为核心目的，如营收活动。 业务开发的第一挑战在于决策与实施的割裂，决策端和实施端是完全不同的两拨人，在关注点、信息量、职业技能、工作方式等方面差异较大，在软件旺盛的迭代协作之下，保障边际生产力是个难点。 在此基础上，核心功能类业务很考验“第一个程序员”，业务迭代就像为飞行中的火箭更换零件，更难的在于下次要怎么换，目前还不一定清楚。
由于流量红利逐渐消退，越来越多的广告企业和从业者开始探索精细化营销的新路径，取代以往的全流量、粗放式的广告轰炸。精细化营销意味着要在数以亿计的人群中优选出那些最具潜力的目标受众，这无疑对提供基础引擎支持的数据仓库能力，提出了极大的技术挑战。 本篇内容将聚焦字节跳动OLAP引擎技术和落地经验，以字节跳动内部场景为例，具体拆解广告业务的实现逻辑和业务效果。
消费者在得物下单购买商品后，卖家不会直接发货给买家，而是先发货给得物，由得物鉴别师团队对商品进行真伪鉴别和瑕疵查验分级，确保是全新正品之后，才会发货给消费者。全流程由得物技术提供的系统能力支撑运作。
在本文中，我们将介绍如何使用自动生成代码工具来解决前端开发中的重复性工作和效率问题。我们将从获取接口文档和项目信息开始，然后介绍如何区分不同类型的项目，并生成相关的关联对象。接着，我们将介绍如何使用自动生成代码工具来生成 ts 定义、页面代码、service 定义等，以及如何将这些代码结合起来并输出到对应页面路径。最后，我们将介绍如何统计项目生成的代码信息，以便于更好地了解项目开发状况和提高开发效率。目前我们已经在业务线陆续接入，包含后台和微信小程序已经有7个项目，生成代码行数五万行加。
