行为序列模型相对于传统机器学习的主要优势在于不依赖行为画像特征，无需强专家经验挖掘高效特征来提升模型性能，缩短了特征工程的周期，能快速响应黑产攻击。

黑产通过刷接口、群控、真人众包等作弊手段在关注、点赞、评论等核心场景进行攻击。不同作弊方式在行为序列上有不同的特点。刷接口、群控作弊属于机器作弊，行为序列呈现团伙相似性、序列周期性 / 密集性。真人众包主要通过线下软件分发任务真人账号执行，行为链路具有比较固定模式以上作弊方式在行为序列上具有显著性，所以在风控业务上序列模型有很好的落地能力。

这篇文章从 Sketch 结构的定义和特性出发，解释了 Sketch 结构如何解决大数据计算场景中海量数据计算痛点，明确了 Quantile 问题的定义。其次，结合大数据开发中常用组件，讨论了如何将 Quantile Sketch 算法带入工程实践中。本文着重介绍了 Quantile Sketches 算法原理，涵盖了算法发展的几个重要阶段和重要产物。笔者尝试用最简单的语言和逻辑讲解了每一个算法的核心思想、优点和缺陷，尝试将多种算法的发展串联起来，方便没有相关背景的人从零开始了解这个领域。

动态监控 SDK 对于客户端上敏感权限 API （安卓端约79个，IOS端约50个）会进行调用的监控。对于不合规的调用会透过自定义异常将当下发生的端上信息记录成日志并回传 Slardar 落库。NvWa 平台致力于将这些报警日志以全自动化的方式做收集、处理、归因、消费。针对有合规疑虑的业务场景通知 POC、RD 整改，并记录其过程，达成完整的动态监控生产消费链，确保隐私合规安全。

动态监控的音视频业务场景下，端上往往因为各种原因导致监控异常引发日志报警，例如：API 只调用一次导致未关闭音视频实例、业务代码 bug、线程关闭异常...等等。传统归因方法通过正则匹配、人工插入日志等方法能够对一部分异常进行归因，但是难以发现公共特征，导致大量报警数据无法消费，形成潜在风险。

计算机或手机的渲染是一个非常复杂的过程，本文介绍了渲染相关的一些基础知识，并结合 iOS 和安卓的技术框架介绍了移动端渲染原理，最后详细的解析了 iOS 中的离屏渲染以及圆角优化的一些方法。

字节的 DataCatalog 系统，在 2021 年进行过大规模重构，新版本的存储层基于 Apache Atlas 实现。迁移过程中，我们遇到了比较多的性能问题。本文以 Data Catalog 系统升级过程为例，与大家讨论业务系统性能优化方面的思考，也会介绍我们关于 Apache Atlas 相关的性能优化。

飞书智能问答应用于员工服务场景，致力于减少客服人力消耗的同时，以卡片的形式高效解决用户知识探索性需求。飞书智能问答整合了服务台、wiki 中的问答对，形成问答知识库，在综合搜索、服务台中以一问一答的方式将知识提供给用户。

作为企业级 SaaS 应用，飞书对数据安全和服务稳定性都有极高的要求，这就导致了训练数据存在严重的不足，且极大的依赖于公开数据而无法使用业务数据。在模型迭代过程中，依赖公开数据也导致模型训练数据存在与业务数据分布不一致的情况。通过和多个试点服务台的合作，在得到用户充分授权后，以不接触数据的方式进行训练。即模型可见数据，但人工无法以任何方式获取明文数据。

本文主要分享字节跳动在使用 Flink State 上的实践经验，内容包括 Flink State 相关实践以及部分字节内部在引擎上的优化，希望可以给 Flink 用户的开发及调优提供一些借鉴意义。

功耗优化是应用体验优化的一个重要课题，高功耗会引发用户的电量焦虑，也会导致糟糕的发热体验，从而降低了用户的使用意愿。而功耗又是涉及整机的长时间多场景的综合性复杂指标，影响因素很多。不论是功耗的量化拆解，还是异常问题的监控，以及主动的功耗优化对于开发人员来说都是很有挑战性的。

本文结合抖音的功耗优化实践中产出了一些实验结论，优化思路，从功耗的基础知识，功耗组成，功耗分析，功耗优化等几个方面，对 Android 应用的功耗优化做一个总结沉淀。

在字节跳动内部，数据平台数据治理团队致力于建立一站式、全链路的数据治理解决方案平台。本文是字节跳动数据平台开发套件团队王慧祥参与的“数智有为第二期”在线分享的部分摘录。

