数据湖与实时数仓应用实践

 

一、Data Fabric 介绍

首先，让我们来看一下 Data Fabric 的定义。

Data Fabric 是一种新兴的数据管理设计理念，起源于美国。根据 Gartner 的定义，Data Fabric 可以实现跨异构数据源的增强、数据集成和共享。这意味着以前在构建数据仓库时需要进行大量的ETL工作，将不同业务关系数据库中的数据加载到数据仓库中，并通过各种链路进行数据同步。然后，在数据仓库中进行分层加工，最终生成各种指标，供用户进行分析和生成报表。

Data Fabric 的理念与传统的数据仓库有所不同。在某些情况下，分析师可能并不需要将整个数据完全搬移到自己的工作环境中，而只需要进行简单的数据探查。因此，Data Fabric 的概念就应运而生。简单来说，Data Fabric 就是一种对企业内部数据进行轻量级探查的编织概念。

基于Data Fabric 的理念，我们可以进行更加灵活和高效的数据分析。自2019年起，Gartner 已经连续三年将 Data Fabric 技术列入十大数据分析技术趋势之一。这表明 Data Fabric 技术正在逐渐成为数据管理和分析领域的重要趋势。在2022年，Gartner 将 Data Fabric 技术列为数据管理和分析领域的排名第一的技术趋势，它的出现为企业提供了更加灵活和高效的数据管理和分析解决方案，因此备受关注和追捧。

Data Fabric 的价值主要体现在降低成本和提高效率方面。它可以帮助用户减少在数据开发、分析和管理过程中的工作量，避免频繁的数据迁移和复制。那么，Data Fabric 实际上解决了什么问题呢？最主要的问题是打破数据孤岛。通过将数据接入到统一的平台中，企业可以获得对整个企业内所有数据的高级视图，了解企业内部的数据在哪里、做什么用途。此外，用户还可以进行简单的数据探查，而无需将数据全部迁移到数据仓库或数据湖中。这样一来，Data Fabric 为企业提供了更加综合和灵活的数据管理和探索方式，从而提高了数据分析的效率和准确性。

现在硅谷流行一个概念——Lakehouse 数据湖。数据湖和 Data Fabric 的理念密切相关。数据湖强调存储的易用性，与传统的数据仓库不同，它对数据的存储和拉取要求不那么严格，数据的结构和格式也不需要遵循传统的范式结构化数据的要求。这与数据仓库的要求有所不同，数据仓库要求数据必须遵循严格的范式结构，并需要进行各种加工处理。因此，数据湖和Data Fabric的理念是密不可分的。

目前，硅谷的一些头部互联网公司都推出了基于 Data Fabric 概念的产品。例如微软在今年五月份推出了 Microsoft Fabric 和 OneLake 两款产品，它们共同组成了整个数据平台。IBM 也在5月9日发布了基于 Data Fabric 理念的产品 Watsonx.data lakehouse，与其另一款产品 Cloud Pak for Data 相互关联，构建了一个从底层到开发应用的全数据加工平台。微软的 Fabric 理念是"All your data, all your teams, all in one place"，意味着所有数据都可以在一个平台上进行查看，但并不一定要将所有数据都搬到一个地方。

二、FastData 实时智能湖仓平台介绍

滴普科技基于 Data Fabric 理念打造了一款产品，名为FastData。该产品定位为一站式的实时智能数据湖平台，主要包含三个层次。

首先是我们的 DLink 引擎，解决了在各种云基础设施上的存储和计算问题。它有效地组织和存储数据，并提供了针对不同工作负载的计算能力。在这一层之上，有开发套件和分析套件。开发套件类似于数据开发中的工具箱，提供了调度、编辑器和工作流编排等功能。而分析套件主要解决指标管理问题，更加面向业务，帮助管理各种非 SQL 方式的指标。

湖仓部分是数据仓库架构中的一个重要组成部分，主要解决数据存储和计算的问题。在数据仓库中，数据通常以表格形式存储，湖仓管理需要考虑如何存储和管理不同格式的数据表格，以及如何提供加速和管理源数据。在存算分离的情况下，湖仓管理需要提供高效的数据访问和查询功能，以便用户能够快速获取所需的数据。

基于 Data Fabric 架构，数据可以分布在不同的位置和系统中，因此湖仓管理需要持有各种数据的源数据，以便能够更好地管理和查看数据。这样可以提供更高阶的 view 视图，使用户能够更好地了解数据的整体情况。

湖仓管理还提供了一些计算能力和开发套件，用于建模、数据质量、数据治理、调度和数据集成等方面。例如，用户可以使用开发套件来建立模型、评估数据质量、制定数据治理策略、调度数据处理任务以及实现数据集成。这些工具可以帮助用户更好地管理和利用数据资源。

