近年来，无论是 Serverless 还是 WebAssembly，都越来越受到开发者的广泛关注，作为字节跳动内部的函数计算平台，ByteFaaS 在 WebAssembly 方向上也有着不少的探索和实践。我们利用 WebAssembly 技术构建出了极致轻量化的函数运行时，并辅以全新设计的精简架构，打造出了云边一体的 Serverless 解决方案，拓展了 FaaS 的边界和应用场景，为业务带去了更多的可能。 本文将先带领大家认识 ByteFaaS 平台，分别介绍经典 FaaS 和 FaaS Worker（轻量级函数）方向。随后通过 WebAssembly 运行时、精简架构、开发者支持三个方面，详细介绍 FaaS Worker 的设计与实现。最后在文章结尾，会对 WebAssembly 函数能够为用户所带来的收益进行大致总结。
在 WebAssembly 社区蓬勃发展的当下，或出于对 JavaScript 等动态语言面对计算密集型任务时改善性能的愿望（如 Ammo.js），或源自将桌面表现出色的软件搬上 Web 环境的想法（如 AutoCAD），或希望在服务端利用沙箱来尽可能保证安全（如 Shopify-Serverless），越来越多的开发者选择 WebAssembly 技术。 而对于一项技术而言，围绕这项技术的开发工具矩阵是否完备，是否足够强大和易用，以及给开发者们带来的体验好坏，则是决定开发者们在尝试之后能否成为拥趸的关键因素。通常来说，一段代码的生命周期，包括编写、测试、交付与部署、上线生效、问题定位与修复等环节。在问题出现之后，对代码的源码调试（Source Code Debugging）往往是定位问题最高效的手段。提供高效的调试工具，帮助开发者迅速解决问题，是助推 WebAssembly 技术社区发展壮大的一个重要手段。 在本文中，我们将主要围绕 WebAssembly 的源码调试，阐述若干相关的问题。
课程的 WebAssembly 工作原理一章已经详细介绍了基于栈结构的指令执行原理和过程，然而，了解 WebAssembly 原理最有效的方式仍然是自己动手实现一个执行引擎；本文将从零开始实现一个简单的 WebAssembly 解释器 WAInterp (WebAssembly Interpreter)，通过这一过程来进一步掌握和实践 WebAssembly 虚拟机技术。
目前字节 Android 的一些超大型项目均从原来的多仓二进制的研发模式切换到了 Monorepo 全源码，并在研发效能方面取得了较大的收益。关于 Monorepo 全源码模式下的一些技术挑战及解决方案后续会有文章单独阐述。在全源码改造的过程中，作为 build 方向的基建团队，我们也不断克服了很多 Gradle 生态的问题与挑战，对构建系统方面有了更进一步的理解。 提到超大型仓库的 Monorepo，就不得不提到 Bazel 构建系统。Google 内部使用 Bazel 作为超大仓（TB 级别）的构建系统，足以证明 Bazel 构建系统优异的性能表现。目前字节内服务端、iOS 端均采用 Bazel 作为构建系统来演进 Monorepo，业界关于 Bazel 的原理文章也很多，但大部分都围绕在工程改造方面或者在单一阐述 Bazel 的设计。
火山引擎云原生数据仓库ByteHouse与Apache Airflow强强结合，为管理和执行数据流程提供了强大而高效的解决方案。本文将带来ByteHouse与Apache Airflow结合使用的主要优势和特点，展示如何简化数据工作流程，并推动业务成功。
Kelemetry是字节跳动开发的用于Kubernetes控制平面的追踪系统，它从全局视角串联起多个 Kubernetes 组件的行为，追踪单个 Kubernetes 对象的完整生命周期以及不同对象之间的相互影响。通过可视化 K8s 系统内的事件链路，它使得 Kubernetes 系统更容易观测、更容易理解、更容易 Debug。
大模型离线推理（Batch 推理）是指在具有数十亿至数千亿参数的大规模模型上进行分布式计算推理的过程，具有如下特点： 一次对一批数据进行推理，数据量通常是海量的，所以计算过程通常是离线计算； 推理作业执行过程一般同时包含数据处理及模型推理； 作业规模通常较大，采用分布式计算，消耗大量计算资源； 相比于在线推理，离线推理对延迟的要求并不高，主要关注吞吐和资源利用率。
本文为火山引擎湖仓一体分析服务LAS嘉宾分享文章，文章会为大家讲解字节跳动在Spark技术上的实践——LAS Spark的基本原理，分析该技术相较于社区版本如何实现性能更高、功能更多，为大家揭秘该技术做到极致优化的内幕，同时，还会为大家带来团队关于LAS Spark技术的未来规划。
存储与计算资源是数仓建设的基础，也是数仓建设中的重要成本支出。而随着数仓建设规模逐渐扩大、时间跨度逐渐拉长，将不可避免的出现数据表、任务、字段的冗余。为了减轻资源负担，降低数仓维护成本，需要对数仓建设成本进行治理与优化。
