构建数据平台架构指导原则与平台核心组件说明

文章目录

- 前言
- 什么是数据架构？
- 数据架构如何帮助构建数据平台？
- 数据平台核心组件
- - 数据源系统
  - 数据加载
  - 数据存储
  - 数据处理和转换
  - 提供使用数据的方式
  - 公共服务

前言

湖仓一体是最近几年非常流行的现代大数据架构，目前它已经成为设计数据平台架构的首要选择。

在本文中，我将介绍与数据架构、数据平台及其核心组件相关的基本概念，以及数据架构是如何帮助构建数据平台的。然后，我将解释为什么需要像 Lakehouse 这样的新架构模式、Lakehouse 基础知识、其特征以及使用 Lakehouse 架构实现数据平台的好处。

数据平台是使用所选技术堆栈实现数据架构的最终结果，是定义我们要构建的系统的蓝图。数据架构定义了核心组件、这些组件之间的相互依赖关系、基本设计原则以及实现数据平台所需的流程。

什么是数据架构？

要理解数据架构，请考虑下现实世界中的类比：商业建筑工地（如任何购物中心或大型住宅区）。

商业地产需要坚固的建筑、创新的设计、经验丰富的建筑师和大批建筑工人。架构起着最关键的作用，确保建筑能够承受所有天气条件，帮助人们轻松进入和穿过各个楼层，并在紧急情况下快速疏散。此类架构基于某些指导原则，这些指导原则定义了构建块的核心设计和布局。无论是建造住宅区、商业区还是体育场馆，基本支柱和核心设计原则都将保持不变。然而，设计模式、内饰、美学和其他符合用户需求的功能会有所不同。

数据架构与任何建筑工地的设计架构一样，在决定平台的用户适应性方面发挥着重要作用。以下部分将介绍数据架构在实现数据平台的整个过程中的重要性。

数据架构如何帮助构建数据平台？

数据平台的架构设计可能是项目最关键的阶段，通常会影响平台用户的使用性、可扩展性、合规性和安全性等关键成果。它可以帮助我们定义构建平台所需的基本内容，以下是这些基本内容的说明：

定义核心组件
核心组件帮助执行日常数据特定活动，例如数据加载、存储、管理、交付以及将其提供给消费者。数据架构可帮助我们定义这些核心组件来构建数据平台，这些核心组件将在下一篇中详细讨论。

定义组件相互依赖关系和数据流
定义核心组件后，还需要确定它们如何交互。数据架构定义了这些依赖关系，并帮助我们可视化数据在生产者和消费者之间的流动方式。它可以帮助我们确定在这些组件之间移动数据时可能面临的任何特定限制或集成挑战。

定义指导原则
作为架构设计过程的一部分，我们还定义了实施平台的指导原则。这有助于使用该平台的各个数据团队之间建立共识，确保每个人都遵循相同的设计方法、通用标准和可重用框架来实施优化、高效和可靠的解决方案。

指导原则可以应用于各种组件，并根据数据架构的功能和限制来决定。例如，如果架构使用不同价位的多个存储层，则应该根据存储价位定义存储冷热数据的指导原则，以优化总体成本。

定义技术栈
该架构蓝图还提供了核心组件的技术覆盖，有助于决定实现平台的技术堆栈。在构建平台时，最终确定所有底层技术可能具有挑战性，因为需要对限制和优势进行详细研究以及概念验证 (PoC)，才能最终确定这些技术。数据架构有助于定义做出这些技术选择的关键考虑因素，并定义执行任何 PoC 活动的成功因素。

与总体愿景和数据策略保持一致
最后，也是最重要的，数据架构可以帮助我们与团队的总体愿景和公司定义的数据策略保持一致，从而通过相应地实施数据平台来实现业务目标。

例如，数据治理是任何公司的数据战略不可或缺的一部分，数据架构定义了元数据存储库、数据catalog、访问控制和数据共享原则等组件，以确保数据治理是每个流程的核心，并且平台与整体数据策略保持一致。

说明
数据治理是一个由各种标准、规则和政策组成的保护机制，以确保所有数据流程都遵循正确的方法指导，以确保和提高合规性、数据质量、数据可信度及其价值。
公司应在所有数据管理流程中遵循数据治理策略，以维持消费者对数据的信任并始终合规。数据治理有助于更好地控制数据、轻松发现数据并与消费者安全地共享数据。