最高层的分析层主要解决如何建立各种指标，并通过自己的模型语言来管理这些指标，从而形成企业的数据资产。用户可以使用分析层来定义和计算各种指标，例如销售额、用户增长率、市场份额等。这些指标可以帮助企业更好地了解自己的业务状况，并制定相应的决策和战略。

现代数据栈（MDS）是一个全流程架构的概念，它是可组装的而不是整体式的。每个客户在使用平台时，并不需要使用所有的套件，因此 MDS 采用了可插拔的插件形式，根据客户的需求进行组装，实现了一种非大而全的平台。这种可组装的方式可以降低企业的成本，并简化平台架构。

MDS 的整个平台架构从数据源的数据拉取开始，包括实时和离线的数据采集和集成部分，然后将数据集成到数据湖和数据仓库中，形成湖仓一体的架构。这个架构实现了数据的整合和统一管理，使得企业能够更好地利用数据资源。

总的来说，MDS 是一个灵活可组装的数据架构，通过插件形式提供所需的功能，覆盖从数据源到数据湖和数据仓库的整个数据流程，帮助企业降低成本并简化平台架构。

在存储底座中使用 DLink 套件时，数据开始进行开发，并在开发界面中进行相应的开发工作。在数据开发过程中，数据治理是一个重要的环节，确保数据质量的高标准。然后，数据进入到数据的分析与应用层，这是分析套件所要解决的问题。分析套件提供了一系列工具和功能，帮助用户进行数据分析和应用开发。

最底层是控制台，这是另一款产品，其主要解决的问题是对基础设施的计算资源和存储资源进行管理。它还提供了监控和告警功能，以及对数据源的统一管理。这个产品被称为 DCE（Data Control Engine），它的主要目标是管理和优化基础设施资源，确保系统的高效运行。

产品的核心优势可以简单概括为四个方面。首先是低成本，因为它可以完全分离地部署在各种公共云的对象存储上，同时也支持私有云的部署，比如在 IDC 里面可以对接传统的 HDFS 等。其次是易用性，它提供了敏捷的数据开发能力，包括低代码指示和低代码开发等工具。第三是可组装性，即根据需求选择自己的链路，这是基于现代数据栈（MDS）的思想，可以根据客户需求进行定制化部署。最后是简单扩展性，它是从 Hadoop 生态的大数据平台向互联网一体的新一代大数据平台演进，同时也支持国产化新创，为用户提供更多的选择。

概括而言，FastData 具有低成本、易用性、可组装和易扩展等核心优势，可以帮助企业更好地管理和利用数据资源，提高数据分析和应用的效率。

FastData 分析套件主要用来处理指标，它采用了统一 ML（Model Language）模型语言来定义、管理和加工指标。一旦指标加工好了，我们就可以将其存储在各种不同的存储介质中，包括开源存储和我们自己的湖仓引擎等。这个分析套件主要关注指标层的存储和管理，而不关心指标具体存储在哪里。

为了更好地服务于客户，我们还提供了各种各样的服务，包括对接各种 BI 工具、提供数据企业产品 API link 等。客户可以通过这些服务来查询指标数据，进行各种数据分析和应用。此外，我们还提供了 AI link 服务，客户可以通过数据科学和 Jupyter 等工具来访问指标数据，实现数据应用的开发和部署。

FastData 分析套件统一的指标管理和加工方案，以及丰富的服务和工具，可以帮助客户更好地利用和应用数据资源，提高数据分析和应用的效率。

分析套件的功能架构主要包括指标语言的建设和指标加速两个方面。首先，指标语言的建设是指如何定义和管理功能指标。用户可以使用统一 ML 模型语言来定义复杂的指标逻辑，包括指标的计算、聚合和过滤等操作。这样可以帮助用户更好地理解和描述业务需求。

其次，指标加速是非常重要的一点。由于用户建立的指标逻辑可能非常复杂，我们需要在用户查询时能够快速地找到指标数据。为了实现指标的快速查询，我们采用了一系列优化技术，包括数据索引、缓存和并行计算等。通过这些加速技术，可以大大提高指标查询的效率，使用户能够快速获取所需的数据。

分析套件的价值在于提供了无门槛的数据洞察能力，即使不懂 SQL 的人也能够建立指标。用户只需要进行简单的配置，比如配置一些原子指标和修饰词，然后指定一些加工公式，就能够计算出所需的指标。通过仪表盘等工具，用户可以洞察到隐藏在数据背后的业务见解。

另外，统一指标服务是通过模型语言提供各种对外的 API，如 JDBC 和 SDK 等。这样可以方便用户通过外部工具访问和查询指标数据。此外，CubeLess 是用于构建数据立方体的一种技术。它通过底层的预计算能力和缓存技术，事先计算好指标并加速查询。同时，分析套件还可以轻松对接各种流行的BI工具，提供加速查询的能力。

