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

下载资料免扫码关注公众号下载资料免扫码关注公众号小红书图数据库在分布式并行查询上的探索 1快手关于海量模型数据处理的实践 25哔哩哔哩基于Iceberg的智能数据组织优化实践 41京东零售数据可视化平台产品实践与思考 58虎牙平台数据驱动业务实践，破局在即！ 73腾讯PCG搜广推机器学习框架GPU性能优化实践 91火山引擎DataLeap计算治理自动化解决方案实践和思考 106火花思维数据分析体系建设和实战分享 121页码：1/137小红书图数据库在分布式并行查询上的探索导读：小红书作为一个社区属性为主的产品，涵盖了各个领域的生活社区，并存储海量的社交网络关系。为了解决社交场景下的应用痛点以及分布式并行查询实现中的问题，我们自研了面向超大规模社交网络的图数据库系统REDgraph，大大提高了系统的查询效率和性能。本次分享的内容主要包括五个部分：1.背景介绍2.原架构问题分析3.分布式并行查询实现4.总结与展望5.问答环节分享嘉宾｜李凝瑞（薯名：再兴）小红书分布式数据库架构师编辑整理｜张进东内容校对｜李瑶出品社区｜DataFun背景介绍页码：2/1371.图数据库介绍关于图数据库的概念，这里不作详细阐述。而是以图表的形式，对其与另外几种NoSQL产品进行比较。图数据库本身归属于NoSQL存储，而诸如KV类型、宽表类型、文档类型、时序类型等其他NoSQL产品，各自具备独特的特性。从上图左侧的坐标轴中可以看到，从KV到宽表、文档，再到图，数据关联度和查询复杂度是越来越高的。前三者，即KV、宽表和文档，主要关注的是单个记录内部的丰富性，但并未涉及记录间的关系。而图数据库则专注于处理这些关系。图数据库主要适用于需要挖掘深链路或多维度关系的业务场景。页码：3/137接下来通过一个具体示例，再来对比一下图数据库与关系型数据库。这是社交网络中常见的一种表结构，包括四个数据表：用户表、好友关系表、点赞行为表以及笔记详情表。比如要查询Tom这个用户的好友所点赞的笔记的详细信息，那么可能需要编写一段冗长的SQL语句。在该SQL语句中，涉及到三个join操作，首先将用户表和好友关系表进行连接，从而获取Tom的所有好友信息。然后，将得到的中间结果与点赞行为表进行连接，以确定Tom的好友都点赞了哪些笔记。最后，还需要对先前生成的临时表和笔记详情表进行连接，以便最终获取这些笔记的全部内容。CPU资源、内存空间以及IO，虽然我们可以通过精心的设计，例如针对所要关联的列创建索引，以降低扫描操作的比例，通过索引匹配来实现一定程度的性能提升。然而，这样的举措所产生的成本相对较高，因为所有新的场景都需要创建索引，要考虑如何撰写SQL中的join条件，选择哪个表作为驱动表等等，这些都需要耗费大量的精力和时间。页码：4/137而如果采用图数据库，则会简单很多。首先进行图建模，创建两类顶点，分别为用户和笔记，同时创建两类边，一类是好友关系，即用户到用户的边；另一类是用户到笔记的点赞关系。当我们将这些数据存储到图数据库中时，它们在逻辑上呈现出一种网状结构，其关联关系已经非常明确。查询时，如上图中使用Gremlin'Tom')，用于定位Tom节点，两个out子句，第一个out子句用于查找Tom的好友，第二个out子句用于查找Tom的点赞笔记。当第二个out子句执行完毕后，就可以遍历所有外部的绿色顶点，即笔记节点。最后，读取它们的content属性。可以发现，与关系型数据库相比，图数据库的查询语句更加简洁、清晰易懂。此外，图数据库还有一个更为显著的优势，就是在存储时，它已经将顶点及其关系作为一等公民进行设计和存储，因此在进行邻接边访问和关系提取时，效率极高。即使数据规模不断扩大，也不会导致查询时间显著增加。2.图数据库在小红书的使用场景页码：5/137小红书是一个年轻的生活方式共享平台。在小红书，用户可以通过短视频、图片等方式，直观地记录生活的点点滴滴。在小红书内部，图数据库被广泛应用于多种场景中，下面将分别列举在线、近线以及离线场景的实例。第一个案例是社交实时推荐功能。小红书具有典型的社区特性，用户可以在其中点赞、发布贴文、关注他人、转发信息等。譬如我进入某用户主页并停留了较长时间，那么系统便会判定我对该用户有兴趣，而这个用户可能同样吸引了他人的注意。因此，系统会将该用户的其他关注者以及他们所关注的其他用户推荐给我，因为我们有共同的兴趣爱好，所以他们的关注内容我也有可能感兴趣，这便是一种简单的实时推荐机制。第二个案例是社区风控机制，小红书社区会对优质笔记或优质视频的创作者进行奖励，但这也给了一些羊毛党可乘之机，他们发布一些质量较低的帖子或笔记，将其发布在互刷群中，或者转发给亲朋好友，让他们点赞和转发，从而伪装成所谓的高质量笔记，以此来骗取平台的奖励。社区业务部门拥有一些离线算法，能够对已有的数据进行分析，识别出哪些用户和笔记属于作弊用户，在图中用红色的点标出。在近线场景中，系统会判断每个顶点在多跳关系内接触到的作弊用户的数量或比例，如果超过一定的阈值，则会将这个人标记为潜在的风险用户，即黄色的顶点，进而采取防范措施。第三个案例是离线任务的调度问题，在大数据平台中，往往存在大量的离线任务，而任务之间的依赖关系错综复杂，如何合理地调度任务，成为一个棘手的问题。图结构非常适合解决这类问题，通过拓扑排序或其他算法，可以找出最受依赖的任务，并进行反向推理。3.业务上面临的困境页码：6/137小红书在社交、风控及离线任务调度等场景中均采用了图数据库，然而在实际应用过程中遇到了诸多挑战。在此，简要介绍其中基于实时推荐场景的一个痛点。业务诉求是能即时向用户推送可能感兴趣的“好友”或“内容”，如图所示，A与F之间仅需经过三次跳跃即可到达，因此A与F构成了一种可推荐的关联关系，如果能即时完成此推荐，则能有效提升用户使用体验，提升留存率。然而，由于先前REDgraph在某些方面的能力尚未完善，业务一直只采用了一跳和两跳查询，未使用三跳，风控场景也是类似。业务对时延的具体要求为，社交推荐要求三跳的P99低于50毫秒，风控则要求三跳的P99低于200毫秒，这是目前REDgraph所面临的一大难题。那为何一至二跳可行，三跳及以上就难以实现呢？对此，我们基于图数据库与其他类型系统在工作负载的差异，做了一些难点与可行性分析。页码：7/137首先在并发方面，OLTP的并发度很高，而OLAP则相对较低。图的三跳查询，服务的仍然是在线场景，其并发度也相对较高，这块更贴近OLTP场景。其次在计算复杂度方面，OLTP场景中的查询语句较为简单，包含一到两个join操作就算是较为复杂的情况了，因此，OLTP的计算复杂度相对较低。OLAP则是专门为计算设计的，因此其计算复杂度自然较高。图的三跳查询则介于OLTP和OLAP之间，它虽不像OLAP那样需要执行大量的计算，但其访问的数据量相对于OLTP来说还是更可观的，因此属于中等复杂度。第三，数据时效性方面，OLTP对时效性的要求较高，必须基于最新的数据提供准确且实时的响应。而在OLAP场景中则没有这么高的时效要求，早期的OLAP数据库通常提供的是T+1的时效。图的三跳查询，由于我们服务的是在线场景，所以对时效性有一定的要求，但并不是非常高。使用一小时或10分钟前的状态进行推荐，也不会产生过于严重的后果。因此，我们将其定义为中等时效性。最后，查询失败代价方面。OLTP一次查询的成本较低，因此其失败的代价也低；而OLAP由于需要消耗大量的计算资源，因此其失败代价很高。图查询在这块，页码：8/137更像OLTP场景一些，但毕竟访问的数据量较大，因此同样归属到中等。总结一下：图的三跳查询具备OLTP级别的并发度，却又有比一般OLTP大得多的数据访问量和计算复杂度，所以比较难在在线场景中使用。好在其对数据时效性的要求没那么高，也能容忍一些查询失败，所以我们能尝试对其优化。正如前面提到的，在小红书，三跳查询的首要目标还是降低延迟。有些系统中会考虑牺牲一点时延来换取吞吐的大幅提升，而这在小红书业务上是不可接受的。如果吞吐上不去，还可以通过扩大集群规模来兜底，而如果时延高则直接不能使用了。原架构问题分析第二部分将详述原体系结构中所存在的问题及其优化措施。1.RedGraph整体架构REDgraph的整体结构如上图所示，其与当前较为流行的NewSQL，如TiDB页码：9/137的架构构相似。采用了存储和计算分离的架构，并且存储是shared-nothing的。三类节点分别为meta-server，元信息的管理；query-server，用户查询请求的处理；store-server，存储数据。2.RedGraph图切分方式图切分的含义为，如果我们拥有一个巨大的图，规模在百亿到千亿水平，应该如何将其存储在分布式集群之中，以及如何对其进行切分。在工业界中，主要存在两种典型的切分策略，即边切分和点切分。边切分，以顶点为中心，这种切分策略的核心思想是每个顶点会根据其ID进行哈希运算，并将其路由到特定的分片上。每个顶点上的每条边在磁盘中都会被存储两份，其中一份与起点位于同一分片，另一份则与终点位于同一分片。如上图中的例子，其中涉及到ABC三个顶点的哈希定位结果。在这个例子中，A至C的这条出边，被放置在与A同一个节点上。同样，B至C的出边跟B放到了一起，最后一个桶中保存了C以及C的入边，即由A和B指向C的两条入边。页码：10/137点切分，与边切分相对应，以边为中心，每个顶点会在集群内保存多份。这两种切分方式各有利弊。边切分的优点在于每个顶点与其邻居都保存在同一个分片中，因此当需要查询某个顶点的邻居时，其访问局部性极佳；其缺点在于容易负载不均，且由于节点分布的不均匀性，引发热点问题。点切分则恰恰相反，其优点在于负载较为均衡，但缺点在于每个顶点会被切成多个部分，分配到多个机器上，因此更容易出现同步问题。REDgraph作为一个在线的图查询系统，选择的是边切分的方案。3.优化方案1.0我们之前已经实施了一些优化，可以称之为优化方案1.0。当时主要考虑的是如何快速满足用户需求，因此我们的方案包括：首先根据常用的查询模式提供一些定制化的算法，这些算法可以跳过解析、校验、优化和执行等繁琐步骤，直接处理请求，从而实现加速。其次，我们会对每个顶点的扇出操作进行优化，即每个顶点在向外扩展时，对其扩展数量进行限制，以避免超级点的影响，降低时延。此外，我们还完善了算子的下推策略，例如filter、sample、limit等，使其尽页码：11/137可能在存储层完成，以减少网络带宽的消耗。同时，我们还允许读从节点、读写线程分离、提高垃圾回收频率等优化。然而，这些优化策略有一个共性，就是每个点都比较局部化和零散，因此其通用性较低。比如第一个优化，如果用户需要发起新的查询模式，那么此前编写的算法便无法满足其需求，需要另行编写。第二个优化，如果用户所需要的是顶点的全部结果，那此项也不再适用。第三个优化，如果查询中本身就不存在这些运算符，那么自然也无法进行下推操作。诸如此类，通用性较低，因此需要寻找一种更为通用，能够减少重复工作的优化策略。4.新方案思考如上图中，是对一个耗时接近一秒的三跳查询的profile分析。我们发现在每一跳产出的记录数量上，第一跳至第二跳扩散了200多倍，第二跳至第三跳扩散了20多倍，表现在结果上，需要计算的数据行数从66条直接跃升至45万条，产出增长速度令人惊讶。此外，我们发现三跳算子在整个查询过程中占据了较大的比重，其在查询层的耗时更是占据了整个查询的80%以上。页码：12/137那么应该如何进行优化呢？在数据库性能优化方面，有许多可行的方案，主要分为三大类：存储层的优化、查询计划的优化以及执行引擎的优化。由于耗时大头在查询层，所以我们重点关注这块。因为查询计划的优化是一个无止境的工程，用户可能会写出各种查询语句，产生各种算子，难以找到一个通用且可收敛的方案来覆盖所有情况。而执行引擎则可以有一个相对固定的优化方案，因此我们优先选择了优化执行引擎。图数据库的核心就是多跳查询执行框架，而其由于数据量大，计算量大，导致查询时间较长，因此我们借鉴了MPP数据库和其他计算引擎的思想，提出了分布式并行查询的解决方案。原有的多跳查询执行流程如上图所示。假设我们要查询933顶点的三跳邻居节点ID，即检索到蓝圈中的所有顶点。经过查询层处理后，将生成右图所示执行计划，START表示计划的起点，本身并无实际操作。GetNeighbor算子则负责实际查询顶点的邻居，例如根据933找到A和B。后续的Project、InnerJoin以及Project等操作均为对先前产生的结果进行数据结构的转换、处理及裁剪页码：13/137等操作，以确保整个计算流程的顺利进行。正是后续的这几个算子耗费的时延较算子的物理执行过程如上图所示。查询服务器（QueryServer）执行START指令后，将请求发送至存储节点（StoreServer）中的一个，该节点获取其邻居信息，并反馈至查询层。查询层接收到结果后，会对其中的数据进行去重或其他相关处理，然后再次下发，此次的目标是另外两个StoreServer。这一步骤即为获取二度邻居的信息，返回至查询层后，再对这些结果进行汇总和去重处理，如此往复。在整个流程中，我们明显观察到三个问题。首先，图中蓝色方框内的算子都是串行运行的，必须等待前一个计算完成后，才能执行下一个。对于大规模的数据，串行执行的效率显然无法与并行执行相提并论。其次，QueryServer内部存在一个同步点，即左侧标注为红色的字（等待所有响应返回要求queryServer等待所有存储节点的响应返回后，才能继续执行后续操作。若某一存储节点的数据量较大或负载过高，导致响应速度较慢，则会耗费大量时间在等待上，因此我页码：14/137们考虑取消同步等待的过程。最后，存储层的结果需要先转发回查询层进行简单处理，然后再向下发送，这无疑增加了不必要的转发成本。如果存储节点（StoreServer）能够自行转发，便可避免一次网络转发过程，从而降低开销。相应的解决策略便是三点：算子并行执行，取消同步点，以及让StoreServer的结果直接转发。基于此，我们提出了如下的改造思路。首先，查询服务器（QueryServer）将整个执行计划以及执行计划所需的初始数据传输至存储服务器（StoreServer之后StoreServer自身来驱动整个执行过程。以StoreServer1为例，当它完成首次查询后，便会根据结果ID所在的分区，将结果转发至相应的StoreServer。各个StoreServer可以独立地继续进行后续操作，从而实现整个执行动作的并行化，并且无同步点，也无需额外转发。需要说明的是，图中右侧白色方框比左侧要矮一些，这是因为数据由上方转到下方时，进行了分区下发，必然比在查询服务器接收到的总数据量要少。可以看到，在各部分独立驱动后，并未出现等待或额外转发的情况，QueryServer页码：15/137只需在最后一步收集各个StoreServer的结果并聚合去重，然后返回给客户端。如此一来，整体时间相较于原始模型得到了显著缩短。分布式并行查询实现分布式并行查询的具体实现，涉及到多个关键元素。接下来介绍其中一些细节。1.如何保证不对1-2跳产生负优化首先一个问题是，在进行改造时如何确保不会对原始的1-2跳产生负优化。在企业内部进行新的改造和优化时，必须谨慎评估所采取的措施是否会对原有方案产生负优化。我们不希望新方案还未能带来收益，反而破坏了原有的系统。因此，架构总体上与原来保持一致。在StoreServer内部插入了一层，称为执行层，该层具有网络互联功能，主要用于分布式查询的转发。QueryServer层则基本保持不变。这样，当接收到用户的执行计划后，便可根据其跳数选择不同的处理路径。若为页码：16/1371至2跳，则仍沿用原有的流程，因为原有的流程能够满足1-2跳的业务需求，而3跳及以上则采用分布式查询。2.如何与原有执行框架兼容第二个关键问题是如何维持与原有执行框架的兼容性，即在进行分布式技术改造时，不希望对原有代码进行大幅修改，而希望通过最小化的调整达到目的。这里参考了其他产品的一些思路，具体来说，就是在一些需要切换分区访问的算子（如Forward、Converge和Merge。Forward的作用显而易见，即当遇到任何运算符时，表示数据需要转发给其他节点处理，而当前节点无法继续处理。Converge运算符则是在整个执行计划的最后一步添加，用于指示最终结果应返回至最初接收用户请求的节点。在Converge后，还需添加一个Merge运算符，该节点在收到结果后需要进行聚合操作，然后才能将结果返回给客户端。如此修改后，我们只需实现这三个算子本身，无需对其他算子进行任何修改，且不会对网络层造成干扰，实现了极轻量级的改造。在执行计划修改的过程中，我们页码：17/137还进行了一些额外的优化，例如将GroupBy、OrderBy等算子也进行了下推处3.如何做热点处理第三问题是如何进行热点处理，或者说是重复ID的处理。当整个执行流程改造成由StoreServer自行驱动之后，会出现一种情况，例如边AC和边BC位于两个不同的StoreServer上，查询都是单跳的操作，可能左侧的机器查询AC操作更快，而右侧的机器查询BC操作较慢，因此导致左侧的机器首先查找到C，GetNeighborfromC，右侧的节点虽然稍显滞后，但也需要执行查询C邻居操作。若不进行任何操作，在中间节点便会对C的邻居进行两次查询，造成资源浪费。优化策略非常简单，即在每个存储节点之上添加NeighborCache。本质是这样一个Map结构，每当读请求到来时，首先在Map中查找是否存在C的邻节点，若存在则获取，否则再访问存储层，访问完毕后填充NeighborCache的页码：18/137扫码关注公众号免费下载资料条目，每个条目的生存时间都非常短暂。之所以短暂，其充分性在于左右节点发出请求的间隔肯定不会很久，不会达到数秒的级别，否则业务上也无法承受。因此，NeighborCache的每个条目也只需存活在秒级，超过则自动删除。必要性则在于Map的Key的组合模式，即Vid+edgeType这种组合模式还是非常多的，若不及时清理，内存很容易爆炸。此外，查询层从DiskStore中查询到数据并向NeighborCache回填时，也需进行内存检查，以避免OOM。4.如何做负载均衡第四个问题是怎么做负载均衡，包括两块，一个是存储的均衡，另一个是计算的均衡。首先存储的均衡在以边切分的图存储里面其实是很难的，因为它天然的就是把顶点和其邻居全部都存在了一起，这是图数据库相比其他数据库的优势，也是其要承担的代价。所以目前没有一个彻底的解决方法，只能在真的碰到此问题时扩大集群规模，让数据的哈希打散能够更加均匀一些，避免多个热点都落在同一个机器的情况。而在目前的业务场景上来看，其实负载不均衡的现象不算严重，例如免费下载资料扫码关注公众号免费下载资料页码：19/137风控的一个比较大的集群，其磁盘用量最高和最低的也不超过10%，所以问题其实并没有想象中的那么严重。另外一个优化方法是在存储层及时清理那些过期的数据，清理得快的话也可以减少一些不均衡。计算均衡的问题。存储层采用了三副本的策略，若业务能够接受弱一致的读取（实际上大多数业务均能接受我们可以在请求转发时，查看三副本中的哪个节点负载较轻，将请求转发至该节点，以尽量平衡负载。此外，正如前文所述，热点结果缓存也是一种解决方案，只要热点处理速度足够快，计算的不均衡现象便不易显现。5.如何做流程控制接下来的问题是如何进行流程控制。执行流程转变为由StoreServer自行驱动之后，仅第一个Stage有Driver参与，而后续步骤则由Worker之间相互传输和控制。那么，Driver应如何了解当前执行的阶段以及其对应的某个Stage何时可以开始执行呢？有一种解决方案便是要求每一个Worker在接收到请求免费下载资料扫码关注公众号免费下载资料页码：20/137后或下发请求后，向Driver回传一个响应，如此便可在Driver内记录所有节点的进度信息，这是可行的。然而，此设计方案较重，因为driver并不需要深入了解每个节点的具体状态，它仅需判断自身是否具备执行条件，因此在工程实现中，我们采取了更为轻便的方式，即每个Stage生成一个32位的二进制数字reqId，将其发送至ACKer确认器以传达相关信息。Acker也以32位整数形式记录该信息，Stage1同样会接收到Stage0发来的reqId，经过内部一系列处理后，它会将接收到的reqId与自身生成的3个reqId进行异或运算，并将异或结果再次发送至确认器。由于异或操作的特性，当两个数相同时，结果为0，因此，当0010数进行异或运算后，这部分将变为0。这就意味着Stage0已经执行完毕。后续的所有阶段均采用类似的方式，当确认器的结果再次变为0时，表示整个执行流程已经完成，即前面的Stage0至Stage3已经读取完毕，此时可以执行Stage4，从而实现流程驱动。另一个重要的问题便是全程链路的超时自检，例如在Stage2或Stage3的某一个节点上运行时间过长，此时不能让其余所有节点一直等待，因为客户端已经超时了。因此我们在每个算子内部的执行逻辑中都设置了一些埋点，用以检查算子的执行是否超过了用户侧的限制时间，一旦超过，便立即终止自身的执行，从而迅速地自我销毁，避免资源的无谓浪费。以上就是对一些关键设计的介绍。6.性能测试我们在改造工程完成后进行了性能测试，采用LDBC组织提供的SNB数据集，生成了一个SF100级别的社交网络图谱，规模达到3亿顶点，18亿条边。我免费下载资料扫码关注公众号免费下载资料页码：21/137们主要考察其一跳、二跳、三跳、四跳等多项查询性能。根据评估结果显示，在一跳和二跳情况下，原生查询和分布式查询性能基本相当，未出现负优化现象。从三跳起，分布式查询相较于原生查询能实现50%至60%的性能提升。例如，在Maxdegree场景下的分布式查询已将时延控制在50毫秒以内。在带有Maxdegree或Limit值的情况下，时延均在200毫秒以下。尽管数据集与实际业务数据集存在差异，但它们皆属于社交网络领域，因此仍具有一定的参考价值。免费下载资料扫码关注公众号免费下载资料页码：22/137四跳查询，无论是原始查询还是分布式查询，其时延的规模基本上都在秒至十余秒的范围内。因为四跳查询涉及的数据量实在过于庞大，已达到数十万甚至百万级别，仅依赖分布式并行查询难以满足需求，因此需要采取其他策略。然而，即便如此，我们所提出的改进方案相较于原始查询模式仍能实现50%至70%的提升，效果还是很可观的。总结与展望我们结合MPP的思想，成功地对原有REDgraph的执行流程实现了框架级别上的革新，提出了一种较为通用的图中分布式并行查询方案。在完成改良后，至少在业务层面上，原本无法执行的三跳任务现在得以实现，这无疑是一项重大突破。同时，通过实验验证，效率得到了50%的显著提升。免费下载资料扫码关注公众号免费下载资料页码：23/137随着小红书DAU的持续攀升，业务数据规模正逐步向着万亿的规模发展。在这样的大背景下，业务对多条查询的需求也将日益强烈。因此，该方案本身具有优化的潜力，具备落地的可能性，且有实际应用的场景。因此，我们将继续致力于提升REDgraph的查询能力。另外，尽管该方案主要在图数据库上实施，但其思想对于其他具有类似重查询需求的在线存储系统同样具有一定的参考价值。因此，其他产品也可借鉴此方案，设计出符合自身需求的高效执行框架。最后。我们诚挚地邀请对技术有着极致追求、志同道合的同学们加入我们的团队。在此，我们特别推荐两个渠道：一是扫描上方二维码加入微信群，共同探讨图数据库相关的技术问题；二是关注小红书的技术公众号REDtech，该公众号会不定期发布技术文章，欢迎大家关注和转发。问答环节Q：介绍中提到的LDBC-SF100那个数据集选择测试样本的规模有多大？免费下载资料扫码关注公众号免费下载资料页码：24/137另外，分布式方式能够提升性能，但分布式实施过程中可能会带来消息通信的成本开支，反而可能导致测试结果表现不佳，可否介绍一下小红书的解决方法。A：三跳基本上都是在几十万的量级。关于分布式引发的消息通信，这确实是一个问题，但在我们的场景下，目前这还不是最严重的问题。因为每一跳，特别是三跳中产生的数据量是巨大的，计算算子处理这些数据量所需的时间已经远远超过了消息通信的耗时。尤其是在多跳并存的环境中，比如一跳和二跳，其实它们作为中间结果其数据量并不大，一跳只有几十上百个，二跳可能也就几万个，但是三跳作为最后的需要参与计算的结果直接到了几十万，所以通信开销跟这个比起来，其实是非常微小的。在消息通信方面，我们也有一些解决思路，比如在发送端开一些很小的窗口（比如5毫秒）来做一些聚合，把那些目标点相同的请求进行聚合，这样可以减少一些通信的请求次数。页码：25/137扫码关注公众号免费下载资料快手关于海量模型数据处理的实践导读：本文将分享快手对海量模型数据处理的实践。（文章整理自2023年11月王靖的分享，数据具有即时性）主要介绍包括：1.模型场景介绍2.大规模模型数据处理3.大规模模型数据存储4.展望分享嘉宾｜王靖快手推荐系统架构师编辑整理｜薛敏内容校对｜李瑶出品社区｜DataFun模型场景介绍1.实时大模型免费下载资料扫码关注公众号免费下载资料页码：26/137*本文数据具有即时性，不代表实时数据。快手的模型场景主要是实时的大模型。实时主要体现在社交上。每天都有新用户上传1500万以上的视频，每天有亿级以上的直播活跃用户，并且上传数每年都在同比上涨。大主要体现在流量规模。快手现在的日活达到了3.87亿，有千亿级别的日均曝光，百亿级别的日均播放，模型量级非常大，还要保证实时。并且快手的核心价值观是平等普惠，即千万级的用户同时在线时，个性化请求时会推荐不同的内容。总结起来，数据处理的特点是既大，又要实时。2.推荐业务复杂免费下载资料扫码关注公众号免费下载资料页码：27/137一般的推荐业务架构如上图所示，在视频池里（比如有几千万的视频）会经过固定的四个阶段：（1）召回：从几千万的视频里召回几万或者几千的视频；（2）粗排：通过一个粗排漏斗，选出几千的视频3）精排：几千的视频又会通过精排，筛选top几百的视频4）重排：进入重排，给出模型打分，做模型校验；（5）返回：加上一些机制和多样化操作，最后选出几十个结果返回给用户，整个漏斗要求非常高。快手的业务类型比较多样，主要可以分成大型业务和中小型业务。大型业务的样本量级很大，像主站推荐一天的样本可能有千亿，存储能达到p的级别。迭代主要用流式迭代，即在线迭代特征和模型，速度会非常快。如果选用批式迭代的话，回溯样本要30天，需要的资源是流式迭代的几十倍，快手大场景下的流量分配又比较多，所以倾向于做在线的流式迭代实验，速度快，消耗资源量相对也少很多。中小业务，一天的样本大约在百亿级别，存储大概几十T。选择流式迭代会需要频繁上线迭代，而且流量分配也不够。这种情况下一般尽量选用批式迭代，此时免费下载资料扫码关注公众号免费下载资料页码：28/137需要很大量级的计算样本，比如要回溯至少60天以上，回溯样本能达到p级别。因为对于大模型来说，如果数据量不够，模型训练不充分，效果就会相应地下降。所以在这种小的业务场景里，还是倾向于批式迭代，回溯更多天的样本，以使模型达到一个更稳定的状态。在这种场景下面，会倾向于批次迭代实验。3.推荐模型的数据量这里是之前在快手发布的一个万亿级别模型文章里的截图，快手是个性化模型，所以参数量非常大。从图中对比来看，OpenAI的GPT3参数量是175B，但快手参数量1900B，已经到万亿级别了。主要是因为快手选用的是SIM长序列模型，需要用户长期的兴趣，然后把该序列输入到模型。快手有亿级用户，life-long兴趣需10万以上序列，再加上千亿级的样本的叠加，因此参数量非常大，能达到1.9万亿。虽然这1.9万亿参数跟OpenAI的GPT3模型的参数类型不一样，计算量也不太一样。但从参数量级上来看，快手推荐是非常大4.语言模型的演进免费下载资料扫码关注公众号免费下载资料页码：29/137推荐模型跟语言模型紧密相关，一般新模型都会在语言模型上去做迭代，成功之后就会引入推荐模型，比如DN、RNN、Transformer。上图是亚马逊3月份时发布的一个图，主要介绍了语言模型的一些进展。可以看到，17年之前主要是RNN模型，RNN模型是按次序去顺序遍历数据后训练，该模型对并行算力要求并不高，但模型收敛比较复杂，因为可能会存在梯度消失的问题。2017年出现Transformer之后，语言模型突破了原有的限制，可以做并发迭代，所以其算力大规模增长。图中的树分为三个部分1）红线部分是encoder-only技术，最早是Bert模型2）绿线是encoder-decoder类型，Google主要选择这一类型3）蓝线主要是openAPI里ChatGPT选用的类型，这一类模型发展得最好，因为它足够简单，只需要考虑decoder，运算量小，而且模型效果也会很好。大规模模型数据处理免费下载资料扫码关注公众号免费下载资料页码：30/1371.背景-实效性快手对数据时效性要求很高，用户看到视频后会反馈到快手的log收集系统，该用户的行为会实时地拼接推荐日志（推荐日志就是推荐服务落下来的特征特征流加上行为流成为样本流进入后面的特征处理，然后进入模型训练。模型训练完成后实时更新到在线预估，在线预估会根据模型的更新推荐出最符合用户需求的一些视频。该链路要求延迟必须要在一秒内，需要将用户行为尽快反馈到模型里，所以对于大数据处理的时效性要求是非常高的。2.大数据量处理免费下载资料扫码关注公众号免费下载资料页码：31/137快手有千万级用户在线，不考虑行为多样性的情况下，QPS至少是千万级的，如果区分到行为的多样性，这个组合数量就更爆炸了，高峰期大概每秒需要处理30T左右的状态。业界方案主要是采用Flink流式框架，但如果直接用Flink引入statejoin，在并发几千的情况下会造成大量的慢节点。因为30T状态如果1000并发的话，需要存30G的状态，如果1万并发也得存3G。3G在1万并发下的慢节点的概率会非常大。在这种情况下如果出现慢节点，需要几个小时恢复，这对于推荐系统肯定是不能忍受的。所以快手选择了一个折中方案，把状态下沉至高性能存储上，然后采用无状态hashjoin的方式来做一个实时join的状态，只要用户的行为和特征都到齐，就立即触发样本的下发，这样就可以保证行为能够及时地反馈到模型。虽然特征和行为来的顺序不一样，但通过外部的状态，再加上Flink流式框架并行的操作，就能实现大规模高性能的join。3.复杂特征计算免费下载资料扫码关注公众号免费下载资料页码：32/137在上述处理完成之后，是特征计算场景，主要有两种计算，标量计算和向量计算。标量计算类似于特征处理，比如要把某些值求和、求平均。在向量计算里，会对一批样本同一列进行一个同样的操作，放在GPU通过cuda计算。这样，通过使用GPU和CPU协同的方式实现高性能计算，一些标量操作在CPU上计算，内存访问也会在CPU上进行，然后传输到GPU上去做高性能的GPU计为了保证算法迭代的灵活性，采用了DSL抽象。因为SQL不能完全描述所有的特征处理场景。比如有一些在时间窗口的操作，如果通过SQL去做需要写一些自定义的UDF，这样很不利于迭代。所以我们的DSL是用Python描述的，用户可以通过Python直接调用下层的高效执行算子。第一步先写计算层，使用C++实现一些高效的operator，包括cuda和CPU相关的计算也都是通过C++库去做的。在runtime下面采用Flink的分布式框架加上GNI的方式去调用C++的这些算子，以达到高性能、高吞吐的处理。4.推荐场景特点免费下载资料扫码关注公众号免费下载资料页码：33/137推荐场景下有两个特点，一个是批流一体，另一个是潮汐。批式调研和在线实验这两种场景会需要有批流一体，因为在批场景里调研特征或调研模型结构完成之后，需要到在线去做上线，因此需要有一个批流一体的统一描述语言加上统一的执行引擎。用户在批式上调研，会使用DSL、Hadoop和Spark把所有的数据计算出来，做模型迭代。模型迭代成功之后做特征上线，上线到流式通用特征处理框架上，或是上线到流式特征框架特化的一个处理框架上。这里之所以会分出两个节点，主要是因为有一些特征是所有模型公用的，所以可能在通用的框架下面，这样只需要计算一次。而在特化的算子下面则是一些模型所特有的特征，因此分开处理。但这两个计算引擎和语言描述其实是一样的。同样地，这些通用处理的数据需要落盘到批场景下。批场景下有很多是基于base的特征去迭代，会加入它自己的性价特征，所以在批次场景下面计算的也是Delta。上线完之后就会到在线服务，这里会有一个高性能的存储和计算库去承接，这一点在后文中还会讲到。在流式场景下，注重的是高吞吐、低延迟和高可用。在批免费下载资料扫码关注公众号免费下载资料页码：34/137场景下，主要关注高吞吐、高可靠。另外一个特点就是请求潮汐。上图是请求潮汐的示意图（并不是快手的真实流量）。从图中可以看到，有早高峰和晚高峰两个高峰。在高峰期需要给足在线的算力，在低峰期则要把冗余的算力利用起来。在这种情况下，快手的大数据处理框架以及在线所有的模块需要针对潮汐的特点，去做云原生架构的一些改造，比如快速恢复、自动伸缩、快速伸缩。快速伸缩主要是因为在自动伸缩的时候并不能保证是高效的，比如一次自动伸缩需要耗一小时或者几个小时之久，那么在线的请求在这几个小时之间会有比较大的损失。另外，还需要把在线服务的资源池和大数据处理的资源池统一起来，这样所有资源在低峰期时可以把冗余算力给批式场景、大模型预训练场景或者大模型批量预估的场景，使资源得以利用。快手现在所有的架构都在向云原生架构演进。大规模模型数据存储免费下载资料扫码关注公众号免费下载资料页码：35/1371.存储特点大规模数据存储的第一个特点就是超低延迟，因为存储节点存储的都是状态，一些计算节点需要很多的状态信息才能去计算，所以存储节点大部分时间都是在叶子节点，而且推荐的在线实验有上千个模块，每一个模块只能给十毫秒以内或者最多几十毫秒的超时时间，因此要保证所有存储节点都是低延迟、高吞吐并且高可用的。推荐实验和推荐服务base之间有一个互相切换的过程。一般并行的实验数量非常多，实验完成之后会去切换成一个在线的base，这样它承担的流量就会非常大。比如在训练服务base里会有召回的base、粗排的base和精排的base，各个base都需要去承担千万级的QPS，而且要提供超高的可靠性。所以在线存储部分，大量选用的是全内存架构。免费下载资料扫码关注公众号免费下载资料页码：36/137其次，快手有超大存储的需求。前文中提到，快手大模型有1.9万亿的参数量，如果换成普通八维的float，需要的存储也要有64T，而且还有一个全用户的行为序列，有180T左右的状态信息。如果要采用全内存的存储，将会需要2000多台机器。而且所有的状态需要在30分钟内恢复，因为推荐系统如果超过30分钟不恢复，会对线上产生非常大的影响，用户体验会很差。针对上述需求，我们的方案主要有以下几个：（1）特征score的准入：特征score可以理解为特征重要性，即将一些重要性比较低，对预估效果影响也微乎其微的特征不放在在线存储上；（2）LRU和LFU的淘汰：因为是在线的模型，需要保证可靠性，即内存需要维持在一个稳定范围内，不能一直增长。因此我们将最远更新的优先淘汰，最先访问的优先保留；（3）NVM新硬件技术：全内存架构的资源消耗也是一个非常大的问题。我们引入了NVM硬件技术。NVM是一个持久化存储，是Intel新发布的一个硬件，它会在DR和SSD之间，有接近于内存的速度，同时有接近于SSD的存免费下载资料扫码关注公众号免费下载资料页码：37/137储空间，既能兼顾存储也能兼顾性能。2.存储方案-NVMTable存储方案是NVMTable，分成异构存储的三层：物理层提供底层存储的API，包括NVM存储和memory存储；中间memorypool封装统一的管理功能，把NVM和memory的模块都管理起来；上层业务通过memorypool的一个API去调用下层的NVM和memory，提供统一的查询逻辑。在数据结构布局方面，memorypool采用的是block接口抽象。将NVM和memory分成若干不同的、可通过全局统一地址来访问的block，这样就可以实现zerocopy的访问自由化。对于一些频繁访问的key，会放到mem-key上。不常访问的key会放在到NVM上。一些索引的key会频繁访问，但查找到key之后，其value在最后要返回给上游的时候才会用到，并且量级较大，所以将value放到持久化的存储。Key查询比较多，同时也比较小，所以放在内存，这样就实现了内存和NVM的零拷贝技术。这里的哈希表采用了业界领先的无锁技术，以减少临界区的竞争，完成高效存储。免费下载资料扫码关注公众号免费下载资料页码：38/137从NVMTable的一个场景测试数据可以看出，其网络的极限吞吐与JIRA是相当的。跨网络访问一般是网络达到极限，所以NVM带宽可以完全覆盖网络带宽，瓶颈主要在网络上，这样就能保证NVM既有成本上的收益，也有大存储和高吞吐的收益。另一方面，恢复时间也下降了120倍。最开始恢复T的数据需要两个小时，采用NVM之后只需要2分钟。3.存储方案-强一致性存储方面，还有强一致性的需求，主要是因为在推荐场景里也有一些广告和电商免费下载资料扫码关注公众号免费下载资料页码：39/137的推荐，需要存储的副本特别多。因为当一些新的短视频或者新物料进来时，下游所有模块会有一个并发分发，需要保证这些视频在10秒内到达所有的推荐服务，且所有推荐服务里的状态需要保证一致。否则对于模型的效果影响很大。我们采用了Raft协议加BT的模式。Raft协议主要负责选组和同步数据，BT的模式主要是改造BT同步的模式，比如在几千上万台机器规模下的同步，如果同时用主从同步的话，主节点的出口带宽可能会是从节点的千倍以上，带宽就会成为瓶颈，下发的状态就会非常少，高吞吐和数据同步会受到影响。我们的方案是分布式的平衡树分发，构造一个平衡二叉树，把所有主从节点进行组织，每个节点只管有限个从节点，从而保证从主节点同步到叶子节点所需要的带宽不变，但是单节点的带宽限制为小于等于2，这样在全局下既能做到一次性，也能做到高效地同步，10秒内即可将所有视频状态分发到每个节点。展望免费下载资料扫码关注公众号免费下载资料页码：40/137推荐模型的发展跟语言模型是相关的，从DNN模型到Wide&Transformer，再到SIM长序列及生成式模型，模型增长了很多倍。除了模型的增长，算力增长也会随视频的增长和用户的增长，呈现出指数级的上升。从统计数据来看，最近两年推荐模型的算力增长接近10倍，我们的方案主要是优化工程架构和新的硬件技术。生成式模型会带来计算量的爆炸，因为它是一个token-based的推荐，每次推荐需要之前所有的token作为context，在这种情况下生成的效果才会最好。如果没有token-based，那么与算力不会呈指数级增长。因此，推荐的压力，将主要来自状态存储的大规模提升，因为目前的推荐模型主要是pointwise的推荐，对于长序列推荐模型算力也是有限的。如果全部采用深层次模型推荐，其状态存储还将再增长10倍，挑战会非常大。因此我们需要通过一些新硬件，比如CXL、NVM以及新推出的Grace架构，再加上工程上的优化，比如状态做差分、传输计算等等，来应对未来的挑战。页码：41/137扫码关注公众号免费下载资料哔哩哔哩基于Iceberg的智能数据组织优化实践导读：随着数据存储规模的增长和查询环境的复杂化，数仓面临着查询性能与稳定性的挑战。为了实现查询加速，哔哩哔哩在Iceberg基础上进行了功能拓展，包括多维排序、多种索引和预计算等。然而，现有优化手段对用户的技术门槛较高，需要手动配置或组织培训提供指导，限制了优化技术的推广使用。因此，采用了智能优化技术，通过自动分析用户历史查询数据，为数据存储和查询配置合理的优化手段，提升了数仓的整体查询效率。今天的分享将主要包括三个主要内容。首先，我们将介绍智能优化项目的背景，然后我们会详细介绍智能优化的整体实践方案。最后，我们将展示目前智能优化所取得的成果，以及未来的规划。本次分享主要内容包括：1.智能优化背景2.智能优化实践方案3.智能优化成果及规划分享嘉宾｜杨金德哔哩哔哩高级开发工程师编辑整理｜张阳内容校对｜李瑶出品社区｜DataFun页码：42/137扫码关注公众号免费下载资料智能优化背景首先来介绍一下智能优化的背景。1.湖仓一体架构与现状我们的湖仓一体平台使用Iceberg作为数据的存储格式，数据存储于HDFS，入湖主要有3条链路：离线场景使用Spark写入数据，实时场景则使用Flink或我们提供的JavaSDK进行写入。交互式分析采用Trino查询引擎，并利用Alluxio对数据进行缓存加速。此外，平台也有一独立的服务Magnus负责Iceberg表的数据优化，将在本次介绍中重点提及。对于写入Iceberg的数据，一部分会继续写入下游的Iceberg表，而在某些对查询性能和稳定性要求较高的场景，需要毫秒级响应时间，这时数据会被导出到ClickHouse或ES。目前，平台包含大约2000张Iceberg表，总数据量达到40PB，100TB。Trino的日查询量超过400万次，P99的响应时间大约为3秒。2.OLAP场景查询加速免费下载资料扫码关注公众号免费下载资料页码：43/137目前的业务场景主要包括BI报表、指标服务、A/BTest人群筛选以及日志处理。针对这些场景，我们在Iceberg基础上进行了功能拓展，以满足用户对查询加速的需求。除了Iceberg原有的数据组织分布能力外，还增加了支持多维排序的功能，比如Z-order和HilbertCurve，并且提供了多种索引类型，包括通用的BloomFilter、Bitmap以及针对日志场景的特殊索引。此外，我们还开发了预计算功能，主要用于加速聚合计算的查询。3.用户使用门槛高免费下载资料扫码关注公众号免费下载资料页码：44/137我们支持的这些查询加速手段能够为查询带来数倍到数十倍的性能提升。然而，实际落地时会遇到一个问题，即这些优化手段对用户的使用门槛较高，要求用户对业务的查询模式有清晰的认知，并了解相关的基础知识才能进行合理配置。因此，通常需要我们手动为用户配置，或者通过组织培训提供指导。这限制了查询优化技术的推广使用。我们希望通过自动化、智能化的方式解决用户使用门槛的问题。这也是智能优化的目标，我们希望它能够自动分析用户的历史查询，为Iceberg表配置合理的优化手段，从而实现后续用户查询的加速。智能优化实践方案接下来将介绍智能优化的整体实践方案。1.整体方案设计整个智能优化流程涉及两个计算引擎，一个是交互式分析的Trino引擎，另一页码：45/137个是执行数据优化的Spark引擎。还包括两个服务，一个是查询采集服务，另一个是负责分析推荐和数据优化调度的Magnus服务。用户提交查询后，查询Iceberg表。Magnus的分析推荐模块定期从查询明细表获取查询信息，分析查询模式，生成推荐的数据组织配置，然后应用到Iceberg表中。这时推荐的配置并未实际生效，需要数据优化模块在Iceberg表数据写入后异步提交优化任务，由Spark完成数据优化。接下来会详细介绍查询采集、分析推荐以及数据优化三个模块的一些细节。2.查询信息采集查询采集模块需要采集四类查询信息。首先是基本信息，包括时间、状态、查询SQL、以及用户身份等。接着是反映查询性能的关键指标，如查询耗时和扫描数据量，这些指标直接影响交互式分析的用户体验和查询优化效果。第三个部分是查询模式，包括查询的过滤条件、Orderby条件以及聚合模型。这些信息理论上可以通过直接分析查询SQL得到，但我们选择将提取查询模式的工作放到免费下载资料扫码关注公众号免费下载资料页码：46/137Trino中实现，通过查询信息方式暴露出来，从而降低开发成本。最后是数据过滤的指标，我们在Trino统计了排序等优化手段在查询中的过滤效果，这些指标可以帮助我们跟踪和分析Iceberg表的优化效果，对推荐策略进行调整。3.分析推荐分析推荐模块是根据查询以及Iceberg表的统计信息进行推荐的。我们的推荐策略是由一系列基于优化原理和实践经验的规则构成的。因此，在实现上相对比较简单，并且对于不是特别复杂的查询模式，也会有较好的推荐效果。分析推荐任务是定期执行的，比如每周执行一次针对每张Iceberg表的分析推荐任务。当用户的查询场景发生变化时，推荐配置也可以相应调整，以达到最佳优化效果。不同优化手段的分析对象和推荐依据是有区别的，下面将简要介绍各个优化手段的分析和推荐逻辑。免费下载资料扫码关注公众号免费下载资料页码：47/137进行数据分析时，一个重要的优化策略是通过调整Iceberg表的分布来提高数据在特定字段上的聚集性。在查询过程中，引擎可以利用Iceberg表文件级别的最大值和最小值统计信息来过滤文件，实现查询加速。举个例子，假设一张表有四个文件，第一个文件在字段a上的最小值是0，最大值是10。如果查询条件是a等于11，由于11不在0到10的范围内，该文件就无需被读取。相反，如果查询条件是a等于2，而没有进行数据分布优化，就需要读取所有文件，因为每个文件在字段a上的最小值和最大值范围都包括2。对表按照字段a进行线性分布优化后，可以看到整个表在字段a上的聚集性得到改善。这样一来，只需读取第二个文件即可完成查询，其他文件则被直接过滤掉。在进行数据分布优化时，主要考虑常用的过滤字段，根据查询条件统计出每个字段出现在过滤条件中的查询占比，推荐优化策略更倾向于选择占比较高的字段。同时，也会考虑字段基数和分区文件数等因素。字段基数越高，分布效果就会更好。举个例子，如果将字段a的基数改为2，即只有0和2两个取值各占一半，即使按照字段a进行分布优化，也至少需要读取两个文件。同理，如免费下载资料扫码关注公众号免费下载资料页码：48/137果分区文件数过少，分布优化效果也会变差。在分布优化推荐中，有几种常见情况可以作为例子。首先，如果有90%的查询是针对a字段进行过滤，而只有10%的查询是针对b字段进行过滤，这种情况下推荐按照a字段进行线性分布。其次，如果有50%的查询是针对a字段进行过滤，而另外50%的查询同时针对a和b字段进行过滤，那么建议按照a和b字段的顺序进行线性分布，可以较好地过滤两类查询。第三种情况是50%的查询对a字段过滤，另外50%的查询对b字段过滤。在这种情况下，如果按照a或b字段线性分布，则对另一类查询都不会有很好的过滤效果。这时候可以考虑采用HilbertCurve这种多维分布方式，它能够在多个字段上实现较好的聚集效果，提升不同字段过滤查询的性能表现。免费下载资料扫码关注公众号免费下载资料页码：49/137索引是用于实现查询加速的一种重要技术，它和分布优化一样通过文件级别的数据过滤加速查询。索引提供了更为详尽的记录，因此其过滤性能更佳，能够处理一些分布优化效果不好的场景。例如当查询条件改为“ain(3,6,9)”时，尽管做了分布优化，仍需读取三个文件，实际上只需读取其中一个文件，这时就需使用索引来实现优化。此外，当参与分布的字段过多时，分布的效果可能较差，因此选择少量字段用于分布，而对其他字段进行索引构建，也是常见的优化策略。不同类型的索引适用于不同的场景，需要综合考虑字段的过滤查询占比和不同类型的过滤条件，如等值过滤和范围过滤。BloomFilter适用于等值过滤，而针对范围过滤的查询，需使用bitmap索引。此外，字段基数也是重要的推荐依据，对于基数较高的字段，使用BloomFilter索引效果较好，而构建bitmap索引可能会因为索引过大，导致性能回退。免费下载资料扫码关注公众号免费下载资料页码：50/137文件内排序也是查询优化的常见手段，可以加速TopN查询。TopN查询在计算引擎中执行时一般会分为局部排序和全局排序两个阶段。通过事先对Iceberg表文件内部进行排序，就可以节省局部排序的计算成本，同时减少扫描的数据量。Orderby条件在查询中的占比来生成推荐。此外，需要注意同一种排序定义是可以响应多种Orderby条件的查询的。举个例子，如果按照字段a、b进行排序，既可以响应按a、b排序的查询，也可以响应按照a排序的查询。这个因素在推荐的时候也是需要考虑的。免费下载资料扫码关注公众号免费下载资料页码：51/137我们实现的预计算是一种针对聚合计算的优化手段。该手段通过提前按照指定的聚合模型对每个数据文件生成预聚合文件，在查询时直接读取这些预聚合文件，从而减少需要读取的数据量。预计算的分析过程相对复杂，首先需要定义聚合模型，然后计算每个模型在查询中的占比。聚合模型包括维度字段和聚合函数，对于涉及多表关联的场景，还需要考虑关联信息。另外，预计算的聚合效果也是重要的考量因素。如果一个文件经过聚合后仍然保留了大部分数据，那么预计算的意义就不大，同时还会浪费存储空间。这个指标通常无法从表的统计信息中获得，而需要通过额外的计算方法，比如通过Trino的查询来获取聚合效果。免费下载资料扫码关注公众号免费下载资料页码：52/137推荐完成后，服务会将推荐结果配置到Iceberg表中。我们还做了推荐结果的持久化和前端展示，这样方便我们和用户查看。在生成的生产表的推荐记录中，展示了推荐的排序和分布信息。这个展示内容还包括推荐结果和当前配置的对比。例如，在Distribution这个部分，黑色字段表示保持不变，绿色字段表示新增，红色字段表示移除。通过这样的展示和对比，用户可以清晰地了解推荐结果和当前配置的变化。4.数据优化免费下载资料扫码关注公众号免费下载资料页码：53/137推荐结果配置到Iceberg表之后，并不会立即生效，需要通过数据优化模块，异步提交Spark任务完成数据优化。数据优化的流程如上图，当任务向Iceberg表写入数据时，会发送一个CommitEvent。通过CommitEvent，调度器可以获取这次写入操作修改了哪些分区，写入了多少文件以及每个文件的数据量等信息。基于这些信息，以及Iceberg表的元数据信息，调度器会调度优化任务到Spark完成优化。对于异步的数据优化，延迟是重要的考量指标。以小时分区的实时表为例，如果在分区所有数据写入完成再进行优化，可能导致超过一小时的延迟。用户查询过去15分钟至半小时内的数据时，性能就会比较差。为降低实时优化延迟，我们采用了基于快照的分级优化调度策略。Iceberg表的快照是表在某个时间点的副本，每次提交时会生成一个快照，其中包含已存在的数据文件、本次提交的增量数据文件以及删除的数据文件。我们的策略是只优化指定快照中新增的数据，当某分区的小文件数量累积较多时，将触发minor优化以合并小文件。当累积未优化文件数据量达到阈值（如2GB），将触发major优化，包括排序、分布以页码：54/137及索引创建等操作。这种策略将整个分区的优化拆分成多阶段优化，用户在查询时能享受到阶段性优化带来的加速效果。为了降低优化延迟，我们还做了其他优化。一是任务合并，将同一张表的多个优化任务打包提交，减少Spark任务调度开销；二是通过优先级调度防止历史数据回刷对实时数据优化造成影响。此外，我们还针对优化任务进行了一些资源管理控制，如限制总体计算资源和单表的并发控制等。目前在高并发提交场景下，Iceberg表存在性能问题，因此需要对每个表同时运行的任务数量进行限制。页码：55/137我们还有一个前端页面，用来展示Iceberg表的分区级别的统计信息。除了数据量、文件数等基本信息，页面还展示最后写入时间以及各种优化手段的实际优化比例，比如排序和分布等，以便进行问题排查。智能优化成果及规划最后介绍一下智能优化现阶段的成果以及未来的规划。1.成果免费下载资料扫码关注公众号免费下载资料页码：56/137我们目前针对一些没有进行任何优化配置的Iceberg表，开放了智能优化功能。截至目前为止，已经对30多张表进行了优化。在这30多张表经过优化后的30天总体扫描数据量减少了28%。其中有超过60%的表扫描量减少了30%以上。目前项目的推荐策略还相对比较保守。在实际的生产环境中，有许多表已经由用户配置了一些优化手段，但由于配置不够合理，所以无法达到良好的加速效果。对这部分表开启智能优化功能，查询加速的收益会更高。2.未来规划免费下载资料扫码关注公众号免费下载资料页码：57/137在接下来的工作中，我们将持续改进并推广智能优化功能。其中一项改进是增加推荐准确性。比如分布和索引的推荐，影响推荐准确率的关键因素之一是过滤效果的判断，因此我们会考虑使用更详细的统计信息，如实际数据分布，来辅助推荐决策。随着参考统计信息的增加，决策模型的参数将变得更加复杂，我们也将考虑利用机器学习或人工智能算法来进一步提高推荐准确性。另一个改进方向是支持更多的查询场景。目前索引和预计算推荐在日志场景和多表关联预计算推荐方面仍有不足，我们将逐步完善这些场景。最终，我们还将把智能优化推广应用到更多的生产表中，以优化用户配置并提供更好的查询体验。页码：58/137扫码关注公众号免费下载资料京东零售数据可视化平台产品实践与思考导读：本次分享题目为京东零售数据可视化平台产品实践与思考。主要包括以下四个部分：1.平台产品能力介绍2.业务赋能案例分享3.平台建设挑战与展望4.Q&A分享嘉宾｜梁臣京东数据产品架构师编辑整理｜梁英琪内容校对｜李瑶出品社区｜DataFun平台产品能力介绍1.产品矩阵免费下载资料扫码关注公众号免费下载资料页码：59/137数据可视化产品是一种利用数据分析和可视化技术，帮助企业从大量数据中提取具有价值的信息和洞察的工具，主要作用有以下几点：n可视化呈现与报告。将数据以图表、仪表盘、报告等形式进行可视化呈现，让用户更加直观地理解数据，快速识别关键指标。n数据分析与探索。通过对数据进行多维度切片和钻取来进行分析。用户也可以通过交互式界面对数据进行探索，发现数据中的模式、趋势和关联性。n实时监控和预警。通过实时监控及时洞悉关键业务指标和数据变化，通过报警和通知来提醒用户异常情况的发生。n业务的监测和评估。通过该产品可以监测评估业绩，并跟踪关键业务指标的变化趋势。n数据驱动决策。帮助决策层、管理层做出更明智的决策，降低决策风险，优化业务的运营。数据可视化产品可以帮助企业更好地利用数据进行决策和业务洞察，加强数据驱动的决策文化，促进业务的增长和创新。免费下载资料扫码关注公众号免费下载资料页码：60/137京东数据可视化的产品矩阵主要有：智能BI平台，数据大屏平台，低代码平台和交互分析平台。数据可视化平台的产品有多种典型应用场景。比如将来自企业内部的业务数据通过数据抽取、清理加工，进行数仓的分层存储，通过数据集市提供给用户进行分析处理。或通过消息管道的方式，利用Flink等引擎进行实时的数据计算，再通过OLAP数据库进行数据查询和使用，等等。根据不同的业务场景，有不同的产品使用链路。下面主要介绍如下三个京东内部的可视化产品平台：nEasyBI定位于拖拽式的可视化报表搭建平台，面向京东域内提供报表搭建能n低代码平台定位于低代码的可视化编排系统，提供多种场景化的数据组件，进行代码配置。nJDV大屏定位于自助式的可视化大屏搭建工具，比如618、双11的可视化大屏都是通过JDV大屏来搭建和呈现的。页码：61/137接下来将详细介绍这几款产品的功能。2.EasyBIEasyBI是京东推出的一款自助式数据报表与可视化分析工具，面对不同的业务场景，以数据驱动价值，帮助用户快速地分析和洞察数据。整体架构分为四层：数据连接层，支持MySQL、Presto、ClickHouse、ElasticSearch、API等数据的接入，还支持本地上传以及数据填报等，满足不同场景的数据接入与集成。第二层为数据建模，可进行轻量级数据建模，包括表与表之间的关联，表条件的过滤，表权限的配置和设置，实现了类似数据视图的功能。第三层是可视化配置，包括大量自研的可视化组件和配置能力，目前支持insight等不同画布模式，通过不同的图层设计、可视化组件编排，以及相应的筛选器、组件参数配置等形成整体的可视化看板。最上面是数据看板应用的发布与管理，支持邮件订阅、看板智能预警，支持配置不同主题，加入第三方组件，也可以无缝嵌入其它业务平台，支持报表、门户等免费下载资料扫码关注公众号免费下载资料页码：62/137不同功能。这款产品目前赋能于京东各个集团及海内外业务，在报表开发者数量、日常使用者数量、嵌入式支持系统的数量、已开发报表数量和外嵌报表数量等方面均取得了较为领先的数据规模。EasyBI的核心功能包括，支持多源数据的接入，可以用于搭建企业级数据门户，支持智能分析，允许用户深度追踪和挖掘数据，包含内置算法，可提供数据诊断分析、时间序列分析等等，帮助用户做智能数据分析和决策。场景模板功能，是基于京东零售在数据分析领域内多年的积累和沉淀，将方法论模板化，形成开箱即用的场景化模板。此外还有丰富的数据可视化组件，交互分析能力，权限管控能力和数据抽取能力等核心功能。在数据看板消费者端，我们做了很多工作，比如性能查询的提升，通过数据查询全链路的监控分析、缓存性能的优化提升、SQL语法的识别分析、SQL全表扫描的查询优化、性能诊断工具等能力，为用户查询体验保驾护航。免费下载资料扫码关注公众号免费下载资料页码：63/137EasyBI产品的核心优势包括：支持零代码拖拽，可以灵活嵌入到各种不同的业务系统中，做到无缝嵌入，还有数据找人的智能预警功能、引擎侧的优化，以及安全管控体系的优化等等。3.低代码平台低代码平台的产生背景有三个方面，首先在业务上，京东有一套成熟的数据BP陪跑模式，会深入到业务一线战场做业务的数据分析，从而对场景化分析提出了较高要求；第二是在研发资源上，希望在有限的人力下，通过技术能力提升，改免费下载资料扫码关注公众号免费下载