抖音集团也在用的数仓「降本」利器
2024-11-5 16:30:0 Author: mp.weixin.qq.com(查看原文) 阅读量:2 收藏

导读 随着数据量的爆炸性增长，现代企业在数据存储、处理与分析上面临巨大挑战。在 IT 架构中，数据仓库承担着企业中关键的数据存储和分析任务，如果不能高效运作，必将导致成本飙升和决策效率低下。因此数据仓库的降本增效是企业IT部门持续的命题。

作为面向实时数据处理的工具，OLAP（联机分析处理）系统能帮助企业充分挖掘数据价值、辅助决策。然而，OLAP 在追求高效数据分析的同时，往往难以平衡成本与效率矛盾。
快节奏的商业环境要求 OLAP 系统在保证数据准确性的前提下，尽可能缩短数据处理和分析的时间。但高效的数据处理往往伴随着更复杂的系统架构和更高的资源消耗，企业需要投入高昂的计算资源、服务器、存储资源等硬件成本以及大量算法优化、运维、迁移等软性成本。
主要内容包括以下几个部分：

1. 问题与挑战

2. 解决方案

3. 架构红利

4. 技术红利

5. 生态红利

6. 融合红利

7. 案例实践

8. 结语

01

问题与挑战

企业使用一款数据仓库产品，成本项可以区分显性成本与隐性成本：

1. 显性成本挑战

  • 硬件成本：代表了部署数据仓库软件的所需的硬件成本，包括计算资源成本（CPU）与存储资源成本（磁盘、存储集群）。毫无疑问数据仓库涉及 TB 甚至 PB 级数据的存储与分析，对硬件的要求颇高。
  • 性能成本：单位能效不高，导致在完成任务或处理数据时，需要配备更多的资源以弥补这一不足。一方面，在计算能效上，需要增加更多的高性能计算单元或优化现有的计算能力，以确保在合理的时间内完成复杂的计算任务，避免处理速度的滞后；另一方面在存储能效上，需要部署更大容量的存储设备以应对日益增长的数据量，同时减少能耗，提高数据存储和检索的效率。

2. 隐性成本挑战

  • 运维成本：代表了运维数据仓库的人力与时间成本。
    数据仓库作为极其复杂的软件产品，对运维人员的专业要求和精力消耗本身极高。如果在数据系统中运行多款组件，如 ClickHouse、Elasticsearch、GreenPlum... 则会让复杂性指数级增加，运维人员的技能要求也指数级增加。
  • 迁移成本：代表了从旧的数据仓库或分析型数据库迁移到 ByteHouse 的人力与时间成本；
    数据仓库之前的语法，架构差异通常极大，搬迁数据难于搬家，带来了极高的替换成本。

1. 关于 ByteHouse

ByteHouse 是火山引擎数智平台VeDI旗下的一款云原生数仓产品，以 ClickHouse 技术路线为基础，从 2017 年内部立项开始，截止到 2022 年 3 月，ByteHouse 节点总数已经达到了 18,000，最大的行为分析集群超过了 2,400 个节点，数据量超过 700PB。
ByteHouse 在架构上遵循新一代云原生理念，实现了容器化、存储计算分离、多租户管理和读写分离等功能，同时支撑实时数据分析和海量数据离线分析，尤其对高吞吐、高并发、复杂查询等多种实时数据分析场景进行优化，能为用户提供极速分析体验。
ByteHouse 具备存储、计算分离，高弹性扩展的特点，其计算层采用 Shared-nothing 架构，存储层采用 Shared-everything 架构，能更好地支持计算和存储层的水平扩展。基于 ByteHouse 高性能的实时数据分析决策能力，数据从导入到分析决策仅需几秒，99% 的查询都能得到秒级保障。除了高可用的基础能力，ByteHouse 还提供免托管运维服务，包括丰富的集群管理工具、全面的系统监控能力，帮助企业轻松了解业务状态，让故障排查与问题诊断变得简单。

2. 四招直击“降本之痛”

