Semi Design 是由抖音前端团队，MED 产品设计团队设计、开发并维护的桌面端设计系统。它从字节跳动各业务的复杂场景提炼而来，支撑包括客服、建站、项目管理、创作者与音乐人服务在内的，多元品类下近千计平台产品，服务内、外部 10 万+ 用户。

本篇文章介绍了字节跳动在 Flink 状态查询方面所进行的优化，解决了查询 Flink 任务状态时开发成本高及无法查询状态元信息等问题，提出了 State Query on Flink SQL 的解决方案，让用户使用 Flink Batch SQL 就可以快速查询 Flink 任务状态。

2022 年 3 月 15 日，Google 发布了万众瞩目的 Golang 1.18，带来了好几个重大的新特性，包括：

1. 解决本地同时开发多个仓库带来的一些问题的工作区（Workspace）
2. 能够自动探测代码分支，随机生成输入，并且检查代码是否会 panic 的模糊测试（Fuzzing Test）
3. 众多开发者盼星星盼月亮终于等到的泛型支持。

本文将简单讲述这三个特性的相关内容。

数据探查上线之前，数据验证都是通过写 SQL 方式进行查询的，从编写 SQL，到解析运行出结果，不仅时间长，还会反复消耗计算资源，探查上线后，只需要一次探查，就可以得到整张表的探查报告，但后续我们还发现了一些问题，主要有三点：

1. 无法看到探查的数据明细以及关联的行详情，无法对数据进行预处理操作。
2. 探查还是需要资源调度，等待时长平均分钟级。
3. 与质量监控没有打通，探查数据的后续走向不明确。

针对这些问题，我们进一步开发了动态探查需求，解决的问题如下：

1. 基于大数据预览的探查，支持对数据进行函数级别的预处理。
2. 探查结果秒级更新，实时响应。
3. 与数据监控打通，探索 SQL 的生成模式。

能抵抗剪切、拼接和编辑等攻击的隐藏水印了解一下？

以抖音直播为例，直播链路各环节延迟贡献如下：

• 推流端——网络延迟平均 20 ～ 30ms，编码延迟依赖编码参数设置而定
• 流媒体服务——在拉流转码的场景下，会额外引入 300ms ～ 2s 的转码延迟(大小与转码参数相关)，如果直接播放源流，则不存在转码延迟
• 播放端——网络延迟 100ms ～ 200ms 左右，主要是链路分发节点之间的传输延迟；防抖 buffer——5 ～ 8s

从各环节延迟贡献看，容易得出一个直观的结论：端到端延迟过大主要是播放器的防抖 buffer 造成，这个表面现象也经常会导致很多同学，认为降低播放器的 buffer，就能降低延迟。这个说法的对错，取决于从什么角度解释。

在实现实现任何功能前，一般都需要有数据统计支撑，作为收益验证的手段以及测试 Case 收集的手段。因此，在尝试实现 HEVC 硬解前，首先需要统计有多少视频是 HEVC 视频，并拿到视频的解码参数。

很不幸，浏览器层面并未给我们暴露出视频的解码信息，比如分辨率，编码，Profile，色彩空间。这些一系列的视频参数，对于前端都是无感知且无法感知的。

因此，在往常，如果需要获取视频信息做数据统计，首先需要拿到视频的二进制数据，在前端解析视频的元数据（比如 HEVC VPS、SPS、PPS），来提取视频参数。这样做，缺点是显而易见的，这种方式并不支持原生的 Video 标签播放的内容，且需要额外二次发起请求，且需要针对每种编码均实现一遍。

因此，如果能从 Renderer 层，以浏览器视角，监听视频的解码信息，那或许我们则不需要做任何 Trick 的操作？我在这个过程尝试探索了一下，并成功实现了这个诉求。

本方案梳理了业界主流权限模型，IT Saas 化中权限管理要解决的问题，参考了公司内外、国内外的一些权限设计方案，结合 RBAC、ABAC 模型提出了 ITAM 融合模型权限管理方案。

以全局视角论述 WebAssembly 技术生态发展情况以及其中涉及到的关键技术。是建立完整技术认知和体系的综述性文章，文章链接较多，建议在 PC 上访问阅读。

随着财经支付业务的快速发展，考虑到未来订单量持续增长，在线存储遇到更大的挑战，需提前做好规划。目前财经支付主要业务都是使用 mysql（InnoDB）作为数据存储，因历史订单信息访问频率低并占用了大量数据库存储空间，期望将历史数据跟生产最新交易数据进行分离，当前数据库保留最近一段时间的数据作为热库，历史交易存入另一个数据库压缩存储作为冷库(rocksdb)，即数据库冷热分离。此举将会极大的节省数据库设备成本，减少因在线存储空间不足扩容导致停服不可用的时长，以下基于财经支付的统一交易系统现状做的相关案例分析仅供大家参考。

前端测试也是一种自动化测试技术，其测试的主要对象就是 Web 应用的图形用户界面（GUI）、功能和可用性，以确保 Web 应用的 GUI 层在连续的更新迭代中没有 Bug。

例如，可以检查输入字段是否接受正确的字符，表单是否仅在填写所需字段后才提交，导航是否足够简单，页面加载是否足够快，等等。

前端测试的目标是测试功能，并验证网站或应用程序的表示层是否存在错误或无错误。测试必须在每次系统更新或变更后执行，以确保最近的更改不会对 UI 层产生任何预期外的影响。

搭建平台解决方案除了常见的 DSL 还是否有其他解决方案？Code In & Code Out 方案的价值在哪里？搭建平台又如何与微前端进行结合？

用户下了一笔订单，订单中有 x（根据业务场景，x <= 6）张电影票，y 张兑换券，从这 y 张兑换券中选择不超过 x 张兑换券，使得该笔订单的实际支付金额最少，如果有多种解决方案，那么根据以下优先级为用户推荐选券的方案：

• 优先级 1: 选择实际支付金额少的方案
• 优先级 2: 如果实际支付金额一致，则优先使用面值小的方案
  • 原因：如果用户想购买一张票价为 38 元的电影票，当前他有一张 40 元和一张 60 元的兑换券，任意使用一张兑换券能得到的实际支付金额都是 0 元，那么优先为用户选择 40 元的兑换券，这样 60 元的兑换券就能服务于用户的下一笔订单，更能为用户省钱。
• 优先级 3: 若面值大小也一致，则优先使用优惠券所在券包消耗券数目多的优惠券
• 优先级 4: 若消耗券数目一致，则优先使用过期时间早的优惠券

本文将介绍字节跳动在埋点数据流业务场景遇到的需求和挑战以及具体实践，分为上下篇呈现。上篇主要包含埋点数据流简介与埋点数据流建设实践；下篇主要包含埋点数据流治理实践以及未来规划。

在前面几篇的内容里，我们的例子大部分都是黑白的，那是因为我们着重于渲染形状，基本没有考虑渲染成不同的颜色。

我们既然把 shader 中文翻译成“着色器”，顾名思义，“着色器”本身就是用来在画布上“着色”的，自然和颜色有着密切的关系。

话不多说，我们仍然通过代码由浅入深地来看一看。

近几年春节期间，抖音都会为用户带来各式各样的春节活动，每年都会有数亿用户参与其中。2022 年春节，抖音支付也参与了春节活动，面向海量用户发放抖音支付券，帮助用户在抖音春节活动中获得更好体验。对抖音支付来说，这是一个很大的挑战，因为之前抖音支付团队没有真正意义上经历过春节活动这种量级的应用场景，这对抖音支付营销系统是极大的考验。