下面重点介绍开发治理套件。开发治理套件是一个相对传统的数据开发和管理工具，按照常规的数据链路进行数据开发。首先，进行数据标准化和建立模型，然后进行数据开发，其中涉及到数据的血缘关系和调度。这个过程涉及到元数据，然后发布到生产环境中进行运行。在这个过程中，还需要进行质量校验、数据集成和数据安全（如加密和脱敏）等处理，最终对外提供服务。整个流程比较标准化。

最底层的存和算引擎是湖仓引擎，主要解决高效存储和计算的问题。在存储方面，我们采用了表格式，主要使用了 Apache 的 Iceberg，并进行了大量的二次开发。在计算方面，我们为不同的工作负载提供了三种内置的算力引擎。对于离线工作负载，提供了 Spark；对于实时工作负载，提供了Flink；而对于机器查询和分析工作负载，则提供了内置的 Trino 组件。这样，能够满足不同场景下的高效存储和计算需求。

湖仓引擎的价值主要在于：

首先，能够提供多工作负载，并能够以云化方式提供数据服务，也就是它的工作负载。不同的工作负载有不同的内置组件来支撑。

另外，它的架构是存算分离的，它的存储底座可以对接各种对象存储，可以提供 PB 乃至 EB 级的海量数据存储。

分布式数据湖架构，企业可以建立多个数据湖，包括总公司和各个分公司的数据湖。然而，如何实现不同数据湖之间的有效数据共享是一个需要解决的问题。

逻辑入湖与物理入湖是数据管理和分析领域的两种不同方法。物理入湖是将传统的数据完全搬迁到数据湖中，并在数据湖上构建数据仓库或进行数据分析。在物理入湖的过程中，通常会采用批流一体的方式，将离线和实时数据处理合并为一条数据流，以提高数据处理效率。此外，还需要对整个数据集成过程进行管理，包括处理数据结构变更的问题，以确保数据湖中的数据与源数据保持同步。

逻辑入湖是一种基于 Fabric 架构的实践方法。它的主要技术要求是统一元数据，包括已经入湖的数据和未入湖的数据。逻辑入湖并不涉及将数据搬迁到数据湖中，而是通过管理元数据的方式，将元数据捞取过来并进行管理。数据仍然保留在原始位置。在数据仓库层进行数据加工和分析时，可以直接使用SQL进行操作，无需关心数据的具体存储位置。

分布式数据湖是一个多湖的概念，它可以解决大型企业中总公司和分公司之间数据交换的问题。以中国移动为例，总公司和各个省分公司都有自己的数据仓库和数据湖。为了实现数据交换，可以采用分布式多湖联邦查询的能力来解决。具体做法是，分公司可以将自己的数据湖注册到总公司，并提供一个注册账号来管理权限。这个注册账号可以控制总公司对分公司数据的访问权限，可以随时扩大或缩小权限，甚至收回权限。这样就实现了有限制的数据分享，不需要将所有权限开放给总公司。例如，可以只开放读权限而不开放写权限。分布式数据湖的架构主要解决这种情况下的数据交换问题。

分布式数据湖中的核心理念是 Fabric，它能够实现统一的数据视图，而这是通过统一的元数据服务来实现的。这个元数据服务不仅可以管理数据湖内的数据，还可以管理企业内其他各种数据存储的元数据。此外，权限管控也非常重要，因为如果源数据管理没有权限控制，数据的安全性就无法得到保障。

在 FastData 团队中负责构建近实时的数仓，是我们的一个重要工作。我们采用了 Apache 的 Iceberg 来做底层的表格式存储。从数据源到 ODS 层，我们使用 Flink CDC 技术将数据源拉进来，之后从 ODS 层到下面的 DWD 层或 DWS 层，需要让数据快速地流动起来。为了实现这个目标，我们需要Iceberg这一层支持 CDC 技术，也就是说通过使用Flink这种流式读取 Iceberg 的 Connector，可以快速地感知上游 Iceberg 表的数据变化和schema变化，并将这些变化及时地同步给下一层。这样，数据和 DML 就可以不需要人工操作便自动地流动起来。除了 Append 数据之外，还有 delete 数据和 update 数据，这些数据都需要通过整个链路不停地往下游流动，以便产生的指标能够跟着业务数据的变化而变化。我们已经做到了这一点，但是 Iceberg 的 changlog 产生是依赖于上游表的 commit 操作。commit 的频率越高，时效性越好，但是会产生更多的杂乱无章的文件，对后台的自动化运维提出了较高的要求。commit 的时间越长，拉的时间越长，对文件是更好，但是时效性就差了一些。因此，我们需要根据业务的实际时效要求做出合理的配置。

