美团

本文整顿自美团技术沙龙第77期《美团亿级流量零碎的品质危险防控和稳定性治理实际》，次要介绍了对网络返回数据进行变异的客户端健壮性测试实践经验。文章第一局部介绍客户端健壮性测试的基本概念；第二局部分享了基于接口返回数据变异的App健壮性测试方案设计的思路；第三局部次要解读了变异数据的结构和异样检测方案设计；第四局部介绍了精简变异数据的摸索计划。01 什么是客户端健壮性在维基百科的定义中，健壮性（Robustness）是指一个计算机系统在执行过程中处理错误，以及算法在遭逢输出、运算等异样时持续失常运行的能力。IEEE中将健壮性定义为零碎或组件在存在有效输出或压力环境条件下能够失常运行的水平。早在1989年，Barton Miller首次提出了含糊测试的概念，通过向指标利用抛出随机字符串的形式来测试UNIX应用程序的健壮性；而在1996年的Ballista我的项目中，钻研人员摸索依据API定义的数据类型，对操作系统或软件接口进行自动化测试方法。两个我的项目均以“无应用程序解体或挂起”作为测试验证通过的规范。 在挪动端App畛域，健壮性能够了解为App运行时遭逢环境异常或者输出异样时客户端可能持续失常运行的能力。 其中，环境异常次要分为操作系统异样、外部环境异样、硬件环境异常三大类。比方内存不足、CPU负载过高、线程池满载、内存调配失败、网络连接失败等。输出异样次要分为零碎输出和用户输出。比方网络接口返回的数据异样、利用内缓存、数据库文件读写异样，这类的异样属于在零碎输出异样；在电话号码输入框场景，用户输出的空格、富文本则属于用户输出异样。 对于这些危险，如果App没有解决，实践上都可能会产生展现异样、交互异样、性能、平安等问题，导致用户无奈持续应用或在应用过程中产生不好的体验。比方用户操作App下单过程中，API申请呈现故障未返回状态码为200的响应，App因为没有获取到预期接口响应的信息而产生解体，就会中断用户的应用流程。 02 基于接口数据变异的App健壮性测试方案设计在理论的客户端测试执行过程中，测试人员会思考测试异样输出的场景，但因为老本无奈做到无穷尽的测试，同时还存在人工执行脱漏的危险。 从美团App平台业务的历史故障剖析中，咱们发现：网络申请返回的数据与实现预期不符引发的Crash或外围性能缺失问题导致的故障占比最高，且影响面较广。比方接口返回非预期数据时，客户端解决数据类型转换异样导致闪退，即便5分钟内操作降级仍影响了百万量级的用户。因而美团平台业务App的健壮性测试摸索优先从发现网络申请返回数据导致的异样开始。 针对于发现申请接口返回客户端非预期数据导致的Crash，或者外围模块缺失问题这个诉求，咱们调研后发现计划的基本原理都是类似的，即以网络申请的原始响应为根底，依据规定进行变异结构，应用代理工具改写响应体返回给客户端，在端上设施做异样检测。然而都存在一些问题不能满足诉求，比方测试变异数据是依据预置或者自定义规定随机生成组合，随机性过大，不能无效拦挡健壮性问题；但如果不做随机，产生的用例组合量过大，测试不能在正当工夫范畴内完结；另外在检测能力方面，不具备发现业务异样或功能模块异样的能力。 因而，咱们联合通用计划做了一些自定义革新，整体检测计划蕴含动态检测和动静检测两局部。 动态检测，次要是指动态代码扫描，将典型代码编写标准问题转化为自定义动态代码扫描规定，管控增量代码，同时长期治理存量危险。比方自定义了PrimitiveParseDetector、ColorParseDetector，管控业务必须应用健壮性测试通过的工具类。动静检测是指联合触发机会，结构并注入变异数据后，辨认App运行时是否呈现解体、挂起或业务功能模块异样。比方在集成事件/回归事件触发自动化测试运行，结构触发异样的数据进行动静测试，而后监测是否呈现了异样。外围动作蕴含结构变异数据和实现检测两局部。比方将接口响应体中示意色彩含意的Key对应的Value值结构成非色值，而后检测客户端申请解决接口数据时是否呈现解体或挂起。下文重点介绍端到端的动静检测计划。 03 变异数据的结构和异样检测对于美团App来说，首页有多种状态，对于某种特定状态，除了管制申请数据外还须要管制试验、策略等一系列因素，能力保障测试对象的唯一性。一个页面中蕴含多个异步申请，因而申请的结构也须要和页面门路关联。这些都是采集变异所需的根底数据时须要关注和管制的。 响应体由根本类型数据和复合类型数据组成，雷同根本类型的数据可能具备不同的业务语义，须要依据语义的类型做变异规定的辨别看待，能力保障业务场景笼罩。 因而，如何保障变异数据结构的全面性和准确性，是咱们面临的首要挑战。 要解决数据结构全面性问题，首先要解决页面形容计划，这样能力管制获取根底数据的唯一性。在解决方案中，咱们构建了页面形容的特色规定，解决用户视角的页面标识问题。须要的信息蕴含端信息、页面路由信息、试验策略账号信息、页面标识模块合集等。通过页面申请数据主动录制的形式，自动更新迭代申请数据和页面之间的绑定关系，使得根底数据可能随需要迭代更新，从而通过变异规定结构生成的用例也可能自动更新。 在用例变异生成结构上，对于响应体里的Value设置了语义匹配规定，比方字符串的语义可能代表色彩、页面跳转路由、动动态资源链接（即图片资源数据/视频文件/GIF文件），须要辨别特色别离按语义结构异样数据。比方在图片的变异数据结构里，除了须要结构非图片链接状况外，还要思考不同图片格式、非图片格式以及非非法的图片剪裁格局拼接等场景。 咱们对接口返回数据应用脚本做了初步的语义剖析，人工二次校对后建设了根本数据类型和语义的映射汇合，联合根本数据类型边界值和语义定义了初始的变异规定。而后对历史的线上健壮性问题和线下测试发现的健壮性Bug的变异数据进行整顿，作为增补的变异规定。 在自动化测试执行过程中，咱们基于App可测性革新提供的能力，对测试场景进行了管制，同时基于布局视图的解析SDK、App异样上报SDK提供的能力，实现了对App异样的通用检测。 04 变异数据的精简计划随同着变异规定的丰盛，主动生成的数据量级是微小的，数据的变异组合如果依照全笼罩形式来生成组合数量就是指数级增长。比方对于1种有7种变异取值的变量，如果存在n个此类型变量，就会产生7^n种数据组合，并且在理论业务场景中很多组合状况是没有意义的。 如何在保障用例结构全面性的状况下精简变异结构的用例数，是咱们面临的第二个挑战。解决方案蕴含2个策略：1）数组元素构造统一时，删减结构的用例数；2）构造不完全一致的数组元素，引入编辑间隔和并查集算法判断节点相似性，节点不类似，能够在一次数据生成里做合并结构。 咱们能够把申请响应的JSON了解成树，第一个解决思路是判断树中节点、门路的类似度，类似节点删减结构。 如果门路、节点类似，能够揣测门路即业务逻辑也是统一的，比方页面上的一些列表元素，可能是数据结构对象完全一致数组，如果对每个数组对象中的每个元素进行全用例结构，生成的变异数据量极大，且对业务场景或代码逻辑的增量笼罩无限，因而咱们决定将结构逻辑优化，进行删减结构。即如果数组中元素的构造完全一致，那么同含意的字段能够为他们调配不同的变异结构值，而后删减掉有效的结构状况。利用这种办法能够无效升高28%左右的用例结构数量。 如图数组的3个元素中均存在“resourceName”键值对，如果每个键值对有3种变异取值，依照全排列形式进行用例结构将会生成有9份变异数据，在删减结构状况下，能够别离为它们结构一个特定的变异值，这样变异生成用例数量能够从9缩小为1。 在对业务接口返回数据的数据结构进行剖析后，咱们发现在层级越深的场景下，间隔根节点越近的两个节点，业务逻辑耦合和构造类似水平越低，它能够进行合并结构，互相逻辑之间不会产生影响，比方有两个键值对，每个键值对的Value有3种变异取值，在合并结构状况下，能够从排列组合的6份数据缩小到3份数据。 基于这个个思路，咱们在实践中引入了编辑间隔和并查集算法，以节点门路为参照，对树的每一层的每两个节点计算编辑间隔，生成一个n*n矩阵；同时以树的高度减去节点位于的层数作为权重，修改编辑间隔。基于这样的计算，会产生多个编辑间隔矩阵。 为了尝试最大化合并结构用例成果，咱们把编辑间隔做了0,1矩阵转化。其中，因为编辑间隔为1的两个节点可能存在业务逻辑耦合关系，必须放在同一个组里别离结构，所以咱们把编辑间隔大于1的状况转化成了0，最初失去了一个0,1的编辑间隔矩阵。 在0,1矩阵状况下，咱们应用了图的连通性概念，如果A和B连通，B和C连通，那咱们认为A和C连通，转化到这里的概念就是A和B类似，B和C类似，那么A和C类似，它们应该被放在同一个组里离开进行结构，那么在同层元素结构时，咱们会从每个分组里取到一个节点，对这些规定进行变异组合结构。 基于以上两个策略进行精简后生成的变异数据量较精简前升高了40%，同时代码覆盖率没有显著变动，并且放弃不变的健壮性问题发现能力。 美团App和优选App都接入了这个工具，在新需要阶段能够人工触发运行，还能够联合客户端组件集成事件和回归事件做主动触发。至今利用一年工夫内，发现了几十个问题。 05 总结及瞻望在健壮性工具建设一期里，咱们实现了App页面加载展现场景的健壮性问题检测，反对解体、卡死和局部性能异样这三类异样检测。另外，基于节点相似性优化变异数据生成策略可能在放弃成果不变的状况下无效管制测试时长，但是否有更优的合并算法和举荐算法，还须要更多的尝试。 在后续工具的迭代还会持续围绕异样结构和异样检测这两个方向，反对更丰盛的结构能力和检测能力，以及更高效的结构效率。短期建设上，咱们将会从业务视角登程丰盛自动化变异数据生成建模，欠缺客户端异样通用异样检测能力，实现通用前后端交互的数据构造类型（比方：长连贯音讯）的笼罩；长期建设上，须要反对更丰盛的数据和环境结构能力，通过智能化用例生成，晋升测试效率。 06 Q&AQ1：节点类似的判断根据是什么？ A：从理论的response剖析来说，两个节点的门路齐全类似就是从根节点到最终的叶子节点上，它们的门路命名齐全类似，数组里两个对象的构造齐全一样。 Q2：用例的生成能举个例子吗？ A：比方色彩色值的格局是#+6位字符，通常经营配置会呈现的状况是遗记增加#，或色值复制中少了一位。在这种状况下，咱们会结构一个色值，比方没有返回#、色值位数不对、色值增加透明度，把这种场景作为结构状况，在配置里增加上，最初用代码生成。 Q3：健壮性平时执行的频率是什么样的？ A：第一个基于需要维度，需要维度须要人工触发；第二个基于变更维度，当组件产生变更时，能够关联到这段代码或者组件变更的页面，而后触发页面对应的健壮性测试，执行频率会受到组件变更频率的影响；第三个在回归测试时，App的回归测试两周一次，咱们会把所有页面以及它关联的所有的用例都执行一次。 Q4：对于裸露给前端开发的接口，大部分是人为调用参数的变动，随机性绝对比拟高，对于必填和非必填参数如何确认用例的范畴？ A：目前咱们在实现的计划里，没有辨别参数是必填参数还是非必填参数，所以对于整个数据接口返回里的所有后果都会进行结构，产生的问题是对于非必返回的参数可能产生的问题，到底是否是须要解决的问题，这部分目前通过经营伎俩做确认。 Q5：首页可能调用10个接口，而后针对每个字段都进行异样验证吗？ A：对于首页关联的接口，咱们在接口申请、录制过程中和录制完数据后，会对接口进行确认到底有哪些接口是咱们须要验证的，这是一次性的老本，录制实现后，会对每个字段都进行异样验证，当然会有一些黑白名单的设置。 Q6：对色号这种状况有一种生成规定嘛，这个规定是怎么制订？ A：刚刚我只是举了一个色号的例子，其实对于图片、申请的资源文件、配置文件、跳转链接，每一个对应到的业务语义，咱们都有对应的用例生成规定，咱们会依据参考根据，比方第一个是自身咱们在通用的根底库里怎么解决这些问题，这里有一个根底的规定；第二个是咱们积攒了线上问题状况理论可能会产生的谬误或者变异状况，生成第一版根底规定，在第一期工具里找相干研发达成共识，这样的话，数据变异是处于正当范畴。 Q7：执行的时候，如何晓得页面对应哪些规定提前配置？ A：执行时，在测试接入过程中有一个配置过程，它不是配置这个页面和接口的关联关系，而是配置咱们要测试哪些页面，主动触发自动化录制过程，就是到这个页面时，会触发哪些接口申请，生成这个页面和这个接口申请的对应关系，给到对应的配置人做确认，保障哪些接口是真正可能想要结构的，哪些接口不须要结构，最初以这个为基准测试，基于录制过程，比方业务迭代外面产生了新接口，咱们在录制中可能感知到它关联的接口产生了变动，在发生变化时发消息给对应的测试提交人/负责人，TA确认这条规定放到黑名单里还是更新到须要结构的接口里。 Q8：是否有做页面显示的一个校验？怎么做的？ A：目前咱们在页面里的模块做了“是否展现”校验，基于以后集成到美团的可测性SDK，这个SDK会获取到以后页面是否渲染里是否展现了对应模块的信息，通过申请把对应模块形容传给SDK，通过返回来校验是否展现。 07 参考资料[1] 健壮性：https://en.wikipedia.org/wiki/Robustness[2] IEEE健壮性：https://ieeexplore.ieee.org/document/7438745[3] Ballista：Carnegie Mellon大学的钻研我的项目，通过黑盒自动化测试的形式，发现导致系统解体或异样终止的零碎调用或接口调用。[4] 基于布局视图的解析SDK：美团App页面视图可测性革新实际-XraySDK| 在美团公众号菜单栏对话框回复【2023年货】、【2022年货】、【2021年货】、【2020年货】、【2019年货】、【2018年货】、【2017年货】等关键词，可查看美团技术团队历年技术文章合集。 ...

MJDK 是基于 OpenJDK 构建的美团 JDK 发行版。本文次要介绍 MJDK 是如何在保障 java.util.zip.* API 及压缩格局兼容性的前提下，实现压缩/解压缩速率晋升 5-10 倍的成果。心愿相干的教训可能帮忙到更多的技术同学。1 前言数据压缩技术[1]因可无效升高数据存储及传输老本，在计算机领域有十分宽泛的利用（包含网络传输、文件传输、数据库、操作系统等场景）。支流压缩技术按其原理可划分为无损压缩[2]、有损压缩[3]两类，工作中咱们最罕用的压缩工具 zip 和 gzip ，压缩函数库 zlib，都是无损压缩技术的利用。Java 利用中对压缩库的应用包含：解决 HTTP 申请时对 body 的压缩/解压缩操作、应用音讯队列服务时对大音讯体（如>1M）的压缩/解压缩、数据库写入前及读取后对大字段的压缩/解压缩操作等。常见于监控、广告等波及大数据传输/存储的业务场景。 美团根底研发平台已经开发过一种基于 Intel 的 isa-l 库优化的 gzip 压缩工具及 zlib[4] 压缩库（又称：mzlib[5] 库），优化后的压缩速度可晋升 10 倍，解压缩速度能晋升 2 倍，并已在镜像散发、图片解决等场景长期稳固应用。遗憾的是，受限于 JDK[6] 对压缩库调用的底层设计，公司 Java8 服务始终无奈应用优化后的 mzlib 库，也无奈享受压缩/解压缩速率晋升带来的收益。为了充分发挥 mzlib 的性能劣势为业务赋能，在 MJDK 的最新版本中，咱们革新并集成了 mzlib 库，实现了JDK中 java.util.zip.* 原生类库的优化，可实现在保障 API 及压缩格局兼容性的前提下，将内存数据压缩速率晋升 5-10 倍的成果。本文次要介绍该个性的技术原理，心愿相干的教训给大家带来一些启发或者帮忙。 2 数据压缩技术计算机领域的数据压缩技术的倒退大抵可分为以下三个阶段： 具体工夫节点如下： 20世纪50～80年代，香农创建信息论，为数据压缩技术奠定了实践根底。期间呈现多种经典算法，如 Huffman 编码、LZ 系列编码等。1989年，Phil Katz推出文件归档软件 PKZIP（zip 前身），并公开文件归档格局 zip 及其应用的数据压缩算法 deflate（Huffman 与 LZ77 的组合算法）的所有技术参数。1990年，Info-ZIP 小组基于公开的 deflate 算法编写了可移植的、收费的、开源实现 zip 和 unzip，极大地扩大了 .zip 格局的应用。1992年，Info-ZIP 小组基于 zip 的 deflate 算法代码，推出了文件压缩工具 gzip（GUN zip），用于代替 Unix 下的 compress（有专利纠纷）。通常 gzip 会与归档工具 tar 联合应用来生成压缩的归档格局，文件扩大名为 .tar.gz。1995年，Info-ZIP 小组成员Jean-loup Gailly 和 Mark Adler 基于 gzip 源码中的 deflate 算法实现，推出了压缩库：zlib 。通过库函数调用的形式，为其余场景（如PNG压缩）提供通用的压缩/解压缩能力。同年，在 RFC 中公布了 DEFLATE、ZLIB、GZIP 三种数据压缩格局。其中 DEFLATE 是原始压缩数据流格局，ZLIB、GZIP 则是在前者的根底上包装数据头及校验逻辑等。尔后随着 zip、gzip 工具及 zlib 库的广泛应用，DEFLATE 成为互联网时代数据压缩格局的事实标准。2010年后，各大型互联网公司陆续开源了新的压缩算法及实现，如：LZFSE（Apple）、Brotli（Google）、Zstandard（Facebook）等，在压缩速度和压缩比方面均有不同水平的晋升。常见的压缩库如下（须要留神的是：因为压缩算法协定的差别，这些函数库不能穿插应用，数据压缩/解压缩必须应用同一种算法操作）： ...

本文整顿自主题分享《美团数据库自治服务平台建设》，系超大规模数据库集群保稳系列的第四篇文章。本文作者在演讲后依据同学们的反馈，补充了很多技术细节，跟演讲（视频）相比，内容更加丰盛。文章分成上、下两篇，上篇将介绍数据库的异样发现跟诊断方面的内容，下篇将介绍内核可观测性建设、全量SQL、异样解决以及索引优化倡议与SQL治理方面的内容。心愿可能对大家有所帮忙或启发。1 背景&指标MySQL的故障与SQL的性能，是DBA跟研发同学每天都须要关注的两个重要问题，它们间接影响着数据库跟业务应用程序的稳定性。而当故障或者SQL性能问题产生时，如何疾速发现、剖析以及解决这些问题，使得数据库或者业务零碎疾速复原，是一项比拟大的挑战。 针对此问题，美团数据库自治平台通过多轮的迭代建设，在多个场景下曾经实现了异样的发现、剖析以及解决的端到端能力。本文将跟大家分享一下咱们平台建设的心路历程，同时提供一些教训、教训供同行参考，心愿可能起到“抛砖引玉”的作用。本文次要介绍以下主题： 异样发现：基于数理统计形式的动静阀值策略，来发现数据库系统的指标异样。故障剖析：丰盛欠缺数据库要害信息，来做准确的数据库异样根因剖析；深刻开掘内核价值，来解决根因诊断方面的疑难杂症。故障解决：根据异样根因剖析的不同后果，通过自助化或自动化的形式来进行故障的复原解决。内核可观测性建设：如何跟数据库内核团队单干，从内核的角度来剖析SQL性能问题，通过内核团队大量的内核代码革新，力求将数据库的可观测性跟诊断做到极致。单SQL优化倡议：通过革新MySQL存储引擎，同时联合查问优化来打造基于Cost模式的索引优化倡议。基于workload索引优化倡议：基于整个DB或者实例的Workload策略的索引优化倡议，为实现数据库的索引自保护提供前置条件。基于SQL生命周期的治理：实现从SQL上线前、执行过程中、执行结束后几个环节，以期实现端到端的慢SQL治理。2 平台演进策略美团数据库自治平台从下到上总体分为四层，别离为接口与展现、平台性能层，计算与存储、数据采集层，平台的总体架构以及每一层的作用如下： 数据库采集层：要进行数据库的诊断与剖析，须要依附要害的指标以及SQL文本数据，以后在每个数据库实例上部署一个数据采集程序（rds-agent）对立负责采集、上报要害数值指标以及SQL文本数据。数据计算与存储层：数据采集层上报上来的数据，依靠Kafka、Flink&Spark作为数据缓冲，对要害组件进行相干的数据处理，如SQL解析、SQL模版化、数据聚合等操作，再把解决的后果存入ES、Blade（美团自研的分布式数据库）、Hive等分布式数据库或者大数据平台，提供给下层的平台性能层应用。平台性能层：此层是整个零碎最为重要的局部，因为平台同时服务于DBA运维团队及研发团队，所以平台的建设分成了两条路：1）次要面向DBA用户，依照可观测性建设、异样发现、故障根因剖析、故障解决几个阶段来进行建设；2）次要面向研发同学，依照SQL优化倡议、危险SQL的发现、剖析与SQL治理等跟SQL相干的几个阶段来建设。当然，两者并没有严格界线，这些性能所有的用户都能够同时应用。接口与展现：平台性能层提供的外围性能会通过Portal来展现，同时为了让平台提供的性能更好地集成在用户本人的零碎中，咱们也通过OpenAPI的形式对外提供服务。3 异样发现数据库产生异样时须要尽早地发现，能力避免异样一提高放大，防止造成真正的故障。异样发现的次要形式是对数据库或者OS的要害数值指标进行监控，相干指标包含seconds_behind_master、slow_queries、thread_running、system load、Threads_connected等等，也能够是业务端研发关注的要害指标，如“应用程序拜访数据库的报错数量”、“SQL执行均匀耗时”等指标来进行监控。如果这些指标短时间内产生比拟大的稳定，那么数据库很可能呈现了一些异样，这就须要及时进行解决。 这些异样如何能力被发现呢？业界个别有基于动态阀值以及动静阀值的两种异样发现策略。前者很简略，如依据专家教训，人工设定seconds_behind_master或者Threads_connected的告警阀值，超过阀值就认为产生了异样。此形式尽管简略易用，但OLTP、OLAP等不同的业务场景，对于雷同指标的敏感度是不一样的，如果所有场景都应用对立的动态阀值来做异样发现，难免会有很多误告。而如果每个场景都去手工去调整，既不灵便，老本又太高，解决方案是基于不同场景的历史时序数据，应用数理统计的形式来别离建模，通过拟合出各自场景的模型来作为异样发现的策略。 3.1 数据分布法则与算法抉择基于数理统计办法的异样发现，须要依据具体的场景应用特定的模型。一般来说，模型的抉择跟时序数据的散布状态有很大的关系，时序数据的散布并不总是都像正态分布一样都是对称的，而是有些是左偏的，有些是右偏的，当然也有对称散布的。下图就展现典型的三种不同的时序数据分布状态。 针对下面的三种不同时序数据的散布状态，以及每种异样检测算法本身的个性，咱们别离采纳不同的异样检测算法。 对于低偏态高对称散布抉择“相对中位差（MAD）”，中等偏态散布抉择“箱形图（Boxplot）”，高偏态散布抉择“极值实践（EVT）”。没有抉择3Sigma的次要起因是：它对异样容忍度较低（建模的时候，如果有乐音等异样点也不会对模型的状态产生很大的影响，则阐明异样容忍度很高），而相对中位差（MAD）从实践上而言具备更好的异样容忍度，所以在数据出现高对称散布时，通过相对中位差代替3Sigma来进行检测。 3.2 模型抉择数据分布跟算法实用场景的剖析之后，对外部的时序数据进行查看，发现数据的法则次要出现漂移、周期和安稳三种状态，对样本先进行时序的漂移（如果检测存在漂移的场景，则须要依据检测取得的漂移点t来切割输出时序，应用漂移点后的时序样本作为后续建模流程的输出）。 之后同时进行平稳性剖析（如果输出时序S满足平稳性测验，则间接通过箱形图或相对中位差的形式来进行建模）以及周期剖析（存在周期性的状况下，将周期跨度记为T，将输出时序S依据跨度T进行切割，针对各个工夫索引j∈{0,1,⋯,T−1} 所组成的数据桶进行建模流程。不存在周期性的状况下，针对全副输出时序S作为数据桶进行建模流程），再对时序数据分布个性进行偏度的计算，最初再依据不同的偏度个性抉择不同的算法模型，具体如下： 在算法确定之后，先在离线环境针对不同的场景应用历史指标来训练模型，模型训练结束之后会存入数据库，在生产环境运行过程中，对于不同场景下的数值指标依据其个性来加载不同的模型，并且联合Flink实时计算框架来实时的发现指标的异样并进行告警。 4 异样诊断发现指标异样后，须要疾速的给出异样的根因，咱们能够依据具体的根因来抉择不同的解决策略，而后进行主动或者手动的复原工作。根因剖析能够基于专家教训，也能够严格地依照内核代码的逻辑来进行剖析。 本文重点讲述后者，强调如何应用“内核思维”来解决专家教训很难或者无奈解决的诊断问题。本文将列举“内核代码路径分析”、”内核日志剖析”、“内核性能加强“、“内核Core Dump剖析”以及“内核埋点”等几种不同的范式，来阐明数据库根因诊断的思路。 4.1 主从提早（内核代码路径分析）这里先介绍“内核代码路径分析”这个形式来诊断根因。对于数据一致性要求比拟高的应用程序，seconds_behind_master是一个非常重要的指标，如果其值过大就须要诊断其根因，避免应用程序读取到不统一的数据。依据专家教训，其值过大可能由“QPS突增”、“大事务”、“大表DDL”、“锁阻塞”、“表短少主键或者惟一健”、“低效执行打算”、“硬件资源有余”等因数造成，把这些专家经验总结成规定列表，当异样产生时一一迭代去验证是不是合乎某个规定，据此来诊断根因，然而此形式存在如下两大问题： 无奈枚举所有根因：教训因为其固有的局限性不可能思考到所有的故障场景，如何残缺的给出造成seconds_behind_master值异样的所有规定是一个挑战；另外，如果须要对一个全新的指标进行诊断，而在没有任何的专家教训状况下，如何能疾速地整顿出残缺的规定列表？不足对根因的深层次了解：“QPS突增”、“大事务”、“大表DDL”、“锁阻塞”、“低效执行打算”、“硬件资源有余”等因素会造成seconds_behind_master指标值的异样，然而为什么这些因数会造成指标值的异样呢？如果不从内核源码角度来理解这些因素跟seconds_behind_master之间的逻辑计算关系，那么是无奈理解真正起因的。4.1.1 内核代码路径分析针对下面两个问题，具体策略是间接看seconds_behind_master这个变量在内核层面是如何计算的，只有这样能力残缺的枚举出所有影响seconds_behind_master值计算的因数。 从源码角度看，seconds_behind_master的值由①time(0)、②mi->rli->last_master_timestamp和③mi->clock_diff_with_master这三个变量来决定（代码层面seconds_behind_master的计算逻辑是：seconds_behind_master=((long)(time(0) - mi->rli->last_master_timestamp)- mi->clock_diff_with_master），其中time(0)是零碎以后工夫（用秒示意），clock_diff_with_master这个值的计算很简单、又很要害，会放到下一节具体进行阐明。 而针对mi->clock_diff_with_master的计算，这个变量从源码层面看就是主、从实例之间的时间差；依据以后的信息就可以看进去，从库的以后工夫以及主从库之间的时间差都会影响seconds_behind_master值的计算。seconds_behind_master的计算和事务在主从库执行的状况如下： last_master_timestamp计算逻辑 从下面剖析能够晓得，last_master_timestamp值是影响seconds_behind_master值计算的要害变量，所以很有必要从源码角度剖析影响last_master_timestamp值的因数有哪些（从而间接获取了影响seconds_behind_master值的因素）。 last_master_timestamp的值来自于一个叫rli->gaq->head_queue()的成员变量new_ts（此处的rli->gaq->head_queue()是指代某个最新的曾经实现replay的事务对应的event group，event group是指一个事务在binlog文件里生成一组event来示意某个事务，这个event group里的event从主库传输到从库后进行replay操作来还原主库的事务）。new_ts值来源于rli->gaq->head_queue())->ts，而rli->gaq->head_queue())->ts的值是通过ptr_group->ts= common_header->when.tv_sec + (time_t) exec_time计算获取的。 再看一下when.tv_sec跟exec_time的含意，前者指代SQL在主库上的SQL执行的开始工夫，后者指代SQL在主库上的“执行时长”，“执行时长”又跟“锁阻塞”、“低效执行打算”、“硬件资源有余”等因素非亲非故。 值得注意的是，后面提到的rli->gaq->head_queue())->ts的计算跟slave_checkpoint_period以及sql_delay两个变量也有关系，依照这个思路层层迭代上来找出所有影响seconds_behind_master值的因素，这些因素都是潜在的主从提早异样的本源，这样也解决了后面说的“无奈枚举所有根因”跟“不足对根因的深层次了解”两大问题。 为了便于了解上诉的逻辑，放出要害的源代码：获取last_master_timestamp值的起源rli->gaq->head_queue()的成员变量new_ts。 bool mts_checkpoint_routine(Relay_log_info *rli, ulonglong period, bool force, bool need_data_lock){ do { cnt= rli->gaq->move_queue_head(&rli->workers); } ....................... ts= rli->gaq->empty() ? 0 : reinterpret_cast<Slave_job_group*>(rli->gaq->head_queue())->ts; //其中的ts来自上面的get_slave_worker函数； rli->reset_notified_checkpoint(cnt, ts, need_data_lock, true); // 社区版本的代码 rli->reset_notified_checkpoint(cnt, rli->gaq->lwm.ts, need_data_lock); /* end-of "Coordinator::"commit_positions" */ ......................}获取Master实例上执行的SQL的开始跟执行时长信息tv_sec跟exec_time。 ...

0 前文回顾在《MySQL自治平台建设的内核原理及实际（上）》一文中，咱们次要介绍了数据库的异样发现与诊断方面的内容，在诊断方面常常会碰到一些难以找出根因的Case。针对这些疑难杂症Case，通过本篇能够理解到，如何通过内核可观测性以及全量SQL来解决这些问题。除此之外，在得出根因后，如何解决异样，如何对SQL进行优化，以及如何进行SQL治理等相干方面问题，也将在本篇中给予解答。 1 内核可观测性建设1.1 内核可观测性建设1.1.1 性能诊断挑战在自治性能诊断平台的建设过程中，咱们发现如下两大挑战： 很多SQL性能抖动的问题找不出根因，比方SQL的执行时长莫名其妙的忽然变大，其执行打算良好、扫描跟返回的行数都很少，也没有行锁、MDL锁相干锁阻塞；查看慢查问日志，也没有哪个字段的耗时比拟高，然而SQL的执行时长就是忽然变长，有时候达到几十秒长，而平时往往是几毫秒，各种剖析后找不出起因。有时候在诊断一些指标异样的根因时，凭借的是不太严格的教训，而不是量化剖析，比方thread_running或者slow_queries值忽然升高的时候，可能会通过表information_schema.processlist查看以后的沉闷会话中线程的状态，看一下状态是不是有行锁或者MDL锁之类的阻塞，或者通过慢查问日志里的相干数据来诊断根因。这里的挑战是：咱们看到的是整个SQL某个工夫点的刹时状态，或者只是整个SQL执行过程中的局部数据，而不是整体的数据，所以得出的根因诊断可能是全面的，兴许一瞬间看到的是行锁，然而大部分工夫被MDL锁阻塞。1.1.2 解决思路如果应用的是社区版本的MySQL，基本上都会面临下面两大问题。咱们先从内核的角度剖析一下这两个挑战，对于第一个挑战，次要是对MySQL在内核层面执行细节不够理解，比方一条SQL执行了10s，而从内核层面来看的话，这十秒的工夫可能会有几百个步骤组成，查看后可能发现row或者MDL锁等待时间加起来只有1秒，那么其余的9秒的耗时在哪里呢？可能产生在这几百个步骤中的任何一个或者多个，所以如果没有这几百个步骤的明细数据，就无奈诊断出忽然呈现的性能问题的根因。 第二个问题跟第一个问题从实质上来说是一样的。因为采集的数据是某个工夫点的快照数据（通过沉闷会话），或者只是局部指标的数据（通过慢查问日志），所以咱们看到的只是全面的信息，而没有方法获取到整个SQL的残缺的耗时散布信息。 1.1.3 Wait耗时量化分析法在剖析完起因之后，咱们参考了TSA的思维，同时联合MySQL本身的特点来做基于Wait的内核可观测性的建设。从TSA能够看出，SQL执行的总耗时无非就是由Off-CPU跟ON-CPU两大部分组成，如果SQL有耗时长的问题，首先要确认是在OnCPU还是在OffCPU上耗时多。如果是前者，那么阐明SQL自身有问题，比方耗费资源太多（比方有效索引造成扫描行数过多）；如果是后者，那么阐明SQL自身没有问题，而是受到烦扰或者系统资源有余，进而造成OffCPU层面耗时过多。 无论是何种状况，咱们都须要把OnCPU跟OffCPU的耗时做进一步的拆分，从而来查看耗时瓶颈点到底在哪里，并且对耗时比拟多的要害代码门路交由内核团队来进行埋点；绝对MySQL performance_schema库中统计的Wait信息，实现十分轻量，所以对总体的性能的影响很小，并且耗时指标都是SQL明细粒度的，而不是相似performance_schema中的SQL模版级别的聚合数据。 耗时在OnCPU 在剖析一条SQL执行耗时，如果发现像下图一样，耗时散布大部分都在OnCPU，这阐明SQL自身有重大的性能问题（全表扫描、过滤成果不佳或者查问优化器的bug等起因），咱们能够把诊断的方向集中在如何优化SQL自身就能够了，而不须要去关注其余的方面，如锁阻塞、磁盘或者网络提早等OffCPU方面的问题。通过应用getrusage办法来获取某条SQL的OnCPU耗时时长，比方在SQL执行前，获取以后线程的ru_utime、ru_stime工夫，而后在SQL执行结束时再次获取ru_utime、ru_stime值，就能够失去SQL执行的CPU Time。 耗时在OffCPU 如果发现OnCPU的耗时占总耗时的比率比拟低，通过OffCPU的相干指标发现其占总耗时的比率比拟高，阐明SQL自身没有问题，可能是被锁住了、硬件资源有余或者是被内核层面某个内核锁给卡住了。咱们就须要查看到底是OffCPU相干的哪个，或者哪些指标耗时比拟高，须要在内核层面对执行过程中的可能的、耗时比拟长的执行代码门路进行埋点，只有获取到了跟性能相干的要害的数据，能力做出精确的判断。 如何抉择适合而全面的OffCPU相干的代码门路进行埋点？通过摸索，这里提供了如下几个形式： 剖析setup_instruments表中蕴含的要害埋点信息，大抵晓得有哪些要害的指标能够埋点，比方wait/IO、Mutex类等，再联合本身的教训来判断哪些指标可能有性能瓶颈的问题。依据理论疑难case来判断抉择哪些Wait指标，比方看到"Thread xxx has waited at trx0trx.cc line 1193 for 241.00 seconds the semaphore: xxxxx mutex REDO_RSEG created trx0rseg.cc:211, lock var 1"，则对mutex REDO_RSEG进行埋点，看到"Thread xxx has waited at dict0dict.cc line 1239 for 245.00 seconds the semaphore: xxxxxx Mutex DICT_SYS created dict0dict.cc:1173, lock var 1"则对 Mutex DICT_SYS进行埋点。源码剖析，在内核层面对SQL的执行过程进行逐渐的Debug，依据教训剖析可能的瓶颈点来埋点；上面举两个例子别离就纯源码的角度来剖析，SQL在读、写过程中哪些地方可能会造成性能抖动并做埋点。例子1，在SQL读操作的执行过程中，须要从buffer pool中申请内存资源，如果始终满足不了内存资源的申请则始终会循环尝试获取，如果在2000ms内还是没有从Buffer pool中申请到须要的内存，会打印日志“Difficult to find free blocks in the buffer pool......”，来表明内存很缓和；这种长时间期待内存资源的获取会生产了性能抖动，这个时候就须要在对应的内核代码处进行埋点获取BP内存资源等待时间。 ...

写在后面CVPR 全称为 IEEE Conference on Computer Vision and Pattern Recognition，国内计算机视觉与模式识别会议。该会议始于1983年，与ICCV和ECCV并称计算机视觉方向的三大顶级会议。依据谷歌学术颁布的2022年最新学术期刊和会议影响力排名，CVPR在所有学术刊物中位居第4，仅次于Nature、NEJM和Science。2023年，CVPR共收到寰球9155篇论文投稿，最终2360篇被接管，接管率约为25.78%。 | 01 Divide and Adapt: Active Domain Adaptation via Customized Learning论文作者：黄铎峻（中山大学，美团实习生），李继昌（香港大学），陈伟凯（腾讯-美国），黄君实（美团），柴振华（美团），李冠彬（中山大学） 论文下载：PDF 论文简介：该论文入选焦点论文（Highlight Paper）。近年来，被动畛域自适应被提出用于在畛域自适应问题中，设计被动学习算法在未标注的指标域数据中抉择最有信息量的一小批样本进行标注，来最大化的晋升深度学习模型在指标域数据上的性能，达到高效的标注效率。在理论的凋谢场景中，指标域样本绝对于源域数据的可区分度各异，即对于源域上初始化的而言具备不同档次的可迁移性。目前，鲜有工作对可迁移性各异的指标域样本分类探讨，设计高价值样本的采样策略和定制化的畛域自适应训练策略。 咱们提出了一种分而治之的策略，综合思考指标域样本与源域数据的差异性，和模型预测的不确定性，来设计被动学习的采样策略，并提出定制化的指标函数来束缚具备不同可迁移性的样本子集，进一步实现采样的鲁棒性。试验表明，咱们实现了在多种畛域自适应场景下的最优性能，包含无监督畛域自适应（UDA）、半监督畛域自适应（SSDA）和无源域畛域自适应（SFDA）等等。 | 02 Efficient Second-Order Plane Adjustment论文作者：周力普（美团） 论文下载：PDF 论文简介：该论文入选焦点论文（Hightlight Paper），推导出了立体优化问题Hessian矩阵的闭式解，由此提出了高效的立体优化问题的二阶优化算法。该算法能够广泛应用于深度传感器的三维高精度重建。 立体通常用于深度传感器的3D重建，例如RGB-D相机和LiDAR。本文钻研预计最佳立体和传感器位姿的问题。这由此产生的最小二乘问题在文献中被称为立体调整（PA）。迭代办法常被用来解决这些最小二乘问题。通常，牛顿法很少用于大规模最小二乘问题，因为Hessian矩阵的计算工夫复杂度很高。相同，迭代算法通常采纳应用Hessian矩阵的近似值，例如Levenberg Marquardt（LM）办法。本文采纳牛顿法无效地解决了PA问题。 具体来说，给定姿态，最佳立体有一个闭式解。因而，咱们能够从中打消立体参数，它显著缩小了变量的数量。此外，因为最佳立体是姿态的函数，这种办法实际上确保了每次迭代都能产生最佳立体，这有利于收敛。其难点在于如何高效计算Hessian矩阵以及由此产生的梯度向量。本文提供一个高效的解决方案。实证结果表明，咱们的算法优于目前的SOTA算法。 | 03 AeDet: Azimuth-invariant Multi-view 3D Object Detection论文作者：冯承健（美团），揭泽群（美团），钟毓杰（美团），初祥祥（美团），马林 （美团） 论文下载：PDF 论文简介：近年来，基于鸟瞰图的多视图3D指标检测技术在Brid-Eye-View（BEV）空间通过卷积网络检测物体，获得了微小的停顿。然而，传统的卷积疏忽了BEV特色的径向对称性，减少了检测器优化的难度。为了放弃BEV特色的固有性质并便于模型优化，咱们提出了方位角等变卷积（AeConv）和方位角等变锚。方位角等变卷积的采样网格始终是径向的，因而能够学习到方位不变的BEV特色。而方位角等变锚使得检测头可能学习预测与方位无关的指标。 此外，咱们还引入了一种相机解耦的虚构深度，以对立具备不同相机内参的图像的深度预测。由此产生的指标检测器被称为方位等变检测器（AeDet）。咱们在nuScenes数据集上进行了多视图3D指标检测试验：方位等变检测器获得62.0% NDS，显著超过了现有的多视图3D指标检测办法。 | 04 Masked Auto-Encoders Meet Generative Adversarial Networks and Beyond论文作者：费政聪（美团），范铭源（美团），朱理（美团），黄君实（美团），魏晓明（美团），魏晓林（美团） 论文下载：PDF 论文简介：掩码主动编码器（Mask autoencoder，MAE）预训练方法通过随机掩码图像块（patch），而后训练视觉模型基于未掩码的图像块来重建原始图像的像素。只管它们在上游视觉工作中体现出很好的性能，但它们通常须要大量的计算能力失效。在本文中，咱们介绍了一种基于生成反抗网络（Generative Adversarial Networks，GAN）的预训练框架。 ...

本文整顿自美团技术沙龙第75期的主题分享《美团数据库攻防演练建设实际》，系超大规模数据库集群保稳系列的第2篇文章。本文首先介绍了美团以后数据库运维现状、遇到的问题，以及为什么要建设数据库攻防演练平台；其次，分享以后数据库攻防演练平台的具体实际；第三局部会介绍数据库攻防演练在美团外部的落地状况；最初，会联合混沌工程的成熟度规范和成熟度等级，分享咱们对将来工作的一些布局。01 背景1.1 初识混沌工程首先咱们先理解一下什么是混沌工程？简略而言，混沌工程是在零碎上进行试验的技术手段，目标是建设对系统抵挡生产环境中失控条件的能力以及信念。这次要体现在两个方面，从零碎角度来讲，混沌工程能够晋升咱们架构的容错能力和韧性，升高故障发生率和复发率，晋升零碎用户在应用时的体验；从人员角度来讲，通过混沌工程咱们能够加深对架构的了解，在解决故障时能进步整体的应急效率，并且能被动去探索零碎中潜在的一些问题。 混沌工程最早能够追溯到2008年，过后奈飞公司（Netflix）因数据库故障造成了一次微小的损失，于是他们便围绕着稳定性体系做出了一些摸索和建设。直到2015年，混沌工程的理念才被奈飞正式的提出。2019年，阿里云推出了开源工具Chaos Blade；2020年，PingCAP开源了Chaos Mesh，这也标记着国内在混沌工程畛域也有了成熟的产品。 1.2 现状上面是以后美团数据库运维的一些现状，这里从五个维度开展：首先集群规模（包含集群的大小和数量）的线性增长；第二，集群访问量的继续减少，当然这也是美团业务增长的必然结果；第三，线上遇到的故障品种也越来越多；第四，单位工夫故障的影响也越来越大；第五，一些小概率事件的产生也随着集群规模的扩充成为了可能。 1.3 痛点&作用基于以上的问题，咱们整体上对于数据库集群的稳定性要求也越来越高。所以，围绕着稳定性建设，数据库团队在故障的预防、发现、剖析、复原以及预先复盘5个方面做了很多工作。其中在故障预防方面，咱们会通过故障演练摸索不同故障场景对咱们业务的影响，晋升故障产生时业务零碎整体的容错能力。晚期的时候，咱们通过人工的形式来做故障演练，但人工演练在以下四个方面存在很大的问题： 在演练场景方面，人工演练能演练的场景比拟少，演练场景的复杂度也比拟高；在演练覆盖率方面，人工演练无奈笼罩大多数的集群，也就无奈保障常态化的故障演练；在演练规模方面，人工演练没有方法进行大规模演练，在遇到一些机房或者交换机级的故障时，切换能力无奈失去无效验证；在影响范畴方面，人工演练在整个演练过程中不能很好地管制爆炸半径，遇到问题不能疾速止损。基于人工演练的这些痛点问题，咱们设计并建设了数据库故障演练平台，这个平台的作用次要体现在以下四个方面：第一，验证故障产生时组件的防守能力；第二，通过数据库大规模容灾演练，验证数据库集群的容灾能力；第三，能够验证故障产生时相干预案（业务、DBA）的有效性；第四，能够预知故障对业务造成的各种影响。 02 建设实际2.1 体系架构以后，数据库故障演练平台体系架构次要包含如下六个模块： 权限治理，管制演练发起人，能够对哪些集群发动故障演练；演练评估，演练之前为了防止演练危险，会对集群做一些查看，比方集群的高可用是否开启，拓扑是否符合要求，演练工夫是否处在集群拜访的高峰期等；故障注入，在相干的查看通过后，真正去执行故障的下发；指标观测，在整个演练期间会通过采集一些能够反映稳态的数据，比方以业务的拜访成功率、业务的响应提早等等，来剖析故障演练对业务造成的影响；终止注入，在演练过程中发现整体影响比拟大，或者有一些非可控的影响，能够立即终止故障演练，防止故障演练对线上业务造成的影响进一步扩充；智能剖析，在演练完结之后，能够通过采集一些反馈故障注入或者是防守组件的相干数据断定本次故障演练是否合乎预期。以后故障注入反对的主机类型比拟全面，能够在物理机、虚拟机、容器上做故障演练。 2.2 能力全景这部分次要介绍一下咱们故障演练平台的能力全景，它次要布局了咱们以后数据库故障演练平台的一些外围能力，整体的细节如下图所示： 从反对的数据库来看，以后咱们次要反对MySQL的故障演练；反对的数据库组件有数据库拜访中间件、数据传输、高可用零碎和Binlog Server，咱们会在后续的迭代中逐渐反对，以后咱们正在接入数据库拜访中间件的一些演练场景；在整个故障演练过程中，咱们会依赖高可用、容灾管控、故障诊断、故障兜底以及拓扑自愈等多个方面的能力，次要是验证下面提到的这些组件在整个演练过程中的体现是否合乎预期；以后，平台本身曾经造成了从故障编排、故障注入、指标观测、故障终止、剖析复盘的一个闭环。2.3 故障注入能力对于故障注入能力，以后反对的故障场景次要包含5个（如下图所示），目前咱们次要建设的是宕机类（包含主库宕机、从库宕机）、主从提早以及从库沉闷连贯多，因为当火线上80%的故障都是由这几个场景引起的，这也是咱们目前没有建设过多故障场景的次要起因。前面咱们还会布局建设高可用的链路故障，比方数据库和高可用同时出问题时，高可用的体现是怎么样的，是否可能顺利的进行切换。 在故障编排方面，咱们通过建设一个工作内的子工作间的串行故障和并行故障的编排机制，来实现演练工作的对立编排。 在并发能力上，以后故障演练平台激进的并发故障注入能力是在一分钟实现5000+节点的故障注入，目前这个能力曾经能够满足咱们对于大规模故障演练的整体需要。 2.4 演练流程整个演练流程次要分成三局部，演练前、演练中和演练后，同时咱们也造成了危险评估、危险复核、一键终止、故障复盘的能力闭环。 在演练前，咱们次要做三个方面的工作： 针对演练集群做危险评估，比方演练集群的高可用是否开启、拓扑是否符合要求；利用多级审批机制，让业务和相干的DBA通晓整个演练的危险；在演练前创立相干交换群，把故障演练相干的信息在群里进行周知。在演练中，有两方面的工作： 在故障注入前，做一下前置查看，次要目标是在建设演练工作后和故障注入前这个时间段，避免因集群拓扑变动产生危险，比方演练的场景是从库宕机，这种状况下如果产生切换，故障注入的节点很有可能变成了主库；如果一个工作里含有多个子工作，而某一个子工作产生了故障注入失败，那么后续演练咱们会主动终止。在演练完结后，咱们会进行故障清理，实现后做演练的数据收集，用于复盘，并据此欠缺相干的危险管控流程。 2.5 爆炸半径管制提到混沌工程，就不得不提到爆炸半径管制的问题，以后咱们次要从两个维度、三个方面做了一些管制。 第一个维度是物理隔离，它蕴含两方面： 场景维度隔离，即在同一时间点、单个数据库的集群只能注入繁多类型的故障，次要是为了防止在单个演练工作中如果针对一个数据库集群注入多种故障，整体影响不容易被评估。机器维度隔离，单个集群故障注入只能选定一个特定机器，而不能抉择多个机器。第二个维度是流量管制，次要是通过中间件按权重下发少部分流量到演练节点实现，流量管制能从一个更精密的维度来管制演练的危险。 另外，咱们在演练前、演练中和演练后都有相干的查看或措施，可能保障在演练期间呈现问题后迅速把影响降到最低，这也是另外一种变相的爆炸半径管制。实质上来说，爆炸半径和通过演练发现的问题数量会有一个反比的关系，即爆炸半径管制得越小，整个故障演练对业务的影响也就越小。但与此同时，整个故障演练裸露进去的问题，就会比拟无限，所以在建设过程中要做一个取舍。如果想发现更多的问题，那爆炸半径就要设计的大一些。以后，综合考量多种因素，咱们还是把爆炸半径管制在一个绝对正当范畴去进行故障演练，让业务以一个更低的老本进行故障演练。 2.6 演练复盘当演练完结后，咱们须要对整体的演练后果做主观的评估剖析，进而判断这次演练整体是否达到预期。演练复盘内容包含演练整体流程、存在的问题以及针对问题造成的相干改良点，它能够用来领导后续的演练。如果本次演练不合乎预期，咱们会通过演练复盘性能买通故障演练平台和故障复盘两大产品，主动生成演练相干的工夫线，从而更好地进行人工复盘。 演练复盘次要是分为四局部： 第一局部是演练复盘的概览信息，它次要是蕴含六个方面：① 演练时长；② 本次演练波及的集群数；③ 演练场景数；④ 演练成功率，即故障注入的成功率；⑤ 演练过程中产生的告警数；⑥ 演练期间业务申请的成功率。第二局部是关键步骤，这里收集了在整个演练过程中十分要害、十分外围的步骤，以及它整体的指标数据，这些能够帮忙咱们剖析平台自身亦或是防守组件的相干体现是否合乎预期。第三局部是在演练过程中波及的外围防守组件的指标数据，比方针对主库宕机，咱们次要关怀两方面数据：一是故障注入后，高可用组件用了多长时间才发现这个故障，二是在发现了这个故障后切换花了多长时间。通过这些数据，就能够晓得在本次演练过程中防守组件的体现是否合乎预期。第四局部是演练详情，它是针对单个集群的演练过程绘制的残缺的工夫线信息，能够通过这些信息看到一个演练集群从前置查看到故障注入，到告警产生，到防守组件的染指，再到故障清理呈现出的一个十分具体的工夫线数据，如下图所示： 2.7 随机、无告诉演练从2022年开始，咱们开始建设随机、无告诉演练能力。之前故障演练平台次要是在特定工夫、特定场景下的演练，并且在整个演练过程会组织相干的人员协同跟进整个演练过程。然而，故障的产生是一个十分随机的行为，它不会给人足够的工夫去筹备、应答。而随机无告诉演练性能，就是心愿建设这样的能力，能够在非特定工夫、非特定集群、非特定场景进行故障演练，在肯定水平上填补了故障演练的空白，也是故障演练平台向混沌工程演进的一个里程碑。整个演练过程次要分成三个局部： 第一局部是须要增加演练打算，其次要内容包含三个方面： 能够通过集群、场景、演练工夫这3个维度，去管制哪些集群能够演练哪些场景，在什么工夫能够进行随机无告诉演练；按集群、场景维度组合去做相干危险查看，以此来保障增加的这些集群能够进行相干场景的演练；和惯例故障演练类似的是，它也提供了多维审批，能够让相干业务人员或者DBA通晓个整个演练的危险。第二局部是演练工作生成，有了演练打算后，咱们按演练打算随机搭配生成演练工作并进行周知，和惯例演练最大不同是咱们不会周知演练的具体工夫（会周知演练集群、场景），次要是为了模仿故障产生的随机性。随着前面整体能力的降级迭代，咱们会逐渐去掉在集群、场景维度的周知。 第三局部是演练工作执行，它齐全复用咱们惯例故障演练的性能，也能够在演练前勾销、演练中终止，演练后能够主动复原整个集群的拓扑。 2.8 演练模式比照上面咱们将惯例故障演练、随机无告诉演练以及混沌工程作一下比照，如下表所示： 首先从演练目标维度来看：惯例故障演练目的性十分强，它次要是验证已知的问题场景是否会再次造成生产上的事变；随机演练次要是在已知的故障场景、在无限的集群范畴内，是否会产生问题；混沌工程的演练目的性最弱，它次要是测验未知的故障场景是否会造成问题。从是否有人值守的维度来看：惯例故障演练须要有人值守；随机无告诉演练是朝着无人值守方向倒退的，但以后鉴于咱们的能力还在建设初期，所以也会减少一些相干的值守机制来管制演练危险；混沌工程是齐全无人值守的，因为也无奈去值守一个混沌工程的“混沌”试验。从事先周知的维度来看：惯例故障演练须要明确进行周知；随机无告诉演练以后在无限集群和无限场景范畴内进行演练（会周知演练集群、演练场景），不会周知具体的演练工夫；混沌工程是齐全无周知的演练模式。2.9 演练经营体系上面是数据库故障演练平台的经营体系的建设，次要关注四个局部： 首先是演练外围指标： 一是在一段时间内，共进行了多少次演练，波及演练集群数有多少个；二是在一段时间内演练集群和演练场景的覆盖率以及达标率；三是故障演练完结后的反馈，即演练是否合乎预期。第二局部是大规模演练的外围指标，咱们次要关注三个方面： 第一方面是每次大规模演练的演练规模；第二方面是故障注入的成功率；第三方面是故障注入的耗时散布，次要统计在某一个工夫点，实现了多少实例的故障注入。第三局部是业务接入指标，一方面统计外围业务的接入状况，同时也会反映一下DBA在不同业务线的推广状况。 第四局部是平台能力指标，一方面是平台接口成功率，另一方面是平台接口的相干耗时。 03 落地状况3.1 演练推广本局部会介绍故障演练平台在美团外部的落地状况。首先在推广层面，咱们次要采纳三种模式： ...

2016年，咱们对美团Android热更新计划Robust的技术原理做了具体介绍。近几年，Google 推出了新的代码优化混同工具R8，Android 热修复补丁制作依赖二次构建包和线上包比照，须要对Proguard切换到R8提前进行适配和革新，本文分享 Robust 在适配 R8 以及优化改良中的一些思路和教训，心愿能对大家有所帮忙或者启发。1. 背景美团 Robust 是基于办法插桩的实时热修复框架，次要劣势是实时失效、零 Hook 兼容所有 Android 版本。2016 年，咱们在《Android 热更新计划 Robust》一文中对技术原理做了具体介绍，次要通过给每个办法插入 IF 分支来动态控制代码逻辑，进而实现热修复。其外围次要有两局部：一个是代码插桩，一个是主动补丁。 代码插桩这部分随着 Javassist、ASM 工具的宽泛应用，整体计划比拟成熟了，迭代改良次要是针对插桩代码体积和性能的优化；主动补丁这部分在理论应用过程中始终在迭代，跟业界支流热修复计划一样，自动化补丁工具作制作机会是在 Proguard 混同之后，因为 Proguard 会对代码进行代码优化和混同解决，在 Proguard 后制作补丁可能升高补丁生成的复杂性。近年来， Google 推出了新的代码优化混同工具 R8，用于取代第三方的代码优化混同工具 Proguard，通过多年性能迭代和缺点改良，R8 在性能上根本能够代替 Proguard，在后果上更为杰出（优化生成的 Android 字节码体积更小）。Google 曾经在新版本的构建工具中强制应用 R8 ，国内外已有多个出名 App 实现了 R8 适配并上线，比方微信 Android 在往年正式从 Proguard 切换到了 R8（通过降级 Android 构建工具链）。Android 热修复补丁制作依赖二次构建包和线上包比照，须要对 Proguard 切换到 R8 提前进行适配和革新，本文分享了美团平台技术部 Robust 在适配 R8 以及优化改良中的一些思路和教训。 2. 次要挑战Android 热修复补丁的大抵制作流程：首先基于线上代码进行逻辑修复并二次打包，而后补丁生成工具主动比拟修复包和线上包的差别，最初制作出轻量的补丁包。因而在补丁制作的过程中，须要解决两个次要问题： 对于没有变动的代码，如何在二次打包时保障和线上包统一；对于本次修复的代码，如何在通过编译、优化、混同之后精确辨认进去并生成补丁代码。要解决这两个问题，须要对 Android 编译和构建过程有肯定理解，弄清楚问题产生的起因。下图 1 是一个 Android 我的项目从源码到 APK（Android 利用安装包）的构建过程（椭圆形对应构建工具链）： ...

用好中间件是每一个开发人员的基本功，一个业余的开发人员，谋求的不仅是中间件的日常应用，还要探索这背地的设计初衷和底层逻辑，进而保障咱们的零碎运行更加稳固，让开发工作更加高效。联合这一主题，本文从一次线上告警问题登程，通过第一工夫定位问题的根本原因，进而引出Google Dapper与MTrace（美团外部自研）这类分布式链路追踪零碎的设计思维和实现路径，再回到问题实质深刻@Async的源码剖析底层的异步逻辑和实现特点，并给出MTrace跨线程传递生效的起因和解决方案，最初梳理目前支流的分布式跟踪零碎的现状，并联合开发人员日常应用中间件的场景提出一些思考和总结。1. 问题背景和思考1.1 问题背景在一次排查线上告警的过程中，忽然发现一个链路信息有点不同寻常（这里仅展现测试复现的内容）： 在机器中能够分明的发现“2022-08-02 19:26:34.952 DXMsgRemoteService ”这一行日志信息并没有携带TraceId，导致调用链路信息戛然而止，无奈追踪过后的调用状况。 1.2 问题复现和思考在解决完线上告警后，咱们开始剖析“失落”的TraceId到底去了哪里？首先在代码中定位TraceId没有追踪到的局部，发现问题呈现在一个@Async注解下的办法，删除无关的业务信息代码，并减少MTrace埋点办法后的复现代码如下： @SpringBootTest@RunWith(SpringRunner.class)@EnableAsyncpublic class DemoServiceTest extends TestCase { @Resource private DemoService demoService; @Test public void testTestAsy() { Tracer.serverRecv("test"); String mainThreadName = Thread.currentThread().getName(); long mainThreadId = Thread.currentThread().getId(); System.out.println("------We got main thread: "+ mainThreadName + " - " + mainThreadId + " Trace Id: " + Tracer.id() + "----------"); demoService.testAsy(); }}@Componentpublic class DemoService { @Async public void testAsy(){ String asyThreadName = Thread.currentThread().getName(); long asyThreadId = Thread.currentThread().getId(); System.out.println("======Async===="); System.out.println("------We got asy thread: "+ asyThreadName + " - " + asyThreadId + " Trace Id: " + Tracer.id() + "----------"); }}运行这段代码后，咱们看看控制台理论的输入后果： ...

美团语音交互部针对交互场景下的低提早语音辨认需要，提出了一种全新的低出字提早流式语音辨认计划。本办法将升高提早问题转换成一个常识蒸馏过程，极大地简化了提早优化的难度，仅通过一个正则项损失函数就使得模型在训练过程中主动升高出字提早。在试验测试集上，本办法可能取得最高近 200 毫秒左右的均匀出字提早升高。1. 前言1.1 语音辨认技术简介人机交互始终都是人工智能大背景下的“热门话题”，语音交互作为人机交互的一个重要分支，具备宽泛的利用价值，也被利用到美团的多个业务场景中，如智能客服、电话营销和电话满意度反馈等。而流式语音辨认技术是整个交互链条的入口，对交互体验影响微小。 常见的语音辨认大多都是非流式语音辨认技术，它是指模型在用户说完一句话或一段话之后再进行辨认。这意味着模型须要期待用户进展或完结谈话能力开始辨认，并且只能在用户进展或完结谈话后能力输入残缺的辨认后果。这样做的毛病是会导致较长的提早和不连贯的交互。例如，在会议场景中，如果应用非流式语音辨认技术，就可能呈现会议参与者说了很长时间的话才显示出他们所说的内容，而且可能因为网络提早或其余起因导致内容显示不全或谬误。这样就会影响会议参与者之间的沟通和了解，并且升高会议效率和品质。 而与之对应的是流式语音辨认技术，它是指能够在解决音频流的过程中，反对实时返回辨认后果的一类语音辨认模型。这意味着模型不须要期待用户说残缺句或整段话就能够开始辨认，并且能够随着用户谈话的进度逐步输入辨认后果。这样做的益处是可能大大减少人机交互过程中语音辨认的解决工夫，进步用户体验和交互效率。例如，在智能客服场景中，应用流式语音辨认技术，就能够实现用户说一句话很快就能取得机器人响应，而不是等到用户说完一段话才给出答复。这样就能够让用户更快地失去称心的解决方案，并且缩小用户的等待时间和不满情绪，晋升用户满意度。在美团外部的泛滥业务场景中宽泛应用了流式语音辨认技术。 本文将具体论述团队在语音交互场景中的低提早流式语音辨认计划，目前以该计划造成的技术论文《Peak-First CTC: Reducing the Peak Latency of CTC Models by Applying Peak-First Regularization》曾经被语音畛域国内顶级会议ICASSP 2023收录。 1.2 问题与挑战对一个好的流式语音识别系统而言，不仅仅须要高的辨认准确率，还应该具备很低的提早。在交互场景中，低提早能够进步用户体验和满意度，让用户感觉不到语音辨认的解决工夫，更加天然和流畅地进行对话和问答。低提早也能够缩小通话交换中的误会和抵触，让用户可能及时地收到反馈后果，防止反复或打断对方的谈话。此外，低提早还能够减少语音利用的可用性和灵活性，让用户可能在各种场景下通过谈话来实现工作（例如在线游戏、语音助手、智能家居等），节省下来的提早也能够用于在语音服务的上下游部署更加简单的模型构造，从而进一步欠缺交互链路等。 在美团的交互场景中，宽泛应用联结时序分类模型（Connectionist Temporal Classification， CTC ）作为根底模型来构架流式语音识别系统。CTC 模型因为其优雅的模型构造、卓越的模型体现以及良好的扩展性受到了宽泛的青眼。目前曾经广泛应用在语音辨认（Automatic Speech Recognition, ASR）、语音翻译（Speech Translation, ST） 以及 光学字符识别（Optical Character Recognition, OCR）等畛域。 下图展现了一种典型的 CTC 模型构造，其依赖 DFSMN 网络结构搭建，仅蕴含声学编码器（Acoustic Encoder）和输入线性映射层两局部。声学编码器用来将输入的声学特色序列转变成声学编码序列，而输入线性映射层则负责将利用声学编码表示，计算失去模型预测出不同文本标记的概率值。比照其余流式语音辨认模型，CTC 模型不须要简单的编码解码（Encoder-Decoder）构造或者注意力机制（Attention Mechanism）就能实现两个不等长序列之间的转换（对于语音辨认而言是从声学特色序列转换到指标文本序列）。 基于 CTC 的流式语音识别系统对于提早也有着十分高的要求。从用户发音完结到零碎辨认出对应文字之间的时间差被称之为出字提早。出字提早越低则意味着 ASR 零碎吐字的速度越快，用户体验越好。下图展现了 CTC 模型的输入概率分布，其中顶部色块示意用户说的每个文本的发声范畴，而底部对应色彩的尖峰则示意零碎辨认出的文本所在的地位。出字提早则对应着色块尾部与概率尖峰地位之间的时间差。本文所展现的工作就聚焦于如何降流式 CTC 语音识别系统的出字提早。 2. 尖峰优先正则化办法2.1 CTC 模型根底CTC 模型可能间接建模了声学序列到文本序列的转换关系，而不须要注意力机制等构造。因为文本序列的长度远远小于声学特色序列（通常状况下声学特色序列以帧作为单位，相邻两帧之间距离为 10ms，时长为 1s 的语音就能够被划分为100 帧），而在模型预测过程中，每帧特色都有一个预测标签。CTC 损失计算过程中引入了空格标记 来作为填充标记符，以使得文本序列与声学序列的长度相等。 ...

目前，美团外部的日均慢查问数量曾经超过上亿条，如何对对这些慢查问进行剖析并建设适合的索引，是美团数据库研发核心面临的一项挑战。美团数据库平台研发组与华东师范大学开展了科研单干，通过基于AI+数据驱动的索引举荐，来与基于代价的办法并行地为慢查问举荐索引，以晋升举荐成果。1 背景随着美团业务量的一直增长，慢查问的数量也日益增多。目前，日均慢查问数量曾经超过上亿条，如果仅依附DBA和开发人员手动地对这些慢查问进行剖析并建设适合的索引，显然是不太事实的。为了解决这一难题，美团外部DAS（数据库自治服务）平台曾经集成了基于代价的慢查问优化倡议来主动地为慢查问举荐索引。然而，依然存在一些问题： 基于代价的慢查问优化倡议是借助于优化器的代价预计，来举荐出对于查问代价改善最大的索引，但优化器的代价预计并不是齐全精确[1]，因而可能存在着漏选或者错选举荐索引的问题。基于代价的慢查问优化倡议须要计算查问在不同索引下查问代价的改善水平，因而须要进行大量的增删索引操作，但实在增删索引的代价是十分大的，须要借助于假索引[2]技术，假索引技术并不创立实在的物理索引文件，只是通过模仿索引存在时的查问打算来估算索引对于查问的收益。目前，美团大部分业务都是运行在MySQL实例上的，不同于商业数据库SQL Server和开源数据库PostgreSQL，MySQL外部并没有集成假索引技术，因而须要本人构建反对假索引的存储引擎，其开发成本较高，这也是目前DAS平台基于代价的慢查问优化倡议所采纳的计划。为了解决上述两个问题，美团数据库研发核心与华东师范大学数据迷信与工程学院开展了《基于数据驱动的索引举荐》的科研单干，单方通过在DAS平台上集成基于AI+数据驱动的索引举荐，来与基于代价的办法并行地为慢查问举荐索引，以晋升举荐成果。 首先，基于代价的办法每天会为慢查问举荐索引，并在采样库上评估举荐的索引是否真正地改善了查问的执行工夫，这为AI办法积攒了大量可信的训练数据，依据此数据训练的AI模型，能够在肯定水平上补救基于代价的办法漏选或错选索引的问题。其次，基于AI的办法将针对慢查问的索引举荐看作是二分类问题，通过分类模型间接判断在某一列或某些列上建设索引是否可能改善查问的执行性能，并不借助于查问优化器和假索引技术，这使得AI办法更加通用，且开发成本更低。2 索引举荐介绍索引举荐能够划分为两个级别：Workload级别和Query级别： 在Workload级别，索引举荐是在限度的索引存储空间或索引个数下，举荐出一组最优的索引汇合来使得整个Workload的代价最低。Query级别的索引举荐能够被视为Workload级别索引举荐的简化版本，在Query级别，索引举荐是为单个慢查问举荐缺失的索引，以改善其性能。2.1 基于代价的索引举荐基于代价的索引举荐[3]大多聚焦于Workload级别的索引举荐，呈现在查问中每一列或者列的组合都能够看作是一个可能改善Workload代价的候选索引，所有的候选索引形成了一个微小的搜寻空间（候选索引汇合）。 基于代价的索引举荐的指标，是在候选索引汇合中搜寻出一组最优索引汇合，以最大水平地改善Workload代价。如果候选索引的个数N，限度的最大举荐索引个数是M，那么最优索引汇合的搜寻空间是： $$ C_{N}^{M}=\frac{N *(N-1) \ldots(N-M+1)}{M !} $$ 这是一个属于NP-hard领域的搜寻问题[4]。目前，基于代价的索引举荐办法大多会采纳“贪婪策略”来简化搜寻过程，但这可能会导致最初举荐出的索引是次优解[5]。 2.2 基于AI+数据驱动的索引举荐基于AI+数据驱动的索引举荐聚焦于Query级别的索引举荐，出发点是在某个数据库中因为缺失索引导致的慢查问，在其它数据库中可能有类似的索引创立案例：这些查问语句类似，因而在类似地位上的列创立索引也可能带来相似的收益。例如下图中，查问q_s和q_t在语句构造和列类型上十分类似。因而，咱们能够通过学习查问q_s的索引创立模式来为查问 q_t举荐缺失的索引。 对于不同列数的索引举荐，咱们会别离训练基于XGBoost的二分类模型。例如，咱们目前最高反对三列的索引举荐，因而会别离训练一个单列索引举荐模型、一个两列索引举荐模型和一个三列索引举荐模型。对于给定的一个单列候选索引和它对应的慢查问，咱们应用单列索引举荐模型来判断该单列候选索引是否可能改善该慢查问的性能。 同样的，对于给定的一个两列（三列）候选索引和它对应的慢查问，咱们应用两列（三列）索引举荐模型来判断这个两列（三列）候选索引是否可能改善该慢查问的性能。如果一条慢查问中蕴含的候选索引个数为N，那么则须要N次模型预测来实现对这条慢查问的索引举荐。 3 整体架构基于AI+数据驱动的索引举荐的整体架构如下图所示，次要分为两个局部：模型训练和模型部署。 3.1 模型训练如上文所述，咱们收集DAS平台基于代价的慢查问优化倡议每天的索引举荐数据（包含慢查问和被验证无效的举荐索引）作为训练数据。咱们生成每条查问的单列、两列和三列候选索引，并通过特色工程来为每个候选索引构建特征向量，应用索引数据来为特征向量打标签。之后，单列、两列和三列特征向量将别离用于训练单列、两列和三列索引举荐模型。 3.2 模型部署针对须要举荐索引的慢查问，咱们同样生成候选索引并构建特征向量。接下来，咱们应用分类模型来预测特征向量的标签，即预测出候选索引中的无效索引。随后，咱们在采样库上创立模型预测出的无效索引，并通过理论执行查问来察看建设索引前后查问性能是否失去改善。只有当查问性能真正失去改善时，咱们才会将索引举荐给用户。 4 建模过程4.1 生成候选索引咱们提取查问中呈现在聚合函数、WHERE、JOIN、ORDER BY、GROUP BY这些关键词中的列作为单列候选索引，并对这些单列候选索引进行排列组合来生成两列和三列候选索引。同时，咱们会获取查问所波及的表中曾经存在的索引，并将其从候选索引汇合中删除。这一步骤遵循索引的最左前缀准则：如果存在索引Idx (col1, col2)，那么候选索引 (col1) 和 (col1, col2) 都将从候选索引汇合中删除。 4.2 特色工程一个候选索引的特征向量包含语句特色和统计特色两局部。语句特征描述了候选索引列在查问中的呈现地位（采纳one-hot的编码方式），统计特征描述了候选索引列的统计信息，如所在表的表行数、Cardinality值、选择率等，这些是判断是否须要在候选索引列上建设索引的重要指标。 下表以单列候选索引 (col1) 为例，展现了它的局部重要特色及其含意： 两列候选索引 (col1, col2) 的特色是通过对单列候选索引 (col1) 和 (col2) 的特色进行拼接而成的，此外，咱们还会计算 col1 和 col2 独特的Cardinality值作为两列候选索引 (col1, col2) 的额定统计特色，以更加全面地形容其统计信息。同样地，咱们也会采纳应用这种形式来构建三列候选索引 (col1, col2, col3) 的特色。在生成完一条查问的特征向量之后，咱们应用这条查问应用到的索引来为生成的特征向量打标签。 4.3 建模举例下图以查问 q_1 为例，展现咱们为训练集中的一条查问生成特征向量并打标签的过程。查问 q_1 波及两张表customer表和warehouse表，其中customer表的c_w_id、c_id、c_d_id、c_last四列参加到查问中，因而对应生成四条单列特征向量；warehouse表的w_id列参加到查问中，因而只生成了一条单列特征向量。查问 q_1 应用的单列索引为Idx(w_id)，所以单列候选索引 (w_id) 对应的特征向量被标记为正样本，其余特征向量则被标记为负样本。 ...

随着举荐算法技术的一直倒退，跨场景学习曾经受到了越来越多的钻研人员的关注。美团到餐算法团队受到业界相干技术的启发，一直摸索到店餐饮多场景举荐的优化问题，在多场景多任务学习的举荐畛域中积攒了较多的利用教训。团队应用到店餐饮全域举荐场景数据训练对立的多场景多任务学习模型，缩小了重复性开发，并在多个到店餐饮举荐场景进行落地，获得了较为显著的成果。本文具体论述了美团到店餐饮业务中多场景多任务学习的解决方案，基于该计划造成的学术论文《HiNet: Novel Multi-Scenario & Multi-Task Learning with Hierarchical Information Extraction》曾经被国内数据工程会议ICDE 2023收录。 1. 背景随着网络信息和服务的爆炸式增长，举荐零碎曾经成为为用户提供高质量个性化决策倡议和体验的要害组件。传统的举荐零碎，模型服务通常须要为特定场景独自进行定制化的开发，以适配不同场景下数据分布和特色空间的差别。然而在美团等工业互联网平台中通常存在多种多样的举荐场景（例如首页信息流、垂类子频道等）作用于用户拜访的决策链路，同时基于每个场景的个性化举荐模型再对展现我的项目进行排序最终出现给用户。 在美团到店餐饮（以下简称到餐）平台中，随同业务精细化的发展趋势，越来越多的场景须要对举荐零碎进行定制化的建设，以满足用户到店就餐的个性化需要。如下图1所示，事实中用户往往会在多个不同场景之间进行浏览、点击，并最终成交。 但随着举荐场景数量的减少，传统地针对单个场景独立开发举荐模型，往往会导致如下问题： 仅依据单场景本身的数据进行建模，无奈利用到用户在跨场景中丰盛的行为信息，漠视了场景共性信息，特地是思考到多种场景中可能会存在反复展现的商品（在上图1中，红色矩形框圈中的其实是雷同的商品）。一些长尾的业务场景因为流量较小且用户行为较为稠密，数据量不足以让模型无效地进行建模。因为每个场景的特色开掘、模型训练和上线部署是独立开发且互相隔离的，这会大大增加计算成本和保护累赘。总的来讲，举荐算法对各场景独自建模存在诸多的局限性。然而，简略地将多个场景数据集进行合并训练一个排序模型来提供服务，并不能无效地捕捉到每个场景的特有信息。 此外，除了多场景举荐问题，每个场景中的用户满意度和参与度等通常都存在不同的掂量指标须要独特优化，例如点击率（CTR）和点击转化率（CTCVR）。因而须要开发一个无效和对立的框架，来解决这种在多个场景中优化各种指标复杂性的问题（即多场景多任务优化问题）。 在最近的一些钻研中，相干办法往往是将多场景举荐做为一个多任务学习（Multi-Task Learning，MTL）问题进行建模，并且此类办法大多应用多门控混合专家（Multi-gate Mixture-of-Experts，MMoE）网络框架作为模型改良的根底来学习场景之间的共性和个性。然而，这种基于MTL的办法往往将多个场景的数据信息投影到同一个特色空间进行优化，这很难充沛捕捉到具备多个工作的泛滥场景之间的简单关系，因而也无奈进一步晋升多场景多任务学习模型的性能。 从直觉来看，多场景和多任务的信息建模应属于不同档次的优化，应该进行分层解决。因而，在本文中，咱们提出了一种层次化信息抽取网络（Hierarchical information extraction Network，HiNet）。具体来说，咱们设计了一个端到端的两层信息抽取框架，来独特建模场景间和工作间的信息共享和合作。 首先，在场景抽取层（Scenario Extraction Layer），HiNet可能通过独自的专家模块提取场景共享信息和场景特有信息。为了进一步增强对以后场景的示意学习，咱们设计了场景感知注意力网络（Scenario-aware Attentive Network，SAN），显式学习其余场景对以后场景的信息表征奉献水平。 而后，在工作抽取层（Task Extraction Layer），利用自定义的由工作共享和工作特有专家网络组成的门控网络，无效地缓解了多任务学习中共享信息和工作特有信息之间的参数烦扰。 通过在模型构造上拆散场景层和工作层的信息提取，能够将不同场景下的多个工作明确划分到不同的特色空间中进行优化，从而有利于晋升模型性能。 整个论文的次要翻新点如下： 咱们提出了一种新鲜的多场景多任务学习模型HiNet，用于优化多场景下的多种工作指标，其中创新性地利用了分层信息抽取架构。在场景信息抽取层中，咱们提出了场景感知注意力网络SAN模块，进一步加强了场景信息建模的能力。离线评估和在线A/B测试的试验证实了HiNet优于以后次要办法。目前，HiNet已在美团到餐中的两个场景中进行了全面部署。2. 层次化信息抽取网络2.1 问题定义 原始的特色输出中次要包含了用户画像特色、用户行为特色、以后场景特有特色和商品特色，其中的数值特色首先被转化为分类特色，而后将所有分类特色映射到低维向量空间来取得$x$。思考到美团到餐平台中具体的优化指标，咱们别离为每个场景设置了CTR和CTCVR两个工作。 2.2 办法介绍本大节将开展介绍层次化信息抽取网络模型HiNet。如下图2-(A)所示，HiNet模型中次要包含场景抽取层和工作抽取层两个外围模块。其中在场景抽取层次要包含了场景共享专家（Scenario-shared expert）模块、以后场景特有专家（Scenario-specific expert）模块以及场景感知注意力网络，通过这三局部的信息抽取，最终造成了场景档次的信息表征；而在工作抽取层中，咱们应用自定义门控网络模块CGC（Customized Gate Control）来对以后场景的多任务学习进行建模。下文将具体介绍上述提到的HiNet模型的要害局部。 2.2.1 场景抽取层（Scenario Extraction Layer）场景抽取层的作用是提取场景特有的信息表征和场景间共享的有价值信息表征，这是进步工作档次信息表征能力的根底。在场景抽取层，次要包含场景共享专家网络、场景特有专家网络和场景感知注意力网络三局部，下文将顺次进行介绍。 场景共享/特有专家网络思考到用户跨场景的交叉式行为以及多个场景间商品重叠的景象，到餐业务中多个场景的数据之间存在着有价值的共享信息。因而在策略上，咱们设计了场景共享专家网络。这里受到混合专家网络架构MoE（Mixture of Expert）的影响，场景共享专家网络是通过应用子专家集成模块SEI（Sub-Expert Integration module，如图2-(C)）生成的。 具体来说，场景共享专家网络的最终输入为$G$，其公式为： 场景感知注意力网络如上文所述，不同场景之间存在肯定水平的相关性，因而来自其余场景的信息也能够对以后场景的信息表征做出奉献，从而加强以后场景的信息表达能力。思考到不同场景间对彼此的表征能力奉献不同，咱们设计了场景感知注意力网络（Scenario-aware Attentive Network，SAN）来掂量其余场景信息对以后场景信息表征奉献的重要性。具体来说，SAN蕴含两局部输出： 2.2.2 工作抽取层（Task Extraction Layer）为了解决多任务学习中的负迁徙问题，在工作抽取层，咱们受到PLE（Progressive Layered Extraction）模型的启发，采纳了自定义门控网络CGC模块。 自定义门控网络 ...

当你和智能语音机器人对话交互时，你是否好奇电话背地的机器人如何“听懂”你的意思，又如何像人一样“答复”你的问题？其中比拟重要的技术就是 MRCP。本文次要介绍了 MRCP 在美团语音交互中的实际和利用，基于美团自研的语音辨认及语音合成能力，咱们晋升了外呼通话的成功率，并且保障了更好的用户体验。一、背景智能语音对话作为人工智能畛域最先落地的分支之一，能够实现与人进行自然语言多轮对话，其核心技术在近年来一直地倒退成熟，包含语音辨认、自然语言了解、对话治理等。随同着技术的成熟，越来越多的电话机器人开始走进咱们的生存，这些电话机器人在客户服务、智能销售、告诉触达等场景施展着重要的作用。 当你和智能语音机器人对话交互时，你是否好奇电话背地的机器人如何“听懂”你的意思，又如何像人一样“答复”你的问题？经典的技术实现门路是：机器人首先通过“语音辨认（ASR）”将用户输出语音辨认成文字，再通过“自然语言了解（NLU）”辨认用意，之后依据用意、零碎信号等输出联合对话治理技术失去相应的回复，最初通过“语音合成（TTS）”生成语音播报给电话对端的用户。但要将 ASR、TTS 这些技术利用到电话零碎上，还须要一些额定的工作和技术撑持，其中比拟重要的技术之一也就是本文将要介绍的 MRCP。 备注：本文波及较多的专业名词，咱们特地在文末附上了名词解释，以帮忙大家进行浏览。 1.1 MRCP 是什么MRCP（Media Resource Control Protocol, MRCP）是一种通信协定，中文定义是：媒体资源控制协议，用于语音服务器向客户端提供各种语音服务（如语音辨认和语音合成）。该协定定义了管制媒体解决资源所必须的申请（Request）、应答（Response）和事件（Event）等音讯，它须要借助 RTP（Real-Time Transport Protocol, 实时传输协定）创立一个媒体会话、借助 SIP（Session Initiation Protocol, 会话初始化协定） 和 SDP（Session Description Protocol, 会话形容协定） 创立一个管制会话来实现媒体资源服务器端和客户端之间的管制[1]。 在传统的语音利用中，各集成商必须针对不同的 ASR/TTS 厂商提供的 API 接口进行专门的集成开发，不同 ASR/TTS 引擎的接口各不相同，从而导致了集成过程的复杂性和局限性。因而，在实现语音和网络技术集成方面必须须要比拟标准的协定来进行解决。MRCP 协定是目前针对媒体资源和 IP 网络起草的标准协议。有了 MRCP 协定后，ASR/TTS 厂商提供 MRCP 协定的规范对立接口，语音集成开发商们不用再针对特定的 ASR/TTS 进行开发，为各种语音利用开发提供了更加灵便的抉择，并无效地升高业务开发周期和老本[2]。 以语音合成（TTS）为例，图 1 展现了一个 MRCP 客户端连贯媒体资源服务器的流程，在连贯中会创立一个媒体会话和一个管制会话。假如连贯胜利，此时 MRCP 客户端对服务器端发动了一个 SPEAK 语音合成的申请，解决此申请的过程中包含了3个音讯指令：SPEAK指令示意发送语音合成申请，IN-POGRESS指令示意正在解决中，SPEAK—COMPLETE指令示意解决实现[3]。 MRCP 协定的音讯格局和 HTTP 音讯格局相似，如下以一次语音合成的 MRCP 音讯为例，展现了 MRCP 音讯的次要形成。 发动语音合成申请： MRCP/2.0 380 SPEAK 14321Channel-Identifier: 43b9ae17@speechsynthContent-Type: application/ssml+xmlContent-Length: 253您好，有什么能帮忙您？IN-PROGRESS 响应音讯： ...

美团根底研发平台视觉智能部与中科院计算所开展科研课题单干，独特构建大规模数据集Food2K，并提出渐进式区域加强网络用于食品图像识别，相干研究成果已发表于T-PAMI 2023。本文次要介绍了数据集特点、办法设计、性能比照，以及基于该数据集的迁徙试验等方面的内容，并对Food2K将来的工作进行了瞻望。心愿能为从事相干工作的同学带来一些帮忙或者启发。1 引言视觉智能部与中科院计算所于2020-2021年度开展了《细粒度菜品图像识别和检索》科研课题单干，本文系单方联结在IEEE T-PAMI2023公布论文《Large Scale Visual Food Recognition》 (Weiqing Min, Zhiling Wang, Yuxin Liu, Mengjiang Luo, Liping Kang, Xiaoming Wei, Xiaolin Wei, Shuqiang Jiang*) 的解读。IEEE T-PAMI全称为IEEE Transactions on Pattern Analysis and Machine Intelligence，是模式识别、计算机视觉及机器学习畛域的国内顶级期刊，2022年颁布的影响因子为24.314。 食品计算[1]因可能撑持许多食品相干的利用失去越来越宽泛的关注。食品图像识别作为食品计算的一项根本工作，在人们通过识别食物进而满足他们生存需要方面施展着重要作用，如食品养分了解[2,3]和饮食治理[4]等。此外，食品图像识别是细粒度视觉辨认的一个重要分支，具备重要的实践钻研意义。 现有的工作次要是利用中小规模的图像数据集进行食品图像识别，如ETH Food-101[5]、Vireo Food-172[6]和ISIA Food- 500[7]，然而它们的数据规模不足以撑持更简单更先进的食品计算模型的建设。思考到大规模数据集已成为许多惯例图像分类和了解工作倒退的要害推动因素，食品计算畛域也迫切需要一个大规模的食品图像数据集来进一步撑持各种食品计算工作，如跨模态食谱检索和生成[8,9]。因而咱们构建了一个新的大规模基准数据集Food2K。该数据集蕴含1,036,564张食品图像和2,000类食品，波及12个超类（如蔬菜、肉类、烧烤和油炸食品等）和26个子类别。与现有的数据集相比，Food2K在类别和图像数量均超过其一个数量级。除了规模之外，咱们还进行了严格的数据清理、迭代标注和多项业余查看，以保障其数据的品质。 在此基础上，咱们进一步提出了一个面向食品图像识别的深度渐进式区域加强网络。该网络次要由渐进式部分特色学习模块和区域特色加强模块组成。前者通过改良的渐进式训练方法学习多样互补的部分细粒度判断性特色（如食材相干区域特色），后者利用自注意力机制将多尺度的丰盛上下文信息融入到部分特色中，进一步加强特色示意。本文在Food2K上进行的大量试验证实了所提出办法的有效性，并且在Food2K上训练的网络可能改善各种食品计算视觉工作的性能，如食品图像识别、食品图像检索、跨模态菜谱-食品图像检索、食品检测和宰割等。咱们期待 Food2K及在Food2K上的训练模型可能撑持研究者摸索更多的食品计算新工作。本论文相干的数据集、代码和模型可从网站下载：http://123.57.42.89/FoodProject.html。 2 Food2K数据集Food2K同时蕴含东方菜和西方菜，在食品专家的帮忙下，咱们联合现有的食品分类办法建设了一个食品拓扑体系。Food2K包含12个超类（如“面包”和“肉”），每个超类都有一些子类别（如“肉”中的“牛肉”和“猪肉”），每种食品类别蕴含许多菜肴（如“牛肉”中的“咖喱牛肉”和“小牛排”），如下图2所示： 下图3展现了每个食品类别的图像数量，Food2K中每个类别的图像数量散布在[153,1999]之间不等，呈现出显著的长尾散布景象，与类别不平衡性。 下图4展现了Food2K与现有食品图像识别数据集的图像数量比照，能够看到Food2K在类别和图像数量上都远超过它们。 除此之外，Food2K还具备以下特色： 1）Food2K涵盖了更多样化的视觉外观和模式。不同食材组合、不同配饰、不同排列等都会导致同一类别的视觉差别。举例来说，陈腐水果沙拉因其不同的水果成分混合而呈现出不同的视觉外观。这些食品的独特特色导致了更高的类内差别，使大规模的食品图像识别变得更加艰难。 2）Food2K蕴含更细粒度的类别标注。以“Pizza”为例，一些经典的食品数据集，如Food-101，只有较粗粒度的披萨类。而Food2K中的披萨类则进一步分为更多的类别。不同披萨图像之间的轻微视觉差别次要是由独特的食材或同一食材的粒度不同引起的，这也导致了辨认的艰难。所有这些因素使Food2K成为一个新的更具挑战性的大规模食品图像识别基准，能够视为食品计算畛域的“ImageNet”。 3 办法食品图像识别须要开掘食品图像的自身特点，并同时思考不同粒度的图像特色进行辨认。通过观察咱们发现，食品图像有着显著的全局特色和部分特色。 首先，食品图像显著有着全局的外观、形态和其余构造方面的特色，且该特色存在较大的类内差别。如下图5的“奶油核桃饼”显著有着变动不一的形态，炒面有着丰盛多样的纹理。尽管以后曾经有很多办法来解决这一问题，但大多数办法次要集中在提取某种类型的特色，而疏忽了其余类型的特色。 其次，食品图像中有细微差别的细节信息，局部细节信息是其要害的部分特色。在许多状况下，现有的神经网络无奈很好地开掘那些具备判断性的细节特色。如图5中第3栏所示，仅仅依附全局特色是不足以辨别“玉米羹”和“鸡蛋羹”，必须进一步开掘其食材信息的不同（图中黄色框内）。因而，如何更好地开掘食品图像的全局特色和部分特色，对于晋升食品图像特色表达能力来说尤为重要。 第三，如下图6所示，不同的食材在不同的食品类别中所占的权重也是不一样的。“香菜”在“香菜”拌牛肉中是一个关键性食材，必不可少，然而在“老醋海蜇”这道菜中仅仅是一个配料，并不总是呈现在该类别的所有图像中。因而须要开掘部分特色之间的关系，突出重点部分特色。进而进步食品辨认的准确率。 针对上述这些特点，本文设计了深度渐进式区域特色加强网络，它能够独特学习多样化且互补的部分和全局特色。该网络结构如下图7所示，该网络次要由三局部组成：全局特色学习模块、渐进式部分特色学习模块和区域特色加强模块。 其中，渐进式部分特色学习次要采纳渐进式训练策略来学习互补的多尺度细粒度的部分特色，例如不同的食材相干信息。区域特色加强应用自注意力机模块，将更丰盛的多尺度上下文信息合并到部分特中，以加强部分特色示意。而后，咱们通过特色交融层将加强的部分特色和来自全局特色学习模块的全局特色交融到对立的特色中。 此外，在模型训练时，本文逐渐渐进式地训练网络的不同阶段，最初将训练整个网络，并在此过程中引入$KL$散度以减少各个阶段之间的差异性，以捕捉更丰盛多样化的部分信息。在推理阶段，思考到每个阶段的输入特色和交融后的特色之间的互补性，咱们将它们的预测后果联合起来失去最终分类得分。接下来，本文将具体介绍各个模块的计算原理。 全局-部分特色学习食品辨认能够看作是一个层次化的工作，在不同超类下的食品图像有着显著可分的视觉差别，因而能够基于他们的全局特色进行辨认。 然而在同一超类下，不同子类的食品图像之间的差别却十分小。因而食品辨认须要同时学习食品图像的全局特色和部分特色。因而，咱们提取并交融了这两个特色，此过程能够应用两个子网络别离提取食品图像的全局和部分特色。这两个子网络能够是两个独立的网络，然而这部分工作为了提高效率并减小模型参数，本文中两个子网络共享根底网络的大部分层。 全局特色学习 渐进式部分特色学习部分特色子网络旨在学习食品的辨别性细粒度特色。因为食材和烹饪格调的多样性，食品图像的要害判断局部是多尺度和不规则的。作为本办法第一个翻新点，咱们提出了渐进式训练策略来解决这个问题。在这种策略中，咱们首先训练具备较小感触野的网络较低阶段（能够了解为模型中较低的层），而后逐渐扩充该部分区域范畴，并引入新的层退出训练。 这种训练策略将迫使咱们的模型提取更精密的判断性部分特色，例如与食材相干的特色。在此过程之后，咱们从不同层提取特色以取得多尺度的特色示意。 因而，该策略能够首先在网络较浅的层中学习更稳固的细粒度信息，而后随着训练的进行逐步将注意力转移到在较深的层中学习粗粒度信息。具体来说，当具备不同粒度的特色被送入网络时，它能够提取出有判断性的部分细粒度特色，例如食材成分信息。然而，简略地应用渐进式训练策略不会失去多样化的细粒度特色，因为通过渐进式训练学习到的多尺度特色信息可能集中在食品图像中类似的区域。 ...

外卖场景的用户停留时长低于传统电商，对用户实时需要的了解和反馈有更高的要求。针对业务问题，外卖举荐团队从2021年起开始继续投入，最终摸索出了一套实用于外卖场景的交互式举荐架构和策略，并获得了较好的收益。本文具体介绍了外卖首页Feed在搭建交互式举荐时遇到的挑战和解决思路。1. 背景1.1 什么是交互式举荐？交互式举荐是一种互动式实时举荐产品模块，次要通过了解用户需要、以互动的形式进行举荐。交互式举荐由Youtube在2018年提出[1]，次要用于解决举荐零碎的提早[2]和与用户互动偏弱的问题。 从2021年下半年开始，美团外卖举荐技术团队在外卖首页Feed上继续进行摸索，2022上半年实现全量。具体流程如视频1所示：用户从首页Feed进入商家详情页并退出之后，动静地插入新的举荐内容到用户举荐列表中。其次要劣势是依据用户的实时需要动静插入卡片进行反馈，进而加强用户的应用体验。 视频1 外卖首页Feed中的交互式举荐状态 1.2 为什么须要交互式举荐？咱们发现，外卖首页Feed在用户即时趣味的捕获和反馈上存在痛点，“比照型”用户的选购效率和体验不佳。外卖首页Feed作为泛用意用户次要选购场景之一，用户在浏览到成单过程中通常须要进行一番比照、能力逐渐收敛用意，而后做出最终决策。 但受限于长列表的翻页模式，首页Feed依据用户需要实时调整举荐后果的能力有余。具体表现在，一部分用户的浏览深度有余一页，举荐零碎没有额定的机会依据用户趣味调整举荐后果。另一部分用户尽管有较深的浏览深度，但须要等到翻页时举荐零碎能力从新了解用户用意，实时性有余。 业界优化这类问题的次要产品状态有交互式举荐、动静翻页、端上重排这三种。交互式举荐因为是在用户可视范畴内插入，用户感知较强；后两种的支流状态是在用户不可见区域更新举荐，用户感知绝对较弱。其实，这三种状态在美团外卖均有尝试，本文重点聚焦于交互式举荐的介绍。 2. 问题与挑战咱们在外卖场景搭建交互式举荐时，次要面临以下难点和挑战： 不同于传统的举荐零碎，交互式举荐是由用户触发的举荐，外卖场景下，如何更好的匹配用户实时需要，搭建出一套实用于外卖的、基于端智能框架的举荐零碎是咱们首要解决的问题。作为首页Feed外部的个性化模块，交互式举荐只做繁多模块的优化是不够的，还要思考首页Feed整体的访购效率。那么，如何抉择优化指标，以及如何掂量成果和收益，是摆在咱们背后的第二个问题。支流的Feed状态是双列商品瀑布流，但外卖首页Feed是以商家为主的单列列表，如何防止交互在用户的抉择门路上带来的“烦扰感”，在适合的机会触发交互式举荐，是咱们面临的第三个问题。交互式举荐具备动静插入成果，用户对于举荐后果好与坏的感触会更加显著。如何更好了解用户即时用意，如何利用首页Feed列表举荐后果优化交互式举荐的单商家卡片，是咱们面临的第四个问题。本文将从以上四个方面，具体介绍外卖首页Feed交互式举荐从0到1搭建的全过程，以及针对以上问题的解决思路。 3. 次要工作3.1 交互式举荐框架3.1.1 整体链路上文提到，要实现交互式举荐，搭建出一套实用于外卖的、基于端智能框架的举荐零碎十分重要。搭建思路能够用“4W1H”来总结： Where/How：交互式举荐卡片展现在哪？交互式举荐卡片的展示模式是什么？波及产品状态。Who/When：交互式举荐须要对什么样的用户触发？在什么机会下触发？波及用户用意了解。What：交互式举荐卡片须要展现什么？波及举荐策略。基于对上述问题的思考和多方探讨，咱们最终和产品、端智能、客户端、应用服务和举荐工程等多个相干团队一起，搭建了这套实用于外卖首页Feed的交互式举荐链路。 上图1展现了从“用户点击首页Feed商家卡片”开始，到交互式举荐卡片展示”的全流程。用户进入点菜页后，由客户端调用端智能的用意了解引擎；满足交互式举荐的触发条件后，进行特色解决、计算和存储，并将计算好的将特色传递给客户端组装举荐申请；举荐申请由应用服务层透传给混排服务，再由混排调用商家举荐模块，通过召回、排序、机制、透出阶段，最终返回后果到客户端进行展现。 3.1.2 产品状态文章结尾局部的视频1是咱们线上的最终状态（在用户点击商家下方插入单个商家卡片），但在此之前，咱们对交互式举荐的卡片状态和交互逻辑进行了多轮尝试。 在卡片状态上，咱们先后摸索、上线了搜索词卡片、多商家聚合卡片（如视频2所示）、单商家卡片（如视频所示）等多种状态，测试不同卡片类型对用户选购的影响。在交互逻辑上，为了防止插入动画对用户选购的“烦扰感”，也比照了“在点击卡片上笼罩”和“在点击卡片下方插入”两种交互，测试对于用户选购的影响。视频2 交互式举荐双商家卡片展现款式 在观测不同产品状态的成果差别时，咱们重点关注插入的交互式卡片对于首页Feed的千人成交额的影响，试验数据见下表： 其中，UV_CXR = 交易用户数/曝光人数。 在摸索过程中，咱们也迭代了以下3点认知： 首先，单列列表中，越原生的卡片（和支流卡片类似度高），对于用户的烦扰越小，也更容易被用户承受，从而产生点击、成单等行为。其次，不论是搜索词举荐，还是多商家聚合举荐，只管看上去外露供应更多，但在转化链路中减少了落地页环节，理论带来的折损会更高（如下图2所示）；同时，因为交互式举荐要保障肯定的相关性，落地页状态对于供应丰盛度的要求更高，然而LBS（基于地位）举荐中供应绝对更少，因此难度也更大。另外，在用户选购过程中，“多店比照”是十分常见的场景，因而，将点击商家覆盖住只管节约了一个坑位，但带来的负向影响要大于其正向收益。 3.2 评估形式和评估指标交互式举荐的指标是晋升首页Feed整体访购效率，进而晋升用户体验。评估其收益的外围指标，落脚到首页Feed整体转化效率。然而，交互式举荐有触发策略约束条件（详见3.3节），流量占比也较低，同时和首页Feed在用户成单上存在“挤占”效应。当交互式卡片的访购效率有较大幅度晋升时，能力撬动首页Feed的整体效率。因而，只观测首页Feed整体效率，无奈领导交互式举荐的日常策略的迭代和成果的剖析，须要更间接、相信的指标掂量“什么是好的交互式举荐算法”。 咱们评估交互式举荐算法，次要思考两个维度： 插入卡片的覆盖面插入卡片的匹配度为了应答以上两个维度的评估，咱们别离引入“曝光页面Page占比”、“同地位订单增量”来掂量交互式举荐对首页Feed曝光的影响。 评估覆盖面，常见指标是曝光量、曝光占比。但交互式举荐卡片插入后会扭转首页Feed曝光量，间接计算其在首页Feed的曝光占比不合理。因而，咱们将统计曝光的维度从“量”改为“页面”，通过计算交互式卡片曝光Page数在首页曝光Page数的占比来评估卡片覆盖面。 观测Page占比（下文简称“曝光页面Page占比”）便于评估交互式举荐的覆盖面和其实践下限的差别，如果用户在首页Feed的每次点击商家都触发并展现交互式商家卡片，曝光Page占比和首页Feed的Page CTR（曝光点击率）等同。因而，联合首页Feed的Page CTR，咱们就能够察看到交互式举荐覆盖面和其实践下限的差距，便于持续优化迫近下限。曝光页面page占比对同一页面屡次触发不敏感，因而，咱们引入了交互式卡片曝光PV占比（交互式卡片曝光量占首页Feed曝光量的比值）、曝光UV（曝光交互式卡片的用户占首页Feed曝光用户的比值）占比辅助观测对首页Feed的影响。 评估匹配度，常见指标是曝光到成单的转化率。咱们认为，交互式举荐插入的商家应该比上下文中的其余商家更合乎用户以后的趣味。因而，最直观的指标就是比照交互式卡片和首页Feed其余卡片的转化率，但这两类卡片比照，会存在三种偏差： 人群偏差：交互式举荐曝光人群是产生过点击的用户，这部分用户群体的转化率人造高于“大盘”。地位偏差：交互式举荐卡片由用户点击触发，因为排在后面的商家往往更容易被点击，因而交互式卡片的曝光地位绝对更加靠前。资源类型偏差：首页Feed列表波及较多主题、广告等异构流量，大部分异构流量往往并不是从转化率登程进行排序。上述3个偏差，使得交互式卡片转化率人造比首页Feed其余卡片转化率高，因而简略比拟交互式卡片和首页Feed失常卡片之间的差别并不能正确评估交互式举荐自身的价值。而交互式举荐的产品个性是将原来曝光在首页Feed的卡片顺次往后挤压，因而只有当交互式举荐卡片的转化率高于本来该地位的卡片（也就是起初被挤压到交互式卡片的下一位的卡片）的时候，交互式举荐能力产生侧面成果。 基于此，咱们应用“比照同一次申请内，与下一位天然商家预估转化率的绝对差别”（下文简称绝对下一位差别）来掂量举荐卡片的匹配度，“同申请”解决了人群偏差问题，“下一位”缓解地位偏差问题，“天然商家”解决了资源类型偏差问题。 此外，扩充覆盖面通常会引起匹配度的降落，为了均衡这两个指标，咱们引入“绝对下一位差别乘以交互式卡片曝光量”作为策略迭代的辅助观测指标，其物理意义是插入交互式卡片并将原来的卡片往下挤压之后，在该地位产生的预期订单数的增量（下文简称“同地位订单增量”）。 3.3 用户用意了解交互式举荐，由举荐零碎感知到用户的“交互”触发。其了解用户用意的流程次要蕴含两个阶段：1）用户对举荐零碎的哪些行为能够触发交互式举荐；2）触发交互式举荐时用户的即时用意是什么样的。下文将会围绕这两局部开展阐明。 3.3.1 首次触发策略为了摸索不同触发机会对交互式卡片“绝对下一位差别”、“曝光页面Page占比”等指标的影响，咱们依据用户的不同需要，尝试了加购物车、点击菜品、停留时长（10s/5s/2s/进店立刻）触发等机会。试验证实，放宽触发条件会增大交互式举荐不相信触发的危险，导致交互式卡片效率降落，但会带来交互式卡片曝光量的晋升，笼罩更多的用户，有利于后续策略迭代。最终，咱们采纳“用户从首页Feed进店后立刻触发”的首次触发策略。 3.3.2 间断触发策略因为用户在商家详情页的停留时长无奈确定，且工程上无奈实现在用户返回列表的霎时申请举荐服务并展现后果，因而，在用户浏览商家详情页期间，零碎须要间断屡次向服务端申请举荐后果，用户在商家详情页的停留时长越长、需要越明确，服务端的举荐后果也就越精准。所以，咱们采纳“间断触发策略”，即随着用户在店内停留时间的减少，或者用户产生新的菜品点击、加购特色后，客户端会间断屡次向后端服务发动申请，更新举荐后果。 3.3.3 用户实时需要了解如何通过端智能[3-4]更好了解用户用意是咱们关注的重点，相比服务端，用户在端上的特色次要有以下2个特点： 实时性更好：从“准实时”到“超实时”的交互。维度更细：从“交互Item”进化到“Item交互的Micro-粒度”。因而，借助端智能的能力，咱们不再受限于首页Feed的分页申请更新机制，可能依据用户行为，更好了解用户需要，实时智能决策更新举荐后果，缓解反馈信号感知提早问题。 用户点击商家卡片后在店内的次要行为能够帮忙咱们更好了解用户实时需要。图4(a)展现了局部店内行为，图4(b)剖析了局部不同的行为比照查看商家介绍行为，在用户当日完单率（当日完单率定义：当日用户在商家内产生某一行为，并在该天然日内外卖有成单）上的差别，阐明不同行为下用户的需要有显著差别。 3.4 举荐排序策略首页Feed一次展现整个列表，而交互式举荐一次仅展现1个商家卡片。为了举荐更精准的后果，就须要交互式举荐更精确的了解用户实时的外卖需要。因而，咱们在首页Feed的举荐链路的根底上，通过优化“召回->排序->机制->透出”链路，笼罩更多用户的同时，一直晋升交互式举荐和用户趣味的匹配度。 3.4.1 召回召回阶段分为两步（如下图5所示）： 利用多个召回算法策略从用户左近召回数百个候选POI商家。利用类似品类过滤计划来过滤和以后用户用意显著不同的商家，并将生成的候选后果传给排序阶段。为更好了解用户即时用意，咱们提出了Item2Item Multi-Trigger召回和类似品类过滤计划。 首先，一方面，咱们间接复用了首页Feed举荐的召回链路，交融了双塔召回[5]、User2Item召回[6]、热销召回等多个召回算法。另一方面，为了增强对用户即时用意的了解和关注，咱们新增了一路Item2Item Multi-Trigger旁路召回。 具体做法是：咱们将用户在首页Feed点击、加购的POI，作为Item2Item召回的Trigger，召回更多合乎用户即时用意的商家。其中每个用户的Trigger数是不同的，每个Trigger召回的商家数量也是不同的，其数量满足N/M（N是I2I Multi-Trigger召回的POI总数，M是Trigger数量）。 其次，用户最近点击的商家可能帮咱们更好了解用户即时用意。咱们思考到外卖场景“比照型”用户居多的特点，为了给用户带来更好的体验，提出了“同叶子品类”策略：束缚了曝光的交互式卡片商家，必须和触发商家的叶子品类（体现的是商家口味，和主营菜品无关，比方串串香、鸡肉卷）雷同。然而该计划会带来2个问题： LBS束缚下同叶子品类商家较少，导致交互式卡片曝光量少。外卖场景下商家品类定义的粗细（每个商家蕴含由粗到细的多个级别的品类）粒度不同，交互式举荐须要一套对立的品类定义形式，既要保障举荐商家品类与用户趣味的高相关性，又须要举荐后果有肯定的多样性。因而，咱们参考了现有商家品类定义，思考了商家口味、消费者相似性以及商家蕴含的商品品类散布等维度，通过聚类的办法从新定义了交互式举荐的类似品类。具体来说，咱们将200个左右的细粒度的品类，定义为70个左右的粗粒度品类，在满足“比照型”用户诉求的同时，也为更多用户带来了新颖性、多样性的体验。 ...

面对在线推理服务应用的GPU资源一直减少、GPU利用率广泛较低的挑战，美团视觉研发团队决定通过模型构造拆分和微服务化进行优化，他们提出一种通用高效的部署架构，来解决这种常见的性能瓶颈问题。以“图像检测+分类”服务为例，优化后的服务压测性能指标GPU利用率由40%晋升至100%，QPS也晋升超过3倍。本文将会重点介绍推理服务部署架构优化的工程实际，心愿对大家能有所帮忙或启发。0. 导读美团视觉面向本地生存服务，在泛滥场景上落地利用了文字辨认、图像品质评估、视频了解等视觉AI技术。此前，在线推理服务应用的GPU资源一直减少，但服务GPU利用率广泛较低，节约大量计算资源，减少了视觉AI利用老本，这是美团也是很多企业亟需解决的问题。 美团视觉智能部通过试验剖析发现，造成视觉推理服务GPU利用率低下的一个重要起因是模型构造问题：模型中预处理或者后处理局部CPU运算速度慢，导致推理骨干网络无奈充分发挥GPU运算性能。基于此，视觉研发团队通过模型构造拆分和微服务化，提出一种通用高效的部署架构，解决这种常见的性能瓶颈问题。 目前，该解决方案曾经在多个外围服务上胜利利用。以“图像检测+分类”服务为例，优化后的服务压测性能指标GPU利用率由40%晋升至100%，QPS晋升超过3倍。本文将会重点介绍推理服务部署架构优化的工程实际，心愿对从事相干工作的同学们有所帮忙或启发。 1. 背景随着越来越多的AI利用进入生产利用阶段，推理服务所须要的GPU资源也在迅速减少。调研数据表明，国内AI相干行业推理服务的资源使用量占比曾经超过55%，且比例将来还会继续升高。但很多公司面临的理论问题是，线上推理服务GPU利用率广泛较低，还具备很大的晋升空间。 而造成服务GPU利用率低的重要起因之一是：推理服务自身存在性能瓶颈，在极限压力状况下也无奈充分利用GPU资源。在这种背景下，“优化推理服务性能、进步GPU资源应用效率、升高资源应用老本”具备十分重要的意义。本文次要介绍如何通过架构部署优化，在保障准确率、推理时延等指标的前提下，晋升推理服务的性能和GPU利用率。 2. 视觉模型服务的特点与挑战近年来，深度学习办法在计算机视觉工作上获得显著停顿，曾经成为支流办法。视觉模型在结构上具备一些特殊性，如果应用现有推理框架部署，服务在性能和GPU利用率方面可能无奈满足要求。 2.1 模型优化工具与部署框架深度学习模型部署前通常会应用优化工具进行优化，常见的优化工具包含TensorRT、TF-TRT、TVM和OpenVINO等。这些工具通过算子交融、动静显存调配和精度校准等办法进步模型运行速度。模型部署是生产利用的最初一环，它将深度学习模型推理过程封装成服务，外部实现模型加载、模型版本治理、批处理以及服务接口封装等性能，对外提供RPC/HTTP接口。业界支流的部署框架有以下几种： TensorFlow Serving：TensorFlow Serving（简称TF-Serving）是Google公布用于机器学习模型部署的高性能开源框架，外部集成了TF-TRT优化工具，然而对非TensorFlow格局的模型反对不够敌对。Torch Serve：TorchServe是AWS和Facebook联合推出的Pytorch模型部署推理框架，具备部署简略、高性能、轻量化等长处。Triton：Triton是Nvidia公布的高性能推理服务框架，反对TensorFlow、TensorRT、PyTorch和ONNX等多种框架模型，实用于多模型联结推理场景。在理论部署中，无论抉择哪种框架，须要同时思考模型格局、优化工具、框架性能特点等多种因素。 2.2 视觉模型特点与传统办法不同， 深度学习是一种端到端的办法，不须要独自设计特征提取、分类器等模块，用单个模型取代传统办法多模块工作。深度学习模型在分类、检测、宰割、辨认等视觉工作上呈现出微小劣势，做到了传统办法无奈达到的精度。罕用的视觉分类模型（如ResNet、GoogleNet等）和检测模型（如YOLO、R-FCN等）具备如下特点： 网络层数多（适宜用GPU运算）：以ResNet-50为例，网络蕴含49个卷积层和1个全连贯层，参数量高达2千5百万，计算量达到38亿FLOPs（浮点运算数）。模型推理蕴含大量矩阵计算，适宜用GPU并行减速。输出图像尺寸固定（须要预处理）：同样以ResNet-50为例，网络的输出是图像浮点类型矩阵，尺寸大小固定为224x224。因而二进制编码图片在送入网络前，须要做解码、缩放、裁切等预处理操作。2.3 视觉推理服务面临的问题与挑战因为视觉模型存在的上述特点，导致模型在部署和优化上存在2个问题： 模型优化不彻底：TensorRT、TF-TRT等工具次要针对骨干网络优化，但疏忽了预处理局部，因而整个模型优化并不充沛或者无奈优化。例如分类模型中ResNet-50所有网络层都能够被优化，但预处理中的图像解码（通常是CPU运算）操作"tf.image.decode"会被TF-TRT疏忽跳过。多模型部署艰难：视觉服务常常存在组合串接多个模型实现性能的状况。例如在文字辨认服务中，先通过检测模型定位文字地位，而后裁切文字所在位置的部分图片，最初送入辨认模型失去文字辨认后果。服务中多个模型可能采纳不同训练框架，TF-Serving或Troch Serve推理框架只反对繁多模型格局，无奈满足部署需要。Triton反对多种模型格局，模型之间的组合逻辑能够通过自定义模块（Backend）和集成调度（Ensemble）形式搭建，但实现起来较为简单，并且整体性能可能存在问题。这两点常见的模型部署问题，导致视觉推理服务存在性能瓶颈、GPU利用率低，即使Triton这种高性能部署框架也难以解决。 通用部署框架重点关注的是“通信形式、批处理、多实例”等服务托管方面的性能问题，但如果模型自身两头某个局部（如图像预处理或后处理）存在瓶颈，优化工具也无奈优化，就会呈现“木桶效应”，导致整个推理过程性能变差。因而，如何优化推理服务中的模型性能瓶颈，依然是一件重要且具备挑战性的工作。 3. GPU服务优化实际分类和检测是两种最根底的视觉模型，常利用在图像审核、图像标签分类和人脸检测等场景。上面以两个典型服务为案例，单个分类模型和“分类+检测”多模型组合的应用状况，来介绍具体性能的优化过程。 3.1 图像分类模型服务优化美团每天有千万量级的图片须要审核过滤有危险内容，人工审核老本太高，须要借助图像分类技术实现机器主动审核。罕用的分类模型构造如图1，其中预处理局部次要包含“解码、缩放、裁切”等操作，骨干网络是ResNet-50。预处理局部接管图像二进制流，生成骨干网络须要的矩阵数据Nx3x224x224（别离代表图片数量、通道数、图像高度和图像宽度 ），骨干网络预测输入图片分类后果。 模型通过TF-TRT优化后的理论构造如下图2所示，骨干网络ResNet被优化为一个Engine，但预处理局部的算子不反对优化，所以整个预处理局部依然放弃原始状态。 3.1.1 性能瓶颈模型通过TF-TRT优化后应用TF-Serving框架部署，服务压测GPU利用率只有42%，QPS与Nvidia官网颁布的数据差距较大。排除TF-TRT和Tensorflow框架等可能影响的因素，最终聚焦在预处理局部。Nvidia进行性能测试的模型没有预处理，间接输出Nx3x224x224矩阵数据。但这里的线上服务蕴含了预处理局部，压测指标CPU利用率偏高。查看模型中各个算子的运行设施，发现模型预处理大部分是CPU运算，主干网路是GPU运算（具体细节参见图1）。 如下图3所示，通过NVIDIA Nsight System（nsys）工具查看模型运行时的CPU/GPU执行状况，能够发现GPU运行有显著距离，须要期待CPU数据筹备实现并拷贝到GPU上，能力执行骨干网络推理运算，CPU处理速度慢导致GPU处于饥饿状态。联合服务压测的CPU/GPU利用率数据能够看出：预处理局部CPU耗费高、处理速度慢，是推理服务的性能瓶颈。 3.1.2 优化办法如下图4所示，针对预处理CPU耗费过高影响推理服务性能的问题，提出几种优化办法： 减少CPU：减少机器CPU数量是最简略的做法，然而受限于服务器硬件配置，1个GPU通常只配置8个CPU。所以减少CPU的办法只能用于性能测试数据比照，无奈理论利用部署。前置预处理：大尺寸图片的解码、缩放操作CPU耗费较高，相较而言小尺寸图片的处理速度会快很多。因而思考对输出图片提前进行预处理，将预处理后的小图再送入服务。通过验证Tensorflow中缩放、裁切操作具备叠加不变性，即屡次操作和单次操作对最终后果没有影响。预处理后的小图像通过编码后，再送入原始分类服务。须要留神的是图像编码必须抉择无损编码（如PNG），否则会导致解码数据不统一，引起预测误差。前置预处理形式的长处是不须要批改原始模型服务，可操作性高、预测后果没有误差。毛病是须要反复预处理，导致整体流程时延减少、CPU资源节约。拆散预处理：另外一种思路是将模型预处理局部和骨干网络拆分，预处理局部独自部署到CPU机器上，骨干网络部署到GPU机器上。这种做法让CPU预处理服务能够程度有限扩容，满足GPU解决数据供应，充分利用GPU性能。更重要的是将CPU和GPU运算进行解耦，缩小了CPU-GPU数据交换等待时间，实践上比减少CPU数量效率更高。惟一须要思考的是服务间的通信效率和工夫，裁切后图像大小为224x224x3，采纳无符号整型类型数据大小是143KB，传输工夫和带宽在1万QPS以下没有问题。3.1.3 优化后果如下图5所示，咱们利用NVIDIA Nsight System，比照上述几种办法优化后的模型运行状况。减少CPU和前置预处理的办法都能够缩短CPU预处理工夫，缩小GPU数据等待时间，晋升GPU利用率。但相较而言，拆散预处理的办法优化更加彻底，CPU到GPU的数据拷贝工夫最短，GPU利用最为充沛。 各种办法优化后的线上服务压测性能后果见下图6（其中前置预处理和拆散预处理中的CPU预处理服务额定应用16个CPU），机器配置的CPU型号是Intel(R) Xeon(R) Gold 5218 CPU@2.30GHz、GPU型号是Tesla T4。从压测后果能够看出： 服务CPU减少到32核，QPS和GPU利用率（通过nvidia-smi命令获取的GPU-Util指标）晋升超过1倍，GPU利用率晋升至88%；前置预处理办法优化后服务QPS晋升超过1倍，略优于减少CPU的办法，但从GPU利用率角度看仍有较大优化空间；拆散预处理办法优化后QPS晋升2.7倍，GPU利用率达到98%靠近满载状态。减少CPU并不能齐全解决服务性能瓶颈问题，尽管GPU利用率达到88%，然而CPU-GPU数据传输工夫占比拟大，QPS晋升无限。前置预处理办法也没有齐全解决预处理性能瓶颈问题，优化并不彻底。相较而言，拆散预处理办法充分发挥了GPU运算性能，在QPS和GPU利用率指标上都获得了更好的优化成果。 3.2 图像“检测+分类”模型服务优化在一些简单工作场景下（如人脸检测辨认、图像文字辨认等），通常是检测、宰割、分类等多个模型组合实现性能。本节介绍的模型便是由“检测+分类”串接而成，模型构造如下图7所示，次要包含以下几个局部： 预处理：次要包含图像解码、缩放、填充等操作，输入Nx3x512x512图像矩阵，大部分算子运行在CPU设施上。检测模型：检测网络结构是YOLOv6，算子运行设施为GPU。检测后处理：应用NMS（非极大值克制）算法去除反复或误检指标框，失去无效检测框，而后裁切指标区域子图并缩放，输入Nx3x224x224图像矩阵，检测后处理大部分算子运行在CPU设施上。分类模型：分类网络结构是ResNet-50，算子运行设施为GPU。其中检测和分类两个子模型是独自训练的，推理时合并成单个模型，部署框架采纳TF-Serving，优化工具采纳TF-TRT。 3.2.1 性能瓶颈模型中预处理和检测后处理大部分是CPU运算，检测和分类模型骨干网络是GPU运算，单次推理过程中须要进行屡次CPU-GPU之间数据交换。同样地，CPU运算速度慢会导致GPU利用率低，推理服务存在性能瓶颈。 理论线上服务压测GPU利用率68%，QPS也存在较大优化空间。服务配置为1GPU+8CPU（机器CPU型号是Intel(R) Xeon(R) Gold 5218 CPU@2.30GHz，GPU型号是Tesla T4）。 3.2.2 优化办法依然采纳模型拆分的思路，将CPU和GPU运算局部独自部署微服务。如下图8所示，咱们将原始模型拆分为4个局部，预处理和检测后处理部署成CPU微服务（可依据流量大小动静扩容），检测模型和分类模型部署成GPU微服务（同一张GPU卡上）。为了放弃调用形式简略，下层采纳调度服务串接各个微服务，提供对立调用接口，对上游屏蔽调用差别。拆分后的检测模型和分类模型通过TensorRT优化后采纳Triton部署。 3.2.3 优化后果如下图9所示，除了原始服务和微服务拆分，另外还比照了减少CPU和Triton Ensemble两种形式的性能测试后果。Triton Ensmeble形式将所有子模型（包含预处理和后处理）部署在一个机器上，实现多模型流水线调度。比照能够看出： ...

美团代码托管平台通过长期的打磨，实现了分布式架构的革新落地，托管数以万计的仓库，日均Git相干申请达到千万级别。本文次要介绍了美团代码托管平台在迭代演进过程中面临的挑战及解决思路，心愿对大家有所帮忙或启发。1. 引言Code是美团自研的代码托管平台，其中包含了代码版本治理、分支治理及代码评审等性能，协同泛滥研发流程工具平台，撑持外部所有工程师的日常研发工作。通过近3年的建设，目前Code托管了数以万计的仓库，日常解决千万级的Git相干申请，稳固撑持着美团研发流程标准的继续落地。本文次要介绍美团在建设代码托管平台过程中面临的一些挑战和实践经验。 2. 美团代码托管平台建设之路2.1 代码托管平台的发展史回顾美团代码托管平台的发展史，整个历程能够划分为三个阶段：单机部署、多机部署以及自研分布式代码托管平台。 第一阶段：单机部署美团最后的代码托管平台，和绝大多数Web零碎一样，单机部署即可运行，所有用户的申请均通过Web利用进行响应。因为Git应用基于文件组织模式的存储模式，无论是通过页面拜访还是执行Git命令操作，最终都会体现为磁盘的文件读写，高IO磁盘尤为重要。整体架构如下图1所示： 第二阶段：多机部署在拜访规模不大的状况下，第一阶段这种单机架构能够满足日常的开发需要。但随着研发团队业务需要的一直增长，测试自动化流程的逐步完善，扩展性瓶颈也愈发显著，次要体现为以下2个方面： 存储：因为公司资源限度和地区调配不均等因素，代码托管平台部署机器已配置最大容量的可用SSD磁盘，使用率仍高达80%，可用空间严重不足。负载：随着研发人员的一直增多，在拜访高峰期，CPU和IO负载高达95%以上，页面呈现重大的卡顿，仅能通过限流保障系统的继续服务。因此，单机部署无奈再承载高峰期的访问量，零碎扩容迫不及待。于是，咱们开始设计了一套可能通过多机负载同一仓库IO的读写拆散架构计划，以解决较为重大的IO负载问题。在读写拆散架构中，最重要的是要保障用户视角的数据一致性（用户随时能够读取提交的最新代码），这里采取了以下措施： 写操作仅产生在主节点。采纳懒汉同步模式，在读取数据时触发从节点同步数据，若失败，则路由到主节点。采纳独主兜底模式，遇遇到突发状况时能够迅速禁用从节点，保障数据安全。 如图2所示，咱们将仓库拜访模式依照应用层协定辨别为HTTP和SSH，别离由对应的解析代理模块进行读写散发操作后再下发到主从节点（此处采纳了Round-Bobin的算法散发读申请），使得读吞吐量整体扩充了2倍。对于从节点，咱们部署了Agent，在用户发动读申请时会触发同步仓库数据的Fetch操作，以保证数据的一致性。 第三阶段：自研分布式代码托管平台在第二阶段，尽管通过多机负载IO的读写拆散架构短暂性地解决了扩展性瓶颈问题，但仓库数据仍在继续一直地指数增长。同时，除扩展性问题之外，可用性瓶颈也凸显进去，次要体现在以下2个方面： 运维：无论是日常迭代更新版本还是热修复紧急Bug，都须要停服能力部署零碎，停服期间用户无奈应用代码托管平台。备份：零碎采纳冷备份的形式多正本存储Git数据，无奈保障外围数据的实时复原，异常情况下存在数据失落危险。 因而，搭建具备高可用性和程度扩展性的分布式架构火烧眉毛。咱们调研了业界支流代码托管平台的分布式计划，并联合公司外部的业务个性，最终抉择了基于应用层分片的分布式架构，该架构满足了以下2个个性：高可用：采纳三正本多活模式，躲避代码失落危险，且零碎版本更新无需停服，单机断电、宕机均可失常提供服务。程度扩大：可通过扩容分片集群的形式进行存储和负载扩大，实现狭义下的“有限”容量。综上所述，Code基于GitLab生态开源组件二次开发，并采纳了应用层分片多活模式的分布式架构计划，简介如下： 底层存储服务基于GitLab生态开源组件二次开发，有良好的生态和丰盛的性能反对。各服务间均通过gRPC进行交互通信，次要思考点是Git大多数为二进制数据通信，gRPC基于HTTP 2.0，有良好的传输性能和流式反对。通过路由模块实现逻辑层与存储层无效隔离，逻辑层对物理分片无感知，存储层如同一个整体提供服务。采纳了多活复制模式的数据保障架构，进步读写吞吐量，满足日均千万级的申请量需要。针对于应用层分片的劣势，在架构设计时也做了相应的针对性优化，具体如下： 热点库：提供了自动化的分片迁徙能力，在发现仓库呈现热点时，可进行分片迁徙达到分片平衡。跨分片数据交互：通过业务层的Git事务包装，咱们应用共享Object的模式并确保互相关联的仓库均落在同一分片上，既防止了跨分片通信的问题，也缩小了磁盘空间占用和拜访时延。 3. 美团代码托管平台架构演进的落地和挑战代码托管平台在架构演进过程中，最终实现了以下两个指标： 高可用：缩短停机工夫，进步可用性，零碎稳固牢靠。高扩大：针对计算和存储资源，能够实现程度扩大。接下来，针对于每个指标，本文别离从技术挑战、计划选型、设计及解决方案等方面具体介绍咱们的实践经验。 3.1 扩展性指标3.1.1 技术挑战在进行程度扩大革新时，次要面临了以下两类挑战： 规模性：在研发流程自动化等背景下，美团代码托管平台须要具备千万级吞吐、低提早及高可用的零碎性能，以进步研发效率。兼容性：技术改造波及的场景比拟多，次要有两方面的考量：（1）用户低感知，新老零碎保障现有通信形式及平台应用形式不变；（2）兼顾过渡时期底层存储介质多样性、运维体系兼容等问题，并保障上下游零碎的失常运行。3.1.2 计划选型通过对支流代码托管平台（GitHub、GitLab、Bitbucket等）的调研剖析，咱们发现各大平台次要采纳了以下两种架构解决扩展性问题。 通过上述比照能够发现，如果间接接入共享存储，临时无奈满足代码托管平台的稳定性和性能要求（若Git机制进行并行优化，且应用更高读写性能的分布式存储系统，或者是一个不错的抉择）。在共享存储优化革新老本较高的前提下，咱们最终采纳了应用层分片的分布式架构，它既满足扩展性的要求，也更加成熟和稳固，并体现出不错的性能。 3.1.3 方案设计咱们通过代理模块实现了申请散发，通过路由模块实现了仓库分片，通过利用模块的无状态革新实现了弹性伸缩，从而达成了程度扩大的架构指标。上面将对这些模块进行具体的介绍。 代理模块 SSH Proxy：提供Git-SSH操作代理，提供Git-SSH申请代理，通过路由模块获取路由信息，到指标机器执行SSH操作。SSH Proxy组件基于go-crypto库开发，实现了公钥辨认用户，流量管制，长连贯超时解决，SSH转gRPC等性能。后续打算引入signature校验，以应答不同的应用场景。HTTP Proxy：提供Git-HTTP/Web申请代理，通过路由模块存储的仓库分片映射关系，决策仓库路由节点。HTTP Proxy基于Go-Gin开发，实现了申请甄别，流量管制，多层代理等性能。最后HTTP Proxy还被作为灰度迁徙的外围组件，通过流量对立收口，反对申请散发到新老Code零碎，以确保申请和数据的平滑迁徙。 路由模块 Shard：记录仓库与其所在分片之间的映射关系，是应用层分片架构的“中枢系统”。Shard服务除保护映射关系外，还是容灾模块必不可少的“决策者”，通过获取各个节点以后拜访仓库的最新版本，从而决定读写路由。因为Golang杰出的高并发体现，目前路由相干接口的均匀响应工夫在15ms以内。该模块的次要个性如下： 建设仓库和分片的映射关系，为了防止因为仓库门路更新造成文件夹拷贝/挪动等行为带来肯定的复杂性，这里采纳了仓库ID作为惟一标识。利用Go Routine获取节点的数据同步状态，并通过超时机制保障用户非有限时期待。应用Key-Value Cache存储仓库和分片的映射，以升高映射关系的申请时延。 利用模块 利用模块次要包含以下两点性能： 提供Git相干的业务逻辑接口解决代码内容信息、代码评审等复杂性业务申请。监听代码和分支变更音讯，发送事件告诉买通第三方业务零碎和收集度量信息。整体模块架构如下图7所示： 3.1.4 解决思路规模性解决思路 规模化的次要指标是：具备撑持千万级申请的零碎能力，并反对计算、存储等资源的程度扩大能力，其中路由平衡是必不可少的一环。 a. 路由平衡 Code系统对数据源可靠性要求较高，而对性能要求绝对比拟低，因此咱们采纳了严格仲裁的路由模式，具体的逻辑配置如下： 应用版本号断定哪个节点提供的代码内容最新：版本号越大，代表数据越新，当版本最大时即为最新的数据。当W+R > N时总能读到最新的数据（N：总节点个数，W：判断写入胜利须要的响应节点数，R：读取数据时至多要胜利读取的个数），当W越小时，写入的可用性就越高，R越小，读取的可用性就越高。咱们抉择了N=3，R=W=2的惯例举荐配置，依据概率推算可达到99.999%的可用性程度。采纳读修复模式：当读取数据时，若发现节点数据不统一，此时触发数据同步逻辑，以修复落后节点的数据。该性能内置于路由模块的Shard服务，架构如下图8所示： 兼容性解决思路 兼容性指标总结为一句话就是：业务应用无感知。因而，咱们次要从以下三个方面思考兼容性。 a. 与各零碎交互方式及现有基础设施兼容 Code零碎的泛滥上游零碎（多套前端UI、业务研发流程工具平台等）依赖零碎提供的凋谢API、Hook机制等扩大性能，为了缩小系统升级对业务方造成影响，须要保证系统交互方式兼容。同时还要确保零碎运维监控体系失常运行，维持可监测状态，咱们次要做了以下四件事件： 兼容外围性能：应用频度高的性能平移到新零碎，而应用中低频的性能，与业务沟通应用场景，再评估是否兼容。从新设计局部性能：提供更为正当的WebHook配置能力及簇新的代码评审性能。边缘性能经营下线：推动废除和历史遗留性能的下线，并提供正当的代替计划。买通运维体系：放弃现有监控埋点及运维接口接入形式，使零碎处于可保护、可监测的状态。b. 非分布式版本无缝切换到分布式版本 Code零碎仓库泛滥，须要有低成本的用户自主切换形式保障数据逐渐迁徙，咱们次要做了以下三件事件： 可视化主动切换：通过页面一键迁徙按钮，低成本实现从非分布式版本切换到分布式版本（迁徙进度可感知，执行过程中仓库可读不可写，确保数据残缺）。Proxy屏蔽底层存储介质多样性：通过Proxy放弃繁多的调用形式不变，可兼顾获取非分布式版本和分布式版本的存储数据。非凡数据共享存储：用户和SSH Public Key等数据与仓库数据没有强制关联关系，可实现数据共享。c. 历史数据平滑迁徙 Code零碎存在泛滥的历史代码数据和业务数据，如何无效、残缺地将历史数据平滑迁徙到新的分布式系统，变得尤为重要。为了达成业务应用无感知的指标，次要做了以下两件事件： 优先迁徙“轻量”仓库：先迁徙应用性能繁多的仓库，依据用户反馈逐步完善迁徙能力。业务维度批次迁徙：依照业务线划分迁徙批次，同类应用模式的仓库同期迁徙，以躲避反馈问题多样性。3.2 可用性指标3.2.1 技术挑战在进行可用性革新时，咱们次要面临数据安全性层面的挑战。代码作为公司的重要资产之一，需达到两方面的要求： ...

新春将至，一年一度的美团技术年货也如约到来! 工夫煮雨，岁月缝花，花开无声，花谢无语。2022这一年，咱们一起经验了有数的悲喜，也留下了满满的回顾。 兴许生存就是这样，只有历尽波澜，能力观赏茫茫大海的辽阔和无际，能力感触到漫天星辰的光辉和和煦。 在2023年春节到来之际，咱们从去年美团技术团队公众号上精选了60多篇技术文章，整顿制作成一本1300多页的电子书，作为新年礼物赠送给大家。 这本电子书内容笼罩算法、前端、后端、数据、平安等多个技术畛域，心愿能对同学们的工作和学习有所帮忙。 也欢送大家转给更多有雷同趣味、踊跃上进的共事和敌人们，一起切磋，独特成长。 祝福2023年，大家诸事顺遂，衰弱安全。 如何获取？ 舒适提醒： 美团技术年货合集大小约为48M，下载须要一些工夫；关上电子书目录后，可间接点击感兴趣的题目进行浏览；局部文章中的动静图片无奈在电子书中进行齐全的展现，大家能够移步美团技术团队官网博客 tech.meituan.com ，或在美团技术团队公众号历史文章中进行浏览，感激了解。2022美团技术年货合辑：共1356页，约48M；20022年算法系列：共430页，约34M；2022年前端系列：共198页，约16M；2022年后端系列：共575页，约24M；2022年数据·运维·平安系列：共160页，约6M。往期技术年货下载关注「美团技术团队」微信公众号。回复【2021年货】、【2020年货】、【2019年货】、 【2018年货】、【2017年货】，即可获取往期年货下载链接。 感激咱们置信保持和积攒的力量，9年多的工夫，3000多个日夜，500多篇技术文章，美团技术团队博客/公众号，感激大家的一路相伴！

美团开放平台为整个美团提供了20+业务场景的凋谢API，为了使开发者可能疾速且平安的接入美团开放平台，美团开放平台提供了多种语言的SDK来进步开发者的接入效率。本文介绍了美团开放平台如何主动生成SDK代码的相干技术实现计划，心愿对大家可能有所帮忙或者启发。1. 引言美团开放平台对外提供了外卖、团购、配送等20余个业务场景的OpenAPI，供第三方开发者搭建利用时应用，是美团零碎与内部零碎通信的最重要平台。本文次要讲述开放平台如何通过技术手段主动生成反对接口参数富模型和多种编程语言的SDK，以进步开发者对接开放平台API的效率。 1.1 背景美团开放平台将美团各类业务提供的扩大服务封装成一系列应用程序编程接口（API）对外开放，供第三方开发者应用。开发者可通过调用开放平台提供的OpenAPI获取数据和能力，以实现本身零碎与美团零碎协同工作的业务逻辑。以外卖业务场景为例，开发者能够在本人为外卖商户开发的利用中通过调用美团开放平台提供的API，提供外卖订单查问、接单、订单治理等一系列性能。如下图所示： 开放平台为开发者提供的OpenAPI以HTTP接口的模式提供。以平台提供的订单查问接口为例，对应的HTTP申请如下所示： POST https://api-open-cater.meituan.com/api/order/queryByIdContent-Type: application/x-www-form-urlencoded;charset=utf-8appAuthToken=eeee860a3d2a8b73cfb6604b136d6734283510c4e92282&charset=utf-8&developerId=106158&sign=4656285a4c2493e279d929b8b9f4e29310da8b2b&timestamp=1618543567&biz={"orderId": "10046789912119"}Response:{ "orderId":"10046789912119", "payAmount":"45.67", "status":7, ......, "products":[{"pid":"8213","num":2,...,"price":"3.67"}{"pid":"6556","num":1,...,"price":"11.99"}]}由上述示例能够看出，美团开放平台提供给开发者的接口契约较为简单，其中蕴含了业务规定简单及安全性要求低等起因。若开发者须要间接从0到1编码对接平台提供的HTTP API，须要关注通信协议、接口契约标准、认证标识传递和平安签名等细节，老本较高。随着业务的倒退，平台反对的OpenAPI数量在近两年增长约一倍，达到近1000个，平台经营和研发人员须要投入越来越多的精力去帮忙开发者解决接口对接过程中的疑难问题。因而，提供SDK以帮忙开发者进步开发对接效率，变得非常有必要。 1.2 SDK指标概述SDK，英文名称为 Software Development Kit，即软件开发工具包，狭义上指辅助开发某一类软件的相干工具、文档和范例的汇合。在开放平台的场景，咱们为开发者提供的SDK应能为其屏蔽调用OpenAPI的通信协议、参数传递标准、接口根底契约（如工夫戳、平安签名）等细节，以升高其对接平台API所需的开发成本。具备基本功能的开放平台SDK的架构和功能模块如下所示： 从应用SDK的开发者角度来看，基于SDK封装的根底性能来编写调用开放平台接口的代码，大抵逻辑如下所示： MeituanClient client = DefaultMeituanClient.builder(developerId, signKey).build();//设置申请参数MeituanRequest request = new MeituanRequest("/api/order/queryById");request.setParam("orderId","10046789912119");MeituanResponse response = client.invokeApi(req);if(response.isSuccess()) { long price = (long)response.getField("price"); String phone = response.getField("customerPhone"); int orderStatus = (int)response.getField("status"); //实现业务逻辑} else { log.warn("query order failed with response={}", response); //解决接口调用失败的逻辑}从上述代码能够看出，提供根底性能的SDK曾经可能为使用者提供较大的便当。相比从零开始编码对接OpenAPI，应用SDK能够帮忙开发者省去解决通信协议、公共参数搁置、平安签名计算和返回状态码解析的工作量。但开发者在编写代码设置API的业务参数字段的环节，仍需对照API文档一一手工填充字段名并按字段类型赋值，并且在获取API返回的业务字段时也需自主填充字段名并解析数据类型，存在较大的不便且易出错。 为解决此问题，咱们须要在SDK的能力上更进一步提供对参数富模型的反对，即为每个API提供模型化封装的申请参数和返回参数构造，让应用SDK的开发者能够更加专一于业务逻辑的开发。 在SDK退出参数富模型的反对后，从使用者的角度来看，须要编写的代码如下所示： MeituanClient client = DefaultMeituanClient.builder(developerId, signKey).build();//设置申请参数QueryOrderRequest request = new QueryOrderRequest();request.setOrderId("10046789912119");//调用接口MeituanResponse<QueryOrderResponse> response = client.invokeApi(req);//解决接口返回if(response.isSuccess()) { QueryOrderResponse orderResponse = response.getData(); long price = orderResponse.getPrice(); String phone = orderResponse.getCustomerPhone(); int orderStatus = orderResponse.getStatus(); log.info("query order finish, price={}, orderStatus={}", price, phone, orderStatus);} else { log.warn("query order failed with response={}", response); //解决接口调用失败的逻辑}能够看出，参数富模型性能能够进一步缩小开发者应用SDK的复杂度。以Java语言版本为例，QueryOrderRequest和QueryOrderResponse两个富模型类中封装了API的申请参数和返回参数的所有字段名、字段类型和字段校验规定等信息，开发者可简略应用字段的getter和setter办法实现对字段的赋值和取值操作，大幅升高了了解老本和出错可能。 ...

时光匆匆，就要跟2022年说再见了！提前祝大家新年快乐~~ 2013年12月4日，美团技术团队博客诞生，发表了第1篇技术文章。9年多的工夫，3311个日夜，目前咱们曾经公布了548篇技术文章，美团技术团队博客/公众号，感激大家的一路相伴。 每年的这个时候，咱们都会筹备一篇年终总结，将本年度最受欢迎的文章举荐给大家。本期咱们汇总了2022年度浏览量比拟靠前的20篇文章，欢送大家品阅。 01 可视化全链路日志追踪 | 浏览量38722 可观测性作为零碎高可用的重要保障，曾经成为零碎建设中不可或缺的一环。然而随着业务逻辑的日益简单，传统的ELK计划在日志收集、筛选和剖析等方面更加耗时耗力，而分布式会话跟踪计划尽管基于追踪能力欠缺了日志的串联，但更聚焦于调用链路，也难以间接利用于高效的业务追踪。本文介绍了可视化全链路日志追踪的新计划，它以业务链路为载体，通过无效组织业务每次执行的日志，实现了执行现场的可视化还原，反对问题的高效定位。 02 设计模式二三事 | 浏览量34065 设计模式是泛滥软件开发人员通过长时间的试错和利用总结进去的，解决特定问题的一系列计划。现行的局部教材在介绍设计模式时，有些会因为案例脱离实际利用场景而令人费解，有些又会因为场景简略而显得有些小题大做。本文会依据在美团金融服务平台设计开发时的教训，结合实际的案例，并采纳「师生对话」这种绝对滑稽的模式去解说几类罕用设计模式的利用。心愿能对想晋升零碎设计能力的同学有所帮忙或启发。 03 Kafka在美团数据平台的实际 | 浏览量28939 Kafka在美团数据平台承当着对立的数据缓存和散发的角色，随着数据量的增长，集群规模的扩充，Kafka面临的挑战也愈发严厉。本文分享了美团Kafka面临的理论挑战，以及美团针对性的一些优化工作，心愿能给从事相干开发工作的同学带来帮忙或启发。 04 基于代价的慢查问优化倡议 | 浏览量28166 对于数据库来说，慢查问往往意味着危险。SQL执行得越慢，耗费的CPU资源或IO资源也会越大。大量的慢查问可间接引发业务故障，关注慢查问即是关注故障自身。本文次要介绍了美团如何利用数据库的代价优化器来优化慢查问，并给出索引倡议，评估跟踪倡议品质，经营治理慢查问。 05 深刻了解函数式编程（上） | 浏览量28103 函数式编程是一种历史悠久的编程范式。作为演算法，它的历史能够追溯到古代计算机诞生之前的演算，本文心愿带大家疾速理解函数式编程的历史、根底技术、重要个性和实际法令。在内容层面，次要应用JavaScript语言来形容函数式编程的个性，并以演算规定、语言个性、范式个性、副作用解决等方面作为切入点，通过大量演示示例来解说这种编程范式。同时，文末列举比拟一些此范式的优缺点，供读者参考。 06 美团外卖搜寻基于Elasticsearch的优化实际 | 浏览量26653 美团外卖搜寻工程团队在Elasticsearch的优化实际中，基于Location-Based Service（LBS）业务场景对Elasticsearch的查问性能进行优化。该优化基于Run-Length Encoding（RLE）设计了一款高效的倒排索引构造，使检索耗时（TP99）升高了84%。本文从问题剖析、技术选型、优化计划等方面进行论述，并给出最终灰度验证的论断。 07 工程效力CI/CD之流水线引擎的建设实际 | 浏览量24918 通过近3年的建设打磨，美团流水线引擎实现了服务端的基建对立，每日撑持近十万次的流水线执行量，零碎成功率放弃在99.99%以上。本文次要介绍在自研引擎建设层面遇到的挑战以及解决方案。 08 Java系列 | 近程热部署在美团的落地实际 | 浏览量23622 Sonic是美团外部一款用于热部署的IDEA插件。本文次要讲述Sonic的实现细节以及底层原理，从IDEA插件到自动化部署，再到沉迷式开发产品闭环，全方位讲述了Sonic在美团的落地与实践经验。目前业界对标的产品并不多，心愿本文能对从事联调/开发/测试等相干方向的同学有所帮忙或启发。 09 常识图谱可视化技术在美团的实际与摸索 | 浏览量24918 常识图谱可视化能够更直观地查看和剖析常识图谱的数据。本文次要介绍了美团平台在布局策略、视觉降噪、交互性能、可视化叙事、3D图谱可视化等方面的一些实际和摸索，同时积淀出了uni-graph图可视化解决方案，并反对了美团的很多业务场景，包含美团大脑、图数据库、智能IT运维、组件依赖剖析、行业畛域图谱等。心愿能对从事常识图谱可视化方向的同学有所帮忙或启发。 10 YOLOv6：又快又准的指标检测框架开源啦 | 浏览量23622 美团视觉智能部研发了一款致力于工业利用的指标检测框架 YOLOv6，可能同时专一于检测的精度和推理效率。在研发过程中，视觉智能部一直进行了摸索和优化，同时汲取借鉴了学术界和工业界的一些前沿停顿和科研成果。在指标检测权威数据集 COCO 上的试验结果显示，YOLOv6 在检测精度和速度方面均超过其余同体量的算法，同时反对多种不同平台的部署，极大简化工程部署时的适配工作。 11 自动化测试在美团外卖的实际与落地 | 浏览量21119 随着美团到家业务的倒退，零碎复杂度也在持续增长。测试用例数量近两年增长约一倍，单端数量超过1万2千条，而研发人员的工作从大部分工夫在开发，转变成一半工夫在开发、一半工夫在模仿环境和自测。因而，引入自动化测试就显得非常有必要，本文介绍了美团外卖在自动化测试方向做的一些摸索和实际，心愿对从事相干畛域工作的同学可能带来一些启发或帮忙。 12 日志导致线程Block的这些坑，你不得不防 | 浏览量20561 ...

美团到店举荐广告团队在图神经网络的长期落地实际中，思考剖析了场景的特点与挑战，针对性地进行了模型设计，并通过大规模训练工具及线上部署优化屡次胜利落地，带来了线上支出晋升。本文次要介绍了大规模图召回技术在美团到店广告场景下的实践经验，包含模型设计思路、模型迭代历程、大规模训练工具以及线上部署性能优化等，心愿为从事相干工作的读者带来一些启发。1. 引言美团到店举荐广告技术部服务于到店餐饮、休娱亲子、丽人医美等泛滥本地生存服务商家。其中，召回环节作为举荐广告零碎的第一个环节，承当着从海量商品中寻找优质候选的角色，是算法优化的外围问题之一。 举荐零碎中经典的召回范式有两类：基于标签构建倒排索引的显式召回和基于模型端到端建模用户趣味的隐式召回。在隐式召回中，历史交互行为建模对于精确刻画用户趣味十分要害。电商场景中，用户与商家、商品之间的交互关系适宜通过图网络来表白。相较于传统模型，图神经网络能够构建用户与商品间的多种交互关系，而后借助高阶网络结构的传递性正当裁减用户行为的丰盛度，将用户行为、用户根底属性和商品的内容属性等各种异质信息在对立的框架中进行交融，带来更大的成果空间。 美团到店举荐广告算法团队和NLP核心常识计算团队围绕图技术在举荐广告的利用进行了亲密的单干，取得了线上成果的显著晋升。本文次要介绍摸索过程以及相干的实践经验。 2. 图神经网络简介图作为蕴含节点本身和节点间边关系的汇合，宽泛存在于真实世界的多种场景中，例如社交网络中人与人之间的社交关系图、举荐零碎中用户与商品的交互图等。图神经网络能捕获节点和边的特色及其之间的拓扑关系，对图构造数据有很好的建模成果。举荐零碎中罕用的图神经网络模型能够分为两大类：基于图游走的办法和基于图卷积的办法。 基于图游走的办法：传统神经网络模型善于解决欧式空间的数据，但难以建模图构造中蕴含的简单拓扑关系。因而，晚期的研究者们提出了通过游走办法从图构造数据上采样序列，而后应用传统神经网络模型解决的间接计划，其中以DeepWalk[1]，Node2vec[2]等工作为典型代表。如下图1所示，这类办法侧重于在图中采纳既定的游走策略生成节点序列，再应用NLP畛域中的Skip-Gram模型训练失去每个节点的向量表征。 基于图卷积的办法：从图上采样序列进行建模的形式简略间接，但因为从原始图构造到序列的转换过程中存在信息损失，其成果存在较大的局限性，因此如何将图构造间接建模到神经网络中成为了图神经网络钻研的关键问题。研究者们联合谱域图上信号的傅里叶变换，定义了图上的卷积操作，并通过一系列的简化将谱图卷积和神经网络分割起来。 2017年Thomas等人提出的GCN[3]是其中的代表作之一。图2为图构造至单层GCN公式的演变，其中$\tilde{A}$和$\tilde{D}$别离为退出自环的邻接矩阵及节点度矩阵，$X$为图节点特色矩阵，$W$为GCN模型的可训练参数，$\sigma$为激活函数（例如ReLU），$H$为图节点特色通过单层GCN网络后的输入特色。 GCN从整图的角度登程，买通了原始图构造和神经网络之间的壁垒，但微小的计算量使其难以利用到大规模场景中。相比之下，GraphSAGE[4]从图上节点的角度，提出了基于采样的消息传递范式，使得图神经网络在大规模图上的高效计算变得可行。GraphSAGE中的SAGE指 SAmple and aggreGatE，即采样和聚合。下图3展现了GraphSAGE的采样聚合过程。图中左侧展现了对节点A应用两层采样器采样其一阶和二阶街坊，图中右侧展现了将采样失去的一阶二阶街坊的特色通过对应的聚合函数进行聚合，失去节点A的表征，进而能够应用A的表征计算包含节点分类、链接预测及图分类在内的多种图相干的工作。 GraphSAGE等基于消息传递范式的图神经网络办法，其核心节点能聚合到的特色范畴取决于其采样的街坊阶数。在应用这类图神经网络训练时，除了应用节点的固有特征作为模型输出外，咱们还能够给每个节点退出独立可训练的向量参数，从而更好的学习到高阶街坊的相关性。 除了上述提到的办法外，图神经网络畛域作为钻研热点之一，近年来不断涌现出GAT[5]、FastGCN[6]、GIN[7]等优良算法，并在Pinterest[8]、阿里巴巴[9]、腾讯[10]等公司的大规模举荐场景落地获得良好效果。 3. 业务场景及挑战到店举荐广告业务在流量侧次要笼罩美团/公众点评双侧的信息流广告、详情页广告等多种业务场景（如下图4所示），供应侧包含了餐饮、丽人医美、休闲娱乐、结婚、亲子等不同广告主品类，且每一个品类下蕴含商户、团单、泛商品等不同的举荐候选类型。 业务中召回模型建模面临以下两大挑战： a. 同场景反馈数据稠密：传统序列行为建模计划依赖用户在同场景的反馈数据结构正负样本进行模型训练，但用户在举荐广告场景的交互行为比拟稠密，据统计超过一半的沉闷用户在近90天内无广告点击行为，超过40%的广告商品在近一个月没有被点击。如何解决反馈数据稠密导致的用户趣味刻画不精确、长尾商品学习不充沛是咱们面临的一大挑战。 b. LBS业务中不同时空场景下的趣味刻画：到店业务中，用户在不同工夫、空间下的浏览行为，往往有着齐全不同的偏好。例如一个用户工作日在公司左近，可能感兴趣的就是一次不便的工作餐；在假期的家中，则会想找一个乏味的遛娃去处。但传统的图神经网络不足对用户申请工夫和所处地位的实时感知能力。因而如何从图蕴含的丰盛信息中挖掘出匹配以后时空场景的候选汇合，同样是一大挑战。 针对以上业务特点和挑战，咱们设计了基于全场景数据高阶关系的大规模异构图建模，借助全场景丰盛的行为数据优化稠密问题；并进一步强化时空信息感知，刻画用户在不同时空上下文中的趣味。 4. 图召回技术在举荐广告的演进4.1 基于全场景数据高阶关系的大规模异构图建模团队之前的召回模型仅通过用户在广告场景的行为结构正负样本进行训练，这种形式进步了训练数据与预测场景的一致性，但也不可避免地产生用户趣味刻画不精确、长尾商品举荐成果较差等问题。特地是召回作为举荐零碎最上游环节，决定了全链路成果优化下限，咱们冀望借助图神经网络蕴含的弱小表达能力，基于用户在全场景的行为数据全面刻画用户趣味和商品信息。 如图5所示，图网络别离产出用户（User）和商品（Item）的隐式表征（Embedding），通过间隔类似度掂量用户对候选广告的潜在趣味。在图神经网络的选型上，咱们应用带Attention构造的GAT[5]，使得街坊信息的贡献度能够依据其对源节点的重要性自适应调节，克制误点击等带来的噪声；应用Jumping Knowledge Network[11]，依据节点的连接性自助调整其聚合网络范畴，防止热门节点因为其宽泛的连接性聚合范畴过大损失了个性化信息。 全场景数据建模：为了全面开掘用户的趣味偏好，咱们通过全场景行为数据构建了超大规模异构图网络进行建模。此处的全场景涵盖全业务（搜寻、举荐、广告），全地位（首页、商品详情页、团单详情页）和全商品类型（商户、团单、泛商品等）。异构图蕴含用户（User）和商品（Item）两种类型节点，并通过三种类型的边进行连贯：User点击Item边、Item独特点击边以及Item同店铺边。 为了加强全场景数据蕴含的丰盛信息在各个场景间无效传递，同时辨别出用户在广告场景独有的趣味特点。咱们在图构建过程中将广告场景和非广告场景的同个Item建模为不同节点，共享雷同的非广告特色，但带有广告标识的节点会额定减少广告专属的特色。这样模型在训练过程中既能通过共享的特色迁徙非广告场景的信息，也能学习到用户在广告场景独有的趣味偏好。图构建实现后蕴含数亿节点、百亿边。 图裁剪与噪声克制：上文提到的异构图因为涵盖了用户在全场景的行为数据，数据规模宏大，给理论落地带来了微小的算力和性能挑战。咱们发现在图的拓扑构造中，各个节点的度散布极不平均，局部热门节点的街坊个数可达几十万，因为训练过程中每个节点只采样固定个数的街坊参加计算，过多的街坊引入了许多噪声数据，也带来了不必要的资源开销。依据图数据背地的业务了解，咱们对原始拓扑构造进行正当裁剪。 具体来说：对于“User点击Item边”，保留行为工夫较近的topN条出边；对于“Item独特点击边”，保留边权重较高的topN条出边。图裁剪后，节点数量放弃不变，边数量缩小46%，训练内存开销升高30%，并带来了约0.68%的离线Hitrate成果晋升。 动静负样本采样：因为广告商户在整体商户中占比拟小，全场景行为数据的引入导致训练样本空间增大了一个数量级，这进一步加剧了SSB（Sample Selection Bias）问题，负样本采样策略成为影响模型成果的关键因素。常见的随机负采样形式因为Hard Negative样本量有余，导致模型在理论预测时泛化性较差。而动态负样本采样策略，例如LBS场景下常见的基于间隔、类目构建负样本，尽管能够获得肯定成果晋升，但通用性较差，策略配置繁琐，无奈依据用户趣味迁徙自适应迭代。 以不同等级的城市为例，用户对于间隔、类目标偏好水平不同，须要设置不同的阈值。因而，咱们提出一种基于半监督学习的迭代式训练范式，将前一轮模型输入的商户Embedding通过KMeans进行聚类，在正样本所在的聚类汇合中采样失去Hard Negative，退出到下一轮的训练样本中，依此步骤循环，疏导模型一直“自我晋升”。 试验发现，随着迭代轮次的减少，离线指标的边际收益会收窄；思考到训练速度与收益的均衡，线上咱们采纳2轮迭代的形式。该优化相比随机负采样带来了约4.66%的离线Hitrate成果晋升；相比动态负样本策略（如基于间隔、类目标采样）带来了约1.63%的离线Hitrate成果晋升。 上述3个优化点的迭代在多个主广告位落地，并在掂量广告营收的RPS（Revenue Per Search）指标晋升约5%~10%。 4.2 强化时空信息感知的端到端异构图建模在LBS的业务中，时空信息是影响用户趣味的重要因素。用户通常具备稳固的长期趣味，但也会受到以后时空信息影响而呈现出多变的短期趣味。因而，咱们在4.1节介绍的全场景异构图建模的根底上进行降级。依据长期趣味稳固、短期趣味多变的特点，咱们采纳针对性措施别离建模时空信息对长短期趣味的影响。 如下图9所示，咱们通过时空子图刻画用户在不同时空场景下的长期趣味偏好，通过多因子协同激活的序列建模刻画用户在短期时空场景下的趣味演变。值得注意的是，区别于将异构图预训练Embedding作为动态特色引入的两阶段训练形式，咱们将模型各局部在雷同的优化指标下进行一阶段端到端训练，防止优化指标不统一带来的成果损失。 时空子图构建及多视角交融：用户在不同的时空下体现出不同的趣味，举例来说，一个用户可能在工作日的办公室订购咖啡，而在休息日的健身房加入静止。仅应用全局视角下的图模型提取用户全局趣味，容易失落用户在不同时空的趣味差别。传统图模型计划通过全局信息取得用户对立的趣味表征，无奈精确刻画用户在不同时空场景下趣味差别。 业界曾经呈现了一些联合时空信息的图表征学习方向的钻研工作，如STGCN[12]等。在相干工作的根底上，咱们从举荐广告的业务场景登程，基于用户行为对应的工夫和空间信息，从工夫、空间、工夫&空间、全局等4个视角构建子图，并通过多视角交融模块取得用户长期趣味。值得注意的是，所有子图共享Item2Item边，因为Item与Item的关系（如同店铺，独特点击等）较为稳固，不容易受到时空变动的影响。 如下图10所示，当用户申请达到时，从空间子图中取得用户在以后地位的趣味，从工夫子图中取得用户在多个工夫的趣味，从工夫&空间子图中取得用户在以后地位下多个工夫的趣味，并联合全局趣味及以后工夫，进行多视角交融。在实践中，咱们将工夫划分为晚上、下午、早晨、深夜等4个时间段，将地位应用Geohash进行划分为多个天文区域。据统计，每个用户的历史行为波及到的时间段和天文区域均比拟集中，并不会对存储空间造成过大的压力。时空子图的构建及交融带来了约3.65%的离线Hitrate晋升。 多因子协同激活的用户序列建模：咱们将工夫信息（以后工夫与行为序列工夫的差值）、地位信息（以后地位与行为序列地位的差值）作为激活因子来激活短期行为序列，捕获用户趣味随时空的迁徙趋势。此外，图神经网络输入的用户长期趣味向量，体现了用户在工夫、地位等维度较稳固的趣味偏好，也有利于从短期序列中提取出匹配以后时空场景的实时趣味。应用时空信息及用户长期趣味对用户短期行为序列进行激活时，波及到多个因子协同激活的问题，业界常见的计划如下图11所示： 在美团LBS的业务场景中，各个激活因子之间可能会相互影响，例如工夫和地理位置两种激活因子对行为序列激活的侧重点存在差别。为了让多因子激活施展最佳成果，咱们联合离线指标抉择“多因子交融激活”模式。多因子协同激活的用户序列建模带来了约6.90%的离线Hitrate晋升。 值得一提的是，图神经网络开掘的多阶关系可能丰盛用户序列的表白。这种多阶关系不仅体现在商品和商品、用户和商品等粗粒度节点之间，也体现在工夫、地位、类目等细粒度特色之间。因而，咱们对特色产出流程进行了降级革新，使图神经网络中的商品节点可能与用户行为序列在特色维度共享Embedding词典，并基于对立的优化指标端到端训练，帮忙细粒度多阶信息更好地在图神经网络与用户序列间传递。 上述2个优化点的迭代在多个主广告位落地，并在掂量广告营收的RPS（Revenue Per Search）指标晋升约5%。 5. 性能优化与利用为了可能在大规模场景上线并进行实时召回，咱们针对模型的离线训练和在线部署进行了优化。 ...

美团语音交互部针对跨语言结构化情感剖析工作中短少小语种的标注数据、传统办法优化老本昂扬的问题，通过利用跨语言预训练语言模型、多任务和数据加强办法在不同语言间实现低成本的迁徙，相干办法取得了SemEval 2022结构化情感剖析跨语言赛道的冠军。1. 背景SemEval（International Workshop on Semantic Evaluation）是一系列国内自然语言解决（NLP）研讨会，也是自然语言解决畛域的权威国内比赛，其使命是推动语义剖析的研究进展，并帮忙一系列日益具备挑战性的自然语言语义问题创立高质量的数据集。本次SemEval-2022（The 16th International Workshop on Semantic Evaluation）蕴含12个工作，波及一系列主题，包含习语检测和嵌入、讥刺检测、多语言新闻相似性等工作，吸引了包含特斯拉、阿里巴巴、支付宝、滴滴、华为、字节跳动、斯坦福大学等企业和科研机构参加。 其中Task 10: 结构化情感剖析（Structured Sentiment Analysis）属于信息抽取（Information Extraction）畛域。该工作蕴含两个子工作（别离是Monolingual Subtask-1和Zero-shot Crosslingual Subtask-2 ），蕴含五种语言共7个数据集（包含英语、西班牙语、加泰罗尼亚语、巴斯克语、挪威语），其中子Subtask-1应用全副七个数据集，Subtask-2应用其中的三个数据集（西班牙语、加泰罗尼亚语、巴斯克语）。咱们在参加该评测工作的三十多支队伍中获得Subtask-1第二名和Subtask-2 第一名，相干工作已总结为一篇论文MT-Speech at SemEval-2022 Task 10: Incorporating Data Augmentation and Auxiliary Task with Cross-Lingual Pretrained Language Model for Structured Sentiment Analysis，并收录在NAACL 2022 Workshop SemEval。 2. 赛题简介结构化情感剖析工作（Structured Sentiment Analysis, SSA）的目标是抽取出文本中人们对创意、产品或政策等的认识，并结构化地表白为观点四元组 - Opinion tuple Oi (h, t, e, p)，包含Holder（主体）、Target（客体）、情绪表白（Expression）、极性（Polarity）四种因素，表征了Holder（主体）对Target（客体）的情绪表白（Expression），和对应的极性（Polarity）。观点四元组能够用Sentiment Graphs来具象化贮存和示意（如下图1所示），图中展现了两个例句，别离用英文和巴斯克语表白了“某些人给the new UMUC大学评五分是不可信的”这个意思。第一句英文示例蕴含了两个观点四元组，别离是O1 (h, t, e, p) = (Some others, the new UMUC, 5 stars, positive)，以及O2 (h, t, e, p) = (, them, don't believe, negative)。 ...

11月6日至9日，第20届国内计算机学会ACM嵌入式网络感知零碎大会SenSys在美国波士顿召开。清华大学软件学院何源副教授课题组和美团无人机团队单干论文“麦巢：辅助无人机精准起飞的远距离即时声源定位技术”取得了大会最佳论文奖第二名（Best Paper Runner-Up）。11月6日至9日，第20届国内计算机学会（Association for Computing Machinery，简称ACM）嵌入式网络感知零碎大会（Conference on Embedded Networked Sensor Systems ，简称SenSys）在美国波士顿召开。清华大学软件学院何源副教授课题组和美团无人机团队单干论文“麦巢：辅助无人机精准起飞的远距离即时声源定位技术”（MicNest：Long-Range Instant Acoustic Localization of Drones in Precise Landing）取得了大会最佳论文奖第二名（Best Paper Runner-Up）。 ACM嵌入式网络感知零碎大会是ACM主办的物联网畛域旗舰学术会议，自2003年开始已间断举办20届。本届大会共收到209篇论文投稿，其中52篇被接管发表，最终评比出1篇“最佳论文奖”（Best Paper）和1篇“最佳论文奖第二名”（Best Paper Runner Up）。 该论文钻研动机来自美团公司正在打造的城市低空物流网络实在利用场景。高精度的定位追踪技术是保障配送服务无人机安全可靠精准起降的关键技术之一。钻研提出了一种基于高空麦克风阵列进行远距离即时声源定位的计划，无效解决了简单城市环境中信号衰减快、信噪比低、多普勒非线性失真等难题，对无人机的可定位高度达120m，定位相对误差0.5%。 背景为了使无人机可能满足配送经营的要求，无人机飞控系统次要依赖RTK、视觉等信息实现对无人机的定位。然而在城市环境，尤其在靠近高空的城市峡谷场景中，无人机左近的楼宇反射甚至会遮挡GPS卫星的信号，从而导致重大的多径效应或者是非视距的信号流传。 无人机配送的长期业务指标是实现全天时全天候配送，为了晋升无人机定位的健壮性，论文提出了基于声波的定位办法。 2 整体框架该论文提出一种新型的声学定位系统，以帮忙无人机准确着陆。如下图1所示，无人机将拆卸一个一般的扬声器，从而使无人机可能发送辅助定位的声学脉冲信号。高空的机场将部署多个麦克风作为定位锚点。高空机场将从各个麦克风采集到的信号中检测声学脉冲，进而计算出脉冲信号的绝对时延，定位无人机。 本论文须要解决如下三个技术难题: 第一个挑战是声学脉冲信号的信噪比非常低。有如下四个起因：（1）因为无人机穿梭于城市之间，所以扬声器的传输功率必须要被限度，以防止烦扰城市居民。（2）本零碎须要定位低空的无人机（>100m），声学脉冲信号将会接受很大的信号瘦弱。（3）此外，许多城市的背景噪声自身就很强，约为 40-75 dB SPL。（4）在地面航行时，无人机螺旋桨还会产生很大的声学烦扰，可能高达104 dB SPL。第二个挑战是无人机静止引起的多普勒信号失真。对于无线信号而言，多普勒效应的重大水平，反比于物体的静止速度，正比于无线信号的传播速度。相比于射频信号的传播速度（即光速），声学信号在空气中的传播速度是十分慢的。所以，声学信号将接受重大的多普勒失真。第三个挑战是信号处理必须要高效。本定位系统用于疏导静止的无人机起飞，定位数据提早不能过高，否则高提早的定位后果将给飞控引入重大的零碎不稳定性，威逼整个起飞环节的平安。总之，本提案要解决的核心技术问题是：如何在低信噪比的条件下，检测失真声学脉冲信号。 上图2展现了本提案的定位流程的示意图与对应的零碎实现：无人机携带一个扬声器继续的播放声学脉冲信号。四个麦克风被部署在起飞平台的四个角上以捕捉声学脉冲信号。本零碎通过定位音箱的地位来定位无人机。 3 具体计划3.1 PRN调制与发送在实在的场景中，无人机发送的声学信号须要满足如下要求： 声学对人耳敌对：无人机收回的声音不能引起居民的听觉不适。反对并发检测和辨认：同一片空域总，可能会有多个无人机在起降，即多个无人机可能同时传输声学脉冲。这就要求本零碎可能从抵触的声学信号中别离检测每个无人机的脉冲，并辨认每个检测出的脉冲属于哪一个无人机。平安：可能避免歹意攻击者伪造无人机的脉冲来误导零碎。为满足以上需要，本零碎采纳伪随机噪声（Pseudo-Random Noise， PRN）调制来生成无人机的声学脉冲。咱们用每个无人机的识别码（ID）来设置伪随机种子，并生成一连串的N个高斯随机变量，作为该无人机发送的脉冲信号。具体实现中，码率等于扬声器的采样率，即48 kHz。 3.2 脉冲检测将声波信号进行调试并发送后，咱们须要在高空端进行脉冲检测。 咱们抉择的是匹配滤波器进行脉冲检测。其思维是以发射脉冲为模板，并将其与接管信号做相干。通过将接管信号流式地输出到匹配滤波器中，匹配滤波器就会流式地输入相干后果。如果从输入后果中找到一个显著的相干峰，咱们就断定该脉冲被检测到了。但为了解决低信噪比问题，须要减少脉冲长度，然而多普勒失真的存在，使得减少脉冲长度只会事与愿违。 解决此问题的间接无效办法就是弥补多普勒失真：多普勒效应缩放了脉冲码字的持续时间。 如果无人机绝对于麦克风的径向速度已知，咱们就能够计算出码字理论的持续时间，再用该参数从新采样原始的PRN脉冲模板，以生成一个与收到的脉冲码字同步的信号模板。能够预期的是，用该新模板来检测PRN脉冲的模板弥补了多普勒效应的烦扰，进而能够按需地减少PRN脉冲长度，克服低信噪比问题。 然而实际上，麦克风的径向速度是未知的。因而，咱们采纳线性搜寻的形式来遍历麦克风的径向速度。对于无人机可能速度的汇合咱们顺次进行重采样和相干计算。当汇合中所有的速度都实现以上的操作，咱们就失去了对应的N个相干函数。从中，咱们只须要保留有着最大相干值的一个相干函数。这是因为最大的相干值就意味着脉冲的多普勒失真曾经被最大水平地弥补了，其对应的搜寻速度也最靠近实在的无人机的径向速度。 3.3 TDoA预计和定位本零碎共部署了四个麦克风，顺时针地别离记这些麦克风为为Mic0、Mic1、Mic2和Mic3。 对于每一路麦克风Mici的音源，咱们顺次进行上述的多普勒速度弥补与脉冲检测，并失去相干函数。从该相干函数中，找到其中相干峰，并把相干峰的地位当作脉冲信号达到Mici的达到工夫（Time of Arrial, ToA）。不便起见，别离记脉冲信号达到4个麦克风Mic0、Mic1、Mic2和Mic3的达到工夫为ToA0、ToA1、ToA2和ToA3。 接着，咱们计算脉冲达到绝对时延（Time Difference of Arrial, TDoA）。在本零碎中，咱们只计算对角麦克风对的TDoA，即麦克风对<Mic0,Mic2>与<Mic1,Mic3>。这是因为几何上，对角麦克风有着最大的麦克距离（即孔径），所以有着最细的空间粒度。 两个TDoA将通过WiFi传输给无人机。基于这些信息，无人机能够建设两个双曲面方程组。依据双曲面方程组和无人机的高度信息，能够求得飞机剩下两个自由度的信息。 4 翻新点相比于视觉定位计划，本计划有如下长处： ...

前言Spring Boot是由Pivotal团队提供的全新框架，其设计目标是用来简化新Spring利用的初始搭建以及开发过程。该框架应用了特定的形式来进行配置，从而使开发人员不再须要定义样板化的配置。 可是老伙计，你会用 Spring 和 SpringBoot，你是否曾想过这样一些问题呢： SpringBoot 只须要依赖 starter 就能整合进一个模块，它是怎么做到的？SpringBoot 只须要编写启动类，打个注解就能拉起一个Web利用，我又没加Tomcat，它咋起来的呢？SpringBoot 跟 Spring 是什么关系呢？它咋利用Spring的呢？Spring 又是怎么做到IOC、AOP等如此高大上而且牛叉的机制呢？人家都说 Spring 和 SpringBoot 的底层设计很牛，都在哪里体现的呢？正如你的这些问题所想， SpringBoot 用的人多，但懂其原理的人说实话不多，能深刻源码探寻最底层的人更是少之又少。（诶伙计别跑啊，等我说完。。。） 为了让更多的 “SpringBoot” 能深刻的理解 SpringBoot 中的一些精华，小编故在此筹备了一份市面上极少见的【Spring Boot 外围常识及源码剖析手册笔记】，本笔记共分为两份笔记，全文共666页！ Spring Boot 外围常识及源码剖析手册笔记本笔记实用于应用过 Spring 和 SpringBoot 并理论开发的小伙伴能纯熟应用 Spring和 SpringBoot ，想理解底层但翻源码一脸懵逼的小伙伴有动向当前成为高级开发的小伙伴技术广度大，但深度无限的小伙伴第一份：Spring Boot 外围常识及源码剖析手册内容介绍： 本专栏共7个模块，28个节点，介绍 Spring Boot 框架所提供的零碎开发解决方案以及源码剖析。 一、Spring Boot疾速入门 介绍 Spring 家族的整个生态系统和技术体系，通过系统分析通过 Spring Boot 构建一个残缺 Web 应用程序的性能个性和开发流程。 二、Spring Boot Web开发 这部分具体介绍 Spring Boot 中最具特色的配置体系和主动配置机制，并具体给出如何应用、治理和定制配置项的实现办法。 三、Spring Boot 数据拜访 ...

美团外卖搜寻工程团队在Elasticsearch的优化实际中，基于Location-Based Service（LBS）业务场景对Elasticsearch的查问性能进行优化。该优化基于Run-Length Encoding（RLE）设计了一款高效的倒排索引构造，使检索耗时（TP99）升高了84%。本文从问题剖析、技术选型、优化计划等方面进行论述，并给出最终灰度验证的论断。1. 前言最近十年，Elasticsearch 曾经成为了最受欢迎的开源检索引擎，其作为离线数仓、近线检索、B端检索的经典基建，已积淀了大量的实际案例及优化总结。然而在高并发、高可用、大数据量的 C 端场景，目前可参考的材料并不多。因而，咱们心愿通过分享在外卖搜寻场景下的优化实际，能为大家提供 Elasticsearch 优化思路上的一些借鉴。 美团在外卖搜寻业务场景中大规模地应用了 Elasticsearch 作为底层检索引擎。其在过来几年很好地反对了外卖每天十亿以上的检索流量。然而随着供应与数据量的急剧增长，业务检索耗时与 CPU 负载也随之上涨。通过剖析咱们发现，以后检索的性能热点次要集中在倒排链的检索与合并流程中。针对这个问题，咱们基于 Run-length Encoding（RLE）[1] 技术设计实现了一套高效的倒排索引，使倒排链合并工夫（TP99）升高了 96%。咱们将这一索引能力开发成了一款通用插件集成到 Elasticsearch 中，使得 Elasticsearch 的检索链路时延（TP99）升高了 84%。 2. 背景以后，外卖搜寻业务检索引擎次要为 Elasticsearch，其业务特点是具备较强的 Location Based Service（LBS） 依赖，即用户所能点餐的商家，是由商家配送范畴决定的。对于每一个商家的配送范畴，大多采纳多组电子围栏进行配送间隔的圈定，一个商家存在多组电子围栏，并且随着业务的变动会动静抉择不同的配送范畴，电子围栏示意图如下： 思考到商家配送区域动静变更带来的问题，咱们没有应用 Geo Polygon[2] 的形式进行检索，而是通过上游一组 R-tree 服务断定可配送的商家列表来进行外卖搜寻。因而，LBS 场景下的一次商品检索，能够转化为如下的一次 Elasticsearch 搜寻申请： POST food/_search{ "query": { "bool": { "must":{ "term": { "spu_name": { "value": "烤鸭"} } //... }, "filter":{ "terms": { "wm_poi_id": [1,3,18,27,28,29,...,37465542] // 上万 } } } } //...}对于一个通用的检索引擎而言，Terms 检索十分高效，均匀到每个 Term 查问耗时不到0.001 ms。因而在晚期时，这一套架构和检索 DSL 能够很好地反对美团的搜寻业务——耗时和资源开销尚在承受范畴内。然而随着数据和供应的增长，一些供应丰盛区域的左近可配送门店能够达到 20000~30000 家，这导致性能与资源问题逐步凸显。这种万级别的 Terms 检索的性能与耗时未然无奈疏忽，仅仅这一句检索就须要 5~10 ms。 ...

人工智能技术正在成为内容畛域的中台力量，其中视觉AI曾经渗透到内容生产、内容审核、内容散发、用户互动、商业化变现等各个环节。美团视觉智能部以场景化的内容产品、智能化的内容工具助力产业，在内容的创作、内容散发等环节利用宽泛。 前不久，美团视觉智能部的8篇论文被多媒体和计算机视觉畛域顶会ACM MM 与ECCV收录，本文将疾速带你理解这8篇论文的研究成果及其可在内容畛域的落地利用。内容生产围绕素材解析、创意生成、展现自适应等内容生产链路，须要继续优化智能抠图、智能延拓、图像文案生成等外围功能模块。因而，在驱动视觉语义宰割、跨模态生成等底层技术方向须要继续降级与翻新。 ECCV | Adaptive Spatial-BCE Loss for Weakly Supervised Semantic Segmentation（基于自适应空间二元穿插熵的弱监督语义宰割） 论文作者：吴桐（北京理工大学&美团实习生），高广宇（北京理工大学），黄君实（美团），魏晓明（美团），魏晓林（美团），刘驰（北京理工大学） 论文下载：PDF 论文简介：弱监督语义宰割旨在解决全监督语义宰割工作中所需的像素级标签人工成本和工夫开销较大的毛病，通过引入较弱的监督信息来升高相干老本。其中本文所应用的图像级监督老本最低，但其较低的信息量也带来了更大的挑战。以后的通用流程是先通过分类网络生成宰割伪标签，通过后处理细化后再用伪标签训练语义宰割网络。先前办法次要有以下毛病：1）生成的伪标签物体轮廓不清晰；2）前背景的划分阈值须要人工调节，升高了泛用性；3）性能重大依赖后处理，训练复杂度较高。为了缓解这些毛病，咱们提出了一个新的损失函数——空间二元穿插熵损失（Spatial-BCE），通过为前景和背景像素调配不同的优化方向来进步它们之间的特色差异性，进而实现更加清晰的伪标签物体轮廓，如下图1所示： 此外，咱们还引入了自适应阈值，通过在训练中让损失函数自行划分前背景像素的比例，并在推理时可同样将划分阈值交由网络生成。最初，咱们还设计了配套的迭代式训练方法，大幅提高了初始伪标签的准确率，即便不应用简单的后处理办法，咱们也能够实现以后的最优性能。大量试验表明，咱们的办法在PASCAL VOC 2012和MS-COCO 2014数据集上在均可成为SoTA，如下图2所示： 该办法对于广告营销素材解析、商品白底图（如下图3）生产等工作，具备弱小的提效作用。针对营销素材、商品主图等元素解析能力，传统的办法须要应用结构化PSD来实现各素材元素、商品主体的拆散，这极大地限度了解析能力的应用场景。尽管，能够引入语义宰割的能力来解决动态图片的素材解析，然而其标注老本高、主体定义繁冗等问题，始终困扰着设计和算法人员。为此，基于大量容易收集的图片级标签，能够通过本文的弱监督语义宰割能力，高效地实现像素级的创意素材解析，进而为后续的创意重组和生成提供短缺的供应。 ACM MM | Efficient Modeling of Future Context for Image Captioning（基于自适应空间二元穿插熵的弱监督语义宰割） 论文作者：费政聪（美团），黄君实（美团），魏晓明（美团），魏晓林（美团） 论文下载：PDF 论文简介：现有的图像形容（Image Caption）生成办法通常从左到右一一生成单词，并受到部分信息（包含给定图像和历史单词）的束缚。有许多钻研的指标是在解码过程中尝试利用全局上下文进行优化，例如迭代解码，然而，如何无效和高效地联合将来上下文仍有待摸索。 为了应答这个问题，受到非自回归图像形容（Non-Autoregressive Image Captioning, NAIC）能够利用批改掩码操作来了解双边关系的启发，咱们旨在将这一提高移植到传统的自回归图像形容模型中，同时放弃推理效率，不减少额定的工夫老本，如下图4所示： 具体来说，自回归和非自回归图像形容模型首先通过共享视觉编码器进行联结训练，以强制视觉编码器蕴含无效的将来上下文；而后，迫使自回归图像形容模型对其不统一预测词的散布校准（相似于常识蒸馏），同时额定捕获非自回归模型中跨层替换的因果变动。试验结果表明，咱们提出的办法在MS COCO基准的主动指标评估和人类评估方面显著超过了最先进的基准模型。 本文办法对于智能广告文案、商品介绍生成（如下图5）有重大价值，有助于晋升营销、曝光点击率，缩小人工设计老本。对于广告营销文案的生成，产品图片给用户的第一印象来自于外观，它对用户的决策有着重要的影响。因而，图像形容生成零碎必须可能充沛开掘图片视觉信息，反映产品的外观特色，从而促成消费者的点击和下单转化。本文提出的高效将来信息建模办法，有助于更细粒度、更高质量的文本生成。 内容散发高效的内容散发离不开对其结构化形容，包含图像视频的标签化、模态间（图-文、视频-文本）相关性等。近年来随着图文/短视频内容的广泛性、个性化及热点效应日趋显著，对新标签下的模型冷启动、更细粒度（包含空间上、语义上）的图文匹配、精细化的图像/视频-文本检索提出了更高的技术要求。 ACM MM | PPMN: Pixel-Phrase Matching Network for One-Stage Panoptic Narrative Grounding（针对单阶段全景指代宰割的像素-短语匹配网络） 论文作者：丁子涵（北京航空航天大学&美团实习生），惠天瑞（中国科学院信息工程研究所），黄君实（美团），魏晓明（美团），魏晓林（美团），刘偲（北京航空航天大学） 论文下载：PDF 论文简介：Panoptic Narrative Grounding (PNG) 是一项新兴工作，其指标是宰割由静止图像的密集叙述字幕形容的things和stuff类别的视觉对象。之前的两阶段办法首先通过现有的全景宰割模型提取宰割候选区域，而后进行粗粒度的区域-短语匹配以失去每个名词短语对应的宰割后果。 ...

人工智能技术正在成为内容畛域的中台力量，其中视觉AI曾经渗透到内容生产、内容审核、内容散发、用户互动、商业化变现等各个环节。美团视觉智能部以场景化的内容产品、智能化的内容工具助力产业，在内容的创作、内容散发等环节利用宽泛。 前不久，美团视觉智能部的8篇论文被多媒体和计算机视觉畛域顶会ACM MM 与ECCV收录，本文将疾速带你理解这8篇论文的研究成果及其可在内容畛域的落地利用。内容生产围绕素材解析、创意生成、展现自适应等内容生产链路，须要继续优化智能抠图、智能延拓、图像文案生成等外围功能模块。因而，在驱动视觉语义宰割、跨模态生成等底层技术方向须要继续降级与翻新。 ECCV | Adaptive Spatial-BCE Loss for Weakly Supervised Semantic Segmentation（基于自适应空间二元穿插熵的弱监督语义宰割） 论文作者：吴桐（北京理工大学&美团实习生），高广宇（北京理工大学），黄君实（美团），魏晓明（美团），魏晓林（美团），刘驰（北京理工大学） 论文下载：PDF 论文简介：弱监督语义宰割旨在解决全监督语义宰割工作中所需的像素级标签人工成本和工夫开销较大的毛病，通过引入较弱的监督信息来升高相干老本。其中本文所应用的图像级监督老本最低，但其较低的信息量也带来了更大的挑战。以后的通用流程是先通过分类网络生成宰割伪标签，通过后处理细化后再用伪标签训练语义宰割网络。先前办法次要有以下毛病：1）生成的伪标签物体轮廓不清晰；2）前背景的划分阈值须要人工调节，升高了泛用性；3）性能重大依赖后处理，训练复杂度较高。为了缓解这些毛病，咱们提出了一个新的损失函数——空间二元穿插熵损失（Spatial-BCE），通过为前景和背景像素调配不同的优化方向来进步它们之间的特色差异性，进而实现更加清晰的伪标签物体轮廓，如下图1所示： 此外，咱们还引入了自适应阈值，通过在训练中让损失函数自行划分前背景像素的比例，并在推理时可同样将划分阈值交由网络生成。最初，咱们还设计了配套的迭代式训练方法，大幅提高了初始伪标签的准确率，即便不应用简单的后处理办法，咱们也能够实现以后的最优性能。大量试验表明，咱们的办法在PASCAL VOC 2012和MS-COCO 2014数据集上在均可成为SoTA，如下图2所示： 该办法对于广告营销素材解析、商品白底图（如下图3）生产等工作，具备弱小的提效作用。针对营销素材、商品主图等元素解析能力，传统的办法须要应用结构化PSD来实现各素材元素、商品主体的拆散，这极大地限度了解析能力的应用场景。尽管，能够引入语义宰割的能力来解决动态图片的素材解析，然而其标注老本高、主体定义繁冗等问题，始终困扰着设计和算法人员。为此，基于大量容易收集的图片级标签，能够通过本文的弱监督语义宰割能力，高效地实现像素级的创意素材解析，进而为后续的创意重组和生成提供短缺的供应。 ACM MM | Efficient Modeling of Future Context for Image Captioning（基于自适应空间二元穿插熵的弱监督语义宰割） 论文作者：费政聪（美团），黄君实（美团），魏晓明（美团），魏晓林（美团） 论文下载：PDF 论文简介：现有的图像形容（Image Caption）生成办法通常从左到右一一生成单词，并受到部分信息（包含给定图像和历史单词）的束缚。有许多钻研的指标是在解码过程中尝试利用全局上下文进行优化，例如迭代解码，然而，如何无效和高效地联合将来上下文仍有待摸索。 为了应答这个问题，受到非自回归图像形容（Non-Autoregressive Image Captioning, NAIC）能够利用批改掩码操作来了解双边关系的启发，咱们旨在将这一提高移植到传统的自回归图像形容模型中，同时放弃推理效率，不减少额定的工夫老本，如下图4所示： 具体来说，自回归和非自回归图像形容模型首先通过共享视觉编码器进行联结训练，以强制视觉编码器蕴含无效的将来上下文；而后，迫使自回归图像形容模型对其不统一预测词的散布校准（相似于常识蒸馏），同时额定捕获非自回归模型中跨层替换的因果变动。试验结果表明，咱们提出的办法在MS COCO基准的主动指标评估和人类评估方面显著超过了最先进的基准模型。 本文办法对于智能广告文案、商品介绍生成（如下图5）有重大价值，有助于晋升营销、曝光点击率，缩小人工设计老本。对于广告营销文案的生成，产品图片给用户的第一印象来自于外观，它对用户的决策有着重要的影响。因而，图像形容生成零碎必须可能充沛开掘图片视觉信息，反映产品的外观特色，从而促成消费者的点击和下单转化。本文提出的高效将来信息建模办法，有助于更细粒度、更高质量的文本生成。 内容散发高效的内容散发离不开对其结构化形容，包含图像视频的标签化、模态间（图-文、视频-文本）相关性等。近年来随着图文/短视频内容的广泛性、个性化及热点效应日趋显著，对新标签下的模型冷启动、更细粒度（包含空间上、语义上）的图文匹配、精细化的图像/视频-文本检索提出了更高的技术要求。 ACM MM | PPMN: Pixel-Phrase Matching Network for One-Stage Panoptic Narrative Grounding（针对单阶段全景指代宰割的像素-短语匹配网络） 论文作者：丁子涵（北京航空航天大学&美团实习生），惠天瑞（中国科学院信息工程研究所），黄君实（美团），魏晓明（美团），魏晓林（美团），刘偲（北京航空航天大学） 论文下载：PDF 论文简介：Panoptic Narrative Grounding (PNG) 是一项新兴工作，其指标是宰割由静止图像的密集叙述字幕形容的things和stuff类别的视觉对象。之前的两阶段办法首先通过现有的全景宰割模型提取宰割候选区域，而后进行粗粒度的区域-短语匹配以失去每个名词短语对应的宰割后果。 ...

人工智能技术正在成为内容畛域的中台力量，其中视觉AI曾经渗透到内容生产、内容审核、内容散发、用户互动、商业化变现等各个环节。美团视觉智能部以场景化的内容产品、智能化的内容工具助力产业，在内容的创作、内容散发等环节利用宽泛。 前不久，美团视觉智能部的8篇论文被多媒体和计算机视觉畛域顶会ACM MM 与ECCV收录，本文将疾速带你理解这8篇论文的研究成果及其可在内容畛域的落地利用。内容生产围绕素材解析、创意生成、展现自适应等内容生产链路，须要继续优化智能抠图、智能延拓、图像文案生成等外围功能模块。因而，在驱动视觉语义宰割、跨模态生成等底层技术方向须要继续降级与翻新。 ECCV | Adaptive Spatial-BCE Loss for Weakly Supervised Semantic Segmentation（基于自适应空间二元穿插熵的弱监督语义宰割） 论文作者：吴桐（北京理工大学&美团实习生），高广宇（北京理工大学），黄君实（美团），魏晓明（美团），魏晓林（美团），刘驰（北京理工大学） 论文下载：PDF 论文简介：弱监督语义宰割旨在解决全监督语义宰割工作中所需的像素级标签人工成本和工夫开销较大的毛病，通过引入较弱的监督信息来升高相干老本。其中本文所应用的图像级监督老本最低，但其较低的信息量也带来了更大的挑战。以后的通用流程是先通过分类网络生成宰割伪标签，通过后处理细化后再用伪标签训练语义宰割网络。先前办法次要有以下毛病：1）生成的伪标签物体轮廓不清晰；2）前背景的划分阈值须要人工调节，升高了泛用性；3）性能重大依赖后处理，训练复杂度较高。为了缓解这些毛病，咱们提出了一个新的损失函数——空间二元穿插熵损失（Spatial-BCE），通过为前景和背景像素调配不同的优化方向来进步它们之间的特色差异性，进而实现更加清晰的伪标签物体轮廓，如下图1所示： 此外，咱们还引入了自适应阈值，通过在训练中让损失函数自行划分前背景像素的比例，并在推理时可同样将划分阈值交由网络生成。最初，咱们还设计了配套的迭代式训练方法，大幅提高了初始伪标签的准确率，即便不应用简单的后处理办法，咱们也能够实现以后的最优性能。大量试验表明，咱们的办法在PASCAL VOC 2012和MS-COCO 2014数据集上在均可成为SoTA，如下图2所示： 该办法对于广告营销素材解析、商品白底图（如下图3）生产等工作，具备弱小的提效作用。针对营销素材、商品主图等元素解析能力，传统的办法须要应用结构化PSD来实现各素材元素、商品主体的拆散，这极大地限度了解析能力的应用场景。尽管，能够引入语义宰割的能力来解决动态图片的素材解析，然而其标注老本高、主体定义繁冗等问题，始终困扰着设计和算法人员。为此，基于大量容易收集的图片级标签，能够通过本文的弱监督语义宰割能力，高效地实现像素级的创意素材解析，进而为后续的创意重组和生成提供短缺的供应。 ACM MM | Efficient Modeling of Future Context for Image Captioning（基于自适应空间二元穿插熵的弱监督语义宰割） 论文作者：费政聪（美团），黄君实（美团），魏晓明（美团），魏晓林（美团） 论文下载：PDF 论文简介：现有的图像形容（Image Caption）生成办法通常从左到右一一生成单词，并受到部分信息（包含给定图像和历史单词）的束缚。有许多钻研的指标是在解码过程中尝试利用全局上下文进行优化，例如迭代解码，然而，如何无效和高效地联合将来上下文仍有待摸索。 为了应答这个问题，受到非自回归图像形容（Non-Autoregressive Image Captioning, NAIC）能够利用批改掩码操作来了解双边关系的启发，咱们旨在将这一提高移植到传统的自回归图像形容模型中，同时放弃推理效率，不减少额定的工夫老本，如下图4所示： 具体来说，自回归和非自回归图像形容模型首先通过共享视觉编码器进行联结训练，以强制视觉编码器蕴含无效的将来上下文；而后，迫使自回归图像形容模型对其不统一预测词的散布校准（相似于常识蒸馏），同时额定捕获非自回归模型中跨层替换的因果变动。试验结果表明，咱们提出的办法在MS COCO基准的主动指标评估和人类评估方面显著超过了最先进的基准模型。 本文办法对于智能广告文案、商品介绍生成（如下图5）有重大价值，有助于晋升营销、曝光点击率，缩小人工设计老本。对于广告营销文案的生成，产品图片给用户的第一印象来自于外观，它对用户的决策有着重要的影响。因而，图像形容生成零碎必须可能充沛开掘图片视觉信息，反映产品的外观特色，从而促成消费者的点击和下单转化。本文提出的高效将来信息建模办法，有助于更细粒度、更高质量的文本生成。 内容散发高效的内容散发离不开对其结构化形容，包含图像视频的标签化、模态间（图-文、视频-文本）相关性等。近年来随着图文/短视频内容的广泛性、个性化及热点效应日趋显著，对新标签下的模型冷启动、更细粒度（包含空间上、语义上）的图文匹配、精细化的图像/视频-文本检索提出了更高的技术要求。 ACM MM | PPMN: Pixel-Phrase Matching Network for One-Stage Panoptic Narrative Grounding（针对单阶段全景指代宰割的像素-短语匹配网络） 论文作者：丁子涵（北京航空航天大学&美团实习生），惠天瑞（中国科学院信息工程研究所），黄君实（美团），魏晓明（美团），魏晓林（美团），刘偲（北京航空航天大学） 论文下载：PDF 论文简介：Panoptic Narrative Grounding (PNG) 是一项新兴工作，其指标是宰割由静止图像的密集叙述字幕形容的things和stuff类别的视觉对象。之前的两阶段办法首先通过现有的全景宰割模型提取宰割候选区域，而后进行粗粒度的区域-短语匹配以失去每个名词短语对应的宰割后果。 ...

基于美团指标检测模型开源框架 YOLOv6，本文提供了一种通用的量化部署计划，在放弃精度的同时大幅晋升了检测的速度，为通用检测的工业化部署摸索出一条可行之路，心愿能给大家带来一些启发或者帮忙。1. 背景和难点YOLOv6 是美团公布的一款开源的面向工业利用的 2D 指标检测模型 [1]，次要特点是速度快、精度高、部署敌对，在美团泛滥视觉业务场景中都有着宽泛的利用。通过量化（Quantization）晋升推理速度是理论工业利用中的基本操作，但因为 YOLOv6 系列模型采纳了大量的重参数化模块，如何针对 YOLOv6 进行高效和高精度的量化成为一个亟待解决的问题。本文旨在解决 YOLOv6 量化方面的难题，并以 YOLOv6s 模型为例，从训练后量化（Post-Training Quantization, PTQ）和量化感知训练（Quantization-Aware Training, QAT）两个方面进行剖析，摸索出了一条切实可行的量化计划。 YOLOv6 采纳了多分支的重参数化构造 [2]（如图 1A 所示），通过在网络结构层面退出人工先验能够在训练阶段让模型更好收敛。在推理阶段，多分支能够等价合并为单路，从而晋升运行速度。但现有的训练后量化办法，不能很好应答多分支构造带来的激烈变动的数值范畴，导致量化后产生重大的精度损失 [3]。另外，如何针对多分支结构设计量化感知训练（QAT）办法也面临着较大的挑战。蒸馏常被用来辅助 QAT 晋升性能，但如何利用 2D 指标检测的蒸馏办法来辅助 YOLOv6 模型的量化，也须要设计正当的计划在理论利用中进行测验。 ![图1 多分支构造重参数化过程（A）构造变动（B）参数变动 （起源：[2]）](https://p0.meituan.net/travel...) 2. 量化计划实战2.1 重参数化优化器YOLOv6 网络中大量应用重参数化构造，在进步模型训练精度的同时可能显著升高模型部署推理延时，但也带来了模型量化部署方面的难题。对重参数化网络的间接量化个别会带来不可承受的精度损失，例如 RepVGG-B1 [2] 网络在 ImageNet 数据集上的浮点精度为 78.42%，采纳 TensorRT 后量化（PTQ）的量化模型精度则升高为 54.55%。 此外，因为重参数化构造在训练和部署时构造不同，因而无奈间接适配现有的量化感知训练（QAT）办法，如何应用 QAT 办法来进步 YOLOv6 量化模型的精度，同样存在着挑战。近期，一篇重参数化优化器的工作 RepOpt [3] 较好地解决了重参数化构造的量化问题。 2.1.1 RepOptRepOpt [3] 对重参数化构造量化艰难的问题进行了钻研，发现重参数构造的分支交融操作，显著放大了权重参数散布的标准差。异样的权重散布产生了过大的网络激活层数值散布，进一步导致该层量化损失过大，因而模型精度损失重大。 鉴于此，咱们统计了基于 RepVGG 构造的 YOLOv6 模型（YOLOv6s_repvgg）各层的权重及激活数值散布，剖析了 YOLOv6 中的重参数化层的数据分布。下图 2 以 “Rep_p4.block.0.rbr_reparam” 层为例，给出其特色图数值散布直方图，咱们发现其数值宽泛散布在 [0, 57] 的区间内。显然，采纳现有的 INT8 量化办法，无论怎样抉择量化缩放参数 （scale），都会产生较大的量化误差。 ...

数据安全最大的挑战是高速扩张前提下，解决数据裸露性问题。Token化让平安成为数据默认属性，让安全性随数据主动扩大，从根本上解决效率和平安合规的矛盾，实现设计平安和默认平安。本文次要介绍了Token化计划、Token化安全性实现以及美团所做的一些工程实际和教训分享。0. 引言随同科技翻新引领数字化浪潮席卷寰球，数据成为企业倒退的外围生产因素。像Google、Facebook等高科技公司，通过提供收费、优良的软件和服务，接入大量的用户，并基于数据资源驱动，取得了微小的商业胜利。然而，在高速倒退的同时，公司对数据却疏于治理，引起了大量的数据透露、算法滥用以及隐衷相干的问题。这种危机随同着Facebook的“剑桥剖析”丑闻、2020年美国大选等标志性事件，推向了低潮。基于对数据安全和隐衷的担心，欧盟的GDPR领衔的古代隐衷合规出台，随后风靡寰球，成为又一不可逆转的潮流。 摆在企业背后是两条路，既要通过数据科技翻新保障生存倒退，又要保障用户数据的平安。在这两条路的抉择与均衡上，有些企业倒下了，有些企业存活下来，并迸发出新的勃勃生机。 由此可见，唯有转变思路，勇于创新，能力化危为机，久远倒退。咱们要认清转折趋势：数字化时代从上半场粗放、低效，大水漫灌式碳增长，向基于高效数据管理、治理能力的高质量、高效率的数据碳中和转变。企业要在这个转变中生存并怀才不遇，科技翻新是重要的抓手，而重点是把握两大核心思想： 须要认清弱小数据利用生产力特色，踊跃进行技术改造，充分利用先进的数据管理技术手段，进步数据应用效率和治理程度。深刻学习、了解隐衷合规的目标和实质，遵循“可用、不可见”的核心思想，实现效率与治理的对立。1. 数据科技对平安的挑战在数字化应用环境下，数据具备如下特色： 数据的流动性与开放性：按数字经济学实践，数据要想发明出商业价值，就必须做到低成本、大规模供给，高效流动。如果利用传统网络安全最小化、层层审批、层层布防，将重大限度数据生产的生机。此外，在数据流经的每一个节点都达到高级的防护基准，起老本也是组织无奈接受的。数据的可复制性和失控性：数据作为流动资产，一旦被拜访后其控制权将被转移，供应者将失去对它的管控。传统的信赖边界在数据利用中也越来越含糊，这些都让集中安全策略在新型数据架构下落实起来老本微小，收效甚微。数据状态多变、利用简单：数据将在简直所有IT零碎中传递、存储和解决，其复杂程度超乎设想。加之AI、机器学习以及各类创新型数据利用，让数据应用逻辑更难以推敲，要想理解数据的全貌简直是不可能的工作。数据威逼复杂多变：数据的微小商业价值让包含黑、灰产业链，内、内部人员乃至商业、国内特务都趋之若鹜。攻打技术、动机层出不穷，防不胜防。 传统模式下，数据以明文模式在零碎中流通，数据裸露性微小。攻击者通过应用程序、存储、主机零碎入口，以及攻打零碎的受权账户等多种渠道获取大量数据。 在数字化场景中，数据将在数以万计的利用、工作中传递。每个利用都有本身逻辑，让所有利用合规老本微小。在如此宽泛、简单的环境下要爱护数据安全，如果采纳传统以零碎为核心的进攻模式，必将造成进攻阵线过长，攻强守弱的格局，让数据安全治理长期处于不利位置。必须转变思路，发明出一种数据内生的平安机制，在数据业务高速扩张环境下，平安防护能力也随之增长，这就是以数据为核心的平安进攻翻新机制。 2. Token化-数字世界银行体系Token化计划参考事实世界的银行零碎。银行体系呈现前，市面上经济流动次要以现金交易为主。现金的适度裸露，产生了大量的偷盗、抢劫案件，尽管镖局生意流行，但只有多数富豪才雇佣得起，因而社会资产大量散失。银行体系应运而生：用户取得现金后，第一工夫去银行将现金兑换成贷款（等价代替物），随后在整个社会中流通的都是这个代替物-电子现金，只有在极个别场景兑换成现金。随着银行零碎的浸透，加上各类线上领取利用的遍及，这种现金应用场景越来越少。要想抢钱，只能到银行去，而银行是通过重点防护。 同样，数据作为外围资产，能够通过计划在集体敏感数据数据（PII）刚进入组织业务零碎时，就将明文数据（P）替换成与其一一对应的假名-Token。在随后的整个组织应用环境中以Token高效流通。因为Token与明文是一一对应的，能够在生命周期绝大多数场景代替明文传输、替换、存储和应用，而Token只有通过安全可靠的Token化服务，能力兑换成明文。黑客和内外部歹意攻击者即使拿到了也毫无用处（不可见）。因为Token的自带平安属性，只有在组织内管制住次要数据源和数据枢纽只应用Token流通。新的明文数据需被动换成Token，实现数据默认平安，也就从根本上解决了集体敏感数据的治理难题。 如上图3所示，咱们通过推广Token化，可将理论可拜访明文的服务压缩到2位数，数据服务裸露性升高到1%以内。 如上图4所示，Token化革新后，敏感数据做到0存储、0缓存，0接口，0数仓；只有在大量具备解密权限主机内存，以及UI才可能获取明文数据拜访权。UI通过后续细粒度访问控制和审计风控等措施，实现危险可控。对于大量的内存数据，因其数量无限，可通过特定的加固和风控措施，进行强化。如果实现全面Token化，敏感数据整体危险控制能力也可大大加强。 3. Token化计划介绍3.1 什么是Token化Token化（Tokenization）是通过不敏感的数据等价替代物Token来替换集体敏感数据，在业务零碎中流通来升高数据危险和满足隐衷合规的计划。Token化属于去标识化技术的一种。最早呈现在支付卡行业（PCI）场景替换银行卡（PANs），目前有趋势替换通用数字化场景中的集体敏感信息（PII）。 集体惟一标识信息（PII）：任何能够间接、间接关联到具体的自然人的惟一标识信息如身份证件、手机号、银行卡、电子邮件、微信号或者地址。独自依赖PII信息，联合其余公开信息，就能够找到自然人。PII信息一旦透露，可能对集体造成如身份冒用、欺诈等生命财产挫伤。因而，在包含国内外各类法规中明确要求企业对PII全生命周期爱护。去标识化（De-identification）：通过肯定技术手段，对敏感数据进行替换、转换，长期或永恒打消集体敏感数据与自然人的关联。具体的伎俩包含假名化、匿名化、数据加密等。假名化（pseudonymization）：通过将敏感数据替换成人工ID或假名，未经受权，任何人无奈利用假名建设起与原自然人之间的关联。Token化就是一种假名化实现机制，狭义上二者能够概念调换。假名化是包含GDPR在内认可的去标识化计划。留神，假名化与PII是一一对应，在特定场景是能够还原原始数据。匿名化（Anonymization）：对敏感数据局部，或全副进行遮蔽、替换，让其齐全失去与原数据或自然人的关联。匿名化是不可逆的，罕用的匿名化技术包含数据遮蔽（Data Masking）。数据加密：采纳数据加密算法，如国密对称算法SM4，普密算法AES，对敏感数据进行加密，生成密文（Cipher），除非获取如密钥管理系统（KMS）加密密钥受权，无奈进行解密，取得明文。留神与假名化Token不同的是，密文只能解密出明文后能力应用，没有任何间接应用属性。因而密文只能用来存储和信息传递，大大限度了应用范畴，例如搜寻、关联、查问、匹配等数据分析场景。3.2 Token化根本设计3.2.1 可用、不可见1. 可用性实现 a）大数据分析场景利用Token的唯一性，实现数据挖掘、加工、剖析等场景的去重、统计、关联等性能。b）信息传递，在其余所有场景，Token利用其唯一性，能够齐全代替明文数据在整个体系中流通，解决替换、关联、查问、匹配等环节的数据应用。c）敏感性能应用：在必须应用明文数据场景，能够通过Token化服务换回明文，实现可用性兜底。 2. 不可见性实现 Token化自身的安全性是整个计划的平安根底。因而Token化从设计、到实现必须保障其平安，来避免非法者利用Token取得对应的原始明文，导致数据透露。具体请参考第四章节——Token化安全性实现。 3.2.2 根本架构需要为满足简单场景下数据保护能力，要求Token化计划满足几个次要架构要求： 业务适配性：Token化须要满足所有数据利用场景的数据交换要求，包含线上交易、实时和离线数据利用，以及AI和机器学习算法等所有场景。安全性：保障Token的脱敏属性是通过保障其与明文的关联关系的爱护。这里须要通过算法和Token化服务的平安以及上游利用的多重平安来保障。可用性和效率：Token化的引入，不应减少对业务零碎的效率和稳定性的降落。3.3 Token生成逻辑Token化的逻辑是，在企业范畴内，为敏感数据生成全局惟一的ID-Token。通常有3种计划实现ID生成。 1. 随机化 ：Token齐全随机生成，并通过保留一一映射关系表（这种是广义的Token化生成形式）。因为Token与明文没有算法关系，只能通过Token化服务能力进行正、反向关联，因而是最平安的计划。但这个计划的毛病是，为保障Token的高度一致性，新Token生成逻辑不能并发，否则会呈现一对多的一致性问题。为保证数据一致性，将就义肯定的分布式能力、性能。有形减少了可用性危险，尤其是近程异地场景。 2. MAC形式：通过对立的加盐哈希HMAC算法，任何过程、任何地位都能生成雷同的Token，保障一致性。生成后的Token与明文的映射关系落表，实现反Token化能力。该形式长处是能够跨地区实现分布式，毛病是就义了肯定的安全性。攻击者一旦取得了盐，就能够用算法批量计算Token。咱们能够通过对盐采取适当的爱护机制（采纳与加密密钥雷同爱护策略），能够取得平安与可用性的均衡。 3. 确定性加解密：通过确定性加密算法，如（AES-SIV），或者格局保留加密（FPE），将明文加密，生成可逆Token。该算法毁坏了加密的平安技术-随机性，但目前的算法普遍存在破绽，不倡议应用。此外，该算法还存在一个人造的破绽，就是密钥无奈轮换。 3.4 Token化计划逻辑架构 Token化服务须要满足全业务场景兼容性、安全性和可用性，次要通过多种接入集成计划。并集成必要的安全措施。Token化服务按逻辑分为接入层、服务层和存储层。 接入层：次要用来对接业务利用和人员拜访，实现Token与明文之间的转换即Token化和反Token化申请需要。别离提供人机接口（Portal）、服务接口（API）调用和大数据工作申请。因为Token化平安要求，接入层须要保障牢靠的安全措施，如细粒度访问控制、IAM、服务鉴权和大数据作业鉴权能力。服务层：理论执行Token化和反Token化的行为。次要是实现Token的生成、存储以及查问。存储层：存储层次要蕴含线上存储和数仓。因为安全性思考，Token化映射表并不存储明文而是保留加密后的密文。同时，通过HMAC算法建设HASH >Token >密文的关联关系实现明文换Token（正查）和Token换明文（反查）的业务逻辑。留神，利用并不能通过Token化间接取得明文，而是取得密文，通过KMS取得解密权限后本地解密取得明文。3.5 Token化利用全景 组件阐明： 1. 线上数据源 敏感数据的次要数据起源，一进入公司须要对接Token化服务API兑换成Token，并落库存储。肯定场景，数据也会接入数仓。数据源另外角色是向上游提供分享敏感数据，可通过API、MQ或共享存储如S3等媒介。 2. 数仓数据源 间接倒入或来自线上，敏感数据进入数仓，须要启用Token化工作，将明文转换成Token，并随后向上游其余大数据利用提供。 3. Token化服务 a）Token化线上服务通过API为线上交易、事实工作提供明文换Token服务。b）Token化离线Hive，为大数据工作提供离线数据荡涤服务，将明文转换成Token。 4. KMS和加解密 a）为Token化派发加密密钥，并将明文加密造成密文字段。b）为所有具备解密权限利用派发解密密钥，进行解密。 5. 数据利用 a）惯例两头利用：基于Token就能实现业务性能的服务。从数据源获取Token，并向上游传递。b）解密利用：按业务需要，满足平安基线前提下，用Token换取密文，并对接加解密模块进行解密，获取明文。 4. Token化安全性实现4.1 Token化的平安精要Token化安全性假设就是Token和明文的无关性，如果任何一个人或零碎非法保留、结构了一份Token与明文的对照字典或者具备结构这个字典的能力，Token化的平安机制就彻底毁坏了，因而Token化平安的外围就是避免这个表的生成。 ...

随着美团到家业务的倒退，零碎复杂度也在持续增长。测试用例数量近两年增长约一倍，单端数量超过1万2千条，而研发人员的工作从大部分工夫在开发，转变成一半工夫在开发、一半工夫在模仿环境和自测。因而，引入自动化测试就显得非常有必要，本文介绍了美团外卖在自动化测试方向做的一些摸索和实际，心愿对从事相干畛域工作的同学可能带来一些启发或帮忙。1. 我的项目背景美团外卖的业务场景比拟多元化，除了外卖本身的业务，还作为平台承接了闪购、团好货、医药、跑腿等其余业务。除此之外，在全链路动态化的大基调下，外卖各个页面的技术状态也变得越来越简单，除了Native代码，还包含Mach（外卖自研动态化框架）、React Native、美团小程序、H5等，不同技术栈的底层技术实现不同，渲染机制不同，进而对测试形式要求也有所不同，这也在无形中减少了测试的难度。下图汇总了美团多业务、多技术、多App的一些典型场景。 在产品交付上线的过程中，测试的占比也是十分大的，甚至大于总时长的30%。如下图所示，整个测试包含了冒烟测试、新功能测试、二轮回归测试、三轮测试。然而，当初需要测试绝大部分还是采纳非自动化的形式，这就使得人力老本变得十分之高。 另一方面，相比于2018年，2022年的测试用例数量增长近3倍，曾经超过1万2千条（如下图所示）。同时，外卖的业务是“三端复用”，除了外卖App，还须要集成到美团App和公众点评App上，这样一来，测试工作量就翻了3倍，业务测试压力之大可想而知。如果依照以后的增长趋势继续上来，要保障外卖业务的稳固，就必须继续一直地投入大量的人力老本，所以引入可能反对外卖“多业务场景”、“多App复用”、“多技术栈” 特点的自动化测试工具来晋升人效和品质，势在必行。 2. 我的项目指标为了解决外卖面临的测试窘境，咱们尝试去摸索一种零学习老本、低保护、高可用的自动化测试计划，可能反对外卖复杂多变的测试场景，它必须同时满足上面几点要求： 易用性：工具/平台的上手难度，应用复杂度应该尽可能的低，因为自动化测试的目标是提效人力，而不是减少人力累赘。平台反对：挪动端至多须要笼罩iOS和Android双平台，同时基于外卖的业务特点，不仅须要对Native反对，也须要反对Mach（自研部分动态化框架）、H5、React Native、美团小程序等技术栈。稳定性：自动化测试用例的执行须要有足够的稳定性和准确性，测试过程中不应因测试工具自身的不稳固而呈现稳定性问题。保护老本：保护老本很大水平上决定了测试工作量的大小，因需要产生变动或架构重构等问题时，用例的保护老本应该尽可能的小。可扩展性：当测试计划不能满足测试需要时，工具/平台应具备可扩大的能力。3. 计划选型自动化测试工具那么多，自研是反复造轮子吗？针对终端的UI自动化测试工具/平台堪称“不足为奇”，市面上也有很多绝对成熟的计划，置信大家都有用过，或者至多有所耳闻，但这些计划是否能真的满足咱们提效的诉求呢？以下咱们筛选了三类十分具备代表性的自动化测试工具/平台 - Appium、Airtest Project、SoloPi进行了剖析，来帮忙大家对自动化测试技术建设一个认知： ---AppiumAirtest ProjectSoloPi脚本语言反对Python，Java，JavaScript，PHP，C#，Ruby，OC等Python/数据记录（网络/本地）不反对不反对不反对环境模拟不反对不反对不反对上手难度高，须要各种环境反对和语言学习个别，不相熟编程语言，也能够肯定水平应用低，用例即操作，不展现问题溯源老本高高高保护老本高高高视图检索基于UI控件的检索，反对10多种UI控件查找形式基于图像识别和基于UI控件检索两种形式基于图像识别和基于UI控件检索两种形式源码集成无需可选无需WebView反对反对反对反对用例编辑反对反对反对平台反对iOS、Android、WindowsiOS、Android、Windows、游戏测试AndroidAppium是一个开源工具，用于自动化测试iOS手机、Android手机和Windows桌面平台上的原生、挪动 Web和混合利用。它应用了各零碎自带的自动化框架，无需SDK集成，Appium把这些零碎自身提供的框架包装进一套API——WebDriver API中，能够应用任何语言编写Client脚本向服务器发送适当的HTTP申请。这让不同技术栈的人员都能疾速上手编写测试用例，能够抉择本人最为相熟的语言，然而对于没有语言开发根底的人来说，还是有肯定学习老本，而且这种形式在多人合作时并没有太大作用，为了保障自动化用例的可维护性，团队外部应该须要对立脚本语言。值得一提的是：Appium在iOS、Android和 Windows 测试套件之间可做的肯定水平的复用代码。然而因为不同端界面及元素定位的差别，这往往是不事实的，更无奈保障测试的准确性，所以这种所谓的“跨端”就变得毫无意义。Airtest Project是由网易游戏推出的一款自动化测试平台，除了反对通过零碎自带的自动化测试框架，还反对了通过图像识别的形式，对于非基于原生UI零碎的一些游戏引擎提供了SDK的反对。其上手难度稍低，能够肯定水平上通过IDE进行相干操作来生成简略的脚本指令。Airtest尽管基于图像进行控件辨认，为跨端提供了肯定的可能性，然而图像识别并不能达到人眼辨认的准确度，除此之外挪动端页面的形成和游戏页面也存在不小的差异，页面元素的展现规定和款式受屏幕分辨率影响较大，单纯依附图像识别来进行元素查找成功率不高，无奈保障测试的准确性。SoloPi是一个无线化、非侵入式的自动化测试工具，通过录制回放的形式进行UI自动化测试，SoloPi尽管只反对Android，然而在录制回放的这种形式中，还是极具代表性的。传统的自动化测试工具因为须要编写测试脚本，所以存在着肯定的上手难度（Airtest还是存在代码编辑的），便产生了SoloPi这种纯基于录制回放的自动化测试形式，将用例的所有操作事件进行录制，生成一个残缺的录制脚本，通过对脚本的回放来还原所有的操作，从而进行自动化测试。然而，这种形式只能记录操作，而不能记录数据，在外卖这种数据驱动展现的场景下无奈满足测试要求。并且外卖的业务要复用到美团App和公众点评App中，不同App存在局部视图和逻辑性的差别，SoloPi也无奈反对咱们“一端录制多端回放”的测试场景。能够看出，以上这些自动化测试工具/平台对于数据记录，环境模拟、保护老本、跨App复用等方面，都是有所欠缺的。所以无论是哪种计划，在易用性、保护老本、稳定性、可扩展性以及最终的测试成果上，都无奈满足咱们对自动化测试的需要。咱们并不是为了自动化而自动化，而是要解决理论的提效问题。 那么，怎样才能确定一个自动化工具/平台的可用性，并长期落地去应用自动化，带着上述提到的较高门槛的上手老本、操作繁琐的环境模拟、差强人意的测试成功率、定位含糊的测试缺点、难以保护的用例脚本等几大重要痛点，本文咱们将介绍美团外卖自研的测试平台——AlphaTest，都具备哪些能力以及是如何解决这些问题。 4. 实际和摸索一个自动化测试工具/平台能不能用起来，取决于他的上手老本和稳定性，即便工具的测试稳定性做的再好，应用的门槛高也会让人望而生却，反之亦然。所以AlphaTest平台为了上手简略，升高应用老本，采纳了基于录制回放的形式进行设计，并且补救了惯例录制回放无奈编辑的痛点，同时在手势操作的根底上减少了数据录制。整合美团系App的个性减少了环境模拟、跨App反对、混合技术栈的反对等能力，在应用简略的同时，也保障了用例的可维护性、测试的准确性等。咱们先通过视频简略的理解一下： 用例录制： 点击查看视频 用例回放： 点击查看视频 回放报告： 点击查看视频 4.1 问题和挑战注：这里咱们将生成的自动化脚本统称为指令，将平台生成的用例统称自动化用例，将录制回放变成可视化的脚本指令，让用例变的易懂、易保护。录制回放自身是一连串的操作数据的汇合，是连续性的、不可拆分，因而简直不具备可编辑性，这也就导致了用例保护老本极高。AlphaTest尽管同样基于录制回放的形式生成自动化用例，然而咱们将每一步的操作都具化成结构化的指令数据，并提供可视化指令编辑器，以反对查看编辑。 这些可视化的指令，齐全通过录制主动生成，也不依赖于任何脚本语言。通过可视化用例指令编辑器，不仅为用例提供了编辑的可能性，同时大大地进步了用例的可浏览性，每一条测试用例在测试过程中每一步都做了什么、过后的界面是什么样的、都有哪些断言校验点，是不言而喻的，不会存在像传统图文形容的测试用例那样，呈现了解偏差。指令生成演示，手机录制与平台远端录制双模式反对： 4.2 前置条件筹备一键环境模拟，解决操作繁琐的用例执行前的环境筹备。进行一个用例的测试之前，往往须要做大量的筹备工作，比方切换API环境，定位到某个地点，登录指定账户等。这些须要筹备的环境条件咱们统称为前置条件。咱们晓得，前置条件的筹备操作通常都不是一两个步骤就能够实现的，比方账号登录/切换：咱们须要进入登录页，填写手机号+明码/验证码，点击登录等一系列动作来实现这个过程，十分繁琐，并且每次测试咱们都须要筹备，重复性高。因而，咱们给AlphaTest设计了独立的前置条件模块，将用例拆成了两个局部：前置条件 + 操作步骤。 与其它测试框架不同的是，AlphaTest采纳了SDK集成，但对业务无侵入的形式，因而能够通过编写白盒代码来实现前置条件的主动配置，只须要在平台增加须要的指令，下发到SDK后，即可依据相干指令实现前置条件的主动配置，不再须要反复进行相干的操作。并且这些前置条件反对复用，也不须要每次进行用例筹备时的反复配置。AlphaTest的前置条件，不仅有着基于美团外部服务及底层Hook的默认实现，也提供了API反对业务方自定义实现，比方实现不同的账号体系。 4.3 用例录制与回放的数据一致性影响用例执行的不仅是代码，还有数据。很多时候，自动化用例无奈失常执行实现，可能是因为App回放时的本地数据及网络数据与录制时的不统一，从而导致用例执行流程的阻塞或App界面展现的不同。这也是大多数自动化测试工具/平台测试通过率不高的次要因素，因而要保障测试成功率，咱们须要控制变量，排除由数据产生的影响。 App运行依赖的数据，有两局部——本地数据和网络数据： 本地数据是App在运行期间产生的缓存数据或长久化的存储数据。为了让用例在录制回放时都可能保持一致的本地数据环境，咱们在录制和回放前都对App的本地数据进行了清理操作，这样用例在录制和回放的过程中，都能够保持一致的App初始化环境。网络数据是驱动App交互出现的基石，各种策略和API降级都会影响网络数据的响应，因而咱们将用例录制过程中产生的网络数据也进行了录制，并将网络数据和对应的操作指令进行了关联和绑定，确定了数据产生的事件源。排除数据影响后，咱们的自动化测试的成功率就取决于自动化操作的准确性了，这就回到了常见自动化框架领域。4.4 用例录制与回放的操作一致性指标定位的准确性与手势定位的精准性。UI自动化测试的实质就是代替人去主动的做一步步的操作（点击、长按、输出、滑动等）。录制与回放过程的操作是否统一，是否精准，间接影响测试的成功率，决定了工具/平台的可用性。 指标控件定位准确性：操作行为是否统一首先须要确认操作指标是否统一。与个别测试工具/平台不同的是AlphaTest采纳了ViewPath + 图像 + 坐标的多重定位计划。得益于SDK集成的形式，咱们的ViewPath能够记录更多的元素视图特色和执行不同的匹配策略。定位过程中会优先应用ViewPath进行指标控件检索，当指标控件查找异样时，会联合图像匹配和坐标匹配的形式进行兜底查找，来确保界面变动水平不大时，也能精确的查找到指标控件。 手势定位的精准性：有了基于控件的指标定位之后，对于一些罕用简略操作手势，比方点击、长按、断言、甚至输出都能够做到很好的反对，只须要找到对应的控件，在控件所在位置下发相应的触摸事件即可。咱们晓得，App真正接管的触摸事件是屏幕上一个个精准的触摸点，在零碎解决后，分发给以后App窗口，App在接管事件后再持续散发，直到找到事件的最佳响应者，后续通过响应者链对事件消化解决。那咱们要还原一个触摸事件的坐标点要如何确定呢？因为咱们确定的只有控件，所以这个点自然而然就成了控件的中心点了。 大多数状况下，这些都能够很好地进行工作，然而对于一些多响应控件重叠的状况，可能会产生料想不到的操作误差。为了解决这样的问题，咱们把控件定位与坐标定位进行了联合：基于纯坐标的定位是一种定位精准度十分高的定位形式，然而稳定性十分差，只有在屏幕分辨率完全一致且回放页面控件地位完全一致的状况下，才具备足够的可靠性，但这往往是不事实的，对测试环境机器量要求过高。 基于控件的定位，又存在着精准度不够的问题。应用坐标定位，如果定位区域足够小的话，那么受屏幕尺寸的影响就会越小，只须要确定在小范畴内的绝对地位即可。而基于控件指标的定位，恰好能够把指标区域放大到一个指定区域，咱们刚好能够将二者联合起来，同时解决定位精准度和稳定性的问题。 对于简单手势的反对，咱们同样能够采纳微分的形式，将一个简单手势拆成多个简略手势的组成，比方咱们能够将一个滑动操作的定位拆成两个局部：起始地位和终止地位，而这两个地位的定位，就变成了两个一般的单点手势操作定位了，能够通过下面提到的一个指标控件+绝对坐标的模式进行定位。核心思想都是将基于屏幕坐标点的定位操作，放大的指标控件的区域范畴内，以达到不受设施分辨率的影响，实现操作行为统一的成果。 4.5 可溯源的自动化测试测试全流程记录，问题溯源一键即达。测试的目标是保障App运行的稳固，测试过程中呈现Bug导致测试未通过时，须要溯源问题起因，产生的场景，乃至具体的执行步骤。这也是大多自动化测试工具/平台所欠缺的，即便发现了问题，排查工作也很艰难；这个问题在手工测试的时候，更为严重，往往因为很多缺点无奈复现而难以定位。 AlphaTest的自动化用例最小执行单元是操作指令，咱们将测试过程的每一条指令的执行情况和过程中的界面快照进行了记录，并在指令执行失败时，对异样起因进行了初步剖析。而后将整个用例的执行组合成了一份残缺的测试报告，可疾速溯源问题步骤。除此之外，咱们还减少大量的日志上报，并将整个用例测试过程进行了视频录制，来进一步帮忙疑难问题的排查。真正做到了用例回放测试可溯源。 4.6 用例的保护自动化用例须要继续地投入人力来保护么？架构降级，页面重构，用例须要全副从新录制么？因自动化工具/平台泛滥，妨碍长期落地应用的一大问题是用例保护老本高，很多工具/平台让咱们即使是应用上了自动化，但还须要继续投入人力保护用例的更新，最终的提效收益微不足道。对于用例更新保护，咱们能够梳理划分成三个场景： ...

近日，在2022年隐衷计算大会上，中国信通院颁布第六批可信隐衷计算评测后果，美团隐衷计算平台通过“联邦学习平安”和“多方平安计算根底能力”两个专项评测认证。2021年，美团曾经通过“联邦学习根底能力”专项评测认证。 通过这三项认证标志着美团隐衷计算平台（产品名为”四方街“）提供的数据安全流通技术计划，可能通过多方平安计算和联邦学习能力，服务于金融、医疗、政务、营销等场景下的数据交融需要，反对数据需求方、数据供给方、算法方在线实现数据申请、受权、剖析、建模、预测，确保数据可用不可见。 什么是认证？认证，就是证实产品符合标准。所以，产品认证须要先有规范。本次通过的两项认证，测试规范是《隐衷计算联邦学习产品安全要求和测试方法》和《基于多方平安计算的数据流通产品技术要求与测试方法》。 认证的标记：通过认证会颁发认证证书，或者容许产品应用认证标识，有些认证标识会加贴在商品或其包装上，向社会阐明其通过规范测试，符合标准中的要求和产品性能。 「联邦学习平安专项」，检测内容蕴含通用算法协定平安、平安求交协定平安、特色工程协定平安、联结建模协定平安、联结预测算法协定平安、AI攻打抵挡能力、明码平安、通信安全、受权平安、系统安全、稳定性、存储平安、日志与存证共13方面专项评测，全方位考查联邦学习零碎安全性。 多方平安计算根底能力，检测内容蕴含隐衷汇合求交、隐匿信息检索、联结统计、通用平安多方计算编译在内的评测项，并且在产品安全性、健壮性和稳定性方面都严格满足评测要求。 什么是隐衷计算？在2022年全国两会上，“数字经济治理”首次呈现在《政府工作报告》中，隐衷计算成为了新的重点。隐衷计算是在保证数据提供方不泄露原始数据的前提下，实现数据价值开掘的一系列信息技术，它为数据价值流通提供了一种“可用不可见”解决方案。 从原理上来看，隐衷计算是一套交融了密码学、数据迷信、人工智能、区块链等泛滥畛域的跨学科技术体系，蕴含三大技术计划路线：多方平安计算MPC、联邦学习FL、可信执行环境TEE。 从利用角度来看，隐衷计算正从金融畛域逐步推进到医疗、政务等多个畛域的倒退。隐衷计算首先在金融曾经有了大面积的落地与利用，包含银行风控、信贷业务和反欺诈等，同时在医疗的辅助诊断、政务数据凋谢、智慧城市和物联网等多种场景也曾经开始逐步摸索落地。 “可用不可见”的实现次要依附隐衷计算 隐衷计算外围解决了数据共享、数据可信、数据权属的问题。在以后的数字经济中，数据因素的重要性曾经被逐步认知，然而如何进行数据流转与治理，仍然面临着两大难题： 合规流转。随着隐衷相干法规的逐渐健全，数据不能再像之前那样明文传输流转。企业须要在爱护隐衷与满足合规要求的前提下来实现数据流通。数据权属。企业都将数据看作本人最重要的资产，不违心和其它机构分享数据。或者在某些企业的外部，因为数据安全隐衷，不同部门间的数据也不违心互相凋谢。而这些难题都能够通过隐衷计算来解决，隐衷计算的外围能力，能让各方在原始数据不出域的前提下，实现数据价值的流通。这一方面解决了数据融通的合规难题，另一方面爱护了数据所有方的数据所有权，实现数据的“可用不可见”。 将来，美团将持续深入摸索隐衷计算技术与美团业务联合的落地利用，充分利用技术平台劣势，平安合规的激活数据交融价值，助力美团各业务疾速与行业搭档发展宽泛且全面的单干，独特保障用户集体信息安全，促成数据因素高效良性流转。 浏览美团技术团队更多技术文章合集 前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试 | 在公众号菜单栏对话框回复【2021年货】、【2020年货】、【2019年货】、【2018年货】、【2017年货】等关键词，可查看美团技术团队历年技术文章合集。 | 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至tech@meituan.com申请受权。

9月5日，美团视觉智能部公布了YOLOv6 2.0版本，本次更新对轻量级网络进行了全面降级，量化版模型 YOLOv6-S 达到了 869 FPS，同时，还推出了综合性能优异的中大型网络（YOLOv6-M/L），丰盛了YOLOv6网络系列。其中，YOLOv6-M/L 在 COCO 上检测精度（AP）别离达到 49.5%/52.5%，在 T4 卡上推理速度别离可达 233/121 FPS（batch size =32）。GitHub下载地址：https://github.com/meituan/YOLOv6。欢送Star珍藏，随时取用。 官网出品具体的Tech Report带你解构YOLOv6：YOLOv6: A Single-Stage Object Detection Framework for Industrial Applications。 注：YOLOv6系列模型均在训练300epoch且不应用预训练模型或额定检测数据集下取得，”‡“示意采纳了自蒸馏算法，”∗“示意从官网代码库对公布模型进行从新测评的指标。以上速度指标均在T4 TRT7.2 环境下测试。 注：YOLOv6系列模型均在训练300epoch且不应用预训练模型或额定检测数据集下取得，”‡“示意采纳了自蒸馏算法，”∗“示意从官网代码库对公布模型进行从新测评的指标。以上速度指标均在T4 TRT7.2 环境下测试。 本次版本升级，次要有以下更新： 性能更强的全系列模型 针对中大型模型（YOLOv6-M/L），设计了新骨干网络 CSPStackRep，它在综合性能上比上一版的 Single Path 构造更具劣势。针对不同网络，系统性地验证了各种最新策略/算法的优劣，综合精度和速度，为每类网络抉择适合的计划。同时将模型整体训练工夫缩小了 50%，极大地晋升了模型的训练效率。引入自蒸馏思维并设计了新的学习策略，大幅晋升了 YOLOv6-M/L 的模型精度。通过训练时 Early Stop 强数据加强及推理时图像 Resize 优化策略，修复了后期版本中输出尺寸对齐到 640x640 后精度损失的问题，晋升了现有模型的理论部署精度。表 1 展现了 YOLOv6 与以后支流的其余 YOLO 系列算法相比拟的试验后果，比照业界其余 YOLO 系列，YOLOv6在所有系列均具备肯定的劣势： YOLOv6-M 在 COCO val 上 获得了 49.5% 的精度，在 T4 显卡上应用 TRT FP16 batchsize=32 进行推理，可达到 233 FPS 的性能。YOLOv6-L 在 COCO val 上 获得了 52.5% 的精度，在 T4 显卡上应用 TRT FP16 batchsize=32 进行推理，可达到 121 FPS 的性能。同时，YOLOv6-N/ S 模型在放弃等同推理速度状况下，大幅晋升了精度指标，训练400 epoch 的条件下，N 网络从 35.0% 晋升至 36.3%，S 网络从 43.1% 晋升至 43.8%。量身定制的量化计划 ...

在外卖广告CTR预估建模中，咱们依靠图技术在场景化上进行了一系列摸索。本文首先介绍了应用图网络技术的出发点，而后从特色层面的形象图关系到子图扩大以及场景感知子图，逐渐介绍如何应用图技术建模业务问题，并针对联结训练的线上服务细节及成果进行解释和剖析，心愿能给从事相干工作的同学带来一些帮忙或启发。1. 引言外卖曾经成为公众生存中十分的重要组成部分，大家也逐渐感触到外卖带来的便当。大数据和深度学习时代的到来，使点击率（Click Through Rate, CTR）/转化率（Conversion Rate, CVR）预估技术失去了长足的倒退，深度学习技术曾经成为业界的支流办法。美团外卖也通过利用深度模型，在线上获得了显著的收益。预估模型所做的事件，是建模蕴藏在数据中、在特定场景下用户和商品之间的关联性（即“人-货-场”）。以点击率预估为例，能够对画像特色、上下文特色、行为特色等进行建模，模型可能感知在该场景下用户和商品之间的关联。 美团外卖是一个场景化业务：用户以后决策是受不同场景因素独特影响的后果，这些场景因素包含但不限于LBS地理位置、商家营业状况、工夫餐段。比方在热闹商圈/小城市（LBS）下的工作日/非工作日/正餐/下午茶（工夫餐段），依据商家营业状况圈选商家。相比于传统电商业务来说，减少了LBS和时段的限度，其场景化因素更为丰盛。同时，外卖具备很强的即时需要性质，用户的决策链路会很短，长时间“逛”外卖App的状况较少，故单次用户决策具备短时性的特点，这也进一步对外卖场景化减少了更多的建模因素。 因而，如何将用户的外卖需要进行场景化建模，从而晋升用户在应用外卖时的下单体验，成为外卖预估模型须要重点解决的问题。 1.1 问题与挑战相较于传统电子商务，用户趣味在外卖业务下呈现出更加显著的场景化特点，具备【用户-场景-趣味-决策】链路：即用户在特定场景下，联合本身需要与集体饮食趣味，产生决策。 场景化建模在实质上，是在给定场景条件下，比方地理位置、餐段时间、天气等，基于用户趣味为用户匹配出最佳商品。围绕场景化建模这一指标，业界从不同角度进行了一系列技术摸索： 特色建模：结构用户-商品-场景交互的统计特色/穿插特色，例如：用户在午餐时段的品类偏好、用户夜宵时段点击商户数量统计等。序列建模：分场景行为序列，精细化刻画在不同场景下的用户趣味，例如：用户在不同蜂窝下的Session行为，在不同时间段的Session行为。以上建模办法可能建模场景因素在用户决策商品时的影响，但存在一些问题： 特色建模，尤其是特色穿插的过程中，容易引入噪声，会对模型学习产生负面影响。序列建模，依赖于用户行为的丰盛水平，在分场景行为划分下对低频用户的趣味刻画不敌对，同时高频用户的趣味刻画容易陷入个人兴趣关闭圈。穿插和序列范式对场景的刻画并不残缺，穿插范式存在维度下限，序列范式局限于用户已有行为偏好。因而，场景化建模存在以下挑战： 如何抽取无效场景特色穿插。如何突破序列建模下的趣味封闭性。如何残缺地对用户决策场景进行无效刻画。针对上述问题特点，通过逐层合成，咱们发现须要一种更加残缺、高效的信息表达方式，可能具备：关系预测能力、全局信息流传能力、高阶表达能力，而咱们在图技术的畛域中找到相应的解决方案，后文会针对这些问题和图技术的解法顺次进行开展，心愿这些思考和实践经验能对大家有所帮忙或者启发。 1.2 图技术介绍近些年来，随着图神经网络（Graph Neural Networks）的疾速倒退[1]，越来越多的人开始关注起图数据。工业界也呈现了图技术的相继落地，很多利用场景都能够形象为节点向量化示意、分类、聚类、链接预测等图工作模式。 对于召回场景来说，基于多种实体间人造存在的关联交互图，构建深度匹配模型学习到的Embedding表白能够间接用来度量用户-商品的偏好、商品-商品关联。对于预估模型来说，最奢侈的视角，即是在用户-商品这个二部图上进行链接预测。在美团外部业务中，Graph Embedding/GNN技术在多个技术团队落地；如美团平台[2],[4],[10]相干工作以及外卖技术Represent-Learning我的项目等，都获得了不错的正向收益。 相比传统欧式空间结构类型数据，图构造数据具备以下特点： 结构化：图网络具备拓扑结构性，这种结构化个性往往代表了一些法则。例如节点重要性，社区构造等。关联化：图网络提供了一种简单关系和交互的度量办法。例如关联关系、依赖关系能够通过图表征学习进行度量。全局化：图网络构建采纳全域数据，相比私域化的序列数据，图构造数据更加可能体现出群体偏好信息。强泛化：利用图网络的音讯流传机制，图上节点丰盛信息更容易流传到冷门节点上，进步冷门节点表达能力。从业界信息示意的发展趋势来看，信息示意是在升维的：从手工特色，到序列建模，再到图建模，背地是对更加残缺信息的无效刻画的诉求。 手动特色时代：基于行为日志统计开掘用户/商家/商品画像。毛病是刻画粒度较粗、不精准、表达能力无限。Neural Network（NN）序列模型时代：基于原始行为序列设计用户趣味提取模块端到端学习用户趣味。长处是肯定水平从多峰和动静演变方面晋升了用户趣味表白的准确性。毛病是较难学习到结构化信息，对于行为数据强依赖，头部用户行为密集，中长尾用户行为稠密。Graph Neural Network（GNN）时代：万物皆图。序列能够看做是一个子图，相比于序列，图构造数据对于信息的表白，更加结构化、残缺、丰盛。在日常业务优化中咱们也发现，如果说要找到一种形式化的建模语言可能精确、残缺的翻译出咱们的业务场景，那么出现进去的建模语言就是“图”。 因而，咱们期待通过图技术手段，实现外卖场景下的场景建模。以下咱们将从图算法摸索和具体工程实际落地两大方面，论述咱们在图技术场景建模上的尝试及教训。 2. 图技术的场景化摸索外卖场景化是指基于用户-商家/商品残缺交互信息（< User、POI、Time、Location >）中开掘到的共性Pattern。咱们通过构建用户-商家/商品交互场景图来刻画和提取这个Pattern，并将场景先验常识引入到预估模型当中辅助决策。业界曾经有前沿摸索将GNN利用于LBS场景建模，如美团平台的STGCN[2]从时空联合的角度形容了LBS场景下GNN利用，外卖数据组的“门控超图GNN”[3]形容了超图在外卖LBS场景化建模的利用；比照一般GNN办法都获得了SOTA的成果。 针对美团外卖的场景化建模特点，咱们在图算法上也进行了一系列摸索，别离在场景特色穿插、子图拓展感知、元门路场景图三个方面，围绕着在不同场景下的用户-POI建模的指标，进行了多方面的摸索，在离线评估、线上业务上均获得了不错的成果。 2.1 基于特色图的场景特色穿插建模2.1.1 场景特色穿插特色是机器学习模型的源能源，业界常言“特色的下限决定了模型的下限”。NN时代以前，模型成果的晋升有很大一部分来自于特色工程。随着模型进入NN时代，NN模型具备的拟合能力以及在数据红利的加持下，极大地缩小了算法工程师们在特色工程上的精力开销，工作重点开始聚焦于模型构造。尽管实践上NN能够拟合所有函数，但在无限的数据和训练周期内，无奈疾速地迫近成果下限。在这种背景下，显式特色穿插重新得到大家的关注，围绕主动穿插特色，业界陆续迭代出FM/xDeepFM/DCN/CAN等模型，并获得了十分好的成果。 在美团外卖场景，也经验了第一阶段的手动穿插特色，以及第二阶段的主动穿插特色。但在场景化建模中咱们发现：穿插特色带来了信息增益，但往往也会带来“噪声”问题；比方具体到样本粒度来说，不同类型的样本所须要的无效穿插特色并不是完全一致，存在差异性。近两年业界的一些工作，如Fi-GNN、L0-SIGN、阿里FIVES等，也都在对应的业务中发现全量信息穿插引入噪声问题。 因而，从迭代思路来看，心愿可能引入更多的穿插特色，同时也缩小噪声信息的引入，实现在样本粒度的“个性化”穿插特色。 2.1.2 图视角的特色穿插特色穿插，能够形象为“从全量特色集中，抉择出K组特色两两组合，实现给模型带来高效非线性表达能力的目标”。实质上能够看做是特色-特色之间二部图的关系预测：将特色看作节点，特色之间的关联关系看作边，则能够将所有特色之间的关联关系形成一张图网络。两个节点连边的权重，可看作对应特色之间穿插关系的强弱。通过将此关系图嵌入到模型训练过程中，关系图中不同边权即反映了不同特色穿插的重要水平。 每个样本中N个特色相互之间形成一个全连通图记为M，图中的每个顶点示意特色F，顶点之间的边示意任意两个特色Fi和Fj的关联度，记为M<i, j>。通过联结训练关系图和预估模型，更新参数矩阵M，使关系图的语义信息与预估模型放弃相关性和一致性，次要过程如下图3所示： 次要步骤可形容如下： Step1. 建设参数矩阵（随机初始化失去），对特色所对应的向量示意做点积，后果作为关联系数。Step2. 对矩阵施加L0惩办，用于限度矩阵M的参数尽量靠近0，缩小无用的场景穿插。Step3. 参数矩阵0,1化，用于确定须要参加聚合的节点。Step4. 图聚合，对于每个特色来说，与其存在交互的多个特色进行聚合操作，聚合形式应用Attention。Step5. 将聚合后的特征向量示意，做为该特色新的向量示意，用在上游CTR预估的联结训练中。通过特色穿插系数形象为图的边权重要性评估问题，使模型具备了对场景特色之间关联强弱的预测能力，从而可能更加高效地引入穿插特色，为用户的场景化建模提供更多的信息输出。 2.2 基于子图扩大的行为图建模2.2.1 场景序列建模的痛点和图解决思路在外卖算法模型迭代中，序列建模也经验了较长时间的迭代，从单场景短期Session建模到多场景用户长期行为趣味建模，在多个方向上都做出了详尽的摸索。序列建模可能在用户历史行为中，充沛挖掘用户的趣味偏好，然而因为用户行为序列自身是“有偏采样”的反馈：不同用户所处的地理位置、商家供应状况、应用频次等方面存在着较大差别；且高低频用户的点击行为散布差别显著，呈现出高频用户行为丰盛汇集、低频用户行为稠密的特点。 对于高频用户，可能会导致趣味圈关闭导致模型建模无奈跳脱既有的趣味圈；对于低频用户，因为信息的不足导致其趣味刻画不残缺。因而，咱们须要具备拓展用户趣味边界的信息扩大能力、对单点信息的裁减能力；即寻找一种新的数据结构，突破二维线性限度，实现三维平面扩大，基于此种想法，咱们从图的角度来从新思考用户行为建模：以私域线性行为序列作为趣味刻画根底，以公域全局互联关系图作为趣味补充，建设个体差异性与群体共性的连贯。 2.2.2 行为POI子图设计用户行为信息是指用户在平台的点击/下单流动记录，是最原始最间接的对于用户趣味的刻画，尤其是针对行为稠密用户来说，行为POI序列中任意节点都值得器重。但对于这部分用户，仅仅依附个人行为POI很难建模趣味，如果可能通过图的形式扩大用户行为，可能有机会跳脱集体私域行为限度，透过全局行为图捕获不同场景下的潜在趣味。 咱们基于用户Session行为构建了POI网络：在同一个Session里，用户所点击过的POI存在关联，那么能够将每个Session里的POI构建一个连通图；因为不同用户行为的POI是有重叠的，整个外卖场景下的不同POI簇之间通过这些重叠的POI链接，就能够造成一张POI网络。对于任意一个POI，咱们都能够从POI行为网络中，寻找到该POI的一跳、二跳街坊，这些街坊能够作为POI信息的相干补充。这样，对于用户的行为趣味刻画，不仅仅局限在用户已有的序列上，而是能够通过子图进一步扩大。 相比传统序列建模办法，图网络建模能够利用全局用户行为互联的高阶网络结构，借助POI序列扩大用户趣味： 对于行为稠密用户，通过全局行为互联图，补充用户趣味建模线索。缓解基于密集用户行为建模产生的马太效应，跳出历史行为摸索潜在趣味，晋升举荐后果泛化性。具体的，针对用户行为序列中的每一个POI，都能够通过子图进行扩大，扩大后的子图通过卷积的形式造成POI的向量示意，如下图（左）所示。通过行为序列的扩大，使用户行为失去补充，从而得以跳出用户个人兴趣局限，丰盛用户和POI的信息表白。 在POI子图的根底上，咱们进一步思考如何无效地聚合不同POI，达到子图信息更加残缺的表白。 建模不同POI之间强弱不同的关联关系，应用Attention构造动态分配确定POI在所属子图中的贡献度。思考到POI子图是由Session构建的，用户的行为序列存在差别，相应地POI信息表白在不同用户序列中也存在差别，POI子图信息应该在不同行为上下文序列中自适应表白。为了捕获这种差异性，在子图卷积的过程中，咱们将核心节点与以后行为序列中其余节点做聚合，从而建模行为上下文场景关联性。核心节点不仅受到序列和子图影响，也受到以后候选POI的影响。因而在联结上游训练的过程中，咱们将核心节点与样本Target POI进行聚合。 离线训练时，是基于用户行为序列，对序列中每个POI作趣味子图拓展；而子图生成时采纳预采样（Message Passing）+联结训练聚合的形式；通过以上三种聚合形式，失去属于行为序列中POI对应的向量示意。因为这个过程不仅是扩大了POI，还将序列信息、候选POI信息思考到了每个节点的示意中，咱们称这种为子图感知卷积。通过子图感知卷积，使卷积的过程中，POI的向量示意与上下文信息产生关联，从而使POI的嵌入示意交融了更准确的趣味信息。 ...

分布式系统设计是一项十分复杂且具备挑战性的事件。其中，数据复制与一致性更是其中非常重要的一环。数据复制畛域概念庞杂、理论性强，如果对应的算法没有实践验证大概率会出错。如果在设计过程中，不理解对应实践所解决的问题以及不同实践之间的分割，势必无奈设计出一个正当的分布式系统。 本系列文章分高低两篇，以《数据密集型利用零碎设计（DDIA）》（下文简称《DDIA》）为主线，文中的外围实践解说与图片来自于此书。在此基础上，退出了日常工作中对这些概念的了解与个性化的思考，并将它们映射到Kafka中，跟大家分享一下如何将具体的实践利用于理论生产环境中。 1. 简介1.1 简介——应用复制的目标在分布式系统中，数据通常须要被扩散在多台机器上，次要为了达到以下目标： 扩展性，数据量因读写负载微小，一台机器无奈承载，数据扩散在多台机器上能够无效地进行负载平衡，达到灵便的横向扩大。容错、高可用，在分布式系统中，单机故障是常态，在单机故障下依然心愿零碎可能失常工作，这时候就须要数据在多台机器上做冗余，在遇到单机故障时其余机器就能够及时接管。对立的用户体验，如果零碎客户端散布在多个地区，通常思考在多个地区部署服务，以不便用户可能就近拜访到他们所须要的数据，取得对立的用户体验。数据的多机散布的形式次要有两种，一种是将数据分片保留，每个机器保留数据的局部分片（Kafka中称为Partition，其余局部零碎称为Shard），另一种则是齐全的冗余，其中每一份数据叫做一个正本（Kafka中称为Replica），通过数据复制技术实现。在分布式系统中，两种形式通常会独特应用，最初的数据分布往往是下图的样子，一台机器上会保留不同数据分片的若干个正本。本系列博文次要介绍的是数据如何做复制，分区则是另一个主题，不在本文的探讨领域。 复制的指标须要保障若干个正本上的数据是统一的，这里的“统一”是一个非常不确定的词，既能够是不同正本上的数据在任何时刻都放弃完全一致，也能够是不同客户端不同时刻拜访到的数据保持一致。一致性的强弱也会不同，有可能须要任何时候不同客端都能拜访到雷同的新的数据，也有可能是不同客户端某一时刻拜访的数据不雷同，但在一段时间后能够拜访到雷同的数据。因而，“一致性”是一个值得独自抽出来细说的词。在下一篇文章中，咱们将重点介绍这个词在不同上下文之间的含意。 此时，大家可能会有疑难，间接让所有正本在任意时刻都保持一致不就行了，为啥还要有各种不同的一致性呢？咱们认为有两个考量点，第一是性能，第二则是复杂性。 性能比拟好了解，因为冗余的目标不齐全是为了高可用，还有提早和负载平衡这类晋升性能的目标，如果只一味地为了地强调数据统一，可能得失相当。复杂性是因为分布式系统中，有着比单机零碎更加简单的不确定性，节点之间因为采纳不大牢靠的网络进行传输，并且不能共享对立的一套零碎工夫和内存地址（后文会具体进行阐明），这使得本来在一些单机零碎上很简略的事件，在转到分布式系统上当前就变得异样简单。这种复杂性和不确定性甚至会让咱们狐疑，这些正本上的数据真的能达成统一吗？下一篇文章会专门详细分析如何设计算法来应答这种简单和不确定性。 1.2 文章系列概述本系列博文将分为高低两篇，第一篇将次要介绍几种常见的数据复制模型，而后介绍分布式系统的挑战，让大家对分布式系统一些稀奇古怪的故障有一些理性的意识。 第二篇文章将针对本篇中提到的问题，别离介绍事务、分布式共识算法和一致性，以及三者的内在联系，再分享如何在分布式系统中保证数据的一致性，进而让大家对数据复制技术有一个较为全面的意识。此外，本系列还将介绍业界验证分布式算法正确性的一些工具和框架。接下来，让咱们一起开始数据复制之旅吧！ 2. 数据复制模式总体而言，最常见的复制模式有三种，别离为主从模式、多主节点模式、无主节点模式，上面别离进行介绍。 2.1 最简略的复制模式——主从模式简介对复制而言，最直观的办法就是将正本赋予不同的角色，其中有一个主正本，主正本将数据存储在本地后，将数据更改作为日志，或者以更改流的形式发到各个从正本（后文也会称节点）中。在这种模式下，所有写申请就全副会写入到主节点上，读申请既能够由主正本承当也能够由从正本承当，这样对于读申请而言就具备了扩展性，并进行了负载平衡。但这外面存在一个衡量点，就是客户端视角看到的一致性问题。这个衡量点存在的外围在于，数据传输是通过网络传递的，数据在网络中传输的工夫是不能疏忽的。 如上图所示，在这个工夫窗口中，任何状况都有可能产生。在这种状况下，客户端何时算写入实现，会决定其余客户端读到数据的可能性。这里咱们假如这份数据有一个主正本和一个从正本，如果主正本保留后即向客户端返回胜利，这样叫做异步复制（1）。而如果等到数据传送到从正本1，并失去确认之后再返回客户端胜利，称为同步复制（2）。这里咱们先假如零碎失常运行，在异步同步下，如果从正本承当读申请，假如reader1和reader2同时在客户端收到写入胜利后收回读申请，两个reader就可能读到不一样的值。 为了防止这种状况，实际上有两种角度的做法，第一种角度是让客户端只从主正本读取数据，这样，在失常状况下，所有客户端读到的数据肯定是统一的（Kafka以后的做法）；另一种角度则是采纳同步复制，假如应用纯的同步复制，当有多个正本时，任何一个正本所在的节点产生故障，都会使写申请阻塞，同时每次写申请都须要期待所有节点确认，如果正本过多会极大影响吞吐量。而如果仅采纳异步复制并由主正本承当读申请，当主节点故障产生切换时，一样会产生数据不统一的问题。 很多零碎会把这个决策权交给用户，这里咱们以Kafka为例，首先提供了同步与异步复制的语义（通过客户端的acks参数确定），另外提供了ISR机制，而只须要ISR中的正本确认即可，零碎能够容忍局部节点因为各种故障而脱离ISR，那样客户端将不必期待其确认，减少了零碎的容错性。以后Kafka未提供让从节点承当读申请的设计，但在高版本中曾经有了这个Feature。这种形式使零碎有了更大的灵活性，用户能够依据场景自在衡量一致性和可用性。 主从模式下须要的一些能力减少新的从正本（节点） 在Kafka中，咱们所采取的的形式是通过新建正本调配的形式，以追赶的形式从主正本中同步数据。数据库所采纳的的形式是通过快照+增量的形式实现。 a.在某一个工夫点产生一个一致性的快照。 b.将快照拷贝到从节点。 c.从节点连贯到主节点申请所有快照点后产生的扭转日志。 d.获取到日志后，利用日志到本人的正本中，称之为追赶。 e.可能反复多轮a-d。 解决节点生效 从节点生效——追赶式复原 针对从节点生效，复原伎俩较为简单，个别采纳追赶式复原。而对于数据库而言，从节点能够晓得在解体前所执行的最初一个事务，而后连贯主节点，从该节点将拉取所有的事件变更，将这些变更利用到本地记录即可实现追赶。 对于Kafka而言，复原也是相似的，Kafka在运行过程中，会定期项磁盘文件中写入checkpoint，共蕴含两个文件，一个是recovery-point-offset-checkpoint，记录曾经写到磁盘的offset，另一个则是replication-offset-checkpoint，用来记录高水位（下文简称HW），由ReplicaManager写入，下一次复原时，Broker将读取两个文件的内容，可能有些被记录到本地磁盘上的日志没有提交，这时就会先截断（Truncate）到HW对应的offset上，而后从这个offset开始从Leader正本拉取数据，直到认追上Leader，被退出到ISR汇合中 主节点生效--节点切换 主节点生效则会稍稍简单一些，须要经验三个步骤来实现节点的切换。 确认主节点生效，因为生效的起因有多种多样，大多数零碎会采纳超时来断定节点生效。个别都是采纳节点间互发心跳的形式，如果发现某个节点在较长时间内无响应，则会认定为节点生效。具体到Kafka中，它是通过和Zookeeper（下文简称ZK）间的会话来放弃心跳的，在启动时Kafka会在ZK上注册长期节点，尔后会和ZK间维持会话，假如Kafka节点呈现故障（这里指被动的掉线，不蕴含被动执行停服的操作），当会话心跳超时时，ZK上的长期节点会掉线，这时会有专门的组件（Controller）监听到这一信息，并认定节点生效。选举新的主节点。这里能够通过通过选举的形式（民主协商投票，通常应用共识算法），或由某个特定的组件指定某个节点作为新的节点（Kafka的Controller）。在选举或指定时，须要尽可能地让新主与原主的差距最小，这样会最小化数据失落的危险（让所有节点都认可新的主节点是典型的共识问题）——这里所谓共识，就是让一个小组的节点就某一个议题达成统一，下一篇文章会重点进行介绍。重新配置零碎是新的主节点失效，这一阶段根本能够了解为对集群的元数据进行批改，让所有外界晓得新主节点的存在（Kafka中Controller通过元数据播送实现），后续及时旧的节点启动，也须要确保它不能再认为本人是主节点，从而承当写申请。问题 尽管上述三个步骤较为清晰，但在理论产生时，还会存在一些问题： 假如采纳异步复制，在生效前，新的主节点与原主节点的数据存在Gap，选举实现后，原主节点很快从新上线退出到集群，这时新的主节点可能会收到抵触的写申请，此时还未齐全执行上述步骤的第三步，也就是原主节点没有意识到本人的角色发生变化，还会尝试向新主节点同步数据。这时，个别的做法是，将原主节点上未实现复制的写申请丢掉，但这又可能会产生数据失落或不统一，假如咱们每条数据采纳MySQL的自增ID作为主键，并且应用Redis作为缓存，假如产生了MySQL的主从切换，从节点的计数器落后于主节点，那样可能呈现利用获取到旧的自增ID，这样就会与Redis上对应ID取到的数据不统一，呈现数据泄露或失落。假如下面的问题，原主节点因为一些故障永远不晓得本人角色曾经变更，则可能产生“脑裂”，两个节点同时操作数据，又没有相应解决抵触（没有设计这一模块），就有可能对数据造成毁坏。此外，对于超时工夫的设定也是个十分复杂的问题，过长会导致服务不可用，设置过短则会导致节点频繁切换，假如自身零碎处于高负载状态，频繁角色切换会让负载进一步减轻（团队外部对Kafka僵尸节点的解决逻辑）。异步复制面临的次要问题--复制滞后如前文所述，如果咱们应用纯的同步复制，任何一台机器产生故障都会导致服务不可写入，并且在数较多的状况下，吞吐和可用性都会受到比拟大的影响。很多零碎都会采纳半步复制或异步复制来在可用性和一致性之间做衡量。 在异步复制中，因为写申请写到主正本就返回胜利，在数据复制到其余正本的过程中，如果客户端进行读取，在不同正本读取到的数据可能会不统一，《DDIA》将这个种景象称为复制滞后（Replication Lag），存在这种问题的复制行为所造成的数据一致性统称为最终一致性。将来还会重点介绍一下一致性和共识，但在本文不做过多的介绍，感兴趣的同学能够提前浏览《Problems with Replication Lag》这一章节。 2.2 多主节点复制前文介绍的主从复制模型中存在一个比较严重的弊病，就是所有写申请都须要通过主节点，因为只存在一个主节点，就很容易呈现性能问题。尽管有从节点作为冗余应答容错，但对于写入申请实际上这种复制形式是不具备扩展性的。 此外，如果客户端来源于多个地区，不同客户端所感知到的服务相应工夫差距会十分大。因而，有些零碎顺着传统主从复制进行延长，采纳多个主节点同时承当写申请，主节点接到写入申请之后将数据同步到从节点，不同的是，这个主节点可能还是其余节点的从节点。复制模式如下图所示，能够看到两个主节点在接到写申请后，将数据同步到同一个数据中心的从节点。此外，该主节点还将一直同步在另一数据中心节点上的数据，因为每个主节点同时解决其余主节点的数据和客户端写入的数据，因而须要模型中减少一个抵触解决模块，最初写到主节点的数据须要解决抵触。 应用场景a. 多数据中心部署 个别采纳多主节点复制，都是为了做多数据中心容灾或让客户端就近拜访（用一个高大上的名词叫做异地多活），在同一个地区应用多主节点意义不大，在多个地区或者数据中心部署相比主从复制模型有如下的劣势： 性能晋升：性能晋升次要体现在两个外围指标上，首先从吞吐方面，传统的主从模型所有写申请都会通过主节点，主节点如果无奈采纳数据分区的形式进行负载平衡，可能存在性能瓶颈，采纳多主节点复制模式下，同一份数据就能够进行负载平衡，能够无效地晋升吞吐。另外，因为多个主节点散布在多个地区，处于不同地区的客户端能够就近将申请发送到对应数据中心的主节点，能够最大水平地保障不同地区的客户端可能以类似的提早读写数据，晋升用户的应用体验。容忍数据中心生效：对于主从模式，假如主节点所在的数据中心产生网络故障，须要产生一次节点切换才可将流量全副切换到另一个数据中心，而采纳多主节点模式，则可无缝切换到新的数据中心，晋升整体服务的可用性。b.离线客户端操作 除了解决多个地区容错和就近拜访的问题，还有一些乏味的场景，其中一个场景则是在网络离线的状况下还能持续工作，例如咱们笔记本电脑上的笔记或备忘录，咱们不能因为网络离线就禁止应用该程序，咱们仍然能够在本地欢快的编辑内容（图中标记为Offline状态），当咱们连上网之后，这些内容又会同步到近程的节点上，这外面咱们把本地的App也当做其中的一个正本，那么就能够承当用户在本地的变更申请。联网之后，再同步到近程的主节点上。 c.协同编辑 这里咱们对离线客户端操作进行扩大，假如咱们所有人同时编辑一个文档，每个人通过Web客户端编辑的文档都能够看做一个主节点。这里咱们拿美团外部的学城（外部的Wiki零碎）举例，当咱们正在编辑一份文档的时候，基本上都会发现右上角会呈现“xxx也在协同编辑文档”的字样，当咱们保留的时候，零碎就会主动将数据保留到本地并复制到其余主节点上，各自解决各自端上的抵触。 另外，当文档呈现了更新时，学城会告诉咱们有更新，须要咱们手动点击更新，来更新咱们本地主节点的数据。书中阐明，尽管不能将协同编辑齐全等同于数据库复制，但却是有很多相似之处，也须要解决抵触问题。 抵触解决通过下面的剖析，咱们理解到多主复制模型最大挑战就是解决抵触，上面咱们简略看下《DDIA》中给出的通用解法，在介绍之前，咱们先来看一个典型的抵触。 a.抵触实例 在图中，因为多主节点采纳异步复制，用户将数据写入到本人的网页就返回胜利了，但当尝试把数据复制到另一个主节点时就会出问题，这里咱们如果假如主节点更新时采纳相似CAS的更新形式时更新时，都会因为预期值不合乎从而回绝更新。针对这样的抵触，书中给出了几种常见的解决思路。 b.解决思路1. 防止抵触 所谓解决问题最基本的形式则是尽可能不让它产生，如果可能在应用层保障对特定数据的申请只产生在一个节点上，这样就没有所谓的“写抵触”了。持续拿下面的协同编辑文档举例，如果咱们把每个人的都在填有本人姓名表格的一行外面进行编辑，这样就能够最大水平地保障每个人的批改范畴不会有重叠，抵触也就迎刃而解了。 2. 收敛于统一状态 然而，对更新题目这种状况而言，抵触是没法防止的，但还是须要有办法解决。对于单主节点模式而言，如果同一个字段有屡次写入，那么最初写入的肯定是最新的。ZK、KafkaController、KafkaReplica都有相似Epoch的形式去屏蔽过期的写操作，因为所有的写申请都通过同一个节点，程序是相对的，但对于多主节点而言，因为没有相对程序的保障，就只能试图用一些形式来决策绝对程序，使抵触最终收敛，这里提到了几种办法： 给每个写申请调配Uniq-ID，例如一个工夫戳，一个随机数，一个UUID或Hash值，最终取最高的ID作为最新的写入。如果基于工夫戳，则称作最初写入者获胜（LWW），这种形式看上去十分间接且简略，并且十分风行。但很遗憾，文章一开始也提到了，分布式系统没有方法在机器间共享一套对立的零碎工夫，所以这个计划很有可能因为这个问题导致数据失落（时钟漂移）。 每个正本调配一个惟一的ID，ID高的更新优先级高于地区低的，这显然也会失落数据。 当然，咱们能够用某种形式做拼接，或利用事后定义的格局保留抵触相干信息，而后由用户自行解决。 3. 用户自行处理 ...

本文次要介绍事务、一致性以及共识，首先会介绍它们怎么在分布式系统中起作用，而后将尝试形容它们之间的内在联系，让大家理解，在设计分布式系统时也是有肯定的“套路”可寻。最初将介绍业界验证分布式算法的一些工具和框架。心愿可能对大家有所帮忙或者启发。 1. 前文回顾在上一篇中，咱们次要介绍了分布式系统中常见的复制模型，并形容了每一种模型的优缺点以及应用场景，同时论述了分布式系统中特有的一些技术挑战。首先，常见的分布式系统复制模型有3种，别离是主从复制模型、多主复制模型以及无主复制模型。此外，复制从客户端的时效性来说分为同步复制&&异步复制，异步复制具备滞后性，可能会造成数据不统一，因为这个不统一，会带来各种各样的问题。 此外，第一篇文章用了“老板安顿人干活”的例子比喻了分布式系统中特有的挑战，即局部生效以及不牢靠的时钟问题。这给分布式系统设计带来了很大的困扰。仿佛在没有机制做保障的状况下，一个奢侈的分布式系统什么事件都做不了。 在上一篇的最初，咱们对分布式系统零碎模型做了一些假如，这些假如对给出前面的解决方案其实是十分重要的。首先针对局部生效，是咱们须要对系统的超时进行假如，个别咱们假如为半同步模型，也就是说个别状况下提早都十分失常，一旦产生故障，提早会变得偏差十分大。另外，对于节点生效，咱们通常在设计零碎时假如为解体-复原模型。最初，面对分布式系统的两个保障Safty和Liveness，咱们优先保证系统是Safety，也就是平安；而Liveness（活性）通常在某些前提下才能够满足。 2. 本文简介通过第一篇文章，咱们晓得了留待咱们解决的问题有哪些。那么这篇文章中，将别离依据咱们的假如去解决上述的挑战。这些保障措施包含事务、一致性以及共识。接下来讲介绍它们的作用以及内在联系，而后咱们再回过头来扫视一下Kafka复制局部的设计，看看一个理论的零碎在设计上是否真的能够间接应用那些套路，最初介绍业界验证分布式算法的一些工具和框架。接下来，持续咱们的数据复制之旅吧！ 3. 事务&内部一致性说到事务，置信大家都能简略说出个一二来，首先能本能做出反馈出的，应该就是所谓的“ACID”个性了，还有各种各样的隔离级别。是的，它们的确都是事务须要解决的问题。 在这一章中，咱们会更加有条理地了解下它们之间的内在联系，具体看一看事务到底要解决什么问题。在《DDIA》一书中有十分多对于数据库事务的具体实现细节，但本文中会弱化它们，毕竟本文不想具体介绍如何设计一款数据库，咱们只需探索问题的自身，等真正寻找解决方案时再去具体看设计，成果可能会更好。上面咱们正式开始介绍事务。 3.1 事务的产生零碎中可能会面临上面的问题： 程序依靠的操作系统层，硬件层可能随时都会产生故障（包含一个操作执行到一半时）。应用程序可能会随时产生故障（包含操作执行到一半时）。网络中断可能随时会产生，它会切断客户端与服务端的链接或数据库之间的链接。多个客户端可能会同时拜访服务端，并且更新对立批数据，导致数据相互笼罩（临界区）。客户端可能会读到过期的数据，因为下面说的，可能操作执行一半应用程序就挂了。假如上述问题都会呈现在咱们对于存储系统（或者数据库）的拜访中，这样咱们在开发本人应用程序的同时，还须要额定付出很大代价解决这些问题。事务的外围使命就是尝试帮咱们解决这些问题，提供了从它本人层面所看到的安全性保障，让咱们在拜访存储系统时只专一咱们自身的写入和查问逻辑，而非这些额定简单的异样解决。而说起解决形式，正是通过它那赫赫有名的ACID个性来进行保障的。 3.2 不厌其烦——ACID个性这四个缩写所组成的个性置信大家已造成本能反馈，不过《DDIA》一书中给出的定义的确更加有利于咱们更加清晰地了解它们间的关系，上面将别离进行阐明： A：原子性(Atomicity)：原子性理论形容的是同一个客户端对于多个操作之间的限度，这里的原子示意的是不可分割，原子性的成果是，假如有操作汇合{A,B,C,D,E}，执行后的后果应该和单个客户端执行一个操作的成果雷同。从这个限度咱们能够晓得： 对于操作自身，就算产生任何故障，咱们也不能看到任何这个操作集中间的后果，比方操作执行到C时产生了故障，然而事务应该重试，直到咱们须要等到执行完之后，要么咱们应该复原到执行A之前的后果。对于操作作用的服务端而言，呈现任何故障，咱们的操作不应该对服务端产生任何的副作用，只有这样客户端能力平安的重试，否则，如果每次重试都会对服务端产生副作用，客户端是不敢始终平安的重试的。因而，对于原子性而言，书中形容说的是能在执行产生异样时抛弃，能够间接终止，且不会对服务端产生任何副作用，能够平安的重试，原子性也成为“可终止性”。 C：一致性（Consistency）：这个名词有太多的重载，也就是说它在不同语境中含意会截然不同，但可能又有分割，这就可能让咱们陷入凌乱，比方： 数据复制时，正本间具备一致性，这个一致性应该指上一章中提到的不同正本状态的统一。一致性Hash，这是一种分区算法，集体了解是为了可能在各种状况下这个Hash算法都能够以统一的形式发挥作用。CAP定理中的一致性指的是前面要介绍的一个非凡的外部一致性，称为“线性一致性”。咱们稍后要介绍ACID中的一致性，指的是程序的某些“不变式”，或“良好状态”。咱们须要辨别不同语境中一致性所表白含意的区别，也心愿大家看完明天的分享，能更好地帮忙大家记住这些区别。话说回来，这里的一致性指的是对于数据一组特定陈说必须成立，即“不变式”，这里有点相似于算法中的“循环不变式”，即当外界环境发生变化时，这个不变式肯定须要成立。 书中强调，这个外面的一致性更多须要用户的应用程序来保障，因为只有用户晓得所谓的不变式是什么。这里举一个简略的小例子，例如咱们往Kafka中append音讯，其中有两条音讯内容都是2，如果没有额定的信息时，咱们也不晓得到底是客户端因为故障重试发了两次，还是真的就有两条截然不同的数据。 如果想进行辨别，能够在用户程序生产后走自定义的去重逻辑，也能够从Kafka本身登程，客户端发送时减少一个“发号”环节表明音讯的唯一性（高版本中Kafka事务的实现大抵思路）这样引擎自身就具备了肯定的本人设置“不变式”的能力。不过如果是更简单的状况，还是须要用户程序和调用服务自身独特保护。 I：隔离性（Isolation）：隔离性实际上是事务的重头戏，也是门道最多的一环，因为隔离性解决的问题是多个事务作用于同一个或者同一批数据时的并发问题。一提到并发问题，咱们就晓得这肯定不是个简略的问题，因为并发的实质是时序的不确定性，当这些不确定时序的作用域有肯定抵触（Race）时就可能会引发各种各样的问题，这一点和多线程编程是相似的，但这外面的操作远比一条计算机指令工夫长得多，所以问题会更重大而且更多样。 这里给一个具体的实例来直观感触下，如下图展现了两个客户端并发的批改DB中的一个counter，因为User2的get counter产生的时刻在User1更新的过程中，因而读到的counter是个旧值，同样User2更新也相似，所以最初应该预期counter值为44，后果两个人看到的counter都是43（相似两个线程同时做value++）。 一个完满的事务隔离，在每个事务看来，整个零碎只有本人在工作，对于整个零碎而言这些并发的事务一个接一个的执行，也好像只有一个事务，这样的隔离成为“可序列化（Serializability）”。当然，这样的隔离级别会带来微小的开销，因而呈现了各种各样的隔离级别，进而满足不同场景的须要。后文会具体介绍不同的隔离级别所解决的问题。 D：持久性（Durability）：这个个性看似比拟好了解，就一点，只有事务实现，不论产生任何问题，都不应该产生数据失落。从实践上讲，如果是单机数据库，起码数据已被写入非易失性存储（至多已落WAL），分布式系统中数据被复制到了各个正本上，并受到正本Ack。但理论状况下，也未必就肯定能保障100%的持久性。这外面的状况书中有具体的介绍，这里就不做反复的Copy工作了，也就是说事务所保障的持久性个别都是某种衡量下的后果。 下面四个个性中，实际上对于隔离性的问题，可能是问题最多样的，也是最为简单的。因为一味强调“序列化”可能会带来不可承受的性能开销。因而，下文将重点介绍一些比可序列化更弱的隔离级别。 3.3 事务按操作对象的划分&&平安的提交重试在介绍前面内容前，有两件事须要当时做下强调，别离是事务操作的对象以及事务的提交与重试，分为单对象&&多对象。 单对象写入：这种书中给出了两种案例。 第一个是单个事物执行一个长时间的写入，例如写入一个20KB的JSON对象，假如写到10KB时断掉会产生什么？ a. 数据库是否会存在10KB没法解析的脏数据。 b. 如果复原之后数是否能接着持续写入。 c. 另一个客户端读取这个文档，是否可能看到复原后的最新值，还是读到一堆乱码。 另一种则是相似上图中Counter做自增的性能。这种事务的解决办法个别是通过日志回放（原子性）、锁（隔离性）、CAS（隔离性）等形式来进行保障。 多对象事务：这类事务实际上是比较复杂的，比方可能在某些分布式系统中，操作的对象可能会跨线程、跨过程、跨分区，甚至跨零碎。这就意味着，咱们面临的问题多于上一篇文章提到的那些分布式系统特有的问题，解决那些问题显然要更简单。有些零碎罗唆把这种“锅”甩给用户，让应用程序本人来解决问题，也就是说，咱们可能须要本人解决因没有原子性带来的两头后果问题，因为没有隔离性带来的并发问题。当然，也有些零碎实现了这些所谓的分布式事务，后文中会介绍具体的实现伎俩。 另一个须要特别强调的点是重试，事务的一个外围个性就是当产生谬误时，客户端能够平安的进行重试，并且不会对服务端有任何副作用，对于传统的真的实现ACID的数据库系统，就应该遵循这样的设计语义。但在理论实际时，如何保障下面说的可能“平安的重试”呢？书中给出了一些可能产生的问题和解决伎俩： 假如事务提交胜利了，但服务端Ack的时候产生了网络故障，此时如果客户端发动重试，如果没有额定的伎俩，就会产生数据反复，这就须要服务端或应用程序本人提供可能辨别音讯唯一性的额定属性（服务端内置的事务ID或者业务本身的属性字段）。因为负载太大导致了事务提交失败，这是贸然重试会减轻零碎的累赘，这时可在客户端进行一些限度，例如采纳指数退却的形式，或限度一些重试次数，放入客户端本人零碎所属的队列等。在重试前进行判断，尽在产生临时性谬误时重试，如果利用曾经违反了某些定义好的束缚，那这样的重试就毫无意义。如果事务是多对象操作，并且可能在零碎中产生副作用，那就须要相似“两阶段提交”这样的机制来实现事务提交。3.4 弱隔离级别事务隔离要解决的是并发问题，并发问题须要探讨两个问题时序与竞争，往往因为事物之间的操作对象有竞争关系，并且又因为并发事务之间不确定的时序关系，会导致这些所操作的有竞争关系的对象会呈现各种奇怪的后果。 所谓不同的隔离级别，就是试图去用不同的开销来满足不同场景下对于时序要求的严格水平。咱们可能不肯定晓得具体怎么实现这些事务隔离级别，但每个隔离级别解决的问题自身咱们应该十分清晰，这样才不会在各种隔离级别和开销中比拟轻松的做衡量。这里，咱们不间接像书中一样列举隔离级别，咱们首先论述并发事务可能产生的问题，而后再去介绍每种隔离级别别离可能解决那些问题。 脏读所谓脏读，指的就是用户能不能看到一个还没有提交事务的后果，如果是，就是脏读。下图展现了没有脏读应该满足什么样的承诺，User1的一个事务别离设置x=3、y=3，但在这个事务提交之前，User2在调用get x时，须要返回2，因为此时User1并没有提交事务。 避免脏读的意义： 如果是单对象事务，客户端会看到一个一会行将可能被回滚的值，如果我须要根据这个值做决策，就很有可能会呈现决策谬误。如果是多对象事务，可能客户端对于不同零碎做拜访时一部分数据更新，一部分未更新，那样用户可能会手足无措。脏写如果一个客户端笼罩了另一个客户端尚未提交的写入，咱们就称这样的景象为脏写。 这里同样给个实例，对于一个二手车的交易，须要更新两次数据库实现，但有两个用户并发的进行交易，如果像图中一样不禁止脏写，就可能存在销售列表显示交易属于Bob但发票却发给了Alice，因为两个事务对于两个数据的雷同记录相互笼罩。 读偏差（不可反复读）间接上例子，Alice在两个银行账户总共有1000块，每个账户500，当初她想从一个账户向另一个账户转账100，并且她想始终盯着本人的两个账户看看钱是否转胜利了。不巧的是，他第一次看账户的时候转账还没产生，而胜利后只查了一个账户的值，正好少了100，所以最初加起来会感觉本人少了100元。 如果只是这种场景，其实只是个临时性的景象，前面再查问就会失去正确的值，然而如果基于这样的查问去做别的事件，那可能就会呈现问题了，比方将这个记录Select进去进行备份，以防DB解体。但不巧如果前面真的解体，如果基于这次查问到的数据做备份，那这100元可能真的永恒的失落了。如果是这样的场景，不可反复读是不能被承受的。 更新失落这里间接把之前那个两个用户同时依据旧值更新计数器的例子搬过去，这是个典型的更新失落问题： 写偏差 && 幻读这种问题形容的是，事务的写入须要依赖于之前判断的后果，而这个后果可能会被其余并发事务批改。 实例中有两个人Alice和Bob决定是否能够休班，做这个决定的前提是判断以后是否有两个以上的医生正在值班，如果是则本人能够平安的休班，而后批改值班医生信息。但因为应用了快照隔离（前面会介绍）机制，两个事务返回的后果全都是2，进入了批改阶段，但最终的后果其实是违反了两名医生值班的前提。 造成这个问题的根本原因是一种成为“幻读”的景象，也就是说两个并发的事务，其中一个事务更改了另一个事物的查问后果，这种查问个别都是查问一个聚合后果，例如上文中的count或者max、min等，这种问题会在上面场景中呈现问题。 抢订会议室多人游戏更新地位惟一用户名下面咱们列举了事务并发可能产生的问题，上面咱们介绍各种隔离级别所能解决的问题。 隔离级别&&简略实现伎俩/问题脏读脏写读偏差更新失落写偏差(幻读)读已提交(行锁 or 记住旧值)YYNNN可反复读(快照隔离，CAS)YYYMaybeN可串行化(2PL乐观锁 or SSI乐观锁)YYYYY3.5 本章小结事务用它的ACID个性，为用户屏蔽了一些谬误的解决。首先，原子性为用户提供了一个可平安重试的环境，并且不会对相应的零碎产生副作用。一致性可能在肯定水平上让程序满足所谓的不变式，隔离性通过不同的隔离级别解决不同场景下因为事务并发导致的不同景象，不同的隔离性解决的问题不同，开销也不同，须要用户按需决策，最初持久性让用户安心的把数据写进咱们设计的零碎。 ...

8小时不间断放送8大技术方向通道委员+学长在线答疑还有2000元美团卡、好运大礼包后盾开发 | 零碎开发 | 前端开发 | 算法策略数据开发 | 硬件开发 | 测试 | 运维 场次如何安顿？都有哪些嘉宾？尽在 ↓↓↓

往年，美团技术团队有多篇论文被KDD 2022收录，这些论文涵盖了图谱预训练、抉择算法、用意主动发现、成果建模、策略学习、概率预测、处分框架等多个技术畛域。本文精选了7篇论文做简要介绍（附下载链接），心愿能对从事相干钻研方向的同学有所帮忙或启发。ACM SIGKDD国内会议（简称 KDD）是由ACM的数据挖掘及常识发现专委会主办的数据挖掘钻研畛域的顶级年会，属于CCF A类会议。因为KDD的交叉学科性和宽泛应用性，其影响力也越来越大，吸引了来自统计、机器学习、数据库、万维网、生物信息学、多媒体、自然语言解决、人机交互、社会网络计算、高性能计算及大数据挖掘等泛滥畛域的从业者和钻研学者。第28届KDD会议于2022于8月14日至18日在美国华盛顿举办。 论文01：Mask and Reason: Pre-Training Knowledge Graph Transformers for Complex Logical Queries（反对常识推理的图谱预训练）| 下载地址：KG-Transformer | 论文作者：刘潇（清华大学）、赵时予（清华大学）、苏凯（清华大学）、岑宇阔（美团）、裘捷中（清华大学）、东昱晓（清华大学）、张梦迪（美团）、武威（美团）、唐杰（清华大学） | 论文简介：面向简单逻辑查问的常识图谱预训练。论文钻研了常识图谱中简单逻辑查问问题，探讨了支流的基于常识图谱嵌入的推理器的固有缺点，并提出了基于KGTransformer的新型图神经网络推理器，及其对应的预训练与微调办法。KGTransformer在两个次要的常识图谱推理数据集上获得了最优的后果，尤其是在域外工作上获得了良好的泛化性能，证实了这一思路利用于常识图谱推理的宽泛前景。 论文02：AutoFAS: Automatic Feature and Architecture Selection for Pre-Ranking System（粗排场景主动特色与构造抉择算法）| 下载地址：AutoFAS| 论文作者：李想（美团）、周晓江（美团）、肖垚（美团）、黄培浩（美团）、陈达遥（美团）、陈胜（美团）、仙云森（美团） | 论文简介：工业级别的搜寻举荐零碎次要遵循召回、粗排、精排、重排的算法体系。为了满足粗排微小的打分规模和严格的时延要求，双塔模型依然被宽泛应用。为了进步模型的成果，一些计划会额定应用精排的打分常识进行蒸馏。但仍有两大挑战亟待解决： 如果不把时延真正作为一个变量放到模型中进行联结优化，成果必然大打折扣；如果把精排的打分常识蒸馏给一个手工设计的粗排构造，模型的体现也必定不是最优。本文应用了神经网络框架搜寻 (Neural Architecture Search) 的办法，开创性地提出了AutoFAS (Automatic Feature and Architecture Selection for Pre-Ranking System) 的算法框架，对立解决了以上两个问题：在给定时延限度和精排打分常识领导的条件下，同时选出最优的粗排特色与构造组合计划，达到了SOTA的成果。本计划曾经在美团主搜场景下全量应用，获得了显著的线上晋升。 论文03：Automatically Discovering User Consumption Intents in Meituan（用户生产用意主动发现）| 下载地址：Automatically Discovering User Consumption Intents | 论文作者：李银峰（清华大学）、高宸（清华大学）、杜小毅（美团）、韦华周（美团）、罗恒亮（美团）、金德鹏（清华大学）、李勇（清华大学） | 论文简介：城市中用户的消费行为往往由特定用意驱动。生产用意作为用户具体消费行为的决策驱动力，对于晋升城市中用户行为建模的可解释性和准确性至关重要，可能广泛应用于举荐零碎和精准化营销等多种业务场景。然而，生产用意难以获取，从用户生产数据和评论中只能开掘到非常无限的用意类型。因而，从生产数据中主动地发现新的未知用意是一项至关重要但极具挑战性的工作，次要面临以下两点关键性挑战：（1）如何对不同类型偏好下的生产用意进行编码；（2）如何仅用大量的已知用意实现对未知用意的发现。 为了应答上述挑战，本文提出了基于超图神经网络和半监督学习的用意发现模型AutoIntent（包含解纠缠的用意编码器和用意发现解码器两局部），实现对美团用户生产用意的主动发现。 具体而言，在解纠缠用意编码器中，本文构建了三组对偶超图来别离捕捉三种不同类型偏好（工夫相干偏好、地点相干偏好和外在偏好）下的高阶关系，并通过超图上的信息流传机制为用户学习解纠缠的用意表征。在用意发现解码器中，本文基于去噪后的用意表征相似性来构建成对样本的用意伪标签，通过半监督学习的形式实现从已知用意到未知用意的常识迁徙，实现用意发现。本文在美团大规模的工业数据集上与多种先进基准算法进行比拟，试验结果表明，提出的AutoIntent办法相比于已有最佳计划能够获得15%以上的显著性能晋升。总的来说，本文为了解并建模城市中的用户消费行为提供了一种新的钻研思路。 ...

美团Hulk调度零碎团队在集群服务质量与资源利用率经营的长期落地实际中，基于业务理论场景，自主设计研发了集群负载主动调控零碎（LAR）以及配套的经营体系，在晋升集群整体资源利用率的同时保障了业务服务质量。本文介绍了LAR的设计理念、根本框架以及外围设计，并联合在线和混部场景利用开展思考，并展现了局部落地成绩。心愿能为从事相干工作的同学带来一些启发或者帮忙。随着云计算时代的到来，大规模资源经营面临着如何在保障服务质量的同时晋升资源利用率（降本增效）。但这两个指标的达成在以后的软硬件技术水平上，是互相矛盾的。本文介绍的LAR（Load Auto-Regulator）零碎，即是摸索这两个矛盾方向间的平衡点，在保证质量的前提下，晋升资源的利用率。 LAR通过资源分级池化，齐备的QoS保障机制，做到精细化的单机资源调度与隔离，在晋升整体资源利用率的同时，可能依据服务的优先级和特色保障服务的品质。LAR的整体设计能够实用于多个场景，包含在线场景和混部场景。目前LAR曾经在美团在线场景中投入生产应用，并获得了较好的成果。 1 背景1.1 云计算时代数据中心资源规模爆炸云计算时代的到来，资源规模化经营成为必然的抉择，大规模数据中心成为当今企业级互联网利用和云计算零碎的要害撑持。为保障日益增长的互联网利用和云计算零碎的计算需要，数据中心须要一直扩容，规模和服务器总量出现快速增长趋势。据权威报告指出，2020年寰球数据中心的服务器总量将达到1800万台，并且正以每年100万台的速度增长。然而，随同着数据中心的急速扩容，资源利用率却始终处于较低状态。统计数据表明，目前寰球数据中心资源利用率仅为10%~20%，如此低的资源利用率意味着数据中心大量的资源节约，进而导致目前数据中心的老本效率极低。 1.2 资源利用率晋升影响微小在国家策略层面，数据中心资源利用率低，造成大量的资源节约，包含物力资源和电能节约，这与可继续倒退的理念是抵触的。2021年7月，工业和信息化部印发《新型数据中心倒退三年行动计划（2021-2023年）》，提出用3年工夫，根本造成布局合理、技术先进、绿色低碳、算力规模与数字经济增长相适应的新型数据中心倒退格局。打算中重点提出建设绿色高效的数据中心指标，将资源利用率晋升作为外围指标。 在公司经营上，晋升资源利用率能够晋升经营效率升高经营老本。谷歌在2019年发表的论文“Borg-the Next Generation”披露其2011年数据中心外围集群（统计1.2万台服务器）的月均匀CPU利用率在30%左右，而到2019年，其数据中心外围集群（统计9.6万台服务器）的月均匀CPU利用率达到了50%左右，8年工夫内晋升了约20%，资源应用效力的大幅晋升，帮忙谷歌节省成本累计数十亿美元。国内各大云服务提供商和互联网公司，目前投入大量人力物力去做晋升数据中心资源利用率的工作，包含阿里巴巴、腾讯、百度、华为等公司均陆续提出了比较完善的资源利用率晋升计划，在外部落地实际并获得了肯定的问题。 晋升资源利用率，降本增效，能给数据中心节俭大量的老本。以数百万核CPU的规模的数据中心为例，整体资源利用率每晋升1个百分点，节省成本（包含洽购老本和经营老本，经营老本次要是机房租金、电费以及运维费用等）每年将达到数千万元。如果思考到集群经营人工成本等，随着资源规模继续扩充，这个收益将持续增长。 继续晋升机器的资源利用率，升高单核老本，晋升集群服务质量，是美团Hulk团队的外围指标之一。针对用户对降本增效的需要，Hulk调度团队在集群资源利用率晋升和服务质量保障方向率先做出相干摸索，提出了一系列的建设计划，并推动落地。本文重点介绍在Hulk整体资源利用率经营体系中的外围零碎集群负载主动平衡管理系统。 2 什么是LAR？LAR全称是集群负载主动平衡管理系统（LAR，Load Auto-Regulator），是美团Hulk团队基于Kubernetes研发的容器编排零碎。LAR在Kubernetes之上，通过提供分级的QoS管理机制和负载管控能力，实现从时空维度对资源的准确调度调配治理。 2.1 指标与挑战晋升资源利用率从大的层面讲，符合国家降本增效、节能减排的绿色低碳倒退策略；从小的层面讲，通过晋升资源利用率，能够为企业每年节俭数亿的老本，并且升高整体零碎复杂度及运维危险。 晋升资源利用率，竟有这么大的收益？可能超乎绝大多数人的意料。依照很多同学的了解，通过非常简单的操作即可达成这个指标——进步单机的服务部署密度。但如此简略的操作，为何寰球数据中心资源利用率仅为10%~20%呢？利用率如此之低，这里最为要害的因素有三个： 部署到同一台物理机的服务在资源应用上存在互相烦扰。服务在流量上存在高下峰，反映在资源应用上也有高下峰。要害外围在线服务的服务质量降落无奈承受。整体来说，从以后硬件架构和操作系统设计上看，尽管在资源分配上，实践上是过程作为独立的调配单位，资源互相隔离，但在理论应用上却是共享的，典型的包含CPU、网卡、I/O总线、Cache以及内核软件资源等。当然，软硬件如此设计自身就是为了晋升整体资源利用的效率，晋升整体工作的解决能力。而晋升资源利用率，从实质上讲，是晋升资源的复用共享，防止资源闲置节约。然而晋升资源共享复用程度，多少都会影响过程运行的效率，且随着复用程度越高，影响越大。 操作系统提供了一系列的资源隔离保障措施，用意升高服务在资源应用时彼此间的烦扰，肯定水平上在保障资源共享复用的同时晋升了资源隔离的能力，但因为底层硬件架构上的限度，这种晋升是无限的。而对于大多数业务的在线服务，服务质量的稳定，比方延时减少、TPS降落等是难以承受的，特地是相似领取、订单类的外围服务。这是造成了以后数据中心整体资源利用率低的根本矛盾：一方面是在线业务对资源竞争导致的服务质量降落是难以容忍的，在线服务质量必须保障，另一方面以后大规模的数据中心在整体上资源利用率程度低，经营老本居高不下，亟需晋升资源利用率，而晋升资源利用率、升高经营老本会间接影响到在线业务服务质量。 一方面，“服务质量”关系着业务的服务体验，间接关系到营收，而另一方面，“晋升资源利用率”，又有着微小的老本空间能够升高，可能减少整体的收益。二者对于企业来说，就像“鱼与熊掌不可兼得”的矛盾。 以后业界，很多企业和钻研单位都在投入大量的资源来钻研如何解决这一矛盾，努力实现整体利益的最大化。 LAR（Load Auto-Regulator），聚焦于“资源利用率晋升”和“服务质量保障”这一矛盾的解决，整个零碎设计的基本出发点，即是在集群资源经营上要实现资源利用率和服务质量的双重保障，解决数据中心经营中的“鱼与熊掌不可兼得”难题和挑战。 2.2 零碎架构晋升资源利用率的实质是晋升资源共享复用程度，而保障服务质量则须要通过资源隔离能力，保障服务的性能稳固。针对上述两个根本点，LAR在Kubernetes上提出两个外围翻新点： 资源池化分级 通过将单机资源划分到不同的资源池，晋升资源在池内的共享复用程度。不同的资源池之间有不同的优先级，并提供不同的资源隔离程度（资源隔离程度越高，资源共享复用程度越低）。资源在不同优先级的资源池之间依据优先级和资源池的资源负载程度流动，优先保障高优资源池服务的资源应用，从而保障其服务质量。动静负载和动态资源映射 资源的调配，实质上是负载空间的调配。假如单机整体CPU利用率小于50%的状况下，经营在其上的服务的服务质量不会有影响，那么这个机器的动态资源其实对应的就是节点50% CPU利用率的负载空间。换个角度看，就是无论如何调度分配资源，只有这个节点的负载不超过50%即可。业务动态的资源申请，依据服务的特色通过调度计算后，服务被放入对应的资源池，而资源池的资源配置则依据池内所有服务的理论负载进行资源配置，并能够实时地依据负载调整资源配置，实现动态资源分配和动静负载的映射治理。上述两个外围翻新点在帮忙晋升资源共享复用的同时，通过负载治理和操作系统提供的单机资源隔离能力，实现分级的服务质量保障的机制，具备很强的通用性，利用场景也比拟宽泛。 联合上述的外围翻新点，LAR的整体设计指标包含： 相较于Kubernetes，提供分级可编辑更粗疏灵便的QoS服务质量保障机制，充沛保障外围服务的资源供应及服务质量。建设负载与资源之间的映射关系，解决Kubernetes基于Request的动态资源调度难以解决的节点负载问题，升高负载动静调度的整体复杂度。提供灵便且具备肯定通用性的单机资源调度能力，实现不同服务间资源的错峰复用。提供更强力的资源隔离能力，保障外围在线业务的服务质量前提下，晋升整体的资源利用率。 在Hulk整体资源利用率经营体系中，LAR基于Kubernetes扩大，负责单个集群的资源管理和调度。相较于Native的Kubernetes，LAR提供分级可编辑更粗疏灵便的QoS服务质量保障机制，充沛保障不同服务的资源供应及服务质量。 而LAR依靠于底层的MTOS提供的资源隔离能力和调度资源Buffer池的物理机弹性伸缩能力，并依据集群经营数据中心和服务画像提供的集群及服务等特色，向上提供精细化的动静资源调整、负载治理以及QoS服务质量保障能力。对立调度零碎在LAR之上，依据LAR提供的动静资源及服务质量数据，实现不同利用场景下，包含在线服务和离线服务的跨集群对立调度。 LAR处于整个资源利用率经营体系中外围要害地位，从性能上来看，整个产品分为五大次要功能模块： 资源分级管理模块资源池配置管理模块服务质量保障模块资源隔离治理模块策略配置模块上述五大功能模块由LAR零碎中3个外围组件来落地实现。LAR是基于原生的Kubernetes进行研发扩大，如下图3的整体架构所示，LAR在Kubernetes的根底性能上，扩大了Scheduler和Kubelet的性能，并新增Recommender和QoSAdaptor两个组件。对Kubernetes原生组件的扩大均采纳插件开发的模式，缩小对原生组件的入侵式批改，从而升高将来运维和降级的老本；对于新增组件，遵循云原生的开发模式，包含代码格调以及运行机制，和Kubernetes放弃对立。 QoSAdaptor QoSAdaptor次要负责服务质量保障，其外围性能是负责单机资源的分池分级管理，提供分级的单机QoS服务质量保障机制。QoSAdaptor分为五个功能模块： 指标采集模块：通过Cadvisor、Node-Exporter等工具采集节点与容器的指标，为资源池治理提供决策依据。资源池治理模块 资源动静配置管理：依据数据指标对资源池实时进行负载计算，并基于负载策略及优先级动静调整资源在各级资源池的配置。QoS服务质量保障：实时监控负载指标，根据资源池的优先级管理策略，在资源竞争的状况下，通过资源抢占、服务降级及驱赶等多种手段分优先级保障服务质量。资源配置管理模块：基于各资源池的配置，通过Cgroup等零碎工具，对不同资源池的资源进行隔离与限度。资源上报模块：周期Patch节点的资源应用状况、资源池负载等信息。 QoSAdaptor以DaemonSet的模式部署在Kubelet节点上，外围性能是实现资源池和容器的资源配置管理。如上图4所示，咱们通过自研的CRI Plugin，以Runtime Hook的模式在容器生命周期治理中引入自定义的QoS保障机制。 因为QoSAdaptor的资源调整与QoS服务质量保障动作，均基于本地指标采集并进行实时的负载和策略计算，不依赖内部监控零碎，缩小了数据传输时延，在保障服务的稳定性同时确保能够秒级响应资源配置调整和服务质量保障动作，保障业务容器的稳定性。 Recommender Recommender次要负责LAR运行中策略及参数的配置更新，依靠内部服务数据，周期性计算并更新LAR相干策略参数，提供对立的集群策略配置入口。 Recommender以集群为维度，每个集群部署一套服务。如上图5所示，Recommender通过集群经营数据中心和服务画像服务的离线数据，周期迭代计算LAR的策略参数。次要功能模块包含： 资源预测：依据离线监控数据及服务画像数据，对节点物理资源将来的应用状况进行提前预估，领导节点的不同资源池的资源配置，并可能触发QoS服务质量保障动作以及集群级别的资源调整，比方节点扩容及服务重调度等。策略计算：依据节点的各级资源池负载数据及集群经营数据中心的集群服务质量数据，周期性迭代更新各级资源池的负载管制及资源配置策略，保障服务质量的同时一直晋升资源利用效率。此外，策略计算会定期更新QoS服务质量保障机制中的相干策略，比方服务降级、驱赶等判断条件。参数配置：提供对立的QoSAdaptor参数配置，实现配置变更散发的性能。Scheduler 在LAR中，通过动态资源和动静负载之间的映射，进而在调度层屏蔽了动静负载变动，在调度层面升高了依据负载进行动静调度的复杂度。 Kubernetes默认依据业务申请的资源规格进行资源的调度调配，并以此设计调度计算框架和算法。但因为业务申请的资源规格是个动态值，且业务方对服务资源的应用通常偏向于放大评估，进而导致整体的资源申请和理论资源应用时存在较大的Gap。咱们进一步思考到资源的应用通常是动静的，也具备规律性的波峰波谷。这两点因素导致在集群的经营上，整体资源分配率靠近满调配的状况下，资源使用率平均水平其实很低。 传统的计划通过节点资源超售来解决资源申请和理论资源应用之间存在的Gap，并引入依据负载的动静调度策略。调整节点资源超售，尽管能在肯定水平上缓解资源申请和应用的Gap问题，但因为Gap在不同的服务间并不相同，加上服务资源应用的波峰波谷散布集中的状况（美团在线业务的典型特色），此办法在整体上过于粗放，会导致节点间的负载散布不平衡，局部节点负载很高，影响服务质量；另一部分节点负载极低，实际上造成资源节约。而依据负载间接进行资源调度，因为负载是动态变化的，在调度算法设计及计算框架实现上会非常复杂，且成果个别。 在LAR中，咱们通过引入资源配置因子（RCF，Resource Configuration Factor，资源池内的资源配比，动态控制池内容器的理论可用资源，数值区间为(0, 1]），依据负载调整理论的资源分配，从而将负载的变动映射为可调度残余资源的变动。如下图6所示，资源负载即为理论的应用资源，是动态变化的，动态资源是指资源总量和业务申请的资源规格，RCF由服务所在的节点的资源池决定，依据服务的历史资源应用数据和服务画像进行计算，并周期进行迭代更新。 2.3 要害能力实现围绕资源利用率晋升和服务质量保障，LAR零碎实现了以下关键技术： 分级池化资源模型：实现资源分池动静治理以及资源池优先级治理。资源动静视图：实现负载和资源配置之间的动静映射，简化负载治理，保障负载的平衡度，保障服务质量。QoS保障机制：依据负载治理的资源配置，在资源竞争的场景下，提供资源抢占以及服务降级驱赶等性能，提供分级服务质量的保障能力。资源智能经营：通过池间资源配置、池内负载配置、历史负载预测等经营策略，自动化调控节点资源分配状况，从而达到晋升资源利用率的目标。2.3.1 分级池化资源模型分级池化资源模型是LAR整个设计的外围，整个模型包含资源分池动静治理和资源池优先级治理两个外围设计。 资源分池动静管理机制 资源分池动静治理引入资源池的概念，通过将节点资源进行分池治理，实现资源池外部资源高度共享，在进步资源复用率的同时，通过池间资源隔离达到池间服务的烦扰隔离。资源池内资源的配置根据服务的负载进行动静调整，并通过资源配置的调整，管制资源池外部的资源负载维系在绝对稳固的范畴内，从而保障服务质量。 资源池优先级管理机制 在资源分池动静管理机制根底上，LAR引入资源池优先级管理机制，通过分级的服务质量保障机制，保障业务的服务质量。在资源池优先级管理机制中，不同的资源池具备不同的优先级，对应不同级别的服务质量保障级别。不同优先级的资源池，在资源配置管理上有3点区别： 资源配置管理策略不同：资源配置管理策略用于决策资源池的资源配置，并通过资源配置管制资源池的资源供应和负载程度。对于优先级高的资源池，资源配置富余，资源池内的负载维系在平安稳固的程度，并通过资源池的资源隔离能力，实现对资源池外部服务资源应用的优先保障，从而保障更高的服务质量。资源隔离保障能力不同：高级别的资源池依靠零碎内核等提供的资源隔离能力，提供更高级别的资源池资源隔离级别，通过实现资源的独占或优先抢占应用，达到高优资源池外部服务在零碎过程级别资源调度时的优先保障。比方，对于高优资源池，能够进行独立的CPU互斥绑定、I/O隔离等，保障其外部服务不受池外服务的影响。优先级资源抢占机制：资源池的资源配置能够动静调整，在高级别资源池配置资源有余，池内负载过高时，QoS服务质量保障机制会依据资源池优先级，高优资源池能够抢占低优资源池已配置的资源，通过就义低优资源池服务质量程度，优先保障高级别资源池的资源供应，保障高优服务的服务质量。在LAR的分级池化的资源模型中，节点闲暇资源，搁置到优先级最低的资源池内，其它资源池的资源配置由服务的资源申请规格、资源池资源配置管理策略以及资源池资源负载决定。在资源池资源配置管理策略中，蕴含资源池指标负载和资源池RCF两局部内容。资源池具体的配置资源由服务申请的资源和资源池实时负载决定。当实时负载升高时，LAR会调整对应资源池的RCF，减少资源池的资源配置，升高资源池负载；当资源池负载升高时，LAR会通过调整RCF升高资源池的资源配置，开释冗余资源。 ...

粗排是工业界搜广推零碎的重要模块。美团搜寻排序团队在优化粗排成果的摸索和实际中，基于业务理论场景，从精排联动和成果性能联结优化两方面优化粗排，晋升了粗排的成果。本文介绍了美团搜寻粗排的迭代路线、基于常识蒸馏和主动神经网络抉择的粗排优化工作，心愿为从事相干工作的同学带来一些启发或者帮忙。1. 前言家喻户晓，在搜寻、举荐、广告等大规模工业界应用领域，为了均衡性能和成果，排序零碎广泛采纳级联架构[1,2]，如下图 1 所示。以美团搜寻排序零碎为例，整个排序分为粗排、精排、重排和混排层；粗排位于召回和精排之间，须要从千级别候选 item 汇合中筛选出百级别 item 汇合送给精排层。 从美团搜寻排序全链路视角扫视粗排模块，目前粗排层优化存在如下几个挑战点： 样本抉择偏差：级联排序零碎下，粗排离最初的后果展现环节较远，导致粗排模型离线训练样本空间与待预测的样本空间存在较大的差别，存在重大的样本抉择偏差。粗排精排联动：粗排处于召回和精排之间，粗排须要更多获取和利用后续链路的信息来晋升成果。性能束缚：线上粗排预测的候选集远远高于精排模型，然而理论整个搜寻系统对性能有严格的要求，导致粗排须要重点关注预测性能。本文将围绕上述挑战点来分享美团搜寻粗排层优化的相干摸索与实际，其中样本抉择偏差问题咱们放在精排联动问题中一起解决。本文次要分成三个局部：第一局部会简略介绍美团搜寻排序粗排层的演进路线；第二局部介绍粗排优化的相干摸索与实际，其中第一个工作是采纳常识蒸馏和比照学习使精排和粗排联动来优化粗排成果，第二个工作是思考粗排性能和成果 trade-off 的粗排优化，相干工作均已全量上线，且效果显著；最初是总结与瞻望局部，心愿这些内容对大家有所帮忙和启发。 2. 粗排练进路线美团搜寻的粗排技术演进分为以下几个阶段： 2016 年：基于相关性、品质度、转化率等信息进行线性加权，这种办法简略然而特色的表达能力较弱，权重人工确定，排序成果存在很大的晋升空间。2017 年：采纳基于机器学习的简略 LR 模型进行 Pointwise 预估排序。2018 年：采纳基于向量内积的双塔模型，两侧别离输出查问词、用户以及上下文特色和商户特色，通过深度网络计算后，别离产出用户&查问词向量和商户向量，再通过内积计算失去预估分数进行排序。该办法能够提前把商户向量计算保留好，所以在线预测快，然而两侧信息的穿插能力无限。2019 年：为了解决双塔模型无奈很好地建模穿插特色的问题，将双塔模型的输入作为特色与其余穿插特色通过 GBDT 树模型进行交融。2020 年至今：因为算力的晋升，开始摸索 NN 端到端粗排模型并且继续迭代 NN 模型。现阶段，工业界粗排模型罕用的有双塔模型，比方腾讯[3]和爱奇艺[4]；交互式 NN 模型，比方阿里巴巴[1,2]。下文次要介绍美团搜寻在粗排降级为 NN 模型过程中的相干优化工作，次要包含粗排成果优化、成果&性能联结优化两个局部。 3. 粗排优化实际随着大量的成果优化工作[5,6]在美团搜寻精排 NN 模型落地，咱们也开始摸索粗排 NN 模型的优化。思考到粗排有严格的性能束缚，间接将精排优化的工作复用到粗排是不实用的。上面会介绍对于将精排的排序能力迁徙到粗排的精排联动成果优化工作，以及基于神经网络构造主动搜寻的成果和性能 trade-off 优化工作。 3.1 精排联动成果优化粗排模型受限于打分性能束缚，这会导致模型构造相比精排模型更加简略，特色数量也比精排少很多，因而排序成果要差于精排。为了补救粗排模型构造简略、特色较少带来的成果损失，咱们尝试常识蒸馏办法[7]来联动精排对粗排进行优化。 常识蒸馏是目前业界简化模型构造并最小化成果损失的广泛办法，它采取一种 Teacher-Student 范式：结构复杂、学习能力强的模型作为 Teacher 模型，构造较为简单的模型作为 Student 模型，通过 Teacher 模型来辅助 Student 模型训练，从而将 Teacher 模型的“常识”传递给 Student 模型，实现 Student 模型的成果晋升。精排蒸馏粗排的示意图如下图 2 所示，蒸馏计划分为以下三种：精排后果蒸馏、精排预测分数蒸馏、特色表征蒸馏。上面会别离介绍这些蒸馏计划在美团搜寻粗排中的实践经验。 3.1.1 精排后果列表蒸馏粗排作为精排的前置模块，它的指标是初步筛选出品质比拟好的候选汇合进入精排，从训练样本选取来看，除了惯例的用户产生行为（点击、下单、领取）的 item 作为正样本，曝光未产生行为的 item 作为负样本外，还能够引入一些通过精排模型排序后果结构的正负样本，这样既能肯定水平缓解粗排模型的样本抉择偏置，也能将精排的排序能力迁徙到粗排。上面会介绍在美团搜寻场景下，应用精排排序后果蒸馏粗排模型的实践经验。 ...

通过近3年的建设打磨，美团流水线引擎实现了服务端的基建对立，每日撑持近十万次的流水线执行量，零碎成功率放弃在99.99%以上。本文次要介绍在自研引擎建设层面遇到的挑战以及解决方案。1. 背景继续交付这个概念最早在2006年麻利大会上被提出，通过多年的倒退，目前已成为很多技术团队晋升研发效力的必经之路。通过建设部署流水线，买通从代码开发到性能交付的整个环节，以自动化的形式实现构建、测试、集成、公布等一系列行为，最终实现向用户继续高效地交付价值。 流水线引擎作为撑持部署流水线的底座，它的好坏间接影响着部署流水线建设的程度。业界通常的做法是通过Jenkins、GitlabCI等开源工具（或私有云产品）进行搭建，这是一条能帮忙业务疾速落地继续交付的路线，美团晚期也是采纳搭建Jenkins的形式来疾速撑持业务。 但随着越来越多业务开始做继续交付的建设，这种“短平快”形式的弊病逐步浮现。比方，工具建设没有对立的规范，各业务都须要去理解整个工具链的细节，建设老本高、程度参差不齐，很少有业务能搭建残缺的部署流水线。同时，业务每天的构建量都在快速增长，逐步超过Jenkins等开源工具所能接受的极限，在交付高峰期工作重大排队、服务不可用景象频出，重大影响着业务交付的顺畅度。 美团在流水线引擎的建设层面大略经验了几个阶段。在2019年以前，次要围绕Jenkins进行优化，2019年开始正式立项打造自研的流水线引擎，大抵的历程如下： 第一阶段（2014-2015）：搭建Jenkins对立集群，解决业务接入的通用问题（如单点登录、代码仓库集成、音讯告诉、执行机的动静扩缩等），升高业务的建设老本。第二阶段（2016-2018）：拆分多个Jenkins集群，解决业务增长导致单集群性能瓶颈。最多时有十几个集群，这些集群通常是按业务线维度划分，并由业务自行建设。但随着工夫的推移，集群的拆分治理难度越来越大，Jenkins安全隐患频出，对平台方造成了很大的运维累赘。第三阶段（2019-至今）：为了彻底解决引擎单机瓶颈和工具反复建设问题，咱们开始自研分布式流水线引擎（美团外部项目名称为Pipeline），并逐渐收敛各业务依赖的底层基建。通过3年左右的建设打磨，流水线引擎实现了服务端的基建对立，涵盖到店、到家、公众点评、美团优选、美团平台、主动配送车、根底研发平台等简直所有的业务，反对Java、C++、NodeJS、Golang等多种语言。在性能和稳定性方面，引擎每日撑持近十万次的流水线执行量（作业调度峰值每小时达上万次），零碎成功率放弃在99.99%以上（排除业务代码本身起因和第三方工具的问题）。 上面咱们次要介绍下咱们在自研引擎建设上遇到的挑战以及对应的解决方案。 2. 问题及思路2.1 业务介绍1）什么是流水线 咱们能够把流水线的执行看作是对代码一步步加工，最终交付到线上的过程。依据业务定义的程序关系，顺次执行相应的加工或品质校验行为（如构建、代码扫描、接口测试、部署工具等），整个执行过程相似一个有向无环图。 2）基本概念 组件：出于代码复用和业务共享的思考，咱们将某一工具的操作行为封装成一个组件，示意对于一项具体的加工或校验行为。通过组件形式，业务能够便捷地应用已集成的品质工具（如动态代码扫描、安全漏洞剖析等），缩小在同一工具上的反复开发成本；对于不满足需要的场景，业务能够自定义一个新的组件。组件作业：示意组件的一次运行实例。资源：为组件作业调配的一个可执行环境。流水线编排：示意流水线中不同组件执行的先后顺序。引擎：负责调度所有的组件作业，为其调配相应的执行资源，保障流水线执行按预期实现。2.2 次要挑战1）调度效率瓶颈 对调度工夫绝对敏感，流水线大部分是短时作业（作业继续数十秒到分钟不等），如果调度工夫过长，业务能显著感知到流水线执行变慢了。咱们须要保障作业调度工夫在一个可控的范畴内，避免出现调度瓶颈。 从业务场景思考，调度逻辑存在肯定的业务复杂性（如组件串并行判断、优先级抢占、降级跳过、复用上一次后果等），不仅仅是作业与资源的匹配计算，作业调度耗时存在肯定的业务开销。引擎撑持公司每天近十万次的执行量，峰值量状况下，并发调度的作业量大，常见的开源工具（Jenkins/GitLab CI/Tekton等）都是采纳单体调度模式，作业是串行调度的，容易呈现调度瓶颈。2）资源分配问题 对于作业系统来说，作业数通常都是大于资源数的（实在部署状况，资源不是有限的），作业积压是零碎设计时必须思考的问题。如何在无限的资源下，尽可能进步作业的吞吐能力，同时升高在资源有余状况时造成对外围业务场景的影响。 如果只依附动静扩容，容易呈现资源有余时无奈扩容、作业排队期待的状况。特地是对于依赖流水线做研发卡控的业务，这会间接阻塞业务的上线流程。出于执行耗时的思考，大部分资源采纳预部署的形式，缩短资源申请和利用启动的筹备工夫。而对于预部署的资源，如何进行无效划分，既保证每类资源都有肯定配额，同时也避免出现局部资源利用率过低，影响作业整体的吞吐能力。不是所有工具的执行资源都由引擎治理（如公布零碎，部署工作的资源管理是独自的），在作业的资源分配上，还须要思考不同的资源管理形式。3）工具差异化问题 公司内不同业务的差异化大，波及的质效类工具泛滥，如何设计一个适合的插件化架构，满足不同工具的接入需要。 不同工具实现模式差异化大，有些工具有独立的平台，能够通过接口方式进行集成，有些仅仅是一段代码片段，还须要提供相应的运行环境。面对不同的接入状态，引擎如何屏蔽不同工具带来的差别，使业务在编排流水线时不必关注到工具的实现细节。随着业务场景的不断丰富，组件执行还会波及人工交互（审批场景）、反对重试、异步解决、故障复原等能力，这些能力的扩大如何尽可能减少对系统的冲击，升高实现的复杂度。2.3 解决思路1）拆分调度决策与资源分配，解决调度效率瓶颈 从上述剖析，一个作业的理论调度耗时 = 单个作业的调度耗时 * 待调度的作业数。因为单个作业的调度耗时会受具体的业务逻辑影响，不确定性大，优化空间无限。而串行调度问题绝对明确，在作业调度工夫和数量不可控的状况下，是一个适合的优化方向。 对于串行调度，业界常见的做法是依照业务线维度拆分多个集群，摊派总的调度压力。但这种形式存在的问题是资源分配不具备灵活性，很容易呈现资源的调配不均，在整体资源有余时，无奈从全局上思考高优作业的资源分配。并且，多集群治理（新增集群/拆分现有集群）也是不小的运维累赘。 进一步剖析，串行调度次要是为了防止资源竞争问题，取得绝对最优的资源。这对于流水线场景（作业量大于资源量且都是短时作业），资源最优解不是强诉求。并且，资源量的并发度绝对作业量更可控，依据作业执行快慢不同，咱们通过被动拉取作业的形式，管制拉取的数量和频率，从而无效升高了资源竞争的状况。 最终，咱们在设计上采取了调度决策与资源分配拆散的模式： 调度决策：负责计算出能够调度的作业，提交决策，期待适合的资源来执行。该模块具体程度扩大，分担调度决策的压力。资源分配：负责保护作业与资源的关系，通过被动拉取作业的形式，资源能够向任意的实例拉取作业，勾销了原先串行分配资源的单点限度。在这种模式下，作业调度、资源分配都具备程度扩大能力，领有更高的性能和零碎可用性。也利于作业调度的逻辑可能独立演进，便于开发、测试以及灰度上线。 2）引入资源池管理模式，实现资源的灵便调配 思考到不是所有资源都由引擎治理，咱们引入资源池的概念来屏蔽不同资源形式的差别，每个资源池代表一类资源的汇合，不同资源池的资源管理形式能够是多样化的。通过该形式，咱们将资源分配的问题简化为作业与资源池的匹配问题，依据作业的理论状况，正当设置不同的资源池大小，并配合监控伎俩对资源池进行动静调整。 在具体措施上，咱们抉择“标签”的形式建设作业与资源池的匹配关系，通过从作业与资源两个维度来满足上述条件。 在作业端，作业基于标签属性拆分到不同的作业队列，并引入优先级概念，保障每个队列中作业按优先级高下被拉取到，防止在积压时，高优作业排在前面无奈被及时处理，阻塞业务研发流程。在资源端，联合资源的理论场景，提供三种不同的资源池治理形式，以解决不同资源类型的配额和利用率问题。 预置的公共资源，这部分资源会提前在资源池上扩容进去，次要应答业务高频应用的且对工夫敏感的组件作业。在资源配额和利用率上，依据资源池的历史状况和实时监控，动静调整不同资源池的大小。按需应用的资源，次要针对公共资源环境不满足的状况，业务须要自定义资源环境，思考到这部分作业的体量不大，间接采纳实时扩容的形式，相比预置资源的形式，能够取得更好的资源利用率。内部平台的资源，这些资源的治理平台方比咱们更有教训，平台方通过管制向引擎拉取作业的频率和数量，自行治理作业的吞吐状况。3）引入组件的分层设计，满足工具差异化需要 为了放弃工具接入的自由度，引擎提供了作业维度最根本的操作接口（拉取作业、查问作业状态、上报作业后果），不同工具能够依据作业接口模式实现定制化的组件开发。 组件开发次要波及①实现业务逻辑和②确定交付形式两局部工作，而与引擎的零碎交互绝对是规范的。咱们依据组件执行过程进行分层设计，拆分出业务逻辑、零碎交互与执行资源三层。在向引擎屏蔽工具实现细节的同时，能够更好地满足多样化的接入场景。 零碎交互层，该层绝对组件开发者是通明的，依据引擎提供的接口制订对立的流程交互规范，以向引擎屏蔽不同组件的实现差别。执行资源层，次要解决工具运行形式的差异化，通过反对多种组件交付模式（如镜像、插件装置、独立服务）满足工具与引擎的不同集成形式。业务逻辑层，针对业务不同的开发场景，采纳多种适配器的抉择，来满足业务不同的开发诉求。3. 整体架构 触发器：作为流水线的触发入口，治理多种触发源及触发规定（Pull Request、Git Push、API 触发、定时触发等）。工作核心：治理流水线构建过程中的运行实例，提供流水线运行、停止、重试、组件作业后果上报等操作。决策者：对所有期待调度的作业进行决策，并将决策后果同步给工作核心，由工作核心进行作业状态的变更。Worker：负责向工作核心拉取可执行的作业，并为作业调配具体的执行资源。组件SDK：作为执行组件业务逻辑的壳，负责真正调起组件，实现组件初始化与状态同步的零碎交互。4. 外围设计点4.1 作业调度设计1）调度过程 上面，咱们以一个简略的流水线调度示例（源码检出 - [并行：代码扫描，构建] - 部署），来介绍调度设计中各模块的合作过程。 大抵逻辑如下： 当触发流水线构建后，零碎会在工作核心创立该编排所要执行的所有组件作业。并且将作业状态的变动以事件形式告诉决策者进行决策。决策者接管决策事件，依据决策算法计算出可被调度的作业，向工作核心提交作业的状态变更申请。工作核心接管决策申请，实现作业状态变更（作业状态变更为已决策），同时退出相应的期待队列。Worker 通过长轮询形式拉取到和本人匹配的期待队列的作业，开始执行作业，执行实现后将后果上报给工作核心。工作核心依据Worker上报的作业执行后果变更作业状态，同时向决策者发动下一轮决策。以此重复，直至流水线下所有作业都已执行实现或呈现作业失败的状况，对流水线进行最终决策，完结本次执行。整个过程中，工作核心作为一个分布式存储服务，对立保护流水线和作业的状态信息，以API形式与其余模块进行交互。而决策者和Worker通过监听作业状态的变动执行相应的逻辑。 2）作业状态流转 上面是一个作业残缺的状态机，咱们通过作业决策、拉取、ACK以及后果上报一系列事件，最终实现作业从初始状态向完结状态的流转过程。 状态机在接管某种状态转移的事件（Event）后，将以后状态转移至下一个状态（Transition），并执行相应的转移动作（Action）。 在理论场景中，因为调度过程波及链路长、各环节稳定性无奈齐全保障，容易产生因异常情况导致状态不流转的状况。为此，在设计上利用数据库保障状态变更的正确性，同时为非完结状态作业设立相应的弥补机制，确保任一环节异样后作业能够复原正确流转。 咱们重点从作业决策和作业拉取这两个要害过程来看状态流转过程可能呈现的问题，以及在设计上是如何解决的。 作业决策过程：工作核心接管调度作业的决策，将可调度的作业从unstart变为pending状态，同时将作业退出期待队列，期待被拉取。 未收到决策事件：因为决策者服务本身的问题或网络起因，导致决策事件的申请失败，作业长时间处于未调度状态。 解决方案：引入定时监测的机制，对于无过程状态作业且处于未完结状态的流水线进行从新决策，防止决策服务短时间异样导致决策失败。反复决策：因为网络提早、音讯重试景象可能呈现多个决策者同时决策同一个作业，产生作业转移的并发问题。 解决方案：减少pending的状态示意作业已被决策到，并通过数据库乐观锁机制进行状态变更，保障仅有一个决策会真正失效。状态变更过程异样：因为存在异构数据库，状态变更和退出队列可能存在数据不统一，导致作业无奈被失常调度。 解决方案：采纳最终一致性的计划，容许调度的短暂提早。采纳先变更数据库，再退出队列的操作程序。利用弥补机制，定时监测队列队首的作业信息，若pending状态下的作业有早于队首作业的，进行从新入队操作。作业拉取过程：工作核心依据Worker拉取作业的事件申请，从期待队列中获取待调度作业，将作业的状态从pending变更为scheduled，并返回给Worker。 作业失落问题：这里存在两种状况，①作业从队列中移除，但在状态将要变更时异样了；②作业从队列中移除，也正确变更了状态。但因为poll申请连贯超时，未失常返回给Worker。 ...

在外卖广告CTR场景下，深度学习模型正在从简略DNN小模型过渡到千亿参数简单模型。基于该背景，本文将重点针对大规模深度模型在全链路带来的挑战，从在线时延、离线效率两个方面开展，论述外卖广告在大规模深度模型上的工程实践经验，心愿能为读者提供思路上的借鉴。导语随着美团外卖业务一直倒退，外卖广告引擎团队在多个畛域进行了工程上的摸索和实际，也获得了一些成绩。咱们将以连载的形式进行分享，内容次要包含：① 业务平台化的实际；② 大规模深度学习模型工程实际；③ 近线计算的摸索与实际；④ 大规模索引构建与在线检索服务实际；⑤ 机制工程平台化实际。 不久前，咱们已发表过业务平台化的实际（详情请参阅《美团外卖广告平台化的摸索与实际》一文）。本文为连载文章的第二篇，咱们将重点针对大规模深度模型在全链路层面带来的挑战，从在线时延、离线效率两个方面进行开展，论述广告在大规模深度模型上的工程实际，心愿能为大家带来一些帮忙或者启发。 1 背景在搜寻、举荐、广告（下简称搜推广）等互联网外围业务场景下，对用户行为进行数据挖掘及趣味建模，为用户提供优质的服务，曾经成为改善用户体验、晋升营收的要害因素。近几年，针对搜推广业务，深度学习模型凭借数据红利和硬件技术红利，在业界得以宽泛落地，同时在CTR场景，业界逐渐从简略DNN小模型过渡到数万亿参数的Embedding大模型甚至超大模型。 外卖广告业务线次要经验了“LR浅层模型（树模型）” -> “深度学习模型” -> “大规模深度学习模型”的演化过程。整个演变趋势从以人工特色为主的简略模型，逐渐向以数据为外围的简单深度学习模型进行过渡。而大模型的应用，大幅提高了模型的表达能力，更精准地实现了供需侧的匹配，为后续业务倒退提供了更多的可能性。但随着模型、数据规模的一直变大，咱们发现效率跟它们存在如下的关系： 依据上图所示，在数据规模、模型规模增长的状况下，所对应的“时长”变得会越来越长。这个“时长”对应到离线层面，体现在效率上；对应到在线层面，就体现在Latency上。而咱们的工作就是围绕这个“时长”的优化来发展。 2 剖析相比一般小模型，大模型的外围问题在于：随着数据量、模型规模减少数十倍甚至百倍，整体链路上的存储、通信、计算等都将面临新的挑战，进而影响算法离线的迭代效率。如何冲破在线时延束缚等一系列问题？咱们先从全链路进行剖析，如下所示： “时长”变长，次要会体现在以下几个方面： 在线时延：特色层面，在线申请不变的状况下，特色量的减少，带来的IO、特色计算耗时减少等问题尤为突出，须要在特色算子解析编译、特色抽取外部任务调度、网络I/O传等方面重塑。在模型层面，模型历经百M/G到几百G的变动，在存储上带来了2个数量级的回升。此外，单模型的计算量也呈现了数量级的上涨（FLOPs从百万到当初千万），单纯的靠CPU，解决不了微小算力的需要，建设CPU+GPU+Hierarchical Cache推理架构来撑持大规模深度学习推理势在必行。离线效率：随着样本、特色的数倍减少，样本构建，模型训练的工夫会被大大拉长，甚至会变得不可承受。如何在无限的资源下，解决海量样本构建、模型训练是零碎的首要问题。在数据层面，业界个别从两个层面去解决，一方面一直优化批处理过程中掣肘的点，另一方面把数据“化批为流”，由集中式转到摊派式，极大晋升数据的就绪工夫。在训练层面，通过硬件GPU并联合架构层面的优化，来达到减速目标。其次，算法翻新往往都是通过人来驱动，新数据如何疾速匹配模型，新模型如何疾速被其余业务利用，如果说将N集体放在N条业务线上独立地做同一个优化，演变成一个人在一个业务线的优化，同时播送适配到N个业务线，将会有N-1个人力释放出来做新的翻新，这将会极大地缩短翻新的周期，尤其是在整个模型规模变大后，不可避免地会减少人工迭代的老本，实现从“人找特色/模型” 到“特色/模型找人”的深度转换，缩小“反复翻新”，从而达到模型、数据智能化的匹配。Pipeline其余问题：机器学习Pipeline并不是在大规模深度学习模型链路里才有，但随着大模型的铺开，将会有新的挑战，比方：①零碎流程如何反对全量、增量上线部署；②模型的回滚时长，把事件做正确的时长，以及事件做错后的复原时长。简而言之，会在开发、测试、部署、监测、回滚等方面产生新的诉求。本文重点从在线时延（模型推理、特色服务）、离线效率（样本构建、数据筹备）等两个方面来开展，逐渐论述广告在大规模深度模型上的工程实际。如何去优化“时长”等相干问题，咱们会在后续篇章介进行分享，敬请期待。 3 模型推理在模型推理层面，外卖广告历经了三个版本，从1.0时代，反对小众规模的DNN模型为代表，到2.0时代，高效、低代码反对多业务迭代，再到现在的3.0时代，逐渐面向深度学习DNN算力以及大规模存储的需要。次要演进趋势如下图所示： 面向大模型推理场景，3.0架构解决的两个外围问题是：“存储问题”和“性能问题”。当然，面向N个百G+模型如何迭代，运算量数十倍减少时在线稳定性如何保障，Pipeline如何加固等等，也是工程面临的挑战。上面咱们将重点介绍模型推理3.0架构是如何通过“分布式”来解决大模型存储问题，以及如何通过CPU/GPU减速来解决性能、吞吐问题。 3.1 分布式大模型的参数次要分为两局部：Sparse参数和Dense参数。 Sparse参数：参数量级很大，个别在亿级别，甚至十亿/百亿级别，这会导致存储空间占用较大，通常在百G级别，甚至T级别。其特点：① 单机加载艰难：在单机模式下，Sparse参数需全副加载到机器内存中，导致内存重大吃紧，影响稳定性和迭代效率；② 读取稠密：每次推理计算，只需读取局部参数，比方User全量参数在2亿级别，但每次推理申请只需读取1个User参数。Dense参数：参数规模不大，模型全连贯个别在2~3层，参数量级在百万/千万级别。特点：① 单机可加载：Dense参数占用在几十兆左右，单机内存可失常加载，比方：输出层为2000，全连贯层为[1024, 512, 256]，总参数为：2000 1024 + 1024 512 + 512 * 256 + 256 = 2703616，共270w个参数，内存占用在百兆内；②全量读取：每次推理计算，须要读取全量参数。因而，解决大模型参数规模增长的要害是将Sparse参数由单机存储革新为分布式存储，革新的形式包含两局部：① 模型网络结构转换；② Sparse参数导出。 3.1.1 模型网络结构转换业界对于分布式参数的获取形式大抵分为两种：内部服务提前获取参数并传给预估服务；预估服务外部通过革新TF（TensorFlow）算子来从分布式存储获取参数。为了缩小架构革新老本和升高对现有模型构造的侵入性，咱们抉择通过革新TF算子的形式来获取分布式参数。 失常状况下，TF模型会应用原生算子进行Sparse参数的读取，其中外围算子是GatherV2算子，算子的输出次要有两局部：1）须要查问的ID列表；2）存储Sparse参数的Embedding表。算子的作用是从Embedding表中读取ID列表索引对应的Embedding数据并返回，实质上是一个Hash查问的过程。其中，Embedding表存储的Sparse参数，其在单机模型中全副存储在单机内存中。 革新TF算子实质上是对模型网络结构的革新，革新的外围点次要包含两局部：① 网络图重构；② 自定义分布式算子。 1. 网络图重构：革新模型网络结构，将原生TF算子替换为自定义分布式算子，同时进行原生Embedding表的固化。 分布式算子替换：遍历模型网络，将须要替换的GatherV2算子替换为自定义分布式算子MtGatherV2，同时批改上下游节点的Input/Output。原生Embedding表固化：原生Embedding表固化为占位符，既能保留模型网络结构残缺，又能防止Sparse参数对单机内存的占用。 2. 自定义分布式算子：革新依据ID列表查问Embedding流程，从本地Embedding表中查问，革新为从分布式KV中查问。 申请查问：将输出ID进行去重以升高查问量，并通过分片的形式并发查问二级缓存（本地Cache + 远端KV）获取Embedding向量。模型治理：保护对模型Embedding Meta注册、卸载流程，以及对Cache的创立、销毁性能。模型部署：触发模型资源信息的加载，以及对Embedding数据并行导入KV的流程。 3.1.2 Sparse参数导出分片并行导出：解析模型的Checkpoint文件，获取Embedding表对应的Part信息，并依据Part进行划分，将每个Part文件通过多个Worker节点并行导出到HDFS上。导入KV：提前预调配多个Bucket，Bucket会存储模型版本等信息，便于在线路由查问。同时模型的Embedding数据也会存储到Bucket中，按分片并行形式导入到KV中。整体流程如下图所示，咱们通过离线分布式模型构造转换、近线数据一致性保障、在线热点数据缓存等伎俩，保障了百G大模型的失常迭代需要。 能够看到，分布式借助的存储是内部KV能力，后续会替换为更加高效、灵便、易治理的Embedding Service。 ...

搜寻相关性用于掂量Query和Doc的相干水平，是搜索引擎的重要环节，本文次要讲述公众点评搜寻团队在相关性计算上的技术摸索和实际，通过多相似矩阵模型构造、多阶段训练等办法晋升预训练模型在相关性问题上的成果，同时解决基于交互的模型在线预测的性能问题，心愿为从事相干工作的同学可能带来一些启发或者帮忙。1. 背景点评搜寻是公众点评App的外围入口之一，用户通过搜寻来满足不同场景下对生存服务类商户的找店需要。搜寻的长期指标是继续优化搜寻体验，晋升用户的搜寻满意度，这须要咱们了解用户搜寻用意，精确掂量搜索词与商户之间的相干水平，尽可能展现相干商户并将更相干的商户排序靠前。因而，搜索词与商户的相关性计算是点评搜寻的重要环节。 公众点评搜寻场景面临的相关性问题简单多样，用户的搜索词比拟多样，例如搜寻商户名、菜品、地址、类目以及它们之间的各种简单组合，同时商户也有多种类型的信息，包含商户名、地址信息、团单信息、菜品信息以及其余各种设施和标签信息等，导致Query与商户的匹配模式异样简单，容易滋生出各种各样的相关性问题。具体来说，能够分为如下几种类型： 文本误匹配：在搜寻时，为保障更多商户被检索和曝光，Query可能会被拆分成更细粒度的词进行检索，因而会带来Query谬误匹配到商户不同字段的问题，如图1(a)所示的用户搜“生蚝火锅”应该想找汤底中蕴含生蚝的火锅，而“生蚝”和“火锅”别离匹配到商户的两个不同菜品。语义偏移：Query与商户字面匹配，但商户与Query的次要用意在语义上不相干，如“奶茶”-“黑糖珍珠奶茶包”，如图1(b)所示。类目偏移：Query与商户字面匹配且语义相干，但主营类目与用户需要不符，例如用户搜寻“水果”时一家提供“果盘”的KTV商户显著与用户的需要不相干。 基于字面匹配的相关性办法无奈有效应对上述问题，为了解决搜寻列表中的各类不合乎用户用意的不相干问题，须要更精确地刻画搜索词与商户的深度语义相关性。本文在基于美团海量业务语料训练的MT-BERT预训练模型的根底上，在公众点评搜寻场景下优化Query与商户（POI，对应通用搜索引擎中的Doc）的深度语义相关性模型，并将Query与POI的相关性信息利用在搜寻链路各环节。 本文将从搜寻相关性现有技术综述、点评搜寻相关性计算计划、利用实战、总结与瞻望四个方面对点评搜寻相关性技术进行介绍。其中点评搜寻相关性计算章节将介绍咱们如何解决商户输出信息结构、使模型适配点评搜寻相关性计算及模型上线的性能优化等三项次要挑战，利用实战章节将介绍点评搜寻相关性模型的离线及线上成果。 2. 搜寻相关性现有技术搜寻相关性旨在计算Query和返回Doc之间的相干水平，也就是判断Doc中的内容是否满足用户Query的需要，对应NLP中的语义匹配工作（Semantic Matching）。在公众点评的搜寻场景下，搜寻相关性就是计算用户Query和商户POI之间的相干水平。 文本匹配办法：晚期的文本匹配工作仅思考了Query与Doc的字面匹配水平，通过TF-IDF、BM25等基于Term的匹配特色来计算相关性。字面匹配相关性线上计算效率较高，但基于Term的关键词匹配泛化性能较差，短少语义和词序信息，且无奈解决一词多义或者多词一义的问题，因而漏匹配和误匹配景象重大。 传统语义匹配模型：为补救字面匹配的缺点，语义匹配模型被提出以更好地了解Query与Doc的语义相关性。传统的语义匹配模型次要包含基于隐式空间的匹配：将Query和Doc都映射到同一个空间的向量，再用向量间隔或类似度作为匹配分，如Partial Least Square（PLS）[1]；以及基于翻译模型的匹配：将Doc映射到Query空间后进行匹配或计算Doc翻译成Query的概率[2]。 随着深度学习和预训练模型的倒退，深度语义匹配模型也被业界广泛应用。深度语义匹配模型从实现办法上分为基于示意（Representation-based）的办法及基于交互（Interaction-based）的办法。预训练模型作为自然语言解决畛域的无效办法，也被宽泛应用在语义匹配工作中。 基于示意的深度语义匹配模型：基于示意的办法别离学习Query及Doc的语义向量示意，再基于两个向量计算类似度。微软的DSSM模型[3]提出了经典的双塔构造的文本匹配模型，即别离应用互相独立的两个网络构建Query和Doc的向量示意，用余弦类似度掂量两个向量的相干水平。微软Bing搜寻的NRM[4]针对Doc表征问题，除了根底的Doc题目和内容，还思考了其余多源信息（每类信息被称为一个域Field），如外链、用户点击过的Query等，思考一个Doc中有多个Field，每个Field内又有多个实例（Instance），每个Instance对应一个文本，如一个Query词。模型首先学习Instance向量，将所有Instance的示意向量聚合起来就失去一个Field的示意向量，将多个Field的示意向量聚合起来失去最终Doc的向量。SentenceBERT[5]将预训练模型BERT引入到双塔的Query和Doc的编码层，采纳不同的Pooling形式获取双塔的句向量，通过点乘、拼接等形式对Query和Doc进行交互。 公众点评的搜寻相关性晚期模型就借鉴了NRM和SentenceBERT的思维，采纳了图2(a)所示的基于示意的多域相关性模型构造，基于示意的办法能够将POI的向量提前计算并存入缓存，线上只需计算Query向量与POI向量的交互局部，因而在线上应用时计算速度较快。 基于交互的深度语义匹配模型：基于交互的办法不间接学习Query和Doc的语义示意向量，而是在底层输出阶段就让Query和Doc进行交互，建设一些根底的匹配信号，再将根底匹配信号交融成一个匹配分。ESIM[6]是预训练模型引入之前被业界宽泛应用的经典模型，首先对Query和Doc进行编码失去初始向量，再用Attention机制进行交互加权后与初始向量进行拼接，最终分类失去相关性得分。 引入预训练模型BERT进行交互计算时，通常将Query和Doc拼接作为BERT句间关系工作的输出，通过MLP网络失去最终的相关性得分[7]，如图2(b)所示。CEDR[8]在BERT句间关系工作取得Query和Doc向量之后，对Query和Doc向量进行拆分，进一步计算Query与Doc的余弦相似矩阵。美团搜寻团队[9]将基于交互的办法引入美团搜寻相关性模型中，引入商户品类信息进行预训练，并引入实体辨认工作进行多任务学习。美团到店搜寻广告团队[10]提出了将基于交互的模型蒸馏到基于示意的模型上的办法，实现双塔模型的虚构交互，在保障性能的同时减少Query与POI的交互。 3. 点评搜寻相关性计算基于示意的模型重在示意POI的全局特色，不足线上Query与POI的匹配信息，基于交互的办法能够补救基于示意办法的有余，加强Query和POI的交互，晋升模型表达能力，同时，鉴于预训练模型在文本语义匹配工作上的强劲体现，点评搜寻相关性计算确定了基于美团预训练模型MT-BERT[11]的交互式计划。将基于预训练模型的交互式BERT利用在点评搜寻场景的相关性工作中时，仍存在诸多挑战： 如何更好地结构POI侧模型输出信息：Doc侧模型输出信息的结构是相关性模型中的重要环节。在通用网页搜索引擎中，Doc的网页题目对相关性的判断极为重要，但在点评搜寻场景下，POI信息具备字段多、信息简单的特点，不存在能提供相似“网页题目”信息量的字段，每个商户都通过商户名、类目、地址、团单、商户标签等多种结构化信息来表白。在计算相关性分数时，大量多源商户信息无奈全副输出到模型中，而仅应用商户名和类目等根底信息又会因为信息缺失无奈达到称心的成果，因而如何更好地结构具备丰盛信息量的POI侧模型输出是咱们要解决的首要问题。如何优化模型来更好地适配点评搜寻相关性计算：公众点评搜寻场景中的文本信息与通用的预训练模型语料信息有肯定差别，例如通用语义场景下“开心”和“快乐”同义，但在点评搜寻的场景下“开心烧烤”和“快乐烧烤”却是两家齐全不同的品牌。同时，Query和POI的相关性断定逻辑与通用NLP场景的语义匹配工作也不完全相同，Query和POI的匹配模式非常复杂，当Query匹配到POI的不同字段时，相关性的断定后果也有所不同，例如Query“水果”匹配到“水果店”商户类目时相关性较高，而命中KTV的“水果拼盘”标签时则相关性较弱。因而，相比通用的基于交互的BERT句间关系语义匹配工作，相关性计算还须要关注Query和POI两局部之间的具体匹配状况。如何优化模型来适配点评搜寻的场景，并能解决简单多样的相关性判断逻辑，尽可能地解决各种不相干问题，是咱们面临的次要挑战；如何解决预训练相关性模型的在线性能瓶颈：基于示意的模型虽计算速度较快但表达能力无限，基于交互的模型能够加强Query和POI的交互从而晋升模型成果，但在线上应用时存在较大的性能瓶颈。因而，在线上应用12层BERT的基于交互的模型时，如何在保障模型计算成果的同时保障整个计算链路的性能，使其在线上稳固高效运行，是相关性计算线上利用的最初一道关卡。通过一直摸索与尝试，咱们针对POI侧的简单多源信息，结构了适配点评搜寻场景的POI文本摘要；为了让模型更好地适配点评搜寻相关性计算，采纳了两阶段训练的办法，并依据相关性计算的特点革新了模型构造；最初，通过优化计算流程、引入缓存等措施，胜利升高了模型实时计算和整体利用链路的耗时，满足了线上实时计算BERT的性能要求。 3.1 如何更好地结构POI侧模型输出信息在断定Query与POI的相干水平时，POI侧有十几个参加计算的字段，某些字段下的内容特地多（例如一个商户可能有上百个举荐菜），因而须要找到适合的形式抽取并组织POI侧信息，输出到相关性模型中。通用搜索引擎（如百度），或常见垂类搜索引擎（如淘宝），其Doc的网页题目或商品题目信息量丰盛，通常是相关性断定过程中Doc侧模型输出的次要内容。 如图3(a)所示，在通用搜索引擎中，通过搜寻后果的题目能够一眼看出对应网站的要害信息及是否与Query相干，而在图3(b)的搜寻后果中，仅通过商户名字段无奈失去短缺的商户信息，须要联合商户类目（奶茶果汁）、用户举荐菜品（奥利奥利奶茶）、标签（网红店）、地址（武林广场）多个字段能力判断该商户与Query“武林广场网红奶茶”的相关性。 标签抽取是业界比拟通用的抽取主题信息的路径，因而咱们首先尝试了通过商户标签来结构POI侧模型输出的办法，依据商户的评论、根底信息、菜品、商户对应的头部搜寻点击词等抽取出具备代表性的商户关键词来作为商户标签。在线上应用时，将已抽取的商户标签，及商户名和类目根底信息一起作为模型的POI侧输出信息，与Query进行交互计算。然而，商户标签对商户信息的笼罩仍不够全面，例如用户搜寻菜品“鸡蛋羹”时，某个距用户很近的韩式料理店有鸡蛋羹售卖，但该店的招牌菜、头部点击词等均与“鸡蛋羹”无关，导致该店所抽取的标签词也与“鸡蛋羹”相关性较低，因而模型会将该店判断为不相干，从而对用户体验带来挫伤。 为了获取最全面的POI表征，一种计划是不抽取关键词，间接将商户的所有字段拼接到模型输出中，然而这种形式会因为模型输出长度过长而重大影响线上性能，且大量冗余信息也会影响模型体现。 为结构更具信息量的POI侧信息作为模型输出，咱们提出了POI匹配字段摘要抽取的办法，即联合线上Query的匹配状况实时抽取POI的匹配字段文本，并结构匹配字段摘要作为POI侧模型输出信息。POI匹配字段摘要抽取流程如图4所示，咱们基于一些文本类似度特色，将与Query最相干且最具信息量的文本字段提取进去，并交融字段类型信息构建成匹配字段摘要。线上应用时，将已抽取的POI匹配字段摘要、商户名及类目根底信息一起作为POI侧模型输出。 在确定POI侧模型输出信息后，咱们采纳BERT句间关系工作，先用MT-BERT对Query侧和POI侧匹配字段摘要信息进行编码，而后应用池化后的句向量计算相干分。采纳POI匹配字段摘要的计划结构POI侧模型输出信息后，配合样本迭代，相比基于标签的办法，模型的成果有了极大的晋升。 3.2 如何优化模型来更好地适配点评搜寻相关性计算让模型更好地适配点评搜寻相关性计算工作蕴含两层含意：公众点评搜寻场景下的文本信息与MT-BERT预训练模型应用的语料在散布上存在着肯定的差别；预训练模型的句间关系工作与Query和POI的相关性工作也略有不同，须要对模型构造进行革新。通过一直摸索，咱们采纳基于畛域数据的两阶段训练计划，联合训练样本结构，使预训练模型更适配点评搜寻场景的相关性工作；并提出了基于多相似矩阵的深度交互相关性模型，增强Query和POI的交互，晋升模型对简单的Query和POI信息的表达能力，优化相关性计算成果。 3.2.1 基于畛域数据的两阶段训练为了无效利用海量用户点击数据，并使预训练模型MT-BERT更适配点评搜寻相关性工作，咱们借鉴百度搜寻相关性[12]的思维，引入多阶段训练方法，采纳用户点击和负采样数据进行第一阶段畛域适配的预训练（Continual Domain-Adaptive Pre-training），采纳人工标注数据进行第二阶段训练（Fine-Tune），模型构造如下图5所示： 基于点击数据的第一阶段训练 引入点击数据作为第一阶段训练任务的间接起因是在点评搜寻场景下存在着一些特有的问题，例如“开心”和“快乐”两个词在通用场景下是简直齐全同义的词，然而在点评搜寻的场景下“开心烧烤”和“快乐烧烤”却是两家齐全不同的品牌商户，因而点击数据的引入可能帮忙模型学习到搜寻场景下的一些特有常识。然而间接将点击样本用于相关性判断会存在较大噪声，因为用户点击某个商户可能是因为排序较为靠前导致的误点击，而未点击某个商户也可能仅仅是因为商户间隔较远，而并不是因为相关性问题，因而咱们引入了多种特色和规定来进步训练样本主动标注的准确率。 在结构样本时，通过统计是否点击、点击位次、最大点击商户距用户的间隔等特色筛选候选样本，将曝光点击率大于肯定阈值的Query-POI对作为正例，并依据业务特点对不同类型商户调整不同的阈值。在负例的结构上，Skip-Above采样策略将位于点击商户之前且点击率小于阈值的商户才做为负样本。此外，随机负采样的形式能够为训练样本补充简略负例，但思考随机负采样时也会引入一些噪声数据，因而咱们利用人工设计的规定对训练数据进行降噪：当Query的类目用意与POI的类目体系较为统一时或者与POI名高度匹配时，则将其从负样本中剔除。 基于人工标注数据的第二阶段训练 通过第一阶段训练后，思考到无奈齐全革除掉点击数据中的乐音，以及相关性工作的特点，因而须要引入基于人工标注样本的第二阶段训练来对模型进行纠偏。除了随机采样一部分数据交给人工去标注外，为了尽可能晋升模型的能力，咱们通过难例开掘和比照样本加强形式生产大量高价值样本交给人工去标注。具体如下： 1）难例开掘 特定类型样本开掘：通过设计一种基于Query和POI的特色和两者的匹配状况来刻画BadCase类型的办法，自动化从候选数据集中筛选出特定BadCase类型的样本进行送标。用户点击过但线上旧版模型断定为不相干的：该办法能够挖掘出当火线上模型预测谬误及语义靠近的用户难以辨别的难例。边缘采样：通过边缘采样的形式开掘具备较高不确定性的样本，如抽取模型预测得分在阈值左近的样本。模型或人工辨认艰难的样本：用以后模型预测训练集，将模型预测后果与标注标签不统一的样本，及人工标注标签有抵触的样本类型从新送标。2）比照样本加强：借鉴比照学习的思维，为一些高度匹配的样本生成比照样本进行数据加强，并进行人工标注确保样本标签的准确率。通过比照样本之间的差别，模型能够关注到真正有用的信息，同时晋升对同义词的泛化能力，从而失去更好的成果。 针对菜品词较容易呈现的跨菜品匹配的相关性问题（例如搜“鹅肝汉堡”匹配到售卖“牛肉汉堡”和“鹅肝寿司”的商家），别离用菜品的各个子成分与举荐菜字段进行匹配，生产大量比照样本，增强模型对于跨菜品匹配问题的辨认能力。针对菜品词命中举荐菜前缀的问题，通过革新齐全匹配到举荐菜的状况（搜“榴莲蛋糕”匹配到售卖“榴莲蛋糕”的商家），仅保留搜索词中的前缀，结构出匹配举荐菜前缀的比照样本（搜"榴莲"和售卖"榴莲蛋糕"的商家），使模型能更好的辨别匹配举荐菜前缀时的状况。 以跨菜品匹配的相关性问题为例，如上图6所示，同样是Query拆开后与商户的多个举荐菜字段匹配的状况，Query“榴莲蛋糕”与举荐菜“榴莲千层、黑森林蛋糕”是相干的，但Query“鹅肝汉堡”与“铁板鹅肝、芝士牛肉汉堡”是不相干的，为了加强模型对这类高度匹配但后果相同的Case的辨认能力，咱们结构了“榴莲蛋糕”与“榴莲千层”、“鹅肝汉堡”与“铁板鹅肝”这两组比照样本，去掉了与Query在文本上匹配但对模型判断没有帮忙的信息，让模型学到真正决定是否相干的要害信息，同时晋升模型对“蛋糕”和“千层”这类同义词的泛化能力。相似地，其余类型的难例同样能够用这种样本加强形式来晋升成果。 3.2.2 基于多相似矩阵的深度交互模型BERT句间关系是一个通用的NLP工作，用于判断两个句子的关系，而相关性工作是计算Query和POI的相干水平。在计算过程中，句间关系工作不仅计算Query与POI的交互，还计算Query外部和POI外部的交互，而相关性计算更关注Query与POI的交互。此外，在模型迭代过程中，咱们发现局部类型的艰难BadCase对模型的表达能力有更高要求，例如文本高度匹配但不相干的类型。因而，为进一步晋升模型对简单的Query和POI在相关性工作上的计算成果，咱们对第二阶段训练中的BERT句间关系工作进行革新，提出了基于多相似矩阵的深度交互模型，通过引入多相似矩阵来对Query和POI进行深度交互，引入indicator矩阵以更好地解决艰难BadCase问题，模型构造如下图7所示： 受CEDR[8]的启发，咱们将通过MT-BERT编码后的Query和POI向量进行拆分，用于显式地计算两局部的深度交互关系，将Query和POI拆分并进行深度交互，一方面能够专门用于学习Query与POI的相干水平，另一方面，减少的参数量能够晋升模型的拟合能力。 参考MatchPyramid[13]模型，深度交互相关性模型计算了四种不同的Query-Doc相似矩阵并进行交融，包含Indicator、Dot-product、余弦间隔及欧氏间隔，并与POI局部的输入进行Attention加权。其中Indicator矩阵用来形容Query与POI的Token是否统一，计算形式如下： Indicator矩阵能够较好地刻画Query和POI的匹配关系，该矩阵的引入次要思考到断定Query和POI相干水平时的一个难点：有时即便文本高度匹配，两者也不相干。基于交互的BERT模型构造更容易将文本匹配水平高的Query和POI断定为相干，然而在点评搜寻场景中，有些难例却未必如此。比方“豆汁”和“绿豆汁”尽管高度匹配，但并不相干。“猫空”和“猫的天空之城”尽管是拆开匹配，但因为前者是后者的缩写而相干。因而，将不同的文本匹配状况通过Indicator矩阵间接输出给模型，让模型显式地接管“蕴含”、“拆开匹配”等文本匹配状况，在帮忙模型晋升对难例判断能力的同时，也不会影响大部分失常的Case的体现。 基于多相似矩阵的深度交互相关性模型将Query和POI拆分后计算相似矩阵，相当于让模型对Query和POI进行显式交互，使模型更加适配相关性工作。多个相似矩阵则减少了模型对Query和POI相干水平计算的表征能力，而Indicator矩阵则是针对相关性工作中简单的文本匹配状况做的非凡设计，让模型对不相干后果的判断更加精确。 3.3 如何解决预训练相关性模型的在线性能瓶颈将相关性计算部署在线上时，现有计划通常会采纳常识蒸馏的双塔构造[10,14]以保障线上计算效率，但此种解决形式或多或少对于模型的成果是有损的。点评搜寻相关性计算为保障模型成果，在线上应用了基于交互的12层BERT预训练相关性模型，须要对每个Query下的数百个POI通过12层BERT的模型预测。为保障线上计算效率，咱们从模型实时计算流程和利用链路两个角度登程，通过引入缓存机制、模型预测减速、引入前置黄金规定层、将相关性计算与外围排序并行化等措施优化相关性模型在线上部署时的性能瓶颈，使得12层基于交互的BERT相关性模型在线上稳固高效运行，保障能够反对数百个商户和Query间的相关性计算。 3.3.1 相关性模型计算流程性能优化 点评搜寻相关性模型的线上计算流程如图8所示，通过缓存机制及TF-Serving模型预测减速来优化模型实时计算的性能。 为无效利用计算资源，模型线上部署引入缓存机制，将高频Query的相关性得分写入缓存。后续调用时会优先读取缓存，若命中缓存则间接输入打分，未命中缓存的则进行线上实时计算。缓存机制大大节俭了计算资源，无效缓解在线计算的性能压力。 对未命中缓存的Query，将其解决为Query侧模型输出，通过图4所述的流程获取每个POI的匹配字段摘要，并解决为POI侧模型输出格局，再调用线上相关性模型输入相干分。相关性模型部署在TF-Serving上，在模型预测时，采纳美团机器学习平台的模型优化工具ART框架（基于Faster-Transformer[15]改良）进行减速，在保障精度的同时极大地提高了模型预测速度。 3.3.2 利用链路性能优化 相关性模型在搜寻链路中的利用如上图9所示，通过引入前置黄金规定、将相关性计算与外围排序层并行化来优化整体搜寻链路中的性能。 为了进一步对相关性调用链路减速，咱们引入了前置黄金规定对Query分流，对局部Query通过规定间接输入相干分，从而缓解模型计算压力。在黄金规定层中利用文本匹配特色对Query和POI进行判断，例如，若搜索词跟商户名完全一致，则通过黄金规定层间接输入“相干”的断定，而无需通过相关性模型计算相干分。 ...

近日，美团搜寻与NLP部NLP核心语义了解团队的小样本学习模型FSL++在中文小样本语言了解权威评测基准FewCLUE榜单登顶，在自然语言推理（OCNLI）单任务中获得第一，并在极少数样本（一个类别仅100余个）的条件下，在新闻分类(TNEWS)、迷信文献学科分类（CSLDCP）工作上超过了人类辨认精确度。1 概述CLUE(Chinese Language Understanding Evaluation)[1]是中文语言了解权威测评榜单，蕴含了文本分类、句间关系、浏览了解等泛滥语义剖析和语义了解类子工作，对学术界和工业界都产生了较大的影响。 FewCLUE[2,3]是CLUE中专门用于中文小样本学习评测的一个子榜，旨在联合预训练语言模型通用和弱小的泛化能力，摸索小样本学习最佳模型和在中文上的实际。FewCLUE的局部数据集只有一百多条有标签样本，能够掂量模型在极少有标签样本下的泛化性能，公布后吸引了包含网易、微信AI、阿里巴巴、IDEA研究院、浪潮人工智能研究院等多家企业与研究院的参加。不久前，美团平台搜寻与NLP部NLP核心语义了解团队的小样本学习模型FSL++以优越的性能在FewCLUE榜单上获得第一名，达到SOTA程度。 2 办法介绍大规模预训练模型尽管在各大工作外面获得十分好的成果，然而在特定的工作上，还是须要许多标注数据。美团的各个业务中，有着丰盛的NLP场景，往往须要较高的人工标注老本。在业务倒退晚期或者新的业务需要须要疾速上线时，往往会呈现标注样本有余的景象，应用传统Pretrain（预训练）+ Fine-Tune（微调）的深度学习训练方法往往达不到现实的指标要求，因而钻研小样本场景的模型训练问题就变得十分必要。 本文提出了一套大模型 + 小样本的联结训练计划FSL++，综合了模型构造优选、大规模预训练、样本加强、集成学习以及自训练等模型优化策略，最终在中文语言了解权威评测基准下的FewCLUE榜单获得了优异的问题，并且在局部工作上性能超过了人类程度，而在局部工作上（如CLUEWSC）还有肯定的晋升空间。 FewCLUE公布后，网易伏羲应用自研的EET模型[4]，并通过二次训练加强模型的语义理解能力，再退出模版进行多任务学习；IDEA研究院的二郎神模型[5]在BERT模型的根底上应用更先进的预训练技术训练大模型，在上游工作微调的过程中用退出动静Mask策略的Masked Language Model(MLM)作为辅助工作。这些办法都应用Prompt Learning作为根本的工作架构，跟这些自研的大模型相比，咱们的办法次要在Prompt Learning框架的根底上退出了样本加强、集成学习以及自学习等模型优化策略，极大地提高模型的工作体现和鲁棒性，同时这套办法能够实用于各种预训练模型，更加灵便便捷。 FSL++整体模型构造如下图2所示。FewCLUE数据集为每个工作提供160条有标签数据以及靠近两万条无标签数据。本次FewCLUE实际中，咱们先在Fine-Tune阶段结构多模板Prompt Learning，并对有标签数据采纳反抗训练、比照学习、Mixup等加强策略。因为这些数据加强策略采纳不同的加强原理，能够认为这些模型之间差异性比较显著，通过集成学习之后会有比拟好的成果。所以在采纳数据加强策略进行训练当前，咱们领有了多个弱监督模型，并且用这些弱监督模型在无标签数据上进行预测，失去无标签数据的伪标签散布。之后，咱们将多个通过不同的数据加强模型预测失去的无标签数据的伪标签散布整合起来，失去一份总的无标签数据的伪标签散布，接着从新结构多模板Prompt Learning，并再次应用数据加强策略，抉择最优策略。目前，咱们的试验只进行一轮迭代，也能够尝试多轮迭代，不过随着迭代次数减少，晋升也不再显著。 2.1 加强预训练预训练语言模型是在宏大的无标签语料库上进行训练的。 例如，RoBERTa[6]在160GB以上的文本进行训练，包含百科全书、新闻文章、文学作品和Web内容。通过这些模型学习到的示意，在蕴含多种起源的各种大小的数据集的工作中实现杰出的性能。 FSL++模型应用RoBERTa-large模型作为根底模型，并且采纳融入畛域常识的Domain-Adaptive Pretraining (DAPT)[7]预训练方法和融入工作常识的Task-Adaptive Pretraining (TAPT)[7]。DAPT旨在预训练模型的根底上，减少大量畛域内无标签文本持续训练语言模型，之后再在指定工作的数据集上进行微调。 对指标文本畛域进行持续预训练，能够进步语言模型的性能，尤其是在与指标文本畛域相干的上游工作上的性能。并且，预训练文本与工作畛域的相关度越高，带来的晋升越大。在本次实际中，咱们最终应用了在100G蕴含娱乐节目、体育、衰弱、国际事务、电影、名人等各个领域的语料的CLUE Vocab[8]上预训练失去的RoBERTa Large模型。TAPT指在预训练模型的根底上，减少数量较少但与工作间接相干的无标签语料进行预训练。针对TAPT工作，咱们抉择应用的预训练数据是FewCLUE榜单为每个工作提供的无标签数据。 除此之外，在针对句间关系工作，如中文自然语言推理工作OCNLI、中文对话短文本匹配工作BUSTM的实际中，咱们应用在其余句间关系工作如中文自然语言推理数据集CMNLI、中文短文本类似度数据集LCQMC上进行预训练的模型参数作为初始参数，相比间接用原始模型实现工作，也能晋升肯定的成果。 2.2 模型构造FewCLUE蕴含多种工作模式，咱们为每种工作抉择了适合的模型构造。文本分类工作和机器浏览了解（MRC）工作自身的类别词就携带了信息，因而更适宜建模为Masked Language Model(MLM)模式；而句间关系工作判断两个句子的相关性，更相似于Next Sentence Prediction(NSP)[9]工作模式。因而，咱们为分类工作和浏览了解工作抉择PET[10]模型，为句间关系工作抉择EFL[11]模型，EFL办法能够通过全局采样结构负样本，学习到更鲁棒的分类器。 2.2.1 Prompt LearningPrompt Learning的次要指标是尽可能减小预训练指标与上游微调指标的差距。通常现有的预训练任务均蕴含MLM损失函数，然而上游的工作则并未采纳MLM，而是引入新的分类器，使得预训练任务和上游工作呈现了不统一。Prompt Learning不引入额定的分类器或其余参数，而是通过拼接模板（Template，即为输出数据拼接语言片段，从而革新工作为MLM模式）和标签词映射（Verbalizer，即为每个标签在词表中找到对应的词，从而为MLM工作设定预测指标），使得模型能够在大量样本的条件下在上游工作中应用。 以图3展现的电商评估情感剖析工作EPRSTMT为例。给定文本“这个电影真不错，值得第二次观看!”，传统的文本分类则是在CLS局部的Embedding接上分类器，并映射到0-1分类上（0：负向，1：正向）。这种办法在小样本场景下须要训练新的分类器，比拟难取得好的成果。而基于Prompt Learning的办法则是创立模板“这是一条 [MASK] 评。”，再将模板与原文进行拼接，训练时通过语言模型预测[MASK]地位的词，再将其映射到对应的类别上（好：正向， 差：负向）。 因为不足足够数据，有时很难确定体现最好的模板和标签词映射。因而，也能够采纳多模板与多标签词映射的设计。通过设计多个模板，最终的后果采纳多个模板的后果的整合，或设计一对多的标签词映射，让一个标签对应多个词。同上述例子，能够设计如下模板组合（左：同一个句子的多模板，右：多标签映射）。 工作样例 2.2.2 EFLEFL模型将两个句子拼接在一起，用输入层的[CLS]地位处的Embedding后接一个分类器实现预测。EFL的训练过程中，除了训练集的样本，还会进行负样本结构，训练过程中，在每个Batch里随机抉择其余数据中的句子作为负样本，通过结构负样本进行数据加强。尽管EFL模型须要训练新的分类器，但目前有很多公开的文本蕴含/句间关系数据集，如CMNLI、LCQMC等，能够通过在这些样本上进行继续学习(continue-train)，再将学习到的参数迁徙到小样本场景中，用FewCLUE的工作数据集进行进一步微调。 工作样例 2.3 数据加强数据加强办法次要有样本加强和Embedding加强。NLP畛域中，数据加强的目标是在不扭转语义的前提下裁减文本数据。次要的办法包含简略文本替换、应用语言模型生成类似句子等，咱们尝试过EDA等裁减文本数据的办法，然而一个词的变动就可能导致整个句子的意思产生翻转，通过替换的文本携带大量乐音，所以很难用简略的规定样本变动产生足够的加强数据。而Embedding加强，则不再对输出进行操作，转而在Embedding层面进行操作，能够通过对Embedding减少扰动或者插值等形式晋升模型的鲁棒性。 因而，本次实际中咱们次要进行Embedding加强。咱们用的数据加强策略别离有Mixup[12]、Manifold-Mixup[13]、反抗训练(Adversarial training, AT) [14]和比照学习R-drop[15]。数据加强策略的具体介绍见之前的技术博客小样本学习及其在美团场景中的利用。 Mixup通过对输出数据进行简略的线性变换，结构新的组合样本和组合标签，能够加强模型的泛化能力。在各种有监督工作或者半监督工作上，应用Mixup都能极大进步模型的泛化能力。Mixup办法能够视为正则化操作，它要求模型在特色层面生成的组合特色满足线性束缚，并且利用这种束缚对模型施加正则化。直观来看，当模型的输出为另外两个输出的线性组合时，其输入也是这两个数据独自输出模型后所得输入的线性组合，其实就是要求模型近似为一个线性系统。 Manifold Mixup将上述的Mixup操作泛化到特色上。因为特色具备更高阶的语义信息，所以在其维度上插值可能会产生更有意义的样本。在相似于BERT[9]、RoBERTa[6]的模型中，随机抉择层数k，对该层的特色示意进行Mixup插值。一般的Mixup的插值产生在输入层Embedding局部，而Manifold Mixup相当于把这一系列插值操作退出到语言模型外部的Transformers构造的随机某层中。 ...

全量SQL（所有拜访数据库的SQL）能够无效地帮忙平安进行数据库审计，帮忙业务疾速排查性能问题。个别可通过开启genlog日志或者启动MySQL审计插件形式来进行获取，而美团选用了一种非侵入式的旁路抓包计划，应用Go语言实现。无论采纳哪种计划，都须要重点关注它对数据库的性能损耗。本文介绍了美团根底研发平台抓包计划在数据库审计实际中遇到的性能问题以及优化实际，心愿能对大家有所帮忙或启发。1 背景数据库安全始终是美团信息安全团队和数据库团队十分重视的畛域，但因为历史起因，对数据库的拜访只具备采样审计能力，导致对于一些攻打事件无奈疾速地发现、定损和优化。平安团队依据历史教训，发现攻打拜访数据库基本上都存在着某些特色，常常会应用一些特定SQL，咱们心愿通过对MySQL拜访流量进行全量分析，辨认出习用SQL，在数据库安全性上做到对症下药。 2 现状及挑战下图是采样MySQL审计零碎的架构图，数据采集端基于pcap抓包形式实现，数据处理端选用美团大数据中心的日志接入计划。所有MySQL实例都部署了用于采集MySQL相干数据的rds-agent、日志收集的log-agent。rds-agent抓取到MySQL拜访数据，通过log-agent上报到日志接收端，为了缩小延时，上报端与接收端间做了同机房调度优化。日志接收端把数据写入到约定的Kafka中，平安团队通过Storm实时生产Kafka剖析出攻打事件，并定期拉数据长久化到Hive中。 咱们发现，通常被攻打的都是一些外围MySQL集群。经统计发现，这些集群单机最大QPS的9995线约5万次左右。rds-agent作为MySQL机器上的一个寄生过程，为了宿主稳定性，资源管制也极为重要。为了评估rds-agent在高QPS下的体现，咱们用Sysbench对MySQL进行压测，察看在不同QPS下rds-agent抓取的数据失落率和CPU耗费状况，从上面的压测数据来看后果比拟蹩脚： QPS失落率CPU利用率10368.721.03%307.35%17172.617.23%599.90%29005.5128.75%662.39%42697.0551.73%622.34%50833.5063.95%601.39%如何在高QPS下保障较低的失落率与CPU耗费？曾经成为以后零碎的一个亟待解决的难题与挑战。 3 剖析及优化上面次要介绍围绕失落率与CPU耗费这一问题，咱们对数据采集端在流程、调度、垃圾回收和协定方面做的剖析与改良。 3.1 数据采集端介绍首先，简要介绍一下数据采集端rds-agent，它是一个MySQL实例上的过程，采纳Go语言编写，基于开源的MysqlProbe的Agent革新。通过监听网卡上MySQL端口的流量，剖析出客户端的拜访工夫、起源IP、用户名、SQL、指标数据库和指标IP等审计信息。上面是其架构图，次要分为5大功能模块： 1. probe probe意为探针，采纳了gopacket作为抓包计划，它是谷歌开源的一个Go抓包库，封装了pcap。probe把抓取到原始的数据链路层帧封装成TCP层的数据包。通过变种的Fowler-Noll-Vo算法哈希源和目标IP port字段，疾速实现把数据库连贯打散到不同的worker中，该算法保障了同一连贯的来包与回包的哈希值一样。 2. watcher 登录用户名对于审计来说极其重要，客户端往往都是通过长连贯拜访MySQL，而登录信息仅呈现在MySQL通信协议的认证握手阶段，仅通过抓包容易错过。 watcher通过定时执行show processlist获取以后数据库的所有连贯数据，通过比照Host字段与以后包的客户端ip port，弥补错过的用户名信息。 3. worker 不同的worker负责管理不同数据库连贯的生命周期，一个worker治理多个连贯。通过定期比对worker的以后连贯列表与watcher中的连贯列表，及时发现过期的连贯，敞开并开释相干资源，避免内存透露。 4. connStream 整个数据采集端的外围逻辑，负责依据MySQL协定解析TCP数据包并辨认出特定SQL，一个连贯对应一个connStream Goroutine。因为SQL中可能蕴含敏感数据，connStream还负责对SQL进行脱敏，具体的特定SQL辨认策略，因为平安方面起因，这里不再进行开展。 5. sender 负责数据上报逻辑，通过thrift协定将connStream解析出的审计数据上报给log-agent。 3.2 根底性能测试抓包库gopacket的性能间接决定了零碎性能下限，为了探索问题是否出在gopacket上，咱们编写了繁难的tcp-client和tcp-server，独自对gopacket在数据流向图中波及到的前三个步骤（如下图所示）进行了性能测试，从上面的测试后果数据上看，性能瓶颈点不在gopacket。 QPSpcap缓冲区失落率CPU利用率100000100MB0%144.9%3.3 CPU画像剖析失落率与CPU耗费二者密不可分，为了探索如此高CPU耗费的起因，咱们用Go自带的pprof工具对过程的CPU耗费进行了画像剖析，从上面火焰图的调用函数能够演绎出几个大头：SQL脱敏、解包、GC和Goroutine调度。上面次要介绍一下围绕它们做的优化工作。 3.4 脱敏剖析及改良因为SQL中可能蕴含敏感信息，出于平安思考，rds-agent会对每一条SQL进行脱敏解决。 脱敏操作应用了pingcap的SQL解析器对SQL进行模板化：即把SQL中的值全副替换成“?”来达到目标，该操作须要解析出SQL的形象语法树，代价较高。以后只有采样和抓取特定SQL的需要，没有必要在解析阶段对每条SQL进行脱敏。这里在流程上进行了优化，把脱敏下沉到上报模块，只对最终发送进来的样本脱敏。 这个优化获得的成果如下： 比照项QPS失落率CPU利用率改良前50833.5063.95%601.39%改良后51246.47<font color=##FF0000>31.95%</font><font color=##FF0000>259.59%</font>3.5 调度剖析及改良从上面的数据流向图能够看出整个链路比拟长，容易呈现性能瓶颈点。同时存在泛滥高频运行的Goroutine（红色局部），因为数量多，Go须要常常在这些Goroutine间进行调度切换，切换对于咱们这种CPU密集型的程序来说无疑是一种累赘。 针对该问题，咱们做了如下优化： 缩短链路：分流、worker、解析SQL等模块合并成一个Goroutine解析器。升高切换频率：解析器每5ms从网络协议包的队列中取一次，相当于手动触发切换。(5ms也是一个屡次测试后的折中数据，太小会耗费更多的CPU，太大会引起数据失落)这个优化获得的成果如下： 比照项QPS失落率CPU利用率改良前51246.4731.95%259.59%改良后51229.54<font color=##FF0000>0%</font><font color=##FF0000>206.87%</font>3.6 垃圾回收压力剖析及改良下图为rds-agent抓包30秒，已调配指针对象的火焰图。能够看出曾经调配了4千多万个对象，GC压力可想而知。对于GC，咱们理解到如下两种优化计划： 池化：Go的规范库中提供了一个sync.Pool对象池，可通过复用对象来缩小对象调配，从而升高GC压力。手动治理内存：通过零碎调用mmap间接向OS申请内存，绕过GC，实现内存的手动治理。 然而，计划2容易呈现内存透露。从稳定性的角度思考，咱们最终抉择了计划1来治理高频调用函数里创立的指针对象，这个优化获得的成果如下： 比照项QPS失落率CPU利用率改良前51229.540%206.87%改良后51275.110%<font color=##FF0000>153.32%</font>3.7 解包剖析及改良MySQL是基于TCP协定之上的，在性能调试过程中，咱们发现了很多空包。从上面的MySQL客户端-服务端数据的交互图能够看出：当客户端发送一条SQL命令，服务端响应后果，因为TCP的音讯确认机制，客户端会发送一个空的ack包来确认音讯，而且空包在整个流程中的比例较大，它们会穿透到解析环节，在高QPS下对于Goroutine调度和GC来说无疑是一个累赘。 下图是MySQL数据包的惟一格局，通过剖析，咱们察看到以下特点： 一个残缺的MySQL数据包长度>=4Byte客户端新发送命令的sequence id都是为0或者1而pcap反对设置过滤规定，让咱们能够在内核层将空包排除掉，上面是上述特点对应的两条过滤规定： 特点1： ip[2:2] - ((ip[0] & 0x0f) << 2) - ((tcp[12:1] & 0xf0) >> 2) >= 4特点2： (dst host {localIP} and dst port 3306 and (tcp[(((tcp[12:1] & 0xf0) >> 2) + 3)] <= 0x01))这个优化获得的成果如下： ...

减小利用安装包的体积，对晋升用户体验和下载转化率都大有益处。本文将联合美团平台的实践经验，分享 so 体积优化的思路、收益，以及工程实际中的注意事项。1. 背景利用安装包的体积影响着用户的下载时长、装置时长、磁盘占用空间等诸多方面，因而减小安装包的体积对于晋升用户体验和下载转化率都大有益处。Android 利用安装包其实是一个 zip 文件，次要由 dex、assets、resource、so 等各类型文件压缩而成。目前业内常见的包体积优化计划大体分为以下几类： 针对 dex 的优化，例如 Proguard、dex 的 DebugItem 删除、字节码优化等；针对 resource 的优化，例如 AndResGuard、webp 优化等；针对 assets 的优化，例如压缩、动静下发等；针对 so 的优化，同 assets，另外还有移除调试符号等。随着动态化、端智能等技术的广泛应用，在采纳上述优化伎俩后， so 在安装包体积中的比重仍然很高，咱们开始考虑这部分体积是否能进一步优化。 通过一段时间的调研、剖析和验证，咱们逐步摸索出一套能够将利用安装包中 so 体积进一步减小 30%～60% 的计划。该计划蕴含一系列纯技术优化伎俩，对业务侵入性低，通过简略的配置，能够疾速部署失效，目前美团 App 已在线上部署应用。为让大家能知其然，也能知其所以然，本文将先从 so 文件格式讲起，联合文件格式剖析哪些内容能够优化。 2. so 文件格式剖析so 即动静库，实质上是 ELF（Executable and Linkable Format）文件。能够从两个维度查看 so 文件的内部结构：链接视图（Linking View）和执行视图（Execution View）。链接视图将 so 主体看作多个 section 的组合，该视图体现的是 so 是如何组装的，是编译链接的视角。而执行视图将 so 主体看作多个 segment 的组合，该视图通知动静链接器如何加载和执行该 so，是运行时的视角。鉴于对 so 优化更侧重于编译链接角度，并且通常一个 segment 蕴含多个 section（即链接视图对 so 的合成粒度更小），因而咱们这里只探讨 so 的链接视图。 通过 readelf -S 命令能够查看一个 so 文件的所有 section 列表，参考 ELF 文件格式阐明，这里简要介绍一下本文波及的 section： ...

CompletableFuture由Java 8提供，是实现异步化的工具类，上手难度较低，且功能强大，反对通过函数式编程的形式对各类操作进行组合编排。相比于ListenableFuture，CompletableFuture无效晋升了代码的可读性，解决了“回调天堂”的问题。本文次要讲述CompletableFuture的原理与实际，同时联合了美团外卖商家端API的异步化实战，心愿能对从事相干开发的同学有所帮忙或启发。0 背景随着订单量的持续上升，美团外卖各零碎服务面临的压力也越来越大。作为外卖链路的外围环节，商家端提供了商家接单、配送等一系列外围性能，业务对系统吞吐量的要求也越来越高。而商家端API服务是流量入口，所有商家端流量都会由其调度、聚合，对外面向商家提供性能接口，对内调度各个上游服务获取数据进行聚合，具备显明的I/O密集型（I/O Bound）特点。在以后日订单规模已达千万级的状况下，应用同步加载形式的弊病逐步浮现，因而咱们开始思考将同步加载改为并行加载的可行性。 1 为何须要并行加载外卖商家端API服务是典型的I/O密集型（I/O Bound）服务。除此之外，美团外卖商家端交易业务还有两个比拟大的特点： 服务端必须一次返回订单卡片所有内容：依据商家端和服务端的“增量同步协定注1”，服务端必须一次性返回订单的所有信息，蕴含订单主信息、商品、结算、配送、用户信息、骑手信息、餐损、退款、客服赔付（参照上面订单卡片截图）等，须要从上游三十多个服务中获取数据。在特定条件下，如第一次登录和长时间没登录的状况下，客户端会分页拉取多个订单，这样发动的近程调用会更多。商家端和服务端交互频繁：商家对订单状态变动敏感，多种推拉机制保障每次变更可能触达商家，导致App和服务端的交互频繁，每次变更须要拉取订单最新的全部内容。在外卖交易链路如此大的流量下，为了保障商家的用户体验，保障接口的高性能，并行从上游获取数据就成为必然。 2 并行加载的实现形式并行从上游获取数据，从IO模型上来讲分为同步模型和异步模型。 2.1 同步模型从各个服务获取数据最常见的是同步调用，如下图所示： 在同步调用的场景下，接口耗时长、性能差，接口响应时长T > T1+T2+T3+……+Tn，这时为了缩短接口的响应工夫，个别会应用线程池的形式并行获取数据，商家端订单卡片的组装正是应用了这种形式。 这种形式因为以下两个起因，导致资源利用率比拟低： CPU资源大量节约在阻塞期待上，导致CPU资源利用率低。在Java 8之前，个别会通过回调的形式来缩小阻塞，然而大量应用回调，又引发臭名远扬的回调天堂问题，导致代码可读性和可维护性大大降低。为了减少并发度，会引入更多额定的线程池，随着CPU调度线程数的减少，会导致更重大的资源争用，贵重的CPU资源被损耗在上下文切换上，而且线程自身也会占用系统资源，且不能有限减少。同步模型下，会导致硬件资源无奈充分利用，零碎吞吐量容易达到瓶颈。 2.2 NIO异步模型咱们次要通过以下两种形式来缩小线程池的调度开销和阻塞工夫： 通过RPC NIO异步调用的形式能够升高线程数，从而升高调度（上下文切换）开销，如Dubbo的异步调用能够参考《dubbo调用端异步》一文。通过引入CompletableFuture（下文简称CF）对业务流程进行编排，升高依赖之间的阻塞。本文次要讲述CompletableFuture的应用和原理。2.3 为什么会抉择CompletableFuture？咱们首先对业界宽泛风行的解决方案做了横向调研，次要包含Future、CompletableFuture注2、RxJava、Reactor。它们的个性比照如下： FutureCompletableFutureRxJavaReactorComposable（可组合）❌✔️✔️✔️Asynchronous（异步）✔️✔️✔️✔️Operator fusion（操作交融）❌❌✔️✔️Lazy（提早执行）❌❌✔️✔️Backpressure（回压）❌❌✔️✔️可组合：能够将多个依赖操作通过不同的形式进行编排，例如CompletableFuture提供thenCompose、thenCombine等各种then结尾的办法，这些办法就是对“可组合”个性的反对。操作交融：将数据流中应用的多个操作符以某种形式联合起来，进而升高开销（工夫、内存）。提早执行：操作不会立刻执行，当收到明确批示时操作才会触发。例如Reactor只有当有订阅者订阅时，才会触发操作。回压：某些异步阶段的处理速度跟不上，间接失败会导致大量数据的失落，对业务来说是不能承受的，这时须要反馈上游生产者升高调用量。RxJava与Reactor显然更加弱小，它们提供了更多的函数调用形式，反对更多个性，但同时也带来了更大的学习老本。而咱们本次整合最须要的个性就是“异步”、“可组合”，综合思考后，咱们抉择了学习老本绝对较低的CompletableFuture。 3 CompletableFuture应用与原理3.1 CompletableFuture的背景和定义3.1.1 CompletableFuture解决的问题CompletableFuture是由Java 8引入的，在Java8之前咱们个别通过Future实现异步。 Future用于示意异步计算的后果，只能通过阻塞或者轮询的形式获取后果，而且不反对设置回调办法，Java 8之前若要设置回调个别会应用guava的ListenableFuture，回调的引入又会导致臭名远扬的回调天堂（上面的例子会通过ListenableFuture的应用来具体进行展现）。CompletableFuture对Future进行了扩大，能够通过设置回调的形式解决计算结果，同时也反对组合操作，反对进一步的编排，同时肯定水平解决了回调天堂的问题。上面将举例来说明，咱们通过ListenableFuture、CompletableFuture来实现异步的差别。假如有三个操作step1、step2、step3存在依赖关系，其中step3的执行依赖step1和step2的后果。 Future(ListenableFuture)的实现（回调天堂）如下： ExecutorService executor = Executors.newFixedThreadPool(5);ListeningExecutorService guavaExecutor = MoreExecutors.listeningDecorator(executor);ListenableFuture<String> future1 = guavaExecutor.submit(() -> { //step 1 System.out.println("执行step 1"); return "step1 result";});ListenableFuture<String> future2 = guavaExecutor.submit(() -> { //step 2 System.out.println("执行step 2"); return "step2 result";});ListenableFuture<List<String>> future1And2 = Futures.allAsList(future1, future2);Futures.addCallback(future1And2, new FutureCallback<List<String>>() { @Override public void onSuccess(List<String> result) { System.out.println(result); ListenableFuture<String> future3 = guavaExecutor.submit(() -> { System.out.println("执行step 3"); return "step3 result"; }); Futures.addCallback(future3, new FutureCallback<String>() { @Override public void onSuccess(String result) { System.out.println(result); } @Override public void onFailure(Throwable t) { } }, guavaExecutor); } @Override public void onFailure(Throwable t) { }}, guavaExecutor);CompletableFuture的实现如下： ...

美团住宿数据治理团队从事数据治理工作多年，从最后的被动、单点治理，倒退到起初的被动、专项治理，再倒退到当初的体系化、自动化治理。一路走来，他们一直进行积攒和积淀，也在继续思考与实际。目前该团队获得了一些阶段性的成绩，并失去美团多个业务线的认可和必定。过程的教训与教训，心愿能和大家分享，也心愿能给从事数据治理工作的同学带来一些新思路。一、序言美团住宿数据治理团队通过多年数仓建设及数据治理的教训积淀，并联合业务倒退阶段对于数据治理的诉求，将治理的思路逐渐从专项、表象、问题驱动的治理，转变为自动化、体系化的治理，并从标准化、数字化、系统化三个方向进行了落地与实际。 二、背景介绍美团住宿业务从2014年上线之后倒退多年，历经探索期、防御期，发展期，并逐渐由发展期向改革期过渡。业务从之前的疾速扩张阶段进入绝对稳固的倒退阶段，经营伎俩转变为精细化经营，同时对数据的老本、效率、平安、价值等方向的要求也越来越高，这些都对数据治理提出了新的要求。 另一方面，住宿数据组所属的数据中心外部有住宿、门票度假等多条业务线，各业务线业务模式不同，所处业务生命周期阶段不同，在数据治理上的认知及教训积攒也不同。如何能将数据治理教训及能力高效复用，使数据中心各业务线在数据治理的效率和成果上都能稳步晋升，防止踩坑，这就须要数据治理更加标准化、体系化、自动化。 此前，咱们在数据治理上曾经有了一些积攒和积淀，前一阶段次要从单点、被动的治理转变为被动、专项的治理，治理动作无意识、有布局，也有肯定的针对性，且获得了肯定的成绩（前一阶段的治理教训可参考美团酒旅数据治理实际一文），但总的来说仍以问题驱动治理、凭教训治理为主。面对新的数据治理责任及要求，过往的形式存在着一些问题，次要包含以下几个方面。 治理认知差别大 认知不统一，思路不对立：治理不足通用的体系指引，不同的治理人对于数据治理的认知深度、问题拆解的形式、治理的思路步骤、采取的办法及其成果追踪等方面，都存在较大的差别。反复治理、信息不通：治理不彻底、治理教训不足积淀，同样的治理，不同的人重复履行。范畴穿插、边界不清、成果难评估：不同的人针对不同的问题成立不同的专项进行治理，问题的底层逻辑有穿插。有的治理没做什么动作，反而收到了较好的后果，有的治理对于后果说不清。治理办法不规范 流程标准缺失：对于每个方向、每类问题的治理短少理论指导，治理的办法、动作、流程、步骤依赖治理人的教训和判断。问题难度量追踪：治理的问题短少衡量标准，更多靠人为来进行判断，治理成果短少评估体系。解决方案难落地：解决方案存在于文档中，须要治理人查找了解，短少工具撑持，老本较高。治理效率低、成果差 治理线上化水平低：治理依赖的资产信息、治理动作都扩散于多个零碎中，信息碎片化，执行效率低。过程无奈标准化，后果无保障：治理过程须要治理人来“人为保障”，存在了解偏差和执行偏差。数据管治不足体系化 不足整体顶层治理方案设计：业务及数据中心对于数据治理的要求，须要治理更全面、更精密、更无效，须要治理的体系化，须要从宏观角度进行思考，层层拆解，须要从整体、从顶层来做方案设计。问题越来越简单，单点难解决：过往更多的是从表象去解决问题，从外表来看掂量指标有改善，理论是“头痛医头、脚痛医脚”，并没有从根本上解决问题。或者多个问题具备共性，基本问题是统一的。比方查问资源缓和的基本，可能是剖析主题模型建设有余或经营不够。不同问题的优先级无奈确定：不同问题的优先级不足衡量标准和办法，次要靠人为判断。治理不合乎MECE准则：每个治理方向由哪些问题组成，哪些最重要，哪些的ROI最高，哪些问题和治理动作能够合并，同一问题在数仓不同主题、不同分层的衡量标准和治理办法应该有哪些差别，都须要在体系化治理中进行思考。三、治理体系化思考从上述背景中不难看出，咱们面临着不同业务生命周期阶段对数据建设和治理不同的要求及挑战，同时过往更多的以被动治理、问题驱动的专项治理形式办法也比较落后，这间接导致技术团队很难满足业务方对于财务、业务反对等方面的要求。 通过一直的吸取教训和总结经验，咱们开始意识到数据管治是一个非常复杂的综合性问题，只有构建出一套规范的业务数据管治体系，能力确保数据治理在现状评估、指标制订、流程标准建设、治理监控治理、能力建设、执行效率、成果评估等各环节无效落地。上面介绍一下咱们在治理体系化层面的了解和思考。 3.1 什么是数据治理体系化？针对数据管理和治理，咱们冀望搭建一套集管理体系、办法体系、评估体系、规范体系、工具体系等外围能力的组合，继续服务于数据管治施行。能够类比个别的电商公司，如果须要运行并服务好顾客，它首先必须搭建起来一套销售体系、产品体系、供应体系、物流体系、人力体系等等，只有这样才能够相互配合，实现服务好用户这一大指标。 3.2 数据治理体系化如何解决目前治理存在的问题？形式办法上：先做顶层治理框架设计，从团队整体视角定义和布局好治理的范畴、人员、职责、指标、办法、工具等必须局部，再进行落地。更关注整体策略的普适性及有效性，而非深陷某个具体问题解决方案开始治理。技术手段上：以欠缺的技术研发标准为根底，以元数据及指标体系为外围，对业务数仓和数据利用进行全面评估和监控，同时配套治理零碎工具，帮忙治理同学落地治理策略和解决数据开发同学治理效率低问题。经营策略上：通过看待治理问题进行影响范畴、收益状况进行评估，确定待治理问题的重要度，从管理者视角以及问题责任人视角2个路径推动不同重要水平的治理问题解决。3.3 业务数据管治体系框架如何建设？咱们的建设思路是：以团队数据治理指标为外围导向，设计实现目标须要的相干能力组合，并依据组织要求，施行过程的问题反馈，继续一直地迭代欠缺，最终实现数据治理的愿景。 体系框架次要蕴含以下内容： 管理层：立法，制订相干的组织保障流程标准、职责设计、奖惩措施，领导和保障数据治理顺利进行，这是数据治理可能胜利启动运行的关键因素。规范层：设规范，制订各类研发标准规范、解决方案规范SOP等数据治理过程中须要的各类技术规范和解决方案，这是所有技术问题正确与否的重要依据，也是治理中事先解决方案必不可少的一部分。欠缺的标准规范和良好的落地成果，可很好地升高数据故障问题的发生量。能力层：欠缺能力，次要是基于元数据的问题度量的数字化能力，以及问题工具化检测和解决的系统化能力。数字化和系统化能力是数据治理施行的科学性、施行的品质及效率的重要保障。执行层：设定动作，联合要达成的具体指标，对各治理域问题，依照事先束缚、事中监控、预先治理的思路进行解决。指标的达成，须要拆分到7大治理域相干的具体问题中去落地。因而，一个治理指标的达成，很依赖治理域对问题形容的全面性及深度。评估层：给出评估，基于指标的问题监控，衰弱度评估体系，专项评估报告，评估治理收益及成果，这是施行治理推动过程监控，后果测验的重要抓手。愿景：长期治理指标，领导数据管治有方向地一直朝着最终目标后退。 体系框架建设成绩：业务数据治理体系框架是针对数据治理工作整体做的顶层方案设计，框架定义好了业务线数据治理是什么、怎么做、做什么、用什么工具以及达成什么指标。拉齐各方对业务数据治理的认知，标准化治理门路办法和组成部分，领导数据治理有序、无效地进行。 3.4 体系框架如何落地施行？参照业务线数据标准化管治体系框架各组成部分特点，咱们具体通过标准化、数据化、系统化3大部分能力建设及经营，来实现数据管治体系框架的落地，并利用在数据治理问题的解决中，最终拿到可量化的后果。 四、治理体系化实际4.1 标准化数据治理标准化是企业进行数据资产治理的要害突破口和重要伎俩，一系列政策、法规、布局须要转化为规范和制度能力无效落地。数据治理标准化既有利于建立健全各种数据管理工作机制、欠缺业务流程，又有利于晋升数据品质，保障数据安全合规应用，开释数据价值。但在数据治理标准化建设过程中，咱们常常会面临以下三个问题： 流程标准缺失：各个环节短少规范和束缚来领导规范化操作，无奈无效杜绝问题的产生、解决。落地条件差：标准规范、SOP等不具备落地条件，靠主观志愿，无奈无效落地，成果差。建设办法不合理：标准建设Case by Case，短少体系化建设思路导致“始终建、始终缺”。针对上述三个问题，咱们从解决问题的视角登程，划分数据开发流程，通过事先束缚、事中监控、预先剖析评估的思路，整顿补齐缺失的流程标准，从而实现规范流程标准在数据管治各环节全笼罩，并建设系统化工具来保障标准规范的落地施行。下文将别离从标准建设及工具保障两方面来介绍咱们在数据治理标准化过程中是如何解决上述问题的。 4.1.1 标准建设标准是数据治理建章立制的根底，针对标准规范建设不合理及流程标准缺失的问题，咱们用体系化的建设思路从整体架构上对数据开发流程及数据治理流程进行划分，并针对全流程数据管治各个环节建设相应标准： 数据治理治理标准：明确数据治理组织职责以及人员构成，确定数据治理施行流程及治理问题运维流程，以保障数据治理过程顺利进行。数据研发标准：明确数据开发各个环节须要恪守的标准要求，从问题产生的源头，通过建设欠缺的研发标准，领导研发工作按规范进行，肯定水平上可缩小问题产生。数据标准化治理SOP：明确各个治理问题治理动作，确保治理动作是规范且可施行。数据衰弱度评估标准：明确治理成果的评估规范，对数据体系做到长期，稳固及指标化的掂量。 4.1.2 工具保障标准规范可视化-常识核心在标准规范的共享方面，以往技术团队在理论标准落地过程中可能存在以下问题： 标准找不着：重要标准文档散落在各个Wiki空间，导致应用时无奈疾速查找，效率低下。标准品质差：文档没有对立进行保护，无奈继续进行迭代和欠缺，不能随着业务及技术的倒退更新。标准没权限：文档散落在各个成员的私人空间外部，未对所有人开明权限，优质内容无奈及时共享。针对上述问题，咱们从新收集整理已有标准文档并进行分类，补充缺失文档，优化文档内容，并新增常识核心模块，将常识体系框架产品化，在产品层面保护对立的入口及权限治理，同时严格控制公布流程，解决了标准规范在理论落地时“找不着”、“品质差”、“没权限”等问题。 测试标准工具化-八卦炉在数据测试标准落地方面，以往数据测试标准都是通过Wiki保护，无奈束缚大家理论执行过程，导致数据品质较差，容易呈现数据故障。为缩小数据开发过程中因为测试不标准而导致数据故障的状况，晋升数据品质及业务满意度，咱们利用数据中心与数据平台工具组合作共建的ETL测试工具（美团外部工具-八卦炉）来保障测试标准SOP落地执行，要求大家在不影响测试验数效率状况下充沛测试，实现数据治理问题在事先束缚，缩小预先问题量，保障数据品质，工具建设如下图所示： 治理提效保质工具-SOP自动化工具在日常数据开发工作中，数据工程师会承当一部分数据治理工作，以往都是通过执行数据治理SOP中每个步骤对问题进行治理，但常常会面临以下几个问题： 治理效率低：须要依据SOP中治理教训，去各个平台别离执行相应治理动作，对于一些步骤较为简单的SOP，须要跳转多个平台操作，治理效率较低。治理过程无奈束缚：治理教训浮于文字，无奈束缚数据工程师的执行动作，导致局部问题治理不彻底。基于上述问题，咱们开发了治理提效工具-SOP自动化工具，汇总多个平台治理工具，将数据治理标准化SOP的各个执行步骤通过工具落地，实现在一个工具内一站式治理能力，束缚工程师的治理动作，确保整个治理过程是规范的，成果是可监控的，从而晋升了治理效率及治理品质。 比方有效工作的治理，首先须要调研问题治理教训并积淀至SOP文档，而后将SOP文档中各个执行步骤顺次通过自动化的工具进行配置。数据工程师在治理时只须要在一个界面内即可实现全副的治理动作，下图是有效工作治理SOP及美团的自动化工具： 4.1.3 标准化收益及建设教训通过数据治理标准化建设，咱们解决了团队在数据治理标准方面若干问题，获得了显著成果： 实现了数据开发、数据治理的标准化，解决了团队内各小组之间在开发、治理、运维方面流程办法规范不统一的问题。通过测试工具对标准化测试标准进行落地，在事先阻塞问题产生，晋升数据品质，缩小故障产生。通过SOP自动化工具，无效保障治理过程的标准化，解决了治理成果差的问题。同时，咱们在理论建设的过程中，也总结了一些标准化的建设教训： 标准规范如何落地，需成为规范流程标准建设的一部分，最好有交付物。标准规范的制订，除惯例内容外，须要综合思考组织指标、组织特点、已有工具、历史状况、用户反馈等因素，否则会给人“不接地气”的感觉。标准规范的制订要优先思考利用和适配已有工具能力，借助工具落地，而非让工具适配流程标准。4.2 数字化以往大家在发展数据治理工作时次要依赖教训判断，不足迷信可量化的抓手，对治理问题的重大水平无奈精确感知，同时对治理收益的回收也不能精确评估。因而咱们发展了数字化的工作，将大家数据开发工作用数据形容，构建整个数据开发工作的精确视图。 4.2.1 数字化架构设计计划建设思路：通过对数据生命周期各环节进行类比业务数仓建设中形象和形容业务对象形式，进行元数据对象的形象和形容，并建设成元数据数仓和治理指标体系，利用在数据管治场景 框架次要蕴含元数据仓库、指标体系、数据资产等级以及基于元数仓根底上建设的各个数据利用，利用元数据驱动数据治理及日常团队治理，防止过多依赖教训解决问题，更好地服务业务。下边几个章节将别离介绍数字化框架最外围的数据内容：元数据仓库、指标体系、数据资产等级。 4.2.2 元数据仓库建设元数据是形容数据的数据，蕴含数据资产品种、数据存储大小、数据流血缘关系、数据生产过程等信息，存在信息品种多，散布零散，信息不残缺的特点。丰盛的元数据有助于咱们疾速理解团队数据资产，让数据资产更加精准，通明。为数据应用和价值开释提供撑持。 咱们的建设思路，采取数据业务化、业务数字化、数字利用化的思路来搭建元数据仓库。 数据业务化：行将数据工程师日常数据开发工作业务化形容，形象多个业务过程，如需要提出、工作开发、数据表产出、数据利用、需要交付。业务数字化：用建设业务数仓的思路和办法，对数据业务化之后的各个业务过程及主题，搭建元数据数仓及指标掂量体系，并通过元数据场景化利用晋升易用性及丰盛度。数字利用化：在元数据仓库根底上开发数据产品，驱动数据管治施行。 通过数据业务化思路，咱们形象业务域、治理域、技术域等3大主题域来形容元数仓对象，并对每个主题域进行细分，划分多个主题： 业务元数据：基于具体业务逻辑元数据，常见业务元数据包含业务定义、业务术语、业务规定、业务指标等。技术元数据：形容了与数据仓库开发、治理和保护相干数据，包含数据源信息、数据仓库模型、数据荡涤与更新规定、数据映射和拜访权限等，次要为开发和治理数据仓库的工程师应用。治理元数据：形容治理畛域相干概念、关系和规定的数据，次要包含治理流程、人员组织、角色职责等信息。 在元数仓分层上，咱们采纳最常见的四层架构分层形式，别离是贴源层、明细层、汇总层、应用层和维度信息。区别于业务数仓分层设计形式，从明细层就按维度建模思路组织数据，防止适度设计，只须要做好主题划分和解耦。在汇总层从剖析习惯登程耦合数据，晋升易用性。应用层按需创立所需接口撑持利用。 目前，咱们已实现元数据仓库技术域、治理域、业务域局部内容的建设，并已撑持指标体系及下层多个数据利用，将来仍将依据大家在理论工作中外围关注的内容对元数仓进一步补充和欠缺。 4.2.2 指标体系建设一个问题的掂量须要从多方面进行思考，只用一个指标无奈充分说明问题，这就须要一组有逻辑且互相关联的数据指标来形容问题。在数据开发过程中，须要制订多个指标来监控掂量数据开发团队在品质、平安、效率、老本等方面存在的问题。 此前，住宿数据团队没有一套成熟稳固的指标体系，无奈长期精确掂量团队的业务反对能力、技术能力。2020年，咱们在元数据仓库根底上搭建了数据治理指标体系，全面掂量了业务数仓建设过程中各类问题，通过指标体系监测工作中的长处与有余，晋升了团队的工作能力，进而进步了对业务的反对能力。 建设计划 指标体系的建设指标是监控团队工作状态和变化趋势，须要可能笼罩到工作中的各个方面。因而，在指标体系的建设上，咱们通过不同视角对指标体系进行分类，做到不重不漏全笼罩，让指标实用于不同应用场景： 生命周期视角：从数据自身登程，掂量数据从生产到销毁的各个过程，包含定义、接入、解决、存储、应用、销毁等等。团队治理指标视角：依据团队治理外围要达成的指标分类，包含品质、效率、老本、平安、易用性、价值等等。问题对象视角：依据治理问题外围关注的对象分类，包含平安、资源、服务、架构、效率、价值、品质等等。 建设成绩 ...

在深度学习时代，算力的需要和耗费日益增长，如何升高算力老本，进步算力效率，逐步成为一个重要的新课题。智能算力旨在对流量算力进行精细化和个性化调配，从而实现零碎算力束缚下的业务收益最大化。本文次要介绍了美团外卖广告智能算力从线性规划算法到进化算法的技术演进过程，给出了一种基于进化算法的多动作算力调配计划，心愿能给大家带来一些帮忙或者启发。 1 业务背景随着美团外卖业务的飞速发展，外卖广告零碎压力变得越来越大，算力开始成为新的瓶颈。2021年上半年，外卖广告的数条业务线开始呈现算力资源有余的状况，算力调配效率亟待晋升。在外卖场景下，流量出现显著的双峰构造，广告零碎在顶峰时段面临较大的性能压力，非顶峰时段存在大量算力冗余。智能算力旨在对流量算力进行精细化和个性化调配，从而实现零碎算力束缚下的业务收益最大化。 本文是广告智能算力系列文章的第二篇，在第一期《美团外卖广告智能算力的摸索与实际》中[1]，咱们对阿里DCAF[2]线性规划求解计划进行了外卖场景下的优化，落地了弹性队列部分最优算力调配计划（以下简称“第一期”）。如上图所示，外卖展现广告链路中，召回通道和模型决策均应用固定策略，在算力有余时会失落局部优质流量带来的收益。 在本文中，咱们提出了基于进化算法的多动作算力决策办法ES-MACA（Evolutionary Strategies based Multi-Action Computation Allocation）。在外卖广告链路上，同时决策弹性通道、弹性队列和弹性模型三个动作。在后置动作决策中，咱们思考前置模块的决策引起的状态变动，同时应用多任务模型联结建模实现零碎仿真模仿（离线仿真+收益预估，实现不同决策动作下的收益评估性能），实现全链路最优算力调配。绝对第一期内容，ES-MACA在外卖展现广告业务线上获得CPM+1.x%、支出+1.x%的成果。 2 整体思路为了应答极大的在线流量压力和宏大的候选集，外卖广告投放零碎将整个检索过程设计成候选集顺次递加的漏斗型级联架构，次要蕴含召回、粗排、精排、机制等模块。在第一期中，咱们把算力调配的伎俩定义为弹性动作，并联合外卖场景演绎了弹性队列、弹性模型、弹性通道和弹性链路等四种动作，具体动作的定义如下： 弹性队列：线上检索是一个漏斗的过程，不同价值流量能够在级联漏斗的各模块中调配不同候选队列长度。弹性模型：在模型预估服务中，对于不同价值流量能够抉择不同大小模型，大模型绝对小模型预估成果更好的同时，耗费的算力也更多。弹性通道：在召回场景中，不同价值流量能够抉择不同复杂度的召回通道和召回通道的路数。弹性链路：在检索链路上，不同价值流量能够抉择不同复杂度的检索链路。2.1 算力调配问题形式化形容在一个蕴含M个算力决策模块的链路中，全链路最优的智能算力的指标可通用的形容为：通过智能化决策M个模块的算力档位，在整体算力满足束缚的条件下，使得整体流量收益最大化。 该问题的个别形式化形容为： 以上是多个算力决策模块的场景，在外卖展现广告中，对算力和收益较为敏感的决策模块为广告召回策略、精排队列长度和精排预估模型，别离对应弹性通道、弹性队列和弹性模型三个动作。 在本期中，咱们同时思考弹性通道、弹性队列和弹性模型三个模块的算力联结决策。 在多个模块联结决策时，同一个申请的不同模块动作之间相互会产生影响。如下图所示，弹性通道决策后果决定了实在召回队列（包含候选队列的长度和广告类型等信息），间接影响了弹性队列的输出状态。同理，弹性队列的决策后果影响了弹性模型的输出状态。因而，在多动作联结建模中，咱们减少了申请“状态”特色，让决策动作与零碎产生交互，更好地拟合零碎状态的过程。 2.2 挑战剖析外卖智能算力第一期中，咱们针对外卖广告场景，在DCAF计划的根底上进行了一系列摸索和改良，并首次进行了模型弹性调配的尝试，获得了不错的收益。近年，阿里CRAS[3]计划给出了一种利用于预排、粗排和精排队列联结优化的联结最优算力调配线性规划计划。从弹性动作的分类来看，该计划以一种优雅的形式解决了三个弹性队列的联结优化问题，CRAS通过一些数据分析和正当假如，将原始问题拆解为三个相互独立且类似子问题，而后别离对三个子问题进行求解。 然而已有计划是基于线性规划计划的，且仅关注一个或多个弹性队列优化问题，在面对非弹性队列动作组合，如弹性通道和弹性模型时，计划无奈间接迁徙。特地地，在约束条件或优化指标发生变化时，线性规划计划须要从新对特定业务问题进行建模和求解，需耗费大量的人力；此外，目前已有线性规划计划的问题建模和求解过程中往往蕴含一些业务数据相干的强假如，这些假如在新的业务上可能难以满足，这进一步使得已有计划难以拓展迁徙到新的业务问题上。 因为外卖场景的LBS限度，外卖广告的候选队列绝对非LBS电商场景较短，不须要通过简单的预排-粗排-精排的过程。在全链路上，咱们更关注召回通道、精排队列长度、精排预估模型等模块的算力调配，这些模块其实对算力更加敏感。 整体来看，美团外卖广告场景全链路最优算力调配的挑战次要包含以下两个方面。 通用化问题 挑战点：已有计划与业务耦合过重，一方面，在约束条件或优化指标发生变化时，线性规划计划须要从新对特定业务问题进行建模；另一方面，对特定的业务线，往往须要依据业务数据个性减少一些强假如。外卖广告目前包含十余条业务线，每条业务线中又存在多个算力决策场景，若对每条业务线的每个场景都独自建模，人力老本微小。应答思路：采纳通用解决方案并积淀为根底通用能力，为广告业务的不同算力决策场景赋能，降本增效。序列决策问题 挑战点：在全链路算力调配时，多个决策模块之间相互耦合，独特对影响以后流量的最终算力和收益。如下图所示，前置动作决策后，须要跟实在环境交互能力获取动作决策后的交互后果，模块之间波及到零碎状态转移，须要在最初一个决策模块实现决策后能力取得流量收益，这使得咱们难以通过惯例形式建模。 应答思路：在全链路最优算力调配问题建模过程中，减少零碎在各链路上的“状态”转移过程，后置模块依据前置模块的决策后果和申请状态进行决策。综合思考以上两个问题，咱们将外卖广告全链路最优算力调配问题建模为多阶段决策问题（每个决策模块对应一个决策阶段），按工夫程序顺次决策召回计划、截断队列和预估模型。每个阶段中，由Agent与环境交互和决策，Agent参数可应用进化算法或强化学习求解。 全链路算力调配过程可建模为马尔科夫决策过程（Markov Decision Process, MDP）或局部可观测马尔科夫决策过程（Partially Observable Markov Decision Process，POMDP）。如上图所示，状态转移产生在相邻的两个阶段之间，各阶段别离有不同的候选动作（如召回策略，截断长度和预估模型编号等），Reward则在最初一个阶段动作执行后通过零碎反馈取得。 咱们能够收集在线日志数据，应用离线强化学习（Offline RL）求解Agent；在不放心线上收益受损的状况下，也能够应用在线强化学习（Online RL）求解Agent。但因为业务场景简单，各阶段算力束缚难以对立，不论是离线强化学习还是在线强化学习，都面临多阶段强束缚难以建模和求解的问题。 而进化算法作为一种利用宽泛、鲁棒性强的全局优化办法，有以下长处： 防止部分最优：进化算法参数搜寻过程具备肯定的随机性，不易陷入部分最优；可并行化：进化算法参数搜寻过程可并行，可缓解评估过程耗时问题；利用宽泛：进化算法能够可能解决不间断、不可微和非凸优化问题，且不须要过多先验常识；简略易用：一些进化算法，比方穿插熵办法（Cross-Entropy Method，CEM）能够优雅地解决各种束缚问题，不须要间接求解束缚问题。进化算法能很好地解决外卖广告场景中的问题，既容易扩大到其余业务线，又能十分不便地建模各种决策问题。因而，本期咱们抉择进化算法来求解外卖场景全链路最优算力调配问题。在后续工作中，咱们会尝试应用强化学习计划求解。 如本节迭代门路（图）所示，咱们在1.5期中尝试了基于进化算法的单动作算力决策办法ES-SACA（Evolutionary Strategies based Single-Action Computation Allocation），验证了进化算法在算力调配场景的有效性。接下来，本文次要介绍基于进化算法的多动作算力决策办法ES-MACA。 3 方案设计为了实现广告零碎全链路上的最优算力调配，咱们设计了如下决策计划： 离线训练：随机抉择决策Agent参数，批量回放历史流量，Agent与广告投放模拟系统进行交互，实现状态转移过程。依据零碎返回的Reward优化决策Agent参数，最终输入离线最优Agent参数，并同步到线上。 在线决策：对于线上单条申请，应用离线最优Agent与线上零碎进行交互和决策。 在本期中，咱们应用进化算法求解Agent参数。进化算法参数寻优的外围是组合动作价值评估，因为波及到状态转移过程，组合动作价值评估不再是一个简略的监督学习问题，Agent须要顺次与零碎交互并执行决策动作，直到最初一个阶段的动作实现时能力从零碎中获得收益。一种简略的计划是让Agent在线学习，与零碎交互的同时优化本身参数，但在线学习会影响业务收益，这对咱们来说是不可承受的。为了解决这个问题，咱们通过结构广告投放模拟器，模仿线上广告零碎环境，由该模拟器与Agent进行交互，并反馈收益（Reward）。 3.1 全链路最优算力决策3.1.1 问题建模依据外卖广告的投放场景，咱们基于进化算法对整个问题建模如下： 状态：上下文特色，申请队列特色等（后置决策模块的状态依赖前置模块的决策，比方弹性通道的决策间接影响了弹性队列时队列长度）。动作：在不同阶段定义不同。 弹性通道：召回动作，一维向量 $(a_1, a_2, a_3, ...)$,$a_i \in \{0,1\}$ 示意是否该通道是否召回。弹性队列：截断长度，整数值。弹性模型：模型编号，整数值。Reward：收益指标为业务收益，为了保障求解参数合乎算力约束条件，在Reward中增加算力约束条件。对于越严格的约束条件，算力系数$\lambda_n$越大。3.1.2 离线参数求解 ...

常识图谱可视化能够更直观地查看和剖析常识图谱的数据。本文次要介绍了美团平台在布局策略、视觉降噪、交互性能、可视化叙事、3D图谱可视化等方面的一些实际和摸索，同时积淀出了uni-graph图可视化解决方案，并反对了美团的很多业务场景，包含美团大脑、图数据库、智能IT运维、组件依赖剖析、行业畛域图谱等。心愿能对从事常识图谱可视化方向的同学有所帮忙或启发。1 常识图谱可视化基本概念1.1 常识图谱技术的简介常识图谱（Knowledge Graph）是人工智能的重要分支，它是一种揭示实体之间关系的语义网络，能够对事实世界的事物及其互相关系进行形式化地形容。举个例子，“孙悟空的徒弟是唐僧”就是一条常识。在这条常识里，有“孙悟空”和“唐僧”两个实体，“徒弟”是形容这两个实体之间的关系，上述内容在常识图谱中就组成了一个SPO三元组（Subject-Predicate-Object）。 所以，对于事实世界中实体之间的关联关系，用常识图谱进行形容的话，就显得十分适合。正是因为常识图谱的这种劣势，这项技术失去迅速遍及，目前在搜寻、举荐、广告、问答等多个畛域都有相应的解决方案。 1.2 常识图谱可视化的简介可视化，简略来说就是将数据以一种更直观的模式体现进去。其实，咱们当初罕用的折线图、柱状图、饼状图（下称折柱饼），甚至Excel表格，都属于数据可视化的一种。 以往，咱们存储数据次要是以数据表的形式，但这种形式很难结构化地存储好常识类型的数据。对于关系类型的数据，如果用前文的例子为根底并补充一些相干信息，通过可视化后就能展现成这样： 这种信息就很难用“折柱饼”或者表格出现进去，而用常识图谱可视化的形式出现，就十分的清晰。 2 场景剖析与架构设计2.1 场景需要剖析咱们梳理后发现，在美团的各个业务场景中常识图谱可视化需要次要蕴含以下几类： 图查问利用：以图数据库为主的图谱可视化工具，提供图数据的编辑、子图摸索、顶点/边信息查问等交互操作。图剖析利用：对业务场景中的关系类数据进行可视化展现，帮忙业务同学疾速理解链路故障、组件依赖等问题。技术品牌建设：通过常识图谱向大家遍及人工智能技术是什么，以及它能做什么，让AI也具备可解释性。2.2 技术选型与架构设计在图关系可视化上，国内外有很多图可视化的框架，因为美团的业务场景中有很多个性化的需要和交互方式，所以抉择了D3.js作为根底框架，尽管它的上手老本更高一些，然而灵便度也比拟高，且性能拓展十分不便。D3.js提供了力导向图地位计算的根底算法，同时也有很不便的布局干涉伎俩。于是，咱们基于D3.js封装了本人的常识图谱可视化解决方案——uni-graph。 整体的性能与架构设计如下图所示，上面咱们会介绍一些uni-graph的性能细节和可视化的通用技术策略。 3 技术挑战与方案设计3.1 布局策略在不同类型的常识图谱中，因数据差别较大，对布局成果的要求也有所不同。能让业务数据有适合的布局来做可视化出现，是一项比拟大的技术挑战。除了上面几种根本的布局之外，咱们还摸索了一些特定场景下的布局计划。 提取数据特色优化布局D3.js提供的力导向图模块（d3-force）实现了一个velocity Verlet数值积分器，用于模仿粒子的物理静止。在不做过多干涉的状况下，会依据节点与边的关系模仿物理粒子的随机静止。D3.js的力导向图提供的力学调参项次要包含Centering（离心力）、Collision（碰撞检测）、Links（弹簧力）、Many-Body（电荷力）、Positioning（定位力）。 如何针对不同的节点进行适合的力学干涉，是让布局更合乎预期的要害。一般来讲，同一业务场景的图谱构造都具备肯定的相似性，咱们思考针对业务特定的数据结构特色来做定制化的力学调优。这里举一个简略的场景进行阐明，咱们形象出了在树中才有的层级和叶子节点的概念，尽管局部节点会相互成环，不满足树的定义，然而大部分数据是相似于树的构造，这样调试后，展现的关联关系就会比随机布局更加清晰，用户在寻找本人须要的数据时也会更快。 其实，美团的各个业务场景都有个性化定制布局的需要，这里只是拿其中一个最简略的场景进行阐明，uni-graph可能将力学参数调整的模块独立进去，并且梳理出一些罕用的参数预设，能够撑持很多场景的布局优化。 层级数据布局计划在很多业务场景中，用户更偏向于采纳分层的形式来察看图谱数据，因为这样有利于了解和剖析图谱数据，比方：依据用户摸索门路分层、边关系聚合分层、业务属性归类分层、指定中心点门路分层等等，这些需要对图谱的款式和布局模式提出了更高的要求。 得益于D3.js力学布局的灵活性和拓展能力，咱们在业务实际的过程中实现了几种罕用的布局计划： 以聚簇层布局为例，咱们简略介绍一下实现过程： 首先解决图谱数据，将核心节点关联的子节点按关联关系归类，生成聚簇边和聚簇边节点，同时将子节点分层。还须要自定义一种聚簇力，聚簇力蕴含三个参数ClusterCenter、Strength、Radius，对应聚簇核心、力的强度、聚簇半径。在力学初始化时，咱们为每个子节点定义聚簇核心节点和聚簇半径。最初在力学布局的Tick过程中，先计算子节点与其聚簇核心节点坐标偏移量，而后依据偏移量和聚簇半径的差值来判断节点的受力方向和大小，最终通过向量计算得出节点的坐标。布局参数配置化在特定畛域的图谱可视化中，通常采纳一两种布局即可满足用户的展现需要，因为这些场景下的图谱的关系构造绝对固定。但作为平台性质的工具，就须要展现多个畛域的图谱。为了更清晰地展现出各畛域图谱的特点，布局状态就须要追随图谱而变动。 针对这种场景，咱们实现了多项布局参数的配置化，用户能够依据畛域图谱的特点优化布局参数，并作为配置保留下来。 畛域图谱可视化-网格布局参数调整 图数据库可视化-布局款式参数调整 服务链路可视化-平铺层布局参数调整 3.2 视觉降噪在用户应用可视化利用时，文字/节点/边等元素内容混淆在一起，如果没有做好信息的表白和出现，会间接影响到用户的应用体验和应用效率。通过剖析，咱们发现这是因为在可视化过程中产生的视觉噪声太多，而通过可视化带来的无效信息太少。上面将举例展现什么叫做视觉噪声： 在以上几张图中，尽管将常识图谱的数据出现了进去，然而元素数量十分多，信息芜杂，给用户的观感是“目迷五色”。上面咱们会介绍针对这类问题的解决方案。 文字处理文字次要用在节点和边的形容上，尽管它能提供十分重要的信息，然而节点多了后，文字会在劫难逃的互相重叠，而重叠后的文字很难疾速辨认进去，不仅起不到传递信息的作用，反而会造成很差的视觉体验。为此，咱们须要对文字进行遮挡检测，依据文字的层叠关系，将置于底部的文字透明度调低，这样即便多层文字重叠后，置于顶层的文字仍然能被疾速辨认。 但这种解法的工夫复杂度会随着节点的增多逐步变得不可控。如果咱们有100个节点，最多须要O(n!)的工夫复杂度能力计算结束。咱们这里采纳栅格划分的形式来做优化，先对画布进行栅格划分，而后确定节点所在的一个或多个栅格，在进行碰撞检测的时候，只须要和本人同栅格的节点做比照即可，因为不同栅格内的节点肯定不会呈现碰撞的状况。 这种栅格划分的实践根底就是四叉树碰撞检测，咱们在此基础上做了进一步的优化。因为须要进行遮挡检测的元素是文字类型的节点，这种节点的特点是长比严惩很多。如果依照传统的四叉树宰割算法，就会造成很多文字节点横跨多个栅格，比照的次数较多。在检测前，咱们先计算出所有文字节点的均匀长宽比，每次栅格划分是横向还是纵向，取决于哪个方向划分后栅格的长宽比更凑近文字的均匀长宽比，这样做就会缩小文字节点横跨多个栅格的状况，从而缩小了每次须要被碰撞检测的节点数量。 边解决多边散列排布 常识图谱中存在蕴含大量出（入）边的核心节点，在对这些核心节点的边进行可视化展现时，往往会呈现边与核心节点联结处（Nexus）重叠交织在一起的状况，进而影响视觉体验。 针对这种非凡场景，咱们设计了一种多边散列排布的算法，通过边夹角偏移量计算和节点半径裁剪，将Nexus扩散排布在节点四周，缩小边线重叠的状况，以达到更清晰的视觉效果： 多类型可调节边 咱们还实现了多种类型的边，并反对通过参数配置的形式来调整边的款式，比方：贝塞尔曲线控制点、弧度、自旋角度等参数，以满足各种简单图谱的可视化场景。 通过多边散列排布，扭转边线类型，并调整款式参数，上面是咱们将图谱中凌乱无序的边线优化后的成果： 3.3 交互性能适合的图谱布局能更好地表白出数据的含意，通过视觉降噪能够进一步让图谱传递出更多的无效信息。然而用户仍然须要通过交互找到本人关怀的信息，一个图谱可视化工具是否好用，交互性能会起到十分重要的作用。目前，咱们实现了上面的根本交互性能： 画布操作：拖动、缩放、动静延展、布局变换、多节点圈选。元素(节点和边)操作：款式配置、悬浮高亮、元素锁定、单击、双击、右键菜单、折叠/开展、节点拖动、边类型更改。数据操作：节点的增删改查、边的增删改查、子图摸索、数据合并、更新重载。除了上述的根底交互性能外，咱们还摸索了一些非凡场景的交互。在图谱可视化中交互的目标，是为了从宏大的常识图谱中找到本人关怀数据的关联关系，同时也可能察看到这些关联关系在全局画布中的地位。 门路锁定通过选取不同的节点，主动计算出节点之间的适合门路，做锁定展示，不便察看两个或多个节点是如何关联起来的。 聚焦展示对于以后不关注的图谱区域，默认布局能够密集一些来节俭画布空间，关注某个区域后，会对以后关注的一小块区域从新布局，让节点排布扩散一些，不便查看文字的内容。 其实，无论可视化的节点与边的数量有多宏大，当深刻到业务细节中的时候，使用者关注的节点数量其实不多，重点是把使用者关怀的数据从大量数据中筛选进去，并且做好清晰地出现表白。 3.4 美团大脑可视化 美团大脑是围绕吃喝玩乐等多种场景，构建的生存娱乐畛域超大规模常识图谱，为用户和商家建设起全方位的链接。为了让美团大脑的能力更容易的被了解和应用，咱们须要通过常识图谱可视化的形式让美团大脑更具象化，并开发出便捷的常识图谱查问利用。 ...

针对视频数据，如何通过计算机视觉技术用相干数据，为用户和商家提供更好的服务，是一项重要的研发课题。本文将为大家分享短视频内容了解与生成技术在美团业务场景的落地实际。1. 背景美团围绕丰盛的本地生存服务电商场景，积攒了丰盛的视频数据。 美团场景下的短视频示例 视频链接 下面展现了美团业务场景下的一个菜品评论示例。能够看到，视频相较于文本和图像能够提供更加丰盛的信息，创意菜“冰与火之歌”中火焰与巧克力和冰淇淋的动静交互，通过短视频模式进行了活泼的出现，进而给商家和用户提供多元化的内容展现和生产指引。 视频行业倒退 咱们可能疾速进入了视频爆炸的时代，是因为多个技术畛域都获得了显著的提高，包含拍摄采集设施小型化、视频编解码技术的提高、网络通信技术的晋升等。近年来，因为视觉AI算法一直成熟，在视频场景中被广泛应用。本文将次要围绕如何通过视觉AI技术的加持，来进步视频内容创作生产和散发的效率。 美团AI——场景驱动技术 说到美团，大家首先会想到点外卖的场景，不过，除了外卖之外，美团还有其余200多项业务，涵盖了“吃”、“住”、“行”、“玩”等生存服务场景，以及“美团优选”“团好货”等批发电商。丰盛的业务场景带来了多样化的数据以及多元化的落地利用，进而驱动底层技术的翻新迭代。同时，底层技术的积淀，又能够赋能各业务的数字化、智能化降级，造成互相促进的正向循环。 美团业务场景短视频 本文分享的一些技术实际案例，次要围绕着“吃”来开展。美团在每个场景站位都有内容布局和展现模式，短视频技术在美团C端也有丰盛的利用，例如：大家关上公众点评App看到的首页Feed流视频卡片、沉迷态视频、视频笔记、用户评论、搜寻后果页等。这些视频内容在出现给用户之前，都要先通过了很多算法模型的了解和解决。 而在商家端（B端）的视频内容展现模式包含，景区介绍——让消费者在线上感触更平面的玩耍体验；酒店相册速览——将相册中的动态图像合成视频，全面地展现酒店信息，帮忙用户疾速理解酒店全貌（其中主动生成的技术会在下文2.2.2章节进行介绍）；商家品牌广告——算法能够通过智能剪辑等性能，升高商家编辑创作视频的门槛；商家视频相册——商家能够自行上传各类视频内容，算法为视频打上标签，帮忙商家治理视频；商品视频/动图——上文提到美团的业务范围也包含批发电商，这部分对于商品信息展现就十分有劣势。举个例子，生鲜类商品，如螃蟹、虾的静止信息很难通过动态图像出现，而通过动图可为用户提供更多商品参考信息。 短视频技术利用场景 从利用场景来看，短视频在线上的利用次要包含：内容经营治理、内容搜寻举荐、广告营销、创意生产。底层的撑持技术，次要能够分为两类：内容了解和内容生产。内容了解次要答复视频中什么工夫点，呈现什么样的内容的问题。内容生产通常建设在内容了解根底上，对视频素材进行加工解决。典型的技术包含，视频智能封面、智能剪辑。上面我将别离介绍这两类技术在美团场景下的实际。 2. 短视频内容了解和生成技术实际2.1 短视频内容了解2.1.1 视频标签 视频内容了解的次要指标是，概括视频中呈现的重要概念，关上视频内容的“黑盒”，让机器晓得盒子里有什么，为上游利用提供语义信息，以便更好地对视频做治理和散发。依据后果的模式，内容了解能够分为显式和隐式两种。其中，显式是指通过视频分类相干技术，给视频打上人能够了解的文本标签。隐式次要指以向量模式示意的嵌入特色，在举荐、搜寻等场景下与模型联合间接面向最终工作建模。能够粗略地了解为，前者次要面向人，后者次要面向机器学习算法。 显式的视频内容标签在很多场景下是必要的，例如：内容经营场景，经营人员须要依据标签，发展供需剖析，高价值内容圈选等工作。上图中展现的是内容了解为视频打标签的概要流程，这里的每个标签都是可供人了解的一个关键词。通常状况下，为了更好地保护和应用，大量标签会依据彼此之间的逻辑关系，组织成标签体系。 2.1.2 视频标签的不同维度与粒度 那么视频标签的利用场景有哪些？它背地的技术难点是什么？在美团场景下比拟有代表性的例子——美食探店视频，内容十分丰盛。标签体系的设定尤为要害，打什么样的标签来形容视频内容比拟适合？ 首先，标签的定义须要产品、经营、算法多方面的视角独特敲定。在该案例中，共有三层标签，越下层越形象。其中，主题标签对整体视频内容的概括能力较强，如美食探店主题；中间层会进一步拆分，形容拍摄场景相干内容，如店内、店外环境；最底层拆分成细粒度实体，了解到宫保鸡丁还是番茄炒鸡蛋的粒度。不同层的标签有不同的利用，最上层视频主题标签可利用于高价值内容的筛选及经营伎俩。它的次要难点是形象水平高，“美食探店”这个词概括水平很高，人在看过视频后能够了解，但从视觉特色建模的角度，须要具备什么特点能力算美食探店，对模型的学习能力提出了较大的挑战。 2.1.3 根底表征学习解决方案次要关注两方面：一方面是与标签无关的通用根底表征晋升，另一方面是面向特定标签的分类性能晋升。初始模型须要有比拟好根底表征能力，这部分不波及上游最终工作（例如：辨认是否是美食探店视频），而是模型权重的预训练。好的根底表征，对于上游工作的性能晋升事倍功半。 因为视频标签的标注代价十分低廉，技术计划层面须要思考的是：如何在尽量少用业务全监督标注数据的状况下学习更好的根底特色。首先，在工作无关的根底模型表征层面，咱们采纳了在美团视频数据上的自监督预训练特色，相比在公开数据集上的预训练模型，更加符合业务数据分布。 其次，在语义信息嵌入层面（如上图所示），存在多源含标签数据能够利用。值得一提的是，美团业务场景下比拟有特色的弱标注数据，例如：用户在餐厅中做点评，图片和视频下层形象标签是美食，评论文本中大概率会提到具体在店里吃的菜品名称，这是可开掘的优质监督信息，能够通过视觉文本相关性度量等技术手段进行荡涤。这里展现了主动挖掘出的标签为“烤肉”的视频样本。 视频样本视频样本 通过应用这部分数据做预训练，能够失去一个初始的Teacher Model，给业务场景无标注数据打上伪标签。这里比拟要害的是因为预测后果不齐全精确，须要基于分类置信度等信息做伪标签荡涤，随后拿到增量数据与Teacher Model一起做业务场景下更好的特色表白，迭代荡涤失去Student Model，作为上游工作的根底表征模型。在实践中，咱们发现数据迭代相较于模型构造的改良收益更大。 2.1.4 模型迭代 面向具体标签的性能晋升次要应答的问题是，如何在根底表征模型的根底上，高效迭代指标类别的样本数据，晋升标签分类模型的性能。样本的迭代分为离线和在线两局部，以美食探店标签为例，首先须要离线标注大量正样本，微调根底表征模型失去初始分类模型。这时模型的辨认准确率通常较低，但即便如此，对样本的荡涤、迭代也很有帮忙。构想如果标注员从存量样本池里漫无目的地筛选，可能看了成千盈百个视频都很难发现一个指标类别的样本，而通过初始模型做预筛选，能够每看几个视频就能筛出一个指标样本，对标注效率有显著的晋升。 第二步如何继续迭代更多线上样本，晋升标签分类模型准确率至关重要。咱们对于模型线上预测的后果分两条回流门路。线上模型预测后果十分相信，或是若干个模型认知统一，能够主动回流模型预测标签退出模型训练，对于高相信但谬误的噪声标签，能够通过模型训练过程中的一些抵制噪声的技术，如：相信学习进行主动剔除。更有价值的是，咱们在实践中发现对于模型性能晋升ROI更高的是人工修改模型非相信数据，例如三个模型预测后果差别较大的样本，筛出后交给人工确认。这种被动学习的形式，能够防止在大量简略样本上节约标注人力，针对性地裁减对模型性能晋升更有价值的标注数据。 2.1.5 视频主题标签利用——高价值内容筛选聚合 上图展现了点评举荐业务视觉主题标签的利用案例，最具代表性的即为高价值内容的圈选：在点评App首页信息流的达人探店Tab中，经营同学通过标签筛选出有「美食探店」标签的视频进行展现。能够让用户以沉迷式地体验形式更全面地理解到店内的信息，同时也为商家提供了一个很好的窗口，起到宣传引流的作用。 2.1.6 视频标签的不同维度与粒度 上图展现了，不同维度标签对于技术有不同要求，其中细粒度实体了解，须要辨认具体是哪道菜，与下层粗粒度标签的问题不同，须要思考如何应答技术挑战。首先是细粒度辨认工作，须要对视觉特色进行更精密的建模；其次，视频中的菜品了解相较于单张图像中的菜品辨认更有挑战，须要应答数据的跨域问题。 2.1.7 菜品图像识别能力向视频畛域的迁徙 形象出关键问题后，咱们来别离应答。首先在细粒度辨认问题上，菜品的视觉相似性度量挑战在于不同食材的特色及地位关系没有标准化的定义，同一道菜不同的徒弟很可能做出两种齐全不同的样子。这就须要模型既可能聚焦部分细粒度特色，又可能交融全局信息进行判断。为了解决这个问题，咱们提出了一种重叠式全局-部分注意力网络，同时捕获形态纹理线索和部分的食材差别，对菜品辨认成果有显著晋升，相干成绩发表在ACM MM国内会议上（ISIA Food-500: A Dataset for Large-Scale Food Recognition via Stacked Global-Local Attention Network）。 上图（）中展现的是第二局部的挑战。图像和视频帧中的雷同物体经常有着不同的外观体现，例如：图片中的螃蟹经常是煮熟了摆在盘中，而视频帧中经常出现烹饪过程中鲜活的螃蟹，它们在视觉层面差异很大。咱们次要从数据分布的角度去应答这部分跨域差别。 业务场景积攒了大量有标注的美食图像，这些样本预测后果的判断性通常较好，但因为数据分布差别，视频帧中的螃蟹则不能被很确信地预测。对此咱们心愿晋升视频帧场景中预测后果的判断性。一方面，利用核范数最大化的办法，获取更好的预测散布。另一方面，利用常识蒸馏的形式，一直通过弱小的模型来领导轻量化网络的预测。再联合视频帧数据的半自动标注，即可在视频场景下取得较好的性能。 2.1.8 细粒度菜品图像识别能力 ...

美团机器学习平台基于外部深度定制的TensorFlow研发了Booster GPU训练架构。该架构在整体设计上充分考虑了算法、架构、新硬件的个性，从数据、计算、通信等多个角度进行了深度的优化，最终其性价比达到CPU工作的2~4倍。本文次要讲述Booster架构的设计实现、性能优化及业务落地工作，心愿能对从事相干开发的同学有所帮忙或者启发。1 背景在举荐零碎训练场景中，美团外部深度定制的TenorFlow（简称TF）版本[1]，通过CPU算力撑持了美团外部大量的业务。但随着业务的倒退，模型单次训练的样本量越来越多，构造也变得越来越简单。以美团外卖举荐的精排模型为例，单次训练的样本量已达百亿甚至千亿，一次试验要消耗上千核，且优化后的训练任务CPU使用率已达90%以上。为了反对业务的高速倒退，模型迭代试验的频次和并发度都在一直减少，进一步减少了算力应用需要。在估算无限的前提下，如何以较高的性价比来实现高速的模型训练，从而保障高效率的模型研发迭代，是咱们迫切需要解决的问题。 近几年，GPU服务器的硬件能力突飞猛进，新一代的NVIDIA A100 80GB SXM GPU服务器（8卡）[2]，在存储方面能够做到：显存640GB、内存1~2TB、SSD10+TB，在通信方面能够做到：卡间双向通信600GB/s、多机通信800~1000Gbps/s，在算力方面能够做到：GPU 1248TFLOPS（TF32 Tensor Cores），CPU 96~128物理核。如果训练架构能充分发挥新硬件的劣势，模型训练的老本将会大大降低。但TensorFlow社区在举荐零碎训练场景中，并没有高效和成熟的解决方案。咱们也尝试应用优化后的TensorFlow CPU Parameter Server[3]（简称PS）+GPU Worker的模式进行训练，但其只对简单模型有肯定的收益。NVIDIA开源的HugeCTR[4]尽管在经典的深度学习模型上性能体现优异，但要在美团的生产环境间接应用起来，还须要做较多的工作。 美团根底研发机器学习平台训练引擎团队，联结到家搜推技术部算法效力团队、NVIDIA DevTech团队，成立了联结项目组。在美团外部深度定制的TenorFlow以及NVIDIA HugeCTR的根底上，研发了举荐零碎场景的高性能GPU训练架构Booster。目前在美团外卖举荐场景中进行了部署，多代模型全面对齐算法的离线成果，比照之前，优化后的CPU工作，性价比晋升了2~4倍。因为Booster对原生TensorFlow接口有较好的兼容性，原TensorFlow CPU工作只须要一行代码就可实现迁徙。这样让Booster能够疾速在美团多条业务线上进行初步验证，相比之前的CPU工作，均匀性价比都晋升到2倍以上。本文将重点介绍Booster架构的设计与优化，以及在美团外卖举荐场景落地的全过程，心愿能对大家有所帮忙或启发。 2 GPU训练优化挑战GPU训练在美团内曾经广泛应用到CV、NLP、ASR等场景的深度学习模型，但在举荐零碎场景中，却迟迟没有失去大规模的利用，这跟场景的模型特点、GPU服务器的硬件特点都有较强的关系。 举荐零碎深度学习模型特点 读取样本量大：训练样本在几十TB~几百TB，而CV等场景通常在几百GB以内。模型参数量大：同时有大规模稠密参数和浓密参数，须要几百GB甚至上TB存储，而CV等场景模型次要是浓密参数，通常在几十GB以内。模型计算复杂度绝对低一些：举荐零碎模型在GPU上单步执行只须要10~100ms，而CV模型在GPU上单步执行是100~500ms，NLP模型在GPU上单步执行是500ms~1s。GPU服务器特点 GPU卡算力很强，但显存仍无限：如果要充分发挥GPU算力，须要把GPU计算用到的各种数据提前搁置到显存中。而从16年~20年，NVIDIA Tesla GPU卡[5]计算能力晋升了10倍以上，但显存大小只晋升了3倍左右。其它维度资源并不是很短缺：相比GPU算力的晋升速度，单机的CPU、网络带宽的增长速度较慢，如果遇到这两类资源workload较重的模型，将无奈充分发挥GPU的能力，GPU服务器相比CPU服务器的性价比不会太高。总结来说，CV、NLP等场景的模型训练属于计算密集型工作，而且大多模型单张卡的显存都能够装下，这和GPU服务器的劣势十分好地进行了匹配。但在举荐零碎场景中，因为模型绝对没有那么简单，远端读取的样本量大，特色解决消耗CPU多，给单机CPU和网络带来较大的压力。同时面对模型参数量大的状况，单机的GPU显存是无奈放下的。这些GPU服务器的劣势，恰好都被举荐零碎场景命中。 好在NVIDIA A100 GPU服务器，在硬件上的降级补救了显存、CPU、带宽这些短板，但如果零碎实现和优化不当，仍然不会有太高的性价比收益。在落地Booster架构的过程中，咱们次要面临如下挑战： 数据流零碎：如何利用好多网卡、多路CPU，实现高性能的数据流水线，让数据的供应能够跟上GPU的生产速度。混合参数计算：对于大规模稠密参数，GPU显存间接装不下的状况，如何充分利用GPU高算力、GPU卡间的高带宽，实现一套大规模稠密参数的计算，同时还须要兼顾浓密参数的计算。3 零碎设计与实现面对下面的挑战，如果纯从零碎的的角度去设计，难度较大。Booster采纳了“算法+零碎”Co-design的设计思路，让这代零碎的设计大大失去简化。在系统实施门路上，思考到业务预期交付工夫、施行危险，咱们并没有一步到位落地Booster的多机多卡版本，而是第一版先落地了GPU单机多卡版本，本文重点介绍的也是单机多卡的工作。另外，依靠于NVIDIA A100 GPU服务器弱小的计算能力，单机的算力能够满足美团绝大多数业务的单次试验需要。 3.1 参数规模的合理化大规模稠密离散特色的应用，导致深度预估模型的Embedding参数量急剧收缩，数TB大小的模型一度风行于业界推搜的各大头部业务场景。然而业界很快意识到，在硬件老本无限的状况下，过于宏大的模型给生产部署运维和试验迭代翻新削减了惨重的累赘。学术研究表明[10-13]，模型成果强依赖于模型的信息容量，并非参数量。实践证明，前者能够通过模型构造的优化来进行晋升，而后者在保障成果的前提下，尚存有很大的优化空间。Facebook在2020年提出了Compositional Embedding[14]，实现举荐模型参数规模数个量级的压缩。阿里巴巴也发表了相干工作[15]，将外围业务场景的预估模型由数TB压缩至几十GB甚至更小。总的来看，业界的做法次要有以下几种思路： 去穿插特色：穿插特色由单特色间做笛卡尔积产生，这会生成微小的特色ID取值空间和对应Embedding参数表。深度预估模型倒退至今，曾经有大量的办法通过模型构造来建模单特色间的交互，防止了穿插特色造成的Embedding规模收缩，如FM系列[16]、AutoInt[17]、CAN[18]等。精简特色：特地是基于NAS的思路，以较低的训练老本实现深度神经网络自适应特征选择，如Dropout Rank[19]和FSCD[20]等工作。压缩Embedding向量数：对特色取值进行复合ID编码和Embedding映射，以远小于特色取值空间的Embedding向量数，来实现丰盛的特色Embedding表白，如Compositional Embedding[14]、Binary Code Hash Embedding[21]等工作。压缩Embedding向量维度：一个特色Embedding向量的维度决定了其表征信息的下限，然而并非所有的特色取值都有那么大的信息量，须要Embedding表白。因而，能够每一个特征值自适应的学习精简Embedding维度，从而压缩参数总量，如AutoDim[22]和AMTL[23]等工作。量化压缩：应用半精度甚至int8等更激进的形式，对模型参数做量化压缩，如DPQ[24]和MGQE[25]。美团外卖举荐的模型一度达到100G以上，通过利用以上计划，咱们在模型预估精度损失可控的前提下，将模型管制在10GB以下。 基于这个算法根底假如，咱们将第一阶段的设计指标定义到反对100G以下的参数规模。这能够比拟好的适配A100的显存，寄存在单机多卡上，GPU卡间双向带宽600GB/s，能够充分发挥GPU的解决能力，同时也能够满足美团大多数模型的需要。 3.2 零碎架构基于GPU零碎的架构设计，要充分考虑硬件的个性能力充分发挥性能的劣势。咱们NVIDIA A100服务器的硬件拓扑和NVIDIA DGX A100[6]比拟相似，每台服务器蕴含：2颗CPU，8张GPU，8张网卡。Booster架构的架构图如下所示： 整个零碎次要包含三个外围模块：数据模块，计算模块，通信模块： 数据模块：美团自研了一套反对多数据源、多框架的数据散发零碎，在GPU零碎上，咱们革新数据模块反对了多网卡数据下载，以及思考到NUMA Awareness的个性，在每颗CPU上都部署了一个数据散发服务。计算模块：每张GPU卡启动一个TensorFlow训练过程执行训练。通信模块：咱们应用了Horovod[7]来做分布式训练的卡间通信，咱们在每个节点上启动一个Horovod过程来执行对应的通信工作。上述的设计，合乎TensorFlow和Horovod原生的设计范式。几个外围模块能够互相解耦，独立迭代，而且如果合并开源社区的最新个性，也不会对系统造成架构性的冲击。 咱们再来看一下整个零碎的简要执行流程，每张GPU卡上启动的TensorFlow过程外部的执行逻辑如下图： 整个训练流程波及参数存储、优化器、卡间通信等几个要害模块。对于样本的输出特色，咱们分为稠密特色（ID类特色）和浓密特色。在理论业务场景中，稠密特色通常IDs总量较多，对应的稠密参数应用HashTable数据结构存储更适合，而且因为参数量较大，GPU单卡显寄存不下，咱们会通过ID Modulo的形式Partition到多张GPU卡的显存中寄存。对于IDs总量较少的稠密特色，业务通常应用多维矩阵数据结构表白（在TensorFlow外面的数据结构是Variable），因为参数量不大，GPU单卡显存能够放下，咱们应用Replica的形式，每张GPU卡的显存都搁置一份参数。对于浓密参数，通常应用Variable数据结构，以Replica的形式搁置到GPU显存中。下边将具体介绍Booster架构的外部实现。 3.3 要害实现3.3.1 参数存储早在CPU场景的PS架构下，咱们就实现了大规模稠密参数的整套逻辑，当初要把这套逻辑搬到GPU上，首先要实现的就是GPU版本的HashTable。咱们调研了业界多种GPU HashTable的实现，如cuDF、cuDPP、cuCollections、WarpCore等，最终抉择了基于cuCollections实现TensorFlow版本的GPUHashTable。究其原因，次要是因为理论业务场景中，大规模稠密特色的总量通常是未知的，并且随时可能呈现特色穿插，从而以致稠密特色的总量变化很大，这就导致“动静扩容”能力将成为咱们GPU HashTable的必备性能，可能做到动静扩容的只有cuCollections的实现。咱们在cuCollections的GPU HashTable根底上实现了非凡接口（find\_or\_insert），对大规模读写性能进行了优化，而后封装到了TensorFlow中，并在其上实现了低频过滤的性能，能力上对齐CPU版本的稠密参数存储模块。 3.3.2 优化器目前，稠密参数的优化器与浓密参数的优化器并不兼容，咱们在GPU HashTable的根底上，实现了多种稠密优化器，并且都做了优化器动量Fusion等性能，次要实现了Adam、Adagrad、FTRL、Momentum等优化器。对理论业务场景来说，这些优化器曾经可能笼罩到绝大多数业务的应用。浓密局部参数能够间接应用TensorFlow原生反对的稠密/浓密优化器。 3.3.2 卡间通信理论训练期间，对于不同类型的特色，咱们的解决流程也有所不同： 稠密特色（ID类特色，规模较大，应用HashTable存储）：因为每张卡的输出样本数据不同，因而输出的稠密特色对应的特征向量，可能寄存在其余GPU卡上。具体流程上，训练的前向咱们通过卡间AllToAll通信，将每张卡的ID特色以Modulo的形式Partition到其余卡中，每张卡再去卡内的GPUHashTable查问稠密特征向量，而后再通过卡间AllToAll通信，将第一次AllToAll从其余卡上拿到的ID特色以及对应的特征向量原路返回，通过两次卡间AllToAll通信，每张卡样本输出的ID特色都拿到对应的特征向量。训练的反向则会再次通过卡间AllToAll通信，将稠密参数的梯度以Modulo的形式Partition到其余卡中，每张卡拿到本人的稠密梯度后再执行稠密优化器，实现大规模稠密特色的优化。具体流程如下图所示： ...

Twins 是美团和阿德莱德大学单干提出的视觉注意力模型，相干论文已被 NeurIPS 2021 会议接管。本文次要讲述 Twins 解决的难点、设计和实现思路，以及在美团场景的摸索落地，心愿能对从事视觉算法研发的同学有所帮忙和启发。概要Twins [1] 是美团和阿德莱德大学单干提出的视觉注意力模型，相干论文已被 NeurIPS 2021 会议接管，代码也已在GitHub上进行开源。NeurIPS（Conference on Neural Information Processing Systems）是机器学习和计算神经科学相干的学术会议，也是人工智能方向的国内顶级会议。 Twins 提出了两类构造，别离是 Twins-PCPVT 和 Twins-SVT： Twins-PCPVT 将金字塔 Transformer 模型 PVT [2] 中的固定地位编码（Positional Encoding）更改为团队在 CPVT [3] 中提出的条件式地位编码 （Coditional Position Encoding, CPE），从而使得模型具备平移等变性（即输出图像产生平移后，输入同时相应发生变化），能够灵活处理来自不同空间尺度的特色，从而可能广泛应用于图像宰割、检测等变长输出的场景。Twins-SVT 提出了空间可拆散自注意力机制（Spatially Separable Self-Attention，SSSA）来对图像特色的空间维度进行分组，别离计算各部分空间的自注意力，再利用全局自注意力机制对其进行交融。这种机制在计算上更高效，性能更优。Twins 系列模型实现简略，部署敌对，在 ImageNet 分类、ADE20K 语义宰割、COCO 指标检测等多个经典视觉工作中均获得了业界当先的后果。 背景2020 年 9 月，谷歌的视觉注意力模型 （Vision Transformer， ViT） [4] 胜利将本来用于自然语言解决的 Transformer [5] 利用到视觉的分类工作中。ViT 将一幅输出图像切分为若干个图像块（Patch），并把一个图像块类比为一个文字（Word）作为 Transformer 编码器的输出（如图 1 所示），通过 L 层的编码器解决后应用一般的多层感知机（Multilayer Perceptron, MLP）映射到类别空间。ViT 的模型性能大幅超过了卷积神经网络，尔后迅速倒退成为了以后视觉畛域钻研的次要热点。 ![图1 视觉注意力模型（ViT）将用于自然语言解决工作的 Transformer 利用于视觉工作（起源：ViT [4]）](https://p1.meituan.net/travel...) ...

随着人工智能的一直倒退，平安及合规问题变得越来越重要。以后机器学习比拟大的一个局限性在于其学习模型都是基于关联框架，这种框架存在样本抉择偏差的问题，且其稳定性也较差。而因果推理模型的呈现，给机器学习关上了一个新的思路。美团技术团队特地邀请到清华大学计算机学院长聘副教授崔鹏老师，请他为美团技术团队的同学分享了因果推断技术最新的发展趋势，以及现阶段获得的一些成绩。| 分享嘉宾：崔鹏，清华大学计算机系长聘副教授，博士生导师 | 钻研趣味聚焦于大数据驱动的因果推理和稳固预测、大规模网络表征学习等。在数据挖掘及人工智能畛域顶级国内会议发表论文100余篇，先后5次取得顶级国内会议或期刊论文奖，并先后两次入选数据挖掘畛域顶级国内会议KDD最佳论文专刊。负责IEEE TKDE、ACM TOMM、ACM TIST、IEEE TBD等国内顶级期刊编委。曾取得国家自然科学二等奖、教育部自然科学一等奖、电子学会自然科学一等奖、北京市科技进步一等奖、中国计算机学会青年科学家奖、国内计算机协会（ACM）卓越科学家。 背景预计将来十到二十年内，人工智能会在很多危险敏感性的畛域失去更加宽泛的利用，包含医疗、司法、生产、金融科技等等。之前，人工智能大部分是利用在互联网之上，而互联网是一个危险不敏感的畛域，不过随着这两年各种法律法规的出台，让各大互联网平台处在了「风口浪尖」，越来越多的人开始看到互联网中各种潜在的危险，并且还面临着被宏观政策调控的危险。因而，从这个层面上来讲，人工智能技术所带来的危险亟待被关注。 对人工智能危险的防控，堪称「只知其然，不知其所以然」。大家晓得怎么去做预测，但很难去答复「Why」，比方为什么要做这样的决策？什么时候能够置信零碎的判断？很多问题的模型咱们都无奈给出一个绝对精确的答案。这样的话，就会带来一系列的问题。首先是不可解释性，这也导致了「人机协同」模式很难在事实世界中落地，比方人工智能技术很难利用于医疗行业，因为医生不晓得零碎判断的根据是什么，所以目前人工智能技术在落地时有很大的局限性。第二，以后支流的人工智能办法基于独立同散布的假如，这要求模型的训练集数据和测试集数据来自同一散布，而在理论利用中，很难保障模型会被利用于什么样的数据中，因为模型最终的性能取决于训练集和测试集散布的拟合度有多高。第三，人工智能技术在利用于社会性问题时会引入公平性危险，比方在美国，支出、教育等背景完全一致的两个人，零碎判断黑人的犯罪率可能是白人的十倍。最初是不可回溯性，无奈通过调整输出来获取想要的输入，因为推理和预测的过程是不可回溯的。 而呈现以上问题的次要本源在于：以后人工智能是基于关联的框架。在基于关联的框架下，能够得出支出-犯罪率和肤色-犯罪率都是强关联关系。而在基于因果的框架下，当咱们须要判断某个变量T对输入Y是否有因果成果时，不是间接度量T和Y的关联关系，而是在管制住X的状况上来看T和Y之间的关联关系。比方，在两组对照组中X（收入水平）是散布是一样的（要么都有钱，要么都没钱），而后再通过调整T（肤色）去察看两组的Y（犯罪率）是否会有显著的差别，而后咱们会发现黑人和白人的犯罪率并没有显著性的差别。那么，为什么在基于关联的框架中会得出肤色与犯罪率是强关联关系呢？这是因为大部分黑人的支出都比拟低，从而导致整体的犯罪率偏高，但这并不是由肤色导致的。 究其基本，问题并不是出在关联模型上，而是出在如何应用机器学习的形式上。总的来说，产生关联一共有三种形式，第一种是因果机制，因果关系是稳固、可解释且可回溯的。第二种是混同效应，如果X同时导致了T和Y，T和Y之间就会产生虚伪关联。第三种是样本抉择偏差。比方在狗和草地的案例中，当更换了沙滩环境之后，模型无奈辨认出狗，这是因为咱们抉择了大量草地环境下的狗作为样本，所以模型会认为狗和草地之间存在关联关系，这也是一种虚伪关联。 在以上三种形式中，除了因果关系产生的关联关系是靠谱的，其余两种形式产生的关联都不太靠谱。但目前的机器学习畛域并没有辨别这三种产生关联的形式，其中存在着很多的虚伪关联，这就导致了模型的可解释性、稳定性、公平性、可回溯性都存在肯定的问题。如果想要从根本上冲破以后机器学习的局限性，就须要用一种更严格的统计逻辑，比方应用因果统计去代替原来的关联统计。 把因果推理利用到机器学习层面面临着很多挑战，因为因果推理本来钻研的范畴次要是在统计畛域（包含哲学领域），这些畛域所面向的环境都是小数据的管制环境，整个数据的产生过程是可控的。比方一个检测疫苗是否无效的行为学试验，咱们能够管制哪些人打疫苗，哪些人不打疫苗。然而在机器学习中，数据的产生过程是不可控的。在一个大数据的观测钻研中，咱们须要思考大数据的高维、高噪声、弱先验性等因素，数据的产生过程是不可知的，这些对传统的因果推理框架都带来了十分大的挑战。另外，因果推理和机器学习的指标也存在很大的区别：因果推理须要去了解数据的产生机制，而机器学习（包含在互联网畛域的很多的利用）次要是去预知将来到底会产生什么样的变动。 那么，怎么去弥合因果推理和机器学习之间的鸿沟呢？咱们提出了一个因果启发的学习推理和决策评估的一套办法体系。第一个要解决问题的是如何在大规模数据中辨认出其中的因果构造。第二个要解决的问题是在有了因果构造后怎么去和机器学习做交融，当初的因果启发的稳固学习模型、偏心无偏见的学习模型都是以此为指标。第三个要解决的问题是从预测问题进一步到设计决策机制，怎么利用这些因果构造去帮忙咱们做决策上的优化，也就是反事实推理和决策优化机制。 因果推理的两个根本范式构造因果模型 因果推理有两个根本范式。第一种范式是构造因果模型（Structure Causal Model），这个框架的外围是怎么在一个已知的因果图中去做推理。比方怎么去辨认其中的任意一个变量，这个变量对另一个变量的影响水平是多少。目前已有较为成熟的判断准则如后门准则（Back Door）、前门准则（Front Door）等去除其中的混同，通过Do-Calculus形式进行因果预计（Causal Estimation）。目前这种办法面对的外围问题是咱们无奈在做观测钻研时定义因果图，尽管在一些畛域（比方考古）能够通过专家常识来定义因果图，但这就又走到了“专家系统”的老路上。总的来说，外围问题还是怎么去发现因果构造。 这里有一个衍生技术是因果发现（Causal Discovery），能够基于条件独立性检测和现有的数据去定义因果图，应用现有的变量去频繁地做条件独立性等一系列的独立性判断来定义因果图，这是一个NP问题，可能会呈现组合爆炸的问题。这是构造因果模型利用于大规模数据时所面临的一个瓶颈，最近也有一些钻研比方应用可微分因果发现去解决这个问题。 潜在后果框架第二种范式是潜在后果框架（Potential Outcome Framework），这个框架的外围是不须要晓得所有变量的因果构造，而只须要晓得其中一个变量对于输入是否有因果影响，对于其余变量之间的影响不在意，但咱们须要晓得这个变量和输入之间有哪些烦扰因素（Confounders），并假如其中所有的烦扰因素都曾经被观测到。 以上就是一些背景常识和实践方面的介绍。接下来，次要讲一下咱们最近的一些思考和尝试，以及如何把这两个范式联合到具体的问题中去。 可微分因果发现以及在举荐零碎中的利用因果发现和问题定义因果发现的定义是对于给定的一组样本，其中每个样本都由一些变量去表征，咱们心愿通过一些可观测数据去找到这些变量之间的因果构造。找到的因果图，能够认为是一个图模型，从生成式模型的角度来讲，咱们心愿找到一个因果图使得它可能依照其中的因果构造去生成这样的一组样本，这组样本的似然性是最高的。 这里引入一个叫做Functional Causal Model(FCMs)的概念，所谓的FCM就是，对于某一类变量X，因为因果图是一个有向无环图（DAG），这个变量肯定有它的父节点，那它的值肯定是由它所有的父节点通过一个函数的作用再加上噪声来生成的。比方在线性框架下，这个问题就变成：怎么找到一组W，使得X的重构是最优的。 有向无环图的优化始终是一个开放性问题，2018年的一篇论文[1]提出来了一个优化办法：能够在全空间的有向无环图内去做梯度优化，通过减少DAG限度和稠密限度（l1或l2正则），使得最终X的重构误差最小。 咱们在具体实施这个框架时发现了一些问题，这个框架的根本假如是所有变量的噪声必须是高斯分布，且噪声的规模应该差不多，如果不满足这个假如就会呈现一些问题，比方说领有最小重构误差的构造可能并不是实在值（Ground Truth），这是可微分因果发现办法的一个局限性。咱们能够通过施加一个独立性限度去解决这个问题，把独立性判断准则转化为可优化的模式去进行优化。具体的实现细节在这里不再赘述，感兴趣的同学能够浏览论文[2]。 可微分因果发现在举荐零碎中的利用整个举荐零碎存在I.I.D（Independent and Identically Distributed, 独立同散布）的假如，也就是说用户和物品的训练集、测试集须要来自同一个散布，但实际上举荐零碎中存在各种各样的OOD（Out Of Distribution，散布外）问题。第一种是天然偏移（Natural Shift），比方基于北京、上海的数据训练失去的模型，在面向重庆的用户时就不肯定无效。第二种是由举荐零碎机制引起的非天然偏移（Artificial Shift）。 咱们心愿能提出一种比拟通用的形式，去抵制举荐零碎中存在的各种OOD问题或者偏差问题的举荐算法。针对这个问题，咱们也做了一些钻研工作[3]。在OOD举荐零碎中存在一个不变性假如——一个人看到了一个商品后是否购买是不会随着环境变动而扭转的。因而只有保障用户对物品的偏好不变，就能够使得这样的不变性假如成立，从而给出比拟正当的举荐后果，这是解决OOD问题的外围。 如何保障用户偏好是不变的？有一个根本共识是，不变性和因果关系是存在某种等价性的转化关系的。如果能够保障一个构造在各种各样的环境下都具备等同的预测效应，那么这个构造肯定是一个因果构造，而且一个因果构造在各种环境下的性能都是绝对稳固的。因而，找到不变的用户偏好，就转化为一个因果偏好学习的问题。在举荐零碎中有一个非凡的构造叫做二部图，咱们须要基于这样的非凡构造去设计因果发现的办法。在这个最终学到的模型中，只须要输出用户的表征，就能够晓得这个用户会喜爱什么样的物品。 很显然，这种办法对于晋升举荐零碎的可解释性、透明性以及稳定性都会肯定的益处，咱们也和很多的办法进行了比照，能够看到，它都有比拟显著的性能晋升。 对于OOD泛化和稳固学习的一些思考OOD问题是机器学习中一个十分根本的问题，之前做的基本上都是基于I.I.D.的假如，尽管迁徙学习做了自适应，但因为迁徙学习假如测试集是已知的，所以它的主体还是I.I.D.的实践框架。咱们从2018年开始在OOD这个方向做了一些钻研，首先，OOD的定义是训练集和测试集不是来自同一个散布，如果训练集和测试集来自同一个散布那么就是I.I.D.。OOD又可分为两种状况，如果测试集的散布是已知或局部已知的，就是OOD Adaptation，也就是迁徙学习/畛域自适应。如果测试集的散布未知，才是真正的OOD泛化问题。 这里的「泛化」和机器学习中的「泛化」概念有所不同。机器学习中的「泛化」更多的是在谈内插问题，训练数据外部的插值问题都是「内插」问题，如果要对超出了插值域的X进行预测就是「外插」问题。「外插」是一件比拟危险的事件，在什么状况下能够做「外插」呢？如果可能找到其中的不变性（invariance），就能够做「外插」这件事件。 以前在做机器学习的时候，都是在做I.I.D.也就是数据拟合，只须要避免过拟合/欠拟合就好了。而当初如果要解决OOD问题，就要找到其中的不变性。找到不变性有两个门路，第一个门路是因果推断，因果关系和不变性之间存在等价性，也就是说只有找到了因果构造就能够保障不变性，实际上因果推断自身就是对于不变性的迷信。稳固学习，在某种程度上就是心愿模型在做学习和预测时是基于因果推断的。咱们发现，通过对样本进行重加权就能够使得所有的变量变得独立，使得一个基于关联的模型变成基于因果的模型，大家如果感兴趣的话，能够去看看相干的论文。 第二个门路是从差异性中找到不变性。在统计中有一个概念是异质性，比方说一个狗的散布有两个峰，一个峰是沙滩上的狗，一个峰是草地上的狗，既然这两个峰都代表狗，那么其中肯定存在着不变性，不变的那局部就具备OOD泛化能力。数据的异质性是不能被预约义的，咱们心愿通过数据驱动的形式去找到其中隐含的异质性，在隐含的异质性中找到其中的不变性，而这二者的学习是互相促进的。 所谓的稳固学习，就是应用一种散布的训练集和多种不同的未知散布的测试集，优化的指标是最小化准确率的方差。也就是说假如有一个训练散布，它外在具备肯定的异质性，但没有对它的异质性进行人为的划分，在这种状况下咱们心愿学出一个可能在各种未知散布下有较好性能体现的模型。咱们在去年写了一篇对于OOD泛化的Survery[4]，对这个问题做了比拟零碎的剖析，感兴趣的同学能够进行参考。 参考文献[1] Zheng, Xun, Bryon Aragam,Pradeep K. Ravikumar, and Eric P. Xing. DAGs with NO TEARS: Continuous Optimization for Structure Learning. Advances in Neural Information Processing Systems 31 (2018).[2] Yue He, Peng Cui, et al. DARING: Differentiable Causal Discovery with Residual Independence. KDD, 2021.[3] Yue He, Zimu Wang, Peng Cui, Hao Zou, Yafeng Zhang, Qiang Cui, Yong Jiang. CausPref: Causal Preference Learning for Out-of-Distribution Recommendation. The WebConf, 2022.[4] Zheyan Shen, Jiashuo Liu, Yue He, Xingxuan Zhang, Renzhe Xu, Han Yu, Peng Cui. Towards Out-Of-Distribution Generalization: A Survey. arxiv, 2021.浏览美团技术团队更多技术文章合集 ...

在LBS（Location Based Services, 基于地位的服务）间隔束缚下，候选较少制约了整个到店广告排序零碎的后劲空间。本文介绍了咱们从候选类型角度进行候选扩大，通过高性能的异构混排网络来应答性能的挑战，从而晋升了本地生存场景排序零碎的潜能下限。心愿能给从事相干方向的同学以启发。1 背景与简介1.1 背景美团到店广告负责美团搜寻流量的商业变现，服务于到店餐饮、休娱亲子、丽人医美、酒店游览等泛滥本地生存服务商家。品质预估团队负责广告零碎中CTR/CVR以及客单价/交易额等品质分预估，在过来几年中，咱们通过位次上下文建模[1]、时空超长序列建模[2]等翻新技术，在CTR预估问题中的用户、上下文等方向都获得了一些冲破[3]，并整顿成论文发表在SIGIR、ICDE、CIKM等国内会议上。 不过以上论文重在模型精度，而模型精度与广告候选独特决定着排序零碎的品质。但在广告候选角度，相比于传统电商的候选汇合，美团搜寻广告因LBS（Location Based Services, 基于地位的服务）的限度，所以在某些类目上门店候选较少，而候选较少又重大制约了整个排序零碎的后劲空间。当用传统形式来减少候选数量的办法无奈获得收益时，咱们思考将广告候选进行扩大与优化，以期晋升本地生存场景排序零碎的潜能下限。 1.2 场景介绍繁多的门店广告不足以满足用户找商品、找服务的细粒度用意诉求。局部场景将商品广告作为门店广告的候选补充，两者以竞争形式来确定展现广告款式；此外，还有局部场景商品广告以下挂模式同门店广告进行组合展现。多种形式的异构广告展现款式，给到店广告技术团队带来了时机与挑战，咱们依据业务场景特点，针对性地对异构广告进行了混排优化。下文以美团结婚频道页和美团首页搜寻为例，别离介绍两类典型异构混排广告：竞争关系异构广告和组合关系异构广告。 竞争关系异构广告：门店和商品两种类型广告竞争混排，通过比拟混排模型中pCTR确定广告展现类型。如下图1所示，左列首位为门店类型广告胜出，展现内容为门店图片、门店题目和门店星级评论数；右列首位为商品类型广告胜出，展现内容为商品图片、商品题目和对应门店。广告零碎决定广告的排列程序和展现类型，当商品类型广告获胜时，零碎确定展现的具体商品。 组合关系异构广告：门店广告和其商品广告组合为一个展现单元（蓝色框体）进行列表排序，商品从属于门店，两种类型异构广告组合混排展现。如下图2所示，门店广告展现门店的头图、题目价格等信息；两个商品广告展现商品价格、题目和销量等信息。广告零碎确定展现单元的排列程序，并在门店的商品汇合中确定展现的Top2商品。 1.3 挑战与做法简介 目前，搜寻广告模型线上为基于DNN（深度神经网络）[4-6]的门店粒度排序模型，门店候选数量受限（约150）且缺失商品等更间接且重要的决策信息。因而，咱们将商品广告作为门店的候选补充，通过门店与门店下多商品的混排关上候选空间，候选量能够达到1500+。此外，思考广告上下文影响，同时进一步扩大打分候选以晋升排序下限，咱们将门店粒度降级为异构广告组合粒度的排序，基于此构建生成式广告组合预估零碎，候选极限达到了1500X（思考线上性能咱们最终抉择1500X)。而在摸索过程中，咱们遇到了以下三大挑战： 商品粒度预估性能压力：下沉到商品粒度后减少至多10倍的候选量，造成线上预估服务无奈接受的耗时减少。组合间关系建模艰难：门店同组合商品的上下文关系应用Pointwise-Loss建模难以刻画。商品广告冷启动问题：仅应用通过模型抉择后曝光的候选，容易造成马太效应。针对上述挑战，技术团队通过思考与实际，别离进行如下针对性的优化： 高性能异构混排零碎：通过bias网络对门店信息迁徙学习，从而实现高性能商品粒度预估。生成式广告组合预估零碎：将商品预估流程降级为列表组合预估，并提出上下文联结模型，建模商品上下文信息。异构广告冷启动优化：基于汤姆森采样算法进行E&E（Exploit&Explore, 摸索与利用）优化，深度摸索用户的趣味。目前，高性能异构混排和生成式广告组合预估曾经在多个广告场景落地，视场景业务不同，在掂量广告营收的千次广告展现收益(RPM，Revenue Per Mille)指标上晋升了4%~15%。异构广告冷启动优化在各业务失效，在精度不降落的前提下给予流量10%随机性。下文将会对咱们的具体做法进行具体的介绍。 2 技术摸索与实际2.1 高性能异构混排零碎打分粒度从门店下沉为商品后，排序候选量从150减少到1500+，带来排序后劲晋升的同时，如果应用门店模型间接进行商品预估，则会给线上带来无奈承当的耗时减少。通过剖析，咱们发现门店下所有商品共享门店根底特色，占用了80%以上的网络计算，但对于多个商品只须要计算一次，而商品独有的、须要独立计算的商品特色只占用20%的网络计算。所以基于这个个性，咱们参照组合预估[7]的做法，来实现异构混排网络。主网络的高复杂性门店表征通过共有表白的迁徙学习，实现对门店网络输入层的复用，从而防止在进行商品预估时对门店网络的反复计算。 如下图4所示，整个网络分为门店网络和商品网络。在离线训练阶段，门店网络（主网络）以门店特色作为输出，失去门店的输入层，计算门店Loss，更新门店网络；商品网络（bias网络）以商品特色为输出，失去商品输出层，与门店网络的输入层门店向量作CONCAT操作，而后计算最终的商品Loss，并同时更新门店网络和商品网络。 为了实现线上预估时对门店网络输入层的复用，咱们将商品以List的形式喂入模型，实现申请一次打分服务，取得1(门店)+n（商品）个预估值。另外，对于门店的商品数不固定这一问题，咱们通过维度动静转换的形式保障维度对齐。实现放弃网络规模状况下扩充了10倍打重量，同时申请耗时仅减少了1%。 通过异构混排网络，咱们在性能束缚下失去了门店和各个商品的预估值，然而因为广告进口依然以门店作为单元进行计费排序，所以咱们须要依据不同业务场景特点进行预估值利用。为了形容不便，下文中用“P门店”代表门店的预估值，“P商品_i”代表第i个商品的预估值。 筛选频道页的竞争关系异构广告 筛选频道页内有门店和商品两种展现类型进行竞争，获胜的广告类型将最终失去展现。训练阶段，每一次曝光为一条样本，一条样本为商品和门店其中一种类型。门店样本只更新门店网络，商品样本同时更新门店网络和商品网络。预估阶段，门店和商品产生点击概率互斥，咱们应用Max算子：通过Max(P门店 ,P商品_1 ,...,P商品_n )，如果门店获胜，则展现门店信息，门店的预估值用于上游计费排序；如果任一商品获胜，则展现该商品信息，该商品的预估值用于上游。首页搜寻的组合关系异构广告 首页搜寻的排序列表页中每个展现单元由门店和两个商品组成，机制模块对这一个展现单元进行计费排序。训练阶段，每一次曝光为多条样本：一条门店样本和多条商品样本。门店样本只更新门店网络，商品样本同时更新门店网络和商品网络。预估阶段，因为用户点击【更多优惠】前，默认展现Top2商品，所以能够抉择商品预估值最高的Top2作为展现商品，其余商品按预估值排序。咱们须要预估pCTR(门店|商品1|商品2) 。从数学角度剖析，咱们在预估门店或商品1或商品2被点击的概率，因而咱们应用概率加法法令算子：pCTR(门店|商品1|商品2) = 1 - (1-P门店 ) (1-P商品_1 ) (1-P商品_2）。所以在失去门店和商品预估值之后，首先要对商品按预估值进行排序，失去商品商品的展现程序，并抉择Top2的商品预估值和门店预估值进行概率加法法令计算，失去展现单元的预估值用于门店排序计费。尽管零碎整体架构类似，然而因应用场景不同，样本生成形式也不同，模型最终输入的P商品有着不同的物理含意。在竞争关系广告中，P商品作为和门店并列的另一种展现类型；组合关系广告中，P商品则为门店广告展现信息的补充，因而也有着不同预估值的利用形式。最终高性能异构混排零碎在多个广告场景落地，视场景业务不同，RPM晋升范畴在2%~15%之间。 2.2 生成式广告组合预估零碎在商品列表中，商品的点击率除了受到其自身品质的影响外，还会受到其高低展现商品的影响。例如，当商品的上下文品质更高时，用户更偏向于点击商品的上下文，而当商品上下文品质较低时，用户则偏向于点击该商品，这种决策差别会累积到训练数据中，从而造成上下文偏置。而打消训练数据中存在的上下文偏置，有利于更好地定位用户用意以及保护广告零碎的生态，因而咱们参照列表排序的思路[8-9]，构建生成式商品排序零碎，建模商品上下文信息。 获取上下文信号能够通过预估商品列表的全排列，然而全排列的打重量极大（商品候选数10的全排列打分数为10!=21,772,800）。为了在耗时容许的状况下获取上下文信号，咱们采纳二次预估的形式对全排列后果进行剪枝。首次预估时采纳Base模型打分，仅取Top N商品进行排列，二次预估时再利用上下文模型对排列的所有后果进行打分。将全排列的打重量从10!缩小到N!（在线上，咱们抉择的N为3）。 然而二次预估会给服务带来无奈接受的RPC耗时，为了在性能的束缚下上线，咱们在TensorFlow外部实现了二次预估模块。如下图5所示，咱们最终实现了基于剪枝的高性能组合预估零碎，整体耗时和基线持平。 通过剪枝和TF算子，任一商品输出能够感知其上下文信号。为了建模上下文信息，咱们提出基于Transformer的上下文自适应感知模型。模型构造如图6所示： 咱们首先将门店特色及商品特色别离过Embedding层失去门店Emb及商品Emb，再通过全链接层失去无位次商品向量和无位次的预估值；将无位次商品向量与商品位次信号进行拼接，通过Transformer建模商品的上下文信息，失去蕴含上下文信息的商品Emb；将蕴含上下文信息的商品Emb与位次信号再次拼接，通过DNN非线性穿插，失去蕴含上下文信息及位次信息的最终输入商品预估值。通过强化商品间的穿插，达到建模商品上下文的目标，最终生成式广告组合预估在首页搜寻获得了RPM+2%的成果晋升。 2.3 异构广告冷启动优化为了防止马太效应，咱们也会被动试探用户新的趣味点，被动举荐新的商品来挖掘有后劲的优质商品。咱们在模型上线前，通过随机展现的形式来开掘用户感兴趣的商品。然而给用户展现的机会是无限的，展现用户历史喜爱的商品，以及摸索用户新趣味都会占用贵重的展现机会，此外，齐全的随机展现从CTR/PRS等成果上看会有较为显著的降落，所以咱们思考通过更正当的形式来解决“摸索与利用”问题。 绝对于传统随机展现的E&E算法，咱们采纳基于汤普森采样的Exploration算法[10]，这样能够正当地控制精度损失，防止因局部流量进行Exploration分桶的bias问题。汤普森采样是一种经典启发式E&E算法，外围思路能够详情为，给历史曝光数（HI，Historical Impressions）较多的商品较低的随机性，历史曝光较少的商品给予较高的随机性。具体的做法是咱们使商品的预估值（pCTR）遵从一个beta(a,b)散布，其中： $${\frac{{a}}{{a+b}}=p} ，a + b = n $$ 其中p是以pCTR为自变量的函数，n是以EI为自变量的函数。依据教训，咱们最终应用的函数为： $${n=hyperN*\text{(}log\mathop{{}}\nolimits_{{10}}\text{(}HI+10\text{))}\mathop{{}}\nolimits^{{2}}} ，p = hyperP * pCTR$$ ...

GPU等专用芯片以较低的老本提供海量算力，曾经成为机器学习畛域的外围利器，在人工智能时代施展着越来越重要的作用。如何利用GPU这一利器赋能业务场景，是很多技术研发者都要面临的问题。本文分享了美团外卖搜寻/举荐业务中模型预估的GPU架构设计及落地的过程，心愿能对从事相干利用研发的同学有所帮忙或启发。1 前言近些年，随着机器学习技术的蓬勃发展，以GPU为代表的一系列专用芯片以优越的高性能计算能力和愈发低廉的老本，在机器学习畛域失去宽泛认可和青眼，且与传统的CPU体系一直交融，造成了新的异构硬件生态。 在这种技术浪潮之中，很多技术研发者会面临着这样的问题：在咱们的业务上利用GPU硬件能取得什么？如何疾速、平滑地从传统CPU体系根底上实现切换？站在机器学习算法设计的角度，又会带来什么影响和扭转？在GPU生态下泛滥的技术路线和架构选型中，如何找到一条最适宜本身场景的门路？ 美团外卖搜寻举荐团队，也面临着相似的挑战和问题。本文咱们会分享美团外卖搜寻/举荐业务中，模型预估的GPU架构设计与落地过程，并将一些技术细节和测试数据做了详尽的披露，心愿能为宽广的技术同行提供一些有价值的参考。 2 背景以后，美团外卖次要通过搜寻和举荐两种流量散发形式，满足用户对“万物到家”的需要。除了首页的搜寻、举荐性能外，重点品类会在首页减少独立入口（下文称之为“金刚”），每个金刚入口中都有相似于首页搜寻、举荐的区域，而不同场景入口独特服务于外卖的最终成单。首页、金刚、店内的联动关系如下图所示： 面向点击率（CTR）/转化率（CVR）预估的深度学习，是每一个电商类搜寻/举荐产品中的核心技术，间接决定了产品的用户体验和转化成果，同时也是机器资源耗费的“小户”。而CTR/CVR精排模型的设计和实际，也是美团外卖搜寻举荐（下称搜推）技术团队必须要攻克且一直谋求卓越的必争之地。 从搜推零碎设计的角度上看，不同的搜寻、举荐入口会天然造成独立的调用链路。在传统的模型设计思路下，会对不同入口链路、不同漏斗环节的CTR/CVR/PRICE多个指标独立设计模型，这也是美团外卖搜推过往模型设计的经典形式。而从2021年起，基于多场景全局优化的考量，搜推场景的CTR/CVR预估模型开始逐渐走向多模型对立，综合利用多个入口的数据、联合不同入口本身的业务特点实现多个入口的联动优化，逐渐实现“One Model to Serve All”的指标。 从模型计算实际的角度上看，外卖精排模型的倒退，让模型Dense网络的计算量显著收缩，以CPU为计算主力的软硬件架构曾经难以应答算法的倒退需要，即使老本耗费大幅加剧，算力天花板依然“近在眉睫”。而GPU硬件面向浓密计算的算力劣势，恰好吻合新的模型特点，能够从根本上突破精排模型预估/训练中的算力困局。因而，从2021年开始，美团外卖搜推场景的深度学习体系开始逐渐从纯CPU架构走向CPU+GPU的异构硬件计算平台，以满足美团外卖模型算法演进对算力的新要求。 本文接下来的内容，会从外卖搜推场景的精排模型设计登程，联合美团理论的软硬件特点，为大家具体分享在外卖精排模型预估畛域，从纯CPU架构转型到CPU+GPU异构平台的摸索和实际过程，供宽广技术同行参考。 3 外卖搜推场景下的精排模型本章节次要介绍在外卖场景下多模型对立的演进思路、模型特点以及在实践中的挑战。本文只对模型设计思路做简略的阐明，引出后续模型计算在GPU落地中的实际思考。 3.1 精排模型的设计思路如前文所述，在美团外卖多入口联动的场景特点下，经典的单体模型设计存在着以下局限： 首页举荐与各金刚入口举荐各保护一个精排模型，不仅保护老本高而且训练数据割裂，导致精排模型不能捕捉到用户在所有举荐场景的趣味。举荐场景的精排模型只应用举荐场景的训练样本，未利用用户在其余重要入口的训练样本，比方搜寻、订单页，模型只学习到用户在部分场景的偏好信息。举荐场景的训练样本中存在Position Bias问题，具体是指用户点击一个商家，有可能只是因为该商家在举荐Feeds中排序地位比拟靠前，而非因为用户对此商家真正感兴趣，此类Bias会引起模型训练有偏。多指标之间存在贝叶斯束缚，网络结构中未思考，CXR=CTR × CVR，CXR预估值应比CTR小，模型在验证集上会呈现CXR比CTR还高的景象，预估不精确。基于此，在2021年，美团外卖搜推场景提出了向超过单体的多模型对立演进、逐渐实现“One Model to Serve All”的思维，这一理念在模型设计中具体体现在： CTR/CXR多指标的交融，实现多指标预测的模型对立。场景专家网络与Attention网络的交融，实现不同流量入口之间的模型泛化和对立。畛域专属网络和共享网络的交融，实现举荐场景向搜索场景的迁徙学习。 随着外卖精排模型的倒退和演进，模型Dense网络的参数量显著减少，单次推理的FLOPs达到26M，对CPU计算架构造成了微小压力。另一方面，咱们采纳Float 16压缩、特色主动抉择、网络穿插代替手动穿插特色等技术手段，将模型由100G放大到10G以内，并且过程中通过模型的优化，做到了模型成果无损。 综上，外卖搜推精排模型浓密局部计算简单、稠密局部体积可控，这些良好的个性，为咱们在GPU硬件架构上落地推理计算提供了绝对合适的模型算法根底。接下来，咱们将探讨如何在高吞吐、低耗时的外卖搜寻举荐零碎中，利用GPU硬件无效解决外卖精排模型在线预估中的老本和性能问题，并给出咱们的实际过程和后果。 3.2 模型利用的特点与挑战在搜寻/举荐技术畛域中，稠密模型预估（CTR/CVR）是决定算法成果的外围因素，模型预估服务是搜寻举荐零碎中必不可少的组成部分，业内各大公司已有很多经典的实现计划。在探讨具体实际之前，先介绍一下咱们的场景特点： ① 需要层面 模型构造：如前文介绍，外卖场景下的精排模型的浓密网络局部绝对简单，单次推理的FLOPs达到26M；而模型的稠密局部通过大量的优化，体积失去了无效的管制，模型规模在10G以内。服务质量要求：举荐服务作为经典的高性能To C场景，业内大部分同类零碎的超时管制在百毫秒量级，合成到预估服务，超时个别须要管制在十毫秒的量级。② 软件框架层面 开发框架：模型开发采纳TensorFlow框架[1]。作为支流的深度学习第二代框架，TensorFlow具备弱小的模型表达能力，这也导致其算子粒度比拟小，这一特点无论是对CPU还是GPU架构都会带来很大的额定开销。在线服务框架：采纳TensorFlow Serving框架[2]。基于此框架，可将离线训练好的机器学习模型部署到线上，并利用rpc对外提供实时预估服务。TensorFlow Serving反对模型热更新及模型版本治理，次要特点是应用灵便，性能较好。③ 硬件层面 机型个性：美团基于晋升算力密度的考量，在预估服务采纳了GPU BOX机型。绝对于传统的GPU插卡机型，这一类机型每张GPU卡配套的CPU和内存绝对无限，这须要咱们在设计在线服务时，精细化的考量CPU、GPU上的计算和数据分布，达到更好的利用率平衡。GPU固有属性：GPU kernel大体上能够划分为传输数据、kernel启动、kernel计算等几个阶段[3]，其中每个kernel的启动须要约10us左右。因而，GPU预估会面临一个普适问题，大量的小算子导致每个kernel的执行工夫很短，kernel启动的耗时占了大部分。相邻的kernel之间须要通过读写显存进行数据的传输，产生大量的访存开销。而GPU的访存吞吐远远低于计算吞吐，导致性能低下，GPU的利用率并不高。 总结而言，与业内其余支流搜推场景绝对比，咱们的CTR模型预估场景有两个显著特点： 浓密网络局部计算复杂度高，绝对的，稠密网络在模型设计环节通过了大量的优化，体积绝对较小。应用GPU BOX机型，单GPU卡的CPU配额受限，须要针对性优化CPU的计算负荷。基于这两个特点，咱们在面向GPU的优化实际中就能够更具针对性了。 4 模型服务架构概览本章节简要介绍美团外卖搜推在线预估服务的整体架构和角色分工，也是外卖搜推精排模型在GPU落地实际的工程零碎根底。 零碎要害角色 Dispatch：承当着特色获取和特色计算的职能，如前文所述，美团应用GPU BOX机型搭建预估服务，推理计算的CPU资源自身就非常吃紧，因而天然会思考将在线特色工程局部独立部署，防止CPU资源的抢占。本局部和GPU实际关系不大，不是本文的重点。Engine：承当着模型在线推理的职能，通过RPC的形式输出特色矩阵、输入预估后果。采纳GPU BOX机型（单容器8核+1 NVIDIA Tesla T4），均匀响应工夫需管制在20ms以内，下文所述GPU优化实际次要面向这一模块的特点进行。Booster：在模型更新过程中离线执行的模型优化器，外部以Optimizer插件的形式，混合了手工优化器插件和DL编译优化器插件，是下文所述GPU优化操作的执行者。5 GPU优化实际本章节将开展分享精排模型预估计算在GPU架构落地中的优化过程。 与CV、NLP等经典机器学习畛域不同，以CTR模型为代表的稠密模型因为构造多变、蕴含大量业务特化等起因，硬件供应商难以对这一类未收敛的模型构造提供端到端优化工具。因而，在CTR模型大规模利用的畛域中，个别会联合GPU个性，面向应用场景对模型执行Case By Case的优化措施。按模型优化的指标来辨别，能够大抵分类为系统优化和计算优化： ① 系统优化：个别指通过对计算、存储、传输的调度，使CPU+GPU的异构硬件体系能够更有效率的协同和被应用。典型的系统优化包含： 设施摆放算子交融GPU并发/流水线优化② 计算优化：个别指面向硬件个性，优化模型前向推理网络的结构设计和算子执行逻辑，使模型推理计算在GPU上的计算开销更小，效率更高。典型的计算优化包含： 冗余计算去除量化计算高性能库的利用在本文介绍的优化工作中，咱们对上述常见优化中的大部分思路进行了摸索和实际，下文会逐个进行论述，并给出优化成果和面向理论场景的总结剖析。 5.1 系统优化5.1.1 设施摆放TensorFlow会为计算图中每个Node主动设置Runtime Device，计算较重者搁置在GPU，计算较轻者搁置在CPU。在简单计算图中实现一次残缺的inference，数据会在CPU和GPU之间重复传输。因为H2D/D2H传输很重，这会造成数据传输耗时远大于op（operator）外部计算耗时，在GPU下模型一次预估耗时为秒级别，远高于只应用CPU时的耗时。此外，如前所述，咱们所应用的GPU机型上CPU资源受限（一张T4卡仅对应8核CPU），这也是咱们在异构架构设计中须要解决的核心技术挑战。 ...

随着美团外卖业务一直倒退，外卖广告引擎团队在多个畛域进行了工程上的摸索和实际，目前曾经获得了一些成绩。咱们打算通过连载的模式分享给大家，本文是《美团外卖广告工程实际》专题连载的第一篇。本文针对业务提效的指标，介绍了美团外卖广告引擎在平台化过程中的一些思考和实际。1 前言美团外卖曾经成为公司最为重要的业务之一，而商业变现又是整个外卖生态重要的组成部分。通过多年的倒退，广告业务笼罩了Feed流模式的列表广告，针对KA以及大商家的展现广告，依据用户查问Query的搜寻广告，以及一些翻新场景的翻新广告等多个产品线，并对应十几个细分的业务场景。 从技术层面而言，一次广告申请的过程，能够分为以下几个次要步骤：广告的触发、召回、精排、创意优选、机制策略等过程。如下图所示：即通过触发失去用户的用意，再通过召回失去广告候选集，通过预估对候选集的店铺打分、排序，再对于Top的店铺再进行创意的抉择，最初通过一些机制策略失去广告后果。 2 现状剖析在业务迭代的过程中，随着新业务场景的一直接入，以及原有业务场景性能的一直迭代，零碎变得越来越简单，业务迭代的需要响应逐步变慢。在业务倒退后期，发展过单个模块的架构重构，如机制策略、召回服务，尽管对于效率晋升有肯定的改善，然而还会存在以下一些问题： 业务逻辑复用度低：广告业务逻辑比较复杂，比方机制服务模块，它次要性能是为广告的管制中枢以及广告的出价和排序的机制提供决策，线上反对十几个业务场景，每种场景都存在很多差别，比方会波及多种召回、计费模式、排序计划、出价机制、估算管制等等。此外，还有大量业务自定义的逻辑，因为相干逻辑是算法和业务迭代的重点，因而开发人员较多，并且散布在不同的工程和策略组内，导致业务逻辑形象粒度规范不够对立，使得不同场景不同业务之间复用水平较低。学习老本高：因为代码简单，新同学相熟代码老本较高，上手较难。此外，线上服务很早就进行了微服务革新，线上模块数量超过20个，因为历史起因，导致多个不同模块应用的框架差别较大，不同模块之间的开发有肯定的学习老本。在跨模块的我的项目开发中，一位同学很难独立实现，这使得人员效率没有失去充分利用。PM（产品经理）信息获取难：因为目前业务场景较多、逻辑简单，对于信息的获取，绝大多数同学很难理解业务的所有逻辑。PM在产品设计阶段须要确认相干逻辑时，只能让研发同学先查看代码，再进行逻辑的确认，信息获取较难。此外，因为PM对相干模块的设计逻辑不分明，往往还须要通过找研发人员线下进行询问，影响单方的工作效率。QA（测试）评估难：QA在性能范畴评估时，齐全依赖于研发同学的技术计划，且大多数也是通过沟通来确认性能改变波及的范畴和边界，在影响效率的同时，还很容易呈现“漏测”的问题。3 指标针对以上的问题，咱们从2020年初，启动美团外卖广告引擎平台化我的项目，旨在通过平台化的我的项目达成以下指标。 晋升产研效率 高性能复用度，晋升开发效率。升高研发人员（RD）、PM、QA之间的合作老本，晋升产研合作的效率。晋升交付品质 准确QA测试的范畴，晋升交付的品质。对业务进行赋能。PM可通过可视化的平台化页面，理解其余产品线的能力，相互赋能，助力产品迭代。4 整体设计4.1 整体思维目前，业界曾经有不少“平台化”方向的钻研，比方阿里巴巴的TMF，定位于泛交易类零碎的平台化畛域领域，次要建设思维是，流程编排与畛域扩大分层，业务包与平台拆散的插件化架构，治理域与运行域拆散。而阿里巴巴的AIOS则定位于搜推平台化畛域领域，次要依赖于底层5大外围组件，以算子流程图定制的模式对组件疾速组合与部署，从而实现了业务的疾速交付。 美团外卖在平台化我的项目启动时，从业务场景和业务痛点登程，确定了咱们我的项目的外围指标：利用平台化设计理念构建相适应的技术能力，将现有外卖广告的业务零碎和产研流程转变为平台化模式，疾速反对外卖广告多业务进行交付。咱们借鉴了行业内平台化的成熟思维，确定了以业务能力标准化为根底、构建平台化框架技术能力为撑持、产研平台化模式降级为保障的平台化建设整体思维，整体思维可分为三局部：业务能力标准化、技术能力框架化、平台化产研新流程。 业务能力标准化：通过对现有逻辑的梳理，进行标准化的革新，为多业务场景、多模块代码复用提供根底保障。技术能力框架化：提供组合编排能力将标准化的逻辑串联起来，通过引擎调度执行，同时实现了可视化能力的透出，帮忙用户疾速获取信息。平台化产研新流程：为保障我的项目上线之后实现研发迭代的整体提效，咱们对于研发流程的一些机制也进行了一些优化，次要波及研发人员、PM、QA三方。即通过标准化提供复用的保障，通过框架承载平台化落地的能力，通过产研新流程的运行机制保障了整体提效的持续性。整个广告引擎服务波及到的模块都遵循了平台化的思维，撑持上游各个产品场景，如下图所示： 4.2 业务标准化4.2.1 业务场景与流程剖析提效是平台化最重要的指标之一，而提效最重要的伎俩是让性能在零碎中失去最大水平上的复用。咱们首先针对外卖广告业务线场景和流量的现状做了对立的剖析，得出以下两点论断： 第一，各业务线大的流程根本相似，都包含预处理、召回、预估、机制策略、排序、创意、后果组装等几个大的步骤；同时，不同业务雷同的步骤里会有很多类似的性能和业务线特有的性能。第二，这些性能实践上都是能够整体进行复用的，但现状是这些性能都集中在业务线外部，不同的业务线之间，不同的小组之间的复用情况也不尽相同。而造成这一问题的次要起因是： 不同业务处在不同的倒退阶段，也有着不同的迭代节奏。组织构造人造存在“隔离”，如举荐和搜寻业务分在两个不同的业务小组。因而，妨碍外卖广告进一步晋升复用水平的次要起因，在于整体的标准化水平有余，各业务线间没有对立的规范，所以咱们要先解决标准化建设的问题。 4.2.2 标准化建设标准化建设的广度和深度决定了零碎复用能力的高下。因而，本次标准化的建设指标要笼罩到所有方面。咱们对广告零碎所有的服务，从业务开发的三个维度，包含实现的性能、性能应用的数据、性能组合的流程登程，来进行对立广告的标准化建设。从而使得： 在个体开发层面：开发同学不必关注如何流程调度，只需将重心放在新性能的实现上，开发效率变得更高。从零碎整体角度：各个服务对于通用的性能不必再反复开发，整体的复用水平更高，节俭了大量的开发工夫。4.2.2.1 性能的标准化 针对性能的标准化问题，咱们首先根据性能是否跟业务逻辑相干，将其划分为两局部：业务逻辑相干和业务逻辑无关。 ① 与业务逻辑无关的性能通过双层形象来对立共建 所有业务线对立共建的标准化模式是进行双层形象。对于单个的、简略的性能点，形象为工具层；对于可独立实现并部署的某一方面性能，比方创意能力，形象为组件层。工具层和组件层对立以JAR包的模式对外提供服务，所有工程都通过援用对立的JAR包来应用相干的性能，防止反复的建设，如下图所示： ② 与业务逻辑无关的性能，在复用范畴上进行分层复用 业务逻辑相干的性能是此次标准化建设的外围，指标是做到最大水平的业务复用。因而，咱们将最小不可拆分的业务逻辑单元形象为业务同学开发的根本单位，称为Action。同时依据Action不同的复用范畴，将其划分为三层，别离是所有业务能够复用的根底Action，多业务线复用的模块Action，具体繁多业务定制的业务Action，亦即扩大点。所有的Action都是从Base Action派生进去的，Base Action里定义了所有Action对立的根底能力。不同的Action类型别离由不同类型的开发同学来开发。对于影响范畴比拟大的根底Action和模块Action，由工程经验丰富的同学来开发；对于仅影响单个业务的业务Action或扩大点，由工程能力绝对单薄的同学来进行开发。同时咱们把多个Action的组合，形象为Stage，它是不同Action组合造成的业务模块，目标在于屏蔽细节，简化业务逻辑流程图的复杂度，并提供更粗粒度的复用能力。 4.2.2.2 数据的标准化 数据作为实现性能的根本元素，不同业务的数据起源大同小异。如果不对数据进行标准化设计，就无奈实现性能标准化的落地，也无奈实现数据层面的最大化复用。咱们从数据起源和数据应用形式两方面来划分数据：对于业务能力的输出数据、两头数据，输入数据，通过标准化的数据上下文来实现；同时对于第三方内部数据及词表等外部数据，通过对立的容器存储和接口获取。 ① 应用上下文Context形容Action执行的环境依赖 每个Action执行都须要肯定的环境依赖，这些依赖包含输出依赖、配置依赖、环境参数、对其余Action的执行状态的依赖等。咱们将前三类依赖都形象到业务执行上下文中，通过定义对立的格局和应用形式来束缚Action的应用。思考不同层级Action对于数据依赖应用范畴由大到小，遵循雷同的分层设计，咱们设计了三层顺次继承的Context容器，并将三类依赖的数据标准化存储到相应的Context中。应用标准化Context进行数据传递，劣势在于Action可自定义获取输出数据，以及后续扩大的便利性；同时标准化的Context也存在肯定的劣势，它无奈从机制上齐全限度Action的数据拜访权限，随着后续迭代也可能导致Context日渐臃肿。综合思考利弊后，现阶段咱们依然采纳规范的Context的模式。 ② 第三方内部数据的对立解决 对于第三方的内部数据的应用，须要成熟的工程教训提前评估调用量、负载、性能、批量或拆包等因素，所以针对所有第三方内部数据，咱们对立封装为根底Action，再由业务依据状况定制化应用。③ 词表数据的全生命周期治理 词表依据业务规定或策略生成，须要加载到内存中应用的KV类数据，标准化之前的词表数据在生成、拉取、加载、内存优化、回滚、降级等能力上有不同水平的缺失。因而，咱们设计了一套基于音讯告诉的词表治理框架，实现了词表的版本治理、定制加载、定时清理、流程监控的全生命周期笼罩，并定义了业务标准化的接入形式。4.2.2.3 调用流程的标准化 最初，将性能和数据进行组合的是业务的调用流程，对立的流程设计模式是业务性能复用和提效的外围伎俩。流程设计对立的最佳形式就是标准化业务流程。其中对于第三方接口的调用形式，让框架研发的同学用集中封装的形式进行对立。对于接口的调用机会，则基于性能优先并兼顾负载，且在没有反复调用呈现的准则下，进行标准化。 在具体实际中，咱们首先梳理业务逻辑所应用到的标准化性能，而后剖析这些性能之间的依赖关系，最初以性能优先并兼顾负载、无反复调用等准则，实现整个业务逻辑流程的规范设计。 从横向维度看，通过比拟不同业务逻辑流程的相似性，咱们也提炼了肯定的实践经验，以中控模块为例： 对于用户维度的第三方数据，对立在初始化后进行封装调用。对于商家维度的第三方数据，有批量接口应用的数据，在召回后对立封装调用；无批量接口应用的数据，在精排截断后对立封装调用。4.3 技术框架4.3.1 整体框架介绍平台次要有两个局部组成，一部分是平台前台局部，另一部分是平台开发框架包。其中前台局部是一个给研发人员、PM以及QA三种角色应用的Web前台，次要性能是跟集成了平台开发框架包的引擎服务进行可视化的交互，咱们也给这个平台起了个名字，叫Camp平台，这是大本营的意思，寓意助力业务方攀登业务顶峰。平台开发框架包被引擎后盾服务所集成，提供引擎调度隔离、能力积淀、信息上报等性能，同时还能确保各个模块放弃同样规范的框架和业务能力格调。 各个在线服务都须要引入平台开发框架包，服务性能与平台通用性之间如何均衡也是咱们须要着重思考的中央。这是因为，引入平台框架会对原有的代码细节进行增强性扩大；在C端大流量场景下，平台框架做得越通用，底层性能做得越丰盛，与单纯的“裸写”代码相比，会带来一些性能上的折损。因而，在性能开销与平台形象能力上，须要尽量做到一个折中。咱们联合本身业务的个性，给出的平安阈值是TP999损失在5ms以内，将各个业务通用的能力下沉至框架，提供给下层的在线服务。 综上，整个零碎架构设计如下： ① Camp平台提供管理控制和展现的性能，该平台由以下几个子模块包组成： 业务可视化包，提供各个后盾零碎上的能力的动态信息，包含名称、性能形容、配置信息等，这些信息在需要评估阶段、业务开发阶段都会被用到。全图化编排和下发包，业务开发同学通过对已有的能力进行可视化的拖拽，通过全图化服务主动生成并行化最优的执行流程，再依据具体业务场景进行调整，最终生成一个有向无环图，图的节点代表业务能力，边示意业务能力之间的依赖关系。该图会动静下发到对应的后盾服务去供执行框架解析执行。统计监控包，提供业务能力、词典等运行期间的统计和异样信息，用于查看各个业务能力的性能状况以及异常情况，达到对各个业务能力运行状态可感知的目标。② 平台开发框架包被广告引擎的多个服务引入，执行编排好的业务流程并对外提供服务，平台框架开发包由以下几个子模块包组成： 外围包，提供两个性能，第一个是调度性能，执行平台下发的流程编排文件，依照定义的DAG执行程序和执行条件去顺次或并行执行各个业务能力，并提供必要的隔离和牢靠的性能保障，同时监控运行以及异常情况进行上报。第二个是业务采集和上报性能，扫描和采集零碎内的业务能力，并上报至平台Web服务，供业务编排以及业务能力可视化透出应用。能力包，业务能力的汇合，这里的业务能力在后面章节“4.2.2.1 性能的标准化”中已给出定义，即“将最小不可拆分的业务逻辑单元，形象为业务同学开发的根本单位，称为Action，也叫能力”。组件包，即业务组件的汇合，这里的业务组件在章节“4.2.2.1 性能的标准化”中也给出定义，即“对于可独立实现并部署的某一方面性能，比方创意能力，形象为组件”。工具包，提供业务能力须要的根底性能，例如引擎罕用的词典工具、试验工具以及动静降级等工具。这里的工具在章节“4.2.2.1性能的标准化”中同样给出了定义，即单个的、简略的非业务功能模块形象为工具。 一个典型的开发流程如上图所示 ，开发人员开发完业务能力后（1），业务能力的动态信息会被采集到Camp平台（2），同时，通过全图化依赖推导失去最优DAG图（3），业务同学再依据理论业务状况对DAG图进行调整，引擎在线服务运行期间会失去最新的DAG流程并对外提供最新的业务流程服务（4，5），同时会把业务运行的动静信息上报至Camp平台（6）。 在上面的章节中，咱们将对几个比拟要害的技术点进行详细描述，其中就包含了可视化相干的组件主动上报和DAG执行相干的全图化编排、执行调度等，最初，本文还会介绍一下跟广告业务强相干的、词典在平台化中对立封装的工作。 4.3.2 业务采集&上报为了方便管理和查问已有业务能力，平台开发框架包会在编译时扫描@LppAbility注解和@LppExtension注解来上报元数据到Camp平台。业务同学能够在Camp平台中对已有组件进行查问和可视化的拖拽。 //原子能力（Action）@LppAbility(name = "POI、Plan、Unit数据聚合平铺能力", desc = "做估算过滤之前，须要把对象打平", param = "AdFlatAction.Param", response = "List<KvPoiInfoWrapper>", prd = "无产品需要", func = "POI、Plan、Unit数据聚合平铺能力", cost = 1)public abstract class AdFlatAction extends AbstractNotForceExecuteBaseAction {}//扩大点@LppExtension(name = "数据聚合平铺扩大点", func = "POI、Plan、Unit数据聚合平铺", diff = "默认的扩大点，各业务线间接无差别", prd = "无", cost = 3)public class FlatAction extends AdFlatAction {@Override protected Object process(AdFlatAction.Param param) { //do something return new Object(); }} ...

查问改写是对用户Query拓展改写词，用更好的表述，帮用户召回更多合乎需要的后果。查问改写对于文本布尔检索系统是十分重要的扩召回伎俩，通过优化该算法模块可能间接且显著地晋升搜寻体验。本文次要讲述在美团的搜寻场景下查问改写我的项目的迭代方向和实现思路，心愿能对从事搜寻、广告、举荐中召回相干工作的同学有所启发或者帮忙。1. 引言在搜寻场景中，因为用户搜索词Query和检索文本Document之间存在大量表述不一的状况，在文本检索框架下，此类文本不匹配导致的漏召回问题重大影响着用户的体验。对这类问题业界个别有两种计划：用户端拓展用户的查问词——即查问改写，或Document端拓展文档关键词——即Document标签。本文次要介绍前一种解决漏召回的计划：查问改写（Query Rewriting，或称为查问扩大Query Expansion）。查问改写的利用形式是对原始Query拓展出与用户需要关联度高的改写词，多个改写词与用户搜索词一起做检索，从而用更好的表述，帮用户搜到更多合乎需要的商户、商品和服务。 在美团搜寻的技术架构下，查问改写管制召回语法中的文本，命名实体辨认（Named Entity Recognition，简称NER）[1]管制召回语法中的检索域，用意辨认管制召回的相关性以及各业务的分流和产品状态，这是最为外围的三个查问了解信号。查问改写策略在美团搜寻的全副流量上失效，除扩大用户搜索词外，在整个美团搜寻技术架构中作为根底语义了解信号，从索引扩大、排序特色、前端高亮等多方面影响着用户体验。对搜寻召回后果中的无后果率、召回后果数以及搜寻点击率等指标，也有着间接且显著的影响。 本文会介绍美团搜寻场景下查问改写这一工作上的迭代教训，内容次要分为三个局部。第一局部会对查问改写工作在美团搜寻场景下的挑战进行简略的介绍；第二局部会介绍查问改写工作上整体技术栈建设的实践经验第三局部是总结与瞻望。目前，业界在文本召回策略方面公开的分享较少，心愿本文能对从事搜寻、广告、举荐中召回相干工作的同学有所启发或者帮忙。 2. 背景与挑战2.1 美团搜寻场景下查问改写信号的应用形式在美团的搜寻场景下，查问改写次要用于解决以下四类语义鸿沟导致的漏召回问题： 语义拓展：次要是同义词、下位词以及常见的大小写数字和繁简转化等，例如“理发”、“剪发”、“造型”、“发艺”、“美发”、“剪头”等等。用户表白和商家表白上的Gap：非语言上的同义。如用户表述口语化“学吉他”，商户形容书面化“吉他培训”；用户输出不齐全匹配商户名：“希尔顿大酒店”（商家更常见的形容为“希尔顿酒店”）。场景拓展：例如“摘草莓”在美团的搜寻场景下，用户基于对平台的认知对应需要是“草莓园”。其余漏召回问题：局部的多字少字、纠错等问题，如“屋宇扫”对应“家政保洁”的需要；实践上查问改写能够通过减少改写词解决所有漏召回问题，诸如“冬日四件套”包含“冰糖葫芦、烤地瓜、炒栗子、热奶茶”这类有时效性的网红概念，也能够通过改写进行解决。 2.2 美团搜寻场景下查问改写信号的难点和挑战搜寻是在用户搜索词以及供应两方面束缚下尽可能进步用户触达效率以及商业化指标，而美团的搜寻场景减少了“地区”第三个束缚。具体的行业对比方下图所示： 通过比照行业内搜寻场景能够发现，美团的搜寻场景下用户需要和服务商家大多是面向本地，而生存服务畛域业务十分细碎，绝对用户对生存服务某个畛域的需要而言，本地化供应绝对较少。 与此同时，美团搜寻还聚合了多种履约模式的后果，搜寻后果中会有团购、外卖、买菜、优选等业务的天然后果聚块，以及在本地相干业务均无后果时的举荐后果聚块。在无限的曝光地位下，每个天然后果聚块的不相干的后果会挤占其余聚块的收益，因而不能依赖排序解决相关性问题。这就要求美团搜寻场景的查问改写在多个业务场景下要强相干且高效率，算法层面须要解决笼罩问题、准确率问题以及多业务问题。以该要求为出发点，在具体算法迭代时查问改写还面临以下两方面挑战： ① 对用户的查问面临着简单的需要场景 语言歧义状况多：短Query减少了歧义的可能性，例如在美团场景下“剪个头发”是一个商户名，不能改写为“理发”；雷同Query在不同城市含意不同，如“工大”在不同城市指代的学校不同。认知关联性：用户的搜寻人造有对美团平台“找店”的认知，须要相似“配眼镜”等同于“眼睛店”的场景关联常识。场景多：随业务的倒退，主观需要增多，查问改写承接的场景越来越多、越来越精密，目前，曾经接入餐饮、到综、酒店游览、外卖、商品、广告等多个业务场景。② 对平台的供应须要兼顾供应建设特点和倒退阶段 美团商户大部分不会做关键词SEO（Search Engine Optimization）：文本不匹配导致的漏召回问题更为严重，对改写的需要很大。商户的外露模式导致实在交互用意不明确：大部分商户同时提供多种菜品、商品、团单服务，例如，一个音乐培训机构往往提供多种乐器的培训课程。与业务特点和倒退阶段强关联：美团是一个聚合生存服务方方面面的平台，并且各业务对改写的需要不同，对于一些重交易的业务来说弱相干的改写能够承受，而对一些重体验的业务来说，对改写的要求更严格，须要肯定的区分度。3. 技术选型下图4总结了目前查问改写迭代的技术框架以及对应解决的问题。咱们在各个子外围模块如离线候选开掘算法摸索、语义关系判断模型、向量化召回、在线生成改写词有较为深刻的摸索。除信号自身迭代，在信号的应用上也通过改写分级信号退出排序、召回相关性等做联动获得了不错的线上收益。 上面，咱们将从离线到在线全面的介绍查问改写工作下的各模块技术的迭代。 3.1 原始语料开掘高质量的数据能够显著改善头部流量的改写成果，并且决定了后续模型性能的天花板。在候选集生成方面，基于搜寻日志的开掘、基于翻译思维、基于图计算、基于Embedding都是工业界和学术界罕用的办法；在候选集过滤判断方面则有句间关系分类、Embedding类似度计算等办法。咱们联合美团搜寻场景总结了各个办法的优缺点，并在每个开掘算法组件都联合了用户行为和语义两方面信息，下文将对离线语料开掘做具体介绍。 3.1.1 搜寻日志开掘候选语料搜寻日志开掘是工业界罕用的同义词获取伎俩，开掘的次要方向有： 用户搜寻后点击独特商户： 利用两个点击雷同Document的Query构建相干关系。这种相干关系能够开掘到大量词对，但这种简略的假如毛病也很显著，点击共现的Query可能有不同水平的漂移。在美团场景下提供综合服务的店铺很多，会有两种类型团单大量呈现在雷同商户下的状况，开掘到“拔牙”→“补牙”这种有语义漂移噪声的可能性更大。此外，这个办法依赖现有搜寻的成果，无奈开掘到无后果Query的改写词。从搜寻Session中开掘： Session是指用户在一段时间内“关上App→多个页面的浏览，多个性能的点击、领取等行为→来到App”的一次交互过程。该办法是利用用户在整次App拜访过程中间断输出的Query来构建相干关系。Session开掘依赖搜寻后果水平低，因而泛化能力更强。但相应的毛病是，Session工夫切割不好确定，并且序列中每个搜索词之间的关联形式比拟荫蔽，甚至可能没有相干关系。须要联合业务特点设计时长、引入点击（例如一次Session在有点击前的搜索词都无点击，可能是有具体需要未被满足）等条件做开掘。词对齐： 词对齐借鉴了翻译的思维，具体方法是将Query召回的商户题目去除了商户名局部后残余的局部做为平行语料，设计一些对齐策略如字对齐（蕴含雷同的字）、拼音对齐（雷同拼音）、构造对齐（分词后词地位雷同）。该办法的毛病是强依赖于现有搜寻的成果。 商户/商品内SEO： 商品场景下，局部商家上架时会做SEO，如：“加长 狗狗牵引绳 狗绳 狗项圈 遛狗泰迪金毛宠物大型中型小型犬 狗链子”。这一类开掘起源的毛病是有比拟大的噪声，并且乐音关联性较大比拟难分辨（存在上下位类型、同位词类型、舞弊等乐音类型）。以上简略办法均能够开掘到大量相干词对，但基于的假如和设计的规定都很简略，优缺点都非常明显。上面介绍几种优化的开掘办法。 3.1.2 基于图办法开掘图办法如经典的协同过滤以及Graph Embedding等，在举荐场景中通过利用用户和Document的关系构建图构造来举荐更类似的Document。在搜寻场景下用户的搜寻Query以及平台的Document通过点击、下单等形式同样也能够建模成图构造。在美团搜寻的应用场景下，咱们对构图形式做了如下两个改良：① Query和Document之间的边权重应用Query点击Document的点击次数和点击率进行Wilson平滑的后果，而不只是Query点击Document的次数，从而进步相关性；② 在二部图中，将用户在Session中自行改写的Query也视为Document节点，与点击的Document题目一起进行构图，从而进步开掘的数据量。 咱们晚期用SimRank++算法[2]验证了构图形式两个优化点的可行性，SimRank++算法是一种同构信息网络中的类似度量算法，它的思维是：如果两个用户类似，则与这两个用户相关联的物品也相似；如果两个物品相似，则与这两个物品相关联的用户也相似。该算法的长处是能够应用Spark进行大规模全局优化，并且边权重能够依据须要调整。优化构图后人工评测SimRank++优化前后查问改写数据量晋升了约30%，同时准确率从72%晋升到83%。 后续，咱们用雷同的思路尝试了其余图神经网络模型（GNN）。DeepWalk[3]在结构Sentence上下文采纳随机游走的办法。 随机游走个别是将Query之间的关系建设成图，通过从一个点随机游走，建设起多条门路，每条门路上的Query组成一个句子，再应用上下文相干原理训练Query的Embedding。随机游走的长处就是关系具备传递性，和Query共现不同，能够将间接关系的Query建立联系。大量的数据通过游走可能产生够多的训练数据。例如在Session1中用户先搜寻Query1后改为Query2再查问，在Session2中用户先搜寻Query2后改为Query3再查问，共现的办法无奈间接建设Query1和Query3的关联关系，而随机游走可能很好地解决。在改写词开掘工作中，基于图的办法相较于间接从搜寻日志开掘词对的办法，开掘的效率和准确率均有所晋升。 3.1.3 基于语义向量开掘在word2vec[4]后，Embedding的思维迅速从NLP畛域扩散到简直所有机器学习的畛域，号称“万物皆可Embedding”，只有是一个序列问题均能够从上下文的角度示意其中的节点。此外，Embedding在数据稠密性示意上的劣势也有利于后续深度学习的摸索。将Query Embedding到低维语义空间，通过计算Embedding间的类似度查找相干词，在开掘类似词的工作中是常见且易于实际的开掘办法。除了简略的在用户评论等语料上训练大规模词向量外（即图7a），在实践中还尝试了以下两种构建上下文的办法： 通过Query召回商户构建Doc2Vec[5]：通过Query召回或点击的商户作为上下文训练Embedding表征Query（即图7b）。因为美团场景下同一商户提供的服务、商品繁多，该办法在没有思考Query自身类目用意的状况下，噪声比拟大。通过用户Session构建改写序列[6]：通过一个Session序列作为上下文训练Embedding表征Query（即图7c）。该办法的长处是无效的利用了用户自行换词的限度条件，开掘覆盖率和准确率都绝对更高。 设计不同的上下文构造失去Embedding后，为了进一步提高准确率后续的根本的步骤是：① 训练语料通过分词后，利用fastText训练Query的词向量，fastText训练时思考了字级别的Ngram特色，能够将未登录Query的字、词Embedding进行简略求和或求均匀，解决OOV（Out-Of-Vocabulary）的问题；② 在指标词表中，用词向量示意该词；③ 利用LSH，查找向量cosine类似度高于肯定阈值候选词，或应用DSSM双塔模型[7]，通过有监督训练进步精度；④ XGBoost联合特色工程进一步过滤。 BERT[8]自提出以来粗浅扭转了自然语言解决畛域的钻研利用生态，咱们尝试了一些应用BERT Embedding的办法，其中比拟无效的是通过Fine-Tuning的Sentence-BERT[9]或SimCSE[10]模型获取词向量。 BERT计算语义类似度是通过句间关系上游工作实现的，办法是用特殊字符将两个句子连接成一个整体做分类，带来的问题是应用时须要两两组合造成大量冗余计算，因而不适宜做语义类似度搜寻或无监督聚类工作。Sentence-BERT借鉴了孪生网络模型的框架，将不同的句子输出到两个参数共享的BERT模型中，获取到每个句子的表征向量，该向量能够用于语义类似度计算，也能够用于无监督的聚类工作。 咱们实际的办法根本与Sentence-BERT思维大致相同，应用下图中左图的办法结构有监督的改写对训练数据，用右图的办法在不同用意类型的历史搜寻Query进行向量计算。 相比于后面的办法，双塔构造BERT的办法捕获语义的能力更强，并且有监督训练的形式联合一些模型构造上的调整，可能缩小各类漂移重大的Case。此外Sentence-BERT不依赖统计特色和平行语料，在任何业务上均能够比拟不便的迁徙和Fine-Tuning，对一些冷启动的业务场景十分敌对。在此基础上利用Faiss[11]向量检索办法构建离线检索流程，可能反对在亿级别候选池中高效检索，通过该办法构建的改写候选能达到千万甚至亿级别数据量，且实测准确率较高。近几年的比照学习等办法在文本示意畛域一直刷新榜单，从向量构建和向量交互方式等方面均可做继续的摸索。 3.2 语义判断模型3.2.1 BERT语义判断模型从以上多个路径的开掘办法中能够失去千万级别的类似词对，但依然有大量语义漂移的Case，其中近义词漂移问题最为重大。起因是Embedding基于雷同上下文的假如太强，而近义词的上下文很类似，包含在商户和商户类目标上下文（一个商家通常会提供多种服务）以及用户Session换词的上下文类似（用户在某一类用意下屡次浏览用意下的概念），因而很容易挖掘出“大提琴”→“小提琴”这种同位词Case，并且加大了从用户点击行为或用意分类等其余维度过滤顽劣Case的难度。 ...

本文介绍了美团在如何解决大规模集群治理的难题、设计优良且正当的集群调度零碎方面的实际，论述了美团在落地以Kubernetes为代表的云原生技术时，比较关心的问题、挑战以及对应的推动策略。同时本文也介绍了针对美团业务需要场景做的一些特色反对，心愿本文可能对云原生畛域感兴趣的同学有所帮忙或者启发。导语集群调度零碎在企业数据中心中占有无足轻重的位置，随着集群规模与利用数量的一直激增，开发者解决业务问题的复杂度也显著晋升。如何解决大规模集群治理的难题，设计优良且正当的集群调度零碎，做到保稳固，降老本，提效率？本文将会逐个进行解答。 | 备注：文章最早公布于《新程序员003》云原生时代的开发者专栏。 集群调度零碎介绍集群调度零碎，又被称为数据中心资源调度零碎，广泛用来解决数据中心的资源管理和任务调度问题，它的指标是做到数据中心资源的无效利用，晋升资源的利用率，并为业务方提供自动化的运维能力，升高服务的运维治理老本。工业界比拟出名的集群调度零碎，如开源的OpenStack、YARN、Mesos和Kubernetes等等，再如出名互联网公司Google的Borg、微软的Apollo、百度的Matrix、阿里巴巴的Fuxi和ASI。 集群调度零碎作为各互联网公司外围的IaaS基础设施，在近十几年经验了屡次架构演进。随同着业务从单体架构向SOA（面向服务的架构）演进和微服务的倒退，底层的IaaS设施也从物理机裸机时代逐渐逾越到容器时代。尽管在演进过程中咱们要解决的外围问题没有扭转，但因为集群规模和利用数量的急剧收缩，问题的复杂度也成指数级增长。本文将论述大规模集群治理的挑战和集群调度零碎的设计思路，并以美团集群调度零碎落地实际为例，讲述通过打造多集群对立调度服务，继续晋升资源的利用率，提供Kubernetes引擎服务赋能PaaS组件，为业务提供更好的计算服务体验等一系列云原生实际。 大规模集群治理的难题家喻户晓，业务快速增长带来的是服务器规模和数据中心数量的暴增。对于开发者而言，在大规模集群调度零碎的业务场景下，必须要解决的两个难题是： 如何治理好数据中心大规模集群部署调度，特地是在跨数据中心场景下，如何实现资源的弹性和调度能力，在保障利用服务质量的前提下尽可能地晋升资源的利用率，充沛升高数据中心老本。如何革新底层基础设施，为业务方打造云原生操作系统，晋升计算服务体验，实现利用的自动化容灾响应和部署降级等，缩小业务方对底层资源管理的心智累赘，让业务方能够更专一于业务自身。经营大规模集群的挑战为了在实在的生产环境解决上述两个难题，具体又能够再拆分成以下四个大规模集群经营治理挑战： 如何解决用户多样化需要并疾速响应。业务的调度需要和场景丰盛且动静多变，作为集群调度零碎这样的平台型服务，一方面须要可能疾速交付性能，及时满足业务需要；另一方面还须要把平台打造得足够通用，将业务个性化需要形象为可落地到平台的通用能力，并长期进行迭代。这十分考验平台服务团队的技术演进布局，因为一不小心，团队就会陷入无休止的业务性能开发中，尽管满足了业务需要，却会造成团队工作低水平反复的景象。如何进步在线利用数据中心的资源利用率且同时保障利用服务质量。资源调度始终是业界公认的难题，随着云计算市场疾速倒退，各云计算厂商一直加大对数据中心的投入。数据中心的资源使用率却非常低，更加剧了问题的严重性。Gartner调研发现寰球数据中心服务器CPU利用率只有6%～12%，即便是亚马逊弹性计算云平台（EC2，Elastic Compute Cloud）也只有7%～17%的资源利用率，可见资源节约有多重大。究其原因，在线利用对于资源利用率十分敏感，业界不得不预留额定资源以保障重要利用的服务质量（QoS，Qualityof Service）。集群调度零碎须要在多利用混合运行时打消利用间的烦扰，实现不同利用之间的资源隔离。如何为利用，特地是有状态利用提供实例异样主动解决，屏蔽机房差别，升高用户对底层的感知。随着服务利用规模的继续扩充，以及云计算市场的日趋成熟，分布式应用往往会配置在不同地区的数据中心，甚至是逾越不同的云环境，实现了多云或混合云部署。而集群调度零碎须要为业务方提供对立的基础设施，实现混合多云架构，屏蔽底层的异构环境。同时升高利用运维治理的复杂性，晋升利用的自动化水平，为业务提供更好的运维体验。如何解决单集群过大或集群数量过多，而带来的与集群治理相干的性能和稳定性危险。集群自身的生命周期治理复杂度会随同集群规模和数量的增多而增大。以美团为例，咱们所采取的两地多核心多集群计划，尽管在肯定水平上躲避了集群规模过大的隐患，解决了业务隔离性、地区提早等问题。随着边缘集群场景和数据库等PaaS组件上云需要的呈现，能够预感小集群数量将会有显著的上涨趋势。随之带来的是集群治理复杂度、监控配置老本、运维老本的明显增加，这时集群调度零碎须要提供更无效的操作标准，并保障操作安全性、报警自愈和变更效率。设计集群调度零碎时的取舍为了解决上述挑战，一个好的集群调度器将施展关键作用。但事实中从来不存在一个完满的零碎，所以在设计集群调度零碎时，咱们须要依据理论场景在几个矛盾中做出取舍： 集群调度零碎的零碎吞吐量和调度品质。零碎吞吐量是咱们通常评估一个零碎好坏很重要的规范，但在面向在线服务的集群调度零碎里更重要的是调度品质。因为每次调度后果的影响是长期的（数天、数周甚至数月），非异常情况不会调整。所以如果调度后果谬误，会间接导致服务时延增高。而调度品质越高则意味着须要思考的计算约束条件越多，而且调度性能越差的话，零碎吞吐量越低。集群调度零碎的架构复杂度和可扩展性。系统对下层PaaS用户凋谢的性能和配置越多，通过反对更多功能来晋升用户体验（比方反对利用资源抢占回收和利用实例异样自愈），也就意味着零碎复杂度越高，各子系统越容易发生冲突。集群调度零碎的可靠性和单集群规模。单集群规模越大，则可调度范畴则越大，但对集群的可靠性挑战也越大，因为爆炸半径会减少，呈现故障的影响也越大。单集群规模较小的状况下，尽管能够晋升调度并发度，但可调度范畴变小，调度失败概率变高，且集群治理复杂度变大。目前，业内的集群调度零碎依照架构辨别，能够分为单体式调度器、两级调度器、共享状态调度器、散布式调度器和混合调度器这五种不同架构（见下图1），都是依据各自的场景需要做了不同的抉择，没有相对的好与坏。 单体式调度器应用简单的调度算法联合集群的全局信息，计算出高质量的搁置点，不过提早较高。如Google的Borg零碎、开源的Kubernetes零碎。两级调度器通过将资源调度和作业调度拆散，解决单体式调度器的局限性。两级调度器容许依据特定的利用做不同的作业调度逻辑，且同时放弃了不同作业之间共享集群资源的个性，可是无奈实现高优先级利用的抢占。具备代表性的零碎是Apache Mesos和Hadoop YARN。共享状态调度器通过半分布式的形式来解决两级调度器的局限性，共享状态下的每个调度器都领有一份集群状态的正本，且调度器独立对集群状态正本进行更新。一旦本地的状态正本发生变化，整个集群的状态信息就会被更新，但继续资源争抢会导致调度器性能降落。具备代表性的零碎是Google的Omega和微软的Apollo。散布式调度器应用较为简单的调度算法以实现针对大规模的高吞吐、低提早并行任务搁置，但因为调度算法较为简单并不足全局的资源应用视角，很难达到高质量的作业搁置成果，代表性零碎如加州大学的Sparrow。混合调度器将工作负载扩散到集中式和分布式组件上，对长时间运行的工作应用简单算法，对短时间运行的工作则依赖于分布式布局。微软Mercury就采取了这种这种计划。所以，如何评估一个调度零碎的好坏，次要取决于理论的调度场景。以业内应用最宽泛的YARN和Kubernetes为例，尽管两个零碎都是通用资源调度器，实际上YARN专一于离线批处理短工作，Kubernetes专一于在线长时间运行的服务。除了架构设计和性能的不同（Kubernetes是单体式调度器，YARN是两级调度器），二者的设计理念和视角也不同。YARN更专一工作，关注资源复用，防止近程数据屡次拷贝，指标是以更低成本、更高速度执行工作。Kubernetes更专一服务状态，关注错峰、服务画像、资源隔离，指标是保障服务质量。 美团集群调度零碎演变之路美团在落地容器化的过程中，依据业务场景需要，集群调度系统核心引擎由OpenStack转变为Kubernetes，并在2019年底实现了在线业务容器化覆盖率超过了98%的既定目标。但仍然面临资源利用率低、运维老本低等问题： 集群整体的资源利用率不高。如CPU资源均匀利用率还处于业内平均水平，相较于其余一线互联网公司差距较大。有状态服务的容器化率水平不够，特地是MySQL、Elasticsearch等产品没有应用容器，业务运维老本和资源老本存在较大的优化空间。从业务需要思考，VM产品会长期存在，VM调度和容器调度是两套环境，导致团队虚拟化产品运维老本较高。因而，咱们决定开始对集群调度零碎进行云原生革新。打造一个具备多集群治理和自动化运维能力、反对调度策略举荐和自助配置、提供云原生底层扩大能力，并在保障利用服务质量的前提下晋升资源使用率的大规模高可用调度零碎。外围工作围绕保稳固、降老本、提效率三大方向来构建调度零碎。 保稳固：晋升调度零碎的健壮性、可观测性；升高零碎各模块之间的耦合，缩小复杂度；晋升多集群治理平台的自动化运维能力；优化系统核心组件性能；确保大规模集群的可用性。降老本：深度优化调度模型，买通集群调度和单机调度链路。从资源动态调度转向资源动静调度，引入离线业务容器，造成自由竞争与强控联合，在保障高优业务利用服务质量的前提下，晋升资源使用率，升高IT老本。提效率：反对用户自助调整调度策略，满足业务个性化需要，踊跃拥抱云原生畛域，为PaaS组件提供包含编排、调度、跨集群、高可用等外围能力，晋升运维效率。 最终，美团集群调度零碎架构依照畛域划分为三层（见上图2），调度平台层、调度策略层、调度引擎层： 平台层负责业务接入，买通美团基础设施，封装原生接口和逻辑，提供容器治理接口（扩容、更新、重启、缩容）等性能。策略层提供多集群对立调度能力，继续优化调度算法和策略，联合业务的服务等级和敏感资源等信息，通过服务分级晋升CPU使用率和分配率。引擎层提供Kubernetes服务，保障多个PaaS组件的云原生集群稳定性，并把通用能力下沉到编排引擎，升高业务云原生落地的接入老本。通过精细化经营和产品性能打磨，咱们一方面对立纳管了美团近百万的容器/虚拟机实例，另一方面将资源利用率从业内平均水平晋升到了一流程度，同时还撑持了PaaS组件的容器化和云原生落地。 多集群对立调度：晋升数据中心资源利用率评估考核集群调度零碎的好坏，资源利用率是最重要的指标之一。因而，尽管咱们在2019年实现了容器化，不过容器化不是目标，只是伎俩。咱们的指标是通过从VM技术栈切换到容器技术栈，为用户带来更多的收益，比方全面升高用户的计算成本。 而晋升资源利用率受限于集群的个别热点宿主，一旦扩容，业务容器就有可能扩容到热点宿主，业务的性能指标如TP95耗时会呈现稳定，以至于咱们只能像业界其余公司一样，通过减少资源冗余来保障服务质量。究其原因，Kubernetes调度引擎的调配形式仅简略思考了Request/Limit Quota（Kubernetes为容器设定了申请值Request和束缚值Limit，作为用户申请容器的资源配额），属于动态资源分配。导致不同宿主机尽管调配了同样多的资源，却因宿主机的服务差异性使得宿主机的资源利用率也存在较大的差别。 在学术界和工业界中，有两种罕用的办法解决资源应用效率和利用服务质量之间的矛盾。第一种办法是通过高效的任务调度器在全局角度解决；第二种办法是通过单机资源管理伎俩来增强利用之间的资源隔离。不论是哪一种办法，都意味着咱们须要全面把握集群状态，所以咱们做了三件事： 系统地建设了集群状态、宿主状态、服务状态的关联，并联合调度仿真平台，综合思考了峰值利用率和均匀利用率，实现了基于宿主历史负载和业务实时负载的预测和调度。通过自研的动静负载调节零碎和跨集群重调度零碎，实现了集群调度和单机调度链路的联动，依据业务分级实现了不同资源池的服务质量保障策略。通过三版迭代，实现了自有集群联邦服务，较好地解决了资源预占和状态数据同步问题，晋升了集群间的调度并发度，实现了计算拆散、集群映射、负载平衡和跨集群编排管制（见下图3）。 集群联邦服务第三版本（图3）依照模块拆分为Proxy层和Worker层，独立部署： Proxy层会综合集群状态的因子及权重抉择适合的集群进行调度，并抉择适合的Worker散发申请。Proxy模块应用etcd做服务注册、选主和发现，Leader节点负责调度时预占工作，所有节点都能负责查问工作。Worker层对应解决一部分Cluster的查问申请，当某集群工作阻塞，能够疾速扩容一台对应的Worker实例缓解问题。当单集群规模较大时会对应多个Worker实例，Proxy将调度申请分发给多个Worker实例解决，晋升调度并发度，并缩小每一个Worker的负载。最终通过多集群对立调度，咱们实现了从动态资源调度模型转向动静资源调度模型，从而升高了热点宿主比例，缩小了资源碎片比例，保障了高优业务利用的服务质量，将在线业务集群的服务器CPU利用率均值晋升了10个百分点。集群资源利用率均值计算形式：Sum(nodeA.cpu.以后应用核数 + nodeB.cpu.以后应用核数 + xxx) / Sum(nodeA.cpu.总核数 + nodeB.cpu.总核数 + xxx），一分钟一个点，当天所有值取均匀。 调度引擎服务：赋能PaaS服务云原生落地集群调度零碎除了解决资源调度的问题之外，还解决服务应用计算资源的问题。正如《Software Engineering at Google》一书中提到的，集群调度零碎作为Compute as a Service中要害组件之一，既要解决资源调度（从物理机拆解到CPU/Mem这样的资源维度）和资源竞争（解决“吵闹街坊”），还须要解决利用治理（实例自动化部署、环境监控、异样解决、保障服务实例数、确定业务需要资源量、不同服务品种等）。而且从某种程度上来说利用治理比资源调度更重要，因为这会间接影响业务的开发运维效率和服务容灾成果，毕竟互联网的人力老本比机器老本更高。 简单的有状态利用的容器化始终是业界难题，因为这些不同场景下的分布式系统中通常保护了本人的状态机。当利用零碎产生扩缩容或降级时，如何保障以后已有实例服务的可用性，以及如何保障它们之间的可连通性，是相较无状态利用简单许多的辣手问题。尽管咱们曾经把无状态服务都容器化了，但咱们还没有充分发挥出一个良好的集群调度零碎的全副价值。如果要想管好计算资源，必须治理好服务的状态，做到资源和服务拆散，晋升服务韧性，而这也是Kubernetes引擎所善于的。 咱们基于美团优化定制的Kubernetes版本，打造了美团Kubernetes引擎服务MKE： 增强集群运维能力，欠缺了集群的自动化运维能力建设，包含集群自愈、报警体系、Event日志剖析等，继续晋升集群的可观测性。竖立重点业务标杆，与几个重要的PaaS组件深刻单干，针对用户的痛点如Sidecar降级治理、Operator灰度迭代、报警拆散做疾速优化，满足用户的诉求。继续改良产品体验，继续优化Kubernetes引擎，除了反对用户应用自定义Operator之外，也提供了通用的调度和编排框架（见图4），帮忙用户以更低的老本接入MKE，取得技术红利。 在咱们推动云原生落地过程中，一个宽泛被关注的问题是：基于Kubernetes云原生形式来治理有状态利用，相比于之前本人打造治理平台有什么区别？ 对于这个问题，须要从问题本源——可运维性思考： 基于Kubernetes意味着零碎做到了闭环，不必放心两套零碎经常出现的数据不统一问题。异样响应能够做到毫秒级别，升高了零碎的RTO（Recovery Time Objective，即复原工夫指标，次要指所能容忍的业务进行服务的最长工夫，也是从劫难产生到业务零碎复原服务性能所须要的最短时间周期）。零碎运维复杂度也升高了，服务做到了自动化容灾。除了服务自身之外，服务依赖的配置和状态数据都能够一起复原。相比于之前各个PaaS组件“烟囱式”的治理平台，通用能力能够下沉到引擎服务，缩小开发保护老本，而通过依靠于引擎服务，能够屏蔽底层异构环境，实现跨数据中心和多云环境的服务治理。将来瞻望：构建云原生操作系统咱们认为，云原生时代的集群治理，会从之前的治理硬件、资源等职能全面转变为以利用为核心的云原生操作系统。以此为指标，美团集群调度零碎还需从以下几方面发力： 利用链路交付治理。随着业务规模和链路复杂度的增大，业务所依赖的PaaS组件和底层基础设施的运维复杂度早已超过广泛认知，对于刚接手我的项目的新人更是难上加难。所以咱们须要反对业务通过申明式配置交付服务并实现自运维，给业务提供更好的运维体验，晋升利用的可用性和可观测性，缩小业务对底层资源管理的累赘。边缘计算解决方案。随着美团业务场景的不断丰富，业务对边缘计算节点的需要增长，比预期快很多。咱们会参考业内最佳实际，造成适宜在美团落地的边缘解决方案，尽快为有需要的服务提供边缘计算节点治理能力，实现云边端协同。在离线混部能力建设。在线业务集群的资源利用率晋升是有下限的，依据Google在论文《Borg: the Next Generation》中披露的2019年数据中心集群数据，刨去离线工作，在线工作的资源利用率仅为30%左右，这也阐明了再往上晋升危险较大，投入产出比不高。后续，美团集群调度零碎将继续摸索在离线混部，不过因为美团的离线机房绝对独立，咱们的施行门路会与业界的广泛计划有所不同，会先从在线服务和近实时工作的混部开始，实现底层能力的构建，再摸索在线工作和离线工作的混部。总结美团集群调度零碎在设计时，整体遵循适合准则，在满足业务根本需要的状况下，保证系统稳固后再逐步完善架构，晋升性能和丰盛性能。因而，咱们抉择了： 在零碎吞吐量和调度品质中咱们抉择优先满足业务对系统的吞吐量需要，不适度谋求单次调度品质，而是通过重调度调整欠缺。在架构复杂度和可扩展性中咱们抉择升高零碎各模块之间的耦合，缩小零碎复杂度，扩大性能必须可降级。在可靠性和单集群规模中咱们抉择通过多集群对立调度来管制单集群规模，保障系统可靠性，缩小爆炸半径。将来，咱们也会依据同样的逻辑继续优化迭代美团的集群调度零碎，彻底转变为以利用为核心的云原生操作系统。 作者简介谭霖，来自美团根底研发平台/根底技术部。 浏览美团技术团队更多技术文章合集 前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试 ...

在2022年春节到来之际，咱们精选过来一年公众号50多篇技术文章以及20多篇国内顶会论文，整顿制作成一本厚达1200多页的电子书，作为新年礼物赠送给大家。这本电子书内容笼罩前端、后端、算法、数据、平安、测试等多个畛域，心愿能对同学们的工作和学习有所帮忙。新年将至，年味渐浓。尽管疫情的阴郁还没彻底消散，然而置信很多人都对2022年的春天充斥了期待。期待春暖花开，期待国泰民安，期待早一天在阳光下自在地呼吸。 老规矩，一年一度的美团技术年货如期而至。 在2022年春节到来之际，咱们精选过来一年公众号50多篇技术文章以及20多篇国内顶会论文，整顿制作成一本厚达1200多页的电子书，作为新年礼物赠送给大家。 这本电子书内容笼罩前端、后端、算法、数据、平安、测试等多个畛域， 心愿能对同学们的工作和学习有所帮忙。 大家如果感觉有价值，也欢送转给更多有雷同趣味、踊跃上进的共事和敌人们，一起切磋，独特成长。 最初，祝大家阖家欢乐，衰弱安全。新的一年，「虎」力全开，走出个「龙行虎步」，闯出个「虎虎生威」！ 如何获取？关注「美团技术团队」微信公众号，回复 【2021年货】，即可获取电子书的下载链接，大家可收费在线浏览、下载。 舒适提醒：往年，咱们不仅为大家筹备了2021年的年度合集，同时咱们将2019年到2021年美团技术团队前端、后端、算法的文章进行了分类整理，同时将平安、运维、测试相干的文章做了综合，大家能够选择性下载或者浏览。 2021美团技术年货合辑：共1250页，约108M；2019年-2021年前端篇：共735页，约52M；2019年-2021年后端篇：共950页，约65M；2019年-2021年算法篇：共920页，约75M；2019年-2021年综合篇：共475页，约37M。因文件较大，可能须要一点急躁。因局部文章中的动静图片无奈在电子书中进行齐全的展现，大家能够移步美团技术团队官网博客 tech.meituan.com 或在美团技术团队公众号历史文章中进行查阅，感谢您的了解。 往期技术年货微信扫一扫，辨认文末的二维码，关注「美团技术团队」微信公众号，回复【2020年货】、【2019年货】、 【2018年货】、【2017年货】，即可获取往期年货下载链接。

CDN曾经成为互联网重要的基建之一，越来越多的网络服务离不开CDN，它的稳定性也间接影响到业务的可用性。CDN的容灾始终由美团的SRE团队在负责，在端侧鲜有计划和实际。本文联合美团外卖业务中的具体实际，介绍了一种在端侧感知CDN可用性情况并进行主动容灾切换的计划，通过该计划可无效升高业务对CDN异样的敏感，进步业务的可用性，同时升高CDN运维压力。心愿本计划可能对被CDN问题所困扰的同学有所帮忙或者启发。1. 前言作为业务研发，你是否遇到过因为 CDN 问题导致的业务图片加载失败，页面关上迟缓，页面布局错乱或者页面白屏？你是否又遇到过某些区域 CDN 域名异样导致业务停摆，客诉一直，此时的你一脸茫然，手足无措？作为 CDN 运维，你是否经常被业务方反馈的各种 CDN 问题搞得焦头烂额，一边顶着各种督促和压力寻求解决方案，一边埋怨着服务商的不靠谱？明天，咱们次要介绍一下美团外卖技术团队端侧 CDN 的容灾计划，通过实际，咱们发现该产品能无效缩小运维及业务开发同学的焦虑，心愿咱们的这些教训也可能帮忙到更多的技术团队。 2. 背景CDN 因可能无效解决因散布、带宽、服务器性能带来的网络拜访提早等问题，曾经成为互联网不可或缺的一部分，也是前端业务重大依赖的服务之一。在理论业务生产中，咱们通常会将大量的动态资源如 JS 脚本、CSS 资源、图片、视频、音频等托管至 CDN 服务，以享受其边缘节点缓存对动态资源的减速。然而在享受 CDN 服务带来更好体验的同时，也常常会被 CDN 故障所影响。比方因 CDN 边缘节点异样，CDN 域名封禁等导致页面白屏、排版错乱、图片加载失败。 每一次的 CDN 故障，业务方往往大刀阔斧，只能寄希望于 CDN 团队。而 CDN 的监控与问题排查，对 SRE 也是微小的难题和挑战。一方面，因为 CDN 节点的散布宽泛，边缘节点的监控就异样艰难。另一方面，各业务汇聚失去的 CDN 监控大盘，极大水平上隐匿了细节。小流量业务、定点区域的 CDN 异样往往会被吞没。SRE 团队也做了很多致力，设计了多种计划来升高 CDN 异样对业务的影响，也获得了肯定的成果，但始终有几个问题无奈很好解决： 时效性：当 CDN 呈现问题时，SRE 会手动进行 CDN 切换，因为须要人为操作，响应时长就很难保障。另外，切换后故障复原工夫也无奈精确保障。有效性：切换至备份 CDN 后，备份 CDN 的可用性无奈验证，另外因为 Local DNS 缓存，无奈解决域名劫持和跨网拜访等问题。精准性：CDN 的切换都是大范畴的变更，无奈针对某一区域或者某一我的项目独自进行。风险性：切换至备份 CDN 之后可能会导致回源，流量剧增拖垮源站，从而引发更大的危险。以后，美团外卖业务每天服务上亿人次，即便再小的问题在微小的流量背后，也会被放大成大问题。外卖的动态化架构，70%的业务资源都依赖于 CDN，所以 CDN 的可用性重大影响着外卖业务。如何更无效的进行 CDN 容灾，升高 CDN 异样对业务的影响，是咱们一直思考的问题。 既然以上问题 SRE 侧无奈完满地解决，端侧是不是能够进行一些尝试呢？比方将 CDN 容灾前置到终端侧。不死鸟（Phoenix） 就是在这样的构想下，通过前端能力建设，一直实际和欠缺的一套端侧 CDN 容灾计划。该计划不仅可能无效升高 CDN 异样对业务的影响，还能进步 CDN 资源加载成功率，现已服务整个美团多个业务和 App。 ...

美团外卖商家端基于 FlutterWeb 的技术摸索已久，目前在多个业务中落地了App、PC、H5的多端复用，无效晋升了产研的整体效率。在这过程中，性能问题是咱们面临的最大挑战，本文结合实际业务场景进行思考，介绍美团外卖商家端在 FlutterWeb 性能优化上所进行的摸索和实际，心愿对大家能有所帮忙或启发。一、背景1.1 对于FlutterWeb工夫回拨到 2018 年，Google 首次公开 FlutterWeb Beta 版，表露出要实现一份代码、多端运行的愿景。通过有数工程师两年多的致力，在今年年初（2021 年 3 月份），Flutter 2.0 正式对外公布，它将 FlutterWeb 性能并入了 Stable Channel，意味着 Google 更加动摇了多端复用的信心。 当然 Google 的“野心”不是没有底气的，次要体现在它弱小的跨端能力上，咱们看一下 Flutter 的跨端能力在 Web 侧是如何体现的： 上图别离是 FlutterNative 和 FlutterWeb 的架构图。通过比照能够看出，应用层 Framework 是专用的，意味着在 FlutterWeb 中咱们也能够间接应用 Widgets、Gestures 等组件来实现逻辑跨端。而对于渲染跨端，FlutterWeb 提供了两种模式来对齐 Engine 层的渲染能力：Canvaskit Render 和 HTML Render，下方表格对两者的区别进行了比照： Canvaskit Render 模式：底层基于 Skia 的 WebAssembly 版本，而下层应用 WebGL 进行渲染，因而能较好地保障一致性和滚动性能，但蹩脚的兼容性（WebAssembly 从 Chrome 57 版本才开始反对）是咱们须要面对的问题。此外 Skia 的 WebAssembly 文件大小达到了 2.5M，且 Skia 自绘引擎须要字体库反对，这意味着须要依赖超大的中文字体文件，对页面加载性能影响较大，因而目前并不举荐在 Web 中间接应用 Canvaskit Render（官网也倡议将 Canvaskit Render 模式用于桌面利用）。 ...

美团外部深度定制的TensorFlow版本，基于原生TensorFlow 1.x架构与接口，从大规模稠密参数的反对、训练模式、分布式通信优化、流水线优化、算子优化交融等多维度进行了深度优化。在举荐零碎场景，分布式扩展性晋升10倍以上，单位算力性能也有显著晋升，并在美团外部业务中大量应用，本文介绍了相干的优化与实际工作。1 背景TensorFlow（下文简称TF）是谷歌推出的一个开源深度学习框架，在美团举荐零碎场景中失去了宽泛的应用。但TensorFlow官网版本对工业级场景的反对，目前做得并不是特地的欠缺。美团在大规模生产落地的过程中，遇到了以下几方面的挑战： 所有参数都是用Variable表白， 对于百亿以上的稠密参数开拓了大量的内存，造成了资源的节约；只反对百级别Worker的分布式扩大，对上千Worker的扩展性较差；因为不反对大规模稠密参数动静增加、删除，增量导出，导致无奈反对Online Learning；大规模集群运行时，会遇到慢机和宕机；因为框架层不能解决，导会致工作运行异样。以上这些问题，并不是TensorFlow设计的问题，更多是底层实现的问题。思考到美团大量业务的应用习惯以及社区的兼容性，咱们基于原生TensorFlow 1.x架构与接口，从大规模稠密参数的反对、训练模式、分布式通信优化、流水线优化、算子优化交融等多维度进行了深度定制，从而解决了该场景的外围痛点问题。 首先新零碎在反对能力层面，目前能够做到千亿参数模型，上千Worker分布式训练的近线性减速，全年样本数据可能1天内实现训练，并反对Online Learning的能力。同时，新零碎的各种架构和接口更加敌对，美团外部包含美团外卖、美团优选、美团搜寻、广告平台、公众点评Feeds等业务部门都在应用。本文将重点介绍大规模分布式训练优化的工作，心愿对大家可能有所帮忙或启发。 2 大规模训练优化挑战2.1 业务迭代带来的挑战随着美团业务的倒退，举荐零碎模型的规模和复杂度也在快速增长，具体表现如下： 训练数据：训练样本从到百亿增长到千亿，增长了近10倍。稠密参数：个数从几百到几千，也增长了近10倍；总参数量从几亿增长到百亿，增长了10~20倍。模型复杂度：越来越简单，模型单步计算工夫增长10倍以上。对于大流量业务，一次训练试验，从几个小时增长到了几天，而此场景一次试验放弃在1天之内是根本的需要。 2.2 零碎负载剖析2.2.1 问题剖析工具链TensorFlow是一个十分宏大的开源我的项目，代码有几百万行之多，原生零碎的监控指标太粗，且不反对全局的监控，如果要定位一些简单的性能瓶颈点，就比拟艰难。咱们基于美团曾经开源的监控零碎CAT[2]，构建了TensorFlow的细粒度监控链路（如下图1所示），能够精准定位到性能的瓶颈问题。 同时，在性能优化的过程中，会波及到大量的性能测试和后果剖析，这也是一个十分消耗人力的工作。咱们形象了一套自动化的试验框架（如下图2所示），能够自动化、多轮次地进行试验，并主动采集各类监控指标，而后生成报告。 2.2.2 业务视角的负载剖析在举荐零碎场景中，咱们应用了TensorFlow Parameter Server[3]（简称PS）异步训练模式来反对业务分布式训练需要。对于这套架构，上述的业务变动会带来什么样的负载变动？如下图3所示： 总结来看，次要包含通信压力、PS并发压力、Worker计算压力。对于分布式系统来说，通常是通过横向扩大来解决负载问题。尽管看来起能够解决问题，但从试验后果来看，当PS扩大到肯定数量后，单步训练工夫反而会减少，如下图4所示： 导致这种后果的外围起因是：Worker单步训练须要和所有的PS通信同步实现，每减少1个PS要减少N条通信链路，这大大增加了链路提早（如下图5所示）。而一次训练要执行上百万、上千万步训练。最终导致链路提早超过了加PS算力并发的收益。 而对于这个零碎，优化的外围难点在于：如何在无限的PS实例下，进行分布式计算的优化。 3 优化实际3.1 大规模稠密参数介绍对于举荐零碎模型，绝大多数参数都是稠密参数，而对稠密参数来说有一个十分重要的操作是Embedding，这个操作通常也是负载最重的，也是后续优化的重点。因为咱们对稠密参数进行了从新定义，后续的优化也基于此之上，所以咱们先介绍一下这部分的工作。 在原生的TensorFlow中构建Embedding模块，用户须要首先创立一个足够装得下所有稠密参数的Variable，而后在这个Variable上进行Embedding的学习。然而，应用Variable来进行Embedding训练存在很多弊病： Variable的大小必须提前设定好，对于百亿千亿的场景，该设定会带来微小的空间节约；训练速度慢，无奈针对稠密模型进行定制优化。咱们首先解决了有无的问题，应用HashTable来代替Variable，将稠密特色ID作为Key，Embedding向量作为Value。相比原生应用Variable进行Embedding的形式，具备以下的劣势： HashTable的大小能够在训练过程中主动伸缩，防止了开拓冗余的存储空间，同时用户无需关注申请大小，从而升高了应用老本。针对HashTable计划施行了一系列定制优化，训练速度相比Variable有了很大的进步，能够进行千亿规模模型的训练，扩展性较好。得益于稠密参数的动静伸缩，咱们在此基础上反对了Online Learning。API设计上放弃与社区版本兼容，在应用上简直与原生Variable统一，对接老本极低。简化版的基于PS架构的实现示意如下图6所示： 外围流程大抵能够分为以下几步： 稠密特色ID（通常咱们会提前完成对立编码的工作）进入Embedding模块，借助TensorFlow搭建的Send-Recv机制，这些稠密特色ID被拉取到PS端，PS端上的Lookup等算子会理论从底层HashTable中查问并组装Embedding向量。上述Embedding向量被Worker拉回进行后续训练，并通过反向流传计算出这部分参数的梯度，这些梯度进一步被位于PS端的优化器拉回。PS端的优化器首先调用Find算子，从HashTable获取到梯度对应的原始稠密参数向量和相应的优化器参数，最终通过优化算法，实现对Embedding向量和优化器参数的更新计算，再通过Insert算子插入HashTable中。3.2 分布式负载平衡优化这部分优化，是分布式计算的经典优化方向。PS架构是一个典型的“水桶模型”，为了实现一步训练，Worker端须要和所有PS实现交互，因而PS之间的均衡就显得十分重要。然而在实践中，咱们发现多个PS的耗时并不平衡，其中的起因，既包含TensorFlow PS架构简略的切图逻辑（Round-Robin）带来的负载不平衡，也有异构机器导致的不平衡。 对于举荐模型来说，咱们的次要优化策略是，把所有稠密参数和大的浓密参数主动、平均的切分到每个PS上，能够解决大多数这类问题。而在实际过程中，咱们也发现一个比拟难排查的问题：原生Adam优化器，实现导致PS负载不平衡。上面会具体介绍一下。 在Adam优化器中，它的参数优化过程须要两个参加计算，在原生TensorFlow的实现中，这两个是所有须要此优化器进行优化的Variabl（或HashTable）所共享的，并且会与第一个Variable（名字字典序）落在同一个PS下面，这会带来一个问题：每个优化器只领有一个_1和一个_2，且仅位于某个PS上。因而，在参数优化的过程中，该PS会接受远高于其余PS的申请，从而导致该PS成为性能瓶颈。 然而通过观察Adam的优化算法，咱们能够看到_1和_2都是常量，且蓝色高亮的局部都是绝对独立的计算过程，各个PS之间能够独立实现。基于这样的发现，优化的办法也就十分直观了，咱们为每一个PS上的Adam优化器冗余创立了参数，并在本地计算t和alpha值，去除了因而负载不均导致的PS热点问题。 该优化所带来的晋升具备普适性且成果显著，在美团外部某业务模型上，通过热点去除能够带来9%左右的性能晋升。此外，因为解脱了对的全局依赖，该优化还能进步PS架构的可扩展性，在扩增Worker数量的时候相比之前会带来更好的减速比。 3.3 通信优化通过2.2章节的剖析可知，零碎的通信压力也十分大，咱们次要基于RDMA做了通信优化的工作。首先简略介绍一下RDMA，相比拟于传统基于套接字TCP/IP协定栈的通信过程，RDMA具备零拷贝、内核旁路的劣势，不仅升高了网络的提早，同时也升高了CPU的占用率，RDMA更适宜深度学习模型的相干通信过程。 RDMA次要包含三种协定Infiniband、RoCE(V1, V2)、iWARP。在美团外部的深度学习场景中，RDMA通信协议应用的是RoCE V2协定。目前在深度学习训练畛域，尤其是在浓密模型训练场景（NLP、CV等），RDMA曾经是大规模分布式训练的标配。然而，在大规模稠密模型的训练中，开源零碎对于RDMA的反对十分无限，TensorFlow Verbs[4]通信模块曾经很长时间没有更新了，通信成果也并不现实，咱们基于此之上进行了很多的改良工作。 通过优化后的版本，在1TB Click Logs[5]公开数据集、DLRM[6]模型、100个Worker以上的训练，性能晋升了20%~40%。在美团的多个业务模型上，比照TensorFlow Seastar[7]革新的通信层实现也有10%~60%的速度晋升。同时也把咱们的工作回馈给了社区。 3.3.1 Memory Registration优化RDMA有三种数据传输的形式SEND/RECV、WRITE、READ，其中WRITE、READ相似于数据发送方间接在近程Memory进行读写，Receiver无奈感知，WRITE和READ实用于批量数据传输。在TensorFlow外部，基于RDMA的数据传输方式应用的是WRITE单边通信模式。 在RDMA传输数据时，须要提前开拓内存空间并将其注册到网卡设施上（Memory Registration过程，下称MR），使得这片空间能够被网卡间接操作。开拓新的内存并注册到设施上，整个过程是比拟耗时的。下图9展现了不同大小的内存绑定到网卡设施上的耗时，能够看到随着注册内存的增大，绑定MR的耗时迅速减少。 社区版Tensorflow RDMA实现，Tensor创立仍旧沿用了对立的BFC Allocator，并将所有创立的Tensor都注册到MR上。正如下面所提到的，MR的注册绑定具备性能开销，高频、大空间的MR注册会带来显著的性能降落。而训练过程中的Tensor，只有那些波及到跨节点通信的Tensor有必要进行MR，其余Tensor并不需要注册到MR。因而，优化的办法也就比拟间接了，咱们辨认并治理那些通信Tensor，仅对这些跨节点通信的Tensor进行MR注册就好了。 3.3.2 RDMA动态分配器RDMA动态分配器是上一个MR注册优化的延长。通过Memory Registration优化，去除非传输Tensor的MR注册，咱们升高了MR注册数量。然而在稠密场景大规模的训练下，并行训练的Worker常有几百上千个，这会带来新的问题： ...

经典的细粒度情感剖析（ABSA，Aspect-based Sentiment Analysis）次要蕴含三个子工作，别离为属性抽取、观点抽取以及属性-观点对的情感偏向断定三个级联工作。本文介绍了美团到店到餐利用算法团队通过联合学界最先进的浏览了解、注意力机制等方面的实体抽取、情感剖析教训，解决到餐（菜品，属性，观点，情感）四元组抽取问题，并在多个业务场景利用落地，心愿能对从事相干工作的同学有所帮忙或启发。一、背景作为一家生存服务在线电子商务平台，美团致力于通过科技链接消费者和商户，致力为消费者提供品质生存。到店餐饮（简称到餐）作为美团的外围业务之一，是满足用户堂食生产需要、赋能餐饮商户在线经营的重要平台，在服务百万级别的餐饮商户和亿级别C端用户的过程中，积攒了海量的用户评论信息（User Generated Content, UGC），蕴含了用户到店生产体验之后的真情实感，如果可能无效提取其中的要害的情感极性、观点表白，不仅能够辅助更多用户做出生产决策，同时也能够帮忙商户收集经营情况的用户反馈信息。 近年来，大规模预训练模型（BERT）、提醒学习（Prompt）等NLP技术飞速发展。文本分类、序列标注、文本生成各类自然语言解决工作的利用成果失去显著晋升，情感剖析便是其中最常见的利用模式之一。它的工作指标在于通过NLP技术手段对输出文本进行剖析、解决、演绎、推理，给出文本情感极性断定的后果。 依照情感极性断定粒度，能够细分为篇章/整句粒度情感剖析、细粒度情感剖析（ABSA, Aspect-based Sentiment Analysis）[1]。一般而言，细粒度情感剖析的工作指标次要围绕属性（Aspect Term）、观点（Opinion Term）、情感（Sentiment Polarity）三要素开展，能够拆分为属性抽取、观点抽取以及属性-观点对的情感偏向断定三个级联工作[2-5]。例如，对于给定的用户评论“这家店环境不错，但服务很蹩脚”，预期的输入后果为（环境，不错，正向）、（服务，蹩脚，负向）。 到餐算法团队联合到餐业务供应侧、平台侧、需要侧的业务场景，为外围业务链路的智能化提供高效、优质的算法解决方案，通过算法能力辅助业务降本提效。本文联合到餐B/C端业务场景，摸索细粒度情感剖析技术在用户评估开掘方向的利用实际。 二、指标回顾2.1 业务问题秉承“帮大家吃得更好，生存更好”的使命，到餐面向消费者提供包含套餐、代金券、买单、预订等在内的丰盛产品和服务，并通过黑珍珠餐厅指南、公众点评必吃榜等榜单，以及搜寻、查问、评估等，帮忙消费者更好地作出生产决策。同时，为商家提供一站式的营销服务，帮忙餐饮商户积淀口碑、获取用户、减少复购等，进而轻松治理餐厅。 随着餐饮连锁化减速、行业竞争格局强烈，商户治理宽幅和难度逐渐加大，商户的经营要求更加精密，数据管理意识更加迫切。用户历史评论中蕴含着大量用户生产后的反馈，是情感剖析的重要组成部分，不仅可能形容生产感触，同时也能反映出就餐环境的好坏。因而，做好情感剖析有利于帮忙餐饮门店晋升服务质量，也可能更好地促成生产体验。 UGC评估剖析，次要是从评论文本中挖掘出菜品、服务、食品安全（简称食安）等方面相干信息，获取用户在各个维度的细粒度情感，粗疏刻画商家的服务现状，如上图2所示。对于餐饮商户，菜品、服务、食安评估剖析问题能够拆解如下： 菜品评估，次要包含用户评论中的菜品辨认、评估属性提取、菜品观点提取、观点情感分类；服务评估，次要包含用户评论中评估属性提取、服务方面观点提取、观点情感分类；食安评估，次要包含用户评论中评估属性提取、食安方面观点提取、观点情感分类。其中问题2和3是典型的三元组抽取工作，即辨认服务或食安方面的（属性，观点，情感）。对于问题1，在服务、食安评估问题的根底上，菜品评估须要辨认评论中提及的菜品，相比业界四元组（属性，观点，属性类别，情感）[6]抽取工作，到餐场景下次要为 (菜品，属性，观点，情感）四元组的辨认。 2.2 技术调研在美团外部，咱们针对UGC评估剖析问题，调研了相干工作成绩，次要为基于MT-BERT预训练模型开发了多任务模型，试图解决情感剖析中的ACSA (Aspect-Category Setiment Analysis) 问题以及（属性，观点，情感）三元组抽取问题，并实现了句子粒度的情感分类工具开发，同时开源了基于实在场景的中文属性级情感剖析数据集ASAP[7-9]。但对于美团到餐业务来说，咱们须要基于具体场景提出针对性的解决方案，如四元组抽取工作，不能间接复用其余团队的相干技术和工具，因而有必要建设服务于到餐业务场景的细粒度情感剖析技术。 在业界，咱们也调研了行业其余团队如腾讯、阿里在细粒度情感剖析方面的相干钻研。2019年腾讯AI Lab和阿里达摩院单干[3]，提出了基于两个重叠的LSTM和三个组件（边界疏导、情感一致性和意见加强）的模型，将“BIOES”标注体系与情感正向（Positive）、中性（Neutral）、负向（Negative）联合造成对立标签，能够同时辨认属性和情感。同年，阿里达摩院提出了BERT+E2E-ABSA模型构造，进一步解决属性和情感的联结抽取问题[10]，同时提出（属性，观点，情感）[2]三元组抽取工作，并给出了两阶段解决框架，首先别离辨认出属性（情感交融为对立标签）和观点，而后判断属性-观点是否配对。 自此，业界后续钻研开始向三元组联结抽取开展[11-14]。2021年2月，华为云[6]提出（属性，观点，属性类别，情感）四元组抽取多任务模型，其中一个工作辨认属性和观点，另一个工作辨认属性类别和情感。2021年4月，腾讯[15]引入Aspect-Sentiment-Opinion Triplet Extraction （ASOTE）工作，提出了一个地位感知的BERT三阶段模型，解决了（属性，观点，情感）三元组抽取问题。 调研机构行业预训练模型细粒度情感剖析问题浏览了解问题三元组问题四元组问题联结抽取问题阿里达摩院[2,10]电子商务✓✓✗✓✗✓华为云[6]云服务✓✓✗✗✓✓腾讯[15]社交✓✓✗✓✗✗美团到餐本地生存✓✓✓✓✓✓从学术界来看，更关注于如何更好地进行实体抽取、情感分类以及多任务的联结抽取，可能会疏忽工业界落地更关注的计算时效性（如多维度标注与情感维度整合，减少计算、存储资源耗费，在无限资源下时长提早）、成果准确性（如工作模块端到端开发，疏忽业务的个性化，间接复用导致准确性升高）等方面要求，导致相干技术办法并不能间接利用于业务场景，须要进一步开发欠缺能力实现业务的落地。 如上表所示，针对以上调研，咱们借鉴了美团搜寻与NLP部在三元组细粒度情感剖析方面的教训，拆解到餐四元组抽取问题，并联合学界最先进的浏览了解、注意力机制等方面的实体抽取、情感分类教训，设计开发了利用于到餐业务的细粒度情感剖析解决方案。 2.3 技术指标如上文所述，菜品评估次要关注菜品、评估属性、菜品观点和观点情感，而服务、食安评估问题，次要关注服务或食安方面的评估属性、观点和情感。就细粒度情感剖析工作而言，能够看出，前一个问题波及四元组信息，而后两个问题仅波及三元组信息。 2.4 次要挑战因为三元组问题能够看作是四元组问题的子问题，不失一般性，下文将重点论述四元组相干技术挑战。 问题3：如何同时对四元组抽取、辨认，缩小pipeline办法的谬误累计影响？ 缩小pipeline办法的谬误累计影响，典型的解决方案是提出同时解决信息抽取和分类工作，即多任务学习。传统的办法是间接尝试多任务学习的思路，但过程中疏忽了实体间依赖的关系，甚至近程关联关系[2]。以后也在尝试间接将四元组转化成多任务学习过程，未来冀望通过建设实体间pair或triplet关系，进行联结抽取、辨认。 综上，对于问题1和问题2，咱们会依照pipeline辨认的后果，再利用策略进行抽取后果的优化；对于问题3，整合实体、关系及分类工作，进行联结学习，将有助于缩小pipeline办法的谬误累计影响。 三、细粒度情感剖析实际3.1 Pipeline办法如上文2.3的问题2所述，咱们采纳pipeline的办法，将四元组抽取问题拆解为三个工作，分为实体辨认、观点抽取、观点类别和情感分类，如下图4所示： 3.1.1 实体辨认自2018年BERT[16]呈现当前，NER模型由传统的LSTM+CRF替换为BERT+CRF（或者BERT+LSTM+CRF），一度是业界NER工作的SOTA模型，近两年来NER工作次要从以下两个方面进行改良： 退出额定的特色[17-19]：如字特色、词特色、词性特色、句法特色、常识图谱表征；转换工作模式[20-21]：将NER工作转化为问答（QA, Question Answering）工作或者机器翻译工作。思考到引入额定特色须要构建人工词典，以及转化问答工作模式依赖于人工模板，老本较高，因而采纳BERT+CRF模型。 学习率调整，模型策略调优。在试验过程中，咱们发现BERT+CRF相比简略的BERT+Softmax成果晋升甚微，究其原因，因为预训练模型通过微调之后能够学习到具备显著区分度的特色，导致减少CRF层对实体辨认后果简直没有影响。然而，一个好的CRF转移矩阵显然对预测是有帮忙的，能够为最初预测的标签增加束缚来保障预测后果的合理性。进一步试验后发现，通过调整BERT和CRF层的学习率，如BERT应用较小的学习率而CRF层应用100倍于BERT的学习率 （即$e2/e1>100$，如图5所示），最终BERT+CRF的成果相比BERT+Softmax有了较显著的晋升。此外，在传统NER模型LSTM+CRF根底上，咱们也试验了BERT+LSTM+CRF，但成果竟然有些许降落，而且预测工夫也减少了，因而最终没有引入LSTM层。 3.1.2 观点抽取观点抽取工作在业界也称为Target-oriented Opinion Words Extraction（TOWE），旨在从评论句子中抽取出给定指标对应的观点词。观点抽取也能够看作是一种NER工作，但若评论波及多个实体和观点，如何精确抽取所有“实体-观点”关系是一个技术挑战。借鉴MRC（Machine Reading Comprehension）工作的思维，通过构建正当的Query引入先验常识，辅助观点抽取。 QA工作模式，观点抽取建模。如图6所示，模型整体由预训练层和输入层两局部组成。输入层咱们应用了惯例QA工作输入，包含开始标签（Start Label）和完结标签（End Label），但须要人工设计Quey。参考论文[20]教训，以图3为例，试验发现Query设计为“找出鲜虾馅饺子口味、口感、重量、食材、卖相、价格、卫生以及整体评估”成果最好，可能融入了观点形容信息，更加有助于观点抽取。思考到QA工作人造有类别不均衡的问题，因而损失函数引入针对类别不均衡的Focal Loss，用于晋升观点抽取模型的成果。因为观点抽取也能够看作是NER工作，故咱们尝试将输入层设计为CRF层，但试验成果并不现实，可能因为观点语句长度不一且比拟个性化，影响模型辨认。另一方面，思考到Google中文预训练模型BERT是以字粒度为切分，没有思考到传统NLP中的中文分词，在预训练层咱们将BERT模型替换为哈工大开源的中文预训练模型，如BERT-wwm-ext、RoBERTa-wwm等，最终模型成果获得进一步晋升。 ...

2019年9月，美团外卖技术团队联结多个研发部门正式推出了React2X，面向所有的前端研发人员，特地是按业务畛域划分的团队，为大家提供一个残缺的、凋谢的多终端容器无关化（Containerless）研发框架。研发同学能够通过React2X框架疾速创立、开发、构建、部署我的项目，在人力耗费最小的前提下，以期在不同终端上达到绝对最佳的性能体验，并且能大幅升高因容器降级带来的替换和革新老本，让代码同构的复用率最大化。终端容器无关化（Containerless）：与服务无关化（Serverless）的概念相似，即在放弃顶层业务研发语言不变更的状况下，在上层能够兼容性地降级、替换终端容器的能力，让用户无需关怀终端容器的运维，只有将精力聚焦到业务逻辑上的技术。 一、前言React2X是一款面向多终端、跨平台、容器无关化研发框架。在整个美团前端技术栈日益标准的趋势下，React技术栈在咱们技术体系环节中的位置变得越来越重要。在广告、营销这些推广属性的业务上，在各个终端（包含美团App、美团外卖App、公众点评App，以及站外的微信小程序、百度小程序、头条&抖音小程序等其余终端）实现“一次开发，同步需要上线”的业务诉求也变得越来越多。在这样的背景下，咱们定义了React2X利用的外围场景： 面对美团外部丰盛多样的技术容器体系（Mach、MRN、Titans、MTFlutter、MMP等），如何保障跨容器开发体验的一致性，以及建设跨容器利用开发的生态能力，是咱们须要解决的问题。公司内丰盛的终端容器化技术蓬勃发展，而因业务降级带来的革新老本也比拟大，亟待一款高扩展性设计的顶层框架作为技术抓手。跨容器动态化能力笼罩，逐渐成为各个业务方越来越器重的根底能力，能够大幅缩短需要交付的周期，进步上线发版的效率，并能无效地解决包体积大小的问题，晋升业务的敏捷性。多场景下的同构诉求，例如在各种推广页、模块化、游戏、轻量布局差别的PC/App同构场景下，能够节俭多端研发的人力。最终咱们的外围痛点围绕在了美团系·小程序和美团系·App矩阵上的同一个需要的屡次开发运维上，为了解决研发人力瓶颈问题，咱们须要一款“一次研发，多终端容器复用”的研发框架来晋升研发效率。 调研整个前端畛域，咱们找到了一些业界的解决方案，像是美团最早的mpvue、腾讯的Wepy、滴滴的Chameleon、京东的Taro等等。在通过比拟与试用之后，咱们最终基于投入产出比的价值判断，抉择站在伟人的肩膀上研发定制一款满足美团技术、业务场景的研发框架——React2X（前面简称R2X）。从R2X第一个版本公布到当初，曾经承受了来自于公司各个业务两年多的考验。所以咱们心愿通过本文帮忙大家对R2X有一个大抵的理解。 二、指标与场景2.1 外围指标为了解决业务需要在多端容器须要反复开发的难题，通过代码复用实现开发提效，咱们确定了以下的指标： 解决公司外部多终端容器开发痛点：实现Webview容器、小程序容器、MRN容器、Mach容器、游戏容器、局部经营推广场景PC容器的代码同构复用，对立开发标准，抹平开发差别，并提供对其余容器的扩大能力。建设跨容器动态化能力：跨容器动态化能力的缺失，导致产品不可能通过疾速迭代来验证需要的成果，这个问题重大限度了业务的倒退。跨容器动态化能力能够解决美团外卖业务端上发版和包体的问题，帮忙业务实现疾速发版上线、线上问题热修复、以及容灾的能力。建设容器无关的开发生态体系：R2X最终要解决的是容器差异性，进行对立的技术生态能力建设，为多终端容器开发场景晋升生产和运维效率。2.2 利用场景R2X开发框架次要冀望能最终面向多终端利用的终端容器，用于场景化研发： 即： 业务我的项目基于React语法为技术框架根底。业务方有在多终端/多容器（包含MRN容器、Webview容器、MP容器、Flutter容器、Mach容器、PC浏览器容器）运行的需要。业务方有特定的场景化诉求，包含推广页、模块化、小游戏、PC/App同构等等。三、挑战与劣势3.1 业界调研针对上述外围指标和利用场景，咱们对市面上的跨容器框架进行了调研。因为美团外卖的技术栈对立是React为主，所以咱们的必备要求是：一款以React为DSL语言的复用框架，能疾速融入美团的技术生态。 依据下表的比照，如果以React为DSL语言登程，过后就只有Taro一家能满足咱们的业务诉求，但它的生态环境并不适宜在美团体系内应用。基于多方面因素的思考，咱们决定联合各大支流框架之所长，而后开发出一款属于美团外卖的跨容器复用框架。 比照项mpvueTaro 1.3ChameleonWePYUniAppDSLVue类React（Nerv）类VueVueVue是否反对 React Native否是，但反对成果不佳Weex否否兼容 API无有（API反对水平不一）自研多态协定无是跨端组件库无有有无无美团生态有无无无无语法校验无ESLint自研无有TypeScript有有无有有定制化扩大无可自研Plugin无无有编译扩大无无无无有调研论断不匹配局部满足局部满足不匹配不匹配注：后期调研工夫截止到2019年05月，可能与以后数据存在肯定的出入。 3.2 技术挑战当咱们决定要打造一款属于美团外卖的跨容器复用框架之后，在实现的过程中次要遇到了以下挑战： ① 各个容器之间差异性适配老本 语法语义：MRN/小程序/Webview在DSL上就有着齐全不同的语法语义。端能力：同一容器在不同端上体现也存在不少差别，比方外卖App中MRN容器和美团App中MRN容器别离有定制的Native模块以及各类桥协定等。② 业务接入的应用老本 首次老本：作为一个新定义的框架如何让新业务方疾速上手，如何从存量业务线进行迁徙。边际老本：如何交融美团的基建生态，让业务方疾速复用平台能力。③ 顶层架构的正当设计 高可维护性、高度扩展性：如何疾速降级、替换、新增一款底层容器。注：以上问题咱们会在下文“技术全景”章节中给予解答。 3.3 我的项目劣势3.3.1 性能特点比照目前，业界以小程序作为跨端指标平台的框架较多，但大多都是应用Web前端技术栈作为根底，但同时兼顾React Native的技术栈就比拟少。下表中列出的是反对以React、类React作为DSL的相干框架进行比照。 R2XTaro 1.3Taro 3.0RaxRemax原理R2X 1.0重编译时，R2X 2.0重运行时重编译时重运行时重运行时重运行时容器重点以MRN，小程序，WebView为主，同时反对MTFlutter、Mach、游戏、PC浏览器以小程序、Web为主，React Native反对不多以小程序、Web为主，React Native交给58团队反对小程序、Web、Flutter小程序、WebAPI反对KNB桥&对多平台API进行了对立对多平台API进行了对立对多平台API进行了对立多平台不对立多平台不对立跨端组件库有有TaroUI，但不反对React Native有TaroUI，但不反对React Native无无业务组件扩大提供扩大计划参考TaroUI参考TaroUI提供扩大计划提供扩大计划美团外部生态反对已反对埋点监控等无无无无模块化能力反对不反对不反对不反对不反对编译插件扩大反对不反对反对反对反对Webpack配置综上所述，从目前的业务状态来看，R2X在容器的匹配水平以及美团生态反对水平上看，是现阶段的最佳计划。R2X相较于业界其余框架来说，领有更加欠缺的实用于美团外卖团队的本地化实现。 3.3.2 性能数据比照基于业界跨平台框架和美团外部的跨平台框架，咱们针对性能也进行了Benchmark测试，最终比照后果如下。 小程序性能比照 框架创立更新增加替换删除R2X-MP947.6586.81467.21355.282.2Remax2798.21872.65162.24818.286.4Taro-MP1653.4976.42483.22256.665.2论断：能够看到，在小程序Benchmark测试后果中，R2X-MP是当先于Remax和Taro-MP。 与React Native性能比照 框架创立更新增加替换删除R2X-MRN309.87583.75384191.87582.125MRN297.625105.25400.125231.62565.875Taro-RN209.577.5246.2585.12517.125论断：在React Native的Benchmark测试后果中，R2X-MRN和MRN根本持平，但都低于纯React Native的性能体现。 3.3.3 同构场景比照除了反对了根本的React Native、小程序和Webview容器同构场景之外，R2X还实现了在MTFlutter、Mach、小游戏（Webview游戏、微信小游戏&小程序、美团小游戏）、PC浏览器等容器上的同构能力扩大，相比于业内的其余跨容器开发框架的生态也更加丰盛和健全。 React Native小程序WebviewFlutter模块级容器小游戏容器PC浏览器（PC/App同构）R2X反对反对反对反对反对反对反对Taro反对反对反对不反对不反对不反对不反对Rax反对反对反对不反对不反对不反对不反对Remax反对反对反对不反对不反对不反对不反对四、技术全景 上图为R2X的架构全景图，整体架构能够依照从下到上，从左到右的视角进行解读： 最上层是R2X的生态环境建设，在R2X外部去实现公司生态的罕用SDK以及业务中的各项专题能力；并通过搭建物料市场/插件市场，以业务共建的模式丰盛R2X生态。再下层是R2XCore的根基，通过解析Command命令来执行唤起构建器，并实现了相似Webpack的插件零碎，以插件化的模式组织驱动整个外围构建流程，便于保护以及扩大。再往上是跨端容器层，它是整个跨端能力的外围，通过实现了不同的容器插件来将R2X代码编译成各端可执行代码，并通过运行时能力对组件/API进行对齐。最上层是承载的App端，目前有美团外卖、公众点评、美团等多款挪动App终端。最左边是R2X在研发、公布、运维以及用户文档上做的一些建设。因为R2X笼罩了美团外部大部分的支流容器场景，所以技术体系较为简单和宏大，大家能够依据本身的业务状态，选择性地去理解对应场景的同构计划。 4.1 底层根底框架4.1.1 R2X-CLI的设计CLI作为R2X我的项目驱动器，它不仅蕴含了命令行的启动，更重要的，它是各个编译构建的外围。 在晚期，CLI执行build命令时，咱们通过--type来辨别不同的构建容器，从而加载不同的编译逻辑。通过指定构建容器的模式来实现同一套代码可能构建出不同的容器产物。但通过长时间的业务迭代，咱们发现了这种构造存在的问题： 整体流程简短且简单，长时间迭代会变得越来越难以保护。每个容器的构建流程互相独立，且构建逻辑各不统一，有多处反复的逻辑解决。编译流程短少对立的要害节点，编译时无奈进行业务方的定制扩大。针对以上问题，咱们思考对CLI进行了一次全新的重构，引入插件化能力（对于插件化能力的具体实现会在下文详细描述）。CLI整体构造变成如下图所示： 整个CLI模块只须要关怀参数的解析以及插件的加载执行，不须要再实现各个容器的具体编译逻辑。通过Hooks的模式，将编译的各个机会裸露给插件，插件基于这些Hook进行编译能力的实现，最终输入产物给CLI模块。这种模式带来了以下几个益处： CLI构造变得清晰，只须要保护配置解析、插件解析等性能。扩展性加强，可通过插件化的模式新增或删减容器/编译能力，保障代码独立保护性能的单一性。编译流程可梳理，无论什么容器的编译流程都基于编译器裸露的机会执行并串联，整体流程清晰明了。4.1.2 组件及API的设计R2X的目标是心愿通过一套代码可能在多端上运行，然而因为多端差别的存在，咱们须要设计一套对立的标准规范来进行对齐。在运行时局部，次要分为组件/接口的对齐。 多端差别 在开始讲述实现之前，咱们先来看看各端之间的差别到底在哪些地方。 ...

为了缩小产品和前端开发人员之间的矛盾，一直降本提效，美团医药技术部构建了跨端一体化富文本治理平台Page-佩奇。本文零碎介绍了该平台的定位、设计思路、实现原理以及获得的功效。心愿这些实战经验与总结，能给大家带来一些启发或帮忙。一、引言在互联网圈，开发和产品经理之间相爱相杀的故事，置信大家都有所耳闻。归根结底，往往都是从简略的改需要开始，而后你来我往、互不相让，接着吵架斗嘴，最初导致矛盾一直降级，甚至带来比较严重的结果。 在这种背景下，如果把一些性能绝对简略的、需要变动比拟频繁的页面，间接交给产品或者经营本人去通过平台实现，是不是就能够从肯定水平上缩小产品和开发人员之间的矛盾呢？ 二、背景当然上述的状况，美团也不例外。近些年，美团到家事业群（包含美团外卖、美团配送、闪购、医药、团好货等）的各个业务稳步发展，业务前端对接的经营团队有近几十个，每个经营团队又有不同的经营规定，这些规定还存在一些轻微的款式差异，同时规定内容还会随着经营节令、节日、地理位置等进行变动和更新。这些需要具体来说有以下几个特点： 需求量大：业务稳步发展，业务需要一直叠加，甚至局部业务呈指数级增长，且业务方向波及到一些业务规定、音讯告诉、协定文档、规定介绍等需要。变更频繁：面对市场监管和法务的要求，以及新业务调整等因素的影响，会波及到需要的频繁变更，像一些业务FAQ、产品介绍、协定文档、业务规定、零碎更新日志等页面，须要做到疾速响应和及时上线。复杂度低：这些页面没有简单的交互逻辑，如果能把这些简略的页面交给经营/产品去实现，开发人员就能有更多的工夫去进行简单性能的研发。时效性高：临时性业务需要较多，且生命周期较短，具备定期下线和周期性上线等特点。基于以上特点，为了进步研发效率，美团医药技术部开始构建了一个跨端一体化富文本治理平台，心愿提供解决这一大类问题的产研计划。不过，部门最后的指标是开发一套提效工具，解决大量诸如帮忙文档、协定页、音讯告诉、规定阐明等动态页面的生产与公布问题，让产品和经营同学可能以所见即所得的形式自主实现动态页面制作与公布，进而缩短沟通老本和研发老本。 然而，随着越来越多业务部门开始征询并应用这个平台，咱们后续不断完善并裁减了很多的性能。通过屡次版本的设计和迭代开发后，将该平台命名为Page-佩奇，并且注册成为美团外部的公共服务，开始为美团外部更多同学提供更好的应用体验。 本文将系统地介绍Page-佩奇平台的定位、设计思路、实现原理及取得成效。咱们也心愿这些实战经验与总结，能给更多同学带来一些启发和思考。 三、跨端一体化富文本治理解决方案3.1 平台定位咱们心愿将Page-佩奇打造成一款为产品、经营、开发等用户提供疾速一站式公布网页的产研工作台，这是对该平台的一个定位。 对产品经营而言，他们可能可视化地去创立或批改一些流动阐明、协定类、音讯类的文章，无需开发排期，省去向开发二次传递音讯等繁琐的流程，也无需期待漫长的公布工夫，从而达到灵便疾速地进行可视化页面的公布与治理。对开发同学而言，他们可能在线编写代码，并实现秒级的公布上线，并且反对ES 6、JavaScript 、Less、CSS语法，咱们还提供了根底的工具、图表库等，可能生成丰盛多样的页面。帮忙开发同学疾速实现数据图表展现，设计特定款式，实现各种交互逻辑等需要。对项目管理方而言，他们可能清晰地看到整个需要流转状态和开发日志信息，为经营治理提供弱小的“抓手”。一般来讲，传统开发流程是这样的：首先产品提出需要，而后招集研发评审，最初研发同学开发并且部署上线；当需要上线之后，如果有问题须要反馈，产品再找研发同学进行沟通并修复，这种开发流程也是目前互联网公司比拟常见的开发流程。 而美团Page-佩奇平台的开发流程是：首先产品同学提出需要，而后本人在Page平台进行编辑和公布上线，当需要上线之后有问题须要反馈，间接就能触达到产品同学，他们通常可自行进行修复。如果需要须要定制化，或者须要做一些简单的逻辑解决，那么再让研发人员配合在平台上进行开发并公布上线。 简略来说，对那些性能绝对简略、需要变动比拟频繁的页面，如果用传统的开发流程将会减少产研沟通和研发排期老本，因而传统计划次要实用于性能复杂型的需要。而Page佩奇平台开发流程，并不适宜性能复杂型的需要，特地实用于性能绝对简略、需要变动比拟频繁的页面需要。 综上所述，能够看出这两种开发流程其实起到了一个互补的作用，如果一起应用，既能够缩小工作量，又能够达到降本提效的目标。 3.2 设计思路咱们最后设计Page-佩奇平台的初心其实很简略，为了给产品和经营提供一个通过富文本编辑器疾速制作并公布网页的工具。然而，在应用的过程中，很多缺点也就缓缓地开始裸露，大抵有上面这些问题： 简略的富文本编辑器满足不了想要的页面成果，怎么办？如果能导入想要的模板，是否会更敌对？怎么查看这个页面的拜访数据？如何能监控这个页面的性能问题？公布的页面是否有存在平安危险？于是，咱们针对这些问题进行了一些思考和调研： 当富文本编辑器满足不了想要实现的成果的时候，能够引入了WebIDE编辑器，能够让研发同学再二次编辑进行实现。一个零碎想要让用户用得高效便捷，那么就要欠缺它的周边生态。就须要装备欠缺的模板素材和物料供用户灵便抉择。如果用户想要理解页面的运行状况，那么页面运行的性能数据、拜访的数据也是必不可少的。如果公布的内容存在不当舆论，就会造成不可控的法律危险，所以内容危险审核也是必不可少的。实现一个性能很容易，然而想要实现一个绝对欠缺的性能，就必须好好下功夫，多思考和多调研。于是，围绕着这些问题，咱们一直开掘和延长出了一系列性能： 富文本编辑：弱小而简略的可视化编辑器，让所有操作变得简略、直观。产品同学能够通过编辑器自主创立、编辑网页，即便无程序开发教训也能够通过富文本编辑器随便操作，实现本人想要的成果，最终能够实现一键疾速公布上线。WebIDE：定制化需要，比方，与客户端和后端进行一些通信和申请需要，以及针对产品创立的HTML进行二次加工需要，均能够基于WebIDE通过JavaScript代码实现。具备业余开发教训的同学也能够抉择通过前端框架jQuery、Vue，Echarts或者工具库Lodash、Axios实现在线编辑代码。页面治理：灵便不便地治理页面。大家能够对有权限的文档进行查看、编辑、受权、下线、版本比照、操作日志、回滚等操作，且提供便捷的文档搜寻性能。模板市场：丰盛多样的网页模板，繁难而又具备共性。模板市场提供丰盛的页面模板，大家可抉择应用本人的模板疾速创立网页，且公布的每个页面又能够作为本人的模板，再基于这个模板，可随时增加个性化的操作。物料平台：提供根底Utils、Echart、Vue、jQuery等物料，不便开发基于产品的页面进行代码的二次开发。多平台跨端接入：高效快捷地接入业务零碎。通过通信SDK，其余零碎能够疾速接入Page-佩奇平台。同时反对以HTTP、Thrift形式的凋谢API供大家抉择，反对客户端、后端调用凋谢API。内容危险审核：谨严高效的审核机制。接入美团外部的危险审核公共服务，针对公布的危险内容将疾速审核，避免误操作造成不可控的法律危险。数据大盘：提供页面的数据监测，帮忙大家时刻把握流量动向。接入美团外部一站式数据分析平台，帮忙大家平安、疾速、高效地把握页面的各种监测数据。权限治理：创立的每个页面都有绝对独立的权限，只有通过受权的人才能查看和操作该页面。业务监控：提供页面级别JavaScript谬误和资源加载成功率等数据，不便开发排查和解决线上问题。性能流程图如下所示： 3.3 实现原理3.3.1 根底服务Page-佩奇平台的根底服务有四个局部，包含物料服务、编译服务、产品赋能、扩大服务。 3.3.2 外围架构 Page-佩奇平台外围架构次要蕴含页面根底配置层、页面组装层以及页面生成层。咱们通过Vuex全局状态对数据进行保护。 页面根底配置层次要提供生成页面的各种能力，包含富文本的各种操作能力、编辑源码（HTML、CSS、JavaScript）的能力、自定义域名配置、适配的容器（PC/H5）、公布环境等。页面组装层则会基于根底配置层所提供的的能力，实现页面的自在编辑，承载大量的交互逻辑，用户的所有操作都在这一层进行。 业务PV和UV埋点，谬误统计，拜访成功率上报。主动适配PC和挪动端款式。内网页面显示外网不可拜访标签。页面生成层则须要依据组装后的配置进行解析和预处理、编译等操作，最终生成HTML、CSS、JavaScript渲染到网页当中。3.3.3 要害流程 如上图7所示，平台的外围流程次要蕴含页面创立之后的页面预览、编译服务、生成页面。 页面预览：创立、编辑之后的页面，将会依据内容进行页面重组，对款式和JavaScript进行预编译之后，对文本+JavaScript+CSS进行组装，生成HTML代码块，而后将代码块转换成Blob URL，最终以iframe的形式预览页面。编译服务：文件树状构造和代码发送申请到后端接口，基于Webpack将Less编译成CSS，ES 6语法编译成ES 5。通用物料应用CDN进行引入，不再进行二次编译。生成页面：当创立、编辑之后的页面进行公布时，服务端将会进行代码品质检测、内容平安审查、代码品质检测、单元测试、上传对象存储平台、同步CDN检测，最终生成页面链接进行拜访。3.3.4 多平台接入Page-佩奇平台也能够作为一个欠缺的富文本编辑器供业务零碎应用，反对内嵌到其余零碎内。作为音讯公布等性能承载，缩小反复的开发工作，同时咱们装备欠缺的SDK供大家抉择应用。通过Page-SDK能够间接触发Page平台公布、治理等操作，具体的流程如下图所示： 3.3.5 OPEN API在应用Page-佩奇平台的时候，美团外部一些业务方提出想要通过Page-佩奇平台进行页面的公布，同时想要拿到公布的内容做一些自定义的解决。于是，咱们提供了Open API凋谢能力，反对以HTTP和Thrift两种形式进行调用。上面次要讲一下Thrift API实现的思路，首先咱们先理解下Thrift整体流程： Thrift的次要应用过程如下： 服务端事后编写接口定义语言 IDL（Interface Definition Language）文件定义接口。应用Thrift提供的编译器，基于IDL编译出服务语言对应的接口文件。被调用服务实现服务注册，调用发动服务实现服务发现。采纳对立传输协定进行服务调用与数据传输。那么上面咱们具体讲下，Node语言是如何实现和其余服务语言实现调用的。因为咱们的服务应用的Node语言，因而咱们的Node服务就充当了服务端的角色，而其余语言（Java等）调用就充当了客户端的角色。 生成文件：由服务端定义IDL接口形容文件，而后基于IDL文件转换为对应语言的代码文件，因为咱们用的是Node语言，所以转换成JavaScript文件。服务端启动服务：引入生成的JavaScript文件，解析接口、解决接口、启动并监听服务。服务注册：通过服务器内置的“服务治理代理”，将服务注册到美团外部的服务注册路由核心（也就是命名服务），让服务可被调用方发现。数据传输：被调用时，依据“服务治理服务”协定序列化和反序列化，与其余服务进行数据传输。目前，美团外部曾经有绝对成熟的NPM包服务，曾经帮咱们实现了服务注册、数据传输、服务发现和获取流程。客户端如果想调用咱们所提供的的Open API凋谢能力，首先申请AppKey，而后抉择应用Thrift形式或者HTTP的形式，依照所要求的参数进行申请调用。 3.4 计划实际3.4.1 H5协定能力：富文本编辑。形容：提供富文本可视化编辑，产品和经营无需前端就能够公布和二次编辑页面。场景：文本协定，音讯告诉，产品FAQ。 具体案例： 3.4.2 业务自定义渲染能力：凋谢API（Thirft + HTTP）。形容：提供凋谢API，反对业务自定义和款式渲染到业务零碎，同时解决了iframe体验问题。场景：客户端、后端、小程序的同学，可依据API渲染文案，实现动态化治理富文本信息。 具体案例： 小程序应用<rich-text>组件、Vue应用v-html指令实现动态化渲染商品抉择阐明。 { "code": 0, "data": { "tag": "苹果,规范", "title": "如何筛选苹果", "html": "<h1>如何筛选苹果</h1>><p>以下规范可供消费者参考</p><ul><li>酸甜</li><li>硬度</li></ul>", "css": "", "js": "", "file": {} }, "msg": "success"}3.4.3 投放需要能力：WebIDE代码编辑。形容：开发基于WebIDE代码开发工作，基于渠道和环境批改下载链接，可能做到分钟级撑持。场景：依据产品创立动态页面进行逻辑和款式开发。 ...

常识图谱问答（Knowledge-based Question Answering, KBQA）是指给定自然语言问题，通过对问题进行语义了解和解析，进而利用知识库进行查问、推理得出答案。美团在平台服务的售前、售中、售后全链路的多个场景中都存在大量的征询问题。咱们基于问答零碎，以主动智能回复或举荐回复的形式，来帮忙商家晋升答复用户问题的效率，同时更快地解决用户问题。本文联合KBQA在美团场景中的具体实际，以及发表在EMNLP 2021上的论文，介绍了KBQA零碎整体设计、难点冲破以及端到端问答的摸索，心愿能对从事相干钻研的同学有所帮忙或者启发。 1 背景与挑战问答零碎（Question Answering System, QA）是人工智能和自然语言解决畛域中一个倍受关注并具备宽泛发展前景的方向，它是信息检索零碎的一种高级模式，能够用精确、简洁的自然语言答复用户用自然语言提出的问题。这项钻研衰亡的次要起因是人们对疾速、精确地获取信息的需要，因而被广泛应用于工业界的各种业务场景中。美团在平台服务的售前、售中、售后全链路的多个场景中，用户都有大量的问题须要征询商家。因而咱们基于问答零碎，以主动智能回复或举荐回复的形式，来帮忙商家晋升答复用户问题的效率，更快地解决用户的问题。 针对不同问题，美团的智能问答零碎蕴含多路解决方案： PairQA：采纳信息检索技术，从社区已有答复的问题中返回与以后问题最靠近的问题答案。DocQA：基于浏览了解技术，从商家非结构化信息、用户评论中抽取出答案片段。KBQA（Knowledge-based Question Answering）：基于常识图谱问答技术，从商家、商品的结构化信息中对答案进行推理。本文次要分享在KBQA技术落地中的实际与摸索。 在用户的问题中，包含着大量对于商品、商家、景区、酒店等相干根底信息及政策等信息征询，基于KBQA技术能无效地利用商品、商家详情页中的信息，来解决此类信息征询问题。用户输出问题后，KBQA零碎基于机器学习算法对用户查问的问题进行解析、了解，并对知识库中的结构化信息进行查问、推理，最终将查问到的准确答案返回给用户。相比于PairQA和DocQA，KBQA的答案起源大多是商家数据，可信度更高。同时，它能够进行多跳查问、束缚过滤，更好地解决线上的简单问题。 理论落地利用时，KBQA零碎面临着多方面的挑战，例如： 繁多的业务场景：美团平台业务场景泛滥，包涵了酒店、游览、美食以及十多类生存服务业务，而不同场景中的用户用意都存在着差异，比方“早餐大略多少钱”，对于美食类商家须要答复人均价格，而对于酒店类商家则须要答复酒店内餐厅的价格明细。带束缚问题：用户的问题中通常带有泛滥条件，例如“故宫学生有优惠吗”，须要咱们对故宫所关联的优惠政策进行筛选，而不是把所有的优惠政策都答复给用户。多跳问题：用户的问题波及到常识图谱中多个节点组成的门路，例如“XX酒店的游泳池几点开”，须要咱们在图谱中先后找到酒店、游泳池、营业时间。上面将具体讲述咱们是如何设计高精确、低延时的KBQA零碎，解决场景、上下文语境等信息，精确了解用户、捕获用户用意，从而应答上述的挑战。 2 解决方案KBQA零碎的输出为用户Query，输入为答案。总体架构如下图1所示。最上层为应用层，包含对话以及搜寻等多个入口。在获取到用户Query后，KBQA线上服务通过Query了解和召回排序模块进行后果计算，最终返回答案文本。除了在线服务之外，常识图谱的构建、存储也非常重要。用户不仅会关怀商户的根本信息，也会询问观点类、设施信息类问题，比方景点好不好玩、酒店停车是否不便等。针对上述无官网供应的问题，咱们构建了一套信息与观点抽取的流程，能够从商家非结构化介绍以及UGC评论中抽取出有价值的信息，从而晋升用户征询的满意度，咱们将在下文进行具体介绍。 对于KBQA模型，目前的支流解决方案有两种，如下图2所示： 基于语义解析（Semantic Parsing-based）：对问句进行深度句法解析，并将解析后果组合成可执行的逻辑表达式（如SparQL），间接从图数据库中查问答案。基于信息抽取（Information Retrieval）：先解析出问句的主实体，再从KG中查问出主实体关联的多个三元组，组成子图门路（也称多跳子图），之后别离对问句和子图门路编码、排序，返回分数最高的门路作为答案。基于语义解析的办法可解释性更强，但这种办法须要标注大量的自然语言逻辑表达式，而信息抽取式的办法更偏差端到端的计划，在简单问题、少样本状况下体现更好，但若子图过大，会显著升高计算的速度。 因而，思考到两者的劣势，咱们采纳将两者联合的计划。如下图3所示，整体的流程分为四大步骤，以“故宫周末有学生票吗”为例： Query了解：输出原始Query，输入Query了解后果。其中会对对Query进行句法分析，辨认出用户查问的主实体是“故宫” 、业务畛域为“游览”、问题类型为一跳（One-hop）。关系辨认：输出Query、畛域、句法解析后果、候选关系，输入每个候选的分数。在这个模块中，咱们借助依存剖析强化Query的问题骨干，召回游览畛域的相干关系，进行匹配排序，辨认出Query中的关系为“门票”。子图召回：输出前两个模块中解析的主实体和关系，输入图谱中的子图（多个三元组）。对于上述例子，会召回游览业务数据下主实体为“故宫”、关系为“门票”的所有子图。答案排序：输出Query和子图候选，输入子图候选的分数，如果Top1满足肯定阈值，则输入作为答案。基于句法分析后果，辨认出约束条件为“学生票”，基于此条件最终对Query-Answer对进行排序，输入满足的答案。上面将介绍咱们对于重点模块的建设和摸索。 2.1 Query了解Query了解是KBQA的第一个外围模块，负责对句子的各个成分进行细粒度语义了解，其中两个最重要的模块是： 实体辨认和实体链接，输入问句中有意义的业务相干实体和类型，如商家名称、我的项目、设施、人群、工夫等。依存剖析：以分词和词性辨认后果为输出，辨认问句的主实体、被发问信息、束缚等。实体辨认是句法分析的重要步骤，咱们先基于序列标注模型辨认实体，再链接到数据库中的节点。对于该模块咱们次要做了以下优化： 为了晋升OOV（Out-of-Vocabulary）词的辨认能力，咱们对实体辨认的序列标注模型进行了常识注入，利用已知的先验常识辅助新常识的发现。思考到实体嵌套的问题，咱们的实体辨认模块会同时输入粗粒度和细粒度的后果，保障后续模块对于Query的充沛了解。在问答的长Query场景下，利用上下文信息进行实体的链接，失去节点id。最终，该模块会输入句子中各个重要成分的类型，如下图4所示： 依存剖析是句法分析的一种，它的目标是辨认句子中词与词的非对称摆布关系，在输入的后果中用有向弧示意，该弧线由隶属词（dep）指向摆布词（head）。对于KBQA工作，咱们定义了五种关系，如下图5所示： 依存剖析次要有两种计划：基于转移的（Transition-based）和基于图的（Graph-based）。基于转移的依存剖析将依存句法树的构建建模为一系列操作，由模型预测每一步的动作（shift、left_arc、right_arc），一直将未解决的节点入栈并赋予关系，最终形成句法树。基于图的办法则致力于在图中找出一棵最大生成树，也就是句子整体依存关系的全局最优解。思考到基于图的办法是对全局进行搜寻，准确率更高，咱们采纳较为经典的“Deep Biaffine Attention for Neural Dependency Parsing”模型，它的构造如下图6所示： 该模型先通过BiLSTM对词与词性的拼接向量进行编码，之后采纳对用两个MLP头别离编码出h(arc-head)和h(arc-dep)向量，去除冗余信息。最终将各个时刻的向量拼接起来失去H(arc-head)和H(arc-dep)，且在H(arc-dep)上拼接了一个单位向量，退出两头矩阵U(arc)进行仿射变换，失去dep与head的点积分数矩阵S(arc)，找到每个词依存的head。 有了依存剖析的后果，咱们能够更好地辨认关系、简单问题，具体的特色应用办法将在下文进行介绍。 2.2 关系辨认关系辨认是KBQA中另一个外围模块，目标是辨认出用户Query所问的关系（Predicate），从而与主实体（Subject）联结确定惟一子图，失去答案（Object）。 在实践中，思考到图谱中边关系的数量会一直减少，咱们将关系辨认建模为文本匹配工作，输出用户Query、Query特色和候选关系，输入关系匹配的分数。为了解决结尾提到的多畛域问题，咱们在输出的特色中退出了畛域信息，从而在畛域示意中存储肯定的畛域相干常识，让模型更好地判断。同时，为了晋升简单Query的了解，咱们在输出中还融入了句法信息，让模型能够更好地了解带束缚、多跳的问题。 随着大规模预训练语言模型的呈现，BERT等大模型在匹配工作上获得了SOTA的后果，通常业界通用的办法次要归类为以下两种： 示意型：也称“双塔模型”，它的次要思维是将两段文本转换成一个语义向量，而后在向量空间计算两向量的类似度，更偏重对语义向量表示层的构建。交互型：该办法侧重于学习句子中短语之间的对齐，并学习比拟他们之间的对齐关系，最终将对齐整合后的信息聚合到预测层。因为交互型模型能够利用到文本之前的对齐信息，因此精度更高、成果更好，所以在本我的项目中咱们采纳交互型模型来解决匹配问题。为了充分利用BERT的语义建模能力，同时思考理论业务的线上延时要求，咱们在推理减速、数据加强、常识加强方面做了以下三点优化： 档次剪枝：BERT每层都会学到不同的常识，凑近输出侧会学到较为通用的句法常识，而凑近输入则会学习更多任务相干的常识，因而咱们参考DistillBERT，采取Skip等距离式档次剪枝，只保留对工作成果最好的3层，比单纯保留前三层的剪枝在F1-score上晋升了4%，同时，试验发现不同剪枝办法成果差距可达7%。畛域工作数据预精调：剪枝后，因为训练数据无限，3层模型的成果有不小的降落。通过对业务的理解，咱们发现美团的“问大家”模块数据与线上数据的一致性很高，并对数据进行荡涤，将问题题目和相干问题作为正例，随机选取字面类似度0.5-0.8之间的句子作为负例，生成了大量弱监督文本对，预精调后3层模型在准确率上晋升超过4%，甚至超过了12层模型的成果。常识加强：因为用户的表达方式多种多样，精确辨认用户的用意，须要深刻语意并联合语法信息。为了进一步晋升成果，同时解决局部Case，咱们在输出中退出了畛域与句法信息，将显式的先验常识融入BERT，在注意力机制的作用下，同时联合句法依存树结构，精确建模词与词之间的依赖关系，咱们在业务数据以及五个大型公开数据集上做验证，比照BERT Base模型在准确率上均匀晋升1.5%。通过上述一系列迭代后，模型的速度、准确率都有了大幅的晋升。 2.3 简单问题了解在实在场景中，大部分问题能够归为以下四类（绿色为答案节点），如下图8所示： 问题的跳数依据实体数量决定，单跳问题通常只波及商户的根本信息，比方问商户的地址、电话、营业时间、政策等，在常识图谱中都能够通过一组SPO（三元组）解答；两跳问题次要是针对商户中某些设施、服务的信息发问，比方酒店的健身房在几层、早餐几点开始、以及接送机服务的价格等，须要先找到商户->主实体（设施/服务/商品等）的门路，再找到主实体的根本信息三元组，也就是SPX、XPO两个三元组。束缚问题指主实体或答案节点上的约束条件，个别为工夫、人群或是定语。 上面介绍针对不同类型的简单问题，咱们所进行的一些改良。 2.3.1 带束缚问题通过对线上日志的开掘，咱们将束缚分为以下几类，如下图9所示： 对于带束缚问题的答复波及两个关键步骤：束缚辨认和答案排序。 通过KBQA零碎中的依存剖析模块，咱们能够辨认出用户在实体或关系信息上所加的束缚限度，但束缚的说法较多，且不同节点的束缚类型也不一样，因而咱们在结构数据库查问SQL时先保障召回率，尽量召回实体和关系门路下的所有候选节点，并在最终排序模块对答案束缚进行打分排序。 为了晋升效率，咱们首先在常识存储层上进行了优化。在复合属性值的存储方面，Freebase提出Compound Value Type (CVT) 类型，如下图10所示，来解决这类复合结构化的数据的存储与查问问题。比方欢乐谷的营业时间，对于不同的场次是不一样的。这种复合的属性值能够用CVT的模式去承接。 ...

剧本杀作为爆发式增长的新兴业务，在商家上单、用户选购、供需匹配等方面存在有余，供应标准化能为用户、商家、平台三方发明价值，助力业务增长。本文介绍了美团到店综合业务数据团队从0到1疾速建设剧本杀供应标准化的过程及算法计划。咱们将美团到店综合常识图谱（GENE，GEneral NEeds net）笼罩至剧本杀行业，构建剧本杀常识图谱，实现供应标准化建设，包含剧本杀供应开掘、规范剧本库构建、供应与规范剧本关联等环节，并在多个场景进行利用落地，心愿给大家带来一些帮忙或启发。一、背景剧本杀行业近年来呈爆发式增长态势，然而因为剧本杀是新兴行业，平台已有的类目体系和产品状态，越来越难以满足飞速增长的用户和商户需要，次要体现在上面三个方面： 平台类目缺失：平台短少专门的“剧本杀”类目，中心化流量入口的缺失，导致用户决策门路凌乱，难以建设对立的用户认知。用户决策效率低：剧本杀的外围是剧本，因为不足规范的剧本库，也未建设规范剧本和供应的关联关系，导致剧本信息展现和供应治理的规范化水平低，影响了用户对剧本抉择决策的效率。商品上架繁琐：商品信息须要商户人工一一录入，没有可用的规范模板用以信息预填，导致商户在平台上架的剧本比例偏低，上架效率存在较大的晋升空间。为了解决上述痛点，业务须要进行剧本杀的供应标准化建设：首先建设“剧本杀”新类目，并实现相应的供应（包含商户、商品、内容）的类目迁徙。以此为根底，以剧本为外围，搭建规范剧本库，并关联剧本杀供应，继而建设剧本维度的信息散发渠道、评估评分和榜单体系，满足用户“以剧本找店”的决策门路。 值得指出的是，供应标准化是简化用户认知、帮忙用户决策、促成供需匹配的重要抓手，标准化水平的高下对平台业务规模的大小有着决定性影响。具体到剧本杀行业，供应标准化建设是助力剧本杀业务持续增长的重要根底，而规范剧本库的搭建是剧本杀供应标准化的要害。因为基于规格如「城限」、背景如「古风」、题材如「情感」等剧本属性无奈确定具体的剧本，但剧本名称如「舍离」则能起惟一标识的作用。因而，规范剧本库的搭建，首先是规范剧本名称的建设，其次是规格、背景、题材、难度、流派等规范剧本属性的建设。 综上，美团到店综合业务数据团队与业务同行，助力业务进行剧本杀的供应标准化建设。在建设过程中，波及了剧本名称、剧本属性、类目、商户、商品、内容等多种类型的实体，以及它们之间的多元化关系构建。而常识图谱作为一种揭示实体及实体间关系的语义网络，用以解决该问题显得尤为适合。特地地，咱们曾经构建了美团到店综合常识图谱（GENE，GEneral NEeds net），因而，咱们基于GENE的构建教训疾速进行剧本杀这一新业务的常识图谱构建，从0到1实现剧本杀标准化建设，从而改善供应治理和供需匹配，为用户、商户、平台三方发明出更大的价值。 二、解决方案咱们构建的GENE，围绕本地生存用户的综合性需要，以行业体系、需要对象、具象需要、场景因素和场景需要五个档次逐层递进，笼罩了玩乐、医美、教育、亲子、结婚等多个业务，体系设计和技术细节可见美团到店综合常识图谱相干的文章。剧本杀作为一项新兴的美团到店综合业务，体现了用户在玩乐上的新需要，人造适配GENE的体系结构。因而，咱们将GENE笼罩至剧本杀新业务，沿用雷同的思路来进行相应常识图谱的构建，以实现相应的供应标准化。 基于常识图谱来实现剧本杀标准化建设的要害，是以规范剧本为外围构建剧本杀常识图谱。图谱体系设计如图1所示，具体地，首先在行业体系层进行剧本杀新类目标构建，开掘剧本杀供应，并建设供应（包含商户、商品、内容）与类目标从属关系。在此基础上，在需要对象层，进一步实现规范剧本名称这一外围对象节点和其剧本属性节点的开掘以及关系构建，建设规范剧本库，最初将规范剧本库的每个规范剧本与供应和用户建设关联关系。此外，具象需要、场景因素、场景需要三层则实现了对用户在剧本杀上的具象的服务需要和场景化需要的显性表白，这部分因为与剧本杀供应标准化建设的分割不多，在这里不做开展介绍。 剧本杀常识图谱中用于供应标准化局部的具体样例如下图2所示。其中，规范剧本名称是外围节点，围绕它的各类规范剧本属性节点包含题材、规格、流派、难度、背景、别称等。同时，规范剧本之间可能构建诸如“同系列”等类型的关系，比方「舍离」和「舍离2」。此外，规范剧本还会与商品、商户、内容、用户之间建设关联关系。 咱们基于剧本杀常识图谱的这些节点和关系进行供应标准化，在图谱构建过程中，包含了剧本杀供应开掘、规范剧本库构建、供应与规范剧本关联三个次要步骤，上面对三个步骤的实现细节以及波及的算法进行介绍。 三、实现办法3.1 剧本杀供应开掘剧本杀作为新兴的业务，已有的行业类目树中并没有相应的类目，无奈间接依据类目获取剧本杀的相干供应（包含商户、商品和内容）。因而，咱们须要首先进行剧本杀供应的开掘，即从以后与剧本杀行业相近类目标供应中挖掘出剧本杀的相干供应。 对于剧本杀的商户供应开掘，须要判断商户是否提供剧本杀服务，判断根据包含了商户名、商品名及商品详情、商户UGC三个起源的文本语料。这个实质上是一个多源数据的分类问题，然而因为不足标注的训练样本，咱们没有间接采纳端到端的多源数据分类模型，而是依靠业务输出，采纳无监督匹配和有监督拟合相结合的形式高效实现，具体的判断流程如下图3所示，其中： 无监督匹配：首先结构剧本杀相干的关键词词库，别离在商户名、商品名及商品详情、商户UGC三个起源的文本语料中进行准确匹配，并构建基于BERT[1]的通用语义漂移判断模型进行匹配后果过滤。最初依据业务规定基于各起源的匹配后果计算相应的匹配分数。有监督拟合：为了量化不同起源匹配分数对最终判断后果的影响，由经营先人工标注大量商户分数，用以表征商户提供剧本杀服务的强弱。在此基础上，咱们结构了一个线性回归模型，拟合标注的商户分数，获取各起源的权重，从而实现对剧本杀商户的精准开掘。 采纳上述形式，实现了桌面和实景两种剧本杀商户的开掘，准确率和召回率均达到了要求。基于剧本杀商户的开掘后果，可能进一步对商品进行开掘，并创立剧本杀类目，从而为后续剧本杀常识图谱构建及标准化建设打好了数据根底。 3.2 规范剧本库构建规范剧本作为整个剧本杀常识图谱的外围，在剧本杀供应标准化建设中扮演着重要的角色。咱们基于剧本杀商品类似聚合的形式，联合人工审核来开掘规范剧本，并从相干发行方获取剧本受权，从而构建规范剧本库。规范剧本由两局部形成，一个是规范剧本名称，另一个是规范剧本属性。因而，规范剧本库构建也分为规范剧本名称的开掘和规范剧本属性的开掘两个局部。 3.2.1 规范剧本名称的开掘咱们依据剧本杀商品的特点，先后采纳了规定聚合、语义聚合和多模态聚合三种办法进行开掘迭代，从数十万剧本杀商品的名称中聚合失去数千规范剧本名称。上面别离对三种聚合办法进行介绍。 规定聚合 同一个剧本杀商品在不同商户的命名往往不同，存在较多的不标准和个性化。一方面，同一个剧本名称自身就能够有多种叫法，例如「舍离」、「舍离壹」、「舍离1」就是同一个剧本；另一方面，剧本杀商品名除了蕴含剧本名称外，商家很多时候也会退出剧本的规格和题材等属性信息以及吸引用户的描述性文字，例如「《舍离》情感本」。所以咱们首先思考剧本杀商品的命名特点，设计相应的荡涤策略对剧本杀商品名称进行荡涤后再聚合。 咱们除了梳理常见的非剧本词，构建词库进行规定过滤外，也尝试将其转换为命名实体辨认问题[2]，采纳序列标注对字符进行“是剧本名”与“不是剧本名”两个类别的辨别。对于荡涤后的剧本杀商品名称，则通过基于最长公共子序列（LCS）的类似度计算规定，联合阈值筛选对其进行聚合，例如「舍离」、「舍离壹」、「舍离1」最初均聚在一起。整个流程如上图4所示，采纳规定聚合的形式，可能在建设初期帮忙业务疾速对剧本杀商品名称进行聚合。 语义聚合 规定聚合的形式尽管简略好用，但因为剧本名称的多样性和复杂性，咱们发现聚合后果中依然存在一些问题：1）不属于同一个剧本的商品被聚合，例如「舍离」和「舍离2」是同一个系列的两个不同剧本，却被聚合在一起。2）属于同一个剧本的商品没有聚合，例如，商品名应用剧本的简称缩写（「唐人街名侦探和猫」和「唐探猫」）或呈现错别字（「弗洛伊德之锚」和「佛洛依德之锚」）等状况时则难以规定聚合。 针对这上述这两种问题，咱们进一步思考应用商品名称语义匹配的形式，从文本语义雷同的角度来进行聚合。罕用的文本语义匹配模型分为交互式和双塔式两种类型。交互式是把两段文本一起输出进编码器，在编码的过程中让其相互交换信息后再进行判断；双塔式模型是用一个编码器别离给两个文本编码出向量，而后基于两个向量进行判断。 因为商品数量泛滥，采纳交互式的办法须要将商品名称两两组合后再进行模型预测，效率较为低下，为此，咱们采纳双塔式的办法来实现，以Sentence-BERT[3]的模型构造为根底，将两个商品名称文本别离通过BERT提取向量后，再应用余弦间隔来掂量两者的类似度，残缺构造如下图5所示： 在训练模型的过程中，咱们首先基于规定聚合的后果，通过同聚簇内生成正例和跨聚簇穿插生成负例的形式，结构粗粒度的训练样本，实现初版模型的训练。在此基础上，进一步联合被动学习，对样本数据进行欠缺。此外，咱们还依据上文提到的规定聚合呈现的两种问题，针对性的批量生成样本。具体地，通过在商品名称后增加同系列编号，以及应用错字、别字和繁体字替换等形式来实现样本的主动结构。 多模态聚合 通过语义聚合的形式实现了从商品名称文本语义层面的同义聚合，然而咱们通过对聚合后果再剖析后发现还存在一些问题：两个商品属于同一个剧本，但仅从商品名称的角度是无奈判断。例如，「舍离2」和「断念」从语义的角度无奈聚合，然而它们实质上是一个剧本「舍离2·断念」。尽管这两个商品的名称各异，然而它们的图像往往是雷同或类似的，为此，咱们思考引入商品的图像信息来进行辅助聚合。 一个简略的办法是，应用CV畛域成熟的预训练模型作为图像编码器进行特征提取，间接计算两个商品的图像类似度。为了对立商品图像类似度计算和商品名称语义匹配的后果，咱们尝试构建一个剧本杀商品的多模态匹配模型，充分利用商品名称和图像信息来进行匹配。模型沿用语义聚合中应用的双塔式构造，整体构造如下图6所示： 在多模态匹配模型中，剧本杀商品的名称和图像别离通过文本编码器和图像编码器失去对应的向量示意后，再进行拼接作为最终的商品向量，最初应用余弦类似度来掂量商品之间的类似度。其中： 文本编码器：应用文本预训练模型BERT[1]作为文本编码器，将输入均匀池化后作为文本的向量示意。图像编码器：应用图像预训练模型EfficientNet[4]作为图像编码器，提取网络最初一层输入作为图像的向量示意。在训练模型的过程中，文本编码器会进行Finetune，而图像编码器则固定参数，不参加训练。对于训练样本构建，咱们以语义聚合的后果为根底，以商品图像类似度来圈定人工标注样本的范畴。具体地，对于同聚簇内商品图像类似度高的间接生成正例，跨聚簇穿插的商品图像类似度低的间接生成负例，而对于残余的样本对则交由人工进行标注确定。通过多模态聚合，补救了仅应用文本匹配的有余，与其相比准确率晋升了5%，进一步晋升了规范剧本的开掘成果。 3.2.2 规范剧本属性的开掘规范剧本的属性包含了剧本的背景、规格、流派、题材、难度等十余个维度。因为商户在剧本杀商品上单的时候会录入商品的这些属性值，所以对于规范剧本属性的开掘，实质上是对该规范剧本对应的所有聚合商品的属性的开掘。 在理论过程中，咱们通过投票统计的形式来进行开掘，即对于规范剧本的某个属性，通过对应的聚合商品在该属性上的属性值进行投票，抉择投票最高的属性值，作为该规范剧本的候选属性值，最初由人工审核确认。此外，在规范剧本名称开掘的过程中，咱们发现同一个剧本的叫法多种多样，为了对规范剧本能有更好的形容，还进一步为规范剧本减少了一个别称的属性，通过对规范剧本对应的所有聚合商品的名称进行荡涤和去重来获取。 3.3 供应与规范剧本关联在实现规范剧本库构建后，还须要建设剧本杀的商品、商户和内容三种供应，与规范剧本的关联关系，从而使剧本杀的供应实现标准化。因为通过商品和规范剧本的关联关系，能够间接获取该商品对应商户和规范剧本的关系，所以咱们只须要对商品和内容进行规范剧本关联。 3.3.1 商品关联在3.2节中，咱们通过聚合存量剧本杀商品的形式来进行规范剧本的开掘，在这个过程中其实曾经构建了存量商品和规范剧本的关联关系。对于后续新减少的商品，咱们还须要将其和规范剧本进行匹配，以建设两者之间的关联关系。而对于与规范剧本无奈关联的商品，咱们则主动进行规范剧本名称和属性的开掘，经由人工审核后再退出规范剧本库。 整个商品关联流程如下图7所示，首先对商品名称进行荡涤再进行匹配关联。在匹配环节，咱们基于商品和规范剧本的名称及图像的多模态信息，对两者进行匹配判断。 与商品之间的匹配不同，商品与规范剧本的关联不须要放弃匹配的对称性。为了保障关联的成果，咱们在3.2.1节的多模态匹配模型的构造根底上进行批改，将商品和规范剧本的向量拼接后通过全连贯层和softmax层计算两者关联的概率。训练样本则间接依据存量商品和规范剧本的关联关系结构。通过商品关联，咱们实现了绝大部分剧本杀商品的标准化。 3.3.2 内容关联对于剧本杀内容关联规范剧本，次要针对用户产生的内容（UGC，例如用户评估）这一类型的内容和规范剧本的关联。因为一段UGC文本通常蕴含多个句子，且其中只有局部句子会提及规范剧本相干信息，所以咱们将UGC与规范剧本的匹配，细化为其子句粒度的匹配，同时出于效率和成果的均衡的思考，进一步将匹配过程分为了召回和排序两个阶段，如下图8所示： 在召回阶段，将UGC文本进行子句拆分，并依据规范剧本名称及其别称，在子句汇合中进行准确匹配，对于匹配中的子句则将进入到排序阶段进行精细化的关联关系判断。 在排序阶段，将关联关系判断转换为一个Aspect-based的分类问题，参考属性级情感分类的做法[5]，构建基于BERT句间关系分类的匹配模型，将理论命中UGC子句的规范剧本别称和对应的UGC子句用[SEP]相连后输出，通过在BERT后减少全连贯层和softmax层来实现是否关联的二分类，最初对模型输入的分类概率进行阈值筛选，获取UGC关联的规范剧本。 与上文中波及的模型训练不同，UGC和规范剧本的匹配模型无奈疾速获取大量训练样本。思考到训练样本的不足，所以首先通过人工大量标注数百个样本，在此基础上，除了采纳被动学习外，咱们还尝试比照学习，基于Regularized Dropout[6]办法，对模型两次Dropout的输入进行正则束缚。最终在训练样本不到1K的状况下，UGC关联规范剧本的准确率达到上线要求，每个规范剧本关联的UGC数量也失去了大幅晋升。 四、利用实际以后剧本杀常识图谱，以数千规范剧本为外围，关联百万供应。剧本杀供应标准化建设的后果已在美团多个业务场景上进行了初步的利用实际。上面介绍具体的利用形式和利用成果。 4.1 类目构建通过剧本杀供应开掘，帮忙业务辨认出剧本杀商户，从而助力剧本杀新类目和相应剧本杀列表页的构建。剧本杀类目迁徙、休闲娱乐频道页的剧本杀入口、剧本杀列表页均已上线，其中，频道页剧本杀ICON固定第三行首位，提供了中心化流量入口，有助于建设对立的用户认知。上线示例如图9所示（(a)休闲娱乐频道页剧本杀入口，(b)剧本杀列表页）。 4.2 个性化举荐剧本杀常识图谱蕴含的规范剧本及属性节点，以及其与供应和用户的关联关系，可利用于剧本杀各页面的举荐位。一方面利用于剧本列表页热门剧本举荐（图10(a)），另一方面还利用于剧本详情页的商品在拼场次举荐（图10(b)左）、可玩门店举荐（图10(b)左）和相干剧本举荐模块（图10(b)右）。这些举荐位的利用，帮忙造就了用户在平台找剧本的心智，优化了用户认知和选购体验，进步了用户和供应的匹配效率。 以剧本列表页的热门剧本举荐模块为例，剧本杀常识图谱蕴含的节点和关系除了能够间接用于剧本的召回，还能够进一步在精排阶段进行利用。在精排中，咱们基于剧本杀常识图谱，联合用户行为，参考Deep Interest Network（DIN）[7]模型构造，尝试对用户拜访剧本的序列和拜访商品的序列进行建模，构建双通道DIN模型，深度刻画用户趣味，实现剧本的个性化散发。其中商品拜访序列局部，通过商品与规范剧本的关联关系将其转为为剧本序列，与候选剧本采纳Attention形式进行建模，具体模型构造如下图11所示： 4.3 信息外露和筛选基于剧本杀常识图谱中的节点和关系，在剧本杀列表页和在剧本列表页减少相干标签筛选项，并外露剧本的属性和关联的供应信息，相干利用如下图12所示。这些标签筛选项和信息的外露，为用户提供了标准的信息展现，升高了用户决策老本，更加不便了用户选店和选剧本。 ...

2021年5月，美团NLP核心开源了迄今规模最大的基于实在场景的中文属性级情感剖析数据集ASAP，该数据集相干论文被自然语言解决顶会NAACL2021录用，同时该数据集退出中文开源数据打算千言，将与其余开源数据集一起推动中文信息处理技术的提高。本文回顾了美团情感剖析技术的演进和在典型业务场景中的利用，包含篇章/句子级情感剖析、属性级情感剖析和观点三元组剖析。在业务利用上，依靠情感剖析技术能力构建了在线实时预测服务和离线批量预测服务。截至目前，情感剖析服务曾经为美团外部十多个业务场景提供了服务。 参考文献[1] https://github.com/Meituan-Di...[2] Bu J, Ren L, Zheng S, et al. ASAP: A Chinese Review Dataset Towards Aspect Category Sentiment Analysis and Rating Prediction. In Proceedings of the 2021 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies. 2021.[3] https://www.luge.ai/[4] Zhang, L. , S. Wang , and B. Liu . "Deep Learning for Sentiment Analysis : A Survey." Wiley Interdisciplinary Reviews: Data Mining and Knowledge Discovery (2018):e1253.[5] Liu, Bing. "Sentiment analysis and opinion mining." Synthesis lectures on human language technologies 5.1 (2012): 1-167.[6] Peng, Haiyun, et al. "Knowing what, how and why: A near complete solution for aspect-based sentiment analysis." In Proceedings of the AAAI Conference on Artificial Intelligence. Vol. 34. No. 05. 2020.[7] Zhang, Chen, et al. "A Multi-task Learning Framework for Opinion Triplet Extraction." In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing: Findings. 2020.[8] Yoon Kim. 2014. Convolutional neural networks for sentence classification. arXiv preprint arXiv:1408.5882.[9] Peng Zhou, Wei Shi, Jun Tian, Zhenyu Qi, Bingchen Li,Hongwei Hao, and Bo Xu. 2016. Attention-based bidirectional long short-term memory networks for relation classification. In Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics (Volume 2: Short Papers), pages 207–212.[10] Devlin, Jacob, et al. “Bert: Pre-training of deep bidirectional transformers for language understanding.” arXiv preprint arXiv:1810.04805 (2018).[11] 杨扬、佳昊等. 美团BERT的摸索和实际.[12] Pontiki, Maria, et al. "Semeval-2016 task 5: Aspect based sentiment analysis." International workshop on semantic evaluation. 2016.[13] Pontiki, M. , et al. "SemEval-2014 Task 4: Aspect Based Sentiment Analysis." In Proceedings of International Workshop on Semantic Evaluation at (2014).[14] Yequan Wang, Minlie Huang, and Li Zhao. 2016. Attention-based lstm for aspect-level sentiment classification. In Proceedings of the 2016 Conference on Empirical Methods in Natural Language Processing, pages 606–615.[15] Sara Sabour, Nicholas Frosst, and Geoffrey E Hinton. 2017. Dynamic routing between capsules. In Advances in neural information processing systems, pages 3856–3866.[16] Chi Sun, Luyao Huang, and Xipeng Qiu. 2019. Utilizing bert for aspect-based sentiment analysis via constructing auxiliary sentence. arXiv preprint arXiv:1903.09588.[17] Qingnan Jiang, Lei Chen, Ruifeng Xu, Xiang Ao, and Min Yang. 2019. A challenge dataset and effective models for aspect-based sentiment analysis. In Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP), pages 6281–6286.[18] Wu, Zhen, et al. "Grid Tagging Scheme for End-to-End Fine-grained Opinion Extraction." In Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing: Findings. 2020.[19] Liu, Yinhan, et al. "Roberta: A robustly optimized bert pretraining approach." arXiv preprint arXiv:1907.11692 (2019).[20] Clark, Kevin, et al. "Electra: Pre-training text encoders as discriminators rather than generators." arXiv preprint arXiv:2003.10555 (2020).0- [21] Timothy Dozat and Christopher D. Manning. 2017.Deep biaffine attention for neural dependency parsing. In 5th International Conference on Learning Representations, ICLR 2017.作者介绍任磊、佳昊、张辰、杨扬、梦雪、马放、金刚、武威等，均来自美团平台搜寻与NLP部NLP核心。 ...

后深度学习时代下，技术迭代全面进入深水区，以晋升模型复杂度为主体的广告预估模型优化曾经不再见效。美团到店广告品质预估团队紧密结合业务特点，施展深度模型构造灵便多变的劣势，实现了进一步破局。本文先介绍了美团业务的LBS空间间隔束缚和长周期性两大挑战，而后介绍了上下文、用户、广告、训练形式四个维度的应答计划，具体如下四个技术冲破：a.基于位次组合的上下文偏差感知预估；b.基于时空依赖的超长序列建模；c.广告候选动态化；d.劫难忘记与继续学习，带动线上指标显著晋升的同时，整顿为论文发表在SIGIR、CIKM等国内顶级会议。最初，基于新一轮了解，提出推理量级动态化、评估指标差异化等预估技术新趋势。 参考文献[1] Friedman J H . Greedy Function Approximation: A Gradient Boosting Machine[J]. Annals of Statistics, 2001, 29(5):1189-1232.[2] Rendle S. Factorization machines[C]//2010 IEEE International conference on data mining. IEEE, 2010: 995-1000.[3] HT Cheng, et al. Wide & Deep Learning for Recommender Systems, 2016[4] Zhou, Guorui, et al. “Deep interest network for click-through rate prediction.” Proceedings of the 24th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. 2018[5] Modeling Task Relationships in Multi-task Learning with Multi-gate Mixture-of-Experts. ACM, 2018.[6] Wen, Ling, Chua. A closer look at strategies for memorization.[J]. Clavier Companion, 2014, 6(6):50-52.[7] Huang J, Hu K, Tang Q, et al. Deep Position-wise Interaction Network for CTR Prediction[J]. arXiv preprint arXiv:2106.05482, 2021.[8] Search-based User Interest Modeling with Lifelong Sequential Behavior Data for Click-Through Rate Prediction[9] Qi, Yi, et al. "Trilateral Spatiotemporal Attention Network for User Behavior Modeling in Location-based Search", CIKM 2021.[10] Overcoming catastrophic forgetting in neural networks[J]. Proceedings of the National Academy of Sciences of the United States of America, 2017.[11] M. Zinkevich. Online convex programming and generalized infinitesimal gradient ascent. In ICML, 2003.[12] Optimized Cost per Click in Taobao Display Advertising[C]// the 23rd ACM SIGKDD International Conference. ACM, 2017.[13] https://tech.meituan.com/2020...招聘信息美团到店广告平台广告算法团队立足广告场景，摸索深度学习、强化学习、人工智能、大数据、常识图谱、NLP和计算机视觉前沿的技术倒退，摸索本地生存服务电商的价值。次要工作方向包含： ...

不论是电商cps，还是外卖cps，对接过这么多第三方cps接口，只有美团联盟提供了订单数据回推接口，而且只有订单状态扭转，就会回推数据，这为咱们本身零碎实现用户跟单继而实现分销裂变的性能提供了极大的敌对帮忙。 登录美团联盟后盾，在联盟API接口列表找到一个名称为【订单回推接口】的栏目。 对，这个就是咱们须要的接口，点进去查看详情。 和大部分回调接口一样，这个接口不须要接入方被动调用，而是接入方提供一个接口给美团联盟平台调用的，平台会将订单数据post到这个接口上，从而咱们就能够从数据中获取到下单时事后传入的sid，这个sid是可能惟一辨认咱们零碎的用户。这样就能够实现订单跟踪的成果，继而做一些业务逻辑的解决。 为了平安，同样的须要对联盟平台post过去的数据进行验签操作，以确保是平台发送过去的数据。留神，验签用到的密钥和调用联盟平台其余接口用到的密钥不是同一个哦，这个密钥在如下地位，签名形式和其余接口统一。 看下service层的代码 留神，接管到推送的订单之后，须要依照上面的固定的格局进行返回，数据失常，返回:{"errcode":"0","errmsg":"ok"}，数据谬误，返回: {"errcode":"1","errmsg":"err"}@Overridepublic Map<String, String> mtOrderCallback(TreeMap<String, String> params) { String data = JSON.toJSONString(params); logger.info("美团回调参数：{}", data); MtOrderModel mtOrder = JSONObject.parseObject(data, MtOrderModel.class); String getSign = mtOrder.getSign(); String sign = MtSignUtils.genSign(params, model.getMtCallbackSecret()); Map<String, String> result = new HashMap<>(3); if (sign.equals(getSign)) { String userUuid = mtOrder.getSid(); UserMember member = userMemberService.getOne(Wrappers.<UserMember>lambdaQuery().eq(UserMember::getUuid, userUuid)); if (member != null) { String orderId = mtOrder.getOrderid(); String status = mtOrder.getStatus(); String type = mtOrder.getType(); CpsOrder order = cpsOrderService.getOne(Wrappers.<CpsOrder>lambdaQuery() .eq(CpsOrder::getOrderSn, orderId)); if (order == null) { order = new CpsOrder(); // TODO // 保留订单 // ...... cpsOrderService.save(order); } else { if (StringUtils.equals("8", status)) { // 美团订单已实现 // ...... } else if (StringUtils.equals("9", status)) { // 美团订单已退款或风控 // ...... } cpsOrderService.updateById(order); } } result.put("errcode", "0"); result.put("errmsg", "ok"); } else { result.put("errcode", "1"); result.put("errmsg", "err"); } logger.info("美团回调返回给美团的参数：{}", JSON.toJSONString(result)); return result;}看下controller层的代码 ...

暌违已久的ICCV 2021如约而至。秉持着“帮大家吃得更好，生存更好”的企业使命，本次大会美团将焦点集中在了计算机视觉技术在大规模细粒度食品剖析畛域的利用。 北京工夫10月16日19:00-22:30，美团视觉智能部将携手中科院计算所、北京智源以及巴塞罗那大学，与来自寰球的食品计算畛域的出名专家学者一起，就“LargeFineFoodAI”主题开展交换研究。 研讨会议程将重点分为以下三个局部，因疫情影响，全程采纳线上形式进行（参加形式详见文章底部）。 01 Invited Talk作为计算机视觉方向的三大顶会之一的ICCV国内计算机视觉大会，以“LargeFineFoodAI”为研究主题、聚焦大规模食品图像的细粒度辨认与检索尚属首次。在备受期待的分享环节，咱们邀请到三位业内顶尖专家，带来对于计算机视觉在食品畛域利用的最新实践和实际成绩。 食物是每个人身体健康和精力愉悦的重要起源，然而集体的饮食偏好未必能与其身体素质相匹配。对于大多数人来说，在衰弱饮食和高兴饮食之间达到均衡是十分艰难的。现实状况下，应该为每个人构建其专属的食物模型来定制其饮食。因而本次分享将围绕如何构建集体专属食物模型及食物图谱开展。 一款新型的食物日志工具 FoodLog Athl横空出世，它可用于与饮食相干的医疗保健及饮食评估服务。该工具从营养师或监控用户角度登程，能够反对食物图像识别，养分膳食评估、食物养分值测算等多项性能。 此外，本次分享还将介绍该工具在 COVID-19 前后施展的作用以及相干食物统计数据变动等要害科研成果。 神经网络已成为最弱小的预测零碎之一。其中深度学习的贝叶斯范式将概率作为神经网络架构和参数的学习指标，并通过后验散布对预测的不确定性进行量化。本次分享中咱们将探讨为什么须要不确定性预计、以及如何对其进行建模和测算等，同时为了进一步展现其利用价值，咱们将探讨食品辨认如何利用不确定性进行建模。 02 Challenge Report 本次研讨会组织的以“大规模食品图像识别和检索”为主题的挑战赛也吸引了国内外泛滥有实力的团队参加，包含清华大学、中国科技大学、南京理工大学、巴塞罗那大学、新加坡南洋理工大学；阿里巴巴、深兰科技、OPPO、欢聚时代等公司在内的143个国内外团队加入较量。 赛事划分了大规模食品图像细粒度辨认和大规模食品图像细粒度检索两大赛道，依据最终后果及提交的技术计划进行评比。研讨会中以下获胜队伍也将像大家汇报比赛成绩与技术计划。 Table 1. The ranking list of the top-3 teams in the “Large-scale fine-grained food recognition” challenge at ICCV 2021 Table 2. The ranking list of the top-3 teams in the “Large-scale fine-grained food retrieval” challenge at ICCV 2021 福利：数据集继续凋谢在本次较量中，咱们提出了蕴含超过 1,000个细粒度食物类别和超过 500,000 张图像的数据集，蕴含西餐和中餐。在食品专家的帮忙下，联合和改编现有的食品分类零碎，构建了对立的食品本体。每个类别的图像数量在[153; 1999]范畴内，与现有食物数据集相比，体现出更大的类别不均衡，也为辨认、检索带来更大挑战！借由本次研讨会及比赛的契机，咱们也将继续公开该数据集，为推动计算机视觉在食品剖析畛域的利用提供贵重助力。 ...

客服是在用户服务体验不完满的状况下，尽可能帮忙体验顺畅进行上来的一种解决办法，是问题产生后的一种兜底计划。而智能客服能让大部分简略的问题得以疾速自助解决，让简单问题有机会被人工高效解决。在用户服务的全旅程中，美团平台/搜寻与NLP部提供了问题举荐、问题了解、对话治理、答案供应、话术举荐和会话摘要等六大智能客服外围能力，以期达到低成本、高效率、高质量地与用户进行沟通的目标。本文次要介绍了美团智能客服核心技术以及在美团的实际。1 背景目前，美团的年交易用户量为6.3亿，服务了770万生存服务类商家。此外，在美团优选业务中还有一个很大的团长群体。美团平台涵盖吃、住、行、游、购、娱等200多个生存服务品类，在平台服务的售前、售中、售后各个环节，都有大量信息征询、订单状态获取以及申述投诉等沟通诉求。另外，作为一家领有几万名员工的上市企业，员工之间亦有大量的沟通诉求。面对以上这些需要，如果都是通过人力进行实现，显然不合乎公司久远倒退的指标，这就须要引入智能客服。 1.1 面对不同场景的智能客服落地首先，咱们看看日常生活中几种最为常见的客服场景。 售前场景：比方消费者在平台抉择入住酒店，对房型价格、酒店设施、入退房政策等，下单前都有很强的信息征询诉求。售中场景：比方外卖催单还没到，增加备注不要辣、加开发票等征询等等，售前和售中场景次要产生在消费者和商家或平台之间。售后场景：比方外卖场景投诉菜品少送、骑手送餐超时、要求退款等，酒店场景投诉酒店到店无奈入住等，售后往往波及到客服座席、消费者、骑手和商家，须要多方协同解决。办公场景：比方IT、人力资源、财务、法务等征询，产运研对提供的接口产品的征询答疑，产品对销售参谋的答疑，以及销售参谋对商家的答疑等等。1.2 面对不同人群的智能客服落地沟通是人类的一项根本需要，在绝大多数场景下，咱们对沟通的谋求都是以低成本、高效率和高质量为指标，而对话机器人也须要同时满足这三点要求。目前咱们依照服务的群体进行划分，智能客服落地场景大体能够分为以下四类： 面向用户：提供智能客服机器人，来帮忙他们自助解决大部分的问题。面向座席：用话术举荐或者会话摘要等能力来晋升人工座席的工作效率，改善人工座席的工作体验。面向商家：打造商家助手来升高商家回复的费力度，改善消费者和商家的沟通体验。面向员工：通过对话机器人，能够自助给员工进行答疑，从而晋升办公效率。1.3 智能客服是什么要答复智能客服是什么，能够先看看客服是什么。咱们的了解是，客服是在用户服务体验不完满的时候，来帮忙体验顺畅进行上来的一种解决办法，是问题产生后的一种兜底计划。而智能客服能让大部分简略的问题得以疾速自助解决，让简单问题有机会被人工高效解决。 上图展现的是用户服务旅程。首先，用户会通过在线打字或者拨打热线电话的形式进线寻求服务，其中在线征询流量占比在85%以上。当用户进入到服务门户后，先是用户表白需要，而后是智能机器人响应需要，过程中机器人先要了解问题，比方是追加备注或是批改地址，还是申请退款等等，继而机器人尝试自助解决。如果解决不了，再及时地流转到人工进行兜底服务。最初，当用户来到服务时，零碎会发送考察问卷，期待用户对本次服务进行评估。 2 智能客服核心技术2.1 对话交互技术概述 智能客服背地的技术次要是以对话交互技术为外围。常见的对话工作可分为闲聊型、工作型和问答型： 闲聊型：通常是不关注某项特定工作，它的次要的指标是和人进行凋谢畛域的对话，关注点是生成晦涩、正当且天然的回复。工作型：通常是帮忙用户实现某项工作指令，如查找酒店、查问订单状态、解决用户的退款申请等等。用户的需要通常比较复杂，须要通过多轮交互来一直收集工作所需的必要信息，进而依据信息进行决策，执行不同的动作，最终实现用户的指令。问答型：侧重于一问一答，即间接依据用户的问题给出精准答案。问答型和工作型最实质的区别在于，零碎是否须要保护一个用户指标状态的示意和是否须要一个决策过程来实现工作。在技术实现上，通常又能够划分为检索式、生成式和工作式： 检索式：次要思路是从对话语料库中找出与输出语句最匹配的回复，这些回复通常是事后存储的数据。生成式：次要思路是基于深度学习的Encoder-Decoder架构，从大量语料中习得语言能力，依据问题内容及相干实时状态信息间接生成答复话术。工作式：就是工作型对话，通常要保护一个对话状态，依据不同的对话状态决策下一步动作，是查询数据库还是回复用户等等。闲聊、问答、工作型对话实质都是在被动地响应用户需要。在具体业务中还会有问题举荐、商品举荐等来被动疏导用户交互。在美团的业务场景里次要是工作型和问答型，两头也会交叉一些闲聊，闲聊次要是打招呼或者简略情绪安抚，起到光滑人机对话的作用。 如后面用户服务流程所介绍的那样，用户的沟通对象可能有两个，除了跟机器人沟通外，还可能跟人工沟通。如果是找客服场景人工就是客服座席，如果是找商家场景人工就是商家。机器人的能力次要包含问题举荐、问题了解、对话治理以及答案供应。 目前，掂量机器人能力好坏的外围输入指标是不满意度和转人工率，别离掂量问题解决的好坏，以及能帮人工解决多少问题。而在人工辅助方面，咱们提供了话术举荐和会话摘要等能力，外围指标是ATT和ACW的升高，ATT是人工和用户的均匀沟通时长，ACW是人工沟通后的其它解决时长。 2.2 智能机器人——多轮对话 这是一个实在的多轮对话的例子。当用户进入到服务门户后，先抉择了一个举荐的问题“如何分割骑手”，机器人给出了联系方式致电骑手。同时为了进一步厘清场景，询问用户是否收到了餐品，当用户抉择“还没有收到”的时候，联合预计送达工夫和以后工夫，发现还未超时，给出的计划是“好的，帮用户催一下”，或者是“我再等等吧”，这时候用户抉择了“我再等等吧”。 这个例子背地的机器人是怎么工作的呢？首先当用户输出“如何分割骑手”的时候，问题了解模块将它与知识库中的拓展问进行匹配，进而失去对应的规范问即用意“如何分割骑手”。而后对话治理模块依据用意“如何分割骑手”触发相应的工作流程，先查问订单接口，获取骑手电话号码，进而输入对话状态给到答案生成模块，依据模板生成最终后果，如左边的红框内容所示。在这个过程中波及到要先有用意体系、定义好Task流程，以及订单的查问接口，这些都是业务强相干的，次要由各业务的经营团队来保护。那么，对话零碎要做的是什么呢？一是将用户的输出与用意体系中的规范问进行匹配，二是实现多轮交互外面的调度。 问题了解是将用户问题与用意体系进行匹配，匹配到的拓展问所对应的规范问即用户用意。机器人的工作过程理论是要做召回和精排两件事件。召回更多地是用现有检索引擎实现，技术上更多地关注精排。 美团自研的智能客服零碎是从2018年开始搭建的，在建设的过程中，咱们一直地将业界最先进的技术引入到咱们的零碎中来，同时依据美团业务的特点，以及问题了解这个工作的特点，对这些技术进行适配。 比如说，当2018年底BERT（参见《美团BERT的摸索和实际》一文）呈现的时候，咱们很快全量应用BERT替换原来的DSSM模型。前面，又依据美团客服对话的特点，咱们将BERT进行了二次训练及在线学习革新，同时为了防止业务之间的烦扰，以及通过减少常识辨别性升高乐音的烦扰，咱们还做了多任务学习（各业务在下层为独立工作）以及多域学习（Query与拓展问匹配，改为与拓展问、规范问和答案的整体匹配），最终咱们的模型为Online Learning based Multi-task Multi-Field RoBERTa。通过这样一系列技术迭代，咱们的辨认准确率也从最后不到80%到当初靠近90%的程度。 了解了用户用意后，有些问题是能够间接给出答案解决的，而有些问题则须要进一步厘清。比如说“如何申请餐损”这个例子，不是间接通知申请的办法，而是先厘清是哪一个订单，是否影响食用，进而厘清一些用户的诉求是局部退款还是想安顿补送，从而给出不同的解决方案。这样的一个流程是跟业务强相干的，须要由业务的经营团队来进行定义。如左边工作流程树所示，咱们首先提供了可视化的TaskFlow编辑工具，并且把外呼、地图以及API等都组件化，而后业务经营人员能够通过拖拽的形式来实现Task流程设计。 对话引擎在与用户的实在交互中，要实现Task内各步骤的匹配调度。比方这个例子里用户如果不是点选”能够但影响就餐了…”这条，而是本人输出说“还行，我要局部退款”，怎么办？这个用意也没有提前定义，这就须要对话引擎反对Task内各步骤的含糊匹配。咱们基于Bayes Network搭建的TaskFlow Engine恰好能反对规定和概率的联合，这里的含糊匹配算法复用了问题了解模型的语义匹配能力。 这是另外一个例子，在用户问完“会员是否退订”后，机器人回复的是“无奈退回”，尽管答复了这个问题，但这个时候用户很容易不称心，转而去寻找人工服务。如果这个时候咱们除了给出答案外，还去厘清问题背地的实在起因，疏导询问用户是“外卖红包无奈应用”或者是“因换绑手机导致的问题”，基于顺承关系建模，用户大概率是这些状况，用户很有可能会抉择，从而会话能够进一步进行，并给出更加精密的解决方案，也缩小了用户间接转人工服务的行为。 这个疏导工作称为多轮话题疏导，具体做法是对会话日志中的事件共现关系以及顺承关系进行建模。如左边图所示，这里本来是要建模句子级之间的疏导，思考到句子稠密性，咱们是将其形象到事件之间的疏导，共现关系咱们用的是经典的协同过滤形式建模。另外，思考到事件之间的方向性，咱们对事件之间的顺承关系进行建模，公式如下： 并通过多指标学习，同时思考点击指标和工作指标，如在非转人工客服数据和非不称心数据上别离建模顺承关系，公式如下： 最终，咱们在点击率、不满意度、转人工率层面，都获得了十分正向的收益。 美团平台涵盖吃、住、行、游、购、娱等200多个生存服务品类，当用户是从美团App或点评App等综合服务门户入口进入服务时，须要后行确定用户要征询的是哪个业务，这里的一个工作是“判断用户Query是属于哪个业务”，该工作咱们叫做畛域辨认。若能明确判断畛域时，则间接用该畛域常识来解答；当不能明确判断时，则还须要多轮对话交互与用户进行廓清。比方用户输出“我要退款”，在多个业务里都存在退款用意，这个时候就须要咱们先判断是哪个业务的退款用意，如果判断置信度不高，则给出业务列表让用户自行抉择来进行廓清。 畛域辨认模型次要是对三类数据建模：各畛域知识库的有标数据、各畛域大量弱监督无标数据和个性化数据。 根据从各畛域知识库的有标数据中学习失去的问题了解模型信号，能够判断用户输出属于各业务各用意的可能性。咱们留神到除了美团App、点评App等综合服务入口波及多个业务外，还有大量可能明确业务的入口，比如说订单入口，从商品详情页进来的入口，这些入口进来的对话数据是有明确业务标签信息的。因而，咱们能够失去大量的弱监督的各业务畛域的数据，基于这些数据咱们能够训练一个一级分类模型。同时，有些问题是须要联合用户订单状态等个性化数据能力进一步明确的。比方“我要退款”，多个业务里都会有。因而，又要联合用户状态特色一起来训练一个二级模型，最终来判断用户的输出属于哪个业务。最终，该二级畛域辨认模型在满意度、转人工率以及胜利转接率指标上都获得了十分不错的收益。 2.3 智能机器人——问题举荐 在介绍完多轮对话根底模块问题了解和对话治理后，接下来咱们介绍一下智能机器人的另外两个模块：问题举荐和答案供应。如后面多轮对话的例子所示，当用户进入服务门户后，机器人首先是要如何疏导用户精准地表白需要，这样即可升高用户迷失或者间接转人工服务，也升高了若机器人不能正确理解时带来的多轮廓清等有效交互。 该问题是一个规范的曝光点击问题，它的实质是举荐问题。咱们采纳了CTR预估工作经典的FM模型来作为根底模型，同时联合业务指标，冀望用户点击的问题的解决方案可能解决用户问题，该问题最终定义为“曝光、点击、解决”问题，最终的模型是联合多指标学习的ESSM-FM，对无效交互的转化率、转人工率和不满意度等指标上都带来了晋升。 2.4 智能机器人——答案供应 售后客服场景通常问题较集中，且问题的解决多依赖业务外部零碎数据及规定，通常是业务部门保护知识库，包含用意体系、Task流程和答案等。但在售前场景，常识多来自于商户或商品自身、用户体验及评估信息等，具备用户问题凋谢、常识密度高、人工难以整顿答案等特点。比方去哪个城市哪个景点玩耍，左近有哪些酒店，酒店是否有浴缸，酒店地址在哪里等，都须要征询”决策”，针对这些诉求，咱们通过智能问答来解决征询以及答案供应问题。 智能问答就是从美团数据中习得答案供应，来疾速答复用户的问题，基于不同的数据源，咱们建设了不同的问答技术。 针对商家根底信息，比方问营业时间、地址、价格等，咱们通过图谱问答（KBQA）来解决。利用商家根底信息构建图谱，通过问题了解模型来了解问题，进而查问图谱获取精确的答案。针对社区数据，即商户详情页中“问大家”模块的用户问用户答的社区数据，构建社区问答（Community QA）能力，通过对用户问题与问大家中的”问答对”的类似度建模，抉择类似度最高的作为答案，来答复用户的一些开放性问题。针对UGC评论数据以及商户政策等无结构化数据，构建文档问答（Document QA）能力，针对用户问题利用机器浏览了解技术从文档中抽取答案，相似咱们小时候语文考试中的浏览了解题，进一步答复用户的一些开放性问题。最初，针对多个问答模块给出的答案，进行多答案起源的答案交融排序，来筛选最终的答案，此外这里还考查了答案真实性，即对“置信少数认为正确的则正确”建模。这部分的具体介绍大家能够参考《美团智能问答技术摸索与实际》一文。 3 人工辅助核心技术3.1 人工辅助——话术举荐 前文介绍的都是智能机器人技术，用户除了跟机器人沟通外，还可能是跟人工沟通。咱们在客服座席职场调研过程中发现，座席在与用户的对话聊天中常常回复类似甚至雷同的话术，他们统一冀望提供话术举荐的能力来提高效率。此外，除了申请客服座席帮忙外，很多状况下用户与商家间接沟通会使得解决问题更高效，而沟通效率不仅影响到消费者的体验，也影响到了商家的经营。比方在外卖业务中，消费者的下单率和商家的回复时长有较为显著的正比关系，无论是客服座席还是商家，都有很强的话术举荐诉求。 那么，话术举荐具体要怎么做呢？常见的做法是先筹备好罕用通用话术库，局部座席或商家也会筹备集体常见话术库，而后零碎依据用户的Query及上下文来检索最合适的话术来举荐。咱们依据考察发现，这部分知识库保护得很不好，既有业务知识变更频繁导致已保护的常识很快不可用因素，也有座席或商家自身志愿不强的因素等。另外，针对新客服座席或者新商家，可用的教训更少。因而咱们采纳了主动记忆每个座席及其同技能组的历史聊天话术，商家及其同品类商家的历史聊天话术，依据以后输出及上下文，预测接下来可能的回复话术，无需人工进行整顿，大大晋升了效率。 ...

ACL是计算语言学和自然语言解决畛域最重要的顶级国内会议。据谷歌学术计算语言学刊物指标显示，ACL影响力位列第一，是CCF-A类举荐会议。美团技术团队共有7篇论文（其中6篇长文，1篇短文）被ACL 2021接管，这些论文是美团技术团队在事件抽取、实体辨认、用意辨认、新槽位发现、无监督句子示意、语义解析、文档检索等自然语言解决工作上的一些前沿摸索及利用。计算语言学协会年会（ACL 2021）于2021年8月1日至6日在泰国曼谷举办（虚构线上会议）。ACL是计算语言学和自然语言解决畛域最重要的顶级国内会议，该会议由国内计算语言学协会组织，每年举办一次。据谷歌学术计算语言学刊物指标显示，ACL影响力位列第一，是CCF-A类举荐会议。往年ACL的主题是“NLP for Social Good”。据官网统计信息，本次会议共收到3350篇无效投稿，共计接管710篇主会论文（承受率为21.3%），493篇Findings论文（承受率为14.9%）。 美团技术团队共有7篇论文（其中6篇长文，1篇短文）被ACL 2021接管，这些论文是美团在事件抽取、实体辨认、用意辨认、新槽位发现、无监督句子示意、语义解析、文档检索等自然语言解决工作上的一些技术积淀和利用。 针对于事件抽取，咱们显示地利用周边实体的语义级别的论元角色信息，提出了一个双向实体级解码器（BERD）来逐渐对每个实体生成论元角色序列；针对于实体辨认，咱们首次提出了槽间可迁徙度的概念，并为此提出了一种槽间可迁徙度的计算形式，通过比拟指标槽与源工作槽的可迁徙度，为不同的指标槽寻找相应的源工作槽作为其源槽，只基于这些源槽的训练数据来为指标槽构建槽填充模型；针对于用意辨认，咱们提出了一种基于监督比照学习的用意特色学习办法，通过最大化类间间隔和最小化类内方差来晋升用意之间的区分度；针对于新槽位发现，咱们首次定义了新槽位辨认（Novel Slot Detection, NSD）工作，与传统槽位辨认工作不同的是，新槽位辨认工作试图基于已有的域内槽位标注数据去开掘发现实在对话数据里存在的新槽位，进而一直地欠缺和加强对话零碎的能力。 此外，为解决BERT原生句子示意的“坍缩”景象，咱们提出了基于比照学习的句子示意迁徙办法—ConSERT，通过在指标畛域的无监督语料上Fine-Tune，使模型生成的句子示意与上游工作的数据分布更加适配。咱们还提出了一种新的无监督的语义解析办法——同步语义解码（SSD），它能够联结使用复述和语法束缚解码同时解决语义鸿沟与构造鸿沟的问题。咱们还从改良文档的编码动手来进步文档编码的语义示意能力，既进步了成果也进步了检索效率。 接下来，咱们将对这7篇学术论文做一个更加具体的介绍，心愿能对那些从事相干钻研的同学有所帮忙或启发，也欢送大家在文末评论区留言，一起交换。 01 Capturing Event Argument Interaction via A Bi-Directional Entity-Level Recurrent Decoder| 论文下载| 论文作者：习翔宇，叶蔚（北京大学），张通（北京大学），张世琨（北京大学），王全修（RICHAI），江会星，武威| 论文类型：Main Conference Long Paper（Oral） 事件抽取是信息抽取畛域一个重要且富裕挑战性的工作，在主动文摘、主动问答、信息检索、常识图谱构建等畛域有着宽泛的利用，旨在从非结构化的文本中抽取出结构化的事件信息。事件论元抽取对具体事件的形容信息（称之为论元信息）进行抽取，包含事件参与者、事件属性等信息，是事件抽取中重要且难度极大的工作。绝大部分论元抽取办法通常将论元抽取建模为针对实体和相干事件的论元角色分类工作，并且针对一个句子中实体汇合的每个实体进行拆散地训练与测试，疏忽了候选论元之间潜在的交互关系；而局部利用了论元交互信息的办法，都未充分利用周边实体的语义级别的论元角色信息，同时疏忽了在特定事件中的多论元分布模式。 针对目前事件论元检测中存在的问题，本文提出显示地利用周边实体的语义级别的论元角色信息。为此，本文首先将论元检测建模为实体级别的解码问题，给定句子和已知事件，论元检测模型须要生成论元角色序列；同时与传统的词级别的Seq2Seq模型不同，本文提出了一个双向实体级解码器（BERD）来逐渐对每个实体生成论元角色序列。具体来说，本文设计了实体级别的解码循环单元，可能同时利用以后实例信息和周边论元信息；并同时采纳了前向和后向解码器，可能别离从左往右和从右往左地对以后实体进行预测，并在单向解码过程中利用到左侧/右侧的论元信息；最终，本文在两个方向解码实现之后，采纳了一个分类器联合双向编码器的特色来进行最终预测，从而可能同时利用左右两侧的论元信息。 本文在公开数据集ACE 2005上进行了试验，并与多种已有模型以及最新的论元交互办法进行比照。试验结果表明该办法性能优于现有的论元交互办法，同时在实体数量较多的事件中晋升成果更加显著。 02 Slot Transferability for Cross-domain Slot Filling| 论文下载| 论文作者：陆恒通（北京邮电大学），韩卓芯（北京邮电大学），袁彩霞（北京邮电大学），王小捷（北京邮电大学），雷书彧，江会星，武威| 论文类型：Findings of ACL 2021, Long Paper 槽填充旨在辨认用户话语中工作相干的槽信息，是工作型对话零碎的要害局部。当某个工作（或称为畛域）具备较多训练数据时，已有的槽填充模型能够取得较好的辨认性能。然而，对于一个新工作，往往只有很少甚至没有槽标注语料，如何利用一个或多个已有工作（源工作）的标注语料来训练新工作（指标工作）中的槽填充模型，这对于工作型对话零碎利用的疾速扩大有着重要的意义。 针对该问题的现有钻研次要分为两种，第一种通过建设源工作槽信息示意与指标工作槽信息示意之间的隐式语义对齐，来将用源工作数据训练的模型间接用于指标工作，这些办法将槽形容、槽值样本等蕴含槽信息的内容与词示意以肯定形式进行交互失去槽相干的词示意，之后进行基于“BIO”的槽标注。第二种思路采纳两阶段策略进行，将所有槽值看作实体，首先用源工作数据训练一个通用实体辨认模型辨认指标工作所有候选槽值，之后将候选槽值通过与指标工作槽信息的示意进行类似度比照来分类到指标工作的槽上。 现有的工作，大多关注于构建利用源-指标工作之间关联信息的跨工作迁徙模型，模型构建时个别应用所有源工作的数据。然而，实际上，并不是所有的源工作数据都会对指标工作的槽辨认具备可迁徙的价值，或者不同源工作数据对于特定指标工作的价值可能是很不雷同的。例如：机票预约工作和火车票预约工作类似度高，前者的槽填充训练数据会对后者具备帮忙，而机票预约工作和天气查问工作则差别较大，前者的训练数据对后者没有或只具备很小的借鉴价值，甚至起到烦扰作用。 再进一步，即便源工作和指标工作很类似，然而并不是每个源工作的槽的训练数据都会对指标工作的所有槽都有帮忙，例如，机票预约工作的登程时间槽训练数据可能对火车票预约工作的登程时间槽填充有帮忙，然而对火车类型槽就没有帮忙，反而起到烦扰作用。因而，咱们心愿能够为指标工作中的每一个槽找到能提供无效迁徙信息的一个或多个源工作槽，基于这些槽的训练数据构建跨工作迁徙模型，能够更为无效地利用源工作数据。 为此，咱们首先提出了槽间可迁徙度的概念，并为此提出了一种槽间可迁徙度的计算形式，基于可迁徙度的计算，咱们提出了一种为指标工作抉择出源工作中可能提供无效迁徙信息的槽的办法。通过比拟指标槽与源工作槽的可迁徙度，为不同的指标槽寻找相应的源工作槽作为其源槽，只基于这些源槽的训练数据来为指标槽构建槽填充模型。具体来说，可迁徙度交融了指标槽和源槽之间的槽值示意散布类似度，以及槽值上下文示意散布类似度作为两个槽之间的可迁徙度，而后对源工作槽根据其与指标槽之间的可迁徙度高下进行排序，用可迁徙度最高的槽所对应训练语料训练一个槽填充模型，失去其在指标槽验证集上的性能，根据依照可迁徙度排序退出新的源工作槽对应训练语料训练模型并失去对应的验证集性能，选取性能最高的点对应的源工作槽及可迁徙度高于该槽的源工作槽作为其源槽。利用抉择进去的源槽构建指标槽槽填充模型。 槽填充模型根据槽值信息及槽值的上下文信息对槽值进行辨认，所以咱们在计算槽间可迁徙度时，首先对槽值示意散布与上下文示意散布上的相似性进行了度量，而后咱们借鉴了F值对于准确率及召回率的交融形式，对槽值示意散布相似性及槽值上下文示意散布相似性进行了交融，最初利用Tanh将所失去的值归一化到0-1之间，再用1减去所失去的值，为了合乎计算失去的值越大，可迁徙度越高的直观认知。下式是咱们所提出的槽间可迁徙度的计算形式： $sim(p_v(s_a),p_v(s_b))$和$sim(p_c(s_a),p_c(s_b))$别离示意槽a与槽b在槽值示意散布与上下文示意散布上的相似性，咱们采纳最大均值差别（MMD）来掂量散布之间的类似度。 咱们并没有提出新的模型，然而咱们提出的源槽抉择办法能够与所有的已知模型进行联合，在多个已有模型及数据集上的试验表明，咱们提出的办法能为指标工作槽填充模型带来一致性的性能晋升（ALL所在列示意已有模型原始的性能，STM1所在列示意用咱们的办法选出的数据训练的模型性能。） 03 Modeling Discriminative Representations for Out-of-Domain Detection with Supervised Contrastive Learning| 论文下载| 论文作者：曾致远（北京邮电大学），何可清，严渊蒙（北京邮电大学），刘子君（北京邮电大学），吴亚楠（北京邮电大学），徐红（北京邮电大学），江会星，徐蔚然（北京邮电大学）| 论文类型：Main Conference Short Paper (Poster) ...

一次编写多处运行的动态化容器技术给研发效率带来了极大的晋升，但对于仍旧须要多端验证的测试流程来说，在效率层面却面临着极大的挑战。本文围绕动态化容器中的动静布局技术，论述了如何通过可测性革新来帮忙达成晋升测试效率的指标。心愿能够给同样须要测试动态化页面的同学们带来一些启发和帮忙。美团App的页面特点对于不同的用户，美团App页面的出现形式其实多种多样，这就是所谓的“千人千面”。以美团首页的“猜你喜爱”模块为例，针对与不同的用户有单列、Tab、双列等多种不同模式。这么多不同的页面款式需要，如果要在1天内工夫内实现开发、测试、上线流程，研发团队也面临着很大的挑战。所以测试工程师就须要重度依赖自动化测试来造成疾速的验收机制。 自动化测试施行中的技术挑战接下来，本文将会从页面元素无奈定位、Appium元素定位的原理、AccessibilityNodeInfo和Drawable等三个维度进行论述。 页面元素无奈定位 目前，美团App客户端自动化次要依靠于Appium（一个开源、跨平台的测试框架，能够用来测试原生及混合的挪动端利用）来实现页面元素的定位和操作，当咱们通过Appium Inspector进行页面元素审查时，能通过元素审查找到的信息只有里面的边框和下方的两个按钮，其余信息均无奈辨认(如上图2所示)。地方地位的图片、左上角的文本信息都无奈通过现有的UI自动化计划进行定位和解析。不能定位元素，也就无奈进行页面的操作和断言，这就重大影响了自动化的施行工作。 通过进一步的调研，咱们发现这些页面卡片中大量应用Drawable对象来绘制页面的信息，从而导致元素无奈进行定位。为什么Drawable对象无奈定位呢？上面咱们一起钻研一下UI自动化元素定位的原理。 Appium元素定位的原理目前的UI自动化测试，应用Appium进行页面元素的定位和操作。如下图所示，AppiumServer和UiAutomator2的手机端进行通信后实现元素的操作。 通过浏览Appium源码发现实现一次定位的流程如下图所示： 首先，Appium通过调用findElement的形式进行元素定位。而后，调用Android提供UIDevice对象的findObject办法。最终，通过PartialMatch.accept实现元素的查找。接下来咱们看一下，这个PartialMatch.accept到底是如何实现元素定位的。通过对于源码的钻研，咱们发现元素的信息都是存储在一个叫做AccessibilityNodeInfo的对象外面。源码中应用大量node.getXXX办法中的信息，大家是否眼生呢？这些信息其实就是咱们日常自动化测试中能够获取UI元素的属性。 Drawable无奈获取元素信息，是否和AccessibilityNodeInfo相干？咱们进一步探索Drawable和AccessibilityNodeInfo的关系。 AccessibilityNodeInfo和Drawable通过对于源码的钻研，咱们绘制了如下类图来解释AccessibilityNodeInfo和Drawable之间的关系。 View实现了AccessibilityEventSource接口并实现了一个叫做onInitializeAccessibilityNodeInfo的办法来填充信息。咱们也在Android官网文档中找到了对于此信息的阐明： onInitializeAccessibilityNodeInfo() ：此办法为无障碍服务提供无关视图状态的信息。默认的View实现具备一组规范的视图属性，但如果您的自定义视图提供除了简略的 TextView或Button之外的其余互动控件，则您应替换此办法并将无关视图的其余信息设置到由此办法解决的AccessibilityNodeInfo对象中。而Drawable并没有实现对应的办法，所以也就无奈被自动化测试找到。探索了元素查找原理之后，咱们就要开始着手解决问题了。 页面视图可测性革新-XraySDK定位计划比照既然晓得了Drawable没有填充AccessibilityNodeInfo，也就阐明我无奈接入目前的自动化测试计划来实现页面内容的获取。那咱们能够想到如下三种计划来解决问题： 实现计划影响范畴革新Appium定位形式，让Drawable能够被辨认须要改变底层的AccessibilityNodeInfo obtain(View,int)办法和为Drawable增加AccessibilityNodeInfo这样就须要对于所有的Android零碎做兼容，影响范畴过大应用View代替Drawable动静布局卡片应用Drawable进行绘制就是因为Drawable比View应用资源更少，绘制性能更好，放弃应用Drawable就等于放弃了性能的改良应用图像识别进行定位动静卡片中有很多图像中蕴含文字，还有多行文本都会对图像识别的准确性带来很大的影响下面的三种计划，目前看来都无奈无效地解决动静卡片元素定位的问题。如何在影响范畴较小的前提下，达成获取视图信息的指标呢？接下来，咱们将进一步钻研动静布局的实现计划。 视图信息的获取和存储-XrayDumper咱们的利用场景十分明确，自动化测试通过集成Client来取得和客户端交互能力，通过Client向App发送指令来页面信息的获取。那咱们能够思考内嵌一个SDK（XraySDK）来实现视图的获取，而后再向自动化提供一个客户端（XrayClient）来实现这部分性能。 对于XraySDK的性能划分，如下表所示： 模块名性能划分运行环境产品状态Xray-Client1.和Xray-Server进行交互进行指令发送和数据的接管2.裸露对外的Api给自动化或者其余零碎App外部客户端SDK（AAR和Pod-Library）Xray-SDK1.进行页面信息的获取以及结构化(Xray-Dumper)2.接管用户指令来进行结构化数据输入(Xray-Server)自动化外部或者三方零碎外部JAR包或基于其余语言的依赖包XraySDK如何能力获取到咱们须要的Drawable信息呢？咱们先来钻研一下动静布局的实现计划。 动静布局的视图出现过程分为：解析模板->绑定数据->计算布局->页面绘制，计算布局完结后，元素在页面上的地位就曾经确定了，那么只有拦挡这个阶段信息就能够实现视图信息的获取。 通过对于代码的钻研，咱们发现在com.sankuai.litho.recycler.AdapterCompat这个类中管制着视图布局行为，在bindViewHolder中实现视图的最终的布局和计算。首先，咱们通过在此处插入一个自定义的监听器来拦挡布局信息。 public final void bindViewHolder(BaseViewHolder<Data> viewHolder, int position) { if (viewHolder != null) { viewHolder.bindView(context, getData(position), position); //自动化测试回调 if (componentTreeCreateListeners != null) { if (viewHolder instanceof LithoViewHolder) { DataHolder holder = getData(position); //获取视图布局信息 LithoView view = ((LithoViewHolder<Data>) viewHolder).lithoView; LayoutController layoutController = ((LithoDynamicDataHolder) holder).getLayoutController(null); VirtualNodeBase node = layoutController.viewNodeRoot; //通过监听器将视图信息向外传递给可测性SDK componentTreeCreateListeners.onComponentTreeCreated(node, view.getRootView(), view.getComponentTree()); } } } }而后，通过裸露一个静态方法给可测性SDK，实现监听器的初始化。 ...

Pike 2.0致力于为美团提供一套易接入、高牢靠、高性能的双向音讯投递服务。本文首先从零碎架构降级、工作模式降级、长稳保活机制降级等方面介绍了Pike2.0的技术演进，而后介绍了Pike 2.0在直播、游戏等新业务场景下的个性反对。心愿本文能给对音讯投递服务感兴趣或者从事相干工作的读者一些帮忙和启发。1 Pike的前世今生1.1 Pike 1.0的诞生背景2015年，美团诞生了Shark终端网络通道，为公司挪动端提供长连代理减速服务。Shark通过网络接入点的寰球多地部署和放弃长连来晋升网络申请的端到端成功率，升高端到端延时，从而晋升用户体验。 Pike 1.0是基于Shark长连通道实现的利用内推送服务。因为底层传输基于Shark长连通道，使得Pike 1.0天生便具备了低延时、高牢靠、防DNS劫持等优良基因。目前Pike 1.0在美团外部的实时互动、营销推送、状态下发、配置同步等业务场景都有宽泛应用。 1.2 Pike 1.0的工作流程挪动端SDK会在每次长连贯创立胜利后，应用APPID、设施惟一标识UnionID（美团惟一标识、点评惟一标识等）向服务器发动注册，在注册胜利之后业务服务端就能够通过Pike 1.0服务端SDK提供的接口，被动向设施的App推送音讯。服务端推送的音讯通过长连贯通道到达客户端，最初通过注册的回调接口投递给业务方。整体工作流程参见下图： 1.3 Pike 1.0的劣势Pike 1.0底层传输基于Shark长连通道，所以Pike 1.0在以下几个方面有不错的体现： 防DNS劫持：底层通道间接应用IP直连，省去DNS解析耗时的同时也防止了被DNS劫持的危险。低延时：Shark长连贯采纳就近接入点长连贯的形式，省去了传统HTTP传输须要屡次建连、握手的耗费，端到端数据传输延时相比HTTP大幅缩短。安全性好：Shark采纳自定义二进制协定进行数据传输，进行了通道级别的TLS加密，防篡改，更平安。更好的境外体验：Pike 1.0与Shark共享服务集群，Shark长连通道在海内多地都部署了接入点，代理减速接入，网络延时及成功率体现要优于惯例申请。1.4 Pike 1.0的痛点Pike 1.0作为Shark的衍生产品诚然有其闪光的中央，然而对Shark的强依赖所带来的痛点更是让开发人员叫苦不迭，次要痛点如下。 1.4.1 代码构造耦合在客户端SDK方面，Pike 1.0代码与Shark代码构造耦合，共用底层通道建连、数据加解密、二进制协定等逻辑。如图展现了Pike 1.0与Shark在代码构造上的关系。 耦合带来的弊病一：代码优化降级艰难。针对一个SDK的变更常常须要更多地思考对另一个SDK是否有负面影响，是否影响面可控，这就无端地减少了开发成本。 耦合带来的弊病二：Shark与Pike 1.0的网络配置环境共用，如图所示，通过DebugPanel对SharkTunnel进行网络环境配置都会同时对Shark和Pike 1.0失效，然而业务方在应用的时候往往只关注其中的一个SDK，不同SDK之间的相互影响引入了很多客服问题，也给客服问题的排查带来了较多烦扰因素。 1.4.2 账号体系凌乱Pike 1.0在同一个App上只反对一种设施惟一标识UnionID，不同App上注册应用的UnionID会有不同，例如美团应用美团惟一标识，点评则应用点评惟一标识。如果一个业务只在一个App上应用的话Pike 1.0天然能够很好地工作，然而同一个业务有可能须要在多个App上同时应用（如图所示），如果业务方不对账号体系进行兼容的话，美团App上应用点评惟一标识作为推送标识的业务将无奈工作，点评App上应用美团惟一标识作为推送标识的的业务也会无奈工作。这就导致同一个业务在不同App上的推送标识ID逻辑会非常复杂，后端要同时保护多套账号体系之间的映射，能力解决账号体系凌乱的问题。 1.4.3 推送连贯不稳固Pike 1.0因为共用Shark的通道逻辑而不足推送场景专项优化，在检测通道异样、断连复原等方面体现不够优良。在通道可用性上，Shark与Pike 1.0关注的SLA也有着很大的不同。 例如，Shark在长连贯通道不可用的状况下，能够通过降级短连贯来躲避业务网络申请继续失败所带来的成功率降落问题。然而对于Pike 1.0此时如果通道不能疾速复原的话就会造成业务音讯投送失败，将间接影响音讯投递成功率。所以Shark通道针对连贯保活的公共逻辑并不能完满地利用在Pike 1.0业务场景上。 尽管Pike 1.0在Shark通道的根底上进一步在协定层强化了心跳探测机制以进步通道可用性，但通道不能及时检测异样还是时有发生。此外，Pike 1.0外部应用的事件散发技术的可靠性还临时没能达到100%，零星地会上报一些异样断连而导致推送不胜利的客服问题。综上，针对推送连贯不稳固专项优化的诉求也就一直被提上日程。 1.5 Pike 2.0的诞生Pike 1.0现有的痛点在业务场景日益丰盛的现状下遭逢了诸多挑战。力求解决Pike 1.0现有在Android和iOS平台经营上遇到的问题，一方面咱们从新梳理产品架构与代码实现，另一方面咱们决定与根底技术部另一个服务于H5的音讯投递服务Pike Web进行产品交融，进而推出全新的降级产品——Pike 2.0。 下图展现了Pike 2.0的产品全景，针对Pike 1.0的现状，Pike 2.0前后端都做了诸多优化，包含技术架构降级、集群独立、协定扩大等。其中在客户端方面Pike 2.0提供了基于多语言实现服务于多平台的SDK，在服务端方面Pike应用部署Java利用的分布式集群来提供服务。 本文次要从客户端视角，具体论述Pike 2.0 客户端SDK的技术方案设计，从原理上阐明Pike 2.0带来的技术劣势。 2 Pike 2.0架构设计针对上文提及的Pike 1.0代码构造耦合的痛点，Pike 2.0进行了全新的架构降级，在代码构造、环境配置、服务集群等方面上都与Shark放弃产品隔离。 ...

1 、前言很多小伙伴想做外卖CPS赚钱，那给大家做一起超具体的外卖CPS教程。话不多说，间接上货 2、上图 3、筹备工作1个订阅号或者1个服务号，这里须要晓得的是订阅号是收费申请的，服务号微信是要免费认证的。2 本人的邀请码（用户点击本人邀请码本人获取推广佣金），获取邀请码形式之前曾经说过了，获取美团饿了么的推广链接 ## 4、开始搭建1 公众号关联小程序点击菜单的外卖红包，就跳到美团和饿了么的小程序领优惠券，所以须要把饿了么小程序和美团小程序关联在本人公众号才能够关上。饿了么小程序AppID：wxece3a9a4c82f58c9 （所有人都一样）美团小程序AppID：wxde8ac0a21135c07d（所有人都一样） 2 设置公众号菜单 给大家汇总一下引流渠道吧1.快递贴外卖红包广告 2.信息流投放 3.BOOS直聘引流 4.闲鱼引流 5.线下引流（包含外卖员引流，商家单干，地推） 6.豆瓣QQ群引流 7.短视频引流（我感觉更适宜杂粉，批量进就完事了） 8.购物类平台玩0.1直通车类引流 根本把大家罕用的引流办法都总结了一下，大家在引流的时候抉择本人的适宜的，大家只须要把本人的执行力提上来，这样战败50%的人了，真正认真做，去经营，你能超过90%的人，在此基础上在去翻新，你就能够站在行业的天花板，所以加油奥。 拉群的形式目前转化率挺高，大家能够通过霸王餐（发红包侥幸王免单），做游戏，答题等来沉闷群内氛围，从而达到高转化，这些都是群里老哥的办法，大家本人总结进去。 好了不BB了，第一次写怎么具体的长文和输入，心愿有不懂的能够分割我而后帮我评论一个有用！！ ## 最初 贴一张推广大佬的收益图，只有你能推广，赚钱真的很容易。 <img src="https://img-blog.csdnimg.cn/20210131174829938.png" width="600px" height="800px" /> 作者相干文章零根底搭建获利的美团饿了么优惠券CPS小程序(附源码) 反编译获取任何微信小程序源码——看这篇就够了 如何获取美团饿了么的推广链接赚钱

在深度学习时代，算力的需要和耗费日益增长，如何升高算力老本，进步算力效率，逐步成为一个重要的新课题。智能算力旨在对算力进行精细化和个性化调配，实现最优化资源利用。本文次要分享美团外卖广告在智能算力摸索和实际过程中积攒的教训，心愿能给大家带来一些帮忙或者启发。 1. 业务背景目前，美团外卖日订单量已冲破4000万，成为美团最为重要的业务之一。外卖广告服务也从最后的撑持繁多业务线倒退到当初的十余条业务线，服务整体接受的流量日益增长，所耗费的机器资源也达到了肯定的规模。 在外卖场景下，流量出现显著的双峰构造，即午餐和晚餐两个时段为流量波峰，其余时段流量较小。在这种流量特点下，外卖广告服务在顶峰时段面临较大的性能压力，在非顶峰时段存在大量算力冗余，从全局来看，机器算力调配效率低，流量价值依然具备较大的开掘空间。一方面，流量耗费的算力没有依据流量价值进行动静的调配，造成零碎在高价值流量上算力调配有余，价值没有失去充沛的开掘，而在低价值流量上，却存在节约大量算力的景象；另一方面，在非顶峰时段，零碎流量较低，导致系统的整体资源利用率偏低，限度了零碎获取更高的业务收益。 因而，算力须要进行更正当的调配来失去更加高效的利用。以后业界对于动静算力调配的钻研较少，以阿里巴巴定向广告平台的DCAF[1]为代表，该计划依据流量价值进行差异化的算力调配，对不同价值的流量调配不同的候选队列长度，实现无限资源束缚下的收益最大化。DCAF提供了一种优良的解决方案，但该计划在外卖广告场景下存在肯定的局限性。 针对外卖广告场景，外卖广告技术团队在DCAF计划的根底上进行了一系列摸索和改良，首次进行了队列弹性调配和模型弹性调配相结合的尝试，并获得了不错的收益。一方面，在机器资源持平的状况下，CPM能够晋升2.3%；另一方面，在业务收益持平的状况下，机器资源能够缩小40%，最初咱们在外卖列表广告精排阶段推全了机器资源持平的计划。 2. 整体思路 在外卖广告投放引擎中，为应答极大的在线流量压力和宏大的候选集，咱们将整个检索过程设计成候选集顺次递加的漏斗型级联架构，次要蕴含召回、粗排、精排、机制等模块。 实现智能算力的整体思路，是在零碎算力容量束缚下，对不同价值流量进行差异化算力调配，从而进步在广告检索过程中的算力调配效率，实现收益的最大化。智能算力次要包含以下四个因素： 1. 流量价值量化：流量价值指流量为平台、广告商家、用户三方带来的收益，零碎须要具备量化流量价值的能力。 2. 流量算力量化：流量算力指流量在零碎内耗费的机器资源，在外卖广告场景下，流量耗费的算力和候选集大小、召回通道数量、模型大小、链路复杂度等零碎变量严密相干，同样零碎须要具备量化流量算力的能力。 3. 零碎算力容量量化：零碎算力容量指零碎的机器资源总和，和流量算力量化的量纲统一，通常能够通过压测等伎俩获取零碎的算力容量；在零碎算力调配过程中，须要保障总体流量算力耗费不超过零碎的算力容量。 4. 智能算力调配：基于以上三个因素，在广告投放引擎全链路进行智能算力调配，咱们把算力调配的伎俩定义为“弹性动作”，在外卖广告场景下，咱们次要演绎了以下四种动作： 弹性队列：线上检索是一个漏斗的过程，不同价值流量能够在级联漏斗的各模块中调配不同候选队列长度。弹性模型：在模型预估服务中，不同价值流量能够调配不同模型，大模型绝对小模型预估成果更好的同时耗费的算力也更多。弹性通道：在多通道召回中，不同价值流量能够调配不同的召回通道。弹性链路：在检索链路上，不同价值流量能够调配不同复杂度的检索链路。 这些弹性动作的可选范畴，定义为“弹性档位”，如队列长度100和200对应弹性队列的两个不同档位。在智能算力下，算力的调配过程即弹性动作和弹性档位的智能决策过程。 挑战剖析为了让智能算力在外卖广告场景着落地，咱们次要面临着如下的挑战： 问题求解 挑战点：智能算力的指标是最优化算力资源分配，这就要求咱们对“在零碎算力束缚下，最大化流量收益”这个问题进行求解。应答思路：参考已有计划，将问题拆解为流量价值预估、流量算力预估以及算力调配三个子问题进行求解，并针对外卖广告场景进行摸索和改良。零碎稳定性保障 挑战点：将零碎算力调配托管给智能算力框架，从等额算力调配到智能算力调配，不仅须要保障智能算力框架自身的稳定性，更须要保证系统全链路的安稳运行。应答思路：除了监控报警、熔断降级等惯例保障伎俩，咱们实现了基于零碎状态的实时调控性能，保障系统稳定性。通用性&扩展性 挑战点：兼顾根底能力的复用和个性化能力的扩大，撑持外卖广告举荐和搜寻两大方向，多个业务场景的接入。应答思路：外围组件以SDK模式提供可复用、可扩大能力，同时基于通用的价值评估指标、算力评估指标和智能算力框架，撑持多弹性动作的组合决策和多业务场景的高效接入。3. 方案设计 通过工程团队和算法团队深度Co-Design后，咱们设计了一套多动作组合决策的智能算力框架。整个框架由决策组件、采集组件和调控组件组成，其中决策组件作为智能算力框架的外围，以SDK模式嵌入应用服务，提供可复用可扩大的多动作组合最优档位决策能力和零碎稳定性保障能力，为广告投放引擎的各阶段赋能；采集组件和调控组件为零碎稳定性保障提供撑持。上面次要对最优档位决策和零碎稳定性保障两个模块进行具体介绍。 3.1 最优档位决策在业内已有弹性队列求解计划的根底上，咱们进行一系列摸索和改良： 通过选用更加通用的流量算力评估指标，同时减少流量算力预估模块，保障量化指标通用的同时进步精确度，解决算力量化不通用和不准确的问题。通过构建非凡档位，首次尝试了弹性队列和弹性模型的联合，解决了局部流量无奈建模的问题。基于以上策略，咱们实现了多弹性动作组合最优化档位决策。 3.1.1 问题建模现有计划 DCAF[1]将该问题转化为对应的对偶问题进行求解，失去决策公式，实现弹性队列调配。 计划改良 上述建模计划在外卖广告场景中存在以下问题： 如图所示，因为档位$j=j_0$的算力和价值已知，无需对不同模型的价值和算力进行预估，后续的流量价值预估和流量算力预估工作都面向弹性队列即可。 3.1.2 决策框架 如图所示，最优档位决策模块分为离线和在线两个阶段，蕴含如下四个子模块： 流量价值预估模块（离线+在线）：预估流量在不同档位下的价值。流量算力预估模块（离线+在线）：预估流量在不同档位下的算力。离线 求解模块（离线）：通过回放历史流量，利用二分查找算法求解最优 。在线决策模块（在线）：对线上流量，基于档位决策公式计算最优档位，并依据计算结果调配不同模型和队列长度。3.1.3 流量价值预估流量价值预估是智能算力决策的外围，要求具备肯定准确性。而线上进行模型预估会减少检索链路耗时，咱们采纳离线XGB模型预估+在线查找词表的计划，既保证了预估的准确性，又足够轻量。 价值评估指标选取：一般来说，流量价值指以后流量为广告平台带来的支出；在外卖广告场景中，咱们关注平台支出的同时，也关注商家的支出，因而咱们的流量预估的指标选定为$k_1 * 平台支出 + k_2 * 商家支出$。 如图所示，流量价值预估模块蕴含离线和在线两个阶段。 离线阶段： 特色筛选&分桶：基于离线特色重要性剖析和散布状况，进行特色筛选和分桶。模型训练 次要问题：初期咱们采纳统计计划，在特色分桶较多的状况下，数据稠密问题重大，且队列长度越大，数据越稠密。解决方案：采纳XGB模型代替统计计划，加强泛化能力。分桶价值存储：不同特色分桶的价值预估后果以KV构造写入词表。在线阶段： 特色抽取&解析：进行特色抽取、解析，依照离线分桶规定生成Key值。原始价值预估：依据Key值查找对应分桶的价值，而后通过线性插值计算原始队列长度下申请的价值。档位价值预估：如下图所示，借助粗排打分，通过计算不同档位下价值的衰减状况，实现不同档位的价值预估。 3.1.4 流量算力预估业内智能算力的落地以弹性队列为主，个别采纳队列长度作为流量算力评估指标，而队列长度作为流量算力评估指标面临以下两个问题： 通用性问题：在弹性模型、弹性通道和弹性链路中流量算力耗费不禁队列长度惟一确定，比方不同起源的流量可能走不同模型（不同模型算力耗费可能不同）。精确度问题：外卖广告场景下，即便对于弹性队列动作，流量算力耗费和队列长度也不是简略的线性关系。算力评估指标选取：为了解决以上问题，咱们采纳流量耗费的CPU工夫作为流量算力评估指标。 如图所示，流量算力预估包含离线和在线两个阶段。 离线阶段： 特色筛选&分桶：基于离线特色重要性剖析和散布状况，进行特色筛选和分桶。模型训练 训练过程：首先将样本划分到不同特色分桶中（同一分桶中队列长度不同，其余特色雷同），而后别离对不同分桶拟合算力和队列长度的关系。 次要问题：因为数据分布不均匀，队列长度大于肯定阈值后，因为数据稠密，分桶内算力统计值开始呈现稳定，不利于线上决策。为了解决数据稠密的问题，并拟合实在业务中的拆包景象，咱们应用了分段线性拟合计划，将算力和队列长度之间的关系拟合为分段线性函数（下图是某个特色分桶内算力和队列长度关系拟合后果）。算力词表存储：不同特色分桶的算力预估后果以KV构造写入词表。在线阶段： ...

从 PC 时代、挪动时代到万物互联的 IoT 时代，随同终端设备的日趋多样化，跨端复用的种子自此落地，开始生根发芽。从业务角度登程，跨端技术演进更多是在不同阶段、不同时间段内业务效率上的抉择，美团民宿业务在大前端交融的浪潮中逐浪前行，一直摸索和迭代抉择，为解决业务痛点而孵化出跨端框架技术，在这个过程中，咱们进行了很多的摸索和实际的思考，心愿能给大家一些启发。本文次要分享美团民宿在跨端复用技术摸索和业务实际过程中的教训。从 PC 时代、挪动时代到万物互联的 IoT 时代，随同终端设备的日趋多样化，跨端复用的种子自此落地，开始生根发芽。从依附容器能力、各类离线化预装包的 Hybrid 计划，到通过 JSC 连贯 JavaScript 生态与原生控件，联合视图框架（React、Vue等）寻找效率、动态性和性能更平衡的 Native 容器计划（React Native、Weex 等），接着由微信牵头的以多过程 WebView、容器标准化的小程序计划入世，各平台小程序随之春笋萌生，随后带来了国内Taro、uni-app、Rax、Remax等多端框架的百家争鸣。 从业务角度登程，跨端技术演进更多是在不同阶段、不同时间段内业务效率上的抉择，美团民宿业务就是在大前端交融的浪潮中逐浪前行，一直摸索和迭代抉择，为解决业务痛点而孵化出跨端框架技术。本文次要分享美团民宿在跨端复用技术摸索层面以及业务实际过程中积攒的教训，心愿能给大家带来一些帮忙或者启发。 1. 背景1.1 美团民宿业务介绍美团民宿专一为消费者提供“住得不一样”的寄居体验，提供的服务包含民宿、酒店、公寓、客栈、短租、宾馆、旅行住宿等，同时包含树屋、房车、INS 风等离奇的网红民宿。美团民宿自上线之后，业务倒退迅猛，在供应侧，房源类型不断丰富，各类分销、直销、直连、境外陆续推出，房源信息维度一直扩大，筛选、举荐、信息出现也一直变得复杂。同时随同着营销形式的丰盛、房东治理、经营、服务的一直裁减，民宿的业务也越来越简单。美团民宿大前端随同业务的倒退一直自我迭代，挪动端整体架构也随之一直调整、降级，以寻求匹配业务多样化、复杂化的倒退诉求。 1.2 美团民宿挪动端现状业务的倒退和跨端复用技术的一直演变，让美团民宿客户端从业务刚起步的单端 Native App，到跨 App（民宿 App、美团 App、点评 App ）的 Native 复用和以 SSR 补救性能差距的 Hybrid 的联合计划，在这场性能和效率的博弈中，客户端最终落脚以 React Native（以下简称 RN）为外围的复用框架。在此同时，民宿小程序端也随着微信小程序的诞生、生态壮大、多平台化的趋势一直成长，逐步造成多平台复用的小程序架构。 上图是美团民宿挪动端原始架构图，左侧是客户端的技术架构，iOS 和 Android 零碎层之上是独立的 Native 基建层，再往上通过了 RN 关上双端的复用之门，接着以 RN 容器标准化屏蔽了宿主利用间差别，保障了容器化的一致性，进而实现了业务层的复用和跨 App 的复用。右侧是民宿小程序以后简化的架构图，咱们在基建层做了多端适配，通过多平台复用构建工具实现了各平台小程序的复用。以后客户端和小程端相干独立，开发保护也互相独立，团队各司其职。 只管美团民宿 App 曾经通过 RN 实现 iOS 和 Android 的跨端复用，然而因为 App 和小程序依然须要投入双倍的人力老本进行业务迭代，所以咱们思考一个问题：是否能够更进一步，应用一套代码解决多端，把 iOS App、Android App、小程序进行大一统。 ...

美团到店广告平台算法团队基于多年来在广告畛域上积攒的教训，始终在数据偏差等业界挑战性问题一直进行深刻优化与算法翻新。在之前分享的《KDD Cup 2020 Debiasing较量冠军技术计划与广告业务利用》一文[4]中，团队分享了在KDD Cup较量中获得冠军的选择性偏差以及风行度偏差的解决方案，同时也分享了在广告业务上偏差优化的技术框架。本文基于这一技术框架进行持续介绍，聚焦于地位偏差问题的最新进展，并具体地介绍团队在美团广告获得显著业务成果的地位偏差CTR模型优化计划，以该计划为根底造成的论文《Deep Position-wise Interaction Network for CTR Prediction》也被国内顶级会议SIGIR 2021录用。近些年来，因为人工智能技术的高速倒退，所带来的公平性问题也愈发受到关注。同样的，广告技术也存在着许多公平性问题，因为公平性问题造成的偏差对广告零碎的生态会产生较大的负面影响。图1所示的是广告零碎中的反馈环路[1]，广告零碎通过累积的用户交互反馈数据基于肯定的假如去训练模型，模型对广告进行预估排序展现给用户，用户基于可看到的广告进行交互进而累积到数据中。在该环路中，地位偏差、风行度偏差等各种不同类型的偏差会在各环节中一直累积，最终导致广告零碎的生态一直好转，造成“强人愈强、弱者愈弱”的马太效应。 因为偏差对广告零碎和举荐零碎的生态有着极大的影响，针对打消偏差的钻研工作也在一直减少。比方国内信息检索会议SIGIR在2018年和2020年组织了一些关注于打消偏差主题的专门会议，同时也给一些基于偏差和公平性的论文颁发了最佳论文奖（Best Paper）[2,3]。KDD Cup 2020的其中一个赛道也基于电子商务举荐中的风行度偏差进行发展[1]。 美团到店广告平台算法团队基于多年来在广告畛域上积攒的教训，始终在数据偏差等业界挑战性问题一直进行深刻优化与算法翻新。在之前分享的《KDD Cup 2020 Debiasing较量冠军技术计划与广告业务利用》一文[4]中，团队分享了在KDD Cup较量中获得冠军的选择性偏差以及风行度偏差的解决方案，同时也分享了在广告业务上偏差优化的技术框架。 本文基于这一技术框架进行持续介绍，聚焦于地位偏差问题的最新进展，并具体地介绍团队在美团广告获得显著业务成果的地位偏差CTR模型优化计划，以该计划为根底造成的论文《Deep Position-wise Interaction Network for CTR Prediction》也被国内顶级会议SIGIR 2021录用。 1. 背景美团到店广告平台算法团队基于美团和点评双侧的广告业务场景，一直进行广告前沿技术的深刻优化与算法翻新。在大多数广告业务场景下，广告零碎被分为四个模块，别离是触发策略、创意优选、品质预估以及机制设计，这些模块形成一个广告投放漏斗从海量广告中过滤以及精选出优质广告投放给指标用户。其中，触发策略从海量广告中挑选出满足用户用意的候选广告汇合，创意优选负责候选广告的图片和文本生成，品质预估联合创意优选的后果对每一个候选广告进行品质预估，包含点击率（CTR）预估、转化率（CVR）预估等，机制排序联合广告品质以及广告出价进行优化排序。在本文中，咱们也将广告称之为item。 CTR预估，作为品质预估的一个环节，是计算广告中最外围的算法之一。在每次点击付费（CPC）计费模式下，机制设计能够简略地按每千次展现支出（eCPM）来对广告进行排序以获得广告支出最大化。因为eCPM反比于CTR和广告出价（bid）的乘积。因而，CTR预估会间接影响到广告的最终支出和用户体验。为了有更高的CTR预估精度，CTR预估从晚期的LR[5]、FM[6]、FFM[7]等反对大规模稠密特色的模型，到XGBoost[8]、LightGBM[9]等树模型的联合，再到Wide&Deep[10]、Deep&Cross[11]、DeepFM[12]、xDeepFM[13]等反对高阶特色穿插的深度学习模型，进一步演变到DIN[14]、DIEN[15]、DSIN[16]等联合用户行为序列的深度学习模型，始终作为工业界以及学术界钻研的热点畛域之一，被一直摸索和不断创新。 因为CTR预估模型的训练通常采纳曝光点击数据，该数据是一种隐式反馈数据，所以会不可避免地产生各种偏差问题。其中，地位偏差因对CTR影响极大而备受关注。如图2所示，随机流量上不同地位的CTR散布反馈了用户通常偏向于点击靠前地位的广告，并且CTR会随着曝光地位的增大而迅速降落。因而，间接在曝光点击数据上进行训练，模型不可避免地会偏差于靠前地位的广告汇合，造成地位偏差问题。图2显示失常流量相比随机流量CTR散布更加集中在高地位广告上，通过反馈环路，这一问题将一直地放大，并且进一步侵害模型的性能。因而，解决好地位偏差问题不仅可能晋升广告零碎的成果，而且还能均衡广告零碎的生态，促成零碎的公平性。 广告最终的实在曝光地位信息在线上预估时是未知的，这无疑进一步增大了地位偏差问题的解决难度。现有的解决地位偏差的办法能够大抵分为以下两种： 神经网络地位特色建模：该办法将地位建模为神经网络中的特色，因为在预估过程中并不知道实在地位信息，故而有些办法[17-19]把地位信息放于网络的Wide局部，在线下训练时应用实在地位，在线上预估时应用固定地位，这种办法因为其简略性和有效性，在工业界被广泛应用。为了在线上预估时无需应用地位信息，如图3所示，PAL[20]将样本的CTR建模为ProbSeen乘以pCTR，其中ProbSeen仅应用地位特色建模，而pCTR应用其余信息建模，在线上只应用pCTR作为CTR预估值。 Inverse Propensity Weighting（IPW）：该办法被学术界宽泛钻研[21-29]，其在模型训练时给不同曝光地位的样本赋予不同的样本权重，直观地看，应该将具备较低接管反馈偏向的广告样本（曝光地位靠后的广告）调配较高的权重。因而，这种办法的难点就在于不同地位的样本权重如何确定，一个简略的办法是应用广告随机展现的流量来精确地计算地位CTR偏差，但不可避免地侵害用户体验。故而，许多办法致力于在有偏的流量上来精确地预估地位偏差。上述的办法通常基于一个较强的假如，即点击伯努利变量$C$依赖于两个潜在的伯努利变量E和$R$，如下式所示： 其中，等式右边指的是用户$u$在上下文$c$中点击第$k$个广告$i$的概率，咱们定义上下文$c$为实时的申请信息。等式左边第一项指的是地位$k$被查看的概率，其中$[s]$通常为上下文$c$的一个子集，大部分办法假如$[s]$为空集，即地位$k$被查看的概率仅与$k$无关。等式左边第二项指的是相关性概率（例如用户$u$在上下文$c$中对广告$i$的的实在趣味）。上述办法通常显式或隐式地预计查看概率，而后利用反事实推理（Counterfactual Inference）得出相关性概率，最终在线上将相关性概率作为CTR的预估值。训练和预估之间地位信息的不同解决将不可避免地导致线下线上间的不统一问题，进一步导致次优的模型性能。 此外，已有办法通常假如查看概率仅依赖于地位及局部上下文信息，其假如过于简略。不同的用户通常具备不同的浏览习惯，有些用户可能偏向于浏览更多item，而有些用户通常能疾速做出决定，并且同一个用户在不同的上下文中搜寻用意中也会有不同的地位偏好，例如商场等地点词的搜寻往往用意不明确导致高下地位的CTR差别并不大。故而，地位偏差与用户，上下文无关，甚至可能与广告自身也无关，建模它们间的关系能更好地解决地位偏差问题。 不同于上述的办法，本文提出了一个基于深度地位穿插网络（Deep Position-wise Interaction Network）（DPIN）模型的多地位预估办法去无效地间接建模$ CTR_k^j=p(C=1|u,c,i,k) $来进步模型性能，其中$ CTR_k^j $是第$j$个广告在第$k$个地位的CTR预估值。该模型无效地组合了所有候选广告和地位，以预估每个广告在每个地位的CTR，实现线下线上的一致性，并在在线服务性能限度的状况下反对地位、用户、上下文和广告之间的深度非线性穿插。广告的最终序能够通过最大化$\sum CTR_k^jbid^j $来确定，其中$bid^j$为广告的出价，本文在线上机制采纳一个地位自顶向下的贪心算法去失去广告的最终序。本文的奉献如下： 本文在DPIN中应用具备非线性穿插的浅层地位组合模块，该模块能够并行地预估候选广告和地位组合的CTR，达到线下线上的一致性，并大大改善了模型性能。不同于以往只对候选广告进行用户趣味建模，本次首次提出对候选地位也进行用户趣味建模。DPIN利用一个深度地位穿插模块无效地学习地位，用户趣味和上下文之间的深度非线性穿插示意。依据对于地位的新解决形式，本文提出了一种新的评估指标PAUC（Position-wise AUC），用于测量模型在解决地位偏差问题上的模型性能。本文在美团广告的实在数据集上进行了充沛的试验，验证了DPIN在模型性能和服务性能上都能获得很好的成果。同时本文还在线上部署了A/B Test，验证了DPIN与高度优化的已有基线相比有显著晋升。2. 深度地位穿插网络（Deep Position-wise Interaction Network本节次要介绍深度地位穿插网络（Deep Position-wise Interaction Network）（DPIN）模型。如图4所示，DPIN模型由三个模块组成，别离是解决$J$个候选广告的根底模块（Base Module），解决$K$个候选地位的深度地位穿插模块（Deep Position-wise Interaction Module）以及组合$J$个广告和$K$个地位的地位组合模块（Position-wise Combination Module），不同模块需预估的样本数量不一样，简单模块预估的样本数量少，简略模块预估的样本数量多，由此来进步模型性能和保障服务性能。通过这三个模块的组合，DPIN模型有能力在服务性能的限度下预估每个广告在每个地位上的CTR，并学习地位信息和其余信息的深度非线性穿插示意。下文将会具体地介绍这三个模块。 ...

菜品是外卖交易过程的外围因素，对菜品的了解也是实现外卖供需匹配的重点。明天咱们将一次推送三篇文章，系统地介绍了美团外卖美食常识图谱的构建和利用。《美团外卖美食常识图谱的迭代及利用》会介绍外卖常识图谱的体系全貌，包含菜品类目、规范菜品、美食根底属性和美食业务主题属性。《外卖商品的标准化建设与利用》将重点介绍外卖菜品标准化建设思路、技术计划和业务利用。因为外卖的业务特点是搭配成单，而《外卖套餐搭配的摸索和利用》一文会针对性地介绍外卖套餐搭配技术的迭代以及利用实际。心愿对从事相干工作的同学可能带来一些启发或者帮忙。本文系外卖美食常识图谱系列的第一篇文章，这篇文章系统地介绍了美团外卖美食常识图谱的标签体系结构，包含菜品类指标签、规范菜品名、美食根底属性（食材、口味、菜系等）和美食业务主题属性（商家招牌、类目经典等）。在技术层面，举例对标签体系的具体构建办法进行介绍，例如基于BERT预训练的分类模型。在利用方面，介绍了美食常识图谱在美团外卖业务的具体利用，包含撑持套餐搭配的菜品表征、晋升搜寻和商家举荐等业务的用户体验。 1. 背景常识图谱，旨在形容真实世界中存在的各种实体和实体之间的关系。在美团外卖业务中，美食商品是美团向用户提供服务的根底，美食常识图谱的建设，能够帮忙咱们向用户提供更加精确、更加丰盛、更加个性化的美食服务。另外，美团外卖业务向用户提供“到家”吃饭的服务，到店餐饮业务则向用户提供“到店”吃饭的服务，而外卖和到店的商家和菜品有相当程度的重合，菜品数据的对齐，为咱们进行线上（外卖场景）线下（到店场景）数据的比照剖析也提供了一个很好的“抓手”。 本文介绍了外卖美食常识图谱的建设，基于对外卖业务数据（外卖交易数据、商家录入的商品标签信息、业余形容PGC、用户评论UGC、商品图片等）和站外数据（百科、菜谱等）的开掘和剖析，造成了针对外卖美食的分类体系（美食类指标签）和标准化体系（规范菜品名标签），并进一步针对不同类型的美食商品，构建蕴含口味、食材等泛滥美食根底属性体系。同时，依靠美团外卖的业务个性，构建美食商品在外卖业务中波及的主题属性体系，例如商家招牌、商家主营、类目经典等。目前，外卖美食常识图谱的标签构造如下图1所示： 外卖美食常识图谱蕴含以下四种维度的标签（以“宫保鸡丁”为例，如下图2所示）： 类指标签：包含主食、小吃、菜品等类目，并在每个类目下，造成了层级化的三百多种细分类目。例如“宫保鸡丁”的类目是“菜品”。类指标签是美食商品的根底分类信息，依据类目标不同，美食商品的根底属性也不同。例如“菜品”类目存在“荤素”、“菜系”之分，而“酒水饮品”类目则没有这种属性标签。规范菜品名标签：规范菜品名标签次要为规范商品信息，例如“宫保鸡丁（招牌必点）”的规范商品是“宫保鸡丁”。因商家输出商品的多样性，规范菜标签的建设，实现了雷同美食的聚合。根底属性：依据美食商品的类目不同，构建包含美食的食材、菜系、口味、制作方法、荤素等根底属性。例如“宫保鸡丁”的菜系是“川菜”，食材有“鸡胸”和“花生”，荤素标签是“荤”。根底属性的开掘对咱们了解商品起到关键作用，在商品的筛选、展现、商品表征等业务需要方面，提供根本的数据特色。主题属性：主题属性次要体现美食的业务主题，包含美食在外卖的交易行为、美食在商家的定位、美食在用户反馈中的好评度等。例如某商家的“宫保鸡丁（招牌必点）”是该商家的“招牌菜”。 菜品对齐，波及到菜品数据，来自外卖在线菜品、点评举荐菜品、美团商家套餐等。 2. 需要及挑战目前，外卖美食常识图谱曾经利用于美团外卖的多个场景，例如举荐、搜寻、套餐搭配、经营剖析等。业务的深刻倒退，对美食常识图谱的建设和迭代也提出了更加简单的要求，例如： 美食商品越来越多样，相应的美食常识图谱则须要越来越精密和精确。例如美食常识图谱的类指标签从零开始，建设了蕴含一百多品种目标类指标签体系。但随着业务倒退，局部类目存在显著的可细化空间。图谱标签的开掘，偏差于动态标签的开掘，对于雷同图谱标签下的美食，短少业务相干的主题属性形容。例如同样蕴含“花生”的“酒鬼花生”，相比“宫保鸡丁”，更能代表“花生”相干的美食。外卖美食常识图谱次要形容外卖美食商品，而同一商家的美食商品，也可能会呈现在该店的线下收银等业务中。通过对齐不同业务的美食商品，能够在美食实体层面，欠缺美食常识图谱对商家美食的形容，从而领导商品和商家经营。为满足业务需要，咱们对类指标签和根底属性进行了迭代和优化；同时，构建了业务相干的主题属性。另外，咱们将外卖菜品和到餐菜品进行了实体对齐。其中，开掘主题属性，即开掘业务相干的图谱常识，是一个须要综合思考外卖业务和商品自身属性的简单过程。外卖菜品和到餐菜品的对齐，则须要综合思考菜品多样性表述和菜品主体归一。 外卖美食常识图谱的迭代难点次要体现在以下几点： 业务相干的主题属性开掘，并没有现成的体系能够参考，在构建过程中，波及大量的剖析和体系设计工作。主题属性的开掘，最重要的是须要从用户的需要登程，剖析用户对商品的需要点，并将其反映在商品的图谱层面，造成相应的主题属性标签。同时，商家的商品信息是一个动态变化的过程，例如销量、供应、商品标签等，前后两天的信息可能就会齐全不同。因而业务性主题属性的开掘，一方面须要建设绝对欠缺的体系，另一方面也须要适配业务数据的动态变化过程，也就在图谱开掘和需要匹配上带来了极大的挑战。商家录入菜品时，对菜品存在多样性表述，例如同一道菜在重量、口味、食材等方面存在的差别。菜品对齐时，则须要对这些多样性表述进行均衡，例如是否疏忽重量因素等。但目前并没有现成的对齐规范能够参考。3. 外卖美食常识图谱的迭代因篇幅受限，本文次要对其中菜品类目，不同类目、口味、食材、荤素、做法下的经典美食，衰弱餐等图谱标签的开掘进行介绍。其中，在图谱标签开掘中波及到的数据起源和采纳的技术，大抵如下表所示： 标签技术菜品类目BERT分类模型不同类目、口味、食材、荤素、做法下的经典美食数据统计、实体辨认、关系辨认、产品定义（综合思考销量和供给量）衰弱餐分类模型+产品定义（合乎肯定食材、做法、效用的商品）3.1 菜品类目菜品类指标签的开掘，次要解决美食菜品是什么类别的问题。实现这一指标的挑战有两方面：首先是类目体系如何建设，其次是如何将商品链接到相应的类目节点。在最开始的体系构建时，咱们从美食商品的特点以及业务的具体需要登程，从零开始建设起蕴含一百多品种别的层次化类别体系，局部实例如图3（左）所示。同时，构建基于CNN+CRF的分类模型，对美食商品进行类目分类，如图4（左）所示。 然而，随着业务的倒退，已有分类目曾经无奈反对现有业务的需要。例如：原先的类目体系，对热菜形容不够具体，譬如没有辨别热菜的做法等。为此，咱们与外卖的供应布局部单干，将类目体系裁减到细分的三百多品种指标签，划分更加具体，笼罩也更加全面，局部实例如图3（右）所示。 类目标细分，要求模型更加准确。在进行类目辨认时，可用的数据包含菜品名、商家店内侧边栏分类名称、商家名等。思考到可应用的信息大多为文本信息，并且，商家录入的文本并没有肯定的标准，菜品名也多种多样，为进步模型精度，咱们将原先的CNN+CRF的分类模型进行了降级，采纳模型容量更大的BERT预训练+Fine-Tuning的模型。模型构造如下图4（右）所示。 3.2 不同类目、口味、食材、荤素、做法下的经典美食标签咱们在建设主题属性时，首先在根底属性标签维度，综合思考商品的销量和供应状况，对菜品进行选优。例如类目下的经典美食等。但在建设过程中，咱们发现菜系的经典美食辨认，如果根据销量和供应进行辨认，则辨认后果偏向于菜系下的“家常菜”，因而将经典菜系美食进行独自辨认。 类目经典美食等指的是销量较高、供给量丰盛的类目美食商品，例如主食经典美食、小吃经典美食。口味、食材、做法经典美食标签等也是类似的定义。 在建设过程中，咱们发现，如果间接在商品维度进行辨认，因为商品的更新频率绝对较高，对新录入的临时没有销量或者临时销量低的美食商品不敌对，销量程度须要思考在线工夫的影响。因而咱们应用规范菜品进行类目、口味经典等的辨认，并通过规范菜品，泛化到具体的美食商品上。 其中，“规范菜品”借用其它类电商业务中的“标品”概念，尽管绝大部分菜品的生产都不是标准化的过程，然而这里咱们只关注次要的共性局部，疏忽主要的差别局部。例如“西红柿鸡蛋”、“番茄炒蛋”都是同一类菜品。从后果上看，目前咱们聚合进去的“规范菜品”达到几十万的量级，并且可能笼罩大部分美食商品。 借助规范菜品，咱们将类目、口味、食材、荤素、做法等标签聚合到规范菜品维度，并将销量、供给量进行规范菜品维度计算，这样就解决了商品在线工夫长短的问题。在具体打标过程中，例如类目经典，咱们基于销量和供应，在类目维度对规范菜进行排序，并抉择Top n%规范菜进行打标，作为类目经典下的商品。例如在“面食”类目下，“西红柿鸡蛋面”的销量和供给量均在Top n%的程度，因而就认为“西红柿鸡蛋面”是一个面食类经典美食。 3.3 衰弱餐这里的衰弱餐次要指低脂低卡餐，即低卡路里、低脂肪、高纤维、制作简略、原汁原味、衰弱养分的食物，个别为蔬菜水果（如罗勒、甘蓝、秋葵、牛油果等），富含优质蛋白的肉类（如三文鱼、虾、贝类、鸡胸等），谷物（次要以细粮为主，如燕麦、高粱、藜麦等）。烹饪办法也保持“少油，少盐，少糖”的准则，次要做法为蒸、煮、少煎、凉拌等。 衰弱餐的辨认，次要挑战在于自身的样本较少，然而因为衰弱餐的特殊性，商家在进行商品录入时，个别会对其进行形容，例如指出这个美食商品是“衰弱”的、“低卡”的、“健身”类型的，因而咱们构建了一个分类模型，对衰弱餐进行辨认。可应用的数据，包含商品名、商家导航栏、商家名称、商家对商品的形容等。而商家类目与商品的类目处于迭代状态，因而并没有对这部分信息进行应用。 辨认过程如下： 训练数据构建：因衰弱餐自身的占比绝对较少，因而首先总结和衰弱餐相干的关键词，应用关键词进行文本匹配，采样概率绝对较高的衰弱餐数据，进行外包数据标注。此处，咱们总结出“沙拉、谷物饭、谷物碗、低油、低卡、无糖、减脂、减肥、轻食、轻卡”等关键词。模型构建：同一个商品因其中应用的配料不同，在衰弱餐辨认方面也会不同，例如菜名为“招牌沙拉”的商品，如果沙拉中增加了芝士，则有可能商品就不会被辨认成衰弱餐。为了综合思考商家录入的商品信息，应用商品名、商家名、导航栏名称、商家录入的商品形容等。这四种数据为不同尺度的数据源，商品名等为绝对较短的文本，因而在模型构建时，思考应用相似Text-CNN[1]的构造进行字级别的特征提取；商品形容则是绝对较长的文本，因而在构建时，思考应用相似Transformer[2]的构造进行特征提取，应用Multi-head Attention的机制，提取长文本中，“字”层面的特色。具体构造如下： 采纳了两种构造：Multihead-attention（Transformer）和Text-CNN。试验发现，采纳两种构造联结的形式，比采纳繁多构造准确率高。在建模时，均应用字级别特色解决，防止因为分词造成的误差，同时也防止未登录词的影响。数据迭代加强：因为应用关键词进行样本构建，在模型训练时，模型会朝着蕴含这些关键词的方向学习，因而存在漏召回的状况。在这里，咱们进行了肯定的训练数据加强，例如在评估时，选取可辨认出衰弱餐的商家，对该商家中漏召回的数据进行训练数据补充；同时，对局部特色显著的关键词，进行补充并裁减正例。通过对训练样本的屡次裁减，最终实现衰弱餐的高准确率辨认。 3.4 菜品实体对齐思考到同一商家菜品在不同业务线的菜品名可能略有差别，咱们设计了一套菜品名匹配的算法，通过拆解菜品名称的量词、拼音、前后缀、子字符串、程序等特色，利用美食类目辨认、规范菜品名抽取、同义关系匹配等进行菜品实体对齐。例如：碳烧鸽=炭烧鸽、重庆辣子鸡=重庆歌乐山辣子鸡、茄子肉泥盖饭=茄子肉泥盖浇饭、番茄炒蛋=西红柿炒蛋等。目前，造成如下图的菜品归一体系： 4. 利用这里对外卖美食常识图谱的利用，进行举例说明。次要波及套餐搭配、美食商品展现等。 4.1 套餐搭配-表征菜品为满足用户的搭配成单需要，进行套餐搭配技术的摸索。套餐搭配技术的关键在于，对美食商品的认知，而外卖美食常识图谱，则提供了最全面的数据根底。咱们基于同商家内的商品信息和历史成单信息，对商品的搭配关系进行拟合，参考指针网络[2]等构造，构建了基于Multi-Head Attention[3]的Enc-Dec模型，具体的模型构造如下： Encoder：对商家菜单进行建模，因菜单为无序数据，因而采纳Attention的形式进行建模。商品的信息次要包含商品名、商品图谱标签、交易统计数据等三局部。 对菜名、商品标签别离进行Self-Attention计算，失去菜名和商品标签对应的向量信息，而后与交易统计数据进行Concat，作为商品的初步示意。对商品的初步示意进行Self-Attention计算，以对同商家的商品有所感知。Deocoder：对搭配关系进行学习，基于以后已抉择的商品，对下一个可能的搭配进行预估。 在搭配输入时，应用Beam-Search进行多种搭配后果的输入。为了保障输入搭配中的商品的多样性，增加Coverage机制[2]。训练之后，将Encoder局部拆散，进行离线调度，可实现每天的向量产出。具体的模型构造如下图所示： 基于外卖美食常识图谱构建的套餐搭配模型，在多个入口（“满减神器”、“对话点餐”、“菜品详情页”等）获得转化的晋升。 4.2 交互式举荐通过剖析外卖用户的需要，发现用户存在跨店类似商品比照的需要，为突破商家界线的选购流程特点，提供便捷的跨店比照决策形式。交互式举荐，通过新的交互模式，打造举荐产品的突破点。在用户的交互过程中，依据用户的历史偏好、实时的点击行为，向用户举荐可能喜爱的美食商品。如下图8（左）所示，在向用户进行同类美食的举荐时，美食常识图谱中的规范菜品标签提供了次要的数据撑持。 4.3 搜寻搜寻作为外卖外围流量入口，承载了用户明确的外卖需要。用户通过输出关键词，进行菜品检索。在理论应用中，从搜寻的关键词类型看，可能是某个具体的菜品，也可能是某种食材、某种菜系。在美食常识图谱中，图谱标签的高准确率和高笼罩，有助于晋升搜寻入口的用户体验，最新的试验也表明了这一点（新增局部食材、菜系、效用等标签，在搜寻的线上试验成果正向）。 5. 将来布局5.1 场景化标签的开掘美食与咱们的生存非亲非故，美团外卖每天为千万用户提供美食方面的服务。然而，用户的需要是多种多样的，在不同的环境、不同的场景下，对美食的需要也不尽相同。目前美食常识图谱开掘，在场景相干的标签较为缺失，例如某些节气、节日等图谱常识；特定天气情况下的图谱常识；特定人群（增肌人群、减肥人群）等的图谱常识。接下来咱们会在场景化标签的开掘方面进行摸索。 在开掘办法方面，目前的开掘数据次要为文本信息。在商品图片、形容、结构化标签等信息的交融方面，开掘不够深刻，模型的成果也有待晋升。因而在多模态辨认模型方面，咱们也会进行相应的摸索。 5.2 基于图谱的举荐技术钻研美团外卖在了解美食的根底上，向用户进行美食举荐，以更好地满足用户对美食的需要。外卖美食常识图谱和外卖业务数据，作为实现这一点的数据根底，蕴含上亿的节点信息和十几亿的关系数据。通过对用户的商品搜寻、点击、购买等行为进行建模剖析，能够更加贴合用户的需要，向用户进行商品举荐，例如，将美食常识图谱和外卖行为数据交融，以用户为终点，进行随机游走，向用户举荐相干的美食。在接下来的图谱利用方面的摸索中，咱们也会更加深刻的摸索基于美食常识图谱和用户行为的举荐技术。 6. 参考文献[1] Kim Y. Convolutional neural networks for sentence classification[J]. arXiv preprint arXiv:1408.5882, 2014.[2] See A, Liu P J, Manning C D. Get to the point: Summarization with pointer-generator networks[J]. arXiv preprint arXiv:1704.04368, 2017.[3] Vaswani A, Shazeer N, Parmar N, et al. Attention is all you need[C]//Advances in neural information processing systems. 2017: 5998-6008.[4] Hamilton W, Ying Z, Leskovec J. Inductive representation learning on large graphs[C]//Advances in Neural Information Processing Systems. 2017: 1024-1034.7. 作者简介杨林、郭同、海超、懋地等，均来自美团外卖技术团队。 ...

外卖菜品命名个性化水平高，为经营剖析、召回排序、后盾治理等业务带来肯定的艰难。本文系外卖美食常识图谱系列的第二篇文章，介绍了外卖从零到一建设菜品标准化体系的过程及计划，波及的次要技术包含NLP畛域的实体抽取、文本匹配、关系分类，以及CV畛域的图像匹配等。最初，通过规范名在外卖业务中的利用实际，验证了规范名体系建设的价值和意义。1. 背景及指标商品作为外卖交易过程中的外围因素，决定了供需匹配的精准度，间接影响交易行为是否能够达成。外卖平台美食、甜点、饮品类在线商品有亿级之多，其中很多是属性信息统一的雷同商品。建设对商品的标准化形容、聚合雷同商品，是很多业务场景的诉求。 供销剖析场景：想剖析一下望京的商家都售卖哪些菜品，有多少商家卖“西红柿炒鸡蛋”？ 遇到的问题：因为菜品是非标品，并且商家对菜品命名的个性化水平也较高，因而在外卖平台，同一个菜品名呈现不同的命名形式；例如“西红柿炒鸡蛋”有西红柿炒蛋、小番茄炒蛋、西红柿鸡蛋、京城三绝~番茄炒蛋【正价小份菜】等，没有方法简略通过关键字进行聚合。 主题举荐场景：想出一个菜品粒度的主题，疾速筛选“小龙虾”、“烤鱼”、“鸡公煲”、“黄焖鸡”等热门菜品？ 遇到的问题：商品分类的颗粒度不够精密，无奈疾速找到适宜颗粒度的菜品。 商家上单场景：像“鱼香肉丝”这样广泛的菜品，每个商家上单都须要录入食材、口味、做法、菜系、荤素等标签，录入老本较高，能不能像淘宝一样，抉择“iPhone 12”，它的属性就可能主动关联。 遇到的问题：没有将菜品的属性标准化，菜品和属性之间没有关联关系。 基于上述业务利用的痛点，启动外卖商品的标准化建设。指标是建设商品的标准化名称，实现对雷同商品的聚合，从而为业务提供正当粒度的概念划分，赋能经营端供销剖析、用户端个性化召回排序、商家端标签生产。 2. 业界调研对于业界的参考，次要参考淘宝标准化SPU建设。SPU在淘宝体系中决定了商品是什么，是商品信息聚合的最小单位，由要害属性+绑定属性来形成。 要害属性：用来束缚和定义一个商品的，比方iPhone X，决定他的就是“苹果”这个品牌和“X”这个系列。绑定属性：是要害属性的补充和细化，比方当iPhone X曾经明确了这个产品后，其余的属性也确定，比方网络模型，屏幕尺寸等，进一步补充这些属性内容，逐渐明确了一个产品。可见淘宝对于SPU的建设，实际上是对属性的建设，例如格力空调S1240，通过“格力”品牌、“空调”类目、“S1240”型号来标准化、惟一化。 但对于餐饮行业，对于外围属性食材“牛肉”、做法“炒”、口味“辣”，都无奈确定是什么菜，更谈不上惟一化；但如果通过“小炒黄牛肉”来标准化，行业/用户对其有广泛的认知，较固定的食材口味做法，适宜用来进行标准化。因而淘宝是标准化属性，而餐饮是标准化菜品名称，所以咱们称之为规范菜品名。 3. 问题剖析及挑战淘宝的标准化次要针对标品，而餐饮标准化都是针对非标品，难度较大，面临着个性化问题、录入不标准、粒度无行业标准、认知局限性等挑战。 3.1 个性化问题餐饮商家能够较低成本的自定义生产，个性化程度较高，同一个菜品在不同商家的命名可能不同，须要大量的同义词聚合，而同义词的召回是最大的难点（如何将潜在的同义词开掘进去进行标注）。例如，京城三绝-番茄炒蛋【正价小份菜】、西红柿炒蛋（小份）、小番茄炒蛋、西红柿炒土鸡蛋（小份），都示意“西红柿炒蛋”这个商品。 3.2 录入不标准商家在录入商品名称时，存在缺失要害信息的问题，例如“缤纷水果”是水果拼盘、饮品还是披萨，“韭菜鸡蛋”是包子还是饺子。除商品名称外，须要借助商家分类，商品左侧栏tag等相干信息，对名称进行推理和补全。 3.3 粒度无行业标准在进行标准化解决时，没有对立的规范，粒度难以把控：过粗容易产生非菜品谬误（例如：“香辣鸡腿”->“鸡腿”），过细则规范名内聚性偏弱（例如：“传统黄焖鸡【大碗】”自身粒度过细，须要提炼到“黄焖鸡”）。 3.4 认知局限性中华美食文化博大精深，对于一些不为公众所熟知的小众或者中央特色菜品，须要具备肯定的业余背景常识，例如“炒鸡”也是一个规范的名称，还并非商家没有填写残缺。 4. 计划商品标准化的整体计划如图所示：首先，基于美食、甜点饮品类商家全量在线的亿级商品，通过名称荡涤、置信度判断、人工测验，取得近菜名骨干；通过同义词开掘，对骨干名进一步聚合压缩，映射到规范名主词上；对于单个商品，进行名称纠错、荡涤，通过模型匹配，建设商品-规范名的映射；为了满足不同业务场景的聚合粒度要求，通过上下级关系开掘、深度遍历，进一步构建规范名层级树。别离对名称聚合、匹配映射、层级构建三个模块，波及的算法模型进行介绍。 4.1 名称聚合荡涤后的骨干名依然存在很多同义说法，比方土豆烧牛肉、牛肉烧土豆、洋芋烧牛肉、小土豆烧牛肉，示意雷同的商品。指标通过开掘这种潜在的同义关系，进一步晋升名称的内聚性。在迭代过程中，先后采纳了规定匹配和语义匹配的办法，开掘潜在同义词；聚合后，依据风行度判断其中的主词，并将原始骨干词映射至规范名主词上。别离对两种同义词开掘办法介绍如下。 4.1.1 规定匹配一期首先采纳了规定匹配的办法，利用NER模型对骨干名进行成份辨认，联合常识图谱构建的属性同义词表，判断两个骨干名是否是同义关系。 如图所示，其中“牛肉烧土豆”通过名称解析失去牛肉-食材，烧-做法，土豆-食材；“洋芋烧牛肉”通过名称解析失去洋芋-食材，烧-做法，牛肉-食材。比照两个骨干名的成份词，其中土豆和洋芋是一对同义词，其余成份雷同，进而取得二者之间是同义关系。 通过这种形式，开掘了十万级同义词。依据规范名笼罩的商品供应数计算风行度值，将更风行度高的作为主词；人工校验后补充到规范名体系，晋升了名称的聚合度。 4.1.2 语意匹配因为规定匹配开掘到的同义词无限，比方“担担面”和“担担汤面”，依据NER模型，担担面和汤面都会被辨认成类目。如此，两个骨干名是无奈建设同义关系的。 咱们二期调研了一些匹配模型，借鉴搜索算法组的教训，采纳BERT+DSSM的语义匹配模型进行同义关系的扩笼罩。如图所示，首先基于一期积攒的同义词，通过组内生成正例、跨组穿插生成负例的形式，结构百万级样本，训练了一版根底模型；为了进一步优化模型性能，通过被动学习和数据加强两种形式，对样本数据进行了迭代。 被动学习的形式是先利用根底模型，圈定一批待标注的类似样本，交与外包标注，将标注正确的样本补充至已有同义词中，标注谬误的样本作为负例退出训练集，用于模型的优化迭代。通过被动学习的形式，补充了万级样本，模型准确率获得了显著晋升。 进一步剖析后果，咱们发现了一批很有特点的Bad Case，比方红烧狮子头和红烧狮子头盖饭、香椿拌豆腐和拌豆腐等，它们都属于字面类似度很高，但外围成份不同的匹配谬误。基于这个特点，先依据字面间隔圈定了一批字面类似度高的样本，再利用名称解析模型对它们进行成份辨认，找出其中的负例。通过这种形式，在不减少标注老本的状况下，主动补充了十万级样本，进一步晋升了模型准确率。 利用语义匹配模型，新增了十万级同义词，进一步晋升了规范名的内聚性。 4.2 匹配映射在开掘到的规范名词表和同义词根底上，为亿级在线商品建设“商品-规范名”映射（如“招牌蛋炒小番茄（大份）”映射到“西红柿炒鸡蛋”），以实现对雷同商品的标准化形容与聚合。采纳“文本+图像”相结合的匹配模型，笼罩了绝大部分的美食、甜点饮品类商家的在线商品。 4.2.1 文本匹配文本匹配流程如图4所示，整体上包含召回、排序两个阶段。首先，对商品名称中的规格、重量等形容信息进行荡涤，将荡涤后的商品名和规范名进行2-Gram切片，通过关联雷同切片的形式召回待匹配的规范名；基于召回的规范名，通过计算Jaccard间隔，保留其中Top 20的规范名；在此基础上，利用BERT向量化模型，生成商品名和规范名的向量示意，通过计算Jaccard字面间隔以及Cosine向量类似度，获取其中综合得分最高的规范名。 其中，BERT向量化模型是基于上文提到的同义语义匹配模型，通过级联一维类型编码的形式，对规范名和商品名加以辨别，革新成非对称的规范名匹配模型。之所以进行这一革新，是因为与同义匹配不同，规范名匹配是非对称的，如应该将“香锅盔”匹配上绝对形象的规范名“锅盔”，而不是匹配上一个更加具体的规范名“五香锅盔”。革新后，匹配准确率晋升显著。 4.2.2 图像匹配因为菜品名称长度无限及商家命名不标准，会导致仅从菜品名称中获取的信息无限，而无奈建设到规范名的匹配。通过引入商品图片信息，晋升对文本信息不全商品的匹配精确和笼罩。 图像匹配采纳的是多分类模型，依据规范名层级聚合（详见3层级构建）后的顶级、二级，抉择待匹配的规范名标签，并依据文本匹配后果结构样本集。因为采纳大规模非人工标注样本，不可避免地要解决样本噪声问题。在本场景下，噪声次要有两个次要起源：一是文本信息不全，导致样本标签谬误；二是因为顶级、二级聚合水平高，导致分类粒度过粗，须要细分多个标签。针对这些问题，采纳样本和模型迭代优化的形式，依据根底样本集训练初版模型，利用模型开掘噪声数据，人工校验后进行模型微调。如此迭代，实现低标注老本的模型优化。 图像分类模型选取了对MBConv模块的参数进行精细化调整的Basebone网络Efficientnet，通过调整网络的分辨率、深度、宽度，确定最优组合。噪声开掘办法首先通过Metric-Learn的办法，学习取得每个类别的聚类核心，及类内样本与聚类核心间隔的均值、方差、中位数，对其进行排序挖掘出类内离散度较大的类别；再借助分类模型在验证集上的预测、O2U-Net和Forgetting Event 开掘样本噪声。通过上述办法优化模型，晋升对噪声样本的鲁棒性。 4.3 层级构建举荐场景下，为了保障用户的个性化和多样性体验，须要对商品进行正当粒度的聚合。对于商品列表排序场景，现有的类目过粗会导致多样性有余，规范名过细又会导致后果反复。指标是建设一个层级化商品体系，为业务提供正当的聚合粒度。通过关系开掘、层级遍历，结构万级顶点的层级树，反对了商品列表、美食排行榜、交互式举荐等业务的上线和优化。构建办法包含规定匹配和模型判断，别离对这两类办法进行介绍。 4.3.1 规定匹配规定匹配办法是基于已有的NER模型和属性词表，通过结构化匹配的办法，开掘到十万级上下级关系，进一步遍历生成万级顶点的规范名层级树。这种办法比较简单且基于已有工作，开发周期短，在我的项目初期疾速反对上线，并获得了显著的业务收益。 4.3.2 模型判断规定匹配办法因为NER模型谬误和属性词关系短少，导致开掘到的关系无限，须要通过判断模型进一步晋升泛化性。基于BERT的关系分类模型如图8所示，看待分类一对规范名用[SEP]进行拼接，并在结尾减少[CLS]标识符；将拼接后果编码后，传入BERT模型，取出[CLS]位的Embedding；再接一个全联接层和Softmax层，输入关系分类后果。规范名关系包含：同义、下级、上级、无关系，一共四个类别。 样本数据包含简略例和难例两局部，其中：简略例基于已有同义词、上下级，以及同义词组间穿插生成无关系，一共结构百万级样本；在此基础上，进一步利用已有的向量化模型，召回类似度较高的规范名对，交与外包标注其类别。第二类样本更加贴近理论分类场景，且属于混同度较高的分类难例。 利用第一类样本预训练初版模型，并在此基础上，利用第二类样本对模型进行微调，进一步晋升了分类模型准确率。经人工校验，进一步补充了万级词关系。 ...

本文系外卖美食常识图谱系列的第三篇文章，从技术层面咱们会介绍外卖套餐搭配的技术计划，包含离线、实时的套餐搭配的迭代，套餐品质评估计划，同时会介绍套餐搭配的业务利用。1. 背景让用户更方便快捷地选购到称心的外卖商品，是美团外卖始终在致力的方向。本文次要介绍了针对美食类商家的套餐搭配技术以及利用实际。在外卖点餐的抉择过程中，用户个别会思考单品偏好、组合搭配等因素，筛选商家和商品的过程耗时较长。咱们通过套餐搭配技术，基于商家的候选商品，主动搭配优质套餐，轻松解决用户“抉择艰难症”，可能晋升用户的决策效率。 2. 业务指标和挑战2.1 业务指标目前，美团外卖App的套餐搭配利用有很多，有“今日套餐举荐”、“满减神器”、“套餐搭配举荐”等。因为目前外卖商家自行搭配套餐的能力较弱而且志愿不强，导致外卖套餐底层供应对业务场景和商家的覆盖率偏低，不能满足套餐相干举荐排序利用的需要。因而，外卖套餐搭配的业务指标是对于美食类商家搭配出候选的套餐组合，给套餐相干利用方提供更丰盛的套餐供应。 对于套餐相干利用方，咱们进行了业务剖析：“今日举荐”、“满减神器”等业务的搭配条件绝对较弱且能够离线获取搭配条件，归类为举荐型相干业务，此类业务须要保障商家的套餐覆盖率晋升，从而保障商家的举荐露出。详情页、满减加购等业务的搭配条件较强，而且偏实时。例如，详情页是用户指定一个菜品后进行搭配，满减加购场景是用户抉择一个菜品和特定的价格区间作为条件。这些属于搭配型业务，此类业务须要保障套餐对实时场景的笼罩，从而保障套餐搭配Tab的露出。套餐搭配算法的指标有：①晋升套餐组合的覆盖度，从而给上游的套餐相干利用提供场景覆盖率高、多样性短缺的套餐组合。②保障搭配套餐的品质。 2.2 业务挑战商品搭配在电商场景下也存在较多的利用，例如淘宝的购物车搭配、服装搭配，化妆品搭配。购物车搭配是基于用户购物车、已购买商品的打包举荐，例如，用户在加购牙刷后，能够给出牙膏的举荐。这类办法次要基于商品的购买行为进行相关性的举荐，指标不是造成一个实现的搭配组合。然而，外卖美食商品搭配则须要思考整个组合的合理性，而不单纯基于商品是否相干。比方：大量订单中有“小炒肉+番茄鸡蛋汤+米饭”、“鱼香肉丝+番茄鸡蛋汤+米饭”等组合形式，然而“番茄鸡蛋汤+米饭”并不形成一个好的套餐搭配。 服装搭配和化妆品搭配为面向组合的搭配举荐，对此类搭配问题的解决方案大体分成两类，一类是：搭配模式用于模型筛选商品过程的剪枝，搭配模式能够是人工或者模型的形式先验给出，参考文献中的论文4、5采纳此思路，该办法的特点是搭配成果靠剪枝策略+品质评估模型独特保障。另一类是通过端到端的网络参数学习搭配模式思路，论文6和咱们的离线套餐搭配采纳此思路，该计划的特点是搭配成果更依赖于端到端模型保障，但同时搭配模型更简单。 相比电商场景的商品搭配，美食搭配面临独特的业务挑战： 套餐搭配的业务场景和搭配条件比拟多样，因而套餐搭配计划须要满足各类业务、各种搭配条件下的需要。美食商品属于非标品，且不同商家销售的商品各不相同，导致套餐搭配模式因商家而异。例如，不同商家销售的宫保鸡丁，在份量、口味、食材、价格上都不雷同，因而对于宫保鸡丁这道菜也会有不同的套餐搭配形式。算法搭配不可避免会产生低质量的搭配后果，而商品的非标品属性，导致咱们更难掂量美食搭配的品质。低质量的搭配可能包含：a.蕴含不合适独自销售、非美食品类的搭配，例如蕴含赠品、锅具、餐具的搭配。b.搭配后果不合乎惯例搭配模式，例如两份饮料，饮料+馒头等。为此，咱们的解决方案是： 为了解决业务场景和搭配条件多样的问题，咱们造成了离线、实时联合的算法搭配框架。对于举荐型相干业务，咱们采纳离线搭配办法事后搭配出套餐候选，再在业务场景中做个性化排序。离线搭配本着规定到模型的迭代思路，规定搭配依赖常识图谱的商品示意，通过高频聚合+规定搭配泛化，产出绝对高质量套餐以确保头部商家笼罩。模型搭配能够在保障搭配品质的同时，通过模型泛化进步套餐的场景覆盖率。对于实时搭配型的业务，算法会根据业务的搭配条件实时搭配套餐，进一步晋升各个实时场景下的套餐的覆盖率。为了解决美食商品非标品的问题，咱们引入外卖美食图谱对菜品进行了多方位的刻画。咱们基于外卖常识图谱提取了菜品丰盛的信息表征，例如菜品的规范菜品、菜品品类、口味、食材、做法等，削弱非标品带来的影响。为了保障搭配套餐的品质，咱们开发了套餐品质评估的模型。总体，咱们在非标品的商品示意、商家示意、套餐搭配模型、套餐搭配品质评估上都进行了相干的摸索和迭代，造成了如下图2所示的套餐搭配框架。 3. 套餐搭配模型3.1 基于图谱标签演绎的套餐搭配模型咱们面临的一个问题是外卖商品为非标品，菜品数据品质较差、属性缺失。为此，咱们基于商家菜单、菜谱、商品形容等多种信息源，通过信息抽取、关系辨认、常识交融等多种办法，构建了以美食为外围的常识图谱，对菜品建设了品类、口味、做法、效用等多个维度的示意。 商家的历史高销量套餐个别可认为是优质的套餐，然而，中低销量商家的高销量套餐数量较少，难以反对套餐的个性化举荐等利用。依赖美食图谱对菜品的语义表白，咱们首先尝试了基于常识图谱的间接演绎演绎进行套餐搭配的计划。例如，通过高频订单能够演绎得出，{热菜}+{米饭}+{汤}是一个常见的套餐搭配形式，进而对于商家演绎出“番茄炒鸡蛋+番茄鸡蛋汤+米饭”的套餐搭配。 图谱演绎演绎的过程是高频聚合和基于搭配模板的泛化过程，咱们通过订单聚合、同品牌、同标签、同菜品模板泛化，来产生高质量的套餐搭配，同时套餐的商家覆盖率有了显著的晋升。然而搭配模板的问题在于较难对搭配品质和泛化水平获得折中。约束性较强的搭配模板能够确保搭配品质，但泛化能力有余，套餐覆盖度较低。如果用繁多或大量标签形容搭配项，会导致模式适度泛化，准确率不能保障。为此，咱们引入了基于模型的套餐搭配办法。 3.2 基于Encoder-Decoder的套餐搭配模型用户搭配套餐也是一个信息编码到信息输入的过程：用户浏览商家菜单即是编码过程，失去该商家和商品信息的一个整体详情，再基于这个详情去进行套餐的搭配。贴合该过程的一个思路是采纳Encoder-Decoder框架进行套餐搭配模型的建设，Encoder类比用户浏览菜单的过程，学习菜单的语义信息，Decoder负责搭配出套餐。Encoder-Decoder是一种深度学习网络框架，曾经被广泛应用于文本摘要、机器翻译、对话生成等利用中，其建模的形式是通过编码（特征提取）和解码（指标拟合），学习从Encoder输出数据到Decoder输入数据的映射。常见的编码方式有CNN、RNN、Transformer等构造，解码形式也相似。 3.2.1 基于LSTM的套餐搭配模型套餐生成问题是要从一个商家的所有候选商品汇合中提取出多个商品子集，造成不便用户筛选、可间接下单的套餐。套餐生成的数据源次要是该商家的候选商品信息（如商品的名称、标签、价格、销量等），再联合用餐价格区间、用餐人数等约束条件，以及用户偏好等信息。最后咱们采纳了LSTM作为Encoder和Decoder的神经网络进行套餐搭配。咱们基于图谱语义抽取商品语义示意，并输出Encoder的RNN模型。Encoder编码过程相似于用户翻阅商家候选商品的过程，Encoder端输出菜品名称、菜品标签、菜品的业务属性（价格、销量等），通过LSTM对非标品菜品进行特色抽取。如下图4所示，每个商品的名称通过Embedding层、CNN+Pooling层提取特色，并同菜品标签、类别的Embedding以及价格和销量等间断特色进行拼接，最终作为Encoder RNN中每步的输出。 Decoder在解码过程中个别依赖一个固定的字典或词典作为候选集，每一步输入候选集中的字、词被选中的概率分布。对于套餐搭配网络来说，Decoder解码的候选集来源于Encoder输出端商家内的商品列表，而非固定维度的内部菜品词表，Pointer Network是建模这一问题的无效架构。Pointer Network是基于Seq2seq的扩大，次要解决的是候选集不固定的问题，这一模型架构已被胜利利用于抽取式文本摘要，以及旅行商问题、凸包问题等组合优化问题的解决方案中。 套餐搭配解码的具体过程为，Decoder每一步预估指标菜品来自菜品列表的概率分布。在第n（n>=1）步时，这个概率分布向量表白了在曾经抉择了n-1个商品的状况下，某个商品或者终止位被选中的概率。若终止位对应的概率较大，则模型偏向以前n-1个已选商品造成一个残缺的套餐搭配。解码过程中，咱们联合BeamSearch算法产生TopN个后果，保障搭配的多样性。 3.2.2 套餐搭配模型的优化套餐搭配模型的学习指标 为了解决菜品搭配模式因商家而异的问题，模型通过拟合该商家的历史订单来学习商家的搭配个性。一种较为支流的训练模式是基于商家实在订单，采纳Teacher Forcing的模式进行训练，使得模型预测的菜品逐位匹配上实在订单内的菜品。Teacher Forcing式的训练方法使得预测菜品的概率偏向于0-1散布，然而事实的菜品搭配通常是个性化、多样性的，例如在Decoder曾经输入“宫保鸡丁”菜品的根底上，下一步抉择的主食为“米饭”或者“炒饭”皆可。 为此，咱们对商家历史成单的套餐搭配模式进行统计，计算出商品抉择的概率分布，Decoder以此商品抉择的概率分布作为训练指标，同预估的散布计算MSE Loss，并最小化该值领导模型的训练。Teacher Forcing的另一个问题是较难引入搭配品质、套餐的点击购买行为等内部常识来领导模型训练，为此咱们尝试了采纳强化学习的思路进行改良。在解码过程的时刻T，咱们通过蒙特卡洛算法采样（Monte Carlo Sampling）出残缺的套餐候选，并计算套餐候选的搭配品质分作为Reward，联合MSE Loss和搭配品质分进行模型训练。 套餐搭配的束缚 套餐搭配过程会面临多种业务束缚，例如，对于“满减神器”来说，搭配的套餐须要满足给定的满减价格档位。“智能助手”的套餐搭配过程须要思考用户选定的筛选条件，例如条件可能为“主食为米饭”且“价格为30元以下”。咱们通过剪枝策略保障搭配过程满足束缚，以“满减神器”的价格区间束缚为例，Decoder端在单步产生候选菜品时，会基于残余的价格过滤掉超出残余价格范畴的菜品。如下图6所示，对于商家的A、B、C、D、E菜品，Decoder会利用残余价格的区间“15元以内”对后一轮菜品A、B、C、D、E进行剪枝，并删除超过价格区间的C、D两个菜品。 基于Attention网络的套餐搭配模型 基于LSTM网络的商家内菜品特征提取面临的问题有：第一，商家菜单的菜品自身无序，而RNN网络依赖序列进行建模。第二，菜品之间可能存在长距离的语义依赖，例如，菜单内是否有“米饭”、“馒头”等菜品会影响对于“宫保鸡丁”菜品的搭配。 为了更好的对无序菜单和菜品之间依赖信息进行表征，咱们尝试了基于Attention构造的Encoder-Decoder模型。Encoder局部采纳层次化Attention构造提取菜品的语义信息，蕴含底层单菜品级的Attention和菜品之间的Attention两局部。对于单菜品级的Attention，咱们在字维度采纳Multi-Head Attention构造失去菜品名称的语义向量，菜品标签同样采纳Multi-Head Attention 失去菜品标签语义向量，对于菜品的交易属性，咱们采纳多层全连贯网络提取交易特色的语义向量。 最初，菜品名称语义向量、菜品标签语义向量、交易特色语义向量拼接后通过全连贯层+层归一化失去菜品语义向量。对于菜品之间的Attention层，咱们对该店的菜品语义向量列表采纳多层Multi-Head Attention失去该店的菜单级别语义向量。模型Decoder局部同样采纳Multi-Head Attention进行解码，输出信息包含用户偏好信息、历史时刻的解码输出、价格束缚等上下文信息，模型在每步输入商家菜单中的菜品被抉择的概率分布。Decoder过程中咱们对用户偏好信息同商家菜单级别的语义向量进行Multi-Head Attention，在套餐搭配过程中思考用户的用餐偏好。 3.2.3 套餐搭配模型剖析咱们认为商家高质量的搭配能够从订单的销量体现，一种评估办法即是评估模型输入的套餐对商家实在高销量套餐的笼罩。通过离线和在线评估，咱们发现该模型能够拟合出商家高销量套餐。在人工评估局部，咱们把算法搭配的套餐和实在成单订单进行混合并让人工进行辨别，发现人工无奈分辨模型搭配的订单和实在成单订单的差别。同时，该模型具备良好的泛化能力，显著晋升了套餐对商家和特定业务场景的覆盖度。 咱们对模型输入的菜品表征向量进行了剖析，以理解模型的套餐搭配模式。利用TSNE对向量进行降维和聚类，通过聚类图察看发现“主食”、“主菜”、“小食”类的菜品各自汇集在一起，能够看出模型辨认了菜品的“主食”、“菜品”、"小食"等品类语义属性，并参考此语义进行套餐搭配。 主食类："馄饨"的TOP N类似菜品菜品类："红烧肉"的TOP N类似菜品鸡汤大馄饨 0.981黄瓜拌牛肉 0.975豌杂酸辣粉 0.979鲜菇牛肉 0.977猪肉馄饨 0.975毛家红烧肉 0.980清汤牛肉面 0.975白菜肥肠 0.973皮肚肥肠面 0.974拌小肠 0.976海鲜炒乌冬面 0.974猪头肉 0.981大葱肉锅贴 0.973红烧小土豆 0.975豌杂米粉 0.971拌牛肉 0.9803.3 实时套餐搭配模型利用离线搭配产生套餐候选的计划能够满足举荐型业务的需要，但对于一些搭配型的业务场景依然笼罩有余，例如，目前离线套餐对菜品的覆盖度较低，即对于菜品详情页等利用只保障局部PV的搭配模块露出。 ...

在微服务架构下，服务拆分会让API的规模成倍增长，应用API网关来治理API逐步成为一种趋势。美团对立API网关服务Shepherd就是在这种背景下应运而生，实用于美团业务且齐全自研，用于替换传统的Web层网关利用，业务研发人员通过配置的形式即可对外开放性能和数据。本文将介绍美团对立API网关诞生的背景、要害的技术设计和实现，以及API网关将来的布局，心愿能给大家带来一些帮忙或者启发。一、背景介绍1.1 API网关是什么？API网关是随着微服务（Microservice）概念衰亡的一种架构模式。本来一个宏大的单体利用（All in one）业务零碎被拆分成许多微服务（Microservice）零碎进行独立的保护和部署，服务拆分带来的变动是API的规模成倍增长，API的治理难度也在日益减少，应用API网关公布和治理API逐步成为一种趋势。一般来说，API网关是运行于内部申请与外部服务之间的一个流量入口，实现对外部申请的协定转换、鉴权、流控、参数校验、监控等通用性能。 1.2 为什么要做Shepherd API网关？在没有Shepherd API网关之前，美团业务研发人员如果要将外部服务输入为对外的HTTP API接口。通常要搭建一个Web利用，用于实现根底的鉴权、限流、监控日志、参数校验、协定转换等工作，同时须要保护代码逻辑、根底组件的降级，研发效率绝对比拟低。此外，每个Web利用都须要保护机器、配置、数据库等，资源利用率也十分差。 美团外部一些业务线苦于没有现成的解决方案，依据本身业务特点，研发了业务相干的API网关。放眼业界，亚马逊、阿里巴巴、腾讯等公司也都有成熟的API网关解决方案。 因而，Shepherd API网关我的项目正式立项，咱们的指标是为美团提供高性能、高可用、可扩大的对立API网关解决方案，让业务研发人员通过配置的形式即可对外开放性能和数据。 1.3 应用Shepherd带来的收益是什么？从业务研发人员的角度来看，接入Shepherd API网关，能带来哪些收益呢？简而言之包含三个方面。 晋升研发效率 业务研发人员只须要通过配置的形式即可疾速凋谢服务接口。Shepherd对立提供鉴权、限流、熔断等非业务根底能力。Shepherd反对业务研发人员通过开发自定义组件的形式扩大API网关能力。升高沟通老本 业务研发人员配置好API，能够主动生成API的前后端交互文档和客户端SDK，不便前后端开发人员进行交互、联调。晋升资源利用率 基于Serverless的架构思维，实现API全托管，业务研发人员无需关怀机器资源问题。二、技术设计与实现2.1 整体架构咱们先来看看Shepherd API网关的整体架构，如下图所示： Shepherd API网关的管制面由Shepherd治理平台和Shepherd监控核心组成。治理平台次要实现API的全生命周期治理以及配置下发的工作，监控核心实现API申请监控数据的收集和业务告警性能。 Shepherd API网关的配置核心次要实现管制面与数据面的信息交互，通过美团对立配置服务Lion来实现。 Shepherd API网关的数据面也就是Shepherd 服务端。一次残缺的API申请，可能是从挪动利用、Web利用，合作伙伴或外部零碎发动，通过Nginx负载平衡零碎后，达到服务端。服务端集成了一系列的根底性能组件和业务自定义组件，通过泛化调用申请后端RPC服务、HTTP服务、函数服务或服务编排服务，最初返回响应后果。 上面咱们将针对这三个次要模块做具体的介绍。 2.1.1 管制面应用API网关的管制面，业务研发人员能够轻松的实现API的全生命周期治理，如下图所示： 业务研发人员从创立API开始，实现参数录入、DSL脚本生成；接着能够通过文档和MOCK性能进行API测试；API测试实现后，为了保障上线稳定性，Shepherd治理平台提供了公布审批、灰度上线、版本回滚等一系列平安保障措施；API运行期间会监控API的调用失败状况、记录申请日志，一旦发现异常及时收回告警；最初，对于不再应用的API进行下线操作后，会回收API所占用的各类资源并期待从新启用。 整个生命周期，全副通过配置化、流程化的形式，由业务研发人员全自助治理，上手工夫根本在10分钟以内，极大地晋升了研发效率。 2.1.2 配置核心API网关的配置核心寄存API的相干配置信息——应用自定义的DSL（Domain-Specific Language，畛域专用语言）来形容，用于向API网关的数据面下发API的路由、规定、组件等配置变更。 配置核心的设计上应用对立配置管理服务Lion和本地缓存联合的形式，实现动静配置，不停机公布。API的配置如下图所示： API配置的具体阐明： Name、Group：名字、所属分组。Request：申请的域名、门路、参数等信息。Response：响应的后果组装、异样解决、Header、Cookies信息。Filters、FilterConfigs：API应用到的性能组件和配置信息。Invokers：后端服务(RPC/HTTP/Function)的申请规定和编排信息。2.1.3 数据面API路由 API网关的数据面在感知到API配置后，会在内存中建设申请门路与API配置的路由信息。通常HTTP申请门路上，会蕴含一些门路变量，思考到性能问题，Shepherd没有采纳正则匹配的形式，而是设计了两种数据结构来存储。如下图所示： 一种是不蕴含门路变量的间接映射的MAP构造。其中，Key就是残缺的域名和门路信息，Value是具体的API配置。 另外一种是蕴含门路变量的前缀树数据结构。通过前缀匹配的形式，先进行叶子节点准确查找，并将查找节点入栈解决，如果匹配不上，则将栈顶节点出栈，再将同级的变量节点入栈，如果依然找不到，则持续回溯，直到找到（或没找到）门路节点并退出。 性能组件 当申请流量命中API申请门路进入服务端，具体解决逻辑由DSL中配置的一系列性能组件实现。网关提供了丰盛的性能组件集成，包含链路追踪、实时监控、拜访日志、参数校验、鉴权、限流、熔断降级、灰度分流等，如下图所示： 协定转换&服务调用 API调用的最初一步，就是协定转换以及服务调用了。网关须要实现的工作包含：获取HTTP申请参数、Context本地参数，拼装后端服务参数，实现HTTP协定到后端服务的协定转换，调用后端服务获取响应后果并转换为HTTP响应后果。 上图以调用后端RPC服务为例，通过JsonPath表达式获取HTTP申请不同部位的参数值，替换RPC申请参数相应部位的Value，生成服务参数DSL，最初借助RPC泛化调用实现本次服务调用。 2.2 高可用设计Shepherd API网关作为接入层的根底组件，高可用性始终是业务研发人员十分关怀的局部。接下来。咱们就来摸索一下Shepherd在高可用设计方面的实际。 2.2.1 排除性能隐患一个高可用的零碎，预防故障的产生，首先要排除性能隐患，保障高性能。 Shepherd对API申请做了全异步化解决，申请通过Jetty IO线程异步提交到业务解决线程池，调用后端服务应用RPC或HTTP框架的异步形式，开释了因为网络期待引起的线程占用，使线程数不再成为网关的瓶颈。下图是应用Jetty容器时，服务端的申请线程解决逻辑： 咱们通过域名压测网关单机的端到端QPS，发现QPS在超过2000时，会呈现很多超时谬误，而网关的服务端负载与性能却十分充裕。调研发现，公司内其余的Web利用都存在这个问题，与Oceanus团队进行联结排查后，发现是Nginx与Web利用之间的长连接功能没有关上，且无奈配置。Oceanus团队通过紧急排期，研发并上线长连接功能后，Shepherd端到端的QPS胜利晋升到了10000以上。 另外，咱们对Shepherd服务端进行了API申请预热的优化，使得网关启动时能立即达到最佳性能，缩小毛刺的产生。而后，通过压测时的CPU热点排查，将性能瓶颈找出，缩小主链路上的本地日志打印，对申请日志进行异步化、近程化革新。Shepherd端到端的QPS再次晋升30%以上。 在Shepherd服务上线稳固运行一年当前，咱们再次对性能进行优化，并且做了一次网络框架降级，将Jetty容器全面替换为Netty网络框架，性能晋升10%以上，Shepherd端到端的QPS胜利晋升到15000以上。下图是应用Netty框架时，服务端的申请线程解决逻辑： 2.2.2 服务隔离集群隔离 ...

1 背景美团外卖业务品种繁多、场景丰盛，依据业务特点可分为举荐、广告、搜寻三大业务线以及数个子业务线，比方商家举荐、菜品举荐、列表广告、外卖搜寻等等，满足了数亿用户对外卖服务的全方面需要。而在每条业务线的背地，都波及用户、商家、平台三方面利益的均衡：用户须要精准的展示后果；商家须要尽可能多的曝光和转化；平台须要营收的最大化，而算法策略通过模型机制的优化迭代，正当地保护这三方面的利益均衡，促成生态良性倒退。 随着业务的倒退，外卖算法模型也在一直演进迭代中。从之前简略的线性模型、树模型，到当初简单的深度学习模型，预估成果也变得愈发精准。这所有除了受害于模型参数的一直调优，也受害于外卖算法平台对算力增长的工程化撑持。外卖算法平台通过对立算法工程框架，解决了模型&特色迭代的系统性问题，极大地晋升了外卖算法的迭代效率。依据性能不同，外卖算法平台可划分为三局部：模型服务、模型训练和特色平台。其中，模型服务用于提供在线模型预估，模型训练用于提供模型的训练产出，特色平台则提供特色和样本的数据撑持。本文将重点论述外卖特色平台在建设过程中遇到的挑战以及优化思路。 诚然，业界对特色零碎的钻研较为宽泛，比方微信FeatureKV存储系统聚焦于解决特色数据疾速同步问题，腾讯广告特色工程聚焦于解决机器学习平台中Pre-Trainer方面的问题，美团酒旅在线特色零碎聚焦于解决高并发情景下的特色存取和生产调度问题，而外卖特色平台则聚焦于提供从样本生成->特色生产->特色计算的一站式链路，用于解决特色的疾速迭代问题。 随着外卖业务的倒退，特色体量也在快速增长，外卖平台面对的挑战和压力也一直增大。目前，平台已接入特色配置近万个，特色维度近50种，日解决特色数据量几十TB，日解决特色千亿量级，日调度工作数量达数百个。面对海量的数据资源，平台如何做到特色的疾速迭代、特色的高效计算以及样本的配置化生成？下文将分享美团外卖在平台建设过程中的一些思考和优化思路，心愿能对大家有所帮忙或启发。 2 特色框架演进2.1 旧框架的有余外卖业务倒退初期，为了晋升策略迭代效率，算法同学通过积攒和提炼，整顿出一套通用的特色生产框架，该框架由三局部组成：特色统计、特色推送和特色获取加载。如下图所示： 特色统计：基于根底数据表，框架反对统计多个时段内特定维度的总量、散布等统计类特色。特色推送：框架反对将Hive表里的记录映射成Domain对象，并将序列化后的后果写入KV存储。特色获取加载：框架反对在线从KV存储读取Domain对象，并将反序列化后的后果供模型预估应用。该框架利用在外卖多条业务线中，为算法策略的迭代提供了无力撑持。但随着外卖业务的倒退，业务线的增多，数据体量的增大，该框架逐步裸露以下三点有余： 特色迭代老本高：框架不足配置化治理，新特色上线须要同时改变离线侧和在线侧代码，迭代周期较长。特色复用艰难：外卖不同业务线间存在类似场景，使特色的复用成为可能，但框架不足对复用能力的很好撑持，导致资源节约、特色价值无奈充分发挥。平台化能力缺失：框架提供了特色读写的底层开发能力，但不足对特色迭代残缺周期的平台化追踪和治理能力。2.2 新平台的劣势针对旧框架的有余，咱们在2018年中旬开始着手搭建新版的特色平台，通过一直的摸索、实际和优化，平台性能逐步齐备，使特色迭代能力更上一层台阶。 特色平台框架由三局部组成：训练样本生成（离线）、特色生产（近线）以及特色获取计算（在线），如下图所示： 训练样本生成：离线侧，平台提供对立配置化的训练样本生成能力，为模型的成果验证提供数据撑持。特色生产：近线侧，平台提供面对海量特色数据的加工、调度、存储、同步能力，保障特色数据在线疾速失效。特色获取计算：在线侧，平台提供高可用的特色获取能力和高性能的特色计算能力，灵便撑持多种简单模型的特色需要。目前，外卖特色平台已接入外卖多条业务线，涵盖数十个场景，为业务的策略迭代提供平台化反对。其中，平台的劣势在于两点： 业务提效：通过特色配置化治理能力、特色&算子&解决方案复用能力以及离线在线买通能力，晋升了特色迭代效率，升高了业务的接入老本，助力业务疾速拿到后果。业务赋能：平台以对立的规范建设特色成果评估体系，有助于特色在业务间的借鉴和流通，最大水平施展出特色的价值。3 特色平台建设3.1 特色生产：海量特色的生产能力特色同步的形式有多种，业界常见做法是通过开发MR工作/Spark工作/应用同步组件，从多个数据源读取多个字段，并将聚合的后果同步至KV存储。这种做法实现简略，但存在以下问题： 特色反复拉取：同一特色被不同工作应用时，会导致特色被反复拉取，造成资源节约。不足全局调度：同步工作间彼此隔离，互相独立，不足多任务的全局调度管理机制，无奈进行特色复用、增量更新、全局限流等操作，影响特色的同步速度。存储形式不够灵便强壮：新特色存储时，波及到上下游代码/文件的改变，迭代老本高，特色数据异样时，需长时间重导旧数据，回滚效率较低。围绕上述几点问题，本文将从三个方面进行特色生产外围机制的介绍： 特色语义机制：用于解决平台从数百个数据源进行特色拉取和转化的效率问题。特色多任务调度机制：用于解决海量特色数据的疾速同步问题。特色存储机制：用于解决特色存储在配置化和可靠性方面的问题。3.1.1 特色语义特色平台目前已接入上游Hive表数百个、特色配置近万个，其中大部分特色都需天级别的更新。那平台如何从上游高效地拉取特色呢？直观想法是从特色配置和上游Hive表两个角度进行思考： 特色配置角度：平台依据每个特色配置，独自启动工作进行特色拉取。 长处：管制灵便。毛病：每个特色都会启动各自的拉取工作，执行效率低且消耗资源。上游Hive表角度：Hive表中多个特色字段，对立放至同一工作中拉取。 长处：工作数量可控，资源占用低。毛病：工作逻辑耦合较重，新增特色时需感知Hive表其它字段拉取逻辑，导致接入老本高。上述两种计划都存在各自问题，不能很好满足业务需要。因而，特色平台联合两个计划的长处，并通过摸索剖析，提出了特色语义的概念： 特色语义：由特色配置中的上游Hive表、特色维度、特色过滤条件、特色聚合条件四个字段提取合并而成，实质就是雷同的查问条件，比方：Select KeyInHive,f1,f2 From HiveSrc Where Condition Group by Group，此时该四个字段配置雷同，可将F1、F2两个特色的获取过程可合并为一个SQL语句进行查问，从而缩小整体查问次数。另外，平台将语义合并过程做成自动化透明化，接入方只需关怀新增特色的拉取逻辑，无需感知同表其它字段，从而升高接入老本。特色平台对特色语义的解决分为两个阶段：语义抽取和语义合并，如下图所示： 语义抽取：平台解析特色配置，构建SQL语法树，通过反对多种形式判同逻辑（比方交换律、等效替换等规定），生成可惟一化表白的SQL语句。语义合并：如果不同特色对应的语义雷同，平台会将其抽取过程进行合并，比方：Select KeyInHive, Extract1 as f1, Extract2 as f2 From HiveSrc Where Condition Group by Group，其中Extract即特色的抽取逻辑，f1和f2的抽取逻辑可进行合并，并将最终抽取到的特色数据落地至特色共享表中存储，供多业务方应用。3.1.2 特色多任务调度为了保障每天数十TB数据量的疾速同步，特色平台首先依照特色的解决流程：获取、聚合和同步，别离制订了特色语义工作、特色聚合工作和特色同步工作： 特色语义工作：用于将特色数据从数据源拉取解析，并落地至特色共享表中。特色聚合工作：用于不同业务线（租户）依照本身需要，从特色共享表中获取特定特色并聚合，生成全量快照以及增量数据。特色同步工作：用于将增量数据（天级）和全量数据（定期）同步至KV存储中。同时，特色平台搭建了多任务调度机制，将不同类型的工作进行调度串联，以晋升特色同步的时效性，如下图所示： 任务调度器：依照工作执行程序，循环检测上游工作状态，保障工作的有序执行。特色语义任务调度：当上游Hive表就绪后，执行语义工作。 上游监测：通过上游任务调度接口实时获取上游Hive表就绪状态，就绪即拉取，保障特色拉取的时效性。语义优先级：每个语义都会设置优先级，高优先级语义对应的特色会被优先聚合和同步，保障重要特色的及时更新。队列优选：平台会获取多个队列的实时状态，并优先选择可用资源最多的队列执行语义工作，晋升工作执行效率。特色复用：特色的价值在于复用，特色只需接入平台一次，就可在不同业务间流通，是一种业务赋能的体现。 特色对立存储在特色共享表中，供上游不同业务方按需读取，灵便应用。特色的对立接入复用，防止雷同数据的反复计算和存储，节俭资源开销。特色聚合任务调度：当上游语义工作就绪后，执行聚合工作。 多租户机制：多租户是平台面向多业务接入的根底，业务以租户为单位进行特色治理，并为平台摊派计算资源和存储资源。特色分组：特色分组将雷同维度下的多个特色进行聚合，以缩小特色Key的数量，防止大量Key读写对KV存储性能造成的影响。全量快照：平台通过天级别聚合的形式生成特色全量快照，一方面便于增量数据探查，另一方面也防止历史数据的失落。增量探查：通过将最新特色数据与全量快照的数值比照，探查出发生变化的特色，便于后续增量同步。特色弥补：因就绪提早而未被当天同步的特色，可跨天进行弥补同步，避免出现特色跨天失落的问题。特色同步任务调度：当上游聚合工作就绪后，执行同步工作。 增量同步：将经全量快照探查到的增量数据，同步写入KV存储，大大降低数据写入量，晋升同步效率。全量刷新：KV存储中的数据因为过期工夫限度，需定期进行全量刷新，避免出现特色过期导致的数据失落问题。全局限流：通过监测同步工作的并行度以及KV存储状态指标，实时调整全局同步速度，在保障KV存储稳定性前提下，充分利用可用资源来晋升特色同步效率。3.1.3 特色存储3.1.3.1 特色动静序列化特色数据通过聚合解决后，需存储到HDFS/KV零碎中，用于后续工作/服务的应用。数据的存储会波及到存储格局的选型，业界常见的存储格局有JSON、Object、Protobuf等，其中JSON配置灵便，Object反对自定义构造，Protobuf编码性能好且压缩比高。因为特色平台反对的数据类型较为固定，但对序列化反序列化性能以及数据压缩成果有较高要求，因而抉择Protobuf作为特色存储格局。 Protobuf的惯例应用形式是通过Proto文件维护特色配置。新增特色需编辑Proto文件，并编译生成新版本JAR包，在离线&在线同时公布更新后，能力生产解析新增特色，导致迭代老本较高。Protobuf也提供了动静自描述和反射机制，帮忙生产侧和生产侧动静适配音讯格局的变更，防止动态编译带来的JAR包降级老本，但代价是空间老本和性能老本均高于动态编译形式，不适用于高性能、低时延的线上场景。 针对该问题，特色平台从特色元数据管理的角度，设计了一种基于Protobuf的特色动静序列化机制，在不影响读写性能前提下，做到对新增特色读写的齐全配置化。 为不便论述，先概述下Protobuf编码格局。如下图所示，Protobuf按“键-值”模式序列化每个属性，其中键标识了该属性的序号和类型。能够看出，从原理上，序列化次要要依赖键中定义的字段序号和类型。 因而，特色平台通过从元数据管理接口查问元数据，来替换惯例的Proto文件配置形式，去动静填充和解析键中定义的字段序号和类型，以实现序列化和反序列化，如下图所示： 特色序列化：通过查问特色元数据，获取特色的序号和类型，将特色序号填充至键的序号属性中，并依据特色类型决定键的类型属性以及特征值的填充形式。特色反序列化：解析键的属性，获取特色序号，通过查问特色元数据，获取对应的特色类型，并依据特色类型决定特征值的解析形式（定长/变长）。3.1.3.2 特色多版本特色数据存储于KV零碎中，为在线服务提供特色的实时查问。业界常见的特色在线存储形式有两种：繁多版本存储和多版本存储。 繁多版本存储即笼罩更新，用新数据间接笼罩旧数据，实现简略，对物理存储占用较少，但在数据异样的时候无奈疾速回滚。多版本存储相比前者，减少了版本概念，每一份数据都对应特定版本，尽管物理存储占用较多，但在数据异样的时候可通过版本切换的形式疾速回滚，保障线上稳定性。因而，特色平台抉择特色多版本作为线上数据存储形式。 ...

1、先上图 2、前言某天下午，我正在公司认真的写着代码，忽然我的手机弹了一个告诉，我连忙抓起手机看看（给本人一个摸鱼的理由） 让我看看到底是谁发消息打搅我认真的工作啊。 害，原来是某个群转发了一个外卖红包，我悲观的刚想放下手机，然而看了一眼电脑上的代码，算了算了，还是再看看手机吧。说不定这不是一个外卖红包这么简略呢？ 满30减8，就这？？？ 看着手机屏幕上的满减券，我陷入了深思，为什么这个人要转发一个红包到群里呢，这不是让我捡便宜了吗？ 不会他真的是一个坏蛋吧，从不利己专门利人？ 我把键盘推开，而后认真看看这个红包，嗷，原来分享给他人之后，如果他人生产了，那么他就能够拿到佣金。 哦豁？ 于是一个小想法在我脑子里呈现 3、想法开始实际我要整一个这样的小程序，让用户从这里领红包，而后我就能拿到佣金 我有一千个好友，如果每个人一天吃一顿外卖20块，我拿5% 1000X20X0.05 = 1000 那就是一千啊！那我还上什么班，还给老板写什么代码？？？ 想着，我又把鼠标给扔了 4、筹备工作一、申请一个小程序申请地址：微信公众平台，申请小程序的操作很简略，大家百度一下跟着步骤申请就行，某宝上还有认证小程序代申请代认证，老铁们能够自行抉择。 二、下载微信开发者工具下载地址：https://developers.weixin.qq.com/miniprogram/dev/devtools/download.html 三、下载解压HBuilderX下载地址：https://www.dcloud.io/hbuilderx.html 四、下载小程序源码 https://github.com/mgbq/coupons 大家能够在我的公众号：“吃喝玩乐券券”间接回复“外卖”即可取得小程序源码。下载后解压。 5、搭建开始一、将源码导入HBuilderX1、源码解压后导入到HBuilderX二、配置我的项目1、关上微信微信开发者工具，在平安设置中关上服务端口 2、关上HBuilderX，点击“运行-运行到小程序模拟器-运行配置”中设置你装置微信开发者工具的门路。 6、公布小程序1、右键我的项目文件夹，点击“发行-小程序-微信（仅实用于uniapp）” 2、填写小程序名称和小程序appid即可唤起微信开发者工具。 3、在微信开发者工具点击上传，在小程序后盾提交审核，审核通过后即可失常经营 常见问题1.如何获取美团饿了么的推广链接 2.为什么说能赚钱？ 例如你有一千个好友(四，五个微信群)，如果每个人一天吃一顿外卖20块，你拿5%1000X20X0.05 = 1000 那就是一千啊！还上什么班？？？ ## 最初 贴一张推广大佬的收益图，只有你能推广，赚钱真的很容易。 作者相干文章反编译获取任何微信小程序源码——看这篇就够了 抽签小程序，妈妈再也不必放心谁洗碗（分配任务）了，so easy 5分钟实现微信云小程序领取性能（含源码）

前言鸿蒙零碎 （HarmonyOS）是华为推出的一款面向未来、面向全场景的分布式操作系统。在传统单设施零碎能力的根底上，鸿蒙提出了基于同一套零碎能力、适配多种终端状态的分布式理念。自 2020 年 9 月 HarmonyOS 2.0 公布以来，华为放慢了鸿蒙零碎大规模落地的步调，预计 2021 年底，鸿蒙零碎会笼罩包含手机、平板、智能穿戴、智慧屏、车机在内数亿台终端设备。对挪动利用而言，新的零碎理念、新的交互模式，也意味着新的时机。如果可能利用好鸿蒙的开发生态及其个性能力，能够让利用笼罩更多的交互场景和设施类型，从而带来新的增长点。 与面临的时机相比，适配鸿蒙零碎带来的挑战同样微小。以后手机端，只管鸿蒙零碎依然反对安卓 APK 装置及运行，但长期来看，华为势必会摈弃 AOSP，逐渐倒退出本人的生态，这意味着现有安卓利用在鸿蒙设施上将会逐步变成“二等公民”。然而，如果在 iOS 及 Android 之外再从新开发和保护一套鸿蒙利用，在现在业界越来越重视开发迭代效率的环境下，所带来的开发成本也是难以估计的。因而，通过打造一套适合的跨端框架，以绝对低的老本移植利用到鸿蒙平台，并利用好该零碎的个性能力，就成为了一个十分重要的选项。 在现有的泛滥跨端框架当中，Flutter 以其自渲染能力带来的多端高度一致性，在新零碎的适配上有着突出的劣势。尽管Flutter 官网并没有适配鸿蒙的打算，但通过一段时间的摸索和实际，美团外卖 MTFlutter 团队胜利实现了 Flutter 对于鸿蒙零碎的原生反对。 这里也要提前阐明一下，因为鸿蒙零碎目前还处于Beta版本，所以这套适配计划还没有在理论业务中上线，属于技术层面比拟后期的摸索。接下来本文会通过原理和局部实现细节的介绍，分享咱们在移植和开发过程中的一些教训。心愿能对大家有所启发或者帮忙。 背景常识和根底概念介绍在适配开始之前，咱们要明确好先做哪些事件。先来回顾一下 Flutter 的三层构造： 在 Flutter 的架构设计中，最上层为框架层，应用 Dart 语言开发，面向 Flutter 业务的开发者；中间层为引擎层，应用 C/C++ 开发，实现了 Flutter 的渲染管线和 Dart 运行时等根底能力；最上层为嵌入层，负责与平台相干的能力实现。显然咱们要做的是将嵌入层移植到鸿蒙上，确切地说，咱们要通过鸿蒙原生提供的平台能力，从新实现一遍 Flutter 嵌入层。 对于 Flutter 嵌入层的适配，Flutter 官网有一份不算具体的指南，实际操作起来老本很高。因为鸿蒙的业务开发语言依然可用 Java，在很多根底概念上与 Android 也有相似之处（如下表所示），咱们能够从 Android 的实现动手，实现对鸿蒙的移植。 Flutter 在鸿蒙上的适配如前文所述，要实现 Flutter 在新零碎上的移植，咱们须要残缺实现 Flutter 嵌入层要求的所有子模块，而从能力反对角度，渲染、交互以及其余必要的原生平台能力是保障 Flutter 利用可能运行起来的最根本的因素，须要优先反对。接下来会顺次进行介绍。 1. 渲染流程买通咱们再来回顾一下 Flutter 的图像渲染流程。如图所示，设施发动垂直同步（VSync）信号之后，先通过 UI 线程的渲染管线（Animate/Build/Layout/Paint），再通过 Raster 线程的组合和栅格化，最终通过 OpenGL 或 Vulkan 将图像上屏。这个流程的大部分工作都由框架层和引擎层实现，对于鸿蒙的适配，咱们次要关注的是与设施本身能力相干的问题，即： ...

1. 引言过来几年，主动驾驶技术有了飞速发展。国内也呈现了许多主动驾驶守业企业，这些公司以百度开源我的项目Apollo为终点，大都能够间接进行公开路线测试，公开路线测试也成为促成技术提高的次要办法。根底问题得以解决之后，行业面临的更多是长尾问题，依附路测驱动主动驾驶能力建设的形式变得不再高效，离线仿真的位置日益凸显。行业头部企业在仿真的投入非常微小，Waymo公司2019年颁布的仿真里程是100亿英里，是路测里程的1000倍。 相应地，美团无人车团队在仿真上的投入也在逐步增大。在仿真平台的建设中，团队发现公开路线测试和仿真测试看似类似，实际上差别微小：在车载环境下，为了确保零碎的稳固运行，通常要保障肯定资源处于闲暇状态；仿真环境则不同，如何高效利用资源，如何实现压迫资源的同时确保仿真后果与路测后果统一成为了要害指标。在应答这些挑战的过程中，美团提出了无人车引擎的概念，将车载与离线环境的差别隔离起来：功能模块无需任何更改便能够满足两种场景的须要。 本文首先会介绍无人车引擎的概念，并以仿真环境面临的挑战为线索介绍美团无人车引擎的外围设计。 02 无人车引擎概念无人车引擎是主动驾驶的基础设施，在机制、工具和计算模型上对功能模块提供反对，隔离主动驾驶所处环境，使各功能模块专一于本身性能。 在机制层，他为各功能模块提供通信、调度、数据、配置、异样监控等反对。 在应用层，引擎为各功能模块提供调试、可视化、性能调优、成果评估等工具反对。 在模块层，引擎为各功能模块提供对立的计算模型和运行环境，确保他们在车上环境、分布式环境、调试环境下的行为统一。 美团无人车引擎的架构图如下： 如图1所示，作为引擎撑持的次要局部，Perception、Localization、Planning等是主动驾驶零碎中重要的功能模块，它们实现了无人车零碎的外围性能。引擎则在机制和工具，高低两个方向上撑持他们：各功能模块依照引擎的标准开发，间接或者间接地应用引擎机制层提供的性能并自然而然地取得工具的反对。比方，功能模块只有应用引擎的通信工具，就能间接取得数据落盘、性能报表调试信息可视化的反对，同时基于这些路测数据，在仿真环境下，功能模块会主动取得单步调试、成果评估等性能反对。 主动驾驶引擎面临的挑战图1中所列举的性能是引擎的根底组成部分，引擎所提供的远不止于此，对于多种环境的反对才是美团无人车团队引入引擎概念的真正起因。后面提到，无人车首先运行在车载零碎中，随着技术和环境的变动，更多地运行于仿真环境下，二者截然不同。车载环境下，无人车零碎的运行环境较好，为了保障各功能模块可能失常运行，CPU、GPU、内存等资源要提供肯定水平的冗余。而仿真环境的要求齐全不同：从用户的角度看，仿真的用户是工程师，他们冀望仿真工作可能在确定工夫内实现尽量多的工作；从集群的角度看，他们心愿仿真可能尽量晋升资源利用率。接下来的局部将介绍无人车零碎在这两类环境下会面临哪些挑战，以及美团无人车团队如何通过引擎应答这些挑战。 行为一致性的挑战晚期，美团无人车团队依赖于ROS搭建无人车零碎，在车载环境下，ROS的体现合格。然而在开始仿真建设后，团队遇到很多问题，其中最突出的是“行为一致性问题”，这个问题具体是指：无人车零碎在运行过程中，当呈现系统资源的变动，行为也随之发生变化。比方，当仿真工作在一台机器上运行时，零碎产生的后果和这台机器的状态无关，这台机器被独占地应用或是和其它工作同时运行，后果会有差别。而且，即便不思考资源利用率，让仿真工作独占机器资源，同一个工作运行两次，后果也会有强劲的扰动。 更重大状况产生在离线环境，此情境谋求资源利用率的最大化，意味着计算资源的非常缓和，扰动将变得不再轻微，后果将变得更不牢靠，仿真的后果也就失去了价值。 因而，如何在车上和离线两套截然不同的环境下确保后果的一致性，是仿真引擎必须解决的问题。此问题由以下两个起因造成：一是功能模块时序的不统一；二是功能模块外部执行的不统一。 时序一致性为了介绍什么是时序一致性，首先要介绍一下无人车零碎中时序的概念。 无人车零碎由多个功能模块组成，功能模块之间有数据依赖关系，比方Perception依赖于 Lidar、Camera的数据，Prediction依赖于Prediction的输入。不同模块的触发条件不同，比方 Planning是根据时钟触发的而Prediction是依赖于Perception的数据触发的。由数据关系和触发条件造成的功能模块的执行程序就是主动驾驶零碎的时序。在现实状况下，每个模块都能在满足触发条件时立即执行并在预期的工夫内实现工作，也就是说，只有保留各模块的输入就能够齐全复现线上的问题，离线仿真呈现的问题在路测时也必然呈现。 然而现实情况远比这简单，举例来说，当无人车通过拥挤路段时，Perception须要解决的数据会显著增多，Planning也可能因为交通参与者过多导致耗时增长，时序必然与现实状况不合乎。如下图3所示，在车载环境下这种行为形式是没问题的，然而在仿真环境时却会导致严重后果：每一次计算环境的些许变动都有可能导致时序的变动，进而导致系统行为的差别。 这就是时序一致性问题。为了解决这种问题，美团无人车引入了调度器，时序的一致性由调度器保障。此外，引擎依照不同的利用场景，进一步细化了调度器的品种。其中最简略的调度器是“在线调度器”，它的指标只有一个：在功能模块处于Ready状态时执行它，车载零碎中就是应用的这种调度器，它的行为形式也与ROS相似，不过他会记录下调度时序以备应用。除此之外，引擎还提供一组离线调度器，以应答不同的应用场景。这里在线和离线的差别依据数据起源判断，如果数据来自传感器那么就是在线调度器；如果数据来自路测记录那就是离线调度器，具体分类如下图4所示： 以下是美团无人车引擎提供的调度器品种及他们的应用场景： 在线调度器：在满足触发条件时立刻触发功能模块，通常在车载环境下会应用；复现调度器：依照调度器保留的调度信息复现调度时序，在调试时或复现路测场景时应用；现实调度器：依照现实时序调度资源，通常在仿真时应用；条件驱动调度器：在条件满足时调度功能模块运行。在这种调度形式下，功能模块的调度密度介于现实调度器和复现调度器之间，他的实现也绝对简略，是利用最宽泛的调度器。在他们的帮忙下，功能模块执行的时序就能失去保障：只有调度器和输出数据不变，那么无论计算环境如何变动，各功能模块的执行时序总能保持一致。 功能模块的计算模型时序一致性除了须要调度保障之外，功能模块的外部计算必须是受到调度器调度的。功能模块必须在调度器容许时能力开始执行，在完结时调度器能失去告诉。如果存在脱离调度器之外的计算线程，那么零碎的一致性必然无奈保障。为此，引擎引入了规范计算模型，任何一个功能模块都有应该恪守这个计算模型，从而取得引擎包含一致性保障、单步调试反对、信息可视化等性能的反对。 规范计算模型如下：每一个功能模块都有且仅有一个计算过程并以迭代为单位，每一次调度实现一帧的计算。当然引擎并不管制帧计算外部的细节，帧计算外部的优化由功能模块负责。 规范模型的定义并不一定合乎每一个功能模块的理论状况：比方Localization，它订阅多类频率不同的传感器数据并以不同的频率输入。在实践中，引擎通过对Localization性能的从新拆分实现了标准化。此外，对于像Perception这类计算量很大、同时兼具异构计算的功能模块来说，多线程，异步I/O的机制必须引入，引擎同时提供了相应的反对确保符合标准模型。 在实际过程中，美团无人车团队破费了相当工夫来实现这些革新。革新实现后仿真后果的权威性失去了增强，更重要的是：零碎的行为不再受内部资源（GPU、CPU、内存等）的影响，这也为离线环境晋升资源利用率扫清了阻碍。接下来介绍无人车引擎如何在功能模块齐全无感的状况下晋升资源利用率。 04 资源利用率问题后面提到过，车载零碎和仿真零碎环境差别很大：车载零碎为了谋求零碎的安稳运行会保障要害资源有肯定水平的富裕；对于仿真零碎，保留idle就是对资源的节约。在零碎的一致性失去保障之后，资源利用率能力成为引擎的优化指标。优化资源利用率蕴含了很多方面，比方数据调度等，因为篇幅所限，这里只介绍与引擎相干的优化工作。接下来的局部，将依据无人车零碎在仿真环境运行时的特点进行优化，他们别离是资源需要不均、功能模块的反复计算、GPU/CPU计算不均衡。 数据需要不平均从数据的输出规模上讲，各功能模块是极不平衡的：Perception和Localization依赖于Lidar和Camera数据，数据使用量占到零碎的 85% 以上（依照数据存储的规模计算，疏忽两头数据，具体比例与开启的Camera相干，此处给出概数）。从资源耗费上讲，Perception和Prediction耗费较多的 GPU 计算资源。为了晋升云计算资源的效率，无人车引擎必须反对分布式部署：即一套主动驾驶零碎别离部署与多台机器甚至是跨机房的机器之上的。 为了实现分布式部署，引擎参考了计算图模型的概念，采纳了相似于Tensorflow的设计：将功能模块分成了Node和Module两个局部。其中Node负责定义依赖关系，而Module负责实现计算。对于近程部署的Module来说，引擎提供了ADVContext和Node Stub 的概念用于帮助Module实现运算，对于Module而言，它对于本身处于环境（近程或者本地）无所不知。 基于图7的设计，主动驾驶零碎有了分布式部署的能力：一套主动驾驶零碎能够运行于一组机器之上。晋升离线效率的致力不再局限于单台机器，无人车零碎的离线优化取得了更多的伎俩和更广的空间。 反复计算仿真工作分成多种类型，即有运行单个模块的工作，也有同时执行 Perception、Prediction、Planning的工作。对于同时运行多个Module的工作，放在集群的角度看，很多计算都是反复的。试想一个场景：Planning引入新办法，工程师心愿可能在最新Perception版本上的取得新办法的成果评估后果。对于仿真而言，这是一个经典场景，罕用的办法是离线执行 Perception、Prediction和Planning三个模块并执行Evaluation产生报表、评估后果。 一般而言，Perception的后果受到数据和自身算法迭代的影响，当 Planning的迭代时，Perception的后果不会受到影响，它的输入齐全能够复用。得益于Node和Module概念的拆散，Perception Node所绑定的Module齐全能够是一个非计算单元，而是一个数据服务Module。 在美团无人车数据平台和无人车引擎共同努力下，通过Data Service Module, 这个常见的仿真工作的流程在工程师感知不到的状况下变成了图9这样。不同版本的Perception的输入后果被保留下来，Prediction和Planning只有应用之前的后果，防止了 Perception的反复计算。 GPU计算分流无人车零碎是一个同时具备重度CPU计算和重度GPU计算零碎，两局部的计算是不均衡的。引擎为了晋升GPU资源的利用效率，在外部集成了模型治理的性能同时提供了本地和近程两种Prediction的机制。再联合分布式部署形式，零碎能够齐全部署于CPU集群之上，模型相干的计算能够通过RPC申请在Model Serving上实现。通过GPU和CPU计算的隔离，引擎帮忙晋升了GPU和CPU计算资源的利用率。 05 论断在继续的实际中，美团无人配送团队抽离出一套主动驾驶引擎，为功能模块提供机制和工具的同时，它还提供了对车载（低时延）和仿真（高吞吐）两套环境的适配。此外，配合美团的大数据基础设施以及在此基础之上专为无人车建设的数据平台，美团无人车逐渐建设了欠缺的主动驾驶基础设施。将来，心愿在引擎的帮忙下可能隔离功能模块、计算平台、运行环境，使得主动驾驶能力迭代与主动驾驶落地利用两个方向上的工作可能独立发展，齐头并进，放慢美团无人车的落地步调。 对于美团无人配送美团无人车配送核心成立于2016年，由美团首席科学家夏华夏博士领导。美团无人车配送围绕美团外卖、美团跑腿等外围业务，通过与现有简单配送流程的联合，造成了无人配送整体解决方案，满足在楼宇、园区、公开路线等不同场景下最初三公里的外卖即时配送需要，晋升配送效率和用户体验，最终实现“用无人配送让服务触达世界每个角落”的愿景。 招聘信息美团无人车配送核心大量岗位继续招聘中，诚招算法/零碎/硬件开发工程师及专家。欢送感兴趣的同学发送简历至：ai.hr@meituan.com（邮件题目注明：美团无人车团队）。 想浏览更多技术文章，请关注美团技术团队（meituantech）官网微信公众号。在公众号菜单栏回复【2019年货】、【2018年货】、【2017年货】、【算法】等关键词，可查看美团技术团队历年技术文章合集。 ...

1.背景ETA（Estimated Time of Arrival，“预计送达时间”），即用户下单后，配送人员在多长时间内将外卖送达到用户手中。送达时间预测的结果，将会以"预计送达时间"的形式，展现在用户的客户端页面上，是配送系统中非常重要的参数，直接影响了用户的下单意愿、运力调度、骑手考核，进而影响配送系统整体成本和用户体验。对于整个配送系统而言，ETA既是配送系统的入口和全局约束，又是系统的调节中枢。具体体现在：ETA在用户下单时刻就需要被展现，这个预估时长继而会贯穿整个订单生命周期，首先在用户侧给予准时性的承诺，接着被调度系统用作订单指派的依据及约束，而骑手则会按照这个ETA时间执行订单的配送，配送是否准时还会作为骑手的工作考核结果。ETA作为系统的调节中枢，需要平衡用户-骑手-商家-配送效率。从用户的诉求出发，尽可能快和准时，从骑手的角度出发，太短会给骑手极大压力。从调度角度出发，太长或太短都会影响配送效率。而从商家角度出发，都希望订单被尽可能派发出去，因为这关系到商家的收入。在这样多维度的约束之下，外卖配送的ETA的建模和估计会变得更加复杂。与打车场景中的ETA做对比，外卖场景的ETA面临如下的挑战：外卖场景中ETA是对客户履约承诺的重要组成部分，无论是用户还是骑手，对于ETA准确性的要求非常高。而在打车场景，用户更加关心是否能打到车，ETA仅提供一个参考，司机端对其准确性也不是特别在意。由于外卖ETA承担着承诺履约的责任，因此是否能够按照ETA准时送达，也是外卖骑手考核的指标、配送系统整体的重要指标；承诺一旦给出，系统调度和骑手都要尽力保证准时送达。因此过短的ETA会给骑手带来极大的压力，并降低调度合单能力、增加配送成本；过长的ETA又会很大程度影响用户体验。外卖场景中ETA包含更多环节，骑手全程完成履约过程，其中包括到达商家、商家出餐、等待取餐、路径规划、不同楼宇交付等较多的环节，且较高的合单率使得订单间的流程互相耦合，不确定性很大，做出合理的估计也有更高难度。下图是骑手履约全过程的时间轴，过程中涉及各种时长参数，可以看到有十几个节点，其中关键时长达到七个。这些时长涉及多方，比如骑手（接-到-取-送）、商户（出餐）、用户（交付），要经历室内室外的场景转换，因此挑战性非常高。对于ETA建模，不光是简单一个时间的预估，更需要的是全链路的时间预估，同时更需要兼顾"单量-运力-用户转化率"转化率之间的平衡。配送ETA的演变包括了数据、特征层面的持续改进，也包括了模型层面一路从LR-XGB-FM-DeepFM-自定义结构的演变。具体ETA在整个配送业务中的位置及配送业务的整体机器学习实践，请参看《机器学习在美团配送系统的实践：用技术还原真实世界》。2.业务流程迭代中的模型改进2.1 基础模型迭代及选择与大部分CTR模型的迭代路径相似，配送ETA模型的业务迭代经历了LR->树模型->Embedding->DeepFM->针对性结构修改的路径。特征层面也进行不断迭代和丰富。模型维度从最初考虑特征线性组合，到树模型做稠密特征的融合，到Embedding考虑ID类特征的融合，以及FM机制低秩分解后二阶特征组合，最终通过业务指标需求，对模型进行针对性调整。特征维度逐步丰富到用户画像/骑手画像/商家画像/地址特征/轨迹特征/区域特征/时间特征/时序特征/订单特征等维度。目前版本模型在比较了Wide&Deep、DeepFM、AFM等常用模型后，考虑到计算性能及效果，最终选择了DeepFM作为初步的Base模型。整个DeepFM模型特征Embedding化后，在FM（Factorization Machine）基础上，进一步加入deep部分，分别针对稀疏及稠密特征做针对性融合。FM部分通过隐变量内积方式考虑一阶及二阶的特征融合，DNN部分通过Feed-Forward学习高阶特征融合。模型训练过程中采取了Learning Decay/Clip Gradient/求解器选择/Dropout/激活函数选择等，在此不做赘述。2.2 损失函数在ETA预估场景下，准时率及置信度是比较重要的业务指标。初步尝试将Square的损失函数换成Absolute的损失函数，从直观上更为切合MAE相比ME更为严苛的约束。在适当Learning Decay下，结果收敛且稳定。同时，在迭代中考虑到相同的ETA承诺时间下，在前后N分钟限制下，早到1min优于晚到1min，损失函数的设计希望整体的预估结果能够尽量前倾。对于提前部分，适当降低数值惩罚。对于迟到部分，适当增大数值惩罚。进行多次调试设计后，最终确定以前后N分钟以及原点作为3个分段点。在原先absolute函数优化的基础上，在前段设计1.2倍斜率absolute函数，后段设计1.8倍斜率absolute函数，以便让结果整体往中心收敛，且预估结果更倾向于提前送达，对于ETA各项指标均有较大幅度提升。2.3 业务规则融入模型目前的业务架构是"模型+规则"，在模型预估一个ETA值之后，针对特定业务场景，会有特定业务规则时间叠加以满足特定场景需求，各项规则由业务指标多次迭代产生。这里产生了模型和规则整体优化的割裂，在模型时间和规则时间分开优化后，即模型训练时并不能考虑到规则时间的影响，而规则时间在一年之中不同时间段，会产生不同的浮动，在经过一段时间重复迭代后，会加大割裂程度。在尝试了不同方案后，最终将整体规则写入到了TF模型中，在TF模型内部调整整体规则参数。对于简单的(ab+c)d等规则，可以将规则逻辑直接用TF的OP算子来实现，比如当b、d为定值时，则a、c为可学习的参数。对于过于复杂的规则部分，则可以借助一定的模型结构，通过模型的拟合来代替，过多复杂OP算子嵌套并不容易同时优化。通过调节不同的拟合部分及参数，将多个规则完全在TF模型中实现。最终对业务指标具备很大提升效果，且通过对部分定值参数的更改，具备部分人工干涉模型能力。在这里，整体架构就简化为多目标预估的架构，这里采用多任务架构中常用的Shared Parameters的结构，训练时按比例采取不同的交替训练策略。结构上从最下面的模型中间融合层出发，分别在TF内实现常规预测结构及多个规则时间结构，而其对应的Label则仍然从常规的历史值和规则时间值中来，这样考虑了以下几点：模型预估时，已充分考虑到规则对整体结果的影响（例如多个规则的叠加效应），作为整体一起考虑。规则时间作为辅助Label传入模型，对于模型收敛及Regularization，起到进一步作用。针对不同的目标预估，采取不同的Loss，方便进行针对性优化，进一步提升效果。模型结构在进行预估目标调整尝试中：尝试过固定共享网络部分及不固定共享部分参数，不固定共享参数效果明显。通常情况下激活函数差异不大，但在共享层到独立目标层中，不同的激活函数差异很大。2.4 缺失值处理在模型处理中，特征层面不可避免存在一定的缺失值，而对于缺失值的处理，完全借鉴了《美团“猜你喜欢”深度学习排序模型实践》文章中的方法。对于特征x进入TF模型，进行判断，如果是缺失值，则设置w1参数，如果不是缺失值则进入模型数值为w2*x，这里将w1和w2作为可学习参数，同时放入网络进行训练。以此方法来代替均值/零值等作为缺失值的方法。3.长尾问题优化3.1 模型预估结果+长尾规则补时基础模型学习的是整体的统计分布，但对于一些长尾情形的学习并不充分，体现在长尾情形下预估时间偏短（由于ETA拥有考核骑手的功能，预估偏短对骑手而言意味着很大的伤害）。故将长尾拆解成两部分来分析：业务长尾，即整体样本分布造成的长尾。主要体现在距离、价格等维度。距离越远，价格越高，实际送达时间越长，但样本占比越少，模型在这一部分上的表现整体都偏短。模型长尾，即由于模型自身对预估值的不确定性造成的长尾。模型学习的是整体的统计分布，但不是对每个样本的预估都有“信心”。实践中采用RF多棵决策树输出的标准差来衡量不确定性。RF模型生成的决策树是独立的，每棵树都可以看成是一个专家，多个专家共同打分，打分的标准差实际上就衡量了专家们的“分歧”程度（以及对预估的“信心”程度）。从下图也可以看出来，随着RF标准差的增加，模型的置信度和准时率均在下降。在上述拆解下，采用补时规则来解决长尾预估偏短的问题：长尾规则补时为 <业务长尾因子 , 模型长尾因子> 组合。其中业务长尾因子为距离、价格等业务因素，模型长尾因子为RF标准差。最终的ETA策略即为模型预估结果+长尾规则补时。4.工程开发实践4.1 训练部分实践整体训练流程对于线下训练，采取如下训练流程：Spark原始数据整合 -> Spark生成TFRecord -> 数据并行训练 -> TensorFlow Serving线下GPU评估 -> CPU Inference线上预测整个例行训练亿级数据多轮Epoch下流程持续约4小时，其中TF训练中，考虑到TF实际计算效率并不是很高，有很大比例在数据IO部分，通过Spark生成TFRecord部分，在此可将速度加速约3.6倍。而在数据并行训练部分，16卡内的并行度扩展基本接近线性，具备良好的扩展性。由于PS上参数量并未达到单机无法承受，暂时未对参数在PS上进行切分。Serving线下GPU评估部分，是整个流程中的非必需项，虽然在训练过程中Chief Worker设置Valid集合可有一定的指标，但对全量线下，通过Spark数据调用Serving GPU的评估具备短时间内完成全部流程能力，且可以指定大量复杂自定义指标。数据并行训练方式整个模型的训练在美团的AFO平台上进行，先后尝试分布式方案及单机多卡方案。考虑到生产及结果稳定性，目前线上模型生产采用单机多卡方案进行例行训练。分布式方案：采用TF自带的PS-Worker架构，异步数据并行方式，利用tf.train.MonitoredTrainingSession协调整个训练过程。整个模型参数存储于PS，每个Step上每个Worker拉取数据进行数据并行计算，同时将梯度返回，完成一次更新。目前的模型单Worker吞吐1~2W/s，亿级数据几轮Epoch耗时在几小时内完成。同时测试该模型在平台上的加速比，大约在16块内，计算能力随着Worker数目线性增加，16卡后略微出现分离。在目前的业务实践中，基本上4-6块卡可以短时间内完成例行的训练任务。单机多卡方案：采用PS-Worker的方案在平台上具备不错的扩展性，但是也存在一定的弊端，使用RPC的通讯很容易受到其他任务的影响，整个的训练过程受到最慢Worker的影响，同时异步更新方式对结果也存在一定的波动。对此，在线上生产中，最终选取单机多卡的方案，牺牲一定的扩展性，带来整体训练效果和训练速度的稳定性。单机多卡方案采取多GPU手动指定OP的Device，同时在各个Device内完成变量共享，最后综合Loss与梯度，将Grad更新到模型参数中。TF模型集成预处理模型训练过程中，ID类特征低频过滤需要用到Vocab词表，连续型特征都需要进行归一化。这里会产生大量的预处理文件，在线下处理流程中很容易在Spark中处理成Libsvm格式，然后载入到模型中进行训练。但是在线上预测时，需要在工程开发端载入多个词表及连续型特征的归一化预处理文件（avg/std值文件等），同时由于模型是按天更新，存在不同日期版本的对齐问题。为了简化工程开发中的难度，在模型训练时，考虑将所有的预处理文件写入TF计算图之中，每次在线预测只要输入最原始的特征，不经过工程预处理，直接可得到结果：对于ID类特征，需要进行低频过滤，然后制作成词表，TF模型读入词表的list_arr，每次inference通过ph_vals，得到对应词表的ph_idx。tf_look_up = tf.constant(list_arr, dtype=tf.int64)table = tf.contrib.lookup.HashTable(tf.contrib.lookup.KeyValueTensorInitializer(tf_look_up, idx_range), 0)ph_idx = table.lookup(ph_vals) + idx_bias对于连续型特征，在Spark处理完得到avg/std值后，直接写入TF模型计算图中，作为constant节点，每个ph_in经过两个节点，得到相应ph_out。constant_avg = tf.constant(feat_avg, dtype=tf.float32, shape=[feat_dim], name=“avg”)constant_std = tf.constant(feat_std, dtype=tf.float32, shape=[feat_dim], name=“std”)ph_out = (ph_in - constant_avg) / constant_std4.2 TF模型线上预测配送机器学习平台内置了模型管理平台，对算法训练产出的模型进行统一管理和调度，管理线上模型所用的版本，并支持模型版本的切换和回退，同时也支持节点模型版本状态的管理。ETA使用的DeepFM模型用TensorFlow训练，生成SavedModel格式的模型，需要模型管理平台支持Tensorflow SavedModel格式。实现方案S线上服务加载TensorFlow SavedModel模型有多种实现方案：自行搭建TensorFlow Serving CPU服务，通过gRPC API或RESTful API提供服务，该方案实现比较简单，但无法与现有的基于Thrift的模型管理平台兼容。使用美团AFO GPU平台提供的TensorFlow Serving服务。在模型管理平台中通过JNI调用TensorFlow提供的Java API TensorFlow Java API，完成模型管理平台对SavedModel格式的支持。最终采用TensorFlow Java API加载SavedModel在CPU上做预测，测试batch=1时预测时间在1ms以内，选择方案3作为实现方案。远程计算模式TensorFlow Java API的底层C++动态链接库对libstdc++.so的版本有要求，需要GCC版本不低于4.8.3，而目前线上服务的CPU机器大部分系统为CentOS 6, 默认自带GCC版本为4.4.7。如果每台线上业务方服务器都支持TensorFlow SavedModel本地计算的话，需要把几千台服务器统一升级GCC版本，工作量比较大而且可能会产生其他风险。因此，我们重新申请了几十台远程计算服务器，业务方服务器只需要把Input数据序列化后传给TensorFlow Remote集群，Remote集群计算完后再将Output序列化后返回给业务方。这样只需要对几十台计算服务器升级就可以了。线上性能模型上线后，支持了多个业务方的算法需求，远程集群计算时间的TP99基本上在5ms以内，可以满足业务方的计算需求。总结与展望模型落地并上线后，对业务指标带来较大的提升。后续将会进一步根据业务优化模型，进一步提升效果：将会进一步丰富多目标学习框架，将取餐、送餐、交付、调度等整个配送生命周期内的过程在模型层面考虑，对订单生命周期内多个目标进行建模，同时提升模型可解释性。模型融合特征层面的进一步升级，在Embedding以外，通过更多的LSTM/CNN/自设计结构对特征进行更好的融合。特征层面的进一步丰富。作者简介基泽，美团点评技术专家，目前负责配送算法策略部机器学习组策略迭代工作。周越，2017年加入美团配送事业部算法策略组，主要负责ETA策略开发。显杰，美团点评技术专家，2018年加入美团，目前主要负责配送算法数据平台深度学习相关的研发工作。 ...

春节已近，年味渐浓。又到了我们献上技术年货的时候。不久前，我们已经给大家分享了技术沙龙大套餐，汇集了过去一年我们线上线下技术沙龙99位讲师，85个演讲，70+小时分享。今天出场的，同样重磅——技术博客2018年大合集。2018年，是美团技术团队官方博客第5个年头，博客网站全年独立访问用户累计超过300万，微信公众号（meituantech）的关注数也超过了15万。由衷地感谢大家一直以来对我们的鼓励和陪伴！在2019年春节到来之际，我们再次精选了114篇技术干货，制作成一本厚达1200多页的电子书呈送给大家。这本电子书主要包括前端、后台、系统、算法、测试、运维、工程师成长等7个板块。疑义相与析，大家在阅读中如果发现Bug、问题，欢迎扫描文末二维码，通过微信公众号与我们交流。也欢迎大家转给有相同兴趣的同事、朋友，一起切磋，共同成长。最后祝大家，新春快乐，阖家幸福。如何获取？长按并识别下方的二维码，关注“美团技术团队”官方公众号，回复 “年货”，即可免费在线阅读、下载2018美团点评技术文章精选。温馨提示：我们提供了电子书的下载链接，大家可以选择性下载。2018美团点评技术年货合辑：1200+页，约350M；前端系列：共566页，约90M；后台系列：共229页，约60M；系统系列：共165页，约48M；算法系列：共183页，约56M；运维系列：共140页，约36M；测试系列：共88页，约28M；工程师成长系列：共49页，约16M。备注：因文件较大，缓存需要一定的时间，需要您的一点耐心，请注意自己的流量。Android系统用户建议通过WiFi环境下载。iOS系统用户建议将地址复制到PC端，使用浏览器进行下载。

背景建立的代码规范没人遵守，项目中遍地风格迥异的代码，你会不会抓狂？通过测试用例的程序还会出现Bug，而原因仅仅是自己犯下的低级错误，你会不会抓狂？某种代码写法存在问题导致崩溃时，只能全工程检查代码，这需要人工花费大量时间Review代码，你会不会抓狂？以上这些问题，可以通过静态检查有效地缓解！静态检查（Static Program Analysis）主要是以不运行程序的方式对于程序源代码进行检查分析的技术，而与之相反的就是动态检查（Dynamic Program Analysis），通过实际运行程序输入测试数据产生预期结果的技术。通过代码静态检查，我们可以快速定位代码的错误与缺陷，可以减少逐行阅读代码浪费的时间，可以（根据需要）快速扫描代码中可能存在的漏洞等。代码静态检查可以在代码的规范性、安全性、可靠性、可维护性等方面起到重要作用。在客户端中，Android可以使用CheckStyle、Lint、Findbugs、PMD等工具，iOS可以使用Clang Static Analyzer、OCLint等工具。而在React Native的开发过程中，针对于JavaScript的ESLint，与TypeScript的TSLint，则成为了主要代码静态检查的工具。本文将按照使用TSLint的原因、使用TSLint的方法、自定义TSLint的步骤进行探究分析。一、使用TSLint的原因在客户端团队进入React Native项目的开发过程中，面临着如下问题：由于大家从客户端转入到React Native开发过程中，容易出现低级语法错误；开发者之前从事Android、iOS、前端等工作，因此代码风格不同，导致项目代码风格不统一；客户端效果不一致，有可能Android端显示正常、iOS端显示异常，或者相反的情况出现。虽然以上问题可以通过多次不断将雷点标记出，并不断地分享经验与强化代码Review过程等方式来进行缓解，但是仍面临着React Native开发者掌握的技术水平千差万别，知识分享传播的速度缓慢等问题，既导致了开发成本的不断增加和开发效率持续低下的问题，还难以避免一个坑被踩了多次的情况出现。这时急需一款可以满足以下目标的工具：可检测代码低级语法错误；规范项目代码风格；根据需要可自定义检查代码的逻辑；工具使用者可以“傻瓜式”的接入部署到开发IDE环境；可以快速高效地将检查工具最新检查逻辑同步到开发IDE环境中；对于检查出的问题可以快速定位。根据上述要求的描述，静态检查工具TSLint可以较为有效地达成目标。二、TSLint介绍TSLint是硅谷企业Palantir的一个项目，它是一款可以检查TypeScript代码可读性、可维护性以及功能性错误的静态检查工具，当前许多编辑器（Editors）和构建系统（Build Systems）支持这一工具，同时支持自定义编写Lint规则、配置、格式化等。当前TSLint已经包含了上百条规则，这些规则构筑了当前TSLint检查的基础。在代码开发阶段中，通过这些配置好的规则可以给工程一个完整的检查，并随时可以提示出可能存在的问题。本文内容参考了TSLint官方文档https://palantir.github.io/tslint/。2.1 TSLint常见规则以下规则主要来源于TSLint规则，是某些规则的简单介绍。2.2 常用TSLint规则包上述2.1所列出的规则来源于Palantir官方TSLint规则。实际还有多种，可能会用到的有以下：我们在项目的规则配置过程中，一般采用上述规则包其中一种或者若干种同时配置，那如何配置呢？请看下文。三、如何进行TSLint规则配置与检查首先，在工程package.json文件中配置TSLint包：在根目录中的tslint.json文件中可以根据需要配置已有规则，例如：其中extends数组内放置继承的TSLint规则包，上图包括了airbnb配置的规则包、tslint-react的规则包，而rules用于配置规则的开关。TSLint规则目前只有true和false的选项，这导致了结果要么正常，要么报错ERROR，而不会出现WARNING等警告。有些时候，虽然配置某些规则开启，但是某个文件内可能会关闭某些甚至全部规则检查，这时候可以通过规则注释来配置，如：/* tslint:disable /上述注释表示本文件自此注释所在行开始，以下的所有区域关闭TSLint规则检查。/ tslint:enable /上述注释表示本文件自此注释所在行开始，以下的所有区域开启TSLint规则检查。/ tslint:disable:rule1 rule2 rule3… /上述注释表示本文件自此注释所在行开始，以下的所有区域关闭规则rule1 rule2 rule3…的检查。/ tslint:enable:rule1 rule2 rule3… /上述注释表示本文件自此注释所在行开始，以下的所有区域开启规则rule1 rule2 rule3…的检查。// tslint:disable-next-line上述注释表示此注释所在行的下一行关闭TSLint规则检查。someCode(); // tslint:disable-line上述注释表示此注释所在行关闭TSLint规则检查。// tslint:disable-next-line:rule1 rule2 rule3…上述注释表示此注释所在行的下一行关闭规则rule1 rule2 rule3…的检查检查。以上配置信息，这里具体参考了https://palantir.github.io/tslint/usage/rule-flags/。3.1 本地检查在完成工程配置后，需要下载所需要依赖包，要在工程所在根目录使用npm install命令完成下载依赖包。IDE环境提示在完成下载依赖包后，IDE环境可以根据对应配置文件进行提示，可以实时地提示出存在问题代码的错误信息，以VSCode为例：本地命令检查VSCode目前还有继续完善的空间，如果部分文件未在窗口打开的情况下，可能存在其中错误未提示出的情况，这时候，我们可以通过本地命令进行全工程的检查，在React Native工程的根目录下，通过以下命令行执行：tslint –project tsconfig.json –config tslint.json（此命令如果不正确运行，可在之前加入./node_modules/.bin/）即为：./node_modules/.bin/tslint –project tsconfig.json –config tslint.json从而会提示出类似以下错误的信息：src/Components/test.ts[1, 7]: Class name must be in pascal case3.2 在线CI检查本地进行代码检查的过程也会存在被人遗忘的可能性，通过技术的保障，可以避免人为遗忘，作为代码提交的标准流程，通过CI检查后再合并代码，可以有效避免代码错误的问题。CI系统可以为理解为一个云端的环境，环境配置与本地一致，在这种情况下，可以生成与本地一致的报告，在美团内部可以使用基于Jenkins的Castle CI系统， 生成结果与本地结果一致：3.3 其他方式代码检查不止局限上述阶段，在代码commit、pull request、打包等阶段均可触发。代码commit阶段，通过Hook方式可以触发代码检查，可以有效地将在线CI检查阶段强制提前，基本保证了在线CI检查的完全正确性。代码pull request阶段，通过在线CI检查可以触发代码检查，可以有效保证合入分支尤其是主分支的正确性。代码打包阶段，通过在线CI检查可以触发代码检查，可以有效保证打包代码的正确性。四、自定义编写TSLint规则4.1 为什么要自定义TSLint规则当前的TSLint规则虽然涵盖了比较普遍问题的一些代码检查，但是实践中还是存在一些问题的：团队中的个性化需求难以满足。例如，saga中的异步函数需要在最外层加try-catch，且catch块中需要加异常上报，这个明显在官方的TSLint规则无法实现，为此需要自定义的开发。官方规则的开启与配置不符合当前团队情况。基于以上原因其他团队也有自定义TSLint的先例，例如上文提到的tslint-microsoft-contrib、tslint-eslint-rules等。4.2 自定义规则步骤那自定义TSLint大概需要什么步骤呢，首先规则文件根据规范进行按部就班的编写规则信息，然后根据代码检查逻辑对语法树进行分析并编写逻辑代码，这也是自定义规则的核心部分了，最后就是自定义规则的使用了。自定义规则的示例直接参考官方的规则是最直接的，我们能这里参考一个比较简单的规则"class-name"。“class-name"规则上文已经提到，它的意思是对类命名进行规范，当团队中类相关的命名不规范，会导致项目代码风格不统一甚至其他出现的问题，而"class-name"规则可以有效解决这个问题。我们可以看下具体的源码文件：https://github.com/palantir/tslint/blob/master/src/rules/classNameRule.ts。然后将分步对此自定义规则进行讲解。第一步，文件命名规则命名必须是符合以下2个规则：驼峰命名。以’Rule’为后缀。第二步，类命名规则的类名是Rule，并且要继承Lint.Rules.AbstractRule这个类型，当然也可能有继承TypedRule这个类的时候，但是我们通过阅读源码发现，其实它也是继承自Lint.Rules.AbstractRule这个类。第三步，填写metadata信息metadata包含了配置参数，定义了规则的信息以及配置规则的定义。ruleName 是规则名，使用烤串命名法，一般是将类名转为烤串命名格式。description 一个简短的规则说明。descriptionDetails 详细的规则说明。rationale 理论基础。options 配置参数形式，如果没有可以配置为null。optionExamples 参数范例 ，如没有参数无需配置。typescriptOnly true/false 是否只适用于TypeScript。hasFix true/false 是否带有修复方式。requiresTypeInfo 是否需要类型信息。optionsDescrition options的介绍。type 规则的类型。规则类型有四种，分别为：“functionality”、“maintainability”、“style”、“typescript”。functionality ： 针对于语句问题以及功能问题。maintainability：主要以代码简洁、可读、可维护为目标的规则。style：以维护代码风格基本统一的规则。typescript：针对于TypeScript进行提示。第四步，定义错误提示信息这个主要是在检查出问题的时候进行提示的文字，并不局限于使用一个静态变量的形式，但是大部分官方规则都是这么编写，这里对此进行介绍，防止引起歧义。第五步，实现apply方法apply主要是进行静态检查的核心方法，通过返回applyWithFunction方法或者返回applyWithWalker来进行代码检查，其实applyWithFunction方法与applyWithWalker方法的主要区别在于applyWithWalker可以通过IWalker实现一个自定义的IWaker类，区别如下：其中实现IWaker的抽象类AbstractWalker里面也继承了WalkContext，而这个WalkContext就是上面提到的applyWithFunction的内部实现类。第六步，语法树解析无论是applyWithFunction方法还是applyWithWalker方法中的IWaker实现都传入了sourceFile这个参数，这个相当于文件的根节点，然后通过ts.forEachChild方法遍历整个语法树节点。这里有两个查看AST语法树的工具：AST Explorer：https://astexplorer.net/ 对应源码：https://github.com/fkling/astexplorerTypeScript AST Viewer：https://ts-ast-viewer.com/ 对应源码：https://github.com/dsherret/ts-ast-viewerAST Explorer优点：在AST Explorer可以高亮显示所选中代码对应的AST语法树信息。缺点：不能选择对应版本的解析器，导致显示的语法树代码版本固定。语法树显示的信息相对较少。TypeScript AST Viewer优点：解析器对应版本可以动态选择：语法树显示的信息不仅显示对应的数字代码，还可为对应的实际信息：每个版本对应对kind信息数值可能会变动，但是对应的枚举名字是固定的，如下图：从而这个工具可以避免频繁根据其数值查找对应信息。缺点： 不能高亮显示代码对应的AST语法树区域，定位效率较低。综上，通过同时使用上述两个工具定位分析，可以有效地提高分析效率。第七步，检查规则代码编写通过ts.forEachChild方法对于语法树所有的节点进行遍历，在遍历的方法里可以实现自己的逻辑，其中节点的类为ts.Node：其中kind为当前节点的类型，当然Node是所有节点的基类，它的实现还包括Statement、Expression、Declaration等，回到开头这个"class-name"规则，我们的所有声明类主要是class与interface关键字，分别对应ClassExpression、ClassDeclaration、InterfaceDeclaration，我们可以通过上步提到的AST语法树工具，在语法树中看到其为一一对应的。在规则代码中主要通过isClassLikeDeclaration、isInterfaceDeclaration这两个方法进行判断的。其中isClassLikeDeclaration、isInterfaceDeclaration对应的方法我们可以在node.js文件中找到：判断是对应的类型时，调用addFailureAtNode方法把错误信息和节点传入，当然还可以调用addFailureAt、addFailure方法。最终这个规则编写结束了，有一点再次强调下，因为每个版本所对应的类型代码可能不相同，当判断kind的时候，一定不要直接使用各个类型对应的数字。第八步，规则配置使用完成规则代码后，是ts后缀的文件，而ts规则文件实际还是要用js文件，这时候我们需要用命令将ts转化为js文件：tsc ./src/.ts –outDir dist将ts规则生成到dist文件夹（这个文件夹命名用户自定），然后在tslint.json文件中配置生成的规则文件即可。之后在项目的根目录里面，使用以下命令既可进行检查：tslint –project tsconfig.json –config tslint.json同时为了未来新增规则以及规则配置的更好的操作性，建议可以封装到自己的规则包，以便与规则的管理与传播。总结TSLint的优点：速度快。相对于动态代码检查，检查速度较快，现有项目无论是在本地检查，还是在CI检查，对于由十余个页面组成的React Native工程，可以在1到2分钟内完成；灵活。通过配置规则，可以有效地避免常见代码错误与潜在的Bug；易扩展。通过编写配置自定义规则，可以及时准确快速查找出代码中特定风险点。TSLint缺点：规则的结果只有对与错两种等级结果，没有警告等级的的提示结果；无法直接报告规则报错数量，只能依赖其他手段统计；TSLint规则针对于当前单一文件可以有效地通过语法树进行分析判定，但对于引用到的其他文件中的变量、类、方法等，则难以通过AST语法树进行判定。使用结果及分析在美团，有十余个页面的单个工程首次接入TSLint后，检查出的问题有近百条。但是由于开启的规则不同，配置规则包的差异，检查后的数量可能为几十条到几千条甚至更多。现在已开发十余条自定义规则，在单个工程内，处理优化了数百处可能存在问题的代码。最终TSLint接入了相关React Native开发团队，成为了代码提交阶段的必要步骤。通过团队内部的验证，文章开头遇到的问题得到了有效地缓解，目标基本达到预期。TSLint在React Native开发过程中既保证了代码风格的统一，又保证了React Native开发人员的开发质量，避免了许多低级错误，有效地节省了问题排查和人员沟通的成本。同时利用自定义规则，能够将一些兼容性问题在内的个性化问题进行总结与预防，提高了开发效率，不用花费大量时间查找问题代码，又避免了在一个问题上跌倒多次的情况出现。对于不同经验的开发者而言，不仅可以进行友好的提示，也可以帮助快速地定位问题，将一个人遇到的经验教训，用极低的成本扩散到其他团队之中，将开发状态从“亡羊补牢”进化到“防患未然”。作者简介家正，美团点评Android高级工程师。2017 年加入美团点评，负责美团大交通的业务开发。 ...

引言挑战与思路搜索是大众点评App上用户进行信息查找的最大入口，是连接用户和信息的重要纽带。而用户搜索的方式和场景非常多样，并且由于对接业务种类多，流量差异大，为大众点评搜索（下文简称点评搜索）带来了巨大的挑战，具体体现在如下几个方面：意图多样：用户查找的信息类型和方式多样。信息类型包括POI、榜单、UGC、攻略、达人等。以找店为例，查找方式包括按距离、按热度、按菜品和按地理位置等多种方式。例如用户按照品牌进行搜索时，大概率是需要寻找距离最近或者常去的某家分店；但用户搜索菜品时，会对菜品推荐人数更加敏感，而距离因素会弱化。业务多样：不同业务之间，用户的使用频率、选择难度以及业务诉求均不一样。例如家装场景用户使用频次很低，行为非常稀疏，距离因素弱，并且选择周期可能会很长；而美食多为即时消费场景，用户行为数据多，距离敏感。用户类型多样：不同的用户对价格、距离、口味以及偏好的类目之间差异很大；搜索需要能深度挖掘到用户的各种偏好，实现定制化的“千人千面”的搜索。LBS的搜索：相比电商和通用搜索，LBS的升维效应极大地增加了搜索场景的复杂性。例如对于旅游用户和常驻地用户来说，前者在搜索美食的时候可能会更加关心当地的知名特色商户，而对于距离相对不敏感。上述的各项特性，叠加上时间、空间、场景等维度，使得点评搜索面临比通用搜索引擎更加独特的挑战。而解决这些挑战的方法，就需要升级NLP（Natural Language Processing，自然语言处理）技术，进行深度查询理解以及深度评价分析，并依赖知识图谱技术和深度学习技术对搜索架构进行整体升级。在美团NLP中心以及大众点评搜索智能中心两个团队的紧密合作之下，经过短短半年时间，点评搜索核心KPI在高位基础上仍然大幅提升，是过去一年半涨幅的六倍之多，提前半年完成全年目标。基于知识图谱的搜索架构重塑美团NLP中心正在构建全世界最大的餐饮娱乐知识图谱——美团大脑（相关信息请参见《美团大脑：知识图谱的建模方法及其应用》）。它充分挖掘关联各个场景数据，用NLP技术让机器“阅读”用户公开评论，理解用户在菜品、价格、服务、环境等方面的喜好，构建人、店、商品、场景之间的知识关联，从而形成一个“知识大脑”[1]。通过将知识图谱信息加入到搜索各个流程中，我们对点评搜索的整体架构进行了升级重塑，图1为点评搜索基于知识图谱搭建的5层搜索架构。本篇文章是“美团大脑”系列文章第二篇（系列首篇文章请参见《美团餐饮娱乐知识图谱——美团大脑揭秘》)，主要介绍点评搜索5层架构中核心排序层的演变过程，文章主要分为如下3个部分：核心排序从传统机器学习模型到大规模深度学习模型的演进。搜索场景深度学习排序模型的特征工程实践。适用于搜索场景的深度学习Listwise排序算法——LambdaDNN。2. 排序模型探索与实践搜索排序问题在机器学习领域有一个单独的分支，Learning to Rank（L2R）。主要分类如下:根据样本生成方法和Loss Function的不同，L2R可以分为Pointwise、Pairwise、Listwise。按照模型结构划分，可以分为线性排序模型、树模型、深度学习模型，他们之间的组合（GBDT+LR，Deep&Wide等）。在排序模型方面，点评搜索也经历了业界比较普遍的迭代过程：从早期的线性模型LR，到引入自动二阶交叉特征的FM和FFM，到非线性树模型GBDT和GBDT+LR，到最近全面迁移至大规模深度学习排序模型。下面先简单介绍下传统机器学习模型（LR、FM、GBDT）的应用和优缺点，然后详细介绍深度模型的探索实践过程。传统机器学习模型LR可以视作单层单节点的线性网络结构。模型优点是可解释性强。通常而言，良好的解释性是工业界应用实践比较注重的一个指标，它意味着更好的可控性，同时也能指导工程师去分析问题优化模型。但是LR需要依赖大量的人工特征挖掘投入，有限的特征组合自然无法提供较强的表达能力。FM可以看做是在LR的基础上增加了一部分二阶交叉项。引入自动的交叉特征有助于减少人工挖掘的投入，同时增加模型的非线性，捕捉更多信息。FM能够自动学习两两特征间的关系，但更高量级的特征交叉仍然无法满足。GBDT是一个Boosting的模型，通过组合多个弱模型逐步拟合残差得到一个强模型。树模型具有天然的优势，能够很好的挖掘组合高阶统计特征，兼具较优的可解释性。GBDT的主要缺陷是依赖连续型的统计特征，对于高维度稀疏特征、时间序列特征不能很好的处理。深度神经网络模型随着业务的发展，在传统模型上取得指标收益变得愈发困难。同时业务的复杂性要求我们引入海量用户历史数据，超大规模知识图谱特征等多维度信息源，以实现精准个性化的排序。因此我们从2018年下半年开始，全力推进L2核心排序层的主模型迁移至深度学习排序模型。深度模型优势体现在如下几个方面：强大的模型拟合能力：深度学习网络包含多个隐藏层和隐藏结点，配合上非线性的激活函数，理论上可以拟合任何函数，因此十分适用于点评搜索这种复杂的场景。强大的特征表征和泛化能力：深度学习模型可以处理很多传统模型无法处理的特征。例如深度网络可以直接中从海量训练样本中学习到高维稀疏ID的隐含信息，并通过Embedding的方式去表征；另外对于文本、序列特征以及图像特征，深度网络均有对应的结构或者单元去处理。自动组合和发现特征的能力：华为提出的DeepFM，以及Google提出的DeepCrossNetwork可以自动进行特征组合，代替大量人工组合特征的工作。下图是我们基于Google提出的Wide&Deep模型搭建的网络结构[2]。其中Wide部分输入的是LR、GBDT阶段常用的一些细粒度统计特征。通过较长周期统计的高频行为特征，能够提供很好的记忆能力。Deep部分通过深层的神经网络学习Low-Order、高纬度稀疏的Categorical型特征，拟合样本中的长尾部分，发现新的特征组合，提高模型的泛化能力。同时对于文本、头图等传统机器学习模型难以刻画的特征，我们可以通过End-to-End的方式，利用相应的子网络模型进行预处理表示，然后进行融合学习。3. 搜索深度排序模型的特征工程实践深度学习的横空出世，将算法工程师从很多人工挖掘和组合特征的事情中解放出来。甚至有一种论调，专做特征工程的算法工程师可能面临着失业的风险。但是深度学习的自动特征学习目前主要集中体现在CV领域，CV领域的特征数据是图片的像素点——稠密的低阶特征，深度学习通过卷积层这个强力工具，可以自动对低阶特征进行组合和变换，相比之前人工定义的图像特征从效果上来说确实更加显著。在NLP领域因为Transformer的出现，在自动特征挖掘上也有了长足的进步，BERT利用Transformer在多个NLP Task中取得了State-of-The-Art的效果。但是对于CTR预估和排序学习的领域，目前深度学习尚未在自动特征挖掘上对人工特征工程形成碾压之势，因此人工特征工程依然很重要。当然，深度学习在特征工程上与传统模型的特征工程也存在着一些区别，我们的工作主要集中在如下几个方面。3.1 特征预处理特征归一化：深度网络的学习几乎都是基于反向传播，而此类梯度优化的方法对于特征的尺度非常敏感。因此，需要对特征进行归一化或者标准化以促使模型更好的收敛。特征离散化：工业界一般很少直接使用连续值作为特征，而是将特征离散化后再输入到模型中。一方面因为离散化特征对于异常值具有更好的鲁棒性，其次可以为特征引入非线性的能力。并且，离散化可以更好的进行Embedding，我们主要使用如下两种离散化方法：等频分桶：按样本频率进行等频切分，缺失值可以选择给一个默认桶值或者单独设置分桶。树模型分桶：等频离散化的方式在特征分布特别不均匀的时候效果往往不好。此时可以利用单特征结合Label训练树模型，以树的分叉点做为切分值，相应的叶子节点作为桶号。特征组合：基于业务场景对基础特征进行组合，形成更丰富的行为表征，为模型提供先验信息，可加速模型的收敛速度。典型示例如下：用户性别与类目之间的交叉特征，能够刻画出不同性别的用户在类目上的偏好差异，比如男性用户可能会较少关注“丽人”相关的商户。时间与类目之间的交叉特征，能够刻画出不同类目商户在时间上的差异，例如，酒吧在夜间会更容易被点击。3.2 万物皆可Embedding深度学习最大的魅力在于其强大的特征表征能力，在点评搜索场景下，我们有海量的用户行为数据，有丰富的商户UGC信息以及美团大脑提供的多维度细粒度标签数据。我们利用深度学习将这些信息Embedding到多个向量空间中，通过Embedding去表征用户的个性化偏好和商户的精准画像。同时向量化的Embedding也便于深度模型进一步的泛化、组合以及进行相似度的计算。3.2.1 用户行为序列的Embedding用户行为序列（搜索词序列、点击商户序列、筛选行为序列）包含了用户丰富的偏好信息。例如用户筛选了“距离优先”时，我们能够知道当前用户很有可能是一个即时消费的场景，并且对距离较为敏感。行为序列特征一般有如下图所示的三种接入方式:Pooling：序列Embedding后接入Sum/Average Pooling层。此方式接入成本低，但忽略了行为的时序关系。RNN：LSTM/GRU接入，利用循环网络进行聚合。此方式能够考虑行为序列的时序关系；代价是增大了模型复杂度，影响线上预测性能。Attention：序列Embedding后引入Attention机制，表现为加权的Sum Pooling；相比LSTM/GRU计算开销更低[4]。同时，为了突显用户长期偏好和短期偏好对于排序的不同影响，我们按照时间维度对行为序列进行了划分：Session、半小时、一天、一周等粒度，也在线上取得了收益。3.2.2 用户ID的Embedding一种更常见的刻画用户偏好的方式，是直接将用户ID经过Embedding后作为特征接入到模型中，但是最后上线的效果却不尽如人意。通过分析用户的行为数据，我们发现相当一部分用户ID的行为数据较为稀疏，导致用户ID的Embedding没有充分收敛，未能充分刻画用户的偏好信息。Airbnb发表在KDD 2018上的文章为这种问题提供了一种解决思路[9]——利用用户基础画像和行为数据对用户ID进行聚类。Airbnb的主要场景是为旅游用户提供民宿短租服务，一般用户一年旅游的次数在1-2次之间，因此Airbnb的用户行为数据相比点评搜索会更为稀疏一些。如上图所示，将用户画像特征和行为特征进行离散分桶，拼接特征名和所属桶号，得到的聚类ID为：US_lt1_pn3_pg3_r3_5s4_c2_b1_bd2_bt2_nu3。我们也采取了类似Airbnb的方案，稀疏性的问题得到了很好的解决，并且这样做还获得了一些额外的收益。点评搜索作为一个本地化的生活信息服务平台，大部分用户的行为都集中自己的常驻地，导致用户到达一个新地方时，排序个性化明显不足。通过这种聚类的方式，将异地有相同行为的用户聚集在一起，也能解决一部分跨站的个性化问题。3.2.3 商户信息Embedding商户Embedding除了可以直接将商户ID加入模型中之外，美团大脑也利用深度学习技术对UGC进行大量挖掘，对商家的口味、特色等细粒度情感进行充分刻画，例如下图所示的“好停车”、“菜品精致”、“愿意再次光顾”等标签。这些信息与单纯的商户星级、点评数相比，刻画的角度更多，粒度也更细。我们将这些标签也进行Embedding并输入到模型中：直连：将标签特征做Pooling后直接输入模型。这种接入方式适合端到端的学习方式；但受输入层大小限制，只能取Top的标签，容易损失抽象实体信息。分组直连：类似于直连接入的方式，但是先对标签进行分类，如菜品/风格/口味等类别；每个分类取Top N的实体后进行Pooling生成不同维度的语义向量。与不分组的直连相比，能够保留更多抽象信息。子模型接入：可以利用DSSM模型，以标签作为商户输入学习商户的Embedding表达。此种方式能够最大化保留标签的抽象信息，但是线上实现和计算成本较高。3.2.4 加速Embedding特征的收敛在我们的深度学习排序模型中，除了Embedding特征，也存在大量Query、Shop和用户维度的强记忆特征，能够很快收敛。而Embedding特征是更为稀疏的弱特征，收敛速度较慢，为了加速Embedding特征的收敛，我们尝试了如下几种方案：低频过滤：针对出现频率较低的特征进行过滤，可以很大程度上减少参数量，避免过拟合。预训练：利用多类模型对稀疏Embedding特征进行预训练，然后进入模型进行微调：通过无监督模型如Word2vec、Fasttext对用户-商户点击关系建模，生成共现关系下的商户Embedding。利用DSSM等监督模型对Query-商户点击行为建模得到Query和商户的Embedding。Multi-Task：针对稀疏的Embedding特征，单独设置一个子损失函数，如下图所示。此时Embedding特征的更新依赖两个损失函数的梯度，而子损失函数脱离了对强特征的依赖，可以加快Embedding特征的收敛。3.3 图片特征图片在搜索结果页中占据了很大的展示面积，图片质量的好坏会直接影响用户的体验和点击，而点评商户首图来自于商户和用户上传的图片，质量参差不齐。因此，图片特征也是排序模型中较为重要的一类。目前点评搜索主要用了以下几类图片特征：基础特征：提取图片的亮度、色度饱和度等基础信息，进行特征离散化后得到图片基础特征。泛化特征：使用ResNet50进行图片特征提取[3]，通过聚类得到图片的泛化特征。质量特征：使用自研的图片质量模型，提取中间层输出，作为图片质量的Embedding特征。标签特征：提取图片是否是食物、环境、价目表、Logo等作为图片分类和标签特征。4. 适用于搜索场景的深度学习Listwise排序算法—LambdaDNN4.1 搜索业务指标与模型优化目标的Gap通常模型的预测目标与业务指标总会存在一些Gap。如果模型的预测目标越贴近业务目标，越能保证模型优化的同时业务指标也能够有相应的提升；反之则会出现模型离线指标提升，但线上关键业务指标提升不明显，甚至出现负向的问题。工业届大部分深度学习排序采用Pointwise的Log Loss作为损失函数，与搜索业务指标有较大的Gap。体现在如下两个方面：搜索业务常用的指标有QV_CTR或者SSR(Session Success Rate)，更关心的是用户搜索的成功率（有没有发生点击行为）；而Pointwise的Log Loss更多是关注单个Item的点击率。搜索业务更关心排在页面头部结果的好坏，而Pointwise的方法则对于所有位置的样本一视同仁。基于上述理由，我们对于深度学习模型的损失函数进行了优化。4.2 优化目标改进-从Log Loss到NDCG为了让排序模型的优化目标尽量贴近搜索业务指标，需要按照Query计算损失，且不同位置的样本具有不同的权重。搜索系统常用的指标NDCG(Normalized Discounted Cumulative Gain)相较于Log Loss显然更贴近搜索业务的要求，NDCG计算公式如下：累加部分为DCG(Discounted Cumulative Gain)表示按照位置折损的收益，对于Query下的结果列表l，函数G表示对应Doc的相关度分值，通常取指数函数，即G(lj)=2lj-1（lj表示的是相关度水平，如{0，1，2}）；函数 即位置折损，一般采用 (j)=1/log(j+1)，Doc与Query的相关度越高且位置越靠前则DCG值会越大。另外，通常我们仅关注排序列表页前k位的效果，Zk 表示 DCG@k 的可能最大值，以此进行归一化处理后得到的就是NDCG@k。问题在于NDCG是一个处处非平滑的函数，直接以它为目标函数进行优化是不可行的。LambdaRank提供了一种思路：绕过目标函数本身，直接构造一个特殊的梯度，按照梯度的方向修正模型参数，最终能达到拟合NDCG的方法[6]。因此，如果我们能将该梯度通过深度网络进行反向传播，则能训练一个优化NDCG的深度网络，该梯度我们称之为Lambda梯度，通过该梯度构造出的深度学习网络称之为LambdaDNN。要了解Lambda梯度需要引入LambdaRank。LambdaRank模型是通过Pairwise来构造的，通常将同Query下有点击样本和无点击样本构造成一个样本Pair。模型的基本假设如下式所示，令Pij为同一个Query下Doci相比Docj更相关的概率，其中si和sj分别为Doci和Docj的模型得分：使用交叉熵为损失函数，令Sij表示样本Pair的真实标记，当Doci比Docj更相关时（即Doci有被用户点击，而Docj没有被点击），有Sij=1，否则为-1；则损失函数可以表示为：在构造样本Pair时，我们可以始终令i为更相关的文档，此时始终有Sij≡1，代入上式并进行求导，则损失函数的梯度为：到目前为止，损失函数的计算过程中并未考虑样本所在的位置信息。因此进一步对梯度进行改造，考虑Doci和Docj交换位置时的NDCG值变化，下式即为前述的Lambda梯度。可以证明，通过此种方式构造出来的梯度经过迭代更新，最终可以达到优化NDCG的目的。Lambda梯度的物理意义如下图所示。其中蓝色表示更相关（用户点击过）的文档，则Lambda梯度更倾向于位置靠上的Doc得到的提升更大（如红色箭头所示）。有了Lambda梯度的计算方法，训练中我们利用深度网络预测同Query下的Doc得分，根据用户实际点击Doc的情况计算Lambda梯度并反向传播回深度网络，则可以得到一个直接预测NDCG的深度网络。4.3 LambdaDNN的工程实施我们利用TensorFlow分布式框架训练LambdaDNN模型。如前文所述，Lambda梯度需要对同Query下的样本进行计算，但是正常情况下所有的样本是随机Shuffle到各个Worker的。因此我们需要对样本进行预处理：通过QueryId进行Shuffle，将同一个Query的样本聚合在一起，同一个Query的样本打包进一个TFRecord。由于每次请求Query召回的Doc数不一样，对于可变Size的Query样本在拉取数据进行训练时需要注意，TF会自动补齐Mini-Batch内每个样本大小一致，导致输入数据中存在大量无意义的默认值样本。这里我们提供两点处理方式：MR过程中对Key进行处理，使得多个Query的样本聚合在一起，然后在训练的时候进行动态切分。读取到补齐的样本，根据设定的补齐标记获取索引位，去除补齐数据。为了提升训练效率，我们与基础研发平台数据平台中心紧密协同，一起探索并验证了多项优化操作：将ID类特征的映射等操作一并在预处理中完成，减少多轮Training过程中的重复计算。将样本转TfRecord，利用RecordDataSet方式读取数据并计算处理，Worker的计算性能大概提升了10倍。Concat多个Categorical特征，组合成Multi-Hot的Tensor进行一次Embedding_Lookup操作，减少Map操作的同时有助于参数做分片存储计算。稀疏Tensor在计算梯度以及正则化处理时保留索引值，仅对有数值的部分进行更新操作。多个PS服务器间进行分片存储大规模Tensor变量，减少Worker同步更新的通讯压力，减少更新阻塞，达到更平滑的梯度更新效果。整体下来，对于30亿左右的样本量、上亿级别的特征维度，一轮迭代大概在半小时内完成。适当的增加并行计算的资源，可以达到分钟级的训练任务。4.4 进一步改进优化目标NDCG的计算公式中，折损的权重是随着位置呈指数变化的。然而实际曝光点击率随位置变化的曲线与NDCG的理论折损值存在着较大的差异。对于移动端的场景来说，用户在下拉滑动列表进行浏览时，视觉的焦点会随着滑屏、翻页而发生变动。例如用户翻到第二页时，往往会重新聚焦，因此，会发现第二页头部的曝光点击率实际上是高于第一页尾部位置的。我们尝试了两种方案去微调NDCG中的指数位置折损：根据实际曝光点击率拟合折损曲线：根据实际统计到的曝光点击率数据，拟合公式替代NDCG中的指数折损公式，绘制的曲线如图12所示。计算Position Bias作为位置折损：Position Bias在业界有较多的讨论，其中7将用户点击商户的过程分为观察和点击两个步骤：a.用户需要首先看到该商户，而看到商户的概率取决于所在的位置；b.看到商户后点击商户的概率只与商户的相关性有关。步骤a计算的概率即为Position Bias，这块内容可以讨论的东西很多，这里不再详述。经过上述对NDCG计算改造训练出的LambdaDNN模型，相较Base树模型和Pointwise DNN模型，在业务指标上有了非常显著的提升。4.5 Lambda深度排序框架Lambda梯度除了与DNN网络相结合外，事实上可以与绝大部分常见的网络结构相结合。为了进一步学习到更多交叉特征，我们在LambdaDNN的基础上分别尝试了LambdaDeepFM和LambdaDCN网络；其中DCN网络是一种加入Cross的并行网络结构，交叉的网络每一层的输出特征与第一层的原始输入特征进行显性的两两交叉，相当于每一层学习特征交叉的映射去拟合层之间的残差。离线的对比实验表明，Lambda梯度与DCN网络结合之后充分发挥了DCN网络的特点，简洁的多项式交叉设计有效地提升模型的训练效果。NDCG指标对比效果如下图所示：5. 深度学习排序诊断系统深度学习排序模型虽然给业务指标带来了大幅度的提升，但由于深度学习模型的“黑盒属性”导致了巨大的解释性成本，也给搜索业务带来了一些问题：日常搜索Bad Case无法快速响应：搜索业务日常需要应对大量来自于用户、业务和老板们的“灵魂拷问”，“为何这个排序是这样的”，“为什么这家商户质量跟我差不多，但是会排在我的前面”。刚切换到深度学习排序模型的时候，我们对于这样的问题显得手足无措，需要花费大量的时间去定位问题。无法从Bad Case中学习总结规律持续优化：如果不明白为什么排序模型会得出一个很坏的排序结果，自然也无法定位模型到底出了什么问题，也就无法根据Bad Case总结规律，从而确定模型和特征将来的优化方向。模型和特征是否充分学习无从得知：新挖掘一些特征之后，通常我们会根据离线评测指标是否有提升决定特征是否上线。但是，即使一个有提升的特征，我们也无法知道这个特征是否性能足够好。例如，模型拟合的距离特征，会不会在特定的距离段出现距离越远反而打分越高的情况。这些问题都会潜在带来一些用户无法理解的排序结果。我们需要对深度排序模型清晰地诊断并解释。关于机器学习模型的可解释性研究，业界已经有了一些探索。Lime(Local Interpretable Model-Agnostic Explanations)是其中的一种，如下图所示：通过对单个样本的特征生成扰动产生近邻样本，观察模型的预测行为。根据这些扰动的数据点距离原始数据的距离分配权重，基于它们学习得到一个可解释的模型和预测结果[5]。举个例子，如果需要解释一个情感分类模型是如何预测“我讨厌这部电影”为负面情感的，我们通过丢掉部分词或者乱序构造一些样本预测情感，最终会发现，决定“我讨厌这部电影”为负面情感的是因为“讨厌”这个词。基于Lime解释器的思想，我们开发了一套深度模型解释器工具——雅典娜系统。目前雅典娜系统支持两种工作模式，Pairwise和Listwise模式：Pairwise模式用来解释同一个列表中两个结果之间的相对排序。通过对样本的特征进行重新赋值或者替换等操作，观察样本打分和排序位次的变化趋势，诊断出当前样本排序是否符合预期。如下图所示，通过右侧的特征位次面板可以快速诊断出为什么“南京大牌档”的排序比“金时代顺风港湾”要更靠前。第一行的特征位次信息显示，若将“金时代顺风港湾”的1.3km的距离特征用“南京大牌档”的0.2km的距离特征进行替换，排序位次将上升10位；由此得出，“南京大牌档”排在前面的决定性因素是因为距离近。Listwise模式与Lime的工作模式基本类似，通过整个列表的样本生成扰动样本，训练线性分类器模型输出特征重要度，从而达到对模型进行解释的目的。6. 总结与展望2018年下半年，点评搜索完成了从树模型到大规模深度学习排序模型的全面升级。团队在深度学习特征工程、模型结构、优化目标以及工程实践上都进行了一些探索，在核心指标上取得了较为显著的收益。当然，未来依然有不少可以探索的点。在特征层面，大量知识图谱提供的标签信息尚未充分挖掘。从使用方式上看，简单以文本标签的形式接入，损失了知识图谱的结构信息，因此，Graph Embedding也是未来需要尝试的方向。同时团队也会利用BERT在Query和商户文本的深层语义表达上做一些工作。模型结构层面，目前线上依然以全连接的DNN网络结构为主，但DNN网络结构在低秩数据的学习上不如DeepFM和DCN。目前LambdaDeepFM和LambdaDCN在离线上已经取得了收益，未来会在网络结构上做进一步优化。在模型优化目标上，Lambda Loss计算损失的时候，只会考虑Query内部有点击和无点击的样本对，大量无点击的Query被丢弃，同时，同一个用户短时间内在不同Query下的行为也包含着一些信息可以利用。因此，目前团队正在探索综合考虑Log Loss和Lambda Loss的模型，通过Multi-Task和按照不同维度Shuffle样本让模型充分学习，目前我们已经在线下取得了一些收益。最后，近期Google开源的TF Ranking提出的Groupwise模型也对我们有一些启发。目前绝大部分的Listwise方法只是体现在模型训练阶段，在打分预测阶段依然是Pointwise的，即只会考虑当前商户相关的特征，而不会考虑列表上下文的结果，未来我们也会在这个方向上进行一些探索。参考资料美团大脑：知识图谱的建模方法及其应用Wide & Deep Learning for Recommender SystemsDeep Residual Learning for Image RecognitionAttention Is All You NeedLocal Interpretable Model-Agnostic Explanations: LIMEFrom RankNet to LambdaRank to LambdaMART: An OverviewA Novel Algorithm for Unbiased Learning to RankUnbiased Learning-to-Rank with Biased FeedbackReal-time Personalization using Embeddings for Search Ranking at Airbnb作者简介非易，2016年加入美团点评，高级算法工程师，目前主要负责点评搜索核心排序层的研发工作。祝升，2016年加入美团点评，高级算法工程师，目前负责点评搜索核心排序层的研发工作。汤彪，2013年加入美团点评，高级算法专家，点评平台搜索技术负责人，致力于深层次查询理解和大规模深度学习排序的技术落地。张弓，2012年加入美团点评，美团点评研究员。目前主要负责点评搜索业务演进，及集团搜索公共服务平台建设。仲远，博士，美团AI平台部NLP中心负责人，点评搜索智能中心负责人。在国际顶级学术会议发表论文30余篇，获得ICDE 2015最佳论文奖，并是ACL 2016 Tutorial “Understanding Short Texts”主讲人，出版学术专著3部，获得美国专利5项。此前，博士曾担任微软亚洲研究院主管研究员，以及美国Facebook公司Research Scientist。曾负责微软研究院知识图谱、对话机器人项目和Facebook产品级NLP Service。

背景近年来，互联网上安全事件频发，企业信息安全越来越受到重视，而IDC服务器安全又是纵深防御体系中的重要一环。保障IDC安全，常用的是基于主机型入侵检测系统Host-based Intrusion Detection System，即HIDS。在HIDS面对几十万台甚至上百万台规模的IDC环境时，系统架构该如何设计呢？复杂的服务器环境，网络环境，巨大的数据量给我们带来了哪些技术挑战呢？需求描述对于HIDS产品，我们安全部门的产品经理提出了以下需求：满足50W-100W服务器量级的IDC规模。部署在高并发服务器生产环境，要求Agent低性能低损耗。广泛的部署兼容性。偏向应用层和用户态入侵检测（可以和内核态检测部分解耦）。针对利用主机Agent排查漏洞的最急需场景提供基本的能力，可以实现海量环境下快速查找系统漏洞。Agent跟Server的配置下发通道安全。配置信息读取写入需要鉴权。配置变更历史记录。Agent插件具备自更新功能。分析需求首先，服务器业务进程优先级高，HIDS Agent进程自己可以终止，但不能影响宿主机的主要业务，这是第一要点，那么业务需要具备熔断功能，并具备自我恢复能力。其次，进程保活、维持心跳、实时获取新指令能力，百万台Agent的全量控制时间一定要短。举个极端的例子，当Agent出现紧急情况，需要全量停止时，那么全量停止的命令下发，需要在1-2分钟内完成，甚至30秒、20秒内完成。这些将会是很大的技术挑战。还有对配置动态更新，日志级别控制，细分精确控制到每个Agent上的每个HIDS子进程，能自由地控制每个进程的启停，每个Agent的参数，也能精确的感知每台Agent的上线、下线情况。同时，Agent本身是安全Agent，安全的因素也要考虑进去，包括通信通道的安全性，配置管理的安全性等等。最后，服务端也要有一致性保障、可用性保障，对于大量Agent的管理，必须能实现任务分摊，并行处理任务，且保证数据的一致性。考虑到公司规模不断地扩大，业务不断地增多，特别是美团和大众点评合并后，面对的各种操作系统问题，产品还要具备良好的兼容性、可维护性等。总结下来，产品架构要符合以下特性：集群高可用。分布式，去中心化。配置一致性，配置多版本可追溯。分治与汇总。兼容部署各种Linux 服务器，只维护一个版本。节省资源，占用较少的CPU、内存。精确的熔断限流。服务器数量规模达到百万级的集群负载能力。技术难点在列出产品需要实现的功能点、技术点后，再来分析下遇到的技术挑战，包括不限于以下几点：资源限制，较小的CPU、内存。五十万甚至一百万台服务器的Agent处理控制问题。量级大了后，集群控制带来的控制效率，响应延迟，数据一致性问题。量级大了后，数据传输对整个服务器内网带来的流量冲击问题。量级大了后，运行环境更复杂，Agent异常表现的感知问题。量级大了后，业务日志、程序运行日志的传输、存储问题，被监控业务访问量突增带来监控数据联动突增，对内网带宽，存储集群的爆发压力问题。我们可以看到，技术难点几乎都是服务器到达一定量级带来的，对于大量的服务，集群分布式是业界常见的解决方案。架构设计与技术选型对于管理Agent的服务端来说，要实现高可用、容灾设计，那么一定要做多机房部署，就一定会遇到数据一致性问题。那么数据的存储，就要考虑分布式存储组件。 分布式数据存储中，存在一个定理叫CAP定理：CAP的解释关于CAP定理，分为以下三点：一致性（Consistency）：分布式数据库的数据保持一致。可用性（Availability）：任何一个节点宕机，其他节点可以继续对外提供服务。分区容错性（网络分区）Partition Tolerance：一个数据库所在的机器坏了，如硬盘坏了，数据丢失了，可以添加一台机器，然后从其他正常的机器把备份的数据同步过来。根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项。理解CAP定理的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了Consistency。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了Availability。除非两个节点可以互相通信，才能既保证Consistency又保证Availability，这又会导致丧失Partition Tolerance。参见：CAP TheoremCAP的选择为了容灾上设计，集群节点的部署，会选择的异地多机房，所以 「Partition tolerance」是不可能避免的。那么可选的是 AP 与 CP。在HIDS集群的场景里，各个Agent对集群持续可用性没有非常强的要求，在短暂时间内，是可以出现异常，出现无法通讯的情况。但最终状态必须要一致，不能存在集群下发关停指令，而出现个别Agent不听从集群控制的情况出现。所以，我们需要一个满足 CP 的产品。满足CP的产品选择在开源社区中，比较出名的几款满足CP的产品，比如etcd、ZooKeeper、Consul等。我们需要根据几款产品的特点，根据我们需求来选择符合我们需求的产品。插一句，网上很多人说Consul是AP产品，这是个错误的描述。既然Consul支持分布式部署，那么一定会出现「网络分区」的问题， 那么一定要支持「Partition tolerance」。另外，在consul的官网上自己也提到了这点 Consul uses a CP architecture, favoring consistency over availability. Consul is opinionated in its usage while Serf is a more flexible and general purpose tool. In CAP terms, Consul uses a CP architecture, favoring consistency over availability. Serf is an AP system and sacrifices consistency for availability. This means Consul cannot operate if the central servers cannot form a quorum while Serf will continue to function under almost all circumstances.etcd、ZooKeeper、Consul对比 借用etcd官网上etcd与ZooKeeper和Consul的比较图。在我们HIDS Agent的需求中，除了基本的服务发现 、配置同步 、配置多版本控制 、变更通知等基本需求外，我们还有基于产品安全性上的考虑，比如传输通道加密、用户权限控制、角色管理、基于Key的权限设定等，这点 etcd比较符合我们要求。很多大型公司都在使用，比如Kubernetes、AWS、OpenStack、Azure、Google Cloud、Huawei Cloud等，并且etcd的社区支持非常好。基于这几点因素，我们选择etcd作为HIDS的分布式集群管理。选择etcd对于etcd在项目中的应用，我们分别使用不同的API接口实现对应的业务需求，按照业务划分如下：Watch机制来实现配置变更下发，任务下发的实时获取机制。脑裂问题在etcd中不存在，etcd集群的选举，只有投票达到 N/2+1 以上，才会选做Leader，来保证数据一致性。另外一个网络分区的Member节点将无主。语言亲和性，也是Golang开发的，Client SDK库稳定可用。Key存储的数据结构支持范围性的Key操作。User、Role权限设定不同读写权限，来控制Key操作，避免其他客户端修改其他Key的信息。TLS来保证通道信息传递安全。Txn分布式事务API配合Compare API来确定主机上线的Key唯一性。Lease租约机制，过期Key释放，更好的感知主机下线信息。etcd底层Key的存储为BTree结构，查找时间复杂度为O（㏒n），百万级甚至千万级Key的查找耗时区别不大。etcd Key的设计前缀按角色设定：Server配置下发使用 /hids/server/config/{hostname}/master。Agent注册上线使用 /hids/agent/master/{hostname}。Plugin配置获取使用 /hids/agent/config/{hostname}/plugin/ID/conf_name。Server Watch /hids/server/config/{hostname}/master，实现Agent主机上线的瞬间感知。Agent Watch /hids/server/config/{hostname}/来获取配置变更，任务下发。Agent注册的Key带有Lease Id，并启用keepalive，下线后瞬间感知。 （异常下线，会有1/3的keepalive时间延迟）关于Key的权限，根据不同前缀，设定不同Role权限。赋值给不同的User，来实现对Key的权限控制。etcd集群管理在etcd节点容灾考虑，考虑DNS故障时，节点会选择部署在多个城市，多个机房，以我们服务器机房选择来看，在大部分机房都有一个节点，综合承载需求，我们选择了N台服务器部署在个别重要机房，来满足负载、容灾需求。但对于etcd这种分布式一致性强的组件来说，每个写操作都需要N/2-1的节点确认变更，才会将写请求写入数据库中，再同步到各个节点，那么意味着节点越多，需要确认的网络请求越多，耗时越多，反而会影响集群节点性能。这点，我们后续将提升单个服务器性能，以及牺牲部分容灾性来提升集群处理速度。客户端填写的IP列表，包含域名、IP。IP用来规避DNS故障，域名用来做Member节点更新。最好不要使用Discover方案，避免对内网DNS服务器产生较大压力。同时，在配置etcd节点的地址时，也要考虑到内网DNS故障的场景，地址填写会混合IP、域名两种形式。IP的地址，便于规避内网DNS故障。域名形式，便于做个别节点更替或扩容。我们在设计产品架构时，为了安全性，开启了TLS证书认证，当节点变更时，证书的生成也同样要考虑到上面两种方案的影响，证书里需要包含固定IP，以及DNS域名范围的两种格式。etcd Cluster节点扩容节点扩容，官方手册上也有完整的方案，etcd的Client里实现了健康检测与故障迁移，能自动的迁移到节点IP列表中的其他可用IP。也能定时更新etcd Node List，对于etcd Cluster的集群节点变更来说，不存在问题。需要我们注意的是，TLS证书的兼容。分布式HIDS集群架构图集群核心组件高可用，所有Agent、Server都依赖集群，都可以无缝扩展，且不影响整个集群的稳定性。即使Server全部宕机，也不影响所有Agent的继续工作。在以后Server版本升级时，Agent不会中断，也不会带来雪崩式的影响。etcd集群可以做到单节点升级，一直到整个集群升级，各个组件全都解耦。编程语言选择考虑到公司服务器量大，业务复杂，需求环境多变，操作系统可能包括各种Linux以及Windows等。为了保证系统的兼容性，我们选择了Golang作为开发语言，它具备以下特点：可以静态编译，直接通过syscall来运行，不依赖libc，兼容性高，可以在所有Linux上执行，部署便捷。静态编译语言，能将简单的错误在编译前就发现。具备良好的GC机制，占用系统资源少，开发成本低。容器化的很多产品都是Golang编写，比如Kubernetes、Docker等。etcd项目也是Golang编写，类库、测试用例可以直接用，SDK支持快速。良好的CSP并发模型支持，高效的协程调度机制。产品架构大方向HIDS产品研发完成后，部署的服务都运行着各种业务的服务器，业务的重要性排在第一，我们产品的功能排在后面。为此，确定了几个产品的大方向：高可用，数据一致，可横向扩展。容灾性好，能应对机房级的网络故障。兼容性好，只维护一个版本的Agent。依赖低，不依赖任何动态链接库。侵入性低，不做Hook，不做系统类库更改。熔断降级可靠，宁可自己挂掉，也不影响业务 。产品实现篇幅限制，仅讨论框架设计、熔断限流、监控告警、自我恢复以及产品实现上的主进程与进程监控。框架设计如上图，在框架的设计上，封装常用类库，抽象化定义Interface，剥离etcd Client，全局化Logger，抽象化App的启动、退出方法。使得各模块（以下简称App）只需要实现自己的业务即可，可以方便快捷的进行逻辑编写，无需关心底层实现、配置来源、重试次数、熔断方案等等。沙箱隔离考虑到子进程不能无限的增长下去，那么必然有一个进程包含多个模块的功能，各App之间既能使用公用底层组件（Logger、etcd Client等），又能让彼此之间互不影响，这里进行了沙箱化处理，各个属性对象仅在各App的sandbox里生效。同样能实现了App进程的性能熔断，停止所有的业务逻辑功能，但又能具有基本的自我恢复功能。IConfig对各App的配置抽象化处理，实现IConfig的共有方法接口，用于对配置的函数调用，比如Check的检测方法，检测配置合法性，检测配置的最大值、最小值范围，规避使用人员配置不在合理范围内的情况，从而避免带来的风险。框架底层用Reflect来处理JSON配置，解析读取填写的配置项，跟Config对象对比，填充到对应Struct的属性上，允许JSON配置里只填写变化的配置，没填写的配置项，则使用Config对应Struct的默认配置。便于灵活处理配置信息。type IConfig interface { Check() error //检测配置合法性}func ConfigLoad(confByte []byte, config IConfig) (IConfig, error) {…//反射生成临时的IConfig var confTmp IConfig confTmp = reflect.New(reflect.ValueOf(config).Elem().Type()).Interface().(IConfig)… //反射 confTmp 的属性 confTmpReflect := reflect.TypeOf(confTmp).Elem() confTmpReflectV := reflect.ValueOf(confTmp).Elem() //反射config IConfig configReflect := reflect.TypeOf(config).Elem() configReflectV := reflect.ValueOf(config).Elem()… for i = 0; i < num; i++ { //遍历处理每个Field envStructTmp := configReflect.Field(i) //根据配置中的项，来覆盖默认值 if envStructTmp.Type == confStructTmp.Type { configReflectV.FieldByName(envStructTmp.Name).Set(confTmpReflectV.Field(i))Timer、Clock调度在业务数据产生时，很多地方需要记录时间，时间的获取也会产生很多系统调用。尤其是在每秒钟产生成千上万个事件，这些事件都需要调用获取时间接口，进行clock_gettime等系统调用，会大大增加系统CPU负载。 而很多事件产生时间的准确性要求不高，精确到秒，或者几百个毫秒即可，那么框架里实现了一个颗粒度符合需求的（比如100ms、200ms、或者1s等）间隔时间更新的时钟，即满足事件对时间的需求，又减少了系统调用。同样，在有些Ticker场景中，Ticker的间隔颗粒要求不高时，也可以合并成一个Ticker，减少对CPU时钟的调用。Catcher在多协程场景下，会用到很多协程来处理程序，对于个别协程的panic错误，上层线程要有一个良好的捕获机制，能将协程错误抛出去，并能恢复运行，不要让进程崩溃退出，提高程序的稳定性。抽象接口框架底层抽象化封装Sandbox的Init、Run、Shutdown接口，规范各App的对外接口，让App的初始化、运行、停止等操作都标准化。App的模块业务逻辑，不需要关注PID文件管理，不关注与集群通讯，不关心与父进程通讯等通用操作，只需要实现自己的业务逻辑即可。App与框架的统一控制，采用Context包以及Sync.Cond等条件锁作为同步控制条件，来同步App与框架的生命周期，同步多协程之间同步，并实现App的安全退出，保证数据不丢失。限流网络IO限制数据上报速度。队列存储数据任务列表。大于队列长度数据丢弃。丢弃数据总数计数。计数信息作为心跳状态数据上报到日志中心，用于数据对账。磁盘IO程序运行日志，对日志级别划分，参考 /usr/include/sys/syslog.h：LOG_EMERGLOG_ALERTLOG_CRITLOG_ERRLOG_WARNINGLOG_NOTICELOG_INFOLOG_DEBUG在代码编写时，根据需求选用级别。级别越低日志量越大，重要程度越低，越不需要发送至日志中心，写入本地磁盘。那么在异常情况排查时，方便参考。日志文件大小控制，分2个文件，每个文件不超过固定大小，比如20M、50M等。并且，对两个文件进行来回写，避免日志写满磁盘的情况。IRetry为了加强Agent的鲁棒性，不能因为某些RPC动作失败后导致整体功能不可用，一般会有重试功能。Agent跟etcd Cluster也是TCP长连接（HTTP2），当节点重启更换或网络卡顿等异常时，Agent会重连，那么重连的频率控制，不能是死循环般的重试。假设服务器内网交换机因内网流量较大产生抖动，触发了Agent重连机制，不断的重连又加重了交换机的负担，造成雪崩效应，这种设计必须要避免。 在每次重试后，需要做一定的回退机制，常见的指数级回退，比如如下设计，在规避雪崩场景下，又能保障Agent的鲁棒性，设定最大重试间隔，也避免了Agent失控的问题。//网络库重试Interfacetype INetRetry interface { //开始连接函数 Connect() error String() string //获取最大重试次数 GetMaxRetry() uint …}// 底层实现func (this *Context) Retry(netRetry INetRetry) error {… maxRetries = netRetry.GetMaxRetry() //最大重试次数 hashMod = netRetry.GetHashMod()for { if c.shutting { return errors.New(“c.shutting is true…”) } if maxRetries > 0 && retries >= maxRetries { c.logger.Debug(“Abandoning %s after %d retries.”, netRetry.String(), retries) return errors.New(“超过最大重试次数”) }… if e := netRetry.Connect(); e != nil { delay = 1 << retries if delay == 0 { delay = 1 } delay = delay * hashInterval… c.logger.Emerg(“Trying %s after %d seconds , retries:%d,error:%v”, netRetry.String(), delay, retries, e) time.Sleep(time.Second * time.Duration(delay)) }…}事件拆分百万台IDC规模的Agent部署，在任务执行、集群通讯或对宿主机产生资源影响时，务必要错峰进行，根据每台主机的唯一特征取模，拆分执行，避免造成雪崩效应。监控告警古时候，行军打仗时，提倡「兵马未动，粮草先行」，无疑是冷兵器时代决定胜负走向的重要因素。做产品也是，尤其是大型产品，要对自己运行状况有详细的掌控，做好监控告警，才能确保产品的成功。对于etcd集群的监控，组件本身提供了Metrics数据输出接口，官方推荐了Prometheus来采集数据，使用Grafana来做聚合计算、图标绘制，我们做了Alert的接口开发，对接了公司的告警系统，实现IM、短信、电话告警。Agent数量感知，依赖Watch数字，实时准确感知。如下图，来自产品刚开始灰度时的某一时刻截图，Active Streams（即etcd Watch的Key数量）即为对应Agent数量，每次灰度的产品数量。因为该操作，是Agent直接与集群通讯，并且每个Agent只Watch一个Key。且集群数据具备唯一性、一致性，远比心跳日志的处理要准确的多。etcd集群Members之间健康状况监控用于监控管理etcd集群的状况，包括Member节点之间数据同步，Leader选举次数，投票发起次数，各节点的内存申请状况，GC情况等，对集群的健康状况做全面掌控。程序运行状态监控告警全量监控Aagent的资源占用情况，统计每天使用最大CPU内存的主机Agent，确定问题的影响范围，及时做策略调整，避免影响到业务服务的运行。并在后续版本上逐步做调整优化。百万台服务器，日志告警量非常大，这个级别的告警信息的筛选、聚合是必不可少的。减少无用告警，让研发运维人员疲于奔命，也避免无用告警导致研发人员放松了警惕，前期忽略个例告警，先解决主要矛盾。告警信息分级，告警信息细分ID。根据告警级别过滤，根据告警ID聚合告警，来发现同类型错误。根据告警信息的所在机房、项目组、产品线等维度来聚合告警，来发现同类型错误。数据采集告警单机数据数据大小、总量的历史数据对比告警。按机房、项目组、产品线等维度的大小、总量等维度的历史数据对比告警。数据采集大小、总量的对账功能，判断经过一系列处理流程的日志是否丢失的监控告警。熔断针对单机Agent使用资源大小的阈值熔断，CPU使用率，连续N次触发大于等于5%，则进行保护性熔断，退出所有业务逻辑，以保护主机的业务程序优先。Master进程进入空闲状态，等待第二次时间Ticker到来，决定是否恢复运行。各个App基于业务层面的监控熔断策略。灰度管理在前面的配置管理中的etcd Key设计里，已经细分到每个主机（即每个Agent）一个Key。那么，服务端的管理，只要区分该主机所属机房、环境、群组、产品线即可，那么，我们的管理Agent的颗粒度可以精确到每个主机，也就是支持任意纬度的灰度发布管理与命令下发。数据上报通道组件名为 log_agent ，是公司内部统一日志上报组件，会部署在每一台VM、Docker上。主机上所有业务均可将日志发送至该组件。 log_agent会将日志上报到Kafka集群中，经过处理后，落入Hive集群中。（细节不在本篇讨论范围）主进程主进程实现跟etcd集群通信，管理整个Agent的配置下发与命令下发；管理各个子模块的启动与停止；管理各个子模块的CPU、内存占用情况，对资源超标进行进行熔断处理，让出资源，保证业务进程的运行。插件化管理其他模块，多进程模式，便于提高产品灵活性，可更简便的更新启动子模块，不会因为个别模块插件的功能、BUG导致整个Agent崩溃。进程监控方案选择我们在研发这产品时，做了很多关于linux进程创建监控的调研，不限于安全产品，大约有下面三种技术方案：方案Docker兼容性开发难度数据准确性系统侵入性cn_proc不支持Docker一般存在内核拿到的PID，在/proc/下丢失的情况无Audit不支持Docker一般同cn_proc弱，但依赖Auditd Hook定制高精确强对于公司的所有服务器来说，几十万台都是已经在运行的服务器，新上的任何产品，都尽量避免对服务器有影响，更何况是所有服务器都要部署的Agent。 意味着我们在选择系统侵入性来说，优先选择最小侵入性的方案。对于Netlink的方案原理，可以参考这张图（来自:kernel-proc-connector-and-containers）系统侵入性比较cn_proc跟Autid在「系统侵入性」和「数据准确性」来说，cn_proc方案更好，而且使用CPU、内存等资源情况，更可控。Hook的方案，对系统侵入性太高了，尤其是这种最底层做HOOK syscall的做法，万一测试不充分，在特定环境下，有一定的概率会出现Bug，而在百万IDC的规模下，这将成为大面积事件，可能会造成重大事故。兼容性上比较cn_proc不兼容Docker，这个可以在宿主机上部署来解决。Hook的方案，需要针对每种Linux的发行版做定制，维护成本较高，且不符合长远目标（收购外部公司时遇到各式各样操作系统问题）数据准确性比较在大量PID创建的场景，比如Docker的宿主机上，内核返回PID时，因为PID返回非常多非常快，很多进程启动后，立刻消失了，另外一个线程都还没去读取/proc/，进程都丢失了，场景常出现在Bash执行某些命令。最终，我们选择Linux Kernel Netlink接口的cn_proc指令作为我们进程监控方案，借助对Bash命令的收集，作为该方案的补充。当然，仍然存在丢数据的情况，但我们为了系统稳定性，产品侵入性低等业务需求，牺牲了一些安全性上的保障。 对于Docker的场景，采用宿主机运行，捕获数据，关联到Docker容器，上报到日志中心的做法来实现。遇到的问题内核Netlink发送数据卡住内核返回数据太快，用户态ParseNetlinkMessage解析读取太慢，导致用户态网络Buff占满，内核不再发送数据给用户态，进程空闲。对于这个问题，我们在用户态做了队列控制，确保解析时间的问题不会影响到内核发送数据。对于队列的长度，我们做了定值限制，生产速度大于消费速度的话，可以丢弃一些数据，来保证业务正常运行，并且来控制进程的内存增长问题。疑似“内存泄露”问题在一台Docker的宿主机上，运行了50个Docker实例，每个Docker都运行了复杂的业务场景，频繁的创建进程，在最初的产品实现上，启动时大约10M内存占用，一天后达到200M的情况。经过我们Debug分析发现，在ParseNetlinkMessage处理内核发出的消息时，PID频繁创建带来内存频繁申请，对象频繁实例化，占用大量内存。同时，在Golang GC时，扫描、清理动作带来大量CPU消耗。在代码中，发现对于linux/connector.h里的struct cb_msg、linux/cn_proc.h里的struct proc_event结构体频繁创建，带来内存申请等问题，以及Golang的GC特性，内存申请后，不会在GC时立刻归还操作系统，而是在后台任务里，逐渐的归还到操作系统，见：debug.FreeOSMemoryFreeOSMemory forces a garbage collection followed by an attempt to return as much memory to the operating system as possible. (Even if this is not called, the runtime gradually returns memory to the operating system in a background task.)但在这个业务场景里，大量频繁的创建PID，频繁的申请内存，创建对象，那么申请速度远远大于释放速度，自然内存就一直堆积。从文档中可以看出，FreeOSMemory的方法可以将内存归还给操作系统，但我们并没有采用这种方案，因为它治标不治本，没法解决内存频繁申请频繁创建的问题，也不能降低CPU使用率。为了解决这个问题，我们采用了sync.Pool的内置对象池方式，来复用回收对象，避免对象频繁创建，减少内存占用情况，在针对几个频繁创建的对象做对象池化后，同样的测试环境，内存稳定控制在15M左右。大量对象的复用，也减少了对象的数量，同样的，在Golang GC运行时，也减少了对象的扫描数量、回收数量，降低了CPU使用率。项目进展在产品的研发过程中，也遇到了一些问题，比如：etcd Client Lease Keepalive的Bug。Agent进程资源限制的Cgroup触发几次内核Bug。Docker宿主机上瞬时大量进程创建的性能问题。网络监控模块在处理Nginx反向代理时，动辄几十万TCP链接的网络数据获取压力。个别进程打开了10W以上的fd。方法一定比困难多，但方法不是拍脑袋想出来的，一定要深入探索问题的根本原因，找到系统性的修复方法，具备高可用、高性能、监控告警、熔断限流等功能后，对于出现的问题，能够提前发现，将故障影响最小化，提前做处理。在应对产品运营过程中遇到的各种问题时，逢山开路，遇水搭桥，都可以从容的应对。经过我们一年的努力，已经部署了除了个别特殊业务线之外的其他所有服务器，数量达几十万台，产品稳定运行。在数据完整性、准确性上，还有待提高，在精细化运营上，需要多做改进。本篇更多的是研发角度上软件架构上的设计，关于安全事件分析、数据建模、运营策略等方面的经验和技巧，未来将会由其他同学进行分享，敬请期待。总结我们在研发这款产品过程中，也看到了网上开源了几款同类产品，也了解了他们的设计思路，发现很多产品都是把主要方向放在了单个模块的实现上，而忽略了产品架构上的重要性。比如，有的产品使用了syscall hook这种侵入性高的方案来保障数据完整性，使得对系统侵入性非常高，Hook代码的稳定性，也严重影响了操作系统内核的稳定。同时，Hook代码也缺少了监控熔断的措施，在几十万服务器规模的场景下部署，潜在的风险可能让安全部门无法接受，甚至是致命的。这种设计，可能在服务器量级小时，对于出现的问题多花点时间也能逐个进行维护，但应对几十万甚至上百万台服务器时，对维护成本、稳定性、监控熔断等都是很大的技术挑战。同时，在研发上，也很难实现产品的快速迭代，而这种方式带来的影响，几乎都会导致内核宕机之类致命问题。这种事故，使用服务器的业务方很难进行接受，势必会影响产品的研发速度、推进速度；影响同事（SRE运维等）对产品的信心，进而对后续产品的推进带来很大的阻力。以上是笔者站在研发角度，从可用性、可靠性、可控性、监控熔断等角度做的架构设计与框架设计，分享的产品研发思路。笔者认为大规模的服务器安全防护产品，首先需要考虑的是架构的稳定性、监控告警的实时性、熔断限流的准确性等因素，其次再考虑安全数据的完整性、检测方案的可靠性、检测模型的精确性等因素。九层之台，起于累土。只有打好基础，才能运筹帷幄，决胜千里之外。参考资料https://en.wikipedia.org/wiki…https://www.consul.io/intro/v...https://golang.org/src/runtim...https://www.ibm.com/developer...https://www.kernel.org/doc/https://coreos.com/etcd/docs/…作者简介陈驰，美团点评技术专家，2017年加入美团，十年以上互联网产品研发经验，专注于分布式系统架构设计，目前主要从事安全防御产品研发工作。关于美团安全美团安全部的大多数核心开发人员，拥有多年互联网以及安全领域实践经验，很多同学参与过大型互联网公司的安全体系建设，其中也不乏全球化安全运营人才，具备百万级IDC规模攻防对抗的经验。安全部也不乏CVE“挖掘圣手”，有受邀在Black Hat等国际顶级会议发言的讲者，当然还有很多漂亮的运营妹子。目前，美团安全部涉及的技术包括渗透测试、Web防护、二进制安全、内核安全、分布式开发、大数据分析、安全算法等等，同时还有全球合规与隐私保护等策略制定。我们正在建设一套百万级IDC规模、数十万终端接入的移动办公网络自适应安全体系，这套体系构建于零信任架构之上，横跨多种云基础设施，包括网络层、虚拟化/容器层、Server 软件层（内核态/用户态）、语言虚拟机层（JVM/JS V8）、Web应用层、数据访问层等，并能够基于“大数据+机器学习”技术构建全自动的安全事件感知系统，努力打造成业界最前沿的内置式安全架构和纵深防御体系。随着美团的高速发展，业务复杂度不断提升，安全部门面临更多的机遇和挑战。我们希望将更多代表业界最佳实践的安全项目落地，同时为更多的安全从业者提供一个广阔的发展平台，并提供更多在安全新兴领域不断探索的机会。招聘信息美团安全部正在招募Web&二进制攻防、后台&系统开发、机器学习&算法等各路小伙伴。如果你想加入我们，欢迎简历请发至邮箱zhaoyan17@meituan.com具体职位信息可参考这里：https://mp.weixin.qq.com/s/ynEq5LqQ2uBcEaHCu7Tsiw美团安全应急响应中心MTSRC主页：security.meituan.com ...

洪磊，2013年加入美团，目前是美团外卖事业部终端组的负责人，也是美团技术委员会前端通道主席。在加入美团之前，洪磊的职业生涯可以用“跌宕起伏”来形容。他就读于中南财经政法大学，曾任职于雅虎中国，先后担任产品经理、前端开发工程师等职位。拥有4年创业经历，对前端和硬件技术有着很高的热情。高中时，洪磊就参加各种计算机竞赛，很喜欢技术，但是大学并没有选择计算机这个方向。2002年，洪磊考入中南财经政法大学，读国际贸易专业。不过大四那年，他瞒着家里人跟几个小伙伴一起休学创业了。当时，他们做了一款基于位置的本地服务（跟美团颇有渊源），受限于团队经验和当时的市场环境，最后以失败而告终。随后加入了雅虎中国，起初做音乐搜索产品经理，一心想做一个好用的音乐搜索产品，但却被技术同学各种“刁难”，“这个不好做，要开发1个月”。于是，他从产品转到了后台，然后又从后台转到了前端。自从2005年，雅虎中国被阿里巴巴收购，就在不断拥抱变化，洪磊并不是很喜欢那种工作氛围。2009年，创业之火再次燃起，于是受邀加入魔位娱乐，在此期间，洪磊做过网页游戏开发，做过塞班App，从业务、运维、后台再到前端，几乎涉足整个流程并都有较深的参与，练就了“十八般武艺”。2013年，他觉得自己在团队管理和个人发展上遇到了瓶颈，于是正式加入美团，负责移动前端组，再次踏上新的征程。从美团触屏版开始做起，后面还搞了公司的运营系统，最后，“阴差阳错”地来到了美团外卖技术团队，一直到现在。近日，我们美团技术学院采访了洪磊，一个“爱折腾”的创业者，一个做过产品、运营、后台和前端的工程师，他说家里的所有的智能家居，都是自己亲手“焊板子”捯饬出来的。我们在洪磊身上，真正看到了一种极客精神。今天，让我们一起听洪磊讲讲，这么多年他“折腾”出来的那些故事。Q：当时怎么接触到的计算机？为什么大学选择了中南财经政法大学，而且选择了国际贸易专业？有什么特别的故事可以分享吗？洪磊：其实，我在高中时候就经常参加计算机的竞赛。当时的高中在浙江淳安县，那是一个小县城，学校对计算机的理解或者说关注度其实是很低的。我参加一些省里和市里计算机竞赛，还给学校拿过一些奖项，这也是淳安中学最早的几个计算机奖项。那个时候，对计算机还是非常感兴趣的，而且通过这几次获奖的经历，在自己心里也打下了这个“烙印”。但因为我们江浙一带的人，更偏向于从商，所以当时选择了中南财经政法大学的国际贸易专业。不过整个大学期间，我也非常有收获，对经济学、会计学、保险、物流、运输等等很多方面，都有了一定了解。国际贸易是一个非常广的学科，它涵盖的东西很多，甚至还要学习谈判技巧、各地文化和礼仪。虽然我觉得这个专业非常赞，但是骨子里，我更偏爱技术一点。最终我还是选择了休学创业，但我知道，家里肯定会反对。所有我没有敢跟家里讲，我只是跟辅导员聊了一下，她当时很支持我的选择，虽然我对经济类专业也比较感兴趣。但是她觉得在计算机领域，我可能会有更好的发展。辅导员了解到我顾虑，她说，“没关系，如果你不敢讲，我帮你去讲”。现在，我还是很感谢辅导员给我的支持。Q：辅导员为什么对你那么有自信？洪磊：因为我在大学期间，参加了学校里一些计算机相关的社团，还给班里同学辅导技术机等级考试的相关知识，有时还会接一些网站外包的活。最主要的是，我和几个小伙伴给微软旗下的即时通讯工具MSN Messenger开发了一个插件，可以加密聊天记录，并且添加了很多好用的小功能，我当时主要负责Tab系统的开发和维护。这应该也是MSN Messenger历史上最著名的一个插件了。那是一个虚拟的小组，我当时在武汉，另两个开发者一个在上海，一个在广州，我们是三地办公。有个同学是专门去破解MSN Messenger的相关接口，获取相关权限。另一个同学是做通讯内容的加密，我负责Tab功能相关的系统，三个人配合的井井有条。后来发现Yahoo! Messenger也有自己的标签系统，我顺便也破解了，这也是后面我能够加入雅虎中国的重要原因。所以我辅导员觉得我在计算机方面有一定的天赋，而且也做出了一些成绩，因此她坚定的支持我去做创业。Q：现在回看第一次创业，失败的原因是什么？对自己的影响是什么？有没有后悔过创业这件事？洪磊：首先是经验不足，我们想的太过理想，觉得把产品做出来就能有用户。但在当时，时机并不成熟，没有智能手机，上网主要靠PC，几乎无法实现精准的定位。做送餐这样的服务，对商家、用户的体验都很差。现在看来，在技术上，我们做的还行，但是在业务上，我们的思考就太少了。这次创业后，我觉得事，都要有条理地去做，当时团队应该算是“散兵游勇”，没做市场调查，没有MRD，连PRD也是很简单的一个框架图而已，我们就开始开发了，甚至一些技术的实现也因为总是变动功能而做得比较糙。对休学这件事，还是有一些遗憾的，但是没有后悔过。比如因为没有毕业证，导致我现在办不了北京的工作居住证，部分城市的落户也会很困难。但是不后悔，如果没有当时的爱折腾，可能也不会有现在这样一个“特别”的我。也许就是每天简单的上班、吃饭、下班、陪家人，当然平淡也是一种幸福。但是我知道，这不是我向往的生活。每次参加校园招聘，我会劝小同学们要来北京这样的大城市，因为视野不同，眼界也大有不同。我很清楚的记得，有个美团校招时被我的思想“安利”的小同学，她入职一年后告诉我，“真是完全不一样的感觉，如果当时留在成都，大概率就是一生默默无闻的做一份工作，可能永远都不会触达到世界各地。但是，现在我一有空，就全球各地跑、去玩，去了解更多更新的知识，原来世界上有这么多有意思的东西，值得我们去体会。”Q：为什么会选择雅虎？洪磊：雅虎当时还是全球第一大网站。而且我刚刚也讲到了，在大学期间，我把Yahoo! Messenger的Tab系统破解了，还总是给他们提一些问题和想法，所以就认识了当时雅虎中国的产品总监Sam。大二的时候，他就邀请我去雅虎实习。后来创业失败，也没有机会参加校招，干脆就过去了。雅虎中国也没有看我的学历。我当时还有点沾沾自喜。因为很多同学参加校招，各种面试，最后等发Offer。而我，只写了一个PPT，下面坐了好几个部门的负责人，等我去选择。其实，我当时也不知道自己想做什么，Sam问我这个问题，我记得是这么回答的：“我想做一些把雅虎美国的产品引入中国以后，让中国用户用的更爽的事，我想做一些本地化，或者说更炫酷的功能。”Q：给现在的实习生或者在校生提点建议吧？洪磊：这个问题我需要好好回答一下，我参加过很多次校招，也结合我亲身的一些经历，我给现在还在实习的同学们三点小建议：第一点，要想清楚自己喜欢的工作，或者自己喜欢的方向是什么，这点很重要。很多同学都觉得找个朝阳行业，一份收入高的工作就好。工作以后，我们会逐渐发现，只有我们真正喜欢的，才可能去深入。第二点，建议大家第一份工作要去一个大点的公司，如果是互联网公司，建议去BAT或者美团这样的大型互联网企业。因为大公司能够提供一个体系化的成长平台，让同学们少走弯路。第三点，不要眼高手低，应该从最基础的岗位做起，从底层去了解一个技术。我经常跟美团的小伙伴讲，“要多去看那些基础知识，少去看那些高大上的东西。”如果真想自己去写一个东西，那我希望是从底层原理去了解，而不是通过一些现成的类库来实现，甚至到网上找一个类似的直接改改。Q：刚开始做的是产品相关的工作，什么原因让你转做前端了呢？洪磊：这段经历其实挺有意思的，最早我去雅虎中国是做音乐搜索产品助理的，但是对整个产品体系了解不够，就被我老板发配去做运营。其中有个重要的工作就是每天要用几个小时去统计业务的各种数据，非常枯燥。不过那个过程，对我的帮助非常之大，通过持续了两个月的数据统计工作，我对整个音乐产品有个非常清晰的了解，知道业务上哪些地方有改进的空间。所以后面做产品设计的时候，就可以游刃有余地通过数据来推动业务的发展。说到转型，还有段精彩的故事。几乎所有的工程师都比较抵触产品，每次去排期的时候，工程师都说这个事情比较难，我们做不了，或者这个事情我们排不上期，如果逼急了，他们可能就来句“你行，你上啊”。当然我也不示弱，就接了一句：“好吧，我自己来搞，你把权限开放给我。”因为我大学的时候就写过PHP代码，雅虎用的也是PHP，所以做一些简单开发，不会有太大的压力。写完后台以后，发现前端又是个瓶颈，前端人员少，排不上期，那行吧，我又开始写起了前端。这时突然发现前端是我喜欢的一个方向，我就直接转入UED（雅虎的前端在UED团队）。这里有个让我记忆犹新的小故事，可以分享给大家，我作为前端工程师写的第一个页面，因为没有做到到像素级的呈现，结果被投诉到我老板那，被训了一顿。这件事对我触动很大，做每一件事，都应该符合需求方的诉求，尊重上游同学的劳动成果，而不是自己埋头做一些自己觉得很轻松的事。这也促使我跟设计师同学们的配合都非常默契，包括现在小米（米UI）的设计部门负责人跟我关系就很好，之前他的个人网站就是他设计我开发的，其中各种渐变、圆角加阴影（当时要考虑低版本IE），他非常赞赏我完美的呈现，我经常说他“就剩下对像素的这点追求了”。Q：你会鼓励技术同学转型吗？洪磊：我还是会鼓励同学们去做一些有挑战的事。而选择转型，去干一个全新的事情，主要还是看个人的兴趣和追求。但是非常推荐同学们去合作团队轮岗。美团外卖就一直在推动轮岗的事，我最近也在产品线轮岗。我觉得各种技术在思想上其实互通的，我们可以通过轮岗学到交叉领域的很多知识。2013年在平台做LocalStorage缓存优化，就借鉴了MemCache的一些想法去实现的。所以很多情况，我们可以去借鉴其他技术的思想，只是代码的实现层面，略有差异。Q：当时为什么会离开雅虎？再次选择创业，有哪些新的收获？洪磊：很重要的一个原因，就是雅虎中国乃至全球的业务在慢慢萎缩，心里有一定的落差。而且收购后，阿里巴巴的企业文化、价值观我也不是非常适应。刚巧有一个好哥们邀请我和他一起创业，我就决定和他一起“干一票大的”。当然，创业依然是一个很艰辛的过程。创业要有极强大的内心。我当时从雅虎中国出来，家人朋友并不支持我，因为阿里巴巴在浙江非常有名，大家都挤破了头往里走。父母会觉得，从那么优秀的一家公司出来跑去创业，还是一家“生死未卜”的公司，是脑袋有“坑”的节奏吗？这次创业中间有很多波折的，做过很多业务，比如网页游戏，比如塞班客户端应用等等。我觉得创业要有耐心，要能够坚持在一个业务上不断深入。也需要灵活，在发现某个业务方向完全行不通的时候快速变化。这次创业，我最大的收获是，从业务到技术，甚至采购和市场都要自己去管理，这让我能更全面的去思考一个业务的发展过程。其实我还是一个技术流，更喜欢去研究技术问题，家里的智能家居系统都是我自己搞的，其中还包括大部分的硬件，自己购买芯片和元件，然后做PCB板、焊接。我希望对这些设备有“掌控权”，或者说我希望这些设备对我来说，是一个完全“透明”的东西。不希望设备“不听话”，更不希望数据莫名奇妙到了别人的服务器上，对于一个做技术同学来说，这是很难容忍的一件事情。Q：这么多年的创业，对技术的发展有哪些体会？洪磊：对技术而言，第一点感触是，在商业社会中，能服务好业务的技术才有价值，不推崇去搞一些不容易落地的技术。第二点感触是，技术和产品应该和业务紧密相连，不能单独割裂开来，我们每个技术同学也都应该了解产品还有业务的思路，做出最合适的技术实现。Q：后来为什么选择美团？洪磊：创业的前两年比较辛苦，后面基本上全球跑，每天都可以有“说走就走的旅行”。公司的业务趋于稳定，没有太大的发展，感觉自己的发展也遇到了一些瓶颈。还有一点，我们的公司属于“哥们型”的公司，在团队管理层面，存在很大的问题，我当时管了20人左右，很难再扩大规模了。恰巧雅虎的一个同事推荐我来美团，当时跟亮哥（陈亮，美团高级副总裁）也比较谈得来，所以就加入了。Q：到美团后经历了哪些事？洪磊：刚来美团的时候，我们团队只有3个人。移动前端在当时也是一个刚兴起不久的方向，几乎相当于从零开始做，我很享受这个过程。团队主要工作就是开发美团系相关触屏版页面，期间还管理了相关的后端团队和产品团队，最多的时候有30多人，也创造了不错的业绩。同时也为公司很多部门输送了大批人才，包括猫眼（已经独立）、大象、美团酒旅最早期的前端的同学，都是从我们移动前端组过去的。2016年初，公司希望我去管理外卖前端团队，最初还是有点犹豫的，后来和外卖同学做了简单沟通后就欣然接受了挑战，当时并没有想到会在外卖团队获得如此快速的成长。到外卖后，第一个挑战就是App的质量欠佳，我并不是客户端出身，所以对客户端技术了解甚少，只能通过管理的手段来做事情，还好当时有非常称心的“左膀右臂”，加上自己精通前端技术，很快跟小伙伴打成一片。我觉得美团的工程师文化还是很好的，“只要你技术好，我就是服你的，可以跟你干”。现在我们团队有100多名小伙伴，管理团队在成员的引入、留存和培养上下足了功夫，资深工程师占比超过30%，是美团比较优秀的团队之一，我也为此骄傲。在此，也欢迎更多的同学加入我们。Q：你觉得美团的技术氛围如何？洪磊：我觉得我们美团的技术氛围挺好的，至少在我待过的几家公司里是最好的。因为我们美团的工程师比较有冲劲，自驱力很强。第二点，再就是大家都愿意去做一些事情，提高整个团队的影响力。在美团这个大家庭里，永远不是一个人在向前跑，而是共同追求进步。Q：平时有哪些爱好？洪磊：一是爱折腾，折腾技术，折腾硬件这些。家里的智能家居系统，都是我自己一个人焊板子，捯饬出来的，我希望家里的东西都是“透明”的，代码也要“透明”。然后，有时间就去旅行，满世界跑。有时一个人，有时约上三两个好友一起自驾。我不太喜欢“走马观花”，更喜欢在一个地方待上一段时间，去体会那里的风土人情，感受当地的文化。旅行时，我不喜欢有太多的规划。很多时候，不知道自己的下一个目的地是哪里，只要一直在路上就好。Q：写代码多少年了？洪磊：要说第一行代码，应该要追溯到2000年左右高二时候了，那时学校还用的是DOS系统，我会用Pascal语言“暴力”获取一些简单游戏的通关步骤。当时“文曲星”上面有一个叫“汉诺塔”的游戏，我就用穷举法找到了最少的移动步骤。第一行PHP代码是2003年写的，直到现在还会偶尔写写。我对写代码这件事兴趣盎然，应该会永远充满激情。Q：对技术同学有哪些建议？洪磊：第一点，我觉得应该深入了解底层的原理，而不要只停留在应用层面。这样才能够真真切切地明白程序运行的机理。第二点，要懂得举一反三，把自己学到的知识，通过加工，创造出更好的实现，使知识得到升华。我感觉中国的工程师比较守规矩，发散性思维较弱，这方面还可以提升很多。第三点，就是要长期有耐心，这也是我们美团倡导的价值观和做事方式。

背景目前，互联网产品呈现出高频优化迭代的趋势，需求方希望尽早地看到结果，并给予及时反馈，所以技术团队需要用“小步快跑”的姿势来做产品，尽早地交付新版本。基于以上背景，美团客户端研发平台适时地推行了单周发版的迭代策略。单周版本迭代的优点可以概括为三个方面：更快地验证产品创意是否符合预期，更灵活地上线节奏，更早地修复线上Bug。首先说一下美团平台的发版策略，主要变更点是由之前的每四周发一版改为每周都有发版。具体对比如下：（旧）三周迭代指的是2周开发+1周半测试，依赖固定的排期和测试时间，如果错过排期，则需要等待至少20天方可跟着下个版本迭代发布，线上验证产品效果的时间偏长。具体示例描述如下：（新）单周版本迭代指一周一发版，单周迭代版本排期、测试不再依赖固定时间节点，需求开发并测试完成，就可以搭乘最近一周的发版“小火车”，跟版发布直接上线。对于一般需求而言，这将会大大缩短迭代时间。业务方研发人员的痛点在之前按月发版的迭代节奏下，基本上所有的需求都属于串行开发，每个版本的开发流程比较固定。从“评审-开发-提测-灰度-上线”各个环节都处于一个固定的时间点来顺序执行，开发人力资源的协调方式也相对简单。全面推进单周发版之后，并不能把所有需求压缩到5天之内开发完成，而是会存在大量的并行开发的场景，之前的固定时间节点全部被打破，由固定周期变成了动态化调配，这给业务方的需求管理和研发人员人力管理都带来了指数式复杂度的提升。一旦进入并行开发，需求之间会产生冲突和依赖关系，版本代码也会随之产生冲突和依赖，这也大大提高了开发过程中的分支管理成本，如何规范化管理分支，降低分支冲突，把控代码质量，是本文接下来要讨论的重点。下面描述了几种典型的单周发版带来的问题：业务需求开发周期不固定，会存在大量的多版本、多需求并行开发。平台只提供了单周发版的基础策略，每5天发一版，业务方完成需求即可搭车发版。对于各业务方来说，需求开发往往并不是都能在5天内完成，一般需求在5~10天左右，在之前串行发版模式下这个问题其实也存在，但并不突出，在单周发版的前提下，都要面临跨版本开发，意味着多个版本多个需求会同步并行开发，这给业务方的分支管理带来了极大的挑战。业务方架构复杂，仓库依赖多，单周发版分支创建合并维护成本大。交通业务线涉及火车票、国内机票、国际机票多条业务线，代码仓库除了业务线的独立仓库，还有交通首页，交通公共仓库，RN仓库等多个仓库，Android端6个Git仓库，iOS端5个仓库，RN5个仓库，共计16个Git仓库。多仓库频繁发版分支代码存在安全风险，容易漏合代码，冲掉线上代码。业务线自身的公共基础库需求变动频繁。也需要具备单周发版的能力。例如交通公共基础仓库，承载了很多交通业务线的UI功能组件，这些公共组件的业务变化频繁，公共基础仓库变化的同时，可能会对使用组件的业务产生影响，需要同步的升级发版。美团平台的策略是公共服务组件每四个小版本统一升级一次，但对业务方自身组件这种策略限制较大，还是需要公共组件也要具备随时发版的能力。单周发版分支管理解决方案针对上面提出的问题，交通客户端团队通过技术培训、流程优化、关键点检测、自动化处理等方式保证分支代码的安全。技术培训主要是加强技术人员分支管理的基本知识，Git的正确使用方法，这里不做过多描述。本文主要讨论关键点检测，以及如何进行自动化的分支管理。在实施单周发版之前，业务方代码仓库只有两个分支，Develop分支，即开发分支；Stage分支，即发版分支；开发流程基本在串行开发模式，每个版本10天开发，8天测试，然后进入下一版本的开发。这种方式只能适用于节奏固定的长周期开发方式，对于多版本并行开发来说，有点力不从心，显然已经不能承载当前更灵活的发版节奏。针对这些问题，我们推出了如下分支管理结构。总的来说，就是废除之前作为开发分支的Develop分支，建立对应的Release发版分支，每个版本打包从Release分支直接打包；同时Stage分支不再承担打包职责，而是作为一个主干分支实时同步所有已发布上线的功能，Stage分支更像一个“母体”，孵化出Release分支和其它Feature分支；当Release分支测试通过、并且发版上线之后，再合入到Stage分支，此时所有正在开发中的其它分支都需要同步Stage分支的最新代码，保证下一个即将发布的版本的功能代码的完整性。上面的流程描述可能有些复杂，下面是简化的流程图，每个版本都有自己的生命周期：从Stage创建一个Release分支；进入开发阶段；如果Stage分支有变化，同步Stage分支；打包测试；测试通过，发布线上；发布线上之后，合回Stage分支。为了适应单周发版，新的开发流程也引入了很多新的挑战。例如下图所示的一个Branch分支中涉及的六个关键点：创建分支、合入主干、主干变化通知、Merge主干变化、检测主干同步、未同步拦截，除了这些还要考虑多仓库同步操作的问题，还有热修复版本的管理方式的问题。能否把这些关键节点合理的规范和把控起来，是我们当前应对多分支并行开发的主要难点：如何更高效的解决这些问题呢？结合我们当前使用的工具：Git + Atlassian Stash 代码仓库管理工具；Jenkins Build打包工具；大象（美团内部通讯工具）内网通信工具。目前这三个开发工具已经非常成熟、稳定，并且接口丰富易于扩展，我们需要配合当前单周发版的分支管理模式，利用这些工具来进行扩展开发，正所谓“要站在巨人的肩膀上”。创建分支Release分支如何创建，何时创建，分支命名规范定义如何约束？创建Release分支，本质上是从Stage新建一个分支，当前提前一个周期创建新的发版分支，例如在10.1.1版本Release后，创建10.1.3版本的分支，此时10.1.2版本处于开发测试阶段。业务方所有的分支命名和平台的分支命名保持一致，采用Release/x.x.x的格式，但同时需要升级成为即将发布的Release版本号，例如10.1.3。现在交通业务线多达十几个仓库，每个仓库每周都要操作一次需要耗费大量人力。之前每个分支的创建都是通过Stash或者手工创建，能不能自动化批处理的创建呢？答案是肯定的。对此，我们采用了Jenkins的方式，需要建立一个Jenkins Job, 基本原理就是通过命令行的方式进行Branch的创建，然后通过Job管理，批处理建立所有仓库的Release分支，这样就收敛了Branch的创建，即采用统一的命名规范，并且同时升级版本号。这就解决了创建分支的难点，实现了自动化创建分支，并且实现了规范化命名。如何知道Stage分支有变化，变化后需要做什么，不做会怎样？一个好的开发习惯，就是每天写码之前都同步主分支，但是还是需要一个机制来确保同步。这里做了三个措施来确保各个分支和Stage是保持同步的：一个通知，一个警告，一次拦截。这三个步骤解决主干变化通知、检测主干同步、未同步拦截的问题。一个通知：具体路径如下，建立了一个内部推送公众账号和一个Jenkins监听Job，当所有交通业务仓库Stage分支有代码改动，通知所有对应的开发人员，该仓库有代码变化，请及时合入。 一次警告：本地开发过程中，每次提交代码到远端仓库时，会触发一个Stage分支代码同步检测的脚本，如果发现未同步，会通过内部通讯系统通知提交者存在未同步主分支问题。但这里目前并不做强制拦截，保证分支代码开发的整体流畅性。最终拦截：在开发分支打包的过程中强制拦截，最终功能代码上线还是需要打包操作。在打包操作时统一收口，由于之前打包也是在Jenkins上来完成的，这里我们也是通过在打包Jenkins上接入了分支合并检测的插件，这样每次打包时会再次检测和主分支的同步情况。如果发现未同步则打包失败，确保每次发版都包含当前线上已有代码的功能，防止新版本丢失功能。如何合并分支，如何保证漏合？和上面提到的第一个如何创建分支的问题类似，通过Jenkins Job来进行批量操作，可以一键创建所有分支的Pull Request；在每个版本发版之前，统一进行一次打包，合入美团的主分支，防止多个仓库有漏合的情况。公共基础库版本策略？公共基础和业务分支保持同样的策略，通过批处理脚本同时建立分支，合并分支，监听分支变化，需要注意的是，每次版本升级，公共基础库也需要同步的打包，并且强制业务库升级。不然，如果基础仓库存在接口变动，有的业务升级了，有的业务没升级，最终会导致无法合入主分支，进而无法打出App包。热修复的版本管理策略？热修复确实是一种非常规的处理方式。从原则上来讲，热修复需要在对应的Release分支上进行修改，然后把修改合入Stage分支，同时需要同步到其它正在开发的分支。实际的处理需要根据具体情况来分析，是否需要对线上多个版本热修复。如果多版本都要修复就不能再合入Stage分支，否则会导致Stage分支冲突，如果把Stage分支合入需要热修复的其它分支，会把线上当前最新代码带入历史旧版本，会导致版本兼容性问题。最终执行起来可能还是对热修复版本进行单独处理，不一定要进行Stage主分支的同步，热修复的版本管理成本会比较高，更多的需要人工介入。未来展望目前整体的分支发版流程已经基本完成，现在已经稳定运行了10个小版本，同时没有出现因为分支管理问题而引发的线上问题。不过，当前整体流程的自动化程度还有待提高，每周需要人工去触发，很多代码合并过程中的冲突问题还需要人工去解决。未来我们希望能够自动化地根据平台的版本号自动创建分支，并且对于一些简单的冲突问题拥有自动化的处理能力。随着单周发版的不断成熟，未来对于持续交付能力也将不断提升，发版节奏可以不限于单周，一周两版或是更快的发版节奏也成为一种新的可能。作者介绍王坤，美团客户端开发工程师，2016年加入美团，目前主要负责大交通业务的客户端架构、版本管理及相关工作。

本文根据美团高级技术专家翟艺涛在2018 QCon全球软件开发大会上的演讲内容整理而成，内容有修改。引言2018年12月31日，美团酒店单日入住间夜突破200万，再次创下行业的新纪录，而酒店搜索在其中起到了非常重要的作用。本文会首先介绍一下酒店搜索的业务特点，作为O2O搜索的一种，酒店搜索和传统的搜索排序相比存在很大的不同。第二部分介绍深度学习在酒店搜索NLP中的应用。第三部分会介绍深度排序模型在酒店搜索的演进路线，因为酒店业务的特点和历史原因，美团酒店搜索的模型演进路线可能跟大部分公司都不太一样。最后一部分是总结。酒店搜索的业务特点美团的使命是帮大家“Eat Better，Live Better”，所做的事情就是连接人与服务。用户在美团平台可以找到他们所需要的服务，商家在美团可以售卖自己提供的服务，而搜索在其中扮演的角色就是“连接器”。大部分用户通过美团App找酒店是从搜索开始的，搜索贡献了大部分的订单，是最大的流量入口。在美团首页点击 “酒店住宿”图标，就会进入上图右侧的搜索入口，用户可以选择城市和入住时间并发起搜索。酒店搜索技术团队的工作不仅有搜索排序，还有查询引导、推荐等工作，查询引导如搜索智能提示、查询纠错等。之所以还有推荐的工作，是因为很多用户在发起搜索时不带查询词，本质上属于推荐，此外还有特定场景下针对少无结果的推荐等。本文主要介绍搜索排序这方面的工作。不同搜索对比现在，大家对搜索都很熟悉，常见的有网页搜索，比如Google、百度、搜狗等；商品搜索，像天猫、淘宝、京东等；还有就是O2O（Online To Offline）的搜索，典型的就是酒店的搜索。虽然都是搜索，但是用户使用搜索的目的并不相同，包括找信息、找商品、找服务等等，不同搜索之间也存在很大的差别。上图对不同搜索进行了简单对比，可以从5个维度展开。首先是目标维度。因为用户是来找信息，网页搜索重点是保证查询结果和用户意图的相关性，而在商品搜索和酒店搜索中，用户的主要目的是查找商品或服务，最终达成交易，目标上有较大区别。用户使用不同搜索的目的不同，从而导致不同搜索对个性化程度的要求不同。交易属性的搜索，包括商品搜索和酒店搜索，对个性化程度的要求都比较高，因为不同用户的消费水平不同，偏好也不一样。在技术层面上，也存在很多不同点。网页搜索会索引全网的数据，这些数据不是它自己生产，数据来源非常多样，包括新闻、下载页、视频页、音乐页等各种不同的形态，所以整个数据是非结构化的，差异也很大。这意味着网页搜索需要拥有两种技术能力，数据抓取能力和数据解析能力，它们需要抓取网页并解析形成结构化数据。在这个层面上，酒店搜索和商品搜索相对就“幸福”一些，因为数据都是商家提交的结构化数据，相对来说更加规范。此外，酒店作为一种O2O的服务，用户在线上（Online）下单，最终需要到线下（Offline）去消费，所以就有一个位置上的约束，而位置的约束也就导致出现供给侧的约束，供给只能在某个特定位置附近。比如北京大学方圆几公里之内的酒店。这两点约束在网页搜索和商品搜索中就不用考虑，网页可以无限次的进行阅读。商品搜索得益于快递业的快速发展，在北京也可以买到来自浙江的商品，供给侧的约束比较小。介绍完不同搜索产品的特点，接下来看不同搜索产品的优化目标。通用搜索的优化目标是相关性，评价指标是DCG、NDCG、MAP等这些指标，要求查询结果和用户意图相关。对商品搜索来说，不同电商平台的优化目标不太一样，有的目标是最大化GMV，有的目标是最大化点击率，这些在技术上都可以实现。而对酒店搜索而言，因为它属于O2O的业务形态，线上下单，线下消费，这就要求搜索结果必须和用户的查询意图“强相关”。这个“强相关”包括两层含义，显性相关和隐性相关。举个例子，用户搜索“北京大学”，那么他的诉求很明确，就是要找“北京大学”附近的酒店，这种属于用户明确告诉平台自己的位置诉求。但是，如果用户在本地搜索“七天”，即使用户没有明确说明酒店的具体位置，我们也知道，用户可能想找的是距离自己比较近的“七天酒店”，这时候就需要建模用户的隐性位置诉求。美团是一个交易平台，大部分用户使用美团是为了达成交易，所以要优化用户的购买体验。刻画用户购买体验的核心业务指标是访购率，用来描述用户在美团是否顺畅的完成了购买，需要优化访购率这个指标。总结一下，酒店搜索不仅要解决相关性，尽量优化用户购买体验、优化访购率等指标，同时还要照顾到业务诉求。根据上面的分析，酒店搜索的整个搜索框架就可以拆分成三大模块：检索、排序以及业务规则。检索层包括查询理解和召回两部分，主要解决相关性问题。查询理解做的事情就是理解用户意图，召回根据用户意图来召回相关的酒店，两者强耦合，需要放在一起。检索的核心是语义理解，比如用户搜索“北京大学”，平台就知道用户想找的是“北京大学附近的酒店”，所以这个模块的优化方式是问题驱动，不断地发现问题、解决问题来进行迭代。接下来，从检索模块检索出来的酒店都已经是满足用户需求的酒店了。还是上面“北京大学”的那个例子，检索模块已经检索出来几百家“北京大学”附近的酒店，这些都是和用户的查询词“北京大学”相关的，怎么把用户最有可能购买的酒店排到前面呢？这就是排序模块要做的事情。排序模块使用机器学习和深度学习的技术提供“千人千面”的排序结果，如果是经常预定经济连锁型酒店的用户，排序模块就把经济连锁型酒店排到前面。针对消费水平比较高，对酒店要求比较高的用户，排序模块就把高档酒店排到前面，对每个用户都可以做到个性化定制。排序属于典型的技术驱动模块，优化目标是访购率，用这个技术指标驱动技术团队不断进行迭代和优化。最后是业务层面，比如有些商家会在美团上刷单作弊，针对这些商家需要做降权处理。整体框架上图是搜索的整体框架，这里详细描述下调用过程：搜索API负责接收用户的查询词并发送给搜索控制中心。控制中心把接收到的查询请求发送到检索与意图模块，搜索词会先经过查询分析模块做用户的查询意图分析，分析完之后，会把用户的查询意图分析结果传回去给业务检索模块，业务检索模块根据意图识别结果形成查询条件，然后去基础检索端查询结果。基础检索访问索引得到查询结果后，再把结果返回给上层。业务检索模块获取基础的检索结果后，会调用一些外部服务如房态服务过滤一些满房的酒店，再把结果返回给控制中心。此时，控制中心得到的都是和用户查询意图强相关的结果，这时就需要利用机器学习技术做排序。通过预测模块对每个酒店做访购率预测，控制中心获取预测模块的排序结果后，再根据业务逻辑做一些调整，最终返回结果给搜索API。可以看到，模块划分和前文描述的思想一致，检索模块主要解决用户意图识别和召回问题，也就是解决相关性。预测模块做访购率预测，业务逻辑放在搜索控制中心实现。接下来会介绍一下意图理解和排序模块中涉及的一些深度学习技术。先来看下查询理解的问题，这个模块通过数据分析和Case分析，不断的发现问题、解决问题来迭代优化。之前的评测发现少无结果的原因，主要包括以下几种：地标词：比如用户搜索“望京国际研发园”，但是后台没有一家酒店包含“望京国际研发园”这几个字，其实用户想找的是望京国际研发园附近的酒店。结构化查询：比如芍药居附近7天，酒店描述信息中没有“附近”这个词，搜索体验就比较差。这种需要对查询词做成分识别，丢掉不重要的词，并且对不用类别的Term走不同的检索域。异地查询：用户在北京搜索“大雁塔”没有结果，其实用户的真实意图是西安大雁塔附近的酒店，这种需要做异地需求识别并进行异地跳转。同义词：在北京搜索“一中”和搜索“北京第一中学”，其实都是同一个意思，需要挖掘同义词。针对这几类问题，我们分别作了以下工作：针对地标词问题，提供地标意图识别和地标策略，把地标类别的查询词改成按经纬度进行画圈检索。针对结构化查询的问题，我们对查询词做了成分识别，设计了少无结果时的多级检索架构。针对异地查询的问题，做异地意图识别和异地的跳转引导。针对语义查询的问题，做同义词和查询改写。这里的每一个模块都用到了机器学习和深度学习的技术，本文挑选两个酒店搜索中比较特殊的问题进行介绍。地标问题是O2O搜索的一个典型问题，在网页搜索和商品搜索中都较少出现此类问题。当用户搜索类似“望京国际研发园”这种查询词的时候，因为搜索的相关性是根据文本计算的，需要酒店描述中有相关文字，如果酒店的描述信息中没有这个词，那就检索不出来。比如昆泰酒店，虽然就在望京国际研发园旁边，但是它的描述信息中并没有出现“望京国际研发园”，所以就无法检索出来，这会导致用户体验较差。经过分析，我们发现有一类查询词是针对特定地点的搜索，用户的诉求是找特定地点附近的酒店，这种情况下走文本匹配大概率是没有结果的。这个问题的解法是针对这种类型的查询词，从“文本匹配”改成“坐标匹配”，首先分析查询词是不是有地标意图，如果是的话就不走文本匹配了，改走坐标匹配，检索出来这个坐标附近的酒店就可以了。这时就产生了两个问题：第一，怎么确定哪些查询词有地标意图；第二，怎么获取经纬度信息。针对这个问题，我们做了地标策略，步骤如下：多渠道获取可能包含地标词的候选集，这些候选集包括用户少无结果的查询词，以及一些酒店提供的描述信息。对候选集合进行命名实体识别（NER，Named Entity Recognition），可以得到各个命名实体的类型，标识为“地标”类型的就是疑似地标词。把疑似地标词放到美团地图服务中获取经纬度，经过人工校验无误后，存入线上数据库中；线上来查询请求时，先会去匹配精准地标库，如果匹配成功，说明这个查询词是地标意图，这时就不走文本检索了，直接在意图服务层走经纬度检索。经过人工校验的精准地标库补充到NER模型的训练数据中，持续优化NER模型。这里提到了NER模型，下面对它做一下详细的介绍。NER是命名实体识别，是机器学习中的序列标注问题，比如输入“北大附近的七天”，就会标注出来每个词的成分，这里“北大”是地标，“七天”是酒店品牌。这里的类别是根据业务特点自己定义的，酒店业务中有地标、品牌、商圈等不同的类别。与分类问题相比，序列标注问题中当前的预测标签不仅与当前的输入特征相关，还与前后的预测标签相关，即预测标签序列之间有强相互依赖关系。 解决序列标注问题的经典模型是CRF（Conditional Random Field，条件随机场），也是我们刚开始尝试的模型。条件随机场可以看做是逻辑回归的序列化版本，逻辑回归是用于分类的对数线性模型，条件随机场是用于序列化标注的对数线性模型，可以看做是考虑了上下文的分类模型。机器学习问题的求解就是“数据+模型+特征”，数据方面先根据业务特点定义了几种实体类别，然后通过“人工+规则”的方法标注了一批数据。特征方面提取了包括词性、Term文本特征等，还定义了一些特征模板，特征模板是CRF中人工定义的一些二值函数，通过这些二值函数，可以挖掘命名实体内部以及上下文的构成特点。标注数据、模型、特征都有了，就可以训练CRF模型，这是线上NER问题的第一版模型。随着深度学习的发展，用Word Embedding词向量作为输入，叠加神经网络单元的方法渐渐成为NLP领域新的研究方向。基于双向LSTM（Long Short-Term Memory）+CRF的方法成为NER的主流方法，这种方法采用双向LSTM单元作为特征提取器替代原有的人工特征，不需要专门的领域知识，框架也通用。Embedding输入也有多种形式，可以是词向量，可以是字向量，也可以是字向量和词向量的拼接。我们尝试了双向LSTM+CRF，并在实际应用中做了些改动：由于在CRF阶段已经积累了一批人工特征，实验发现把这些特征加上效果更好。加了人工特征的双向LSTM+CRF是酒店搜索NER问题的主模型。当然，针对LSTM+CRF的方法已经有了很多的改进，比如还有一种NER的方法是融合CNN+LSTM+CRF，主要改进点是多了一个CNN模块来提取字级别的特征。CNN的输入是字级别的Embedding，通过卷积和池化等操作来提取字级别的特征，然后和词的Embedding拼接起来放入LSTM。这种方法在两个公开数据集上面取得了最好的结果，也是未来尝试的方向之一。为了解决少无结果的问题，我们设计了多级检索架构，如上图所示，主要分4个层次：基本检索、二次检索、核心词检索和异地检索。基本检索会根据查询词的意图选择特定的检索策略，比如地标意图走经纬度检索，品牌意图只检索品牌域和商家名。基本检索少无结果会进行二次检索，二次检索也是分意图的，不同意图类型会有不同的检索策略，地标意图是经纬度检索的，二次检索的时候就需要扩大检索半径；品牌意图的查询词，因为很多品牌在一些城市没有开店，比如香格里拉在很多小城市并没有开店，这时比较好的做法，是推荐给用户该城市最好的酒店。如果还是少无结果，会走核心词检索，只保留核心词检索一遍。丢掉非核心词有多种方式，一种是删除一些运营定义的无意义词，一种是保留NER模型识别出来的主要实体类型。此外还有一个TermWeight的模型，对每个词都有一个重要性的权重，可以把一些不重要的词丢掉。在还没有结果的情况下，会选择”异地＋全国“检索，即更换城市或者在全国范围内进行检索。多级检索架构上线后，线上的无结果率就大幅度降低了。排序排序其实是一个典型的技术问题，业界应用比较广泛的有广告排序和推荐排序，广告排序比如Google和百度的关键字广告排序，今日头条、腾讯的展示广告排序。推荐排序比如快手、抖音这些短视频平台，以及各大App、浏览器的信息流。广告排序和推荐排序优化的目标都是点击率，技术栈也比较相似，包括LR/FTRL、FM/FFM、GBDT、DNN等模型。跟以上两种排序应用相比，酒店排序有自己的业务特点，因为美团酒店具有LBS属性和交易属性，天生自带很多连续特征，如酒店价格、酒店评分、酒店离用户的距离等，这些连续特征是决定用户购买行为的最重要因素。优化目标也不一样，大部分场景下酒店搜索的优化目标是访购率，部分场景下优化目标是点击率。在技术层面，酒店排序整体的技术栈和广告、推荐比较相似，都可以使用LR/FTRL、FM/FFM、GBDT、DNN等模型。面临的挑战具体到酒店排序工作，我们面临一些不一样的挑战，主要包括以下4点：数据稀疏。住酒店本身是一种低频行为，大部分用户一年也就住一两次，导致很多特征的覆盖率比较低。业务众多。美团酒店包括国内酒店业务、境外酒店业务，以及长租、钟点房等业务，同时有美团和点评两个不同的App。场景复杂。按照用户的位置可以分成本地和异地，按照用户的诉求可以分成商务、旅游、本地休闲等几大类，这些用户之间差异很明显。比如商务用户会有大量复购行为，典型例子是美团员工的出差场景，美团在上海和北京各有一个总部，如果美团的同学去上海出差，大概率会在公司差旅标准内选一家离公司近的酒店，从而会在同一家酒店产生大量的复购行为；但是如果是一个旅游用户，他就很少反复去同一个地方。供给约束。酒店行业供给的变化很快，一个酒店只有那么多房间，一天能提供的间夜量是固定的，全部订出的话，用户提价也不会提供新的房间，这种情况在劳动节、国庆这种节假日特别明显。上图右侧是排序的整体架构图，分为线下、线上和近线上三个部分。在线下部分，主要做离线的模型调优和评估，线上部分做预测。这里比较特别的是近线上部分，我们在实时层面做了大量的工作，包括用户的实时行为、酒店实时价格、实时库存等等，以应对供给变化快的特点。这里介绍一个业务特点导致的比较独特的问题：模型切分。美团酒店有很多业务场景，包括国内酒店、境外酒店、长租、钟点房等；还有两个App，美团App和大众点评App；还有搜索和筛选两种场景，搜索带查询词，筛选没有查询词，两种场景差异较大；从地理位置维度，还可以分成本地和异地两种场景。面对这么多的业务场景，第一个问题就是模型怎么设计，是用统一的大模型，还是分成很多不同的小模型？我们可以用一个大模型Cover所有的场景，用特征来区分不同场景的差异，好处是统一模型维护和优化成本低。也可以划分很多小模型，这里有一个比较好的比喻，多个专科专家会诊，胜过一个全科医生。切分模型后，可以避免差异较大的业务之间互相影响，也方便对特殊场景进行专门的优化。在模型切分上，主要考虑三个因素：第一，业务之间的差异性。比如长租和境外差异很大，国内酒店和境外业务差异也很大，这种需要拆分。第二，细分后的数据量。场景分的越细，数据量就越小，会导致两个问题，一是特征的覆盖率进一步降低；二是数据量变小后，不利于后续的模型迭代，一些复杂模型对数据量有很高的要求。我们做过尝试，国内酒店场景下，美团和大众点评两个App数据量都很大，而且用户也很不一样，所以做了模型拆分；但是境外酒店，因为本身是新业务数据量较小，就没有再进行细分。第三，一切以线上指标为准。我们会做大量的实验，看当前数据量下怎么拆分效果更好，比如美团App的国内酒店，我们发现把搜索和筛选拆开后，效果更好；筛选因为数据量特别大，拆分成本、异地效果也更好，但是如果搜索场景拆分成本地、异地模型就没有额外收益了。最终，一切都要以线上的实际表现为准。模型演进接下来介绍一下排序模型的演进过程，因为业务特点及历史原因，酒店搜索的排序模型走了一条不一样的演进路线。大家可以看业界其他公司点击率模型的演进，很多都是从LR/FTRL开始，然后进化到FM/FFM，或者用GBDT+LR搞定特征组合，然后开始Wide&Deep。酒店搜索的演进就不太一样。酒店业务天生自带大量连续特征，如酒店价格、酒店和用户的距离、酒店评分等，因此初始阶段使用了对连续特征比较友好的树模型。在探索深度排序模型的时候，因为已经有了大量优化过的连续特征，导致我们的整个思路也不太一样，主要是借鉴一些模型的思想，结合业务特点做尝试，下面逐一进行介绍。初始阶段线上使用的模型是XGB(XGBoost, eXtreme Gradient Boosting)。作为GBDT的改进，XGB实现了非线性和自动的特征组合。树节点的分裂其实就实现了非线性，树的层次结构实现了不同特征的自动组合，而且树模型对特征的包容性非常好，树的分裂通过判断相对大小来实现，不需要对特征做特殊处理，适合连续特征。树模型的这些特点确实很适合酒店这种连续特征多的场景，至今为止，XGB都是数据量较小场景下的主模型。但是树模型优化到后期遇到了瓶颈，比如特征工程收益变小、增大数据量没有额外收益等，此外树模型不适合做在线学习的问题愈发严重。酒店用户在劳动节、国庆节等节假日行为有较大不同，这时需要快速更新模型，我们尝试过只更新最后几棵树的做法，效果不佳。考虑到未来进一步的业务发展，有必要做模型升级。模型探索的原则是从简单到复杂，逐步积累经验，所以首先尝试了结构比较简单的MLP(Multiple-Layer Perception)多层感知机，也就是全连接神经网络。神经网络是一种比树模型“天花板”更高的模型，“天花板”更高两层意思：第一层意思，可以优化提升的空间更大，比如可以进行在线学习，可以做多目标学习；第二层意思，模型的容量更大，“胃口”更大，可以“吃下”更多数据。此外它的表达能力也更强，可以拟合任何函数，网络结构和参数可以调整的空间也更大。但是它的优点同时也是它的缺点，因为它的网络结构、参数等可以调整的空间更大，神经网需要做很多的参数和网络结构层面的调整。上图是MLP的网络结构图，包含输入层、若干个隐藏层、输出层。在很长一段时间内，在特征相同的情况下，MLP效果不如XGB，所以有段时间线上使用的是XGB和MLP的融合模型。后来经过大量的网络结构调整和参数调整，调参经验越来越丰富，MLP才逐步超越XGB。这里额外说明一下，酒店搜索中有少量的ID类特征，在第一版MLP里ID类特征是直接当做连续特征处理的。比如城市ID，ID的序关系有一定的物理意义，大城市ID普遍较小，小城市开城晚一些，ID较大。在MLP阶段我们对网络结构做了大量实验，尝试过三种网络结构：平行结构、菱形结构、金字塔结构。在很多论文中提到三者相比平行结构效果最好，但是因为酒店搜索的数据不太一样，实验发现金字塔结构效果最好，即上图最右边的“1024-512-256”的网络结构。同时还实验了不同网络层数对效果的影响，实验发现3-6层的网络效果较好，更深的网络没有额外收益而且线上响应时间会变慢，后面各种模型探索都是基于3到6层的金字塔网络结构进行尝试。MLP上线之后，我们开始思考接下来的探索方向。在树模型阶段，酒店搜索组就在连续特征上做了很多探索，连续特征方面很难有比较大的提升空间；同时业界的研究重点也放在离散特征方面，所以离散特征应该是下一步的重点方向。深度排序模型对离散特征的处理有两大类方法，一类是对离散特征做Embedding，这样离散特征就可以表示成连续的向量放到神经网络中去，另一类是Wide&Deep，把离散特征直接加到Wide侧。我们先尝试了第一种，即对离散特征做Embedding的方法，借鉴的是FNN的思想。其实离散特征做Embedding的想法很早就出现了，FM就是把离散特征表示成K维向量，通过把高维离散特征表示成低维向量增加模型泛化能力。实际使用中，我们稍微做了一些改动，实验中发现使用FM预训练的效率不高，所以尝试了不做预训练直接把Embedding随机初始化，然后让Embedding跟随网络一起学习，实验结果发现比FM预训练效果还要好一点。最后的做法是没有用FM做预训练，让Embedding随机初始化并随网络学习，上图是线上的V3模型。FNN的成功上线证明离散特征Embedding这个方向值得深挖，所以我们接着实验了DeepFM。DeepFM相对于Wide&Deep的改进，非常类似于FM相对LR的改进，都认为LR部分的人工组合特征是个耗时耗力的事情，而FM模块可以通过向量内积的方式直接求出二阶组合特征。DeepFM使用FM替换了Wide&Deep中的LR，离散特征的Embedding同时“喂”给神经网和FM，这部分Embedding是共享的，Embedding在网络的优化过程中自动学习，不需要做预训练，同时FM Layer包含了一阶特征和二阶的组合特征，表达能力更强。我们尝试了DeepFM，线下有提升线上波动提升，并没有达到上线的标准，最终没有全量。尽管DeepFM没有成功上线，但这并没有动摇我们对Embedding的信心，接下来尝试了PNN。PNN的网络重点在Product上面，在点击率预估中，认为特征之间的关系更多是一种And“且”的关系， 而非Add“加”的关系，例如性别为男且用华为手机的人，他定酒店时属于商务出行场景的概率更高。PNN使用了Product Layer进行显式的二阶特征组合。上图右边是PNN的网络结构图，依然对离散特征做Embedding，Embedding向量同时送往隐层和Product层，Product通过内积或者外积的方式，对特征做显式的二阶交叉，之后再送入神经网的隐层，这样可以做到显式的二阶组合和隐式的高阶特征组合。特征交叉基于乘法的运算实现，有两种方式：内积和外积。我们尝试了内积的方式，线下略有提升线上也是波动提升，没有达到上线标准，所以最终也没有全量上线。PNN之后我们认为Embedding还可以再尝试一下，于是又尝试了DCN（Deep&Cross Network）。DCN引入了一个Cross Network进行显式的高阶特征交叉。上图右边是论文中的图，可以看到Deep&Cross中用了两种网络，Deep网络和Cross网络，两种网络并行，输入都一样，在最后一层再Stack到一起。Deep网络和前面几种网络一样，包括连续特征和离散特征的Embedding，Cross网络是DCN的特色，在Cross网络里面，通过巧妙的设计实现了特征之间的显式高阶交叉。看上图左下角的Cross结构示意，这里的x是每一层的输入，也就是上一层的输出。Feature Crossing部分包括了原始输入x0、本层输入x的转置、权重w三项，三项相乘其实就做了本层输入和原始输入的特征交叉，x1就包含了二阶的交叉信息，x2就包含了三阶的交叉信息，就可以通过控制Cross的层数显式控制交叉的阶数。不得不说，DCN在理论上很漂亮，我们也尝试了一下。但是很可惜，线下有提升线上波动提升，依然未能达到上线的标准，最终未能全量上线。经过DeepFM、PNN、DCN的洗礼，促使我们开始反思，为什么在学术上特别有效的模型，反而在酒店搜索场景下不能全量上线呢?它们在线下都有提升，在线上也有提升，但是线上提升较小且有波动。经过认真分析我们发现可能有两个原因：第一，连续特征的影响，XGB时代尝试了600多种连续特征，实际线上使用的连续特征接近400种，这部分特征太强了; 第二，离散特征太少，离散特征只有百万级别，但是Embedding特别适合离散特征多的情况。接下来方向就很明确了：补离散特征的课。最终，我们还是把目光转回Wide&Deep。Wide&Deep同时训练一个Wide侧的线性模型和一个Deep侧的神经网络，Wide部分提供了记忆能力，关注用户有过的历史行为，Deep部分提供了泛化能力，关注一些没有历史行为的Item。之前的工作主要集中在Deep测，对低阶特征的表达存在缺失，所以我们添加了LR模块以增加对低阶特征的表达，Deep部分和之前的V3一样。刚开始只用了少量的ID类特征，效果一般，后来加了大量人工的交叉特征，特征维度达到了亿级别后效果才得到很好的提升。下图是我们的V4模型：接下来介绍一下优化目标的迭代过程（后面讲MTL会涉及这部分内容）。酒店搜索的业务目标是优化用户的购买体验，模型的优化指标是用户的真实消费率，怎么优化这个目标呢? 通过分析用户的行为路径可以把用户的行为拆解成“展示->点击->下单->支付->消费”等5个环节，这其中每个环节都可能存在用户流失，比如有些用户支付完成后，因为部分商家确认比较慢，用户等不及就取消了。刚开始我们采用了方案1，对每一个环节建模（真实消费率=用户点击率×下单率×支付率×消费率）。优点是非常简单直接且符合逻辑，每个模块分工明确，容易确认问题出在哪里。缺点也很明显，首先是特征重复，4个模型在用户维度和商家维度的特征全部一样，其次模型之间是相乘关系且层数过多，容易导致误差逐层传递，此外4个模型也增加了运维成本。后来慢慢进化到了方案2的“End to End”方式，直接预测用户的真实消费率，这时只需要把正样本设定为实际消费的样本，一个模型就够了，开发和运维成本较小，模型间特征也可以复用，缺点就是链路比较长，上线时经常遇到AB测抖动问题。模型切换到神经网络后就可以做多任务学习了，之前树模型时代只预测“End to End”真实访购率，神经网络则可以通过多任务学习同时预测CTR展示点击率和CVR点击消费率。多任务学习通过硬共享的方式同时训练两个网络，特征、Embedding层、隐层参数都是共享的，只在输出层区分不同的任务。上图是酒店搜索当前线上的模型，基于Wide&Deep做的多任务学习。网络结构演进路线上图是酒店搜索排序的深度排序模型演进路线，从MLP开始，通过对离散特征做Embedding进化到FNN，中间尝试过DeepFM、PNN、DCN等模型，后来加入了Wide层进化到Wide&Deep，现在的版本是一个MTL版的Wide&Deep，每个模块都是累加上去的。除了上面提到的模型，我们还探索过这个:这是我们自己设计的混合网络，它融合了FNN、DeepFM、PNN、DCN、Wide&Deep等不同网络的优点，同时实现了一阶特征、显式二阶特征组合、显式高阶特征组合、隐式高阶特征组合等，有兴趣的同学可以尝试一下。不同模型实验结果上图是不同模型的实验结果，这里的BP是基点（Basis Point），1BP=0.01%。XGB是Baseline，MLP经过很长时间的调试才超过XGB，MLP和XGB融合模型的效果也很好，不过为了方便维护，最终还是用FNN替换了融合模型。Wide&Deep在开始阶段，提升并没有特别多，后来加了组合特征后效果才好起来。我们Embedding上面的尝试，包括DeepFM、Deep&Cross等，线下都有提升，线上波动有提升，但是未能达到上线的标准，最终未能全量。在特征预处理方面对连续特征尝试了累计分布归一化、标准化，以及手工变换如根号变换、对数变换等；累积分布归一化其实就是做特征分桶，因为连续特征多且分布范围很广，累积分布归一化对酒店搜索的场景比较有效。离散特征方面尝试了特征Embedding及离散特征交叉组合，分别对应FNN和 Wide&Deep。这里特别提一下缺失值参数化，因为酒店业务是一种低频业务，特征覆盖率低，大量样本存在特征缺失的情况，如果对缺失特征学一个权重，非缺失值学一个权重效果较好。参数调优方面分别尝试了激活函数、优化器等。激活函数尝试过Sigmoid、ReLU、Leaky_ReLU、ELU等；优化器也实验过Adagrad、Rmsprop、Adam等；从实验效果看，激活函数ReLU+Adam效果最好。刚开始时，加了Batch Normalization层和Dropout层，后来发现去掉后效果更好，可能和酒店搜索的数据量及数据特点有关。网络结构和隐层数方面用的是3到6层的金字塔网络。学习率方面的经验是学习率小点比较好，但是会导致训练变慢，需要找到一个平衡点。下面介绍深度排序模型线上Serving架构的演化过程，初始阶段组内同学各自探索，用过各种开源工具如Keras、TensorFlow等，线上分别自己实现，预测代码和其他代码都放一起，维护困难且无法复用。后来组内决定一起探索，大家统一使用TensorFlow，线上用TF-Serving，线上线下可以做到无缝衔接，预测代码和特征模块也解耦了。现在则全面转向MLX平台，MLX是美团自研的超大规模机器学习平台，专为搜索、推荐、广告等排序问题定制，支持百亿级特征和流式更新，有完善的线上Serving架构，极大地解放了算法同学的生产力。最后介绍一下我们对搜索排序技术节奏的一些理解，简单来说就是在不同阶段做不同的事情。 在上图中，横轴表示技术深度，越往右技术难度越大，人力投入越大，对人的要求也越高。纵轴是业务阶段。业务阶段对技术的影响包括两方面，数据量和业务价值。数据量的大小，可以决定该做什么事情，因为有些技术在数据量小的时候意义不大；业务价值就更不用说了，业务价值越大越值得“重兵投入”。起步阶段：起步阶段，还没有数据，这时候做简单排序就好，比如纯按价格排序或者距离排序，目的是让整个流程快速地跑起来，能提供最基本的服务。比如2017年，美团的长租业务当时就处于起步阶段。业务初期：随着业务的发展，就进入了业务发展初期，订单数慢慢增长，也有了一些数据，这时候可以增加一些启发式规则或者简单的线性模型，检索模型也可以加上。但是由于数据量还比较小，没必要部署很复杂的模型。稳定成长期：业务进一步发展后，就进入了稳定成长期，这时候订单量已经很大了，数据量也非常大了，这段时间是“补课”的时候，可以把意图理解的模块加上，排序模型也会进化到非线性模型比如XGB，会做大量的特征工程，实时特征以及实时模型，在这个阶段特征工程收益巨大。技术瓶颈期：这个阶段的特点是基本的东西都已经做完了，在原有的技术框架下效果提升变的困难。这时需要做升级，比如将传统语义模型升级成深度语义模型，开始尝试深度排序模型，并且开始探索强化学习、多模型融合、多目标学习等。中国有句俗话叫“杀鸡焉用牛刀”，比喻办小事情，何必花费大力气，也就是不要小题大做。其实做技术也一样，不同业务阶段不同数据量适合用不同的技术方案，没有必要过度追求先进的技术和高大上的模型，根据业务特点和业务阶段选择最匹配的技术方案才是最好的。我们认为，没有最好的模型，只有合适的场景。总结酒店搜索作为O2O搜索的一种，和传统的搜索排序相比有很多不同之处，既要解决搜索的相关性问题，又要提供“千人千面”的排序结果，优化用户购买体验，还要满足业务需求。通过合理的模块划分可以把这三大类问题解耦，检索、排序、业务三个技术模块各司其职。在检索和意图理解层面，我们做了地标策略、NER模型和多级检索架构来保证查询结果的相关性；排序模型上结合酒店搜索的业务特点，借鉴业界先进思想，尝试了多种不同的深度排序模型，走出了一条不一样的模型演进路线。同时通过控制技术节奏，整体把握不同业务的技术选型和迭代节奏，对不同阶段的业务匹配不同的技术方案，只选对的，不选贵的。参考文献[1] John Lafferty et al. Conditional random fields: Probabilistic models for segmenting and labeling sequence data.ICML2001.[2] Guillaume Lample et al Neural architectures for named entity recognition. NAACL2016.[3] Zhiheng Huang, Wei Xu, and Kai Yu. 2015.[4] Bidirectional LSTM-CRF models for sequence tagging. arXiv preprint arXiv:1508.01991.[5] Xuezhe Ma et al.End-to-end Sequence Labeling via Bi-directional LSTM-CNNs-CRF.ACL2016.[6] T Chen, C Guestrin. XGBoost: A scalable tree boosting system. KDD2016.[7] Weinan Zhang et al. Deep Learning over Multi-Field Categorical Data: A Case Study on User Response Prediction. ECIR 2016.[8] Huifeng Guo et al. DeepFM: A Factorization-Machine based Neural Network for CTR Prediction. IJCAI2017.[9] Yanru Qu et al. Product-based neural networks for user response prediction. ICDM2016.[10] Heng-Tze Cheng et al. 2016. Wide & deep learning for recommender systems. 2016.In Proceedings of the 1st Workshop on Deep Learning for Recommender Systems.[11] Ruoxi Wang et al. Deep & Cross Network for Ad Click Predictions. ADKDD2017.作者简介艺涛，美团高级技术专家，2016年加入美团，现负责美团酒店业务搜索排序技术。2010年毕业于中科院计算所，曾在网易有道等公司工作，先后从事网页搜索、购物搜索、计算广告等方向的研发工作。曾荣获“Kaggle卫星图像分类大赛”亚军，QCon明星讲师。 ...

背景为了更好地实现对项目的管理，我们将组内一个项目迁移到MDP框架（基于Spring Boot），随后我们就发现系统会频繁报出Swap区域使用量过高的异常。笔者被叫去帮忙查看原因，发现配置了4G堆内内存，但是实际使用的物理内存竟然高达7G，确实不正常。JVM参数配置是“-XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+AlwaysPreTouch -XX:ReservedCodeCacheSize=128m -XX:InitialCodeCacheSize=128m, -Xss512k -Xmx4g -Xms4g,-XX:+UseG1GC -XX:G1HeapRegionSize=4M”，实际使用的物理内存如下图所示：排查过程1. 使用Java层面的工具定位内存区域（堆内内存、Code区域或者使用unsafe.allocateMemory和DirectByteBuffer申请的堆外内存）笔者在项目中添加-XX:NativeMemoryTracking=detailJVM参数重启项目，使用命令jcmd pid VM.native_memory detail查看到的内存分布如下：发现命令显示的committed的内存小于物理内存，因为jcmd命令显示的内存包含堆内内存、Code区域、通过unsafe.allocateMemory和DirectByteBuffer申请的内存，但是不包含其他Native Code（C代码）申请的堆外内存。所以猜测是使用Native Code申请内存所导致的问题。为了防止误判，笔者使用了pmap查看内存分布，发现大量的64M的地址；而这些地址空间不在jcmd命令所给出的地址空间里面，基本上就断定就是这些64M的内存所导致。2. 使用系统层面的工具定位堆外内存因为笔者已经基本上确定是Native Code所引起，而Java层面的工具不便于排查此类问题，只能使用系统层面的工具去定位问题。首先，使用了gperftools去定位问题gperftools的使用方法可以参考gperftools，gperftools的监控如下：从上图可以看出：使用malloc申请的的内存最高到3G之后就释放了，之后始终维持在700M-800M。笔者第一反应是：难道Native Code中没有使用malloc申请，直接使用mmap/brk申请的？（gperftools原理就使用动态链接的方式替换了操作系统默认的内存分配器（glibc）。）然后，使用strace去追踪系统调用因为使用gperftools没有追踪到这些内存，于是直接使用命令“strace -f -e"brk,mmap,munmap" -p pid”追踪向OS申请内存请求，但是并没有发现有可疑内存申请。strace监控如下图所示:接着，使用GDB去dump可疑内存因为使用strace没有追踪到可疑内存申请；于是想着看看内存中的情况。就是直接使用命令gdp -pid pid进入GDB之后，然后使用命令dump memory mem.bin startAddress endAddressdump内存，其中startAddress和endAddress可以从/proc/pid/smaps中查找。然后使用strings mem.bin查看dump的内容，如下：从内容上来看，像是解压后的JAR包信息。读取JAR包信息应该是在项目启动的时候，那么在项目启动之后使用strace作用就不是很大了。所以应该在项目启动的时候使用strace，而不是启动完成之后。再次，项目启动时使用strace去追踪系统调用项目启动使用strace追踪系统调用，发现确实申请了很多64M的内存空间，截图如下：使用该mmap申请的地址空间在pmap对应如下：最后，使用jstack去查看对应的线程因为strace命令中已经显示申请内存的线程ID。直接使用命令jstack pid去查看线程栈，找到对应的线程栈（注意10进制和16进制转换）如下：这里基本上就可以看出问题来了：MCC（美团统一配置中心）使用了Reflections进行扫包，底层使用了Spring Boot去加载JAR。因为解压JAR使用Inflater类，需要用到堆外内存，然后使用Btrace去追踪这个类，栈如下：然后查看使用MCC的地方，发现没有配置扫包路径，默认是扫描所有的包。于是修改代码，配置扫包路径，发布上线后内存问题解决。3. 为什么堆外内存没有释放掉呢？虽然问题已经解决了，但是有几个疑问：为什么使用旧的框架没有问题？为什么堆外内存没有释放？为什么内存大小都是64M，JAR大小不可能这么大，而且都是一样大？为什么gperftools最终显示使用的的内存大小是700M左右，解压包真的没有使用malloc申请内存吗？带着疑问，笔者直接看了一下Spring Boot Loader那一块的源码。发现Spring Boot对Java JDK的InflaterInputStream进行了包装并且使用了Inflater，而Inflater本身用于解压JAR包的需要用到堆外内存。而包装之后的类ZipInflaterInputStream没有释放Inflater持有的堆外内存。于是笔者以为找到了原因，立马向Spring Boot社区反馈了这个bug。但是反馈之后，笔者就发现Inflater这个对象本身实现了finalize方法，在这个方法中有调用释放堆外内存的逻辑。也就是说Spring Boot依赖于GC释放堆外内存。笔者使用jmap查看堆内对象时，发现已经基本上没有Inflater这个对象了。于是就怀疑GC的时候，没有调用finalize。带着这样的怀疑，笔者把Inflater进行包装在Spring Boot Loader里面替换成自己包装的Inflater，在finalize进行打点监控，结果finalize方法确实被调用了。于是笔者又去看了Inflater对应的C代码，发现初始化的使用了malloc申请内存，end的时候也调用了free去释放内存。此刻，笔者只能怀疑free的时候没有真正释放内存，便把Spring Boot包装的InflaterInputStream替换成Java JDK自带的，发现替换之后，内存问题也得以解决了。这时，再返过来看gperftools的内存分布情况，发现使用Spring Boot时，内存使用一直在增加，突然某个点内存使用下降了好多（使用量直接由3G降为700M左右）。这个点应该就是GC引起的，内存应该释放了，但是在操作系统层面并没有看到内存变化，那是不是没有释放到操作系统，被内存分配器持有了呢？继续探究，发现系统默认的内存分配器（glibc 2.12版本）和使用gperftools内存地址分布差别很明显，2.5G地址使用smaps发现它是属于Native Stack。内存地址分布如下：到此，基本上可以确定是内存分配器在捣鬼；搜索了一下glibc 64M，发现glibc从2.11开始对每个线程引入内存池（64位机器大小就是64M内存），原文如下：按照文中所说去修改MALLOC_ARENA_MAX环境变量，发现没什么效果。查看tcmalloc（gperftools使用的内存分配器）也使用了内存池方式。为了验证是内存池搞的鬼，笔者就简单写个不带内存池的内存分配器。使用命令gcc zjbmalloc.c -fPIC -shared -o zjbmalloc.so生成动态库，然后使用export LD_PRELOAD=zjbmalloc.so替换掉glibc的内存分配器。其中代码Demo如下：#include<sys/mman.h>#include<stdlib.h>#include<string.h>#include<stdio.h>//作者使用的64位机器，sizeof(size_t)也就是sizeof(long) void* malloc ( size_t size ){ long* ptr = mmap( 0, size + sizeof(long), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0 ); if (ptr == MAP_FAILED) { return NULL; } ptr = size; // First 8 bytes contain length. return (void)(&ptr[1]); // Memory that is after length variable}void calloc(size_t n, size_t size) { void ptr = malloc(n * size); if (ptr == NULL) { return NULL; } memset(ptr, 0, n * size); return ptr;}void *realloc(void ptr, size_t size){ if (size == 0) { free(ptr); return NULL; } if (ptr == NULL) { return malloc(size); } long plen = (long)ptr; plen–; // Reach top of memory long len = plen; if (size <= len) { return ptr; } void rptr = malloc(size); if (rptr == NULL) { free(ptr); return NULL; } rptr = memcpy(rptr, ptr, len); free(ptr); return rptr;}void free (void ptr ){ if (ptr == NULL) { return; } long plen = (long)ptr; plen–; // Reach top of memory long len = plen; // Read length munmap((void)plen, len + sizeof(long));}通过在自定义分配器当中埋点可以发现其实程序启动之后应用实际申请的堆外内存始终在700M-800M之间，gperftools监控显示内存使用量也是在700M-800M左右。但是从操作系统角度来看进程占用的内存差别很大（这里只是监控堆外内存）。笔者做了一下测试，使用不同分配器进行不同程度的扫包，占用的内存如下：为什么自定义的malloc申请800M，最终占用的物理内存在1.7G呢？因为自定义内存分配器采用的是mmap分配内存，mmap分配内存按需向上取整到整数个页，所以存在着巨大的空间浪费。通过监控发现最终申请的页面数目在536k个左右，那实际上向系统申请的内存等于512k * 4k（pagesize） = 2G。为什么这个数据大于1.7G呢？因为操作系统采取的是延迟分配的方式，通过mmap向系统申请内存的时候，系统仅仅返回内存地址并没有分配真实的物理内存。只有在真正使用的时候，系统产生一个缺页中断，然后再分配实际的物理Page。总结整个内存分配的流程如上图所示。MCC扫包的默认配置是扫描所有的JAR包。在扫描包的时候，Spring Boot不会主动去释放堆外内存，导致在扫描阶段，堆外内存占用量一直持续飙升。当发生GC的时候，Spring Boot依赖于finalize机制去释放了堆外内存；但是glibc为了性能考虑，并没有真正把内存归返到操作系统，而是留下来放入内存池了，导致应用层以为发生了“内存泄漏”。所以修改MCC的配置路径为特定的JAR包，问题解决。笔者在发表这篇文章时，发现Spring Boot的最新版本（2.0.5.RELEASE）已经做了修改，在ZipInflaterInputStream主动释放了堆外内存不再依赖GC；所以Spring Boot升级到最新版本，这个问题也可以得到解决。参考资料GNU C Library (glibc)Native Memory TrackingSpring BootgperftoolsBtrace作者简介纪兵，2015年加入美团，目前主要从事酒店C端相关的工作。 ...

你好，2019再见，2018又到了一年辞旧迎新的时候，大家应该也和美美一样，在忙着总结回顾和展望规划吧。按老惯例，我们该献上技术年货了。今年首先出场的，是我们的技术沙龙大套餐！美团技术沙龙是由美团技术团队和美团科协主办的线下技术活动，每期沙龙邀请美团和同行公司的技术专家分享来自一线的实践经验，覆盖前端、后台、系统、数据、算法、测试、运维等技术领域。目前已在北京、上海、厦门、成都等城市成功举办了48期，吸引了超过2万名工程师报名参会。除了现场亲密交流之外，大家还在会后继续进微信群里切磋问道。我们同时也定期举办线上沙龙，有更多的朋友已经在线收听或收看过我们的直播。过去的一年里，我们一共举办了19场线下沙龙，16次线上沙龙，包括99位讲师，85个演讲，70+小时分享。除美团的几十位专家之外，还邀请了腾讯、蚂蚁金服、百度、京东、去哪儿、美亚柏科同行。主题既有最火的AI热点——深度学习、强化学习、知识图谱，新潮技术Go、Kotlin、Flutter的落地实践，也有大规模互联网平台不可或缺的稳定性保障、高可用架构、监控体系、持续集成，还有接地气的运营系统、数据平台、配送调度的经验，更少不了CAT、mpvue、EasyReact这些火爆的开源项目……我们整理了今年所有线上线下沙龙的演讲稿和视频，分享给大家，希望能帮助大家在技术之路上继续追求卓越。还没有关注美团技术团队公众号（meituantech）的同学，赶快关注哟。现在，大家请闭眼，大餐来了～～～美团线下沙龙任意点击标题，就能直接查看视频及演讲稿Tech Salon 048：AI在复杂业务场景中的应用（请在微信端打开）出品人|何仁清 美团研究员 2018/12/22《深度强化学习技术在智能调度中的应用》王超@美团高级技术专家《深度学习在物流配送舆情监控中的应用》李超@京东物流NLP方向资深算法工程师《美团搜索中的深度学习实践》周翔@美团技术专家Tech Salon 047：运营效率系统架构演进之道（请在微信端打开）出品人|阳纯飞 美团高级技术专家 2018/12/08《面向O2O大促活动的高效运营系统实践》李力@美团高级技术专家《京东物流实时数据平台性能优化实践》杨国斌@京东技术专家《外卖商家菜品运营效率提升实践》罗震@美团高级技术专家《外卖商户数据化运营体系建设》李觊@美团高级技术专家Tech Salon 046：AI在外卖配送的应用（请在微信端打开）出品人|王兴星&郝井华 美团研究员 2018/11/25《预估模型在外卖广告的演进》谢乾龙@美团外卖广告算法专家《即时配送中的运筹优化技术》郝井华@美团配送智能调度平台负责人《即时配送中的机器学习技术》何仁清@美团配送AI方向负责人Tech Salon 045：如何构建高性能、稳定的后端服务系统（请在微信端打开）出品人 |方建平 美团技术总监 2018/11/24《美团度假交易稳定性建设实践》韩建起@美团技术专家《美团配送智能调度系统架构演进》郑伟@美团技术专家《美团稳定性保障平台Rhino》占军@美团技术专家《美团外卖LBS服务实践》易奎@美团高级技术专家Tech Salon 044：千万级日活App的质量保证（请在微信端打开）出品人|李永刚 美团研究员 2018/09/15《AI语音产品测试》于海生@美团技术专家《美团外卖客户端 UI 自动化测试实践》刘健@美团技术专家《客户端QA效率工具》赵晔@美团测试开发架构师Tech Salon 043：美团金融千万级交易系统质量保障之路（请在微信端打开）出品人|赫大龙 美团高级技术专家 2018/09/01《智能支付稳定性测试实战》范勋伟@美团高级测试开发工程师《去哪儿网服务端自动化测试体系》郑希文@去哪儿《线上支付SDK质量保证体系》张朋飞@美团高级测试开发工程师《质量运营演变之道》符欣@美团高级开发工程师Tech Salon 042：高效率前端与架构实战（请在微信端打开）出品人|王鹤 美团高级技术专家 2018/08/26《EH — 用黑科技打造全新的 Hybrid 体验》 陈禹霖@美团技术专家《mpvue小程序开发框架和最佳实践》胡成全@美团技术专家《美团金融前端工程化最佳实践》田泱@美团高级研发工程师《前端架构师应该做的事——架构模型与技术实践》王鹤@美团高级技术专家Tech Salon 041：企业级前端开发360°实践（请在微信端打开）出品人|任远 美团高级技术专家 2018/08/18《浅谈流量劫持与防治》刘洋河@美团高级工程师《前端高可用性保障实践》田泱@美团高级研发工程师《跨容器高性能的离线化方案在美团的实践和探索》龙佳文@美团高级工程师《前端遇上Go: 静态资源增量更新的新实践》杨义天@美团高级工程师Tech Salon 040：前端遇上黑科技，打造全新界面体验与效率（请在微信端打开）出品人 | 冯湧 美团研发总监 2018/08/04《EH——用黑科技打造的全新的 Hybrid 体验》陈禹霖@美团技术专家《Vix——如何打造一个高效的前端组件库》张胜@美团高级研发工程师《委以重任的Node.js——百亿级访问实践》迪波威@百度资深软件工程师《构建时预渲染——网页首帧优化实践》尚寒阳@美团资深研发工程师Tech Salon 039：新思路打造移动端高效研发体系（请在微信端打开）出品人|周辉 美团资深架构师 2018/07/21《Picasso在大众点评首页的应用》虞惠文@美团Android开发工程师《移动前后端开发解耦》林晨@美团后端技术专家《打造稳定、灵活、高效的运营配置平台》蒋国宝@美团后端技术架构师《移动持续集成实践》何智聪@美团iOS技术专家Tech Salon 038：旅游电商架构攻略指南（请在微信端打开）出品人|金孟哲 美团高级技术专家 2018/07/07《旅游度假预订系统架构演进实践》 金孟哲@美团高级技术专家《旅游度假多要素动态打包实践》 王超@美团高级技术专家《旅游度假商品中心架构演进》 徐泼@美团高级技术专家《直连低可信系统，实现高可用服务实践》 郑旭@美团高级技术专家Tech Salon 037：美团外卖两千万日订单背后的客户端技术架构（请在微信端打开）出品人|吴凯 美团高级技术专家 2018/06/23《美团外卖客户端技术架构演进》朱瑞利@美团资深工程师《客户端监控体系建设》冯天锡@美团资深工程师《客户端多端复用架构》郑金光@美团高级工程师《客户端容灾能力体系》李富强@美团资深工程师Tech Salon 036：大前端的动态化与可用性建设（请在微信端打开）出品人|洪磊 美团研究员 2018/06/02《大前端高可用性建设》李富强@美团资深前端工程师《React fiber漫谈》覃俊文@蚂蚁金服前端技术专家《小程序开发的新姿势 -mpvue 的应用和实践》胡成全@美团前端技术专家《ReactNative性能优化企业级应用》赵宏罡@腾讯资深前端开发工程师Tech Salon 035：前端热点技术的企业级实践（请在微信端打开）出品人|任远 美团高级技术专家 2018/04/21《前端遇上 Go——静态资源增量更新的新实践》刘洋河@美团高级前端工程师《金融扫码付 H5 迁移小程序拓荒之旅》陈瑶@美团前端工程师《小程序开发的新姿势 - mpvue 开发框架和最佳实践》胡成全@美团技术专家Tech Salon 034：聊聊酒店系统高可用架构实践（请在微信端打开）出品人|许关飞 美团研究员 2018/04/14《高可用之中间件技术》吴湘@美团技术专家《分布式开源监控系统CAT在美团点评演进》尤勇@美团研究员《美团旅行住宿产品中心系统高可用实战》槐国涛@美团酒店CRS商品负责人《美团旅行酒店住宿订单系统高可用实战》李磊@美团资深工程师《美团旅行直连系统高可用实战》秦浏杰@美团资深工程师Tech Salon 033：企业信息化建设和安全管理（请在微信端打开）出品人|邓昀泽 美团企业平台研发负责人 2018/02/03《美团点评内部系统构建之路》邓昀泽@美团企业平台研发部负责人《企业信息防护体系建设》陆平@美亚柏科企业电子数据取证事业部副总《企业如何应对安全威胁》游兴旺@美团企业平台研发高级总监Tech Salon 032：移动开发热点技术—动态日志、监控、Hybrid、插件化（请在微信端打开）出品人|方锦涛 美团研究员 2018/02/03《线上问题排查体系构建：动态日志》 陈潼@美团Android资深工程师《混合应用工程化实践》 李罡@美团前端工程师《Caesium iOS启动时间监控》 吴君阳@美团iOS工程师Tech Salon 031：线下支付千万级订单服务—前后端架构实践（请在微信端打开）出品人|任远 美团高级技术专家 2018/01/27《扫码付前端可用性保障实践》 田泱@美团高级工程师《业务系统的建设之路》刘运@美团技术专家《Web离线化加载》 于秋@美团技术专家《基于WTL框架的Windows开发最佳实践》 钱声鹏@美团高级工程师Tech Salon 030：餐饮生态高可用系统实践（请在微信端打开）出品人|温华剑 美团技术专家 2018/01/13《从“0”开始-美团收银客户端》聂龙羽@美团技术专家 《美团餐饮生态大数据架构实践》牛江浩@美团技术专家《餐饮开放平台的高可用实践》朱洋波@美团技术专家美团线上沙龙任意点击标题，就能在线观看视频或者文章On-Line Salon 33：美团大脑 智享生活分享人：王仲远 美团点评高级研究员On-Line Salon 32：基于深度学习的计算机视觉技术在无人驾驶中的应用分享人：刘宇达 美团点评资深算法工程师On-Line Salon 31：利用响应式来解决客户端问题分享人：臧成威 美团点评前端技术专家On-Line Salon 30：美团针对 Redis Rehash 机制的探索和实践分享人：葛春林 美团点评资深工程师On-Line Salon 29：Flutter 原理与实践分享人：李少杰 美团点评资深工程师On-Line Salon 28：如何基于深度学习实现图像的智能审核分享人：魏晓明 美团点评高级技术专家On-Line Salon 27：美团客户端响应式框架 EasyReact 开源分享人：臧成威 美团点评前端技术专家On-Line Salon 26：移动持续集成在大众点评的实践分享人：何智聪、邢轶 美团点评前端技术专家On-Line Salon 25：Kotlin 代码检查探索与实践分享人：周佳 美团点评前端开发工程师On-Line Salon 24：静态资源增量更新的新实践分享人：刘洋河 美团点评资深工程师On-Line Salon 23：点评侧用户行为检索系统分享人：朱凯 美团点评资深工程师On-Line Salon 22：深度学习在美团搜索广告排序的应用实践分享人：薛欢、梁玉林、王新 美团点评资深工程师On-Line Salon 21：使用 Mpvue 开发微信小程序的最佳实践分享人：胡成全 美团点评前端技术专家On-Line Salon 20：亿级用户个性化品类推荐实战解析分享人：张晓宇 美团高级工程师On-Line Salon 19：MVVM 在美团点评酒旅业务中的实践分享人：吴卓 美团点评技术专家On-Line Salon 18：深度学习在美团点评推荐业务中实践分享人：陈文石 美团点评算法专家感恩！99位出品人和讲师，70+小时的分享，感谢他们给我们带来一线的技术实践分享，感谢他们给我们2万多小伙伴送上技术的“饕餮盛宴”。除了美团技术团队的讲师们，我们还要特别感谢来自腾讯、蚂蚁金服、百度、京东、去哪儿、美亚柏科等公司的讲师们，感谢你们的付出和努力，我们期待新的一年会有更多的合作！（2018全年出品人及讲师）———- END ———- ...

背景对苹果开发者而言，由于平台审核周期较长，客户端代码导致的线上问题影响时间往往比较久。如果在开发、测试阶段能够提前暴露问题，就有助于避免线上事故的发生。代码覆盖率检测正是帮助开发、测试同学提前发现问题，保证代码质量的好帮手。对于开发者而言，代码覆盖率可以反馈两方面信息：自测的充分程度。代码设计的冗余程度。尽管代码覆盖率对代码质量有着上述好处，但在 iOS 开发中却使用的不多。我们调研了市场上常用的 iOS 覆盖率检测工具，这些工具主要存在以下四个问题：第三方工具有时生成的检测报告文件会出错甚至会失败，开发者对覆盖率生成原理不了解，遇到这类问题容易弃用工具。第三方工具每次展示全量的覆盖率报告，会分散开发者的很多精力在未修改部分。而在绝大多数情况下，开发者的关注重点在本次新增和修改的部分。Xcode 自带的覆盖率检测只适用于单元测试场景，由于需求变更频繁，业务团队开发单元测试的成本很高。已有工具很难和现有开发流程结合起来，需要额外进行测试，运行覆盖率脚本才能获取报告文件。为了解决上述问题，我们深入调研了覆盖率报告的生成逻辑，并结合团队的开发流程，开发了一套嵌入在代码提交流程中、基于单次代码提交（git commit）生成报告、对开发者透明的增量代码测试覆盖率工具。开发者只需要正常开发，通过模拟器测试开发代码，commit 本次代码（commit 和测试顺序可交换），推送（git push）到远端，就可以在本地看到这次提交代码的详细覆盖率报告了。本文分为两部分，先从介绍通用覆盖率检测的原理出发，让读者对覆盖率的收集、解析有直观的认识。之后介绍我们增量代码测试覆盖率工具的实现。覆盖率检测原理生成覆盖率报告，首先需要在 Xcode 中配置编译选项，编译后会为每个可执行文件生成对应的 .gcno 文件；之后在代码中调用覆盖率分发函数，会生成对应的 .gcda 文件。其中，.gcno 包含了代码计数器和源码的映射关系， .gcda 记录了每段代码具体的执行次数。覆盖率解析工具需要结合这两个文件给出最后的检测报表。接下来先看看 .gcno 的生成逻辑。.gcno利用 Clang 分别生成源文件的 AST 和 IR 文件，对比发现，AST 中不存在计数指令，而 IR 中存在用来记录执行次数的代码。搜索 LLVM 源码可以找到覆盖率映射关系生成源码。覆盖率映射关系生成源码是 LLVM 的一个 Pass，（下文简称 GCOVPass）用来向 IR 中插入计数代码并生成 .gcno 文件（关联计数指令和源文件）。下面分别介绍IR插桩逻辑和 .gcno 文件结构。IR 插桩逻辑代码行是否执行到，需要在运行中统计，这就需要对代码本身做一些修改，LLVM 通过修改 IR 插入了计数代码，因此我们不需要改动任何源文件，仅需在编译阶段增加编译器选项，就能实现覆盖率检测了。从编译器角度看，基本块（Basic Block，下文简称 BB）是代码执行的基本单元，LLVM 基于 BB 进行覆盖率计数指令的插入，BB 的特点是：只有一个入口。只有一个出口。只要基本块中第一条指令被执行，那么基本块内所有指令都会顺序执行一次。覆盖率计数指令的插入会进行两次循环，外层循环遍历编译单元中的函数，内层循环遍历函数的基本块。函数遍历仅用来向 .gcno 中写入函数位置信息，这里不再赘述。一个函数中基本块的插桩方法如下：统计所有 BB 的后继数 n，创建和后继数大小相同的数组 ctr[n]。以后继数编号为序号将执行次数依次记录在 ctr[i] 位置，对于多后继情况根据条件判断插入。举个例子，下面是一段猜数字的游戏代码，当玩家猜中了我们预设的数字10的时候会输出Bingo，否则输出You guessed wrong!。这段代码的控制流程图如图1所示。- (void)guessNumberGame:(NSInteger)guessNumber{ NSLog(@“Welcome to the game”); if (guessNumber == 10) { NSLog(@“Bingo!”); } else { NSLog(@“You guess is wrong!”); }}例1 猜数字游戏 这段代码如果开启了覆盖率检测，会生成一个长度为 6 的 64 位数组，对照插桩位置，方括号中标记了桩点序号，图 1 中代码前数字为所在行数。图 1 桩点位置.gcno计数符号和文件位置关联.gcno 是用来保存计数插桩位置和源文件之间关系的文件。GCOVPass 在通过两层循环插入计数指令的同时，会将文件及 BB 的信息写入 .gcno 文件。写入步骤如下：创建 .gcno 文件，写入 Magic number(oncg+version)。随着函数遍历写入文件地址、函数名和函数在源文件中的起止行数（标记文件名，函数在源文件对应行数）。随着 BB 遍历，写入 BB 编号、BB 起止范围、BB 的后继节点编号（标记基本块跳转关系）。写入函数中BB对应行号信息（标注基本块与源码行数关系）。从上面的写入步骤可以看出，.gcno 文件结构由四部分组成：文件结构函数结构BB 结构BB 行结构通过这四部分结构可以完全还原插桩代码和源码的关联，我们以 BB 结构 / BB 行结构为例，给出结构图 2 (a) BB 结构，(b) BB 行信息结构，在本章末尾覆盖率解析部分，我们利用这个结构图还原代码执行次数（每行等高格代表 64bit）：图2 BB 结构和 BB 行信息结构.gcda入口函数关于 .gcda 的生成逻辑，可参考覆盖率数据分发源码。这个文件中包含了 __gcov_flush() 函数，这个函数正是分发逻辑的入口。接下来看看 __gcov_flush() 如何生成 .gcda 文件。通过阅读代码和调试，我们发现在二进制代码加载时，调用了llvm_gcov_init(writeout_fn wfn， flush_fn ffn)函数，传入了_llvm_gcov_writeout（写 gcov 文件），_llvm_gcov_flush（gcov 节点分发）两个函数，并且根据调用顺序，分别建立了以文件为节点的链表结构。（flush_fn_node * ，writeout_fn_node * ）__gcov_flush() 代码如下所示，当我们手动调用__gcov_flush() 进行覆盖率分发时，会遍历flush_fn_node *这个链表（即遍历所有文件节点），并调用分发函数_llvm_gcov_flush（curr->fn 正是__llvm_gcov_flush函数类型）。void __gcov_flush() { struct flush_fn_node *curr = flush_fn_head; while (curr) { curr->fn(); curr = curr->next; }}具体的分发逻辑观察__llvm_gcov_flush 的 IR 代码，可以看到：图3 __llvm_gcov_flush 代码示例__llvm_gcov_flush 先调用了__llvm_gcov_writeout，来向 .gcda 写入覆盖率信息。最后将计数数组清零__llvm_gcov_ctr.xx。而__llvm_gcov_writeout逻辑为：生成对应源文件的 .gcda 文件，写入 Magic number。循环执行llvm_gcda_emit_function: 向 .gcda 文件写入函数信息。llvm_gcda_emit_arcs: 向 .gcda 文件写入BB执行信息，如果已经存在 .gcda 文件，会和之前的执行次数进行合并。调用llvm_gcda_summary_info，写入校验信息。调用llvm_gcda_end_file，写结束符。感兴趣的同学可以自己生成 IR 文件查看更多细节，这里不再赘述。.gcda 的文件/函数结构和 .gcno 基本一致，这里不再赘述，统计插桩信息结构如图 4 所示。定制化的输出也可以通过修改上述函数完成。我们的增量代码测试覆盖率工具解决代码 BB 结构变动后合并到已有 .gcda 文件不兼容的问题，也是修改上述函数实现的。图4 计数桩输出结构覆盖率解析在了解了如上所述 .gcno ，.gcda 生成逻辑与文件结构之后，我们以例 1 中的代码为例，来阐述解析算法的实现。例 1 中基本块 B0，B1 对应的 .gcno 文件结构如下图所示，从图中可以看出，BB 的主结构完全记录了基本块之间的跳转关系。图5 B0，B1 对应跳转信息B0，B1 的行信息在 .gcno 中表示如下图所示，B0 块因为是入口块，只有一行，对应行号可以从 B1 结构中获取，而 B1 有两行代码，会依次把行号写入 .gcno 文件。图6 B0，B1 对应行信息在输入数字 100 的情况下，生成的 .gcda 文件如下：图7 输入 100 得到的 .gcda 文件通过控制流程图中节点出边的执行次数可以计算出 BB 的执行次数，核心算法为计算这个 BB 的所有出边的执行次数，不存在出边的情况下计算所有入边的执行次数（具体实现可以参考 gcov 工具源码），对于 B0 来说，即看 index=0 的执行次数。而 B1 的执行次数即 index=1，2 的执行次数的和，对照上图中 .gcda 文件可以推断出，B0 的执行次数为 ctr[0]=1，B1 的执行次数是 ctr[1]+ctr[2]=1， B2 的执行次数是 ctr[3]=0，B4 的执行次数为 ctr[4]=1，B5 的执行次数为 ctr[5]=1。经过上述解析，最终生成的 HTML 如下图所示（利用 lcov）：图8 覆盖率检测报告以上是 Clang 生成覆盖率信息和解析的过程，下面介绍美团到店餐饮 iOS 团队基于以上原理做的增量代码测试覆盖率工具。增量代码覆盖率检测原理方案权衡由于 gcov 工具（和前面的 .gcov 文件区分，gcov 是覆盖率报告生成工具）生成的覆盖率检测报告可读性不佳，如图 9 所示。我们做的增量代码测试覆盖率工具是基于 lcov 的扩展，报告展示如上节末尾图 8 所示。图9 gcov 输出，行前数字代表执行次数，#### 代表没执行比 gcov 直接生成报告多了一步，lcov 的处理流程是将 .gcno 和 .gcda 文件解析成一个以 .info 结尾的中间文件（这个文件已经包含全部覆盖率信息了），之后通过覆盖率报告生成工具生成可读性比较好的 HTML 报告。结合前两章内容和覆盖率报告生成步骤，覆盖率生成流程如下图所示。考虑到增量代码覆盖率检测中代码增量部分需要通过 Git 获取，比较自然的想法是用 git diff 的信息去过滤覆盖率的内容。根据过滤点的不同，存在以下两套方案：通过 GCOVPass 过滤，只对修改的代码进行插桩，每次修改后需重新插桩。通过 .info 过滤，一次性为所有代码插桩，获取全部覆盖率信息，过滤覆盖率信息。图10 覆盖率生成流程分析这两个方案，第一个方案需要自定义 LLVM 的 Pass，进而会引入以下两个问题：只能使用开源 Clang 进行编译，不利于接入正常的开发流程。每次重新插桩会丢失之前的覆盖率信息，多次运行只能得到最后一次的结果。而第二个方案相对更加轻量，只需要过滤中间格式文件，不仅可以解决我们在文章开头提到的问题，也可以避免上述问题：可以很方便地加入到平常代码的开发流程中，甚至对开发者透明。未修改文件的覆盖率可以叠加（有修改的那些控制流程图结构可能变化，无法叠加）。因此我们实际开发选定的过滤点是在 .info 。在选定了方案 2 之后，我们对中间文件 .info 进行了一系列调研，确定了文件基本格式（函数/代码行覆盖率对应的文件的表示），这里不再赘述，具体可以参考 .info 生成文档。增量代码测试覆盖率工具的实现前一节是实现增量代码覆盖率检测的基本方案选择，为了更好地接入现有开发流程，我们做了以下几方面的优化。降低使用成本在接入方面，接入增量代码测试覆盖率工具只需一次接入配置，同步到代码仓库后，团队中成员无需配置即可使用，降低了接入成本。在使用方面，考虑到插桩在编译时进行，对全部代码进行插桩会很大程度降低编译速度，我们通过解析 Podfile（iOS 开发中较为常用的包管理工具 CocoaPods 的依赖描述文件），只对 Podfile 中使用本地代码的仓库进行插桩（可配置指定仓库），降低了团队的开发成本。对开发者透明接入增量代码测试覆盖率工具后，开发者无需特殊操作，也不需要对工程做任何其他修改，正常的 git commit 代码，git push 到远端就会自动生成并上传这次 commit 的覆盖率信息了。为了做到这一点，我们在接入 Pod 的过程中，自动部署了 Git 的 pre-push 脚本。熟悉 Git 的同学知道，Git 的 hooks 是开发者的本地脚本，不会被纳入版本控制，如何通过一次配置就让这个仓库的所有使用成员都能开启，是做好这件事的一个难点。我们考虑到 Pod 本身会被纳入版本控制，因此利用了 CocoaPods 的一个属性 script_phase，增加了 Pod 编译后脚本，来帮助我们把 pre-push 插入到本地仓库。利用 script_phase 插入还带来了另外一个好处，我们可以直接获取到工程的缓存文件，也避免了 .gcno / .gcda 文件获取的不确定性。整个流程如下：图11 pre-push 分发流程覆盖率累计在实现了覆盖率的过滤后，我们在实际开发中遇到了另外一个问题：修改分支/循环结构后生成的 .gcda 文件无法和之前的合并。 在这种情况下，__gcov_flush会直接返回，不再写入 .gcda 文件了导致覆盖率检测失败，这也是市面上已有工具的通用问题。而这个问题在开发过程中很常见，比如我们给例 1 中的游戏增加一些提示，当输入比预设数字大时，我们就提示出来，反之亦然。- (void)guessNumberGame:(NSInteger)guessNumber{ NSInteger targetNumber = 10; NSLog(@“Welcome to the game”); if (guessNumber == targetNumber) { NSLog(@“Bingo!”); } else if (guessNumber > targetNumber) { NSLog(@“Input number is larger than the given target!”); } else { NSLog(@“Input number is smaller than the given target!”); }}这个问题困扰了我们很久，也推动了对覆盖率检测原理的调研。结合前面覆盖率检测的原理可以知道，不能合并的原因是生成的控制流程图比原来多了两条边（ .gcno 和旧的 .gcda 也不能匹配了），反映在 .gcda 上就是数组多了两个数据。考虑到代码变动后，原有的覆盖率信息已经没有意义了，当发生边数不一致的时候，我们会删除掉旧的 .gcda 文件，只保留最新 .gcda 文件（有变动情况下 .gcno 会重新生成）。如下图所示：图12 覆盖率冲突解决算法整体流程图结合上述流程，我们的增量代码测试覆盖率工具的整体流程如图 13 所示。开发者只需进行接入配置，再次运行时，工程中那些作为本地仓库进行开发的代码库会被自动插桩，并在 .git 目录插入 hooks 信息；当开发者使用模拟器进行需求自测时，插桩统计结果会被自动分发出去；在代码被推到远端前，会根据插桩统计结果，生成仅包含本次代码修改的详细增量代码测试覆盖率报告，以及向远端推送覆盖率信息；同时如果测试覆盖率小于 80% 会强制拒绝提交（可配置关闭，百分比可自定义），保证只有经过充分自测的代码才能提交到远端。图13 增量代码测试覆盖率生成流程图总结以上是我们在代码开发质量方面做的一些积累和探索。通过对覆盖率生成、解析逻辑的探究，我们揭开了覆盖率检测的神秘面纱。开发阶段的增量代码覆盖率检测，可以帮助开发者聚焦变动代码的逻辑缺陷，从而更好地避免线上问题。作者介绍丁京，iOS 高级开发工程师。2015 年 2 月校招加入美团到店餐饮事业群，目前负责大众点评 App 美食频道的开发维护。王颖，iOS 开发工程师。2017 年 3 月校招加入美团到店餐饮事业群，目前参与大众点评 App 美食频道的开发维护。招聘信息到店餐饮技术部交易与信息技术中心，负责点评美食用户端业务，服务于数以亿计用户，通过更好的榜单、真实的评价和完善的信息为用户提供更好的决策支持，致力于提升用户体验；同时承载所有餐饮商户端线上流量，为餐饮商户提供多种营销工具，提升餐饮商户营销效率，最终达到让用户“Eat Better、Live Better”的美好愿景！我们的团队包含且不限于 Android、iOS、FE、Java、PHP 等技术方向，已完备覆盖前后端技术栈。只要你来，就能点亮全栈开发技能树。诚挚欢迎投递简历至 wangkang@meituan.com。参考资料覆盖率数据分发源码覆盖率映射关系生成源码基本块介绍gcov 工具源码覆盖率报告生成工具 .info 生成文档 ...

背景在视觉设计领域中，设计师们往往会因为一些简单需求付出相当多的时间，比如修改文案内容，设计简单的海报版式，针对不同机型、展位的多尺寸拓展等。这些工作需要耗费大量的时间、人力成本（5~6张/人日），但对设计师的进步成长起到的作用却非常有限。另一方面，精准营销是未来的大趋势，在大流量背景下，首页的海报资源展位需要展示“千人千面”的效果，这对海报的生产效率也提出了非常高的要求。所以，我们美团外卖技术团队尝试结合AI技术，来协助设计师避免这种低收益、高重复的任务，同时低成本、高效率、高质量地完成海报图片的生成。本文以Banner（横版海报）为例，介绍我们在海报设计与AI技术结合方面所进行的一些探索和研究。分析什么是Banner的设计过程？我们尝试总结了对Banner设计的理解，Banner的设计过程是一系列的具备某种特征属性的素材图层的有序叠加过程。这里的特征属性既包括颜色、形状、纹理、主题等视觉属性，也包括位置、大小、贴边等空间属性。在这个过程中，哪些环节可以被机器算法所探索呢？文献[1]研究了如何调整图像的颜色分布，使杂志封面的视觉效果更加符合人眼的视觉特性；文献[2]以此为基础，引入了基于显著性识别的图像裁剪，并使用优化方法来解决布局问题。阿里巴巴的鹿班系统在去年双十一当天，生成1.7亿张Banner；京东内部也在孵化玲珑和莎士比亚系统，更加智能地设计文案和Banner。图1 封面配色&布局设计[2]在设计领域的一些子问题上，可以用算法来挖掘出数据背后的规律（如图1所示）。那么，能否构建一个完整的学习算法和处理系统，统一解决Banner设计中所有的子问题（配色、布局、搭配、生成）呢？技术方案素材图层是Banner的基础元素，其本身可以被特征化，同时组成Banner的若干元素间的叠加顺序可以被序列化，因此，算法实际是在学习“在什么时候，选择某种素材，放在哪里”。图2 流程框架如图2所示，为了解决这个问题，我们设计规划器、优化器、生成器来共同构建海报设计的学习与生产过程。其中：规划器从数据中学习设计师对不同风格下的设计习惯与规律；优化器基于美学质量和设计原则，对前者的输出结果做精细化调整；最后，由生成器选取/生成素材并渲染成图；素材库作为这三个环节的基础，负责素材管理和素材标签化。素材库如何提取素材图片的特征属性，这是比较典型的分类问题。在计算机视觉领域，传统方案是提取图像的颜色、梯度等低级语义特征[3]，结合传统的分类器（LR、SVM等）来实现分类。近年来，基于深度学习的方法因为能表达更为复杂的语义特征，逐渐成为主流方法[4]。如图3所示我们提取传统的低级语义特征，以及基于CNN的高级语义特征，来共同完成素材特征属性提取。图3 素材库-特征提取规划器完成素材的数据化工作后，怎样学习Banner的设计过程？作为一种生成模型，对抗生成网络（GAN）[5]在近年广为应用，其优势是可以端到端地训练图像生成模型，但在我们的应用场景下，GAN存在以下两个问题：GAN的过程更像是“黑盒”的过程：输入方面，虽然Conditional-GAN之类的方法可以实现某种程度有条件地可控生成，但对于Banner设计任务来说，其输入信息（文案、目标风格、主体信息）仍然过于复杂；输出方面，GAN直接生成源数据（即图像），但非常缺乏解释性。我们需要的是更加直观、更有解释性的信息，比如素材的类型、颜色、轮廓、位置等。在上文中有提到，Banner设计过程是素材图层依次叠加的过程。因此，我们可以用序列生成模型来拟合这个过程[6]。在建模过程中，我们把素材视作词汇（Word），海报视作句子（Sentence），词汇索引视为离散化的特征索引，素材叠加顺序就可以视为句子中的词顺序[7]。图4 规划器-序列生成图4是我们使用的序列生成模型，输入主体信息和目标风格，输出素材特征的序列。为了增强预测过程中多条路径结果的多样性，我们在监督性地训练每个时刻的输出之外，还引入了评估整个序列合理性的Object loss。如图5所示，借鉴SeqGAN的思想，Object loss可以由判别器来提供[8]。图5 SeqGAN[8]优化器规划器预测素材的量化特征，为了确保最终成图符合美学标准，需要一个后处理的过程（图6）。我们用优化器来解决这个问题。从本质上讲，这是一个优化过程。通过和设计师们的沟通，我们设计了一些基于常规设计理念和美学标准的目标函数，动作集合包括移动、缩放、亮度调整等，结合优化方法，提升Banner的视觉效果。图6 优化器生成器优化后的素材特征序列，通过生成器来渲染成图。如图7所示，对于素材库检索不到符合某种特征属性的素材的情况，我们设计了图像风格迁移的方法来实现图像特征迁移。这里的特征可以是颜色、形状、纹理等低级特征，也可以是某种语义化的视觉风格特征，对后者来说，可以将源图像的内容Content和目标图像的风格Style在某种特征空间（CNN中的某一层）里做融合，实现风格迁移[9,10]。图7 素材生成应用场景及功能拓展“千人千面”的精准营销是未来营销策略的趋势，这对商品素材的丰富性提出了非常高的要求；从为商家赋能的角度来说，也需要为商家提供更多样的海报版式，这也要求系统具备海报风格的快速学习能力和拓展能力。对此，在常规设计风格的研究之外，我们从以下3个方面做了一些拓展研究。主体图片加工商品素材的丰富度与美学质量是精细化营销及海报美学质量非常重要的一环。其中最核心的要求是图像分割的能力[11,12]。以全卷积网络（FCN）为基础，如图8所示，我们采取以下几个在目标分割领域常见的技巧，来实现商品图片的目标分割：Encoder-Decoder结构空洞卷积多尺度特征融合Two-Stage微调网络图8 图像语义分割&抠图（结构图部分参考DeepLab v3+[12]）这种基于语义分割方法的结果，在专业设计师人工评审质量的过程中，发现主体边缘有时会出现明显的锯齿感。经过分析，我们认为有以下两个原因：语义分割模型把问题建模为一个“像素级分类过程”，每一个像素的类别都天然地被假设为“非此即彼”，大多数的Segmentation模型都采用Cross-Entropy作为损失函数；因此，无论是从模型结构（CNN）还是从损失函数的角度来说，分割模型会更倾向于全局信息从而丢弃局部结构信息，导致只能得到边缘比较粗糙的分割结果。为此，如图8所示，我们在图像分割的输出结果之外，结合了Image Matting方法：对分割模型的输出结果做形态学变换，生成三值Trimap，分别表示前景区、背景区、未知区；应用常规的Matting方法，比如Bayesian、Close-Form等，以原图像和Trimap图像为输入，输出前景图的Alpha通道；Matting可以使前景主体的边缘更加平滑，视觉质量更高（图9）。图9 商品主体抠图另外，基于图像美学质量评分模型，我们会优先选择质量分高的图片作为主体素材来源。对中低分的图片，未来可以考虑借鉴Cycle-GAN[13]的思想，设计基于半监督和GAN的图像增强网络，美化后再经过图像分割产生主体素材。海报模板拓展上述的常规设计风格的学习属于一种广义的设计风格，需要设计师先期投入很多精力做风格划分以及数据收集、处理。为了快速适配热点场景，我们借鉴图像检索技术(如图10所示)，提取素材图片的CNN特征及颜色特征，使用欧式距离来度量素材相似度，这能节省人工打标签的成本，实现基于固定模板的自动拓展及生成（海报临摹）。图10 素材图像检索与模板拓展多分辨率拓展在日常工作中，设计师在设计出Banner后，往往要花费很长时间对不同展位、不同版本、不同机型做多尺寸适配（如图11所示）。能否用算法来协助人工提效？在素材已经确定，并且相互的位置关系近乎确定的条件下做多分辨率适配，这本质上是一个优化问题，我们在上文布局优化器的基础上，增加元素的局部相对位置与全局绝对位置的拓扑关系作为目标函数。目前，系统支持在某个固定宽高比±30%范围内的任意分辨率适配，未来会进一步扩大适配范围。图11 多分辨率拓展总结目前，我们的Banner智能设计系统为钻展（外卖首页广告位）、商家店铺装修等业务提供稳定的设计能力；素材加工等子能力也在为外卖、闪购等商品图片提供技术支持。后续我们会从扩展常规设计风格、语义相关的颜色及素材挖掘、自动解析数据、构建自评估学习闭环等方面继续研究，进一步提高算法的设计能力和适用性，尽可能协助设计师提高效率，降低高重复性工作的时间和经济成本。参考文献[1] A. Jahanian, J. Liu, D. Tretter, Q. Lin, E. O’Brien-Strain, S. Lee, N. Lyons, and J. P. Allebach. “Automatic Design of Colors for Magazine Covers”. In Proc. IS&T/SPIE Electronic Imaging, International Society for Optics and Photonics, 2013[2] X. Y. Yang, T. Mei, Y. Q. Xu, Y. Rui, S. P. Li. “Automatic Generation of Visual-Textual Presentation Layout”. ACM Transactions on Multimedia Computing, Communications, and Applications, 2017[3] David G. Lowe. “Distinctive Image Features from Scale-Invariant Keypoints”. International journal of computer vision, 2004[4] Alex Krizhevsky, Ilya Sutskever, Geoffrey E. Hinton. “ImageNet Classification with Deep Convolutional Neural Networks”. NIPS, 2012[5] I. Goodfellow, J. Pouget-Abadie, M. Mirza, B. Xu, D. Warde-Farley, S. Ozair, A. Courville, Y. Bengio. “Generative Adversarial Networks”. NIPS, 2014[6] K. Kawakami. “Supervised Sequence Labelling with Recurrent Neural Networks”. Studies in Computational Intelligence, 2008[7] T. Mikolov. “Statistical Language Models based on Neural Networks”. 2012[8] L. Yu, W. Zhang, J. Wang, Y. Yu. “SeqGAN: Sequence Generative Adversarial Nets with Policy Gradient”. AAAI, 2017[9] L.A. Gatys, A.S. Ecker, M. Bethge. “Image Style Transfer Using Convolutional Neural Networks”. CVPR, 2016[10] Y. Li, M.Y. Liu, X. Li, M.H. Yang, J. Kautz. “A Closed-form Solution to Photorealistic Image Stylization”. ECCV, 2018[11] J. Long, E. Shelhamer, T. Darrell. “Fully Convolutional Networks for Semantic Segmentation”. CVPR, 2015[12] L.C. Chen, Y. Zhu, G. Papandreou, F. Schroff, H. Adam. “Encoder-Decoder with Atrous Separable Convolution for Semantic Image Segmentation”. ECCV, 2018[13] J.Y. Zhu, T. Park, P. Isola, A. A. Efros. “Unpaired Image-to-Image Translation using Cycle-Consistent Adversarial Networks”. ICCV, 2017作者简介晓星，2017年6月加入美团，目前主要负责美团外卖图像内容挖掘、增强、生成方面的相关工作，致力于图像相关技术的积累及落地。 ...

背景作为一家高度数字化和技术驱动的公司，美团非常重视数据价值的挖掘。在公司日常运行中，通过各种数据分析挖掘手段，为公司发展决策和业务开展提供数据支持。经过多年的发展，美团酒旅内部形成了一套完整的解决方案，核心由数据仓库+各种数据平台的方式实现。其中数据仓库整合各业务线的数据，消灭数据孤岛；各种数据平台拥有不同的特色和定位，例如：自助报表平台、专业数据分析平台、CRM数据平台、各业务方向绩效考核平台等，满足各类数据分析挖掘需求。早期数据仓库与各种数据平台的体系架构如图1所示：图1 酒旅早期各数据平台和数据仓库体系架构图图1所示的体系架构，在业务需求的满足上非常高效，但在长时间的使用过程中，也产生了如下一些问题：各数据平台或平台内不同模块的指标定义不一致。各数据平台或平台内不同模块指标计算口径不一致。各数据平台或平台内不同模块指标数据来源不一致。上述这些问题总结归纳起来，就是指标数据不一致的问题，最终带来的后果是指标数据可信度底，严重影响分析决策。通过后续追踪分析，上述问题的由来，主要是不同业务线的数据分析人员、数据开发人员，以及不同的产品之间，缺乏有效的沟通，也没有一个统一的入口，来记录业务的发生和加工过程。在加上人员的流动，长时间积累之后就产生了这些问题。针对这些问题，酒旅内部启动了数据治理项目，通过建设一个专业数据治理平台，实现指标维度及数据的统一管理，也探索一套高效的数据治理流程。挑战在建设起源数据治理平台的过程中，主要面临的挑战如下：起源数据治理平台应该在架构中的哪个位置切入，减少对原有系统的侵入，并实现数据治理目标。探索一套简洁高效的管理流程，实现指标维度信息统一管理，保证信息的唯一性、正确性。整合各种存储引擎，实现一套高并发、高可用的数据唯一出口。做好各业务线间的信息隔离和管理，确保数据安全。解决思路为了达成数据治理的目标，起源数据治理平台就必须记录下业务发展过程，并映射到数据加工和数据提取，规范约束这些过程。因此起源数据治理平台归纳到数据治理层，该层就位于数据仓库层（或数据集市层）之上，数据应用层之下起到桥梁的作用，而且提供一系列规则，改变原来无序交互方式，将数据仓库层和数据应用层的交互变为有序的、可查询、可监控。新的体系架构如图2所示：图2 数据治理后的新体系架构图如上图所示，在新的体系架构下：对于数据仓库层，起源数据治理平台综合业务组织形式、指标数据来源、上层产品的使用及查询的效率，指导数据仓库模型的建设；对于应用层的产品，业务元数据信息及数据信息都是由起源数据治理平台提供，保证了各数据产品获取到的信息一致，而且还简化了应用层产品数据获取成本，也降低了对原有系统的侵入。平台架构起源数据治理平台核心是保证数据一致，在数据安全的前提下，尽可能提升数据分发能力。因此平台内部有着极其复杂的关系，需要在建设过程中进行抽象，形成具有相对单一功能的模块；合理地组织模块的层级和连接关系，降低平台的开发难度，并提升平台的可维护性。平台架构如图3所示，展示了平台的内部模块组织方式。图3 起源数据治理平台架构图如上图所示起源数据治理平台在功能模块上由数据存储、数据查询、数据缓存、元数据管理、业务管理、安全管理、应用管理、对外API接口构成，各模块的功能介绍如下。数据存储起源数据治理平台管理的数据存储范围包括：数据仓库中的Topic层和数据应用层，存储方式包括：Hive、MySQL、Kylin、Palo、ES、Druid。如下图4所示：图4 起源数据治理平台管理的数据存储上图所示的这些数据存储中的数据的加工过程，由数据开发工程师负责，具体采用哪种存储介质，由数据开发工程师综合所需数据存储空间、查询效率、模型的组织形式等因素决定。但后续的使用维护都由起源数据治理平台管理，管理方式是通过管理这些数据表的元数据信息和查询实现，具体实现细节会在下面章节中详解。数据存储托管之后，数据表元数据信息变更监控、表数据生产（存储空间、生产状态及完成时间）监控、表数据波动（同环比等）监控以及表的使用（模型的构建及查询效率等）监控及评估，都由起源数据治理平台自动完成，所有信息的变动都会自动周知对应的负责人，保证数据应用的安全和稳定。元数据管理元数据信息宏观上包括两大部分：业务元数据信息和数据元数据信息。其中业务元数据信息包括：指标业务定义、维度的业务定义等；数据元数据信息包括：数据表元数据信息、模型元数据信息、维表与维度的绑定关系、数据模型字段与指标的绑定关系。起源平台为了实现元数据信息的管理，设计了四个模块实现，分别是：数据表管理模块、模型管理模块、指标管理模块、维度管理模块。元数据管理是起源数据治理平台的核心，起源平台就是通过控制好元数据，来驱动数据的生产和消费。数据表管理模块数据表管理模块管理了数据库信息和数据表信息。其中数据库信息包括数据库链接信息，数据库信息维护后，起源数据治理平台自动获取对应库中表的元数据信息。数据表信息包括：表的元数据信息（引擎、字段等）、表类型（维表或事实表）、表的使用情况（是否被模型使用）、表对应的ETL、表的负责人、表的推荐度、描述信息、表的监控配置及报警历史、以及样例数据等。上述这些信息为业务用户提供指导，为模型管理提供数据支持，为数据表和数据的稳定提供监控和预警。模型管理模块模型管理模块能够还原业务落地后数据表的组织关系，包括：数据表的关联方式（join、left join、semi join等）、数据表的关联限制、模型ER图、模型包含字段、模型字段与维度的绑定关系、模型与指标的绑定关系。不过在实际使用过程中，面向业务和面向分析的模型有所不同，起源数据治理平台是面向分析的，所以主要的模型包括维度建模中的星型模型或雪花模型，再就是OLAP多维分析的MOLAP或ROLAP。模型管理如下图5、图6所示：图5 起源数据治理平台数据表模型图6 起源数据治理平台SQL模型维度管理模块维度管理模块包括基础信息和技术信息，对应着不同人员维护。其中基础信息对应维度的业务信息，由业务管理人员维护，包括维度名称、业务定义、业务分类。技术信息对应维度的数据信息，由数据开发工程师维护，包括是否有维表（是枚举维度还是有独立的维表）、是否是日期维、对应code英文名称和中文名称、对应name英文名称和中文名称。如果维度有维表，则需要和对应的维度表绑定，设置code和name对应的字段；如果维度是枚举维，则需要填写对应的code和name。维度的统一管理，有利于以后数据表的标准化，也方便用户的查看。指标管理模块指标管理模块核心包括基础信息和技术信息管理，衍生信息包括关联指标、关联应用管理。基础信息对应的就是指标的业务信息，由业务人员填写，主要包括指标名称、业务分类、统计频率、精度、单位、指标类型、指标定义、计算逻辑、分析方法、影响因素、分析维度等信息；基础信息中还有一个比较重要的部分是监控配置，主要是配置指标的有效波动范围区间、同环比波动区间等，监控指标数据的正常运行。技术信息构成比较复杂，包括数据类型、指标代码，但是核心部分是指标与模型的绑定关系，通过使用演进形成了当前系统两类绑定关系：绑定物理模型和构建虚拟模型。绑定物理模型是指标与模型管理中的物理模型字段绑定，并配置对应的计算公式，或还包含一些额外的高级配置，如二次计算、模型过滤条件等；创建虚拟模型是通过已有指标和其对应的物理模型，具体步骤首先配置已有指标的计算方式或指标维度的过滤，然后选择指标已绑定的物理模型，形成一个虚拟模型，虚拟模型的分析维度就是所选指标基础模型的公共维度。衍生信息中的关联指标、关联应用管理，是为了方便观察指标被那些其他指标和数据应用使用，这是因为指标技术信息采用了严格权限控制，一旦被使用为了保证线上的运行安全是禁止变更的，只有解绑并审核通过后才可以编辑，所以这些衍生信息就是方便管理人员使用。指标技术信息如图7所示：图7 起源数据治理平台指标技术信息业务管理业务管理按照功能划分为业务线管理、主题管理和工单管理三部分，在系统的实际建设中是拆分为业务主题管理、数据主题管理和工单管理三大模块实现的。相关模块的建设主要保证业务人员和数据人员业务主题建设，相关模块的权限控制，业务流程审核，对应资源的隔离以及业务资源加工申请和加工过程的记录追踪。具体实现和功能如下：业务主题管理实现业务业务线管理和业务主题管理，实现不同业务线的管理以及业务线下的业务主题管理。业务线的拆分还隐藏着其他模块的权限管控和资源隔离的功能，不同业务线的用户只能看到有权业务线的指标和维度；而且业务线的用户划分为普通用户和管理员，分别查看或编辑维度和指标的业务信息。而且业务线和业务主题中分别维护的商分负责人对指标进行二级审核，因为新创建的指标仅仅是普通指标，如果想要全网都能查看，则需要发起认证，由这些人员审核。数据主题管理数据主题管理实现数据业务线和数据主题管理，实现不同数据线的管理以及数据线下的数据主题管理。数据线的拆分也隐藏着对数据表、模型、指标、维度的资源隔离和权限管控的功能，不同数据线的用户只能查看有权数据线的资源；而且数据线的用户分为普通用户和管理员，对有权资源进行查看或编辑。数据线的接口人在工单模块中具有审核工单的权限功能。数据主题的负责人拥有审核模型和指标技术信息的权限功能。工单模块管理工单模块管理实现了指标维度和对应模型加工线上申请、审核、加工、审批的流程。整个模块也是围绕着这四个流程实现的，具体是业务人员发起指标和维度集合的加工申请，然后由数据线接口人审核工单的合理性并分配对应的数据开发工程师，数据开发工程师加工模型并与对应的维度指标绑定，然后在工单中提交由数据接口人审核是否合理，最终由工单发起人验收。这个流程是一个标准的工单流程，每个节点的业务流程可能会反复，但是每次操作都进行记录，方便业务人员后期追踪。工单管理如下图8所示：图8 起源数据治理平台工单管理安全管理安全管理是起源数据治理平台核心功能之一，分为平台操作权限管理和接口调用权限管理两大部分。其中平台操作权限管理是通过与公司将军令权限管理系统打通，并配合平台其他模块中权限控制代码，实现了权限管理、审批、审计三大功能模块；接口权限管理是通过平台内的数据应用管理和外部应用管理模块的映射关系，并在接口调用时鉴权实现，这部分会在下面的应用管理章节中介绍。权限管理模块权限管理模块是将平台的资源分划分为页面权限、业务线&数据线用户权限、数据应用权限来实现的。页面权限实现平台内页面访问控制。业务线&数据线用户权限是将用户分类为普通用户和管理员，普通用户只能查看业务线和数据线内资源，管理员可以操作业务线和数据线内的资源；并且通过业务线和数据线的独立管理实现资源隔离，业务线实现了所属维度和指标的隔离；数据线实现了所属数据表和模型的隔离，并且通过建立业务线和数据线的关联关系，也保证了指标和维度的技术信息操作隔离。数据应用中每个应用都是独立管理的，每个应用权限都拆分普通用户和管理员，普通用户可以访问查询应用，管理员可以操作应用。审批模块审批模块包含审批工作流、我的申请、我的审批构成。审批工作流是根据不同的应用场景实现不同层级的审批，例如：在指标管理中服务于个人的普通指标变更为服务于整个业务线的认证指标，就需要发起两级审批，由业务主题负责人和业务商分审核通过才可以；模型管理中新增或修改模型上线，都需要数据主题负责人审批；数据应用的变更，都需要下游所有依赖外部应用负责人审批才生效。我的申请和我的审批是平台页面方便用户查看流程进度和操作审核。审批模块目标是保证发布信息的正确性、系统服务的稳定性。审计模块审计模块包括用户操作记录和记录查看追踪。用户操作记录是平台各模块调用接口记录用户每次操作前后的数据变更；记录查看追踪是检索查询页面，查看对应的变更。审计模块保证了用户操作追踪追责，也保证误操作的信息恢复。应用管理应用管理由数据应用、外部应用、数据地图三大模块组成，它们构成了对外服务的主体，记录了外部应用与平台内管理的指标、维度、模型和表的关联关系，也提供数据查询展示、应用层ETL生产的能力。而且数据开发人员从底层向上观察，可以追踪数据最终的所有流向；业务分析人员从顶层向下观察，可以看到构成服务的所有数据来源。数据应用模块数据应用模块是记录生成每个服务所需的指标、维度和数据模型的关系。每次服务中可以包含多个指标，这些指标可以来源于多个数据模型，不过不同的数据模型中需要包含公共维度，因为是通过这些公共维度将不同模型关联起来。数据应用中构建的服务可以发布成查询服务、应用层ETL生产服务、对外API数据接口服务、通用报表配置服务，来满足业务的不同需求。数据应用管理如下图9所示：图9 起源数据治理平台数据应用外部应用模块外部应用模块管理外部应用和应用内的模块，以及这些模块订阅的对应数据应用，目标是实现API接口调用的权限管理和数据最终流向的记录。具体的实现上模块首先创建对应的外部应用，记录外部应用的名称、URL、APPKEY等信息，然后由对应应用的负责人创建模块，记录模块名称、URL、moduleKey等信息。这些信息完善后，由对应的数据应用赋权给对应的模块，建立起数据应用与外部应用的联系。最后在外部应用调用平台对外API接口时，进行权限管理。数据地图数据地图功能是追查数据的流向，可以从数据表、模型、指标、数据应用、外部应用任意节点查看上游数据来源和下游数据去向。起源数据治理平台核心功能也是组织这些节点间的关系，形成完整的服务，数据地图就是通过上面介绍模块记录的关系，追踪数据流向，方便数据开发人员和业务分析人员了解数据消费和数据来源。数据地图如下图10所示：图10 起源数据治理平台数据地图对外API对外API接口是一套完整的对外信息提供接口，提供的功能分为元数据信息类的接口、数据类接口、监控统计类接口，分别满足外部平台和分析人员的对应需求。外部系统通过起源数据治理平台获取到的元数据和数据是经过认证并由平台自动校验后的，可以保证信息的一致性、正确性。元数据信息接口元数据信息接口提供的包括指标、维度业务元数据信息和数据表、模型、指标计算、维度维表相关的数据元数据信息，实现与上游系统信息共享，达到信息一致性的目标。数据类接口数据类接口提供指标维度数据查询服务，不单单满足常见的单条SQL查询，而且可以实现多次查询聚合运算（例如：同环比等）以及跨引擎查询，并通过并发处理，可以有效提升查询效率，满足更多的业务场景。接口具有监控功能，能够评估每次查询效率，提供查询指导或预警的能力。监控统计类接口监控统计类接口提供指标数据监控信息、指标维度使用统计、数据接口的调用效率统计等服务，帮助下游服务平台了解服务质量。内部工作原理起源数据治理平台内部工作原理就是实现指标、维度业务信息与数据模型计算关系的映射管理，并根据外部应用所需的指标、维度以及查询条件选择最优的模型动态的实现查询SQL或查询Query的拼接，然后通过分布式查询引擎实现数据的高效查询，具体过程如下图11所示：图11 起源数据治理平台内部工作原理上图所示的分布式查询引擎，整合了大数据分析常见的各种存储，通过封装的接口提供服务。而且分布式是通过Akka Cluster自主实现，通过Cluster Singleton解决单点故障的问题，通过Redis实现了任务队列的持久化，通过平衡子节点任务量实现任务的合理调度，通过查询状态监控自动实现查询降级和任务队列的拆解，并且也完善了整个调度的监控，可以实时查看任务和节点的运行情况。管理流程起源数据治理平台生产所需参与的角色包括：业务人员和数据开发人员（RD）。为了保证信息的正确性，平台内有着严格的管理流程，需要不同的角色在对应的节点进行维护管理，平台的管理流程如下图12所示：图12 起源数据治理平台管理流程所上图所示，指标的业务信息需要业务人员首先进行维护，然后数据RD同学进行相应的数据表的建设，维护对应的数据表和模型的元数据信息，并完成指标与模型的绑定，最后由数据RD同学构建数据应用为用户、业务系统及数据产品等提供服务。建设成果经过长时间的探索开发，完成了起源数据治理平台的建设，成功的解决了上面提到的问题，并且已经完成了酒旅内部10+个数据平台（包括定制化产品和通用报表服务平台）的数据治理支持。起源数据治理平台还带来了一些额外的收获，总结归纳起来实现了3个目标，提供了4种能力，如下：统一指标管理的目标。保证指标定义、计算口径、数据来源的一致性。统一维度管理的目标。保证维度定义、维度值的一致性。统一数据出口的目标。实现了维度和指标元数据信息的唯一出口，维值和指标数据的唯一出口。提供维度和指标数据统一监控及预警能力。提供灵活可配的数据查询分析能力。提标数据地图展示表、模型、指标、应用上下游关系及分布的能力。提供血缘分析追查数据来源的能力。如果换位到指标的角色，以辩证的角度分析，起源数据治理平台解决了一个终极哲学问题：我是谁，我从哪里来，我到哪里去。未来展望起源数据治理平台是天工体系（从数据管理、查询到展示的一个完整生态）的一部分，整个天工体系还包括如意通用报表系统、筋斗云数据查询系统。通过对天工体系的建设，直接目标是为业务提供一整套高效、高质量的数据服务平台；但是在天工体系的建设中，进行微服务治理，抽象形出一套统一标准，吸纳更多的业务参与建设，为业务提供开发降级，避免服务的重复建设，提升服务建设速度。如下图13所示：图13 天工体系架构图如上图所示，天工体系开放三套交互标准，实现模块的可插拔和自由扩展，分别是：元数据交互标准，实现元数据管理的可插拔。数据查询标准，实现数据查询引擎的可插拔。可视化组件数据交互标准，实现可视化组件的可插拔。作者简介夷山，美团点评技术专家，现任TechClub-Java俱乐部主席，2006年毕业于武汉大学，先后就职于IBM、用友、风行以及阿里巴巴。2014年加入美团，长期致力于BI工具、数据安全与数据质量工作等方向。李鹏，美团点评技术专家，曾就职于搜狐畅游、网易，2018年加入美团点评，长期致力于数据治理、数据仓库建设、数据平台研发等工作方向。招聘最后插播一个招聘广告，有对数据产品工具开发感兴趣的可以发邮件给 fuyishan#meituan.com。我们是一群擅长大数据领域数据工具，数据治理，智能数据应用架构设计及产品研发的工程师。