应用安装包的体积会显著影响应用的下载速度和安装速度，按照 Google 的经验数据，包体积每增加 1M 会造成 0.17%的新增折损。抖音的一些实验也证明了包体积会显著影响下载激活的转化率。

Android 的安装包是 APK 格式的，在抖音的安装包中 DEX 的体积占比达到了 40%以上，所以针对 DEX 的体积优化是一种行之有效的包体积优化手段。

DEX 本质上是由 Java/Kotlin 代码编译而成的字节码，因此，针对字节码进行业务无感的通用优化成为我们的一个探索方向。

随着虚拟化技术如模拟器，容器化等技术等发展，在安卓云游戏/云手机场景中，可以在服务宿主侧虚拟出更多更小颗粒度的 Android 实例。其中比较核心的技术是图形虚拟化技术，如何最大限度利用宿主侧的 GPU 资源进行渲染和编码，不考虑软编等利用 CPU 资源进行渲染编码是因为效率带来的延迟问题。

数据库技术一直是信息技术中极其重要的一环，在步入云原生时代后，云基础设施和数据库进一步整合，弥补了传统数据库的痛点，带来了高可扩展性、全面自动化、快速部署、节约成本、管理便捷等优势。

从 2018 到 2021 年，伴随业务和数据的迅猛增长，字节跳动的分布式数据库系统取得了令人振奋的发展。如下图所示，在这 4 年间，公司应用侧容器数量从 5 万个增长到了 750 万个，截至目前已经突破 1000 万。这 1000 万个容器筑成了字节跳动坚实的云原生基础设施，支撑着整个业务体系的发展。

自 2016 年以来，为了支撑在线推荐的存储需求而诞生的——字节跳动自研高可用 KV 存储 Abase，逐步发展成支撑包括推荐、广告、搜索、抖音、西瓜、飞书、游戏等公司内几乎所有业务线的 90% 以上的 KV 存储场景，已成为公司内使用最广泛的在线存储系统之一。

作为一个以新闻、资讯为主的 App，今日头条上的主要内容都是由文章组成，文章服务自然伴随着今日头条 App 的产生就已出现，之后又逐步扩展为目前的内容云，为头条、西瓜、小说、懂车帝等多个 App 服务的业务内容中台。截止 2021 年底，内容云接入子业务已经达到数百个，高峰期主要读服务 QPS 数百万，维护超过 2200 个属性，存量数据达到百亿条级别。然而由于历史悠久，经手人众多，加上历史上一些环境或周边系统的特殊性，业务模式发生转变等，使得内容云成为一个标准的大型遗留系统，早期的一些存储、架构上的设计已经逐渐无法满足当前的业务场景，并给维护者带来了较大维护和迭代成本。

因此我们启动了内容云存储层的迁移项目，随着调研和与其他业务的讨论的不断深入，发现各业务对存储层的痛点及需求基本一致，存储模型和实现方案逐渐趋同，因此决定基于 ByteKV 开发一个宽表数据服务（本文主要聚焦在遗留系统存储层迁移的过程，暂不涉及新存储层的设计与实现细节），下沉存储层通用逻辑，供其他业务接入，并替换内容云原有的存储层。最终历时将近 1 年时间将在线流量切换至新的存储层。

迁移一个系统的存储能有多复杂？无非是双写、迁移数据、切读、停写罢了，为何内容云存储层的迁移竟花费将近一年时间？本文主要分享内容云存储层迁移的血泪史，过程中的一些坑和经验，望能给其他大型系统迁移存储或做重构带来一些流程上的参考。

作为一款面向 ToB 市场的产品——火山引擎 A/B 测试（DataTester）为了满足客户对数据安全、合规问题等需求，探索私有化部署是产品无法绕开的一条路。

在面向 ToB 客户私有化的实际落地中，火山引擎 A/B 测试（DataTester）也遇到了字节内部服务和企业 SaaS 服务都不容易遇到的问题。在解决这些问题的落地实践中，火山引擎 A/B 测试团队沉淀了一些流程管理、性能优化等方面的经验。

本文主要分享火山引擎 A/B 测试当前的私有化架构，遇到的主要问题以及从业务角度出发的解决思路。

本文分析了 Android Studio Sync 在 Gradle 层面的底层逻辑，并且从原理出发介绍了 DevOps - Build 团队 Gradle Sync 优化框架的实现细节以及在飞书项目中进行 Sync 优化的实战经验。