云原生数据仓库 ByteHouse 在架构、技术、生态、融合四个方面上均能带来红利，能显著地降低显性成本与隐性成本。通过引入像 ByteHouse 这样“能省钱”的云原生数据库，企业能够在支持大规模数据查询的同时，有效控制硬件成本、迁移成本与运维成本的投入，提升系统性能，实现数据驱动的业务增长。
  • 架构红利：ByteHouse 采用独特的存算分离架构，实现了资源的高效利用和灵活扩展。这一架构解决了传统数据仓库在计算和存储资源上的紧耦合问题，使企业能够根据实际需求独立扩展计算或存储资源，从而避免了资源浪费。
  • 技术红利：在计算层面，ByteHouse 自研的查询优化器提升了多表查询性能，点查优化技术则提高了系统的并发性能。在存储层面，通过共享对象存储、存储分级、数据压缩等极致优化，ByteHouse 进一步降低了存储成本。
  • 生态红利：ByteHouse 支持丰富的上下游生态，包括数据导入、加工工具、调度工具、BI 工具以及语言 Driver 和开发工具等。同时，与 ClickHouse、MySQL 生态完全兼容，降低了用户数据迁移的门槛和额外成本。
  • 融合红利：ByteHouse 融合了实时查询、聚合查询、人群圈选、文本检索等各类场景，简化了企业的技术栈管理，降低了运维成本。此外，在湖仓融合方面，ByteHouse 支持业界常见数据湖的外表连接方式，能实现多种外表和 ByteHouse 内表的联邦查询，进一步提高了分析效率并降低了数据冗余存储和转换成本。
首先，ByteHouse 支持存算分离架构，也是让 ByteHouse“更省钱”的重要原因，存算分离通过更高效的资源分配和灵活的扩展方式，帮助企业在数据管理和计算任务中有效控制资源成本并提升效率。

1. 资源利用率的瓶颈

传统的数据仓库通常使用无共享（shared-nothing）的架构，使得计算资源和存储资源是紧耦合的，因此集群时计算和存储资源的配比和容量就已经固定，无法支持二者独立扩缩容。这就意味着计算与存储必有一项存在资源浪费情况。
例如，当业务不需要太多计算资源，但存储的数据量激增，也需要新购大量服务器；另一些情况下，一些集群的存储资源冗余，但 CPU 利用率很高，用户的查询体验差；且上述两种情况无法共享 CPU 与存储资源，结果就是资源成倍浪费。
同时，传统的架构面对计算资源高峰低谷，比如例如早上查询业务高峰期，夜间ETL任务高峰期，只能通过生硬的混合部署方式来应对；这种方式不够灵活，同时也可能会发生夜晚ETL任务未完成，影响上午业务的情况，从而导致连环影响。
正是基于上述痛点，ByteHouse 研发了存算分离的云原生新架构。
计算和存储分离架构
如上图所示，计算节点（VW）与数据存储（Data Storage）是隔离的。从计算节点的角度来看，他们将看到一个全局共享的数据池，即数据存储层。这意味着该池中的所有数据都可以跨所有计算资源共享。
采用这种存算分离架构架构具有三大优势：
  • 灵活的伸缩能力，因为计算资源和存储是分离的，它们可以根据需求，对计算或存储资源独立扩展。
  • 无尽的可扩展性。由于数据是在存储层中共享的，理论上可以横向扩展以利用尽可能多的计算资源。
  • 对于集群管理者来说更加友好，因为他们不需要担心数据一致性、数据副本和数据收费问题；所有这些都可以委托给云服务提供的数据存储层来实现，如对象存储或 HDFS。

2. 基于存算分离的关键特性

1. 计算隔离，按需购买

弹性策略应对多样业务场景：当您拥有多个计算组资源，每个计算组资源应对不同业务；当工作负载各不相同时，用户可以根据业务场景针对不同的计算组设置不同的策略；

2. 弹性计费，自动启停

ByteHouse 计算组自动启停策略，帮助用户节省 ～20%+ 成本：当 VW 空闲超过 5 分钟时，自动启停 会自动关闭集群，VW 在关闭期间不会产生任何费用。

3. 按需扩展，无损弹性

弹性扩展，灵活自动：根据时间，资源负载等条件进行扩容/缩容配置；减轻手动管理的负担，提升资源利用率。
节省成本：根据实际业务需求灵活调整计算资源规模，无需提前购买全部资源。

存算分离决定了整体架构的高效能，低成本。
但深入“存”和“算”的领域，ByteHouse 仍然有非常多的极致的技术优化，让整个数据仓库“省上加省”。

1. 计算技术优势

