技术永远是在“更新”或“替换”中得到发展。 在大数据行业里，2006 年 Hadoop 的诞生，给我们带来了变革意义的改变，大数据生态组件也开始层出不穷。各种不同体型的企业都喜欢选择开源大数据软件来搭建自己的系统，无论是先前十分繁荣的 Hadoop，还是后来涌现出来的 Kafka、Flink 等，都被广泛地使用着。 十多年来，这些系统经历了多轮技术洗礼，我们也随之需要根据新的技术潮流不断地进行调整甚至做技术转型。以 Hadoop 三大组件来说，计算引擎 MapReduce 基本被 Spark 取代。在数据上云的时代，对象存储也取代了一部分 HDFS 文件系统。近几年，云原生又火了起来，行业里再次开始了对大数据体系的云原生改造，同时 K8s 的流行，也让同为资源管理的 YARN 地位越来越尴尬。 然而，过去的技术体系在很多企业系统里仍发挥着很重要的作用，在技术更新迭代的时候，业务不能随意变动，那么我们在新旧技术共存的条件下，如何发挥新技术的最大潜力？
想要获得一个 A/B 实验系统，需要做些什么事情？火山引擎团队会把这些事情分成四个部分。 首先得有一个可靠的实验系统。其次，通过实验系统采集数据，从而观测用户在不同的策略下的反应。再次，采集到数据之后，借助统计学知识，对各组的结果进行分析，以得到正确的实验结论。最后，通过精细的治理和运维，来保证实验始终正常运行。 本篇内容围绕下面五点展开：A/B 实验系统平台概览、灵活的执行组件、高效的数据建设、科学的统计分析、精细的治理运维。
DataLeap 是火山引擎自研的一站式大数据中台解决方案，集数据集成、开发、运维、治理、资产管理能力于一身的大数据研发治理套件。在平台中，一个核心的功能为任务的调度，会根据任务设置的调度频率（月级，日级，小时级等）运行任务，从而生成对应的实例。 在数仓研发中，不同的表之间会存在依赖关系，而产生表数据的任务实例，也会因此存在依赖关系。只有在上游实例运行成功、下游实例到达设定的运行时间且资源充足的情况下，下游实例才会开始执行。所以，在日常的任务运维中，常常需要分析实例上下游的运行情况，根据具体的情况对实例进行置成功、重跑等操作。 而如何清晰地展示实例之间的关系，帮助用户快速地分析整个链路的运行情况，并完成问题定位和运维操作，则是实例 DAG 需要解决的问题。下面对比下优化前后的效果。
插件的设计能带来许多好处： 1: 它可以极大地提升软件的可扩展性。很多工程工具都提供了插件能力给开发者，借助社区力量基于插件扩展各种原本不具备的能力，从而极大地提升了生命力； 2: 它可以让主体程序和插件代码解耦，保持主体程序的稳定。可以想象如果 webpack 不是通过插件来扩展能力，那当我们需要某个当前版本不具备的能力时，只能不断地升级 webpack，而这种升级则很容易引入不稳定因素。 3: 它可以帮助我们控制主体程序复杂度。借助插件，我们可以很好地把能力分而治之，化整为零，从而有效地控制系统整体的复杂度。 4: 它可以帮助我们控制程序体积，做到按需引用。由于插件是可以独立地动态加载，我们可以针对性地选择我们需要的插件能力。我们也可以设想，VsCode 如果是把各种能力都由自己完成，其软件大小会是怎样的规模（其实也不会是现在的形态了，比如针对各个编程领域提供一个应用包）。
KubeBrain 是字节跳动针对 Kubernetes 元信息存储的使用需求，基于分布式 KV 存储引擎设计并实现的取代 etcd 的元信息存储系统，支撑线上超过 20,000 节点的超大规模 Kubernetes 集群的稳定运行。 项目地址：github.com/kubewharf/kubebrain
Data Catalog 通过汇总技术和业务元数据，解决大数据生产者组织梳理数据、数据消费者找数和理解数的业务场景。本篇内容源自于火山引擎大数据研发治理套件DataLeap中的Data Catalog 功能模块的实践，主要介绍Data Catalog在公有云部署和发布中遇到挑战及解决方案。
Data Catalog 能够帮助大公司更好地梳理和管理自己的资产，是 Data-drvien 公司的重要平台。一个通用的 Data Catalog 平台通常包含元数据管理，搜索，血缘，标签，术语等功能。其中，搜索是 Data Catalog 的入口功能，承担着让用户“找到数”的主要能力。在字节跳动数据中台的 Data Catalog 系统中，每天有 70% 以上的用户会使用搜索功能。
