服装网站模板,游戏开发模拟器,wordpress访客切换主题,选择佛山网站设计简介#xff1a; 优酷视频内容数据天然呈现巨大的网络结构#xff0c;各类数据实体连接形成了数十亿顶点和百亿条边的数据量#xff0c;面对巨大的数据量#xff0c;传统关系型数据库往往难以处理和管理#xff0c;图数据结构更加贴合优酷的业务场景#xff0c;图组织使用…简介 优酷视频内容数据天然呈现巨大的网络结构各类数据实体连接形成了数十亿顶点和百亿条边的数据量面对巨大的数据量传统关系型数据库往往难以处理和管理图数据结构更加贴合优酷的业务场景图组织使用包括顶点和边及丰富属性图来展现随着年轻化互动数据和内容数据结合在更新场景形成单类型顶点达到日更新上亿的消息量。本文将分享阿里文娱开发专家遨翔、玄甫在视频内容实时更新上的实践从图谱化的全新视角重新组织内容数据的更新诠释图谱化在业务更新场景的应用。一 背景搜索推荐系统作为在线服务为满足在线查询性能要求需要将预查询的数据构建为索引数据推送到异构储存介质中提供在线查询。这个阶段主要通过 Offline/Nearline 把实时实体、离线预处理、算法加工数据进行处理更新。这里包含了算法对这些数据离线和在线的处理不同业务域之间最终数据合并(召回、排序、相关性等)。在平台能力方面采用传统的数仓模式即围绕有共性资源、有共性能力方面建设形成分层策略将面向业务上层的数据独立出来而这种模式在实现业务敏捷迭代、知识化、服务化特征方面已不能很好满足需求。知识图谱作为对数据进行结构化组织与体系化管理的核心技术实际面向业务侧应用过程中能很好的满足知识化、业务化、服务化方面的诉求基于内容图谱体系的特征平台建设以内容(视频、节目、用户、人物、元素等)为中心构建一个实时知识融合数据更新平台。二 设计概要基于搜索推荐系统数据处理链路一般包括以下几个步骤从内容生产端(媒资、互动、内容智能、包罗、粮仓、琳琅等)接收 dump 出来的全量数据和业务侧增量数据然后业务侧拿到这些数据按业务域进行一层一层加工最终通过 build 构建索引进入到引擎端。不同于其它业务场景在优酷场景中我们接收的内容生产端并不是源头生产端中间掺杂了很多半加工的异源异构数据数据的一致性(逻辑一致性、功能一致性)是摆在用户侧实际性面临问题特别实时和全量产出的数据需要保持结构一致同时搜索引擎的字段结构保持一致。我们从数据结构化组织与业务体系化管理方面进行索引平台更新设计。1 数据结构化组织设计文娱大脑面向应用侧的中间层将知识图谱引入中间层实现了面向业务领域的数据组织方式。将知识图谱融入在中间层数据模型这一层用包含实体、关系、事件、标签、指标的知识图谱统一视图来定义面向领域的数据模型。将视频领域知识图谱作为中间层数据组织的基础实现面向业务领域数据组织方式的转变。2 业务体系化管理将算法的逻辑以组件化的模式进行封装实现了业务方只需要维护一套逻辑实时和全量一套代码采用统一 UDF 来实现。利用 Blink 的流批一体化的架构实现全增量架构模式如在数据清洗订正逻辑时进行全量(实时引擎中做到了消息不丢的机制保证不需要每天实现全量)让全量数据走一遍逻辑。三 关键模块1 特征库特征库包含两层第一层是全增量一级特征计算对接不同的数据源(包括实时和离线)在特征域计算中不存在离线全量对于冷数据或修正数据采用存量的全集重新走一次流处理。数据组织储存在顶点和边关系表中。实时更新过程中为了减少对上游反查导致的性能压力不同实体属性变更直接走内部图查询统一封装 DataAPI 对这些数据进行操作不同类型顶点采用独立 blinkjob 进行计算。离线数据组织方面由于搜索引擎在线服务的机器并不持久化数据。当新的在线机器加入集群时需要从某个地方拉取全量索引文件进行数据装载我们组装一个和索引模型一样全量文件。全量文件只是某一个时间戳的快照全量文件时间戳越早需要追的实时消息就越多故障的恢复速度就越慢需要有一个机制尽量及时产出最新全量文件减少实时增量消息带来的性能压力。二级特征计算面向算法的接入包含了搜索的相关性、排序、召回这层直接面向业务域它直接消费一级特征库中的数据业务主要逻辑集中到这层进行计算此时实时离线逻辑主要通过组件库来完成。2 组件库不同业务线算法按各自业务从同一份数据中获取自身需要的数据进行处理加工无形中就导致代码的重复。组件库建立主要开放适配接口让相同功能代码得以复用减少重复开发。组件库将业务逻辑抽象成简单的基于 UDF 的算术表达式来组织简单、简洁并且更易维护特征使用方只需关注特征粒度不需要关注整体。3 TraceDebug 模块每一个消息有唯一签名(uuid)源头数据会在各个计算流程中流转处理过程中为了便于业务更好追踪处理流程问题将不同系统数据按 uuid 和实体 id 进行聚合通过 TraceDebug 服务能较好理解业务处理过程信息和系统处理信息。四 技术细节整体计算框架采用新一代的实时计算引擎 Blink主要优势在于流批一体化业务模块通过 job 切分不同的计算模块可以随意组合消费位点自动保存消息不丢失进程 failover 自动恢复机制分布式的计算可消除单点消费源和写入性能瓶颈问题。储存引擎采用 Lindorm 进行实体数据储存主要利用 Lindorm 二级索引来储存 KV 和 KKV 数据结构用于构建知识图谱的底层数据。1 知识图谱储存和组织采用标签属性图(Labeled Property GraphLPG)建模Lindorm 作为主储存实体表(视频、节目、人物等)作为顶点表实体间关系利用 lindorm 的二级索引能力作为边表。数据访问方面实现数据驱动层提供给外部使用接口 API开发人员通过本地 API 来操纵 Lindorm。接口层一接收到调用请求就会调用数据处理层来完成具体的数据处理屏蔽了 java 代码属性和 Lindorm 列值的转换以及结果查询的取值映射使用注解用于配置和原始映射解决 java 对象直接序列化到 Lindorm 的行列储存问题。2 计算和更新策略采用 Blink 计算平台实现特征计算和索引更新由于采用了全增量架构在全量更新过程减少上游服务反查的压力采用列更新策略。在不同实体属性或边表属性(边表属性为了减少图查询过程中顶点查询的压力开销)更新采用级联更新策略即属性更新后生成新的消息推送到总线链路端不同实体或关系订阅消息后按需进行自身属性更新。更新一个业务核心诉求就是一致性其本质就是不丢消息和保序我们采用 MetaQ 作为主消息管道本身具备不丢消息更多是在外部服务、储存、处理链路层面上失败情况。对于一个实体数据或关系数据(通常一个 job)采用原子操作内部有一定的重试机制如访问外部服务自身会有重试机制这种重试为了不影响整体的链路性能我们称作 Fast try一般应对网络抖动如超时等情况如果失败会保留一定现场将数据写入重试队列中抛出异常由最外层捕获异常丢弃本次更新接受下一个消息失败的消息会在 5 分钟、10 分钟20 分钟去重试 3 次如果依然失败则发出通知人为干预。3 统一 UDF采用核心解决 UDF 的业务逻辑在各个系统之间的可移植通过技术手段保证只维护一套业务逻辑各个计算平台(离线/实时)可复用解决 UDF 业务逻辑的一致性和可移植性问题。五 总结 展望基于内容图谱结构化特征与索引更新平台在结构化方面打破传统的数仓建模方式以知识化、业务化、服务化为视角进行数据平台化建设来沉淀内容、行为、关系图谱目前在优酷搜索、票票、大麦等场景开始进行应用。随着图神经网络、表征学习方面不断的发展进一步在图存储和图计算在面向 OLTP 和 OLAP 进行着重深度优化通过深度算法策略来补充实时融合和实时推理方面的建设。在索引更新平台建设方面随着多方业务的接入、搜推融合带来的挑战索引更新朝向全增量化的进行推进在业务自助方面进一步探索抽象 DSL提升业务整体接入效率。来源阿里云开发者社区