字节跳动 Flink 状态查询实践与优化_ 字节跳动技术团队的博客-CSDN博客
字节跳动 Flink 状态查询实践与优化
字节跳动技术团队
于 2022-07-12 12:00:53 发布
1707
收藏
文章标签：
大数据
编程语言
数据库
python
java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ByteDanceTech/article/details/125755236
版权
动手点关注干货不迷路 👆
本篇文章介绍了字节跳动在 Flink 状态查询方面所进行的优化，解决了查询 Flink 任务状态时开发成本高及无法查询状态元信息等问题，提出了 State Query on Flink SQL 的解决方案，让用户使用 Flink Batch SQL 就可以快速查询 Flink 任务状态。
背景
众所周知，Flink 中的 State 保存了算子计算过程的中间结果。当任务出现异常时，可以通过查询任务快照中的 State 获取有效线索。
但目前对于 Flink SQL 任务来说，当我们想要查询作业 State 时，通常会因为无法获知 State 的定义方式和具体类型等信息，而导致查询 State 的成本过高。
为了解决这个问题，字节跳动流式计算团队在内部提出了 State Query on Flink SQL 的解决方案——用户通过写 SQL 的方式就可以简单地查询 State。本文将主要介绍字节跳动在 Flink 状态查询这方面所进行的相关工作。
State Processor API 介绍
提到状态查询，我们自然会联想到 Flink 在 1.9 版本提出的特性 -- State Processor API。使用 State Processor API，我们可以将作业产生的 Savepoint 转换成 DataSet，然后使用 DataSet API 完成对 State 的查询、修改和初始化等操作。
下面简单介绍一下如何使用 State Processor API 来完成 State 的查询：
首先创建 ExistingSavepoint 用来表示一个 Savepoint。初始化 ExistingSavepoint 时需要提供 Savepoint 路径和 StateBackend 等信息；然后实现 ReaderFunction 用于重新注册所需要查询的 State 以及定义处理 State 的方式。查询状态的过程中会遍历所有的 Key 并按照我们定义的方式去操作 State；最后，调用 Savepoint.readKeyedState 并传入算子的 uid 和 ReaderFunction，就可以完成 State 的查询。
接下来为大家简述一下 State 查询背后的原理。
在 Savepoint 目录中包含两种文件，一种是状态数据文件，比如上图中的 opA-1-state ，这个文件里面保存着算子 A 在第一个 SubTask 状态的明细数据；还有一种元数据文件，对应上图中的 _metadata，元数据文件中保存了每个算子和状态文件的映射关系。
当我们在进行状态查询的时候。首先在 Client 端会根据 Savepoint 路径去解析 metadata 文件。通过算子 ID，可以获取需要查询的状态所对应的文件的句柄。当状态查询真正执行时，负责读取状态的 Task 会创建一个新的 StateBackend ，然后将状态文件中的数据恢复到 Statebackend 中。等到状态恢复完成之后就会遍历全部的 Key 并把对应的状态交给 ReaderFunction 处理。
有些同学可能会问，既然社区已经提供了查询 State 的功能，我们为什么还要去做同样的工作呢？主要是因为我们在使用 State Processor API 的过程中发现一些问题：
每次查询 State 我们都需要独立开发一个 Flink Batch 任务，对用户来说具有一定的开发成本；实现 ReaderFunction 的时候需要比较清晰地了解任务状态的定义方式，包括 State 的名称、类型以及 State Descriptor 等信息，对用户来说使用门槛高较高；使用 State Processor API 时，只能查询单个算子状态，无法同时查询多个算子的状态；无法直接查询任务状态的元信息，比如查询任务使用了哪些状态，或者查询某个状态的类型。
总体来说，我们的目标有两个，一是降低用户的使用成本；二是增强状态查询的功能。我们希望用户在查询 State 时能用最简单的方式；同时也不需要知道任何信息。
此外，我们还希望用户能同时查询多个算子的 State ，也可以直接查询作业使用了哪些 State，每个 State 的类型是什么。
因此，我们提出了 State Query on Flink SQL 的解决方案。简单来说是把 State 当成数据库一样，让用户通过写 SQL 的方式就可以很简单地查询 State。
在这个方案中，我们需要解决两个问题：
如何对用户屏蔽 State 的信息：参考 State Processor API 我们可以知道，查询 State 需要提供非常多的信息，比如 Savepoint 路径、 StateBacked 类型、算子 id 、State Descriptor 等等。通过 SQL 语句显然难以完整地表述这些复杂的信息，那么查询状态到底需要哪些内容，我们又如何对用户屏蔽 State 里复杂的细节呢？这是我们面对的第一个难点。如何用 SQL 表达 State：State 在 Flink 中的存储方式并不像 Database 一样，我们如何去用 SQL 来表达状态的查询过程呢？这是我们要解决的另一个难点。
StateMeta Snapshot 机制
首先我们来回答第一个问题，查询一个 State 需要哪些信息呢？
可以参考上文中 State Processor API 的示例，当我们创建 ExistingSavepoint 和 ReaderFunction 的时候，我们需要提供的信息有 Savepoint 路径、Backend 类型、OperatorID、算子 key 的类型、State 名称以及 Serializer 等等，我们可以将这些统一称为状态的元信息。
对于 Flink SQL 任务来说，要清楚地了解这些信息，对用户来说门槛是非常高的。我们的想法是让用户只需要提供最简单的信息，即 Savepoint ID ，然后由 Flink 框架把其他的元信息都存在 Savepoint 中，这样就可以对用户屏蔽 State 那些复杂的细节，完成状态的查询。因此，我们引入了 StateMeta Snapshot 机制。
StateMeta Snapshot 简单来说就是把状态的元信息添加到 Savepoint Metadata 的过程，具体步骤如下：
首先在 State 注册的时候，Task 会把 operatorName\ID\KeySerializer\StateDescriptors 等元信息都保存在 Task 的内存中；触发 Savepoint 时，Task 会在制作快照的同时，对状态的元信息也同样进行快照。快照完成之后将状态的元信息 (StateMeta) 和状态文件的句柄 (StateHandle) 一起上报给 JobManager；JobManager 在收到所有 Task 上报的 StateMeta 信息之后 ，将这些状态元信息进行合并，最后会把合并之后的状态元信息保存到 Savepoint 目录里名为 stateInfo 的文件中。
之后在状态查询时就只需解析 Savepoint 中的 stateInfo 文件，而不再需要用户通过代码去输入这些 State 的元信息。通过这样的方式可以很大程度地降低用户查询状态的成本。
State as Database
接下来我们来回答第二个问题，我们如何用 SQL 来表达 State。其实社区在设计 State Processor API 的时候就提出了一些解决思路，也就是 State As Database。
在传统的数据库中，通常用 Catalog、Database、Table 这个三个元素来表示一个 Table，其实我们也可以将用样的逻辑到映射到 Flink State 上。我们可以把 Flink 的 State 当作一种特殊的数据源，作业每次产生的 Savepoint 都当作一个独立 DB 。在这个 DB 中，我们将 State 元信息、State 的明细数据，都抽象成不同的 Table 暴露给用户，用户直接查询这些 Table 就可以获取任务的状态信息。
首先我们来看如何把 State 表示为 Table。我们都知道在 Flink 中，常用的 State 有两种类型，分别是 KeyedState 和 OperatorState。
对于 OperatorState 来说，它只有 Value 这一个属性，用来表示这个 State 具体的值。因此我们可以把 OperatorState 表示为只包含一个 Value 字段的表结构。对于 KeyedState 来说，每个 State 在不同的 Key 和 Namespace 下的值可能都不一样， 因此我们可以将 KeyedState 表示为一个包含 Key、Namespace、Value 这三个字段的表结构。
当我们抽象出了单个 State 之后，想要表示多个 State 就比较容易了。可以看到在上图的例子中，这个算子包含 3 个 State，分别是两个 KeyedState 和一个 OperatorState，我们只需要将这些 Table 简单的 union 起来，再通过 state_name 字段去区分不同的 State，就可以表示这个算子中所有的 State。
最后还有一个问题，我们如何知道一个任务到底用了哪些 State 或者这些 State 的具体类型呢？
为了解决这个问题，我们定义了一种特殊表 -- StateMeta ，用来表示一个 Flink 任务中所有 State 的元信息。StateMeta 中包含一个任务中每个 State 的名称、State 所在的算子 ID 、算子名称 、Key 的类型和 Value 的类型等等，这样用户直接查询 StateMeta 这个表就能获取任务中所有状态的元信息。
使用 Flink Batch SQL 查询任务状态
以上就是状态查询方案的整体介绍。那我们到底如何去查询一个 State 呢，我们以一个 Word Count 任务为例来说明。
首先，我们需要创建一个 Flink SQL 任务并启动。通过 web-ui 可以看到这个任务中包含三个算子，分别是 Source，Aggregate 还有 Sink。然后，我们可以触发 Savepoint，当 Savepoint 制作成功之后获取对应的 SavepointID。我们可以通过 SavepointID 去完成作业状态的查询。
假如我们现在对 Flink SQL 任务中状态的使用一无所知，那么首先我们需要查询的就是这个 Flink 任务中包含哪些 State 以及这些 State 的类型。我们可以从 StateMeta 表获取这些信息。如上图中场景一所示，通过查询 StateMeta 表，可以看到这个任务包含一个 ListState 和一个 ValueState，分别存在于 Source 算子和 Aggregate 算子中。
此外，有些对 Flink 比较了解的同学知道，KafkaSource 中的 State 是用于记录当前消费的 Offset 信息。如场景二所示，我们可以通过查询 Source 算子的状态，获取到任务中消费 Kafka Topic 的 Partition 和 Offset 信息。
还有一种比较常见的场景，比如下游的业务同学发现某个 key（比如 key_662）的结果异常。我们在定位问题的时候可以直接去查询作业中 aggregate 算子中的状态，同时去指定 key 等于 key_662 作为查询条件。如上图场景三所示，通过查询的结果可以看到，当 key 为 662 时对应的聚合结果是 11290。用户使用这样的方式就可以比较方便地验证状态是否正确。
未来展望
未来，我们计划进一步丰富 State 的功能，目前我们支持了使用 SQL 查询 State 的功能 ，其实社区还提供了 State 修改和初始化的能力。在一些场景下，这些能力也比较重要。比如，我们已知状态中的部分 key 计算错误，希望将状态中这部分的数据进行修正；或者任务逻辑发生变更以后和之前的状态不能完全兼容， 这个时候我们希望可以通过状态修改和初始化的能力去生成一个新的 Savepoint。同样，在使用方式上我们也希望用户能直接使用 SQL 中 insert 和 update 语法来完成状态的修改和初始化操作。
其次，我们会进一步加强 State 的可用性。我们使用 DAG 编辑的方案解决了作业拓扑发生变化时产生的状态不兼容问题，但是当 Flink SQL 任务修改字段时 State Serializer 可能会变化，同样导致状态无法兼容。针对这种情况我们设计了完整的 Flink SQL State Schema Evolution 方案，可以极大的增强 Flink SQL 任务发生变化之后状态的恢复能力，目前正在落地中。我们还提供了完善的状态恢复事前检查能力，能够做到在任务上线之前就检查出状态是否兼容并告知用户，避免状态不兼容引起作业启动失败对线上造成影响。
加入我们
字节跳动实时计算团队负责公司内部实时计算场景, 支撑了数仓/机器学习/推荐/搜索/广告/流媒体/安全和风控等众多核心业务，我们面临的挑战是超大单体作业(千万级别 QPS)，超大集群规模(上万台机器)的应用场景，在 SQL, State, Runtime 上都有深度优化。公司仍处于高速发展阶段，欢迎有能力、有想法的同学来这里一起建设实时计算引擎。工作地点：北京、杭州，感兴趣的同学点击阅读原文投递简历。
字节跳动技术团队
关注
关注
点赞
收藏
评论
字节跳动 Flink 状态查询实践与优化
动手点关注干货不迷路????本篇文章介绍了字节跳动在 Flink 状态查询方面所进行的优化，解决了查询 Flink 任务状态时开发成本高及无法查询状态元信息等问题，提出了 State Query on Flink SQL 的解决方案，让用户使用 Flink Batch SQL 就可以快速查询 Flink 任务状态。背景众所周知，Flink 中的 State 保存了算子计算过程...
复制链接
扫一扫
参与评论
您还未登录，请先
登录
后发表或查看评论
博客
字节跳动一站式数据治理思考及实践
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币套餐、付费专栏及课程。
余额充值