GaussDB（DWS）云原生数仓技术解析：湖仓一体，体验与大数据互联互通【绽放吧！GaussDB(DWS)云原生数仓】
文章目录
- 前言
- 一、关于数据仓库需求场景分类
- 二、数据仓库线下部署场景
- 2.1、线下部署场景介绍及优劣势说明
- 2.2、线下部署场景对应的客户需求
- 三、数据仓库公有云部署场景
- 3.1、公有云部署场景介绍及优劣势说明
- 3.2、公有云部署场景对应的客户需求
- 四、为何重视数据共享（含湖仓一体）？
- 4.1、传统数据共享业务场景
- 4.2、数据共享（含湖仓一体）能力解决掉的问题
- 五、数据仓库技术架构演进
- 5.1、Shared Storage 架构
- 5.2、Shared Nothing 架构
- 5.3、存算分离架构
- 六、GaussDB（DWS）演进历程
- 七、DWS 云原生架构技术解析
- 7.1、极致弹性、数据共享、高灵活度、高性价比
- 7.2、按需弹性实践适应灵活多变的业务需求
- 7.3、湖仓一体，与大数据互联互通
- 7.4、数据生产线与 AI 生产线的高效配合
- 7.5、灵活可配的性能优化选择
- 7.6、提供按需权衡、灵活可配的缓存
- 7.7、深度优化存算分离架构
- 总结
数据仓库是一个用于存储大量结构化和非结构化数据的集中式数据存储区域。它旨在帮助组织更好地理解其数据并支持决策制定过程。数据仓库通常由多个数据源提供数据，并使用 ETL（提取，转换，加载）过程将这些数据集成到一个单独的位置中。数据仓库通常用于支持商业分析、数据挖掘、业务智能和决策制定。
数据仓库的重要性在于它提供了一种将数据从各种来源集成到单个位置的方法。这使得对整个组织的数据进行分析和报告变得更加容易。数据仓库还可以帮助组织更好地了解其数据模型，从而更好地规划未来的IT项目。使用数据仓库可以提高组织的数据质量、数据集成能力和数据分析能力，从而提高组织的效率和决策质量。
我们将数据仓库需求场景分为两类，分别是线下部署场景和公有云场景。
数据仓库的线下部署场景是指将数据仓库部署在本地服务器或数据中心的情况。适用于需要访问敏感数据或需要高度定制化的企业系统。
- 优势：线下部署可以提供更高的安全性和数据隐私保护，因为数据不需要通过互联网传输，而是在公司的内部网络中处理。
- 劣势：通常需要专业的 IT 团队来管理和维护服务器、网络和软件，以确保数据仓库正常运行并满足业务需求。
线下部署场景客户需求，主要集中在以下几点：
- 稳定、隔离。如在金融行业中第一要求就是系统是稳定的，并且负载之间具有比较好的隔离能力，系统之间的影响是比较小的。
- 数据共享（含湖仓一体）。
- 弹性。
数据仓库需求场景的公有云场景是指将数据仓库部署在公有云中的场景。其中，公有云指的是由第三方服务商提供的云计算基础设施，例如亚马逊云服务（AWS）、微软云服务（Azure）、谷歌云平台（GCP）等。
公有云部署场景具备的优势集中在以下几点：
- 弹性伸缩：公有云提供强大的弹性伸缩能力，可以根据实际需求灵活扩充或缩减计算和存储资源，而无需担心硬件设备和系统软件的更新维护问题。
- 高可用性：公有云提供多区域部署，可以做到容灾和数据备份，保证数据的高可用性。
- 管理简单：公有云提供了全套的云端管理服务，包括监控、日志、备份、自动化部署等。这些服务可以降低数据仓库运维的复杂性，提高数据仓库运行效率和稳定性。
- 降低成本：公有云采用按需计费的模式，能够根据实际使用情况灵活调整资源，降低了企业的成本。
公有云部署场景面临的劣势集中在以下几点：
- 安全性问题：部分企业存在数据安全和隐私保护的顾虑，担心采用公有云会导致数据被泄露和攻击等问题。因此，需要严格的数据安全策略和监测手段。
- 可控性问题：公有云中数据仓库的运行状态和系统配置等由云服务商托管，企业并不能完全掌控，因此需要与云服务商进行密切合作。
- 稳定性问题：公有云的稳定性和服务质量会受到云服务商的影响，如果云服务商的服务出现问题，可能会导致数据仓库的运行受到影响。
- 依赖互联网：公有云场景需要依赖互联网，如果网络不稳定或有意外中断，可能会影响数据仓库的使用和管理。
公有云部署场景客户需求，主要集中在以下几点：
- 成本。客户希望成本能够随着业务曲线变化也能动态变化，负载低的时候成本能够降下来，负载高的时候，成本可以做相应的提升，成本能够跟业务量有正比的关系，而不是固定成本，具体如下图所示：
- 灵活、实时弹性。对弹性的要求更加实时，收到系统告警之后能够马上对服务的吞吐或并发做弹性扩容。
- 数据共享（含湖仓一体）。很多客户在建设数据处理技术站的时候会和大数据一起建设，大数据作为数据旅程的一部分，在不同的处理环节使用的是不同组件，既有湖仓一体的诉求，也有本身数仓的数据共享诉求。
业务场景：客户搭建一套系统，上面跑一个业务 1，里面有一些数据。现在客户需要新上一个业务 2，传统做法就是把这个新作业加到这个原来系统 A 上，但是原来这个系统可能撑不住，原因可能是并发数、吞吐，或者其他原因。这个时候我们需要对系统做扩容，但是仅扩容单个集群，节点到一个规模的时候线性比的提升并不明显，尤其是并发很高的时候，单纯的增加节点并不能够很好的解决问题。
传统措施：这个时候我们需要搭建一个系统，用一个新系统服务新业务，新业务可能要访问业务 1 数据，就会把业务 1 的数据复制一份放到这个数据 2，类似于读写分离，但是这样的话会造成以下问题：
- 系统扩展性弱，通过数据 copy 实现数据共享。
- 系统间存在大量的数据冗余，甚至不一致。
- 系统间存在大量的数据传递。
为了规避掉上述问题，我们采用数据共享（含湖仓一体）能力，其具备的优势有以下几点：
- 一份数据支持不同业务访问，数据零 copy。快速、敏捷支持新业务上线。
- 业务之间具备良好的隔离能力，性能稳定。
不同的场景对需求的优先级是不一样的，我们数仓要考虑在面对这两类不同的场景的时候，怎么用一套数仓的价格去解决这个问题，这是在需求场景上我们看到的一些变化。
早期的数仓，就挂了一个共享存储，我们称其为 Shared Storage。
特点：共享存储和状态，计算节点像访问单机一样访问最新的全局数据。
优点：无需数据分片，无需分布式 plan 执行，对业务透明。
缺点：
- 计算节点需要引入协调机制（cache 同步），保证数据的一致性，扩展性有上限。
- 单个 SQL 无法利用所有计算节点的扩展能力
后面又出了这种 Shared Nothing 架构，像 GaussDB 十几年前刚开始做的时候，也是这么一个架构。
特点：一种分布式计算架构，CPU、内存、磁盘等资源都是私有的，整个系统中不存在共享资源，每个节点只处理自己分片的数据，没有单点的竞争。
优点：扩展性好。
缺点：
- 计算存储耦合，需要同时扩容，不够灵活。
- 扩容需要较长的数据重分布时间。
特点：存储类似 Shared Storage，计算类似 Shared Nothing，每个节点只处理自己分片的数据。
优点：
- 计算存储分层扩展，计算节点扩容无需数据重分布，速度快，灵活；存储节点按需扩容，无限容量。
- 计算节点之间无需协调机制，只需保证计算节点只处理自己分片的数据。
我们先回顾一下 DWS 演进历程，具体如下图所示：
GaussDB（DWS）在十年前就开始在做了，当时是针对于线下的这种场景，采用的就是 Shared Nothing 架构，在14年之前主要是做数仓里面比较通用的技术，包括分布式的执行、现代化引擎、列存储机制，后面开始在大行里面做连创，就遇到了更多的产品化的需求，包括这种大集群的通信、负载管理以及怎么跟用户这种大数据的生态做互通等等，再到后面随着市场的推广越来越多，就有更多产品化诉求和企业级特性诉求。在 2020 年的时候开始做 DWS，内部叫 3.0 版本，主要就是一个云原生数仓，也是我们本文将要给大家分享的内容。
三层解耦：
- 管理层，计算层，存储层独立灵活伸缩。
- 计算资源以逻辑集群方式组织。
灵活弹性：
- 分钟级单逻辑集群扩缩容。
- 分钟级快速创建销毁逻辑集群。
- 快速扩缩容，无数据重分布、拷贝。
一数多用：
- 任意逻辑集群均可承载读写负载。
- 多逻辑集群间共享数据，无需拷贝。
- 提供跨逻辑集群建的同时和近实时两种数据共享方式。
按需配置：
- 逻辑集群隔离不同业务。
- 业务承载量/并发量的线性扩展。
- 读写分离、不同负载隔离。
我们把弹性需求可以分成两大类：一类就是较长周期，随着公司业务的增长逐渐增加的；另外一种是短周期的，可能每天都在变，或者是每天的同时间点的业务负载都不一样，像对于这种比较稍微长周期或者稳态一点的业务，可以用这种在单位 vw 内增加计算资源的方式去来承载。
在湖仓一体上进一步增强体验，使用大数据的生态更加简单、维护代价更低，体验横向融合分析。
传统的维护，当外表的数量是一张、两张的时候还比较好维护，当外表有有成千上万张的时候就比较麻烦，你首先要把这些外表都创建出来，其次如果大数据这边把表的结构改了，不管是改了字段的类型或者是新加了字段，外表都需要做同步的维护，维护的代价就会高，而新的湖仓一体就完美解决掉了这个问题。
无缝访问数据湖：
- 对接 Hive Metastore 元数据管理，直接访问数据湖的数据表定义。
- 支持主要数据格式：ORC、Parquet、Hudi、Carbon。
融合查询：
- 混合查询数据湖和仓内的任意数据。
- 查询一步到位输出到仓内/数据湖，无需额外数据中转拷贝。
极致查询性能：
- 使用数仓高质量的查询计划和高效的执行引擎。
- 使用数仓的负载管理手段，精准控制。
AI 有自己的一套系统，即 ModelArts，数据是 DWS，AI 如何访问到 DWS 的数据，DWS 又该如何利用 ModelArts 的模型？主要就是解决这两个问题。数据共享我们可以把数据都放到 obs上去，用开放的格式，这样数据共享的问题就比较好解决；在 AI 模型这方面，我们通过在 DWS 里面写 SQL的形式去使用 ModelArts 的 AI 能力。
数据生产线→AI 生产线：无缝数据通路
- 面向批量生产：通过 OBS 共享开放格式数据。
- 面向快速开发：通过 ConnectorX 等以查询取数的方式嵌入 Python 开发生态，重点是 Pandas。
AI 生产线→数据生产线： AI for Data
- 提供 SQL 语法，在数据分析过程中提供驱动 AI 训练、应用 AI 推理的能力。
- 将推理能力引入分析：直接调用部署的推理服务端点，灵活性好；将模型二进制部署为 UDF，性能好。
在性能方面，存算分离之后关心的就是计算存储，保证性能主要的手段有冷热分区高效缓存、近数据计算和大带宽云存储三个方面，我们来看下图这个效果是非常显著的。
系统会把 obs 上的数据缓存到本地，解决很多性能的问题，缓存现在支持大小可配，想获得更好的性能可以多买一点本地缓存，如果对这个性能没有太高诉求，可以少买，成本完全由自己决定。
无缝配合缓存：
- 热数据优先缓存，使用本地的算子下推能力。
- 冷数据优先下推，使用云存储的近数据计算资源池。
近数据计算：
- 将数据下推到云存储，显著降低数据读取量。
计算和存储分离之后，这种时延天然存在，物理上是不可避免的，在这种时延下，如果不做任何优化，性能肯定会下降，所以在这里做了一个通过并发来换取带宽的手段，虽然单线程作 IO，延迟变高，但是可以开更高的并发的，来把 obs 带宽打满。
- 更低时延：充分利用云存储的带宽优势，弥补其相较传统 MPP 的高延迟劣势。
- 更优资源调度：单查询充分利用资源，为并发查询提供稳定、可预测的性能保证。
- 更灵活配置：多级资源池灵活配置。
- 点赞
- 收藏
- 关注作者
评论（0）