字节数据中台 DataLeap 的 Data Catalog 系统通过接收 MQ 中的近实时消息来同步部分元数据。Apache Atlas 对于实时消息的消费处理不满足性能要求，内部使用 Flink 任务的处理方案在 ToB 场景中也存在诸多限制，所以团队自研了轻量级异步消息处理框架，很好的支持了字节内部和火山引擎上同步元数据的诉求。本文定义了需求场景，并详细介绍框架的设计与实现。
KubeGateway 是字节跳动针对 kube-apiserver 流量特征专门定制的七层网关，它彻底解决了 kube-apiserver 负载不均衡的问题，同时在社区范围内首次实现了对 kube-apiserver 请求的完整治理，包括请求路由、分流、限流、降级等，显著提高了 Kubernetes 集群的可用性。
Notebook 是一种支持 REPL 模式的开发环境。所谓「REPL」，即「读取-求值-输出」循环：输入一段代码，立刻得到相应的结果，并继续等待下一次输入。它通常使得探索性的开发和调试更加便捷。在 Notebook 环境，你可以交互式地在其中编写你的代码、运行代码、查看输出、可视化数据并查看结果，使用起来非常灵活。 在数据开发领域，Notebook 广泛应用于数据清理和转换、数值模拟、统计建模、数据可视化、构建和训练机器学习模型等方面。 但是显然，做数据开发，只有 Notebook 是不够的。在火山引擎 DataLeap 数据研发平台，我们提供了任务开发、发布调度、监控运维等一系列能力。我们将 Notebook 作为一种任务类型，加入了数据研发平台，使用户既能拥有 Notebook 交互式的开发体验，又能享受一站式大数据研发治理套件提供的便利。
2022 年 10 月 25 日（美国时间）支持 HEVC 硬解功能的 Chrome 107 已正式开始全量推送给所有用户。10 月 21 日 Chrome 官方在更新日志中做了正式说明。 这个事件的背后离不开一位来自字节的开源贡献者的努力，ByteTech 了解到了相关背景，特意邀请了斯杰同学对整件事的来龙去脉作了梳理，以飨读者。
数据地图平台是字节跳动内部的大数据检索平台，每天近万的字节员工在此查找所需数据。数据地图通过提供便捷的找数，理解数服务，大大节省了内部数据的沟通和建设成本。 血缘图谱由 xGraph 与数据地图平台团队合作研发。xGraph 从 Dataleap 业务中孵化，从底至上完全自研，提供设计成熟的内置节点、连线、分组样式，精心打磨图分析产品中常用布局和交互，帮助用户快速搭建关系图产品。血缘图谱解决方案已沉淀到 xGraph 为更多团队复用。
RTC（Real Time Communication）是音视频基础设施，它已经融入了大家生活的方方面面：工作中，我们组织视频会议，即使团队成员身处异国，也能保证项目推进；休息时，我们打开抖音，看主播直播连麦；来一局游戏时，我们打开小队语音，大杀四方；学习时，我们相聚线上互动课堂，知识传播不再受距离的桎梏。RTC 拉近了大家的距离，丰富了大家的生活。 在这些场景里，我们最不能忍受的是什么？是延迟！想象一下，开会或者主播连麦时，一个人讲完话，其他人隔 10 秒才能做出反应，这几乎是完全不能接受的体验。 那么什么样的延迟才是好的体验呢？根据 ITU-T G.114 的建议：延时低于 400ms 的通话体验是可接受的，低于 200ms 是令人愉悦的。
字节各类业务拥有众多用户群，作为字节前端性能监控 SDK，自身若存在性能问题，则会影响到数以亿计的真实用户的体验。所以此类 SDK 自身的性能在设计之初，就必须达到一个非常极致的水准。 与此同时，随着业务不断迭代，功能变得越来越多，对监控的需求也会变得越来越多。例如，今天 A 业务更新了架构，想要自定义性能指标的获取规则，明天 B 业务接入了微前端框架，需要监控子应用的性能。在解决这些业务需求的同时，我们会不断加入额外的判断逻辑、配置项。同时由于用户的电脑性能、浏览器环境的不同，我们又要解决各种兼容性问题，加入 polyfill 等代码，不可避免地造成 SDK 体积膨胀，性能劣化。那么我们是如何在需求和功能不断迭代的情况下，持续追踪和优化 SDK 的体积和性能的呢？
VLDB 会议，全称 International Conference on Very Large Data Bases，是全球数据库系统领域最负盛名的三大顶会之一。从 1975 年开始举办，每年一次，全球各地顶尖高校的大量研究者、各大高科技公司都会将自己的学术研究进展或工业界成果以论文形式投递到 VLDB 组委会，而组委会会审阅并接收其中最前沿、最具影响力的一批，并召开线下会议，供论文作者们分享、交流。 今年的 VLDB 在 9 月 5 日到 9 日，在澳大利亚悉尼举办。作为在全球有广泛用户和海量数据挑战的字节跳动公司，有三篇论文被 VLDB 接收：其中两篇来自 Graph 团队 ，一篇 ByteHTAP 系统，应 VLDB 组委会邀请，字节相关团队来到了正值早春的悉尼，与来自世界各地的数据领域专家学者，分享交流，共襄盛举。 为了让大家能对 VLDB 2022 有个快速的了解，我们总结了 VLDB 的论文分类、研究趋势以及工业界重点论文的摘要，当然啦，也包括字节跳动三篇论文简介。本文抛砖引玉，如果想深入了解学习，还是非常建议找到论文原文来仔细研究一番。
在正式开始介绍第一部分的内容之前，先给大家展示一组关键词。2020 年初 Hertz 立项，2020 年 10 月，Hertz 发布第一个可用版本。2022 年 6 月，Hertz 正式开源。 截至目前，Hertz 在字节内部已经支撑超过 1.4 万个业务服务，日峰值 QPS 超过 5000 万。 Hertz 不仅支撑业务服务，同时还会横向支撑字节内部的各种基础组件，包括但不限于字节跳动服务网格控制面、公司级别压测平台以及 FaaS，还包括各种业务网关等等。Hertz 的高性能和极强的稳定性可以支撑业务复杂多变的场景。在公司内部 Hertz 接替了大量基于 Gin 框架开发的存量服务，大幅度降低了业务资源使用成本以及服务延时，助力公司层面的降本增效。
我们一般会把 Sync 理解为 Android Studio 的准备阶段，包括解析工程配置信息、下载远程依赖到本地、更新代码索引等准备工作，当修改 gradle build 文件后，需要重新 Sync 将 Gradle 构建配置信息同步到 IDE，进而使 IDE 的功能及时应用新的构建配置，这些功能包括项目的 Gradle Task 列表展示、依赖信息展示等等。Sync 是 Android Studio 中独有的概念，当通过 Gradle 命令行程序构建 Android 应用时，只会经历 Gradle 定义的 Initialization、Configuration 和 Execution 生命周期，根本没有 Sync 的概念。Android Studio 的 Sync 阶段涉及到 IDE、Gradle、Plugin 等多个角色，梳理清楚这些角色各自的作用和联系，才能清晰理解 Sync 的整体架构，下面分别来介绍这些角色：
