数据血缘图谱升级方案设计与实现_ 字节跳动技术团队的博客-CSDN博客
数据血缘图谱升级方案设计与实现
字节跳动技术团队
于 2022-08-19 12:02:30 发布
1807
收藏
文章标签：
大数据
人工智能
数据分析
java
数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ByteDanceTech/article/details/126434202
版权
动手点关注 干货不迷路 👆
数据地图平台是字节跳动内部的大数据检索平台，每天近万的字节员工在此查找所需数据。数据地图通过提供便捷的找数，理解数服务，大大节省了内部数据的沟通和建设成本。
数据血缘图谱介绍
字节的数据可分为端数据和业务数据，这些记录往往需要通过加工处理才能产生业务价值。数据加工处理的流程一般是读取原始数据，进行数据清洗，再经过多种计算和存储，最终汇入指标、报表和数据服务系统。数据血缘描述了数据的来源和去向，以及数据在多个处理过程中的转换，是组织内使数据发挥价值的重要基础能力。
数据地图平台在 2021 年接入了全链路核心元数据，包括但不限于：Hive、Clickhouse、Kafka、BI 报表、BI 数据集、画像、埋点、MySQL、Abase。这些数据全部要通过数据血缘连接起来，进而可以进行影响分析、内部审计、SLA 保障、归因分析、理解和查找数据、自动化推荐等操作。
随着内部数据不断膨胀，简单的数据血缘图谱已经无法满足万级表血缘的关系展示。一些突出的问题包括看不清单个表的直接上下游，看不清数据链路，整体情况等等。因此需要重构一种更清晰、灵活、便利的方式。下图简单展示了优化后的使用效果。
在新版血缘图谱中，我们可以直接清晰的看到每个表的多层上下游依赖关系，甚至可以直接看到一些特殊场景下用户关注的表属性，通过点击节点高亮查看数据链路，更可以看清每层的统计信息。在下文中我们将详细拆解优化的全过程。
需求发现
要做出一个能满足用户需求的图产品，首先是要清楚用户想从图中获取什么信息，从而有针对性的将这些信息展示出来。从血缘图谱的背景本身可以推断出用户希望在图谱中查看表之间的关系，查看关系链路，而更多的使用场景待发掘。因此我们对内部重度用户进行了访谈，整理得出了以下不同用户角色使用数据血缘图谱的用户场景。
结合访谈结果和用户的日常反馈，数据血缘图谱的场景按目前用户的使用频率从大到小排序依次为：
场景用户关注场景描述影响分析下游当处于血缘上游的研发同学修改任务前，通过查看自己的下游，通知对应资产或任务的负责人，进行相应的修改，否则会造成严重的生产事故。找数理解数上游在找数据时，通过查看一份数据资产的血缘，来更多的了解它的“前世今生”，可以更好的判定当前资产是不是自己需要的，或者是不是值得信赖的。就像了解一个人，可以从他周围的朋友中得到很多信息一样，是对这个人“生平”很好的补充。链路梳理链路事先挑选已知的核心任务，通过血缘关系，自动化的梳理出其所在的核心链路。多用于内审和数据治理。归因分析上游当某一个指标或字段数据/产出时间等出问题时，通过查看血缘上游的任务或资产，排查出造成问题的根因。使用分析下游一个表的下游表越多，使用越频繁，可以认为价值越大。
抽象出几个主要需求即为：
表血缘关系查看：能从图中清楚的浏览用户关注的表的上下游血缘关系，最好还能便捷的查看一些场景相关的表属性。表血缘链路查看：能清晰的查看到某个上游/下游表到用户关注表的链路情况。按关键指标分组查看：例如当表数据发生变更时，分组查看所有下游表的负责人以便通知变更。筛选关键信息查看：例如用户找数据指标的时候，仅看相关的报表更高效。
问题分析
其实上述需求旧版血缘图谱都有一定程度上的满足，我们需要去找出旧版血缘图谱提供的功能为什么不满足用户需求，有哪些问题需要在新版中注意避免。
概览：在数据量较小的情况下可用，在数据量大的时候完全不可用。看不清每层有多少个节点，层级关系是怎么样的，且链路查看困难。
节点较少，比较清晰
大量节点，查看困难
旧版血缘图谱中功能细节粗糙：
用户无法直观的区分节点：旧版节点上显示了表类型、库名、表名。因此表名只能显示几个字符，不具备辨识度。无法知晓表到表之间的任务：旧版血缘图谱仅在侧边栏列出了与当前表相关的任务有哪些并未列出加工逻辑的对应关系，归因分析困难。分组结构不清晰：旧版是在原图中框出节点来展示分组的。一方面是空间利用率更低，另一方面是看节点时难定位到所属分组，看分组时则无法看清包含的节点。筛选功能不直观：符合筛选条件的节点高亮展示，而被筛掉的表仍在图中，无法有效提升用户浏览效率。
方案设计
用户在使用过程中看重的是查看关系的效率和属性的完备度，因此在设计优化方案时会尽量从这两点出发去考虑。
首先是表数据查看的效率问题。看不清表名，无法区分相同前缀的表是用户痛点之一。首先我们统计了现有表的平均字符数是 47 位，于是调宽了节点让用户能更直观的区分表名。用数据地图平台中通用的类型图表来代替色块图例，让数据类型一目了然。
其次对于数据量大时看不清数据关系的问题，我们需要一个更紧凑清晰的数据呈现方式。通过需求分析和用户调研，我们了解到用户关心的是节点所在层级和节点之间的联系。对于同一层级节点的先后顺序，次层级节点之间的关系不是很看重。
说到紧凑的布局方式，自然而然我们就想到了列表。如果能用一个列表来承载层级血缘的节点，用连线来连接不同层级的节点，那么久可以表达节点之间的血缘关系了。当节点较多超出一屏时可以拖动此列滚动条来查看更多节点，连线随之刷新位置。当层级不满一屏时整体居中展示，层级过多超过一屏时可以左右滑动查看。这样在保留层级结构信息的同时最大程度的利用了可视区域，展示出了尽可能多的数据。
新版血缘图谱支持了点击任意节点则高亮该节点到主节点的链路功能。配合列滚动和连线刷新，不管数据量多大总能看清一整条数据链路。
我们还在每列列表顶部增加了层级信息和节点统计，让用户能同时查看每个节点细节和节点的整体分布。最终实现效果如下图：
当用户想去找数，理解数或做归因分析时，不仅要了解一个表的上游依赖，更需要理解表的加工逻辑。因此我们在节点的连线上新增了任务信息。当用户 hover 到连线上后，连线会加粗高亮并弹出任务信息。我们还附上了大数据开发平台的对应任务链接，点击链接即可跳转到新页面查看任务逻辑详情。
在设计分组功能时，采用了每列独立分组的方式。一般认为用户会关注有对应分组数据的节点，因此总将有分组的数据放在上面，无分组数据的置底，这样排序能提升用户的浏览效率。
旧版血缘图谱的筛选功能是在前端处理的，由于一些性能限制导致筛选后只能显示部分数据，用户无法得知符合条件的节点是否已经全部展示。新版血缘图谱针对这个用户痛点，将前端筛选改为了服务端筛选，尽量展示全符合要求的数据。每个层级的顶栏对应更新为筛选后的统计信息。同时更新连线，如果筛选后节点之间是有关联的，也会展示关联关系和高亮关系链路。
不同职能的用户在不同场景下使用血缘图谱时关注的节点属性并不相同，如果血缘图谱可以直接在图上显示用户当前想关注的表属性就能帮助用户更高效的解决问题。于是我们在血缘图谱上设计了属性展示功能，用户可以勾选自己感兴趣的属性直接显示到图中。比如下图中展示了每个节点表热度和生命周期两个属性。
技术实现
技术选型
在编码实现之前，我们需要进行技术选型。好的选型往往能让编码事半功倍。在做技术选型时，我们会主要考虑实现复杂度、研发周期、可扩展性三个角度。分析整个血缘图谱的需求：
Canvas 实现滚动条，节点文字标签混排很复杂，要达到 HTML 的美观度需要大量调试，后续迭代要新增属性标签，进行流式布局会很头痛。开放组件给别的产品复用也有很大的定制成本。而这些问题使用 React 框架渲染就可以轻松解决。如果用 DOM 实现不但很难实现箭头，在连线高亮时也很难灵活处理层叠关系。在大数据量下连线很多，还容易出现性能问题。而这是 Canvas 的优势。
于是我们结合两者之长，选用了 React + Canvas 的混合模式来实现血缘图谱。Canvas 居于底部，仅负责画连线。React 在上层负责渲染节点响应 hover 等交互。DOM 层叠关系如下：
整个血缘图谱的初始化流程如下：
数据预处理：服务端给到点边结构的数据。由于两个节点之间可能存在多个任务，对应会有多条连线记录。而血缘图谱中相同两个节点之间仅一条连线，对应多个任务。先做连线的合并处理。计算节点层级：服务端会给到点边结构的数据，根据主节点的连线关系向来源和去向两个方向做广度遍历来确定每个节点的层级。数据分组：按分组条件对每列数据进行分组计算。节点布局：根据层级和分组情况布局节点，相对应的每个节点有 { x, y, width, height 属性以确定每个节点的定位。初始化画布：画布用于绘制连线，响应连线的交互。采用内部自研的图形渲染引擎实现。渲染节点：根据节点的位置和分组情况用 React 渲染出每一列节点 DOM。渲染画布：根据前景的列和节点位置调整画布，绘制连线。在渲染连线时分两个图层：默认状态连线在底层；高亮链路和高亮连线状态下的连线在上层。这样做的好处是高亮的连线永远在默认状态的上方，不用特殊处理图形的层叠关系。
实现细节
用这种混合模式的一个挑战就是 Canvas 和 DOM 的刷新率和同步率。在血缘图谱中滚动横向滚动条和每一列的纵向滚动条时 Canvas 要进行及时的刷新以保证连线和节点的相对位置一定。
当图谱横向滚动时，每条连线的斜率不变，只是端点左右平移了。我们可以通过更新绘图矩阵来加速这种情况下的更新，不需要去重计算每条连线的位置。具体做法是监听容器的滚动事件，根据容器的 scrollLeft 属性来更新绘图矩阵后重绘。当图谱纵向滚动时，与当前滚动的列中节点相连的连线斜率和端点都有变化，而与滚动列不直接相连的连线无需更新。我们仅重计算并更新与当前列连接的线条位置。
另一个挑战是 DOM 节点在大数据量下的性能问题。通常情况下我们认为 Canvas 在大数据量渲染有更好的性能，而万级的 DOM 节点就会让用户在使用中感受到卡顿了。这时候我们想到了按需渲染。 用户在图谱可视区域中一屏能看到的节点数量是有限的，高度为 1120 的容器中，一列仅存在至多 30 个节点。如果仅渲染可见的节点，则能保证使用 过程的流畅。具体做法是在节点布局时增加以下步骤：
根据视口的位置（主要是图容器的横向滚动距离 scrollLeft ）和每一列的滚动距离（主要是每一列容器的纵向滚动距离 scrollTop ）计算目前的可视范围。计算节点坐标时判断是否在可视范围的上半屏和下半屏内，如果在此范围内则打标。多显示一屏的节点是希望在用户上下滚动浏览节点时不会出现空白区域闪一下等体验不佳的问题。计算出每一列的真实长度。
在 React 渲染时更新每列容器的长度，将节点根据坐标绝对定位到正确的位    置上。看起来就跟全量渲染的效果一致，渲染效率大幅提升。
然而问题并不止于此。在进行大数据量的纵向滚动时，会发现帧率很低，交  互还是不流畅。分析得知是由于列表滚动时会在短时间内进行大量线条重计算和渲染。于是还要在 Canvas 绘制上进行优化。
我们从上图可以看到在单层节点很多的情况下，主节点与不可见节点的连线可见，但是没有任何价值，只是加重了用户对当前节点连线查看的负担。因此我们对线条也进行了渲染优化，仅当一条连线两端的节点都在可见范围中时才渲染连线，在连线的 Tooltip 上增加了来源去向的展示辅助查看。至此我们做到了在复杂情况下的流畅展示血缘数据。
总结
以上就是数据血缘图谱的整个优化过程。在这个过程中，我总结起来就是在了解用户诉求的前提下，克制地表达关系图中的信息，在合适的场景下突出核心的内容。做图分析产品时不需要拘泥于某种形式，而是真正的从用户需求出发，为用户服务。
关于我们
火山引擎大数据研发治理套件 DataLeap
一站式数据中台套件，帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，帮助数据团队有效的降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。
欢迎加入字节跳动数据平台官方群，进行数据技术交流、获取更多内容干货
点击阅读原文了解产品详情
字节跳动技术团队
关注
关注
点赞
收藏
评论
数据血缘图谱升级方案设计与实现
动手点关注干货不迷路????数据地图平台是字节跳动内部的大数据检索平台，每天近万的字节员工在此查找所需数据。数据地图通过提供便捷的找数，理解数服务，大大节省了内部数据的沟通和建设成本。数据血缘图谱介绍字节的数据可分为端数据和业务数据，这些记录往往需要通过加工处理才能产生业务价值。数据加工处理的流程一般是读取原始数据，进行数据清洗，再经过多种计算和存储，最终汇入指标、报表和数据服务系统。数据血缘描述了...
复制链接
扫一扫
参与评论
您还未登录，请先
登录
后发表或查看评论
博客
字节跳动一站式数据治理思考及实践
12-14
202
动手点关注干货不迷路导读：今天的分享主要分四个部分：机遇与挑战、数据治理思路、技术架构演进以及未来展望1. 机遇与挑战数据治理工作有很多挑战，最主要的一点是落地比较困难。首先，治理工作中与业务有一定的矛盾。第二，治理涉及的组织和管理难度大。第三，规范“人”的动作难度大，治理过程中，需要依靠人来推进和执行，人员能力参差不起，组织文化、目标也存在不对齐的情况。第四，缺乏适配性强的产品工具。因为治理工作...
博客
火山引擎 RTC 助力抖音百万并发“云侃球”
12-07
623
动手点关注干货不迷路1. 背景及技术挑战从电视看直播到手机电脑看直播，直播技术的发展让观众可以随时、随地观看自己喜欢的比赛，并且在看比赛时通过发送表情、发文字进行互动。但表情、文字承载的信息量较小、沟通效率低，我们无法像线下一起看比赛那样和好友边看边聊、一起为精彩的比赛呐喊，观赛体验大打折扣。为了让观众获得更好的观赛体验，抖音在 2022 世界杯比赛直播中推出了“边看边聊”的玩法：每个观众都可以邀...
博客
字节跳动数据中台的 Data Catalog 系统搜索实践
11-21
777
动手点关注干货不迷路1. 背景Data Catalog 能够帮助大公司更好地梳理和管理自己的资产，是 Data-drvien 公司的重要平台。一个通用的 Data Catalog 平台通常包含元数据管理，搜索，血缘，标签，术语等功能。其中，搜索是 Data Catalog 的入口功能，承担着让用户“找到数”的主要能力。在字节跳动数据中台的 Data Catalog 系统中，每天有 70% 以上的用...
博客
火山引擎 RTC 视频性能降级策略解析
11-16
445
动手点关注干货不迷路1. 背景随着 RTC 使用场景的不断复杂化，新特性不断增多，同时用户对清晰度提升的诉求也越来越强烈，这些都对客户端机器性能提出了越来越高的要求 (越来越高的分辨率，越来越复杂的编码器等)。但机器性能差异千差万别，同时用户的操作也不可预知，高级特性的使用和机器性能的矛盾客观存在。当用户机器负载过高时，我们需要适当降级视频特性来减轻系统复杂性，确保重要功能正常使用，提升用户体验...
博客
火山引擎工具技术分享：用 AI 完成数据挖掘，零门槛完成 SQL 撰写
11-14
413
动手点关注干货不迷路在使用 BI 工具的时候，经常遇到的问题是：“不会 SQL 怎么生产加工数据、不会算法可不可以做挖掘分析？”而专业算法团队在做数据挖掘时，数据分析及可视化也会呈现相对割裂的现象。流程化完成算法建模和数据分析工作，也是一个提效的好办法。同时，对于专业数仓团队来说，相同主题的数据内容面临“重复建设，使用和管理时相对分散”的问题——究竟有没有办法在一个任务里同时生产，同主题不同内容的...
博客
大规模分布式链路分析计算在字节跳动的实践
11-07
1025
动手点关注干货不迷路1. 综述微服务架构的快速发展使得分布式链路追踪系统成为观测体系中越来越重要的组件。字节跳动的分布式链路追踪系统经历了数年的发展后，已覆盖了字节的绝大部分在线业务，完成了对数万微服务和数百万微服务实例的在线链路追踪。在经典的指标观测分析和单请求链路追踪的基础上，如何从浩瀚如海的分布式链路数据中进一步挖掘出更高层次的信息，为业务的架构优化、服务治理、成本优化等场景提供更高效的数据...
博客
深度解析字节跳动开源数据集成引擎 BitSail
11-01
976
动手点关注干货不迷路1. 导读BitSail 是字节跳动开源数据集成引擎，支持多种异构数据源间的数据同步，并提供离线、实时、全量、增量场景下全域数据集成解决方案，目前支撑了字节内部和火山引擎多个客户的数据集成需求。经过字节跳动各大业务线海量数据的考验，在性能、稳定性上得到较好验证。10 月 26 日，字节跳动宣布 BitSail 项目正式在 GitHub 开源，为更多的企业和开发者带来便利，降低数...
博客
一文了解 DataLeap 中的 Notebook
10-27
1856
动手点关注干货不迷路一、概述Notebook 是一种支持 REPL 模式的开发环境。所谓「REPL」，即「读取-求值-输出」循环：输入一段代码，立刻得到相应的结果，并继续等待下一次输入。它通常使得探索性的开发和调试更加便捷。在 Notebook 环境，你可以交互式地在其中编写你的代码、运行代码、查看输出、可视化数据并查看结果，使用起来非常灵活。在数据开发领域，Notebook 广泛应用于数据清理和...
博客
火山引擎 RTC 全球化架构设计
10-24
1072
动手点关注干货不迷路1. 为什么 RTC 要做全球化RTC（Real Time Communication）是音视频基础设施，它已经融入了大家生活的方方面面：工作中，我们组织视频会议，即使团队成员身处异国，也能保证项目推进；休息时，我们打开抖音，看主播直播连麦；来一局游戏时，我们打开小队语音，大杀四方；学习时，我们相聚线上互动课堂，知识传播不再受距离的桎梏。RTC 拉近了大家的距离，丰富了大家的生...
博客
Spark AQE SkewedJoin 在字节跳动的实践和优化
10-12
1768
动手点关注干货不迷路1. 概述本文将首先介绍 Spark AQE SkewedJoin 的基本原理以及字节跳动在使用 AQE SkewedJoin 的实践中遇到的一些问题；其次介绍针对遇到的问题所做的相关优化和功能增强，以及相关优化在字节跳动的收益；此外，我们还将分享 SkewedJoin 的使用经验。2. 背景首先对 Spark AQE SkewedJoin 做一个简单的介绍。Spark Ada...
博客
深入理解 Android Studio Sync 流程
10-10
1958
动手点关注干货不迷路1. 初识 Sync我们一般会把 Sync 理解为 Android Studio 的准备阶段，包括解析工程配置信息、下载远程依赖到本地、更新代码索引等准备工作，当修改 gradle build 文件后，需要重新 Sync 将 Gradle 构建配置信息同步到 IDE，进而使 IDE 的功能及时应用新的构建配置，这些功能包括项目的 Gradle Task 列表展示、依赖信息展示等...
博客
火山引擎 RTC 自研音频编码器 NICO 实践之路
09-30
1683
动手点关注干货不迷路1. 前言随着互联网技术的不断发展，越来越多的人开始尝试使用或者依赖实时音视频产品解决团队沟通与协作问题。在通话过程中，我们时常会遇到因为网络波动（如拥塞、丢包、延时和抖动等）而导致的音频卡顿、掉字或者杂音等问题，影响工作效率。为解决此类音频弱网问题，业界一般采用前向纠错（Forward Error Correction，FEC）或者重传等网络策略优化方法，但这些方法存在冗余率...
博客
prompt 综述
09-28
1365
动手点关注干货不迷路1. 概述1.1 基本概念用一句话概括模板学习，即将原本的输入文本填入一个带有输入和输出槽位的模板，然后利用预训练语言模型预测整个句子，最终可以利用这个完整的句子导出最终需要的答案。模板学习最吸引人的关键在于其通过已有的预训练模型，定义合适的模板就能完成 few-shot 或者 zero-shot 任务，这样可以使得语言模型可以在预训练阶段利用尽可能多的信息进行训练，后续也能最...
博客
初探自然语言预训练技术演进之路
09-27
879
动手点关注干货不迷路人工智能的三个层次：运算职能：数据的存储和计算能力，机器远胜于人类。感知职能：视觉、听觉等能力，机器在语音识别、图像识别领域已经比肩人类。认知智能：自然语言处理、常识建模与推理等任务，机器还有很长的路要走。自然语言处理属于认知智能范畴，由于自然语言具有抽象性、组合性、歧义性、知识性、演化性等特点，为机器处理带来了极大的挑战，有人将自然语言处理称为人工智能皇冠上的明珠。近些年来，...
博客
Redis 持久化策略浅析
09-26
1298
动手点关注干货不迷路Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的内存高速缓存数据存储服务。使用 ANSI C 语言编写，支持网络、可基于内存亦可持久化的日志型、Key-Value 数据存储，并提供多种语言的 API。▶ 简介Redis 是内存数据库，数据都是存储在内存中，为了避免进程退出导致数据的永久丢失，需要定期将 Redis 中的数据以某种形式...
博客
Babel 插件：30分钟从入门到实战
09-16
1515
动手点关注 干货不迷路 ????Babel 是一个 source to source（源码到源码）的 JavaScript 编译器，简单来说，你为 Babel 提供一些 JavaScript 代码，Babel 可以更改这些代码，然后返回给你新生成的代码。Babel 主要用于将 ECMAScript 2015+ 代码转换为能够向后兼容的 JavaScript 版本。Babel 使用插件系统进行代码转换，因...
博客
HiveServer2 内存泄漏问题定位与优化方案
09-09
1842
动手点关注 干货不迷路 ????前言HiveServer2 属于 Hive 组件的一个服务，主要提供 Hive 访问接口，例如可通过 JDBC 的方式提交 Hive 作业，HiveServer2 基于 Java 开发，整个服务运行过程中，内存的管理回收均由 JVM 进行控制。在 JVM 语言中的内存泄漏与 C/C++ 语言的内存泄漏会有些差异，JVM 的内存泄漏更多的是业务代码逻辑错误引起大量对象引用被...
博客
火山引擎在行为分析场景下的 ClickHouse JOIN 优化
09-05
1090
动手点关注 干货不迷路 ????1. 背景火山引擎增长分析 DataFinder 基于 ClickHouse 来进行行为日志的分析，ClickHouse 的主要版本是基于社区版改进开发的字节内部版本。主要的表结构：事件表：存储用户行为数据，以用户 ID分 shard 存储。--列出了主要的字段信息CREATETABLEtob_apps_all(`tea_app_id`...
博客
飞书 Android 升级 JDK 11 引发的 CI 构建性能问题
09-02
929
动手点关注干货不迷路????一、摘要本文从飞书 Android 升级 JDK 11 意外引发的 CI 构建性能劣化谈起，结合高版本 JDK 在 Docker 容器和 GC 方面的新特性，深挖 JVM 和 Gradle 的源码实现，抽丝剥茧地介绍了分析过程和修复方法，供其他升级 JDK 的团队参考。二、背景最近飞书适配 Android 12 时把 targetSdkVersion 和 compileSd...
博客
春节活动 - 高峰值奖励发放技术方案
08-30
1168
动手点关注 干货不迷路 ????1. 背景2022年春节活动在8款字节系 APP 上线，包含了红包雨、集年味卡和烟火大会等诸多玩法。红包雨、集卡开奖和烟火大会都存在高峰值突发流量。其中，红包雨活动会在10分钟内给几千万甚至上亿用户发放上亿现金奖励，且大多数请求集中在前3分钟。在项目启动时，红包雨活动作为最大的流量来源，预估的发红包峰值流量有180万 QPS 。为了保证用户体验、活动效果和资金安全，红包雨...
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
字节跳动技术团队
CSDN认证博客专家
CSDN认证企业博客
238
原创
9690
周排名
1719
总排名
128万+
访问
等级
8466
积分
5913
粉丝
656
获赞
369
评论
2165
收藏
私信
关注
热门文章
抖音品质建设 - iOS启动优化之原理篇
38182
字节跳动自研万亿级图数据库 & 图计算实践
31420
字节跳动技术团队年度 TOP10 技术干货，陪你度过不平凡的 2020
27557
字节跳动自研线上引流回放系统的架构演进
26426
字节跳动开源云原生机器学习平台 Klever
24539
最新评论
浅谈Linux设备虚拟化技术的演进之路
Bill_Xiang:
vdpa将virtio带入了容器领域，容器是说只能用内核驱动的网络设备，没有vdpa之前virtio应该是说只能虚拟机用，有了vdpa之后容器也能用virtio硬件设备了，然后vduse又进一步可以给容器提供软件的virtio设备，总的来说还是用在容器的场景里，可以这么理解吧
Android 系统 Bar 沉浸式完美兼容方案
huaqiangsina:
鸿蒙无效。
字节跳动智能创作团队多篇论文入选 CVPR 2022
小菜鸡加油:
Dressing in the Wild by Watching Dance Videos 这一篇没有代码吗
抖音Android无障碍开发知识总结
qiixiao:
所以，抖音app是和Mac一样，支持按键操作吗？
西瓜视频 iOS Voice Over 无障碍适配实践
LTOVE-CODE:
多音字怎么处理的
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
字节跳动一站式数据治理思考及实践
火山引擎 RTC 助力抖音百万并发“云侃球”
字节跳动数据中台的 Data Catalog 系统搜索实践
2022
12月
2篇
11月
5篇
10月
4篇
09月
8篇
08月
11篇
07月
14篇
06月
21篇
05月
17篇
04月
11篇
03月
6篇
02月
8篇
01月
8篇
2021年58篇
2020年47篇
2019年12篇
2017年6篇
目录
目录
最新文章
字节跳动一站式数据治理思考及实践
火山引擎 RTC 助力抖音百万并发“云侃球”
字节跳动数据中台的 Data Catalog 系统搜索实践
2022
12月
2篇
11月
5篇
10月
4篇
09月
8篇
08月
11篇
07月
14篇
06月
21篇
05月
17篇
04月
11篇
03月
6篇
02月
8篇
01月
8篇
2021年58篇
2020年47篇
2019年12篇
2017年6篇
目录
评论
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值