自动化表运维方面，因为数据湖与传统的 Hive 表格有所不同，数据湖支持行级别和列级别的更新，因此会产生各种各样的删除文件和小文件。同时，数据湖也支持实时写入，这会导致更多的小文件和删除文件。如果不及时整理这些文件，直接查询的效果将非常差。为了解决这个问题，我们使用了异步合并和读时合并 MOR 等技术来提高性能。在后台，我们必须确保这些工作得到良好的处理。

在 FastData 内部，我们致力于让用户完全无需关心这些工作。就像使用传统的 Hive 表格一样，用户只需要专注于他们的数据业务，写入和读取数据即可。后续的维护工作由系统自动完成，用户无需进行操作。

物化视图是一种常见的空间换时间的策略，通常在 MPP 中也会使用，例如 StarRocks 也使用了这种策略。物化视图的一个特点是对于那些查询相对固定的query，查询加速的效果比较好，因为它的命中率较高。

在 Fastdata 内部，我们基于 Trino 实现了物化视图。然而，社区版的物化视图基本上无法使用。首先，它的刷新需要手动刷新数据，全量刷新是不可行的。例如，如果我的基表有上亿条数据，如果我做了一个聚合查询生成一个物化视图，如果要全量刷新，代价太大了。因此，我们在这个基础上做了一些优化工作。例如，我们现在可以自动刷新，第二刷新可以做增量刷新。增量刷新意味着，当基表发生任何变更时，例如添加了一行或删除了某一行数据，这种变更很快就能体现在物化视图中。在后台，我们通过使用 Iceberg 的CDC 技术来实现实时监控基表的变化。一旦感知到变化，就会触发增量计算。我们使用Flink 来进行增量计算，然后将结果同步到物化视图中。

三、FastData 实时智能湖仓平台实践案例

FastData 已经在多个行业中积累了一些客户案例。尤其在能源和商品流通领域，特别是新零售方面，得到了广泛应用，并取得了一定的成果。

在能源领域，我们的平台主要解决两个核心问题。首先，利用 Hadoop 技术来处理各个油田的数据。由于油田分布广泛，每个油田都有自己的数据管理系统，因此我们的平台能够将这些数据整合起来，并提供更快速的数据采集速度，从T+1天级别提升到分钟级别。

其次，我们通过建立分布式数据湖（Lakehouse）来解决数据管理的问题。以前，各个油田的数据是相互独立的，没有统一的管理方式。现在我们的平台允许各个油田建立自己的数据湖，并将数据注册到总部。这样，总部就可以随时进行数据分析，了解各个油田当天的生产经营情况。同时，数据仍然保留在各个油田的本地存储中，实现了数据的集中管理和分散存储，解决了这两个核心痛点问题。

FastData 平台不仅提供结构化数据仓库和数据湖仓库的能力，还能处理半结构化和非结构化数据。对于零售客户来说，这是一个重要的功能。在过去的 Hadoop 时代，处理结构化和非结构化数据通常需要使用完全独立的技术栈和平台。但通过 FastData 平台，可以实现半结构化数据和非结构化数据的统一存储和管理，解决了企业内部存在的各种非结构化数据的问题。这样，客户可以在一个统一的平台上处理和管理不同类型的数据，提高数据处理的效率和一致性。

这个案例是一家新能源汽车企业的数字化转型。他们主要面临以下问题：营销不精准、被动式服务、缺乏用户价值的运营，以及数据管理混乱，难以发现数据背后的价值。

我们的产品在这个案例中的重点是分析套件，通过它来帮助企业构建数据资产并发现业务价值。FastData 分析套件能够帮助企业进行数据分析，提升营销精准度，改善服务质量，并发现潜在的业务价值。通过这个案例，我们能够看到企业在数字化转型中取得了显著的进展。

四、FastData 实时智能湖仓平台未来规划

FastData 平台的未来规划包括以下几个方向：

首先，我们将继续致力于构建高性能、低成本、易使用的大数据平台。

其次，我们将提升数据湖内部的数据服务性能。目前我们的数据服务在高并发情况下仍有待提高。

第三，我们计划统一 Gateway 服务，以提供一致的用户体验。不同的工作负载和引擎可能有不同的使用方式，我们希望能够统一这些工作方式，使用户能够像使用 MySQL 一样方便地使用我们的平台。

第四，我们计划支持更多的云环境。目前我们已经适配了一些主流的云平台，但对于一些较冷门的云平台，仍需要增加适配能力。

最后，我们将通过大模型技术来解决数据资产变现的问题。传统的数据处理链路需要人工参与，从数据集成、开发、指标加工到决策，都需要人工操作。通过大模型技术，我们希望能够降低重复劳动，并实现自然语言翻译和直接生成 SQL 等功能，以提升效率。