根据 ByteHouse 性能白皮书的标准数据集性能参考，ByteHouse 性能比开源的 ClickHouse 强 40%-50%。性能提升意味着在相同的查询单位算力下，ByteHouse 需要的算节点数量的减少，因此能带来成本的等比例降低。
（如上图，开源 ClickHouse 在 TPC-DS 99 条查询中只能跑出 28 条 SQL，而 ByteHouse 能跑出 99 条，同时 ByteHouse 每一条都更快）
假设在当前业务需求下，ClickHouse 需要 100 个节点来处理每日的数据量。使用 ByteHouse 后，由于性能的提升，可能只需要 60-70 个节点。
那为何 ByteHouse 的性能如此强劲？有以下两个关键技术点：

（1）多表查询性能优化

首先，ByteHouse 自研了查询优化器，使得多表查询性能出众。
ByteHouse 的查询优化器同时基于 CBO（基于代价优化） 与 RBO（基于规则优化）：
  • 语法支持：ClickHouse/ANSI/MySQL；
  • Join 优化：Join-Reorder，bucket join，Runtime filter ；
  • Filter 下推：多层嵌套下推。支持下推 join 子查询；
  • 分布式计划优化：将这单机版计划和分布式计划两个阶段融合在一起，在整个 CBO 寻求最优解的过程中寻求最优解。

（2）点查性能优化

其次，ByteHouse 支持多种点查优化技术，提升了整体系统的并发性能：
  • 支持预先注册查询模板，避免对模版 sql 的分析和优化的开销；
  • 支持使用 unique 引擎生成的内存中唯一键索引；
  • 优化 TopN 类型 SQL 模式（select column from {} where condition order by column limit 10; ），使数据读取量更少，查询更快：

2. 存储技术优势

（1）对象存储，优化成本

ByteHouse 的存储层基于共享对象存储，存储成本下降 10 倍；
资源按需计费，存储资源无限容量且弹性扩缩。

（2）存储分级，温冷隔离

温数据使用对象存储标准规格存储，冷数据使用对象存储深度归档规格存储；
温冷分层，存储成本进一步降低 2~5 倍；

（3）数据压缩，极致优化

ByteHouse 支持 LZ4、ZSTD 等高效压缩算法，基于压缩算法下的存储成本再次降低75%+；
行业上有这样的说法，“客户价值=新产品价值-老产品价值-迁移成本”。可见迁移成本对于产品选择是如此的重要，数据仓库这类重型产品，不论产品的架构、技术如何优秀，迁移成本是否足够低，仍然是能否足够“省钱”的核心考量。
ByteHouse 搬迁 ClickHouse 生态、MySQL 生态都非常丝滑，将迁移成本降到最低。同时 ByteHouse 本身上下游生态丰富，易于集成进现有的生产系统。

1. 多元化生态

ByteHouse 支持丰富的上下游生态，包含各类数据导入加工工具，如 Flink，Spark，DataX，DataSail；各类调度工具，如 Airflow，DophinScheduler，各类 BI 工具，如 Superset，Tableau，FineBI，DataWind，各语言 Driver，各类开发工具等等。方便集成进每一个现有系统。

2. ClickHouse 生态兼容

ByteHouse 与 ClickHouse 23.3 主流的版本的语法、函数、客户端、驱动均兼容，并且支持 ClickHouse->ByteHouse 的迁移工具，替换成本极低；
有诸多客户通过 ByteHouse 大规模替换了开源产品。例如在某头部股份制银行，已通过工具替换了超过 200 个节点的 ClickHouse。

3. MySQL 生态兼容

MySQL 是市面上分析型数据库的广泛兼容的一种语法之一。ByteHouse 原生兼容各类 SQL 语法，也自研支持了 90% 的 MySQL 语法，因此，从 MySQL 生态的数据库、数据仓库搬栈到 ByteHouse，现成 SQL 的改造量少，体验丝滑；
同时，ByteHouse 支持 Zero-ETL 的能力，可以将 MySQL 生产库的数据通过 Binlog 实时同步到 ByteHouse，整体数据延迟在分钟级别，实现 AP-TP 的一体化。
分析型数据库有一个老生常谈的问题：
各类技术栈五花八门，各有所长，如 ClickHouse 善于宽表查询，HBase 善于点查，Kylin 善于汇聚指标，ES 善于解决文本分析，还有 Presto，SparkSQL，Impala 等各种用于分析的组件。
为了解决多样的分析问题，从而选择多样的底层技术栈，进而导致的维护成本激增。
ByteHouse 的能力全面，少有短板；因此，可以作为一个 All in One 的大一统云原生数仓，融合各类使用场景。

