共计 5211 个字符，预计需要花费 14 分钟才能阅读完成。
本文整顿自 37 手游 技术主管彭佳铭 和 高级算法工程师左伟健在 OpenMLDB Meetup No.6 中的分享 ——《OpenMLDB 在 37 手游 特色计算场景中的利用》。大家好，我是彭佳铭，来自 37 手游算法团队。明天将和我的搭档左伟健给大家带来 OpenMLDB 在 37 手游 特色计算场景的利用分享。分享的前半部分会由我来主讲，次要介绍 37 手游、37 手游算法利用场景以及 OpenMLDB 的引入历程。37 手游 介绍
首先为大家介绍一下咱们公司吧。37 手游成立于 2013 年，是上市公司三七互娱旗下的独立子公司，专一于移动游戏的经营，致力于手游游戏发行业务。在中国大陆地区，37 手游以 10% 的市场占有率，位居行业前 3，仅次于腾讯和网易。在非中国大陆地区，37 手游也胜利进入了“月入过亿”俱乐部。
迄今为止，咱们胜利发行过很多优良的作品，包含《永恒纪元》、《一刀传世》、《云上城之歌》（在韩国颇受关注和好评）、《谜题大陆》、《斗罗大陆：魂师对决》等等。也邀请到了很多颇具影响力的形象代言人，成龙、李连杰、拂晓、王宝强、金馆长等均是 / 曾是 37 手游旗下的作品的形象代言人。
目前，37 手游累计为超过四亿游戏玩家提供过服务，用户量和数据量比拟宏大。咱们着重强化本身的游戏经营能力、市场推广能力和广告设计能力，并联合这三种外围能力提出了立体化、AI 智能化营销的“流量经营”策略。37 手游算法利用场景 基于这一打法策略，37 手游的算法团队次要服务于公司“智能风控”、“智能投放”、“智能经营”三大智能业务模块。
第一模块的智能风控是咱们公司业务的护城河。目前，37 手游围绕算法团队外部构建的审判零碎 ——“神探”，构建了一个平面风控体系。次要解决游戏发行厂商常见的风控问题，比如说防拉人或者刷号（资源号、初始号）的黑产反抗。第二模块是智能投放。作为一家头部的游戏公司，在投放畛域也投入了较大的工夫精力人力去构建算法的相干利用。最近几年，不仅是抖音、快手这类视频产品的广告平台在尝试构建自动化智能化的投放策略，头部的游戏公司也在着手构建本人的智能投放平台。这一块也是咱们正在尝试构建的一个外围竞争力，目前 37 手游曾经基于外部的“量子”搭建了一站式智能投放零碎。第三模块即智能经营模块，次要服务于智能化营销以及智能化客服。接下来将会以此模块为例，为大家做一个具体的利用场景介绍。
以后算法次要是利用在智能化营销相干的散失预测场景上。其实大家也有理解，互联网公司曾经不再处于用户快速增长的一个红利期，用户增长老本也在逐步进步。那对于产品来说，如果能服务好存量用户并防止或缩小用户散失的话，实际上的收益将远远超过开发同等量级新用户。所以散失用户的召回成为了后续产品倒退的一个要害。过来的教训通知咱们：过来的教训也通知咱们，留住用户最好的机会是在用户行将散失前。如何在及时的工夫点预估用户的一个散失偏向，是咱们须要解决的一个要害业务问题。37 手游最开始的计划是一个 T+1 数据的一个离线预估解决，但这意味着咱们召回机会的错失。所以过后咱们提出要做在工夫线上更提前的节点做出拦挡召回，实现更及时的散失预警。同时咱们以此做到依据用户的行为特色或属性特色去无效辨认散失危险，智能配置多元化的召回策略，再通过一些试验提出一些比拟好的召回计划，最终达到留住用户的目标。这个时候就须要咱们在技术层面上做到更快的预估，所以咱们开始了技术调研。上面展现的是散失预测场景的流程图。一开始的话，咱们是依照左图以 T+1 维度进行的一个预估。后续咱们依照右图，提出了一个演变后的流程。
在日志数据进入后，咱们会做一个原始的解决，接着进行离线特色的抽取。抽取完之后，咱们会开始着手进行一个模型的预估和训练并且调优，最终评估模型的成果是否满足上线需要。在达到下限成果的时候，咱们会给开发团队提出线上特色的开发需要。最终通过和后端的联合，实现性能的上线。在理论推动的过程中，咱们会面临很多问题，比方 PPT 中提到的线上线下不统一带来的一些问题。在开发过程中，离线算法团队会编写离线特色，开发团队会帮忙实现线上特色，这时候就带来了一个口径对齐的问题。在开发实现之后，咱们还有一个比拟漫长的对数过程。最初，在开发周期上也导致了困扰。OpenMLDB 引入历程
方才提到咱们做了一些技术计划上的调研，理解了 Featurestore 的相干技术。因为咱们和阿里有单干关系，所以也理解到了阿里的一些闭源解决方案。然而因为阿里的我的项目还处于外部阶段，并且也不是特地贴合咱们的业务，所以咱们决定另寻其余计划。往年五月份的时候，咱们接触到了 OpenMLDB，退出了微信社群，分割到社区经营负责人，通过一些案例解说和技术分享理解到了这样一个组件的存在。在 5 月 26 日约了线上会议，做了深刻的理解之后，发现 OpenMLDB 正好是切中咱们的业务痛点。过后咱们是提了很多问题的，包含：OpenMLDB 的个性是什么？OpenMLDB 和其余特色仓库的比照体现如何？OpenMLDB 在特色方面能不能做到共享跟复用？OpenMLDB 有没有运维的难点，要如何解决？OpenMLDB 怎么去保障大量数据的流转？如果真正上线后呈现数据谬误，怎么去做解决？在那天的会议中，咱们还聊到了一些老本相干的话题，以及后续应用能不能给到一些技术支持。并且在会后咱们也建设了一个交换群，并且有开始有打算地去进行一些部署跟测试。
于是在六七月份，37 手游应用 OpenMLDB 进行了离线特色场景的特色抽取测试，并且在八九月份咱们尝试在线上场景做一些特色计算测试。在将来的话，咱们和 OpenMLDB 团队探讨后布局了后续的议程，有在着手一些上云的计划，并心愿在这一块比拟深刻的单干。这就是咱们的业务背景以及逐步引入 OpenMLDB 的过程，接下来会由伟健去解说咱们在接触和引入 OpenMLDB 期间做的绝对残缺的测试以及失去的一些论断。业务场景介绍
大家好，我是 37 手游的左伟健。在接下来的分享中我会先简略介绍一下咱们的业务场景和整体的部署流程。在解说在引入过程中咱们遇到的问题和对应的解决方案。第三局部，我会展现在整个业务落地过程中实际得进去的论断，包含咱们所冀望的性能是否被 OpenMLDB 满足。最初，我会在将来瞻望局部探讨如果 OpenMLDB 要在公司业务场景中大规模落地还须要做哪些筹备工作？还有哪些性能点是心愿失去满足的？
方才佳铭也有提到，采纳了用户散失这样的业务场景去做试用，次要是想借助 OpenMLDB 更快更实时对用户的散失动向造成预估。预估实现之后，依据业务配置的策略将用户召回，比如说提供礼包、设置流动将玩家从新拉回到游戏外面。简略来说，咱们想要在用户触发登录时候，计算出用户的过后的特色，进而预测用户是否会在最近七天中散失。因为整体业务的用户量级达到了百万级，所以数据量也比拟宏大，这是咱们引入 OpenMLDB 的业务背景。
整体部署与问题解决 接下来我会介绍整体部署流程和问题解决，次要分为组件部署、特色设计、数据导入和问题解决四局部。
组件部署方面，思考到数据量级和稳定性的要求，放心单机版不能满足需要，咱们部署了 OpenMLDB 的一个集群版。同时，部署集群版也能为咱们其余业务大规模实际提前做调研。整体上也部署了 zookeeper、tablet、nameserver、APIServer 和 TaskManager 这些必要组件。
在 SQL 和数据表方面，咱们次要用到三张表，一张是登录表，一张是领取表，最初一张是行为表。而后下图中列举了三张表格的必要字段，像登陆表的登录 ID、游戏 ID、用户 ID、登录的工夫；领取表的用户 ID、领取工夫、领取金额、领取物品等；行为表中则是对应的行为数据。这里列了一个简略版的构造。
特色设计方面，下图展现一个简化版的特色。其中包含，三天、七天、十五天、三十天的登录次数、行为次数、领取次数和领取金额。这一部分不做详解，因为咱们想把重点放到接下来的部署流程。
在登录次数方面，实际上它是一个主表的窗口特色，这是参考官网的 SQL 设计文档编辑的特色。领取次数，领取金额的也是相似的特色，但它们实际上归属一个不同的类别，是副表的聚合特色。行为次数也是副表的一个聚合特色，所以实际上它们 SQL 的构造下面实际上差不多的。以上就是咱们在特色方面的设计。
特色设计实现之后，咱们去对这个数据进行导入。咱们在离线和在线局部采纳了不同的一个计划，离线方面咱们通过 HDFS 的文件导入，次要是因为咱们离线局部应用了大数据的组件，而后离线的一些日志次要存储在 HDFS 下面，所以采纳了 HDFS 文件间接导入的计划。在线方面，咱们没有采纳 SDK 导入的形式，而是采纳了 Kafka Connector 这一个计划，因为咱们理论业务的在线局部曾经有实时数据流曾经导入到 Kafka 中了，就能够间接用 Kafka Connector 对现有的一个数据流进行生产，导入到在线的表外面。
在这个过程中咱们可能次要遇到了三个问题。第一个问题是，咱们要在建表时留神索引的建设。这样有利于咱们后续多个场景对表格进行复用，而不须要在业务上线后，再去批改索引。因为像之前提到的副表聚合等，实际上会走一个索引键，一个是组件，像 UID 和工夫键 TTL 须要去走。咱们在一开始的时候，没有笼罩到索引，而后发现咱们须要重复批改索引，导致组建工作的减轻。工作减轻，进而容易带来咱们的组件重启、下线等等。第二个问题存在于在线数据流格局方面。实际上原版的 Kafka Connector 的数据格式和咱们线上的 Kafka 数据流格局不同，这导致了咱们不能间接应用原来的 Kafka connector 把数据拉到咱们的在线环境里。这里咱们专门求教了 OpenMLDB 的开发团队，最终 OpenMLDB 研发同学帮助咱们开发了一个比拟通用的格局。第三个须要关注的是组件运行状态。比如说咱们的组件是否重启，而后节点的存活状态等等。为什么特意提到这个问题呢？其实是咱们在试用的过程中建设索引、批改索引的时候呢，就会常常会导致那个组件进入重启或者审核状态。咱们会发现因为当整体组件的运行状态不对的时候，服务的稳定性是不够的。有时候会呈现申请响应较慢或申请数据和导入数据不统一，但实际上是受咱们组件运行状态导致的问题。所以这一块也是比拟须要关注。如果后续大规模上线应用 OpenMLDB，在监控方面咱们也肯定会去做这方面的安顿。
试验论断 整体试验的论断是：OpenMLDB 能够满足咱们对性能点的期待和业务场景的需要。在离线导出方面，接口开发完后，咱们就能够说对特色开展比拟疾速的导出和计算了。还有就是因为 OpenMLDB 人造保障线上线下一致性，像 TTS 的工夫设计等咱们无需放心数据泄露方面的问题。在线上服务方面，咱们发现 OpenMLDB 能帮咱们去缩小比拟多的新特色上线工作量，缩短上线周期，在业务上有比拟大的晋升。当初咱们能够从原来的 15 / 人 / 日降到 1.5 / 人 / 日左右的工作量，可能比拟快地将线上业务或模型进行迭代。
将来瞻望 如果后续还要去推动 OpenMLDB 大规模落地，咱们还须要对两局部工作做进一步的开展。其中一个就是监控。组件服务的状态会导致咱们整体服务质量或者说数据计算的一些小问题，所以咱们须要去对组件状态进行监控，而后再监控下层服务整体状态。再者是数据一致性还须要做比对，保障咱们提供给线上服务的特色所计算出来的数据不存在偏差。另一个值得关注的问题是落地老本预估。老本预估方面，咱们也求教了 OpenMLDB 的技术团队，次要思考了两个方面，第一是线上方面，须要掂量 TTL 工夫范畴内的存储数据量，因为这关系到内存方面的资源要求。第二是在离线方面须要思考离线存储所须要的存储空间，如果是云的话，能够忽略不计。还要留神的是咱们抽取离线特色须要用到的计算资源，这也会关乎到落地老本。
除了咱们对现版本的 OpenMLDB 有一个推动打算之外，咱们还对将来的 OpenMLDB 有一些期待。在实际的过程中，咱们发现 OpenMLDB 特色治理这一块的性能比拟少。咱们心愿 OpenMLDB 将来能开发特色元信息管理性能。比如说能够帮忙咱们对整体特色进行一些梳理等等，不便咱们疾速地复用先前结构特色的教训以及疾速发展其余的一个业务。还有一个期待更凑近性能上的优化降级。现版本的 OpenMLDB 在线上特色计算时是对每一个部署的 SQL 离开计算过后的特征值，咱们认为这里能够应用的计算资源能够进一步优化。第二点是离线计算依赖的次要是特色计算始末工夫，从实践上来说，也是能够对离线特色也进行计算复用的。
总体而言，OpenMLDB 对咱们业务需要的性能笼罩还是很不错的。以上就是咱们的分享，谢谢大家。
相干链接
✦
OpenMLDB 官网
https://openmldb.ai/
OpenMLDB github 主页
https://github.com/4paradigm/…
OpenMLDB 微信交换群
