图谱技术在贝壳的实践

标签:无 2537人阅读 评论(0)
分类:

贝壳找房于12月13号在北京环球财讯中心进行了一次关于知识图谱方面应用与实践的分享。总结了一下听的贝壳几位专家在图谱技术方面的一些分享。

1.关系图谱在贝壳找房风控体系的应用与实践 贝壳风控 王学志

主讲人的将分享分成了三个部分,贝壳风控业务概况,关系图谱在贝壳风控的应用与实践,关系图谱的规划。

首先他先介绍了贝壳的业务模式,即贝壳想要打破客户,房源,经纪人之间的ACN网络的联络难题,以及贝壳想要扩展业务边界,形成利益联盟,信任联盟,尊严联盟,品质联盟,网络联盟。其次他介绍了在贝壳在业务方面存在的风险,如平台体验类的虚假房源、客源,虚假带看等,如平台利益类的外部爬虫,资源泄漏,高能低效等,如平台规则类的经纪人藏客,藏房,IM恶意竞争等。同时他结合业界遇到的风控问题提出了贝壳风控自己的特点:贝壳与业界的线上模式不同之处为其“线上+线下”的模式,从房源录入到最终成交需要经过35个环节的超长链条;同时贝壳会面临加盟商风险、经纪人风险等;贝壳的交易场景是低频、大额、长周期的。

第二部分王学志介绍了贝壳风控团队为什么使用图谱技术以及图谱技术在风控中的实践。目前业界风控中主要采取了黑名单、专家规则、有监督的机器学习模型、行为序列分析这些技术。但是每一个都有自己的局限性,如全行业内的黑名单,需要公司之间的数据共享,但是往往公司都不愿意共享数据,如专家规则的建立耗费人力物力,同时也存在出现经验错误而导致的误判。图谱技术目前在风控中适用于团伙发现,而在贝壳的服务中,利用图谱技术可以在发现大型的团伙违规中获得更好的效果。贝壳风控的事实图谱中含有19类节点,47类的关系,节点数有10亿+,关系数有100亿+,面对这么庞大的数据量,王学志也谈了贝壳风控的技术选型,在图计算上他们选择了生态圈更加友好的Spark作为引擎,在图数据库方面他们选择了对Spark可以很好支持的分布式图数据库JanusGraph,在有了技术架构后,他谈了贝壳风控利用图谱技术的一些详细应用:包括准入防控、风险量化、品质管理、风险发现、查案溯源等。在风险量化中他分享了目前已经采用的两种方法,一个是基于Louvain算法,一个是基于node2vec算法,可以用在社区发现以及经纪人与加盟商后续风险的预测等。谈到规划上,贝壳风控在未来会利用图谱技术实现违规溯源智能化、工单自动化处理、违规模式自动学习等。

 

2.从0到1构建图谱 贝壳策略算法部 周玉驰

首先周玉驰谈了为什么要做关系图谱,贝壳找房近年来发展迅速,客户,房源等增速很快,贝壳的经纪人,客人,房源之间的行为数据等可以用关系图谱来表示。

之后他介绍了目前贝壳的关系图谱实现了多度查询,影响力查询,Embedding,聚类等。在关系图谱的建立中分享了基础图谱中客户买房,业主卖房事件中各种行为如VR带看,电话沟通,委托等是如何建模到关系图谱中的,同时也介绍了不同的关系类型他们采用了不同的权重,如高频关系权重大于低频关系,近期关系权重大于远期关系等。随后其介绍了在关系图谱中一些实例是如何建立的,如在房子图中利用基于用户行为序列进行一定的建模,考虑同一事件窗口内用户浏览过的房子是其感兴趣的,则房子两两之间可以进行关系建模;在经纪人模型中采用度中心性的方法来判断每个经纪人节点的影响力从而关注其转化率。后续周玉驰也谈到了Graph Embedding的发展,在同质图中贝壳采用了node2vec算法,其核心优点是平衡了深度优先与广度优先算法,异质图中采用了Metapath2vec算法。最后他分享了在关系预测中基于用户相似度的房源推荐,从优质房推导出优质客户。

 