1. 多技术栈融合

字节跳动在许多年前就遇到了上述问题。当时面对上亿的行为日志分析，业务提出了实时数据、离线数据、明细查询等业务需求，最初的解决方案是采用了 Druid，Apache Kylin，SparkSQL，Redis 分门别类解决各个问题，但带来了各类技术栈的学习成本，维护数据一致性的成本，另外部分技术栈如 Apache Kylin，SparkSQL 有数据膨胀问题，资源成本本身就很高。
如今，ByteHouse 的查询分析能力已经覆盖实时查询，聚合查询，人群圈选，文本检索，向量检索，地理检索等，且多场景下都比开源更快。为多种不同业务场景提供了一致的使用体验。

2. 统一运维

融合技术栈后，不仅意味着丰富的场景下，只需要运维 ByteHouse 一种技术栈，那也只需要学习一套知识体系，一种优化方法，一套排障策略。
同时，ByteHouse 提供完善的自动化与可视化运维能力，比如大查询诊断，集群健康仪表盘，Schema 智能推荐工具，自动化扩容工具等，进一步降低运维成本。这就意味着在管理数据库集群时，不再需要专门的 DBA 团队来深入理解开源产品的原理，才能用好 ByteHouse。
对于 ByteHouse 的使用者而言，ByteHouse 能通过完善的产品运维体系，专家团队持续提供专业的产品运维建议，能大幅降低客户的人力成本。

3. 湖仓融合

Databricks 等技术公司于 2017 年首次提出了“湖仓一体”的概念，并在之后逐渐得到广泛接受。湖仓一体架构的目标是将数据湖的灵活存储与数据仓库的高效查询和管理功能结合起来，提供一种统一的架构，既能支持大规模数据存储，也能支持高性能数据分析。
湖仓一体架构不仅能提高分析效率，减少多分数据带来的不一致问题。同时也能够减少数据的冗余存储和转换成本，还可以降低企业维护多个系统的运维成本。
ByteHouse 也大力投入了湖仓一体，首先 ByteHouse 支持业界常见数据湖的外表连接方式，包括 Hive，Hudi，Paimon，Iceberg（Q4），实现多种外表和 ByteHouse 内表的联邦查询；
其次，面对外表分析性能有限的问题，ByteHouse 也支持 Zero-ETL 技术，即将数据湖中的数据通过物化视图，自动同步到数仓中，实现透明加速。由优化器来辨识直接查询外表，还是查询仓内已经落地的内表数据，这样更增进了湖仓查询体验的一致性。
湖仓融合也可以认为是 ByteHouse 存算分离架构的延续和扩展，不仅延续了存算分离在弹性和成本方面的优势，还在统一数据处理和扩展性方面做出了进一步的提升，成为现代数据处理架构中重要的一环。

1. 抖音集团广告集群上云业务：QPS 提升 35%，成本降低 60%

  • 业务背景：
抖音集团原先采用物理机作为其内部基础设施，具有低软件冗余的优势。然而，在构建上层 ByteHouse 系统时，为了满足数据高可用性的需求，需要独立考虑并实施数据副本策略，这直接导致了存储资源的双倍使用。面对这一挑战，抖音集团决定采用存算分离的架构进行优化，并随后决定将其业务系统上云。
  • 解决方案：
上云后，抖音集团基于 ByteHouse 对象存储作为底层存储解决方案。对象存储本身具备高可用性和数据冗余特性，即底层自动存储三份数据副本，以确保数据的持久性和可靠性。这一特性使得上层软件层无需再额外配置数据副本，从而简化了系统架构，减少了分片数和副本数。此外，尽管云上的虚拟机相对于物理机在单机成本（TCO）上可能略高，但云环境的弹性扩展、按需付费以及运维简化等优势为整体成本节约提供了可能。
  • 最终效果：
通过 ByteHouse 存算分离架构和采用对象存储，抖音集团最终将整体成本降低了 60%。此外，优化后的架构还提高了系统的灵活性和可扩展性，让业务 QPS 提升了 35%。

2. 抖音集团行为分析业务：仅需运维 1 套系统，100T 数据查询只要 5 秒

  • 业务背景：
