2025年AI+for+Data：智能数据处理与分析实战报告

目录 小红书图数据库在分布式并行查询上的探索.....................................................................1快手关于海量模型数据处理的实践.....................................................................................25哔哩哔哩基于Iceberg的智能数据组织优化实践......................................................41京东零售数据可视化平台产品实践与思考.......................................................................58虎牙平台数据驱动业务实践，破局在即！.......................................................................73腾讯PCG搜广推机器学习框架GPU性能优化实践.................................................91火山引擎DataLeap计算治理自动化解决方案实践和思考.............................106火花思维数据分析体系建设和实战分享.........................................................................121 小红书图数据库在分布式并行查询上的探索 导读：小红书作为一个社区属性为主的产品，涵盖了各个领域的生活社区，并存储海量的社交网络关系。为了解决社交场景下的应用痛点以及分布式并行查询实现中的问题，我们自研了面向超大规模社交网络的图数据库系统REDgraph，大大提高了系统的查询效率和性能。 本次分享的内容主要包括五个部分： 1.背景介绍2.原架构问题分析3.分布式并行查询实现4.总结与展望5.问答环节 01 1.图数据库介绍 关于图数据库的概念，这里不作详细阐述。而是以图表的形式，对其与另外几种NoSQL产品进行比较。图数据库本身归属于NoSQL存储，而诸如KV类型、宽表类型、文档类型、时序类型等其他NoSQL产品，各自具备独特的特性。从上图左侧的坐标轴中可以看到，从KV到宽表、文档，再到图，数据关联度和查询复杂度是越来越高的。前三者，即KV、宽表和文档，主要关注的是单个记录内部的丰富性，但并未涉及记录间的关系。而图数据库则专注于处理这些关系。图数据库主要适用于需要挖掘深链路或多维度关系的业务场景。 接下来通过一个具体示例，再来对比一下图数据库与关系型数据库。这是社交网络中常见的一种表结构，包括四个数据表：用户表、好友关系表、点赞行为表以及笔记详情表。比如要查询Tom这个用户的好友所点赞的笔记的详细信息，那么可能需要编写一段冗长的SQL语句。在该SQL语句中，涉及到三个join操作，首先将用户表和好友关系表进行连接，从而获取Tom的所有好友信息。然后，将得到的中间结果与点赞行为表进行连接，以确定Tom的好友都点赞了哪些笔记。最后，还需要对先前生成的临时表和笔记详情表进行连接，以便最终获取这些笔记的全部内容。 关系型数据库中的join操作通常复杂度较高，其执行过程中需消耗大量的CPU资源、内存空间以及IO，虽然我们可以通过精心的设计，例如针对所要关联的列创建索引，以降低扫描操作的比例，通过索引匹配来实现一定程度的性能提升。然而，这样的举措所产生的成本相对较高，因为所有新的场景都需要创建索引，要考虑如何撰写SQL中的join条件，选择哪个表作为驱动表等等，这些都需要耗费大量的精力和时间。 而如果采用图数据库，则会简单很多。首先进行图建模，创建两类顶点，分别为用户和笔记，同时创建两类边，一类是好友关系，即用户到用户的边；另一类是用户到笔记的点赞关系。当我们将这些数据存储到图数据库中时，它们在逻辑上呈现出一种网状结构，其关联关系已经非常明确。查询时，如上图中使用Gremlin语句，仅需四行代码即可获取到所需的信息。其中第一行g.V().has('name','Tom')，用于定位Tom节点，两个out子句，第一个out子句用于查找Tom的好友，第二个out子句用于查找Tom的点赞笔记。当第二个out子句执行完毕后，就可以遍历所有外部的绿色顶点，即笔记节点。最后，读取它们的content属性。可以发现，与关系型数据库相比，图数据库的查询语句更加简洁、清晰易懂。 此外，图数据库还有一个更为显著的优势，就是在存储时，它已经将顶点及其关系作为一等公民进行设计和存储，因此在进行邻接边访问和关系提取时，效率极高。即使数据规模不断扩大，也不会导致查询时间显著增加。 小红书是一个年轻的生活方式共享平台。在小红书，用户可以通过短视频、图片等方式，直观地记录生活的点点滴滴。在小红书内部，图数据库被广泛应用于多种场景中，下面将分别列举在线、近线以及离线场景的实例。 第一个案例是社交实时推荐功能。小红书具有典型的社区特性，用户可以在其中点赞、发布贴文、关注他人、转发信息等。譬如我进入某用户主页并停留了较长时间，那么系统便会判定我对该用户有兴趣，而这个用户可能同样吸引了他人的注意。因此，系统会将该用户的其他关注者以及他们所关注的其他用户推荐给我，因为我们有共同的兴趣爱好，所以他们的关注内容我也有可能感兴趣，这便是一种简单的实时推荐机制。 第二个案例是社区风控机制，小红书社区会对优质笔记或优质视频的创作者进行奖励，但这也给了一些羊毛党可乘之机，他们发布一些质量较低的帖子或笔记，将其发布在互刷群中，或者转发给亲朋好友，让他们点赞和转发，从而伪装成所谓的高质量笔记，以此来骗取平台的奖励。社区业务部门拥有一些离线算法，能够对已有的数据进行分析，识别出哪些用户和笔记属于作弊用户，在图中用红色的点标出。在近线场景中，系统会判断每个顶点在多跳关系内接触到的作弊用户的数量或比例，如果超过一定的阈值，则会将这个人标记为潜在的风险用户，即黄色的顶点，进而采取防范措施。 第三个案例是离线任务的调度问题，在大数据平台中，往往存在大量的离线任务，而任务之间的依赖关系错综复杂，如何合理地调度任务，成为一个棘手的问题。图结构非常适合解决这类问题，通过拓扑排序或其他算法，可以找出最受依赖的任务，并进行反向推理。 3.业务上面临的困境 小红书在社交、风控及离线任务调度等场景中均采用了图数据库，然而在实际应用过程中遇到了诸多挑战。在此，简要介绍其中基于实时推荐场景的一个痛点。 业务诉求是能即时向用户推送可能感兴趣的“好友”或“内容”，如图所示，A与F之间仅需经过三次跳跃即可到达，因此A与F构成了一种可推荐的关联关系，如果能即时完成此推荐，则能有效提升用户使用体验，提升留存率。然而，由于先前REDgraph在某些方面的能力尚未完善，业务一直只采用了一跳和两跳查询，未使用三跳，风控场景也是类似。 业务对时延的具体要求为，社交推荐要求三跳的P99低于50毫秒，风控则要求三跳的P99低于200毫秒，这是目前REDgraph所面临的一大难题。 那为何一至二跳可行，三跳及以上就难以实现呢？对此，我们基于图数据库与其他类型系统在工作负载的差异，做了一些难点与可行性分析。 首先在并发方面，OLTP的并发度很高，而OLAP则相对较低。图的三跳查询，服务的仍然是在线场景，其并发度也相对较高，这块更贴近OLTP场景。 其次在计算复杂度方面，OLTP场景中的查询语句较为简单，包含一到两个join操作就算是较为复杂的情况了，因此，OLTP的计算复杂度相对较低。OLAP则是专门为计算设计的，因此其计算复杂度自然较高。图的三跳查询则介于OLTP和OLAP之间，它虽不像OLAP那样需要执行大量的计算，但其访问的数据量相对于OLTP来说还是更可观的，因此属于中等复杂度。 第三，数据时效性方面，OLTP对时效性的要求较高，必须基于最新的数据提供准确且实时的响应。而在OLAP场景中则没有这么高的时效要求，早期的OLAP数据库通常提供的是T+1的时效。图的三跳查询，由于我们服务的是在线场景，所以对时效性有一定的要求，但并不是非常高。使用一小时或10分钟前的状态进行推荐，也不会产生过于严重的后果。因此，我们将其定义为中等时效性。最后，查询失败代价方面。OLTP一次查询的成本较低，因此其失败的代价也低；而OLAP由于需要消耗大量的计算资源，因此其失败代价很高。图查询在这块， 更像OLTP场景一些，但毕竟访问的数据量较大，因此同样归属到中等。 总结一下：图的三跳查询具备OLTP级别的并发度，却又有比一般OLTP大得多的数据访问量和计算复杂度，所以比较难在在线场景中使用。好在其对数据时效性的要求没那么高，也能容忍一些查询失败，所以我们能尝试对其优化。正如前面提到的，在小红书，三跳查询的首要目标还是降低延迟。有些系统中会考虑牺牲一点时延来换取吞吐的大幅提升，而这在小红书业务上是不可接受的。如果吞吐上不去，还可以通过扩大集群规模来兜底，而如果时延高则直接不能使用了。 02 原架构问题分析 第二部分将详述原体系结构中所存在的问题及其优化措施。 1.RedGraph整体架构 REDgraph的整体结构如上图所示，其与当前较为流行的NewSQL，如TiDB 的架构构相似。采用了存储和计算分离的架构，并且存储是shared-nothing的。三类节点分别为meta-server，元信息的管理；query-server，用户查询请求的处理；store-server，存储数据。 2.RedGraph图切分方式 图切分的含义为，如果我们拥有一个巨大的图，规模在百亿到千亿水平，应该如何将其存储在分布式集群之中，以及如何对其进行切分。在工业界中，主要存在两种典型的切分策略，即边切分和点切分。 边切分，以顶点为中心，这种切分策略的核心思想是每个顶点会根据其ID进行哈希运算，并将其路由到特定的分片上。每个顶点上的每条边在磁盘中都会被存储两份，其中一份与起点位于同一分片，另一份则与终点位于同一分片。如上图中的例子，其中涉及到ABC三个顶点的哈希定位结果。在这个例子中，A至C的这条出边，被放置在与A同一个节点上。同样，B至C的出边跟B放到了一起，最后一个桶中保存了C以及C的入边，即由A和B指向C的两条入边。 点切分，与边切分相对应，以边为中心，每个顶点会在集群内保存多份。 这两种切分方式各有利弊。边切分的优点在于每个顶点与其邻居都保存在同一个分片中，因此当需要查询某个顶点的邻居时，其访问局部性极佳；其缺点在于容易负载不均，且由于节点分布的不均匀性，引发热点问题。点切分则恰恰相反，其优点在于负载较为均衡，但缺点在于每个顶点会被切成多个部分，分配到多个机器上，因此更容易出现同步问题。 REDgraph作为一个在线的图查询系统，选择的是边切分的方案。 3.优化方案1.0 我们之前已经实施了一些优化，可以称之为优化方案1.0。当时主要考虑的是如何快速满足用户需求，因此我们的方案包括：首先根据常用的查询模式提供一些定制化的算法，这些算法可以跳过解析、校验、优化和执行等繁琐步骤，直接处理请求，从而实现加速。其次，我们会对每个顶点的扇出操作进行优化，即每个顶点在向外扩展时，对其扩展数量进行限制，以避免超级点的影响，降低时延。此外，我们还完善了算子的下推策略，例如filter、sample、limit等，使其尽 可能在存储层完成，以减少网络带宽的消耗。同时，我们还允许读从节点、读写线程分离、提高垃圾回收频率等优化。 然而，这些优化策略有一个共性，就是每个点都比较局部化和零散，因此其通用性较低。比如第一个优化，如果用户需要发起新的查询模式，那么此前编写的算法便无法满足其需求，需要另行编写。第二个优化，如果用户所需要的是顶点的全部结果，那此项也不再适用。