了解了数据架构及其重要性后，现在是讨论数据平台核心组件的时候了。

数据平台核心组件

基于数据架构蓝图实现数据平台的核心组件如下图所示：

数据源系统

数据源系统向数据平台提供可用于分析、报表 (BI) 和机器学习 (ML) 用例的数据。这些来源包括公司运营的系统、后端 OLTP 应用程序、物联网设备、点击事件和社交媒体数据源。

内部或外部源系统

内部源是属于公司的一部分并生成内部数据的源应用程序。例如，内部 CRM 系统、事务数据库、机器生成的日志等。
数据平台通常需要来自外部系统的数据来增强其内部数据。比如说使用包括汇率、天气信息、市场研究等外部数据，这些数据有助于增强内部数据，以提供更好的分析能力。

批处理、近实时或流式系统

直到几十年前，大多数源系统只能发送批量数据。他们通常会在一天结束时以每日批处理的方式发送数据。随着对更接近实时的数据分析的需求不断增加，源系统开始以接近实时的方式发送数据。这些系统现在可以以固定间隔（短至几分钟）将数据共享为多个较小的微批次。物联网设备、社交媒体源和点击流等来源以连续流的形式发送数据，应实时加载和处理这些数据，以获得该数据的最大价值。

结构化、半结构化和非结构化数据

传统上，源系统仅生成表或固定结构化文件中的结构化数据。随着数据交换格式的进步，越来越多地采用 XML 和 JSON 文件形式的半结构化数据。随着组织开始实施大数据解决方案，他们开始生成大量非结构化数据。
我们的数据架构应该支持所有类型的源系统，以不同的空间和时间间隔发送不同类型的数据。

数据加载

数据摄取是从源系统提取数据并将其加载到数据平台的过程。如上文所示，基于源系统生成和发送数据的能力，必须实现加载对应的框架来构建批量/近实时或流式加载系统。

批量加载
每天发送一次数据的系统（作为一天结束或一天开始的过程）可以作为批处理过程加载到数据平台中。这是传统仓库架构中用于生成日常管理信息系统 (MIS) 或监管报告的最常见模式。

近实时
对于时间敏感的数据，可以以微批次或近乎实时的方式进行加载。微批量加载间隔可以低至几分钟，而近乎实时的数据可以在几分钟到几秒钟的时间内加载。数据加载工具应该能够根据业务需求满足所需的 SLA。

流式
流式场景对时间极其敏感，需要一种支持实时数据加载的架构，即在数据生成后的几毫秒内。这些数据对时间至关重要，如果不立即加载和处理，可能会迅速失去价值。我们的加载组件应该能够支持低延迟要求，以便在源系统生成数据后立即提供数据。

数据存储

数据被加载后，必须将其存储起来，以便于数据分析。数据存储组件能够有效地存储各种数据类型，数据存储分为两大类：

一般存储
所有数据类型都可以存储在对象存储中，例如 Hadoop 分布式文件系统 (HDFS)、Amazon Simple Storage Service (S3)、Azure Data Lake Storage (ADLS) 或 Google Cloud Storage (GCS)。这些存储支持持久保存结构化、半结构化或非结构化数据。它们提供高可用性和耐用性，并且具有成本低，使它们成为长期存储数据的最佳选择之一。

专用存储
虽然对象存储适合经济高效的长期存储，但我们可能经常需要一个专门构建的存储系统，该系统可以具有快速访问、更快检索、基于键的搜索、列式存储、高并发查询等功能。

有不同的技术和架构模式来实现这些：

支持联机分析处理 (OLAP) 工作当时 - 数据仓库
应用程序后端的在线事务处理 (OLTP) 系统 - 关系数据库 (RDBMS)
更快的数据检索 - 内存数据库
存储连接和关系 - 图形数据库

数据存储组件是数据平台中使用最广泛的组件。从存储长期数据到快速提供数据 - 所有主要活动都是在计算引擎的帮助下通过这些组件进行的。

数据处理和转换

从源系统收集的原始数据必须根据业务需求进行验证、清理、集成和转换。作为数据处理的一部分，需要执行多个步骤，通过执行各种步骤将原始数据转换为更易于使用的最终产品，详细信息如下：

