众所周知，堆crash dump是最难分析的dump类型之一。此类crash最大的问题在于，造成错误的代码无法在发生堆破坏时被发现。线上采集到的minidump，仅能提供十分有限的信息。当调试工具报告了堆破坏、堆内存访问违例后，即便是有经验的开发人员也会觉得头疼。剪映专业版及其依赖的音视频编辑SDK、特效模块均采用MD的方式链接标准库，这意味着任何一个模块出现了堆损坏都会互相影响。从crash的位置回溯堆破坏的源头，是一个非常有挑战性的工作。剪映业务模块较常见的是Use-after-free，而音视频编辑SDK和特效模块这类底层算法特效模块更多的是Buffer-overflow，不同团队模块间的堆错误互相影响，导致问题难以定位。 GWP-ASan是Google主导开发的用于检测堆内存问题的调试工具。它基于经典的Electric Fence Malloc调试器原理，概率采样内存分配行为，抓取内存问题并生成上传崩溃报告。说到这里，也许你会好奇它和ASan（Address Sanitizer）的区别。
WebAssembly 作为一项新兴的技术，已经发展至 2.0 版本；相较于 1.0 版本，2.0 版本增加了更全面的指令支持和对大容量内存的友好性；同时，向量指令的加入也提高了 WebAssembly 在复杂场景下的性能表现。目前，WebAssembly 已经广泛应用于各种 Web 和非 Web 场景，例如 Web 端的视频渲染、编解码、算法移植，以及非 Web 端的 Serverless、客户端跨平台等领域。 除了广泛的应用场景，WebAssembly 还具有跨平台、高效、安全的优点。它可以在各种计算机架构上运行，并且具有接近原生代码的性能。此外，WebAssembly 的代码可以在沙箱中运行，不会影响主机环境的稳定性和安全性，从而有助于保护用户数据和隐私。 随着 WebAssembly 技术的不断进步，未来还有许多值得期待的方向。例如 WebAssembly 的多线程支持、AI 模型的推理和训练，以及在区块链领域的智能合约编写和执行。这些发展方向有助于进一步提高 WebAssembly 的性能和功能，从而推动 Web 上更多应用场景的发展。
CloudWeGo - Shmipc 是字节跳动服务框架团队研发的高性能进程间通讯库，它基于共享内存构建，具有零拷贝的特点，同时它引入的同步机制具有批量收割 IO 的能力，相对于其他进程间通讯方式能明显提升性能。在字节内部，Shmipc 应用于 Service Mesh 场景下，mesh proxy 进程与业务逻辑进程、与通用 sidecar 进程的通讯， 在大包场景和 IO 密集型场景能够取得显著的性能收益。 开源社区关于这方面的资料不多，Shmipc 的开源希望能为社区贡献一份力量，提供一份参考。本文主要介绍 Shmipc 的一些主要的设计思路以及后续的演进规划。
ByteHouse是火山引擎数智平台旗下云原生数据分析平台，为用户带来极速分析体验，能够支撑实时数据分析和海量离线数据分析；便捷的弹性扩缩容能力，极致的分析性能和丰富的企业级特性，助力客户数字化转型。 本文为字节跳动数据平台超话数据直播回顾文章，全篇将从字节内部发展链路、选择ClickHouse原因，基于ClickHouse的四个维度优化、多场景实践四个版块，介绍ByteHouse基于ClickHouse的实时计算能力升级。
众所周知，堆 crash dump 是最难分析的 dump 类型之一。此类 crash 最大的问题在于，造成错误的代码无法在发生堆破坏时被发现。线上采集到的 minidump，仅能提供十分有限的信息。当调试工具报告了堆破坏、堆内存访问违例后，即便是有经验的开发人员也会觉得头疼。剪映专业版及其依赖的音视频编辑 SDK、特效模块均采用 MD 的方式链接标准库，这意味着任何一个模块出现了堆损坏都会互相影响。从 crash 的位置回溯堆破坏的源头，是一个非常有挑战性的工作。剪映业务模块较常见的是Use-after-free，而音视频编辑 SDK和特效模块这类底层算法特效模块更多的是Buffer-overflow，不同团队模块间的堆错误互相影响，导致问题难以定位。
在前面章节中，我们已经对 WebAssembly 的关键特性、历史演变和核心的应用场景做了详细的介绍；基于 对 WebAssembly 的入门和初步了解，在第二部分的各个章节中，我们会从 WebAssembly 模块入手，和大家一起学习 WebAssembly 基础知识，包括核心规范，核心开发语言和工具链以及常用的执行引擎等相关内容。 本文将从 WebAssembly 模块入手介绍相关基础概念和 W3C 二进制格式核心规范，与此同时，进一步介绍 WebAssembly 的文本格式及语法，并给出一个 WebAssembly 文本 demo；以便读者可以与本文格式的介绍相互印证，进一步加深理解。
2022 年 11 月 ChatGPT 像一股风暴席卷全球。时隔数月，OpenAI 终于在 3 月 1 日正式推出了 ChatGPT 的开放 API。这意味着，我们通过简单的 API 调用，就可以与 ChatGPT 进行对话。可以预见的是像自来水一样使用 AI 的时代已经到来，我们可以随时随地使用它，而不需要关心算法实现细节。 值得注意的是在此之前有大量的第三方平台号称调用的是 ChatGPT 的 API，实际多数为基于 GPT-3 的“自动补齐” API，其能力远不可与 ChatGPT 相媲美，而这一次提供的则是官方的基于聊天（Chat）消息的 API。 本文将通过一个简单的命令行翻译程序，来展示如何使用 ChatGPT API。 你以为 API 调用工程就是本文的全部内容吗？不，更重要的是教会大家如何通过“Prompt Engineering”（即所谓“提示工程”学）将聊天型 AIGC 转换为特定领域的生产力。
首先介绍一下字节内部数据血缘遇到的挑战。 随着公司业务扩张、用户数量持续增长以及数仓建设不断完善，元数据种类和数量也经历了非线性增长，并在此期间涌现出一些问题。 第一，扩展性。好的扩展性可以在面对新型元数据血缘时保证快速接入和迭代，而扩展性不佳则会导致在业务变化时需要不停地重构来适应业务，对业务造成很多影响。 第二，性能。一个模型本身的插入和更新效率会直接影响数据的导入导出的流程，这些都会带来更直观的业务上的感受，所以需要考虑如何保证环节高效性。 第三，时效性。很多应用场景对正确率格外敏感，如果血缘数据有延迟，其实就等于血缘的不准确，会对业务造成影响。 最后，赋能业务。技术服务于业务，业务增长会帮助技术升级迭代，技术创新也会促进业务发展。在字节内部，我们会根据业务特点，考虑业务需要，将技术成本与业务收益做平衡，最终做出数据模型决策。总而言之，数据模型没有完美的方案，只有最适合企业自身业务、适合当前阶段的数据血缘方案。
在组件化的浪潮下，公司引入多仓开发对工程架构进行解耦、跨业务技术能力复用，并辅以组件(混合)二进制化进行编译提速。不过随着工程规模增长、业务复杂度提升，多仓二进制的弊端日益凸显： 合码效率低下：多仓的引入使开发流程变复杂，最有代表性的合码环节一次合码涉及到主仓和多个组件，每个组件要跑 Pipeline 流程进行版本发布。因涉及到组件发布，从而引入了 MR 锁，进而导致吞吐量有限。如果某个组件失败，那么 MR 需要重新跑一遍流程。这种模式提升了 CI 复杂度，降低了合码效率（封板排队时间可达 6h+） 依赖管理衍生问题：稳定性差，多仓使环境依赖度变高，稳定性变成多个仓库稳定性的乘积。即使每个仓库成功率是 99.9%，每次 install 成功的概率也仅有 74%；版本溯源性差，项目通过依赖动态决议生成，无法做到 single source of truth。 代码的可视性和可控性降低：跨组件重构困难，全量静态检测无从入手，并且很难统一架构规范；本地开发体验差，工程代码可信度低，无法直接对代码进行开发调试，本地开发需要更多的工具和流程来保证代码的可视性和可控性。