3.百亿图谱如何实现毫秒级查询 贝壳找房搜索平台负责人 高攀

本次分享高攀主要从基础平台的技术选型与平台建设来分享。首先他以客户想要查询开放商是xx,绿化面积大于30%,周边有地铁,学校,大型超市,房价xx万以内的房源为例提出现有的关系型数据库需要关联几十张表,非常不现实,而图数据库可以满足这样的图谱数据。

之后他展示了DB-Engine上的数据,可以看出市场上有很多流行的图数据库,图数据的基础平台建设需要考虑开源,成熟,扩展,文档,性能,稳定,运维,易用这些方面,如何进行选型是一个问题。接着他分享了贝壳基础平台在技术选型上的思考,目前市场主流的是Neo4j图数据库,其社区版开源,但是社区版仅支持单机,不支持分布式,并不能很好的做到扩展;OrientDB也是主流的数据库但是其webUI管理模块收费且不支持分布式;JanusGraph与DGraph两个图数据库都是开源,且支持分布式的数据库,所以他们在选型上针对二者进行了深入比较。

首先在架构上,JanusGraph依赖其他存储系统如Cassandra、HBase,索引依赖ES和solar,可控性低,风险更高,而DGraph,不依赖任何第三方系统,它由Zero节点来控制集群,alpha用来数据存储以及处理查询,group由多个alpha构成,数据分片后存储到group,由此看出DGraph架构比JanusGraph简单。在性能对比上,写入性能上双方差不多;查询性能上简单的节点属性与一度关系二者差不多,但是最短路径,二度,三度所有顶点及其属性等复杂操作,JanusGraph性能会越来越差。在查询体验上JanusGraph使用的Gremlin查询语言更易用,而Dgraph有自己的查询语言。

最终贝壳的基础平台选择了DGraph图数据库,后续他分享了DGraph的一些原理,存储引擎方面,采用go语言写的查询层,随机读取比RocksDB快3.5倍;数据分片方面,根据谓词分片,相同谓词按顺序存储在同一个节点,减少RPC,Zero节点会定期进行数据均衡;高可用方面采用raft协议保证强一致性。当然DGraph也有不足,如不支持多重边(janusgraph允许多重边),一个集群只支持一个图(官方后期支持),大数据组件兼容不够(Spark兼容会有比较多的问题)。

 

个人总结:听完整个贝壳图谱技术的分享,首先的感想是目前业界的应用是产学结合的体现,学术界最新的一些算法也会在产业界的应用上体现,如近两年很火的GCN图卷积技术;第二个是目前的图谱技术在社区发现,溯源等方面可以很好的应用,结合网络流量方面的一些思考,个人终端设备到服务器,服务器到个人终端设备类似于贝壳的房客,房源,经纪人模式,我们可以利用“被动探测+主动探测”的形式对获取到的流量通过网络拓扑进行一定的深度发现,找出潜在的风险;第三个是半年前和李钊老师在调研分布式图数据库时,当时没有注意到贝壳基础平台使用的DGraph数据库,调研更多的是JanusGraph数据库,后续如果在图数据库上进行一些业务开发时,可以测试一下DGraph的性能以及易用性。


查看评论

暂无评论

发表评论
  • 评论内容:
      
首页
团队介绍
发展历史
组织结构
MESA大事记
新闻中心
通知
组内动态
科研成果
专利
论文
项目
获奖
软著
人才培养
MESA毕业生
MESA在读生
MESA员工
招贤纳士
走进MESA
学长分享
招聘通知
招生宣传
知识库
文章
地址:北京市朝阳区华严北里甲22号楼五层 | 邮编:100029
邮箱:nelist@iie.ac.cn
京ICP备15019404号-1