伊对资深架构师 王成光
本次主题的内容主要分三点介绍，第一是伊对的简介，第二是推荐平台的架构简介，第三是PAI在推荐平台的应用。
伊对的简介
伊对是北京米连科技有限公司旗下的品牌。公司成立于2015年，是国家高新技术企业，也是北京中关村的高新技术企业。2019年公司营收近10亿元人民币，2020年6月获得小米、人民网旗下基金等多家机构的近1亿美元的融资。伊对主要专注于移动端的线上交友和相亲，将视频、直播和在线红娘创造性地融入该领域，开辟了视频恋爱社区的独立赛道，为单身人群提供了全新的社交体验。截止2020年8月，伊对注册的用户超过4000万，活跃红娘4万多人，每月撮合线上相亲活动约1000万场。“找对象，上伊对”，我们竭力为用户提供一个更阳光积极、真实的恋爱社区，我们希望每一个用户都能遇到心动的他/她。
平台的架构简介
主要从三个部分介绍。第一，弹性扩展的服务架构，保证服务的高可用。第二，数据计算存储架构提供底层数据挖掘支持。第三，算法模型的架构，保证推荐的效果。
首先来看弹性扩展服务的架构，整体架构基于服务网关+自研弹性扩展服务框架的结合，上游业务端通过服务网关分发服务给各个业务端的微服务，而微服务的实现是依赖于我们自研的弹性服务框架。
自研弹性服务框架主要涉及到4个特点。
第一是支持主流的开发语言，像Java、GO、Python等。
第二，为了支持服务的弹性扩展，我们借助了容器，像ZooKeeper和Etcd这两个都是可选的。
第三是兼容当前主流的服务框架，像RPC框架里面谷歌的GRPC，Facebook的Thrift，以及类似于spring boot的Restful Web Service。
第四是支持容器化部署，像Docker和K8S。这是我们的资源的弹性服务框架，也是当前线上使用最多的框架。
数据计算存储架构，是我们业务中使用最多的计算框架，其中包含三个部分：
第一，是离线计算，离线计算主要借助 Hadoop、Spark 以及阿里云的 DataWorks 中的 MaxCompute。
第二，实时计算主要借助 Flink 和 Spark Streaming，前期还有 Storm 和 JStorm，只是相比较而言，现在 Flink 和 Spark Streaming 用的居多。
第三，为了满足一些线上轻量级的业务快速的应用落地，我们也使用自研的轻量级的流批合一的计算框架—— Ldrtc，主要借助 Spark Streaming 的 Mini-Batch 和 Storm 流式拓扑任务的设计思想实现，最小资源化地在线上云资源上使用。
数据计算的存储架构，对推荐服务而言，底层的数据存储是我们的核心所在，数据主要从以下6个方面介绍：
一，业务元数据的数据库存储主要借助MySQL和TiDB。
二，用户的行为及用户画像部分主要借助MongoDB的存储。
三，满足业务需要的业务数据、报表数据，主要存在 Hive、Impala、Presto、HBase 和 Clickhouse 等数据库，之所以列出来这么多数据库，是因为每个数据都有它自身的一个特性来满足不同的业务需要。
四，对于社交产品而言，其社交关系、社交网络存储我们选择图数据库，先后主要使用Neo4J、ArangoDB、Dgraph这些图数据库，前期也做了一些数据的升级和变更，目前选择使用的是业务支持更成熟的Neo4J。
五，面向在线的查询服务数据库主要借助Redis和Elastic。
六，除上述这些开源的数据库的组件，为了满足自己的业务需要，还有自研对象数据库。
自研的对象数据库，它主要支持聚合大value复杂数据。之所以叫对象数据库？这个对象并不是指我们传统的文本、图像或视频等对象，它是指我们在日常软件开发时所用面向对象的类实例，是一个比较复杂的业务数据对象。整个对象就是一个Java或C++里面的Object类实例，里面有很多属性、方法等。大Value数据的存储是相对于MongoDB这样单条数据不能超过16M的存储，因为一些实际业务的限制，我们自研了对象数据库。
它主要有6个特点。
第一，基于Java语言开发，支持横向的弹性扩展，而Java也是目前使用最广的服务端语言。
第二，数据的另一特点是数据索引分离。数据的存储和索引部分是分开存放的。索引你可以选择使用Redis或MongoDB，而底层的存储，我们借助RocksDB的字节流来满足业务数据非固定大小的弹性扩展。
第三部分是高效的读写，是指对外提供批量查询和添加修改一体化的批量数据异步更新接口，对外只提供基础的添加接口，内部依靠异步更新任务来将最新的数据和已有的数据融合，不需要用上游业务端关心如何更新。
第四个特点就是相对于MongoDB单条数据不超过16M，在一些比较复杂的业务场景下使用往往受限，这也是我们自研对象数据库的一个原因。
第五，高效存储，主要是指在数据存储前，把这个比较复杂的对象序列化。序列化主要基于Hadoop底层的标准序列化框架Avro。其存储和MongoDB相比较，同等数据规模，自研对象DB存储比在MongoDB里面存储能节省1/3的空间。
第六，高效通讯，是指底层传输依赖于高效率的RPC通讯，像Avro、Thrift。
上述是我们自研对象DB的6个核心点，也是满足我们业务需要而独立研发的一个行业技术创新点。
推荐平台里面的算法模型架构，算法模型主要涉及到6个部分：
第一是基于用户自身资料的相似，主要基于用户自身的基本属性，从Elastic索引库里面找相关的信息查询，多维度匹配。
第二是基于用户行为的推荐——关联规则和CF协同过滤。
第三是图像识别的分类，基于TensorFlow，用于用户的颜值高中低分类，以及用户发布的动态图文内容分类，动态图文有风景、美食和人物分类等。图像识别分类也是我们很重要的一个模块。
第四部分是社交关系，它是我们做社交产品的一个很重要的基础，主要基于图数据库做服务召回，模型中有单双向匹配以及N度人脉，这里N一般不超过3。
第五部分是用户画像的构建，社交存在着物以类聚人以群分的特性，所以对我们的用户群体也做了聚类，构建了一个个的用户群体标签。
最后一个就是特征工程训练，使用当前主流的Xgbt和深度学习的框架DeepFM等。恋爱公式：“恋爱转化率 * 机会 = 结果”，这是我们CEO任总给的一个结论，意思是要想获得心仪的对象，机会成本的付出是必要的，而且需要游客在不断的探索中寻找真爱。而我们推荐的目的就是要帮用户更加便捷的寻找到真爱。
主要从三个部分介绍。第一，弹性扩展的服务架构，保证服务的高可用。第二，数据计算存储架构提供底层数据挖掘支持。第三，算法模型的架构，保证推荐的效果。
PAI在推荐业务的经验，PAI是阿里云比较成熟的机器学习框架平台，它能够覆盖推荐的整个链条——从前端用户行为的埋点收集、行为日志到加工、数据分析以及用户画像的构建，包括在线的学习以及推荐服务、召回、过滤及综合排序，最终推荐给用户。可以说PAI这一套整体的运用大大方便了，初创公司以及对推荐业务不太成熟的企业迅速落地，大大提高了整体效率，这是PAI自身的优势。
PAI在推荐场景的算法服务，可以说业内主流的这些推荐算法，像协同过滤、ALS的矩阵分解、LR逻辑回归、FM、 LDA这些自然语言文本处理分类算法以及涉及到人工的运营策略都考虑得非常充分。它里面还涉及到多路召回，将各种独立召回算法模型结果，使用像LR、GBDT、FM等综合排序最终融合在一起。所以说PAI是非常成熟的一个机器学习平台，也能大大加快推荐业务使用效率。
相亲推荐是PAI在我们实际业务中的一个具体应用场景。相亲是我们伊对APP里面最核心的一个用户场景，用户相亲交友时，视频直播间的推荐是非常关键的一环。从PAI在整个相亲推荐的应用上看，主要分为4个维度。从推荐维度上看，有直播间的红娘推荐和嘉宾的匹配以及视频质量的评分等。其次是在线训练，像多路召回、排序及策略等，它都是基于PAI现有的机器学习算法模型来使用。再其次就是底层的数据加工和用户特征工程的建立，以及底层数据的周期性的更新，有天级别、小时级别和分钟级别的这些更新。整体的基础数据准备好了，接下来就是更好的是利用PAI的成熟的服务平台，构建我们的相亲推荐服务。
整体的相亲推荐流程就如上述架构图描述的。首先从用户曝光请求发起，获取用户的基本信息，再从阿里云的Hologres里获取已有的特征模型，再基于在线的特征学习训练，把这些特征工程结合底层的离线和在线的学习计算综合排序，最终产生的结果反回给用户。
我们的训练的所有数据都是来源于飞天大数据平台的处理，除了推荐平台，还有一些基础业务报表的使用。其优势，主要是MaxCompute计算性能比Hive和Impala都有了大幅度的提高，其成本方面也降低了50%。其次就是Streamsql也简化了Flink的开发。Hologres本身相当于是Hbase+Druid，但更加方便使用，业务功能上类似于Redis，但是比Redis更加廉价，更加方便运用。这些都是它的一些实际应用的优点所在。
展望PAI在我们伊对未来的工作，后续我们会应用到更多的推荐业务场景，验证其效果，其次是尝试风控反作弊等在PAI的使用，后期我们会投入更多的人力研究使用PAI，逐步替换内部一些自建的大数据平台。
谢谢大家！
更多大数据客户实战案例：https://developer.aliyun.com/article/772449