数据校验和清理
从源系统获取的数据是原始形式，在提供给最终用户之前需要校验和清理。这两个步骤对于确保数据准确性存储层间传递不会受到影响非常重要。

校验是输入数据加载后的第一步，这些验证适用于结构化数据，并且在某种程度上适用于报表和数据分析生成的半结构化数据。数据流经各种验证关卡，包括技术和业务验证，如下所列：

技术验证主要涉及数据类型、数据格式和其他检查，这些检查本质上是技术性的，可以跨任何领域/行业应用**。**
业务验证是特定于领域/功能的，并且与属性中的特定值及其准确性或完整性相关。
schema 验证是输入数据源应根据规范或数据契约中定义好的 schema 格式进行的验证。

说明
数据契约是一个相对较新的术语，描述数据生产者与其消费者之间的协议。它定义了与所产生的数据相关的各种参数，例如数据的所有者、频率、数据类型和格式，以便数据的生产者和消费者之间有共同的理解。

数据转换
这是将原始数据转化为有用信息的过程。它可以是一系列转换，集成从多个源系统接收的数据并将其转换为下游应用程序、业务用户和其他数据消费者可以根据其需求使用的可用形式。

下边是常见的数转换方式：

数据整合

由于数据是从多个源系统获取的，因此我们必须将其组合起来以获得集成的数据视图。作为转换过程的一部分，这种集成是在将数据存储到更高层之前完成的。数据集成的数据包括集成来自源系统、内部系统或营销 app 的客户端数据。
数据增强

我们必须通过使用外部数据来增强数据，使其更有意义。数据增强的示例包括使用第三方应用程序/API 提供的汇率数据来计算每日销售额，以及使用信用评级机构提供的数据来计算信用评分。
数据聚合

最后，需要根据业务需求汇总数据。此过程有助于汇总和存储数据，以便更快地查询和检索。一个示例是根据日期、产品和位置聚合数据以获得销售的汇总视图。

什么是 ETL 和 ELT？
在实施数据仓库和数据湖时，有两种广泛采用的执行数据转换的方法：ETL 和 ELT。
抽取、转换和加载（ETL）

ETL 是从源系统中提取数据、执行所需转换并最终将数据加载到数据仓库中的过程。这种方法广泛应用于使用数据仓库方法构建的架构中。

抽取、加载和转换（ELT）

ELT 是从源系统中提取数据、将其加载到仓库中，然后使用仓库平台提供的计算能力执行转换的过程。近年来，随着高效、高性能仓库的兴起，ELT 方法非常流行。

数据管理和服务

这是根据业务流程和需求整理数据的过程。使用维度建模等建模方法，根据行业标准数据模型将数据加载到特定的数据层中。这种使用行业特定数据模型的数据排列有助于更快、更轻松地生成分析和报表。筛选过的数据可用于创建数据产品，消费者可以直接使用这些产品来满足其业务需求。

说明
数据产品是一个新术语，用于定义专门为其消费者策划的消费品。数据产品通常由负责数据的领域团队创建。这些产品可以与其他领域团队和下游应用程序共享。数据产品可以是表格、视图、报表、仪表盘，甚至可以是机器学习模型。

提供使用数据的方式

数据消费组件使用户能够访问、分析、查询和消费数据。这些可以是我们的 BI 报表工具，甚至是可用于进行预测和预报的 ML 模型。以下是这些组件支持的各种工作方式的说明：

BI 报表
BI 工具可帮助创建报表和仪表盘来实施 MIS、监管报表、销售仪表盘等用例。这是 RDBMS 等传统技术和使用数据仓库方法构建的架构支持的最早用例之一。

即席查询
业务用户、数据分析师和领导通常需要立即执行查询来进行数据分析或者为会议上突然出现的问题进行查询分析答案。这些组件提供了一个简单的 SQL 接口来执行此类分析。

APIs
下游应用程序需要一种通用的方式与数据平台交互。 API 提供了灵活性，下游系统可以使用它来轻松获取数据。

机器学习
ML 可以帮助支持多种用例，例如预测、预报、建议等。数据平台应该能够为 ML 生命周期提供工具，包括训练、部署和推理模型。
所有这些组件都可以将数据交付给数据消费者，并在提高用户对平台的采用方面发挥着重要作用。这些数据架构组件为用户提供了与平台内驻留的数据进行交互的接口，在设计这些组件时应考虑用户体验。