导读 本文将分享滴普科技基于 Data Fabric 的实时湖仓平台技术实践。文章将介绍 Data Fabric 的基本原理和概念，并分享滴普基于 Data Fabric 构建的一款产品------FastData。

今天的介绍会围绕下面四点展开：

1. Data Fabric 介绍

2. FastData 实时智能湖仓平台介绍

3. FastData 实时智能湖仓平台实践案例

4. FastData 实时智能湖仓平台未来规划

分享嘉宾｜张赵中 北京滴普科技有限公司 架构师

内容校对｜李瑶

出品社区｜DataFun

01Data 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"，意味着所有数据都可以在一个平台上进行查看，但并不一定要将所有数据都搬到一个地方。

02FastData 实时智能湖仓平台介绍

滴普科技基于 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 来进行增量计算，然后将结果同步到物化视图中。

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

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

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

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

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

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

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

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

FastData 平台的未来规划包括以下几个方向：首先，我们将继续致力于构建高性能、低成本、易使用的大数据平台。其次，我们将提升数据湖内部的数据服务性能。目前我们的数据服务在高并发情况下仍有待提高。第三，我们计划统一 Gateway 服务，以提供一致的用户体验。不同的工作负载和引擎可能有不同的使用方式，我们希望能够统一这些工作方式，使用户能够像使用 MySQL 一样方便地使用我们的平台。第四，我们计划支持更多的云环境。目前我们已经适配了一些主流的云平台，但对于一些较冷门的云平台，仍需要增加适配能力。最后，我们将通过大模型技术来解决数据资产变现的问题。传统的数据处理链路需要人工参与，从数据集成、开发、指标加工到决策，都需要人工操作。通过大模型技术，我们希望能够降低重复劳动，并实现自然语言翻译和直接生成 SQL 等功能，以提升效率。

以上就是本次分享的内容，谢谢大家。