企业在进行营销推广时，广告投放通常是必备环节之一。为了避免投放“乱烧钱”，在大规模投放前，企业和广告优化师都会希望在多种广告策略中，找准效果更好策略才进行投放。早期这样的方案决策只能通过“拍脑袋”，或者简易的分流投放测试来粗略进行。在火山引擎AB测试推出“广告投放AB实验”后，可逐步支撑企业快速、科学地验证不同投放策略的平均转化成本数据效果，并根据实验报告得到计划中不同素材、不同落地页、不同人群包、不同预算等变量到底哪种更好。 广告投放AB实验背后，所需的数据能力支撑繁琐而复杂，开启广告实验后，如果数据不能够及时准确的送达，会对报告结论造成影响，甚至影响最终决策，而这均依赖于AB实验平台底层的基础投放能力。
预聚合是OLAP系统中常用的一种优化手段，在通过在加载数据时就进行部分聚合计算，生成聚合后的中间表或视图，从而在查询时直接使用这些预先计算好的聚合结果，提高查询性能。 实现这种预聚合方法大多都使用物化视图来实现，本文将为大家分享火山引擎ByteHouse基于ClickHouse物化视图的进阶Projection实现。
在 7 月 21 日至 22 日举行的 ArchSummit 全球架构师峰会（深圳站）及 DataFunCon.数据智能创新与实践大会（北京站）上，来自火山引擎 DataLeap 的三位专家分别就 DataOps、数据治理和指标体系等方向进行了精彩的分享。 本次分享内容皆来自于字节跳动业务实战经验，希望可以帮助企业更高效地管理和处理大量的数据，提高数据资产的价值和利用率，助力企业抓稳数字化机遇，建立数据驱动的决策机制。 以下为嘉宾演讲PPT部分精彩内容，关注字节跳动数据平台微信公众号回复【0721】，或点击文末“阅读原文”，即可下载完整版PPT。
本文为 Apache Hudi 技术社区分享会第十期嘉宾分享文章，主要介绍火山引擎 LAS 团队自研的多场景样本离线存储技术，用于处理机器学习系统的离线数据流。同时，还会为大家揭秘流批一体样本生成的过程，分享对 Hudi 内核所做出的优化和改造，探索其在数据处理领域的实际应用和效果。
火山引擎DataLeap作为一站式数据中台套件，汇集了字节内部多年积累的数据集成、开发、运维、治理、资产、安全等全套数据中台建设的经验，助力企业客户提升数据研发治理效率、降低管理成本。 Data Catalog是一种元数据管理的服务，会收集技术元数据，并在其基础上提供更丰富的业务上下文与语义，通常支持元数据编目、查找、详情浏览等功能。目前Data Catalog作为火山引擎大数据研发治理套件DataLeap产品的核心功能之一，经过多年打磨，服务于字节跳动内部几乎所有核心业务线，解决了数据生产者和消费者对于元数据和资产管理的各项核心需求。 Data Catalog系统的存储层，依赖Apache Atlas，传递依赖JanusGraph。JanusGraph的存储后端，通常是一个Key-Column-Value模型的系统，本文主要讲述了使用MySQL作为JanusGraph存储后端时，在设计上面的思考，以及在实际过程中遇到的一些问题。
在 Web 3D 渲染场景中，使用建模软件构建好的 3D 模型文件，模型的细节越精细对应的文件体积也会越大，考虑到 Web 下网络传输的影响，往往会对 3D 模型文件应用压缩算法以减少文件体积，此时就需要在 Web 端对经过压缩的模型进行快速高效的解码。WebAssembly 在 CPU 计算密集的场景有着更优的性能，同时结合 Web Worker 一起使用的话，还不会阻塞渲染主线程，非常适合用来实现 3D 模型解码的解码器（以下简称 decoder）。 本文将以 glTF 格式的 3D 模型为例，介绍实际业务场景中是如何应用 WebAssembly 来实现 3D 模型的解码。首先，本文将简要介绍保时捷礼物的业务背景和 glTF 格式相关压缩算法；其次，分别介绍基于 WebAssembly 的 Draco 和 Meshopt 两种压缩算法的解码器实现；最后，在保时捷业务场景中尝试应用 glTF 两种压缩算法，并对 glTF 模型的不同压缩率和模型加载耗时进行了对比。
JavaScript 作为解析型脚本语言，它的运行速度，一直是其被诟病的一个点。WebAssembly 技术的出现，且被各主流浏览器所支持，让我们在 Web 应用中，使用新技术，突破 JavaScript 引擎的速度局限，有了新的可能。JavaScript 是动态类型语言，WebAssembly 是静态语言编译的产物，理论上 WebAssembly 的运行速度，能比 JavaScript 快好几倍。在本文中，我们将讨论如何对 Web 前端应用优化，从而提高框架以及业务代码的整体性能。
随着 5G 时代的到来，多媒体音视频、特效在 5G 时代下会迎来新的云端的挑战，同时也会催生更多的跟云端相关的业务场景。因此我们需要规划云端的建设，把音视频和特效在移动端积累的能力和经验复制扩展到云端，在云端全面打磨提升音视频能力，支持公司更多业务创造更大价值。同时随着 WebAssembly 的逐步成熟，也给了我们将编辑 SDK 放到 Web 运行的机会。 本文首先帮大家回顾一下 WebAssembly 的一些基本情况，然后将介绍 Web 视频编辑所依赖的关键特性的情况，以及再迁移过程中我们遇到的问题和解决思路。
目前 PC Web 侧实现直播推流通常基于 WebRTC 技术，视频编码为 H264/VP8 格式，音频编码为 Opus 格式，而通常的下行直播分发协议如 Flv、Hls 等挟带的视频数据编码格式为 H264，音频数据编码格式为 AAC，这中间存在流媒体服务器需要将 Opus 音频转码为 AAC 音频的工作，增加了流媒体服务器转码成本和转码稳定性问题。如果能够在直播推流时直接推送 AAC 音频数据，就可以省去流媒体服务器音频转码部分的开销。为了解决推流 AAC 的问题，我们选择在 Web 侧自己实现推流能力。 推流主要分三部分工作，音视频采集、编码、上行传输。采集借助浏览器暴露的摄像头、麦克风采集 API，视频编码借助 WebCodec API，传输借助 WebSocket、WebTransport API。只有音频编码的工作由于目前 WebCodec 暂不支持对 AAC 音频格式的编码，需要寻找音频编码的替代方案。 音视频编解码工作是 CPU 密集型任务，业界相关方案实现大多基于 C/C++ 语言编写。这其中，FFmpeg 作为多媒体处理领域强大的软件实现，提供了简洁的 API
