课程的 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技术的未来规划。
存储与计算资源是数仓建设的基础，也是数仓建设中的重要成本支出。而随着数仓建设规模逐渐扩大、时间跨度逐渐拉长，将不可避免的出现数据表、任务、字段的冗余。为了减轻资源负担，降低数仓维护成本，需要对数仓建设成本进行治理与优化。
自从 2022 年底 OpenAI 推出了 ChatGPT3.5 后，GPT 的活跃用户数快速突破一亿，打破了互联网应用发展的历史记录。ChatGPT是一种基于人工智能技术的聊天机器人，它可以理解人类的自然语言，模拟人类的语言和思维方式，与人类进行自然的对话。GPT 技术的发展，给社会带来了巨大的影响，各行各业都在讨论GPT影响和带来的机会。 微软公司创始人比尔·盖茨在其博客文章《人工智能时代已经开启》中表示，自1980年首次看到图形用户界面（graphical user interface）以来，OpenAI的GPT人工智能模型是他所见过的最具革命性的技术进步。 前端工程师本质上是开发软件 GUI（graphical user interface） 部分，GPT 技术发展使得应用从 GUI 慢慢往 GUI&LanguageUI结合方向发展，对于软件工程在视图层的架构要求更高，帮助产品更加好用和业务上能取到更大的业务价值。在这个充满变化和机会的时代，我们前端开发者如何抓住机会呢？本文从认识 GPT、GPT 集成软件调研和机会等方面分享下自己的看法。
在一年多前，我们对外正式开源了 btrace（AKA RheaTrace），它是基于 Systrace 的高性能 Trace 工具，目前字节跳动已经有接近 10+ 产品团队使用 btrace 做日常性能优化工作。在这一年期间，我们收到很多社区以及公司内部反馈，包括使用体验、性能体验、监控数据等上都收到众多反馈，我们汇总了大家反馈的内容，主要包括以下三类： 使用体验：Windows 有着大量用户群体，但 btrace 1.0 未支持；桌面脚本依赖 Systrace 和 Python 2.7 环境，导致环境搭建十分复杂，此外手机端还依赖外部存储访问权限，在初次使用时很容易导致打断。同时产物体积庞大，网页打开速度很慢。 性能体验：大型应用插桩数量达到百万级别，性能损耗接近 100%，对性能优化工作产生一定困扰。 监控数据：在 Trace 分析过程中，有些信息是缺失的，并不知道耗时原因，比如目前 Trace 中仅包含 synchronized 锁信息，缺少 ReentrantLock 等其他锁信息，同时渲染监控只有部分系统关键路径信息，缺少业务层信息。