在当前的数据生态中，存在多种开源数据解决方案，如 ClickHouse、Doris、Apache Kylin 等，各自擅长不同的分析场景。这种多样性也带来了“烟囱林立”的问题，即每个解决方案都像一座独立的烟囱，各自为政，缺乏统一的管理和整合。这导致使用者需要熟悉多种不同的 SQL 语法和技术栈，而运维团队则面临更大的挑战，他们需要掌握多种技术栈的性能优化和问题排查方法。
在抖音集团内部，通常会用行为分析来支持其业务决策，包括用户行为转换分析、行为流图分析等，这些分析需要处理大量的实时和离线数据。然而，由于之前使用了多种不同的开源架构来解决这些问题，如 Druid 用于实时分析、Apache Kylin、Spark SQL 用于离线分析、Hbase 则用于明细查询。这些架构不仅存在各自的瓶颈，无法全面满足需求，且整体运维开销巨大。
  • 解决方案：
迁移到 ByteHouse 之后，由于 ByteHouse 能支持实时数据消费，并具备强大的查询能力，同时支持多个不同的查询维度，最多能达到 1000 列，大大超过了之前使用的任何单一架构。
此外，ByteHouse 还提供了许多工具来帮助运维团队进行监控、集群管理、SQL 优化等。这些工具使得运维团队能够更高效地管理大量的集群和服务器，同时降低了对人力投入的需求。
  • 最终效果：
首先，ByteHouse 在性能方面表现出色，在 100TB 级别的数据量基础上，90% 的查询都能在 5 秒钟左右完成。
其次，迁移到 ByteHouse 后，抖音集团将原本的 4 套系统整合为 1 套系统，大大降低了运维团队的工作量和复杂度。运维团队不再需要熟悉多种不同的技术栈和 SQL 语法，只需要掌握 ByteHouse 即可，提高运维效率，降低运维成本。
最后，ByteHouse 提供的工具使得运维团队能够更高效管理大量的集群和服务器。在抖音集团内部，SRE 团队只有 5 个人，但共同管理了 400 个集群和 18000 台服务器，大大提升人效。

3. 某头部游戏企业迁移案例：QPS 提升 200%，成本降低 30%

  • 业务背景：
某头部游戏厂商原先使用其他云服务商的数据分析产品，但在面临业务增长和数据分析需求提升的背景下，无法满足性能和成本的需求，因而决定迁移到火山引擎 ByteHouse。
  • 解决方案：
迁移前，该头部游戏厂商在云平台上部署了 896 个 CPU core，并发峰值仅能达到 15 万。迁移至火山引擎后，该游戏厂商采用了更为高效和灵活的 ByteHouse 解决方案，得益于架构优化和高效处理能力，仅需 640 个 CPU 核心就能实现更高的并发处理能力，峰值并发量达到了 30 万。
此外，基于 ByteHouse 弹性伸缩能力，在寒暑假等高峰期，该头部游戏厂商可以轻松扩容到 640 核以满足业务需求；而在非高峰期，则可以缩容到 320 核，以维持与原云平台相同的 15 万并发峰值，同时降低成本。
  • 最终效果：
通过迁移到火山引擎 ByteHouse，该游戏厂商不仅实现了成本的降低，还显著提升了数据处理性能。这种弹性使用的方式不仅满足了业务高峰期的需求，还在非高峰期有效节约了资源成本，在服务器核数减少 30% 情况下，并发性能提升 2 倍。
ByteHouse 通过独特的存算分离架构、自研的查询优化器以及存储层面的极致优化，为企业带来了显著的“架构红利”和“技术红利”。这些红利不仅体现在资源成本的大幅降低上，更为企业提升了数据处理和分析效率。同时，ByteHouse 丰富的生态兼容性和强大的“融合红利”，进一步简化了企业的技术栈管理，降低了运维成本，并为企业提供了更加丰富和一体化的使用体验。
未来，ByteHouse 将继续聚焦降本增效，帮助更多企业加速数字化转型，实现数据驱动下的业务增长。
点击阅读原文，领取《云原生数据仓库ByteHouse性能白皮书（企业版）》

文章来源: https://mp.weixin.qq.com/s?__biz=MzI1MzYzMjE0MQ==&mid=2247511128&idx=1&sn=f464f7cda3db24ad9af5a938308beb3e&chksm=e9d367badea4eeac650775bcb03cdf27e8b0148be6d6bd249d5c237f562e3bcfd55dcae1f350&scene=58&subscene=0#rd
如有侵权请联系:admin#unsafe.sh