如何借助逻辑数据编织平台实现“数据优先堆栈（ DFS ）”

一、什么是面向“数据优先”的数据研发平台？

企业在数字化转型的浪潮中，愈发认知到数据作为核心战略资产的重要性。然而，要充分利用数据的价值并非易事。一方面，企业需要投入大量资源来建设和维护复杂的数据基础设施；另一方面，还需要不断应对新兴技术和市场变化带来的挑战。此外，随着大数据、人工智能等技术的快速发展，数据治理的压力和要求也在不断提高。随着数字化进程的加速，业界不断探索和实践，数据架构与管理模式在全球范围经历了几个阶段的逐步演进。

传统数据堆栈（ Traditional Data Stack，TDS ）阶段，数据主要来源于结构化数据源，通过集中式的方式抽取至数据仓库中进行处理。在这一阶段，数据经历清洗、转换和加载（ ETL ）等步骤，最终服务于数据分析和应用需求。 TDS 在处理单一类型数据时表现出色，但随着数据量的激增和数据类型的多样化，TDS 逐渐暴露出扩展性不足和灵活性欠缺的问题。

接着，现代数据堆栈（ Morden Data Stack，MDS ）应运而生，它突破了 TDS 的局限，接纳非结构化数据，还引入了数据湖与数据仓库相结合的 Lakehouse 模式。 MDS 通过大量工具高度集成的解决方案，实现了数据源、数据处理与消费端的连接，并呈现出从集中式向分布式、从本地往云端演进。然而，一方面 MDS 是一个由大量工具构成的复杂生态，这给企业带来“数据技术多样化、碎片化和大量堆叠”的复杂性挑战；另一方面 MDS 的实施成本高昂，往往要求企业彻底重构现有数据体系架构，这对于许多企业而言是难以承受之重。

在此背景下，面向数据优先的研发平台（ Data-First Stack，DFS ）成为了一种更为理想的选择。

在数据集成方面， DFS 主要通过标准的 API 进行数据的接入，而非传统的物理加载进数仓中。通过对 API 层进行统一抽象，使得数据加工能够通过统一、结构化的模式进行处理。

在数据消费端， DFS 提供了统一的消费网关，通过这个网关对外提供数据服务。这种方式减少了用户因性能或其他灵活需求而将数据导出至其他系统的必要性。

通过这种一体化的解决方案，不仅简化了数据的获取和使用流程，还优化了整体的数据处理链条，为用户带来了更高效、更便捷的数据管理体验。

在深度探讨 DFS 之前，让我们先审视传统数据研发模式的局限。传统模式下，数据研发通常涉及复杂的数据集成、处理与消费流程，这些环节紧密依赖于底层技术栈的具体实现。例如，数据集成可能需要开发者深入了解不同集成技术的优劣，并据此选择最合适的方案；数据处理则要求开发者直接面对底层计算引擎（如 MaxCompute、Spark 等），编写与之适配的代码；数据消费时，不同引擎间的查询语言与数据交互方式差异显著，增加了复杂性和学习成本。

这种模式的核心问题在于其“面向组件”的特性，即每个环节都紧密绑定于特定的技术组件，缺乏统一的抽象层。这不仅导致工具繁杂、功能重叠，还极大地提高了专业门槛，使得数据研发人员需花费大量精力理解并适配底层技术细节。更进一步，一旦底层技术更新或替换，整个数据解决方案可能需要全面重构，增加了维护与升级的成本。

为了解决传统数据研发模式中存在的问题，我们需要寻找一种对用户而言最为自然、方便且高效的数据研发模式。在此过程中，普遍存在一种思考：是否可以借鉴操作系统的设计理念来优化数据研发流程？通过抽象和封装底层技术细节，使用户能够专注于数据处理逻辑本身，而非深陷于技术实现的泥沼之中。

操作系统的核心在于，它对底层硬件和设备进行了统一的抽象，形成了内核层。这一层抽象出了文件系统、应用、线程、进程等概念，以及进程调度的机制。因此，程序员在开发应用时，不再需要直接面对底层硬件，而是可以基于这些抽象概念进行开发，从而大大降低了开发难度和成本。

在数据处理的具体实践中，也面临着类似的场景。例如，使用 Flink CDC 进行数据同步时，它负责数据的接入和导出工作。在此过程中，可能还需要进行跑批操作，相当于对数据进行预计算。最后，消费端通过查询来获取结果。

这与传统的硬件程序开发有着异曲同工之妙。在硬件层面，我们可以通过通用的 I/O 接口来进行数据交互。在数据处理领域，我们可以定义类似于 Kernal 的中间层，提供一套标准化的访问接口，使数据开发者能够基于这些接口快速构建数据处理逻辑，而无需深入了解底层技术的具体实现细节。

回到今天我们所探讨的——数据优先（DFS）的数据研发平台，首先要理解“数据优先”的含义。这主要体现在数据研发过程的高度抽象化。在传统的面向组件的研发模式中，实现数据处理需要明确告知底层引擎如何抽取、同步和加工数据。而在数据优先的模式下，我们更侧重于告知系统数据的处理逻辑，而非具体实现细节。

这种模式的核心特点之一是声明式编程，即向系统阐述所需结果，而非实现方式，从而更易于实现标准化。这得益于对计算、存储及输入输出的统一抽象。

在此基础之上，我们为数据研发人员提供统一的标准访问接口。他们通过标准接口编写逻辑和 SQL ，这意味着加工逻辑与底层硬件无关。因此，当底层引擎更换时，对数据代码的影响微乎其微。

此外，通过模块化方式接入各种底层资源，为上层数据开发人员提供了快速集成的便利。这种方式的显著优势在于，上层解决方案如数据质量或数据安全方案，可以很方便地适配任意资源。无论底层引擎如何更换，上层方案均能保持通用性，进而可以充分复用现有架构和上层解决方案。

综上，数据优先的数据研发平台的核心理念是，让数据研发工程师将更多精力聚焦于数据研发本身，而非被底层引擎和组件的特性所干扰或分散注意力。这种模式有助于提升数据研发效率，降低底层技术变动对研发工作的影响。

二、Aloudata AIR ：数据优先技术栈的构建与实现

接下来，我们来深入介绍一下 Aloudata AIR 逻辑数据编织平台如何实现 DFS - 数据优先技术栈。

Aloudata AIR 对数据研发过程的抽象

Aloudata AIR 是如何定义 DataOS 的呢？

首先，在最底层，我们抽象出了一个适配层，涵盖了几类核心组件。

第一类是 IO 组件，包括数据的导入（ Import ）和导出（ Export ）。例如，利用 Flink CDC 来实现实时的数据同步。这些操作对用户是透明的，主要取决于部署时的具体场景和需求。
除了 IO 组件，我们还提供了构建引擎（Build Engine），类似于 CPU ，负责数据的实时构建和跑批构建。
同时，我们还有查询引擎（Query Engine），类似于内存，用于数据查询加速。这个查询引擎可以对接各种 OLAP 引擎，以满足用户不同的查询需求。
另外，在存储方面，也进行了统一的抽象，以屏蔽底层存储系统的复杂性。

其次，基于这三类抽象，我们定义了 DataOS 的内核层（Kernal），它包含几种核心单元。

首先是 Compute Unit 。在企业部署逻辑数据编织平台时，可以定义一个或多个 Cluster ，每个 Cluster 下会嵌套两个或多个 Compute Units 。这些 Compute Units 可以对应不同的计算引擎，如跑批引擎或实时计算引擎，具体取决于配置的路由策略，比如一个用于跑批，一个用于跑流，一个用于查询。
其次是对数据 Import 和 Export 的抽象，包括全量和增量的数据同步作业。
再往上，我们有统一的调度层（Scheduler），负责调度实时和离线的作业。同时，我们还引入了 Data Source 的概念，通过 Data Source 连接所有底层物理源，包括文件、 API 、关系型和非关系型数据库等。
基于 Scheduler 跟 Data Source ，我们定义了几个核心概念，这些概念会直接暴露给用户。首先是逻辑表（ Logic Table ）。包括贴源层（ PDS，数据源的物理映射）、视图层（ VDS，逻辑视图）和表（ Table，与传统数仓的物理表类似，但其存储取决于 Cluster 的配置，无需用户关心）。这些逻辑表屏蔽了底层的物理存储细节，让用户可以更加专注于数据处理逻辑。
Aloudata AIR 有一个重要概念是关系投影（ Relational Projection，RP ），其本质是作业的映射，如同步作业、导出作业、实时作业、离线作业等都可以被抽象成关系投影。关系投影的操作非常简单，用户只需去勾选 PDS、VDS 或者 Table 中的字段，再配置离线或者实时即可，Aloudata AIR 会将这些 RP 配置翻译成底层的跑批、跑流等具体任务，即可快速、智能地实现查询的物化加速。
在这些基本单元之上，我们提供了一系列功能层，包括元数据管理（数据源的元数据和 Aloudata AIR 内部加工产生的元数据）、作业管理（Job Manager）和查询优化（Planning）等。Planning 负责查询改写、RP 作业生成、跨源的查询下推等。特别是，我们有一个 RP 管理器（RP Manager），负责智能创建和回收RP。

最后，我们包装了统一的 SQL 语言层，使用户能够通过 SQL 操作表、RP 等。

在实际应用中，用户可以通过创建视图来进行数据加工，平台会自动分析视图逻辑并翻译成底层查询引擎的查询。当查询性能不足时，用户可以通过建立 RP 来触发跑批或跑流作业，从而实现查询加速。用户的查询体验是只面向逻辑视图的，查询是否命中 RP 以及命中后的查询改写和引擎适配完全由系统自动化实现，因此物化表和底层引擎的差异性完全被屏蔽掉了。传统数据研发模式下，用户需要了解和直接操作构建引擎、流计算引擎和 OLAP 引擎，直接操作数据流在不同的引擎之间流转。而 Aloudata AIR 只需要用户感知逻辑视图、RP 和查询 SQL 本身即可。

Aloudata AIR 逻辑数据编织平台的能力与功能

Aloudata AIR 逻辑数据编织平台的能力主要包含数据集成、资产管理和资产交付三个方面。

在数据集成方面，我们实现了对传统数据库及数据仓库的整合。Aloudata AIR 可以使用用户的数据仓库作为我们的执行引擎。这意味着在构建流程中，任务能够直接推送至数据仓库进行执行，充分复用现有的基础设施。此外，我们还支持云端数据存储，包括数据湖（如： Iceberg、Hudi ...）、NoSQL 数据库（如 ES、HBase、MongoDB ...）以及 Restful API 、文件（如： HDFS 、 S3 、NAS 及本地文件...），这些都可以方便快捷地集成到 Aloudata AIR 中。

资产管理包含以下能力：

首先我们提供了完善的资产加工工具。用户在数据处理、分析或面向 BI 工具的分析场景中，均可使用统一的 SQL 语法查询同一个虚拟化引擎，通过这种方式我们可以创建和管理逻辑数据资产。
在此基础上，我们通过 RP 实现查询的智能自适应加速。 RP 本质上是一种数据加工方式，能够将传统数据研发的主链路转移到旁路，并实现按需物化。例如，当查询性能不佳时，用户可以创建一个 RP ，此时 RP 管理器会自动生成作业。在查询该作业时，系统会自动进行查询改写和计算。
Aloudata AIR 还具备智能 RP 的创建和自动回收功能。传统数仓开发中，当需要进行表和作业的回收时，通常需要手动发起治理流程，这不仅操作繁琐，协同困难，而且可能引发数据丢失或难以再次利用的问题。然而，在智能 RP 的机制下，加工逻辑与 RP 并行存在， RP 的回收并不等同于加工逻辑的消失。即使 RP 被回收，其背后的加工逻辑依然保留，只是在查询时性能可能有所下降。这种机制的最大优势在于，当 RP 不再被使用时，系统可以自动进行回收，从而实现了计算和存储资源的自动优化。
此外，我们提供了统一的安全管控，通过逻辑集成所有数据资源，便于统一的安全管理和治理。
同时，为了满足拥有多个子公司或部门的大型企业的需求，我们还支持多租户模式，实现数据的安全隔离与共享。
此外，Aloudata AIR 支持按照业务语义组织和管理数据资产。

在资产交付方面，我们提供了几种模式：

首先，我们提供完整的资产目录，用户可以根据标签和资产属性查找资产。
其次，所有逻辑化数据均可通过 Restful API 无缝对接至用户的应用系统，或通过 JDBC、ODBC 等标准接口与各类 BI 工具实现集成。
此外，针对用户可能的数据迁移需求，我们还提供了灵活的数据导出功能，支持将逻辑表中的数据以文件形式导出，或直接导入至关系型数据库、数据仓库、分布式文件存储和数据湖等，从而满足用户在不同场景下的数据应用需求。

三、Aloudata AIR ：让数据研发专注于数据处理本身

与传统数据研发相比，Aloudata AIR 具有哪些显著优势呢？

Aloudata AIR 在连接层通过高效的逻辑映射技术实现数据的迅速集成，突破了传统数据仓库必须进行数据同步的限制，实现更加快速的数据探查。

此外，在传统数据仓库中，用户需要创建实时任务、离线任务和物理表，而在 Aloudata AIR 中，仅需创建视图（如普通视图或参数化视图）。用户面向统一的抽象层创建 VDS，进而由 RP 自动构建 VDS 的加工作业，自动串联以往建立物理作业的所有过程，从而大幅降低用户的工作量和理解复杂度。值得一提的是， Aloudata AIR 内置了 OLAP 引擎，因此通过 BI 工具能够轻易实现结果的秒级返回。

从研发效率的角度来看， Aloudata AIR 模式下的数据研发人员仅需明确数据需求，而后续的导出任务、引擎选择等复杂流程均可由系统自动完成。这种模式在数据集成方面的优势特别明显，能够显著提升数据探查与集成的效率，提升幅度高达 90% 以上。

在数据处理环节，由于调度作业与引擎差异的透明化处理，且平台提供了统一的数据语法，使得整个数据加工过程的研发效率至少提升了 50% 。

在数据导出方面，由于 RP 加速过程中已内置了导出步骤，因此几乎完全消除了独立的导出过程，数据导出效率也实现了至少 90% 的提升。

在运维层面，当底层引擎进行升级换代， Aloudata AIR 确保引擎对上层数据产品透明化，能显著降低替换成本。结合自动化 RP 创建与回收达成的存储和计算优化，Aloudata AIR 对数据运营效率可以实现 80% 以上的提升。

在生产模式上，传统研发采用面向组件的方式，通常是先生产后使用。 Aloudata AIR 的方法截然不同，它采用面向抽象的数据研发方式。这种方式不鼓励先进行数据加工生产和加速，而是通过连接和逻辑视图的构建验证数据资产是否符合需求。只有当数据资产符合要求且存在性能需求时，才会触发真正的 RP 构建，生成具体的 ETL 作业任务，这是一种典型的以销定产的模式，更加经济和高效。

在数据集成方面，传统方法依赖物理集成，而 Aloudata AIR 则运用逻辑集成。

在数据加工方面，从技术角度看，两者在数据处理能力上可能相差无几，但隐形成本上的差异显著。传统数据研发平台要求深入理解不同引擎间的差异，并需手动管理物理表的管理、复用与回收。相反，Aloudata AIR 中研发人员面向逻辑层进行开发，RP 的复用和回收实现了全自动化。在查询改写时，它并不关注特定视图的 RP ，只要逻辑和算子匹配并能提取所需数据，就会自动改写到相应的 RP 进行查询。

对于数据消费者来说，在传统数据研发平台上可能需要考虑集成 OLAP 引擎的问题，但在 Aloudata AIR 已经内置了 OLAP 引擎。此外，在资产管理方面，传统方法通常仅限于管理已集成的资产，包括数据安全也是如此。然而，将企业内所有资产完全集中至数仓对于大多数企业来说并不现实。但逻辑集成方式由于集成成本非常低，使得数据资产管理更加容易实现。

最后，在底层技术引擎的升级换代方面，基于逻辑数据编织的方案，基础引擎的升级换代代价会大幅降低。

四、Aloudata AIR 助力企业数据整合与高效决策

案例一：打破多套数仓壁垒，实现一体化数据服务

该客户拥有多套数据仓库，过去主要依赖各个独立的数据服务系统来调用对应数据仓库中的数据，经过缓存，再为业务提供数据服务。随着企业数据量的增长和业务需求的复杂化，这种传统方式逐渐暴露出诸多痛点。

首先，数据分散在多套数仓中，导致数据查询和整合变得异常复杂。每当需要进行跨源查询时，都需要单独编写复杂的查询逻辑，甚至需要手动导出和整合数据，严重影响了工作效率和数据准确性。其次，由于每个数仓都对应一套独立的数据服务系统，这种烟囱式的数据服务模式不仅增加了管理和维护成本，还限制了数据服务的灵活性和可扩展性。

另外，无法提供高性能的跨源服务。尽管之前曾尝试利用 HBase 来加速查询，但这种方法存在明显的短板。一方面， HBase 解决方案显得相对厚重，需要占用大量的系统资源；另一方面，其解决方案的应用范围相当有限。特别是在处理跨源查询时， HBase 显得力不从心，难以满足复杂多变的业务需求。

为了解决这些痛点，我们在客户的数仓和数据湖之上，搭建了 Aloudata AIR 。通过 Aloudata AIR ，能够有效地整合数仓和数据湖包括各子分公司的数据源。现在，企业的上层应用可以通过 Aloudata AIR 实现与所有数据源的无缝连接，轻松进行跨源查询，而无需担心数据源之间的入口、语法和用法等方面的差异，加速了数据分析与决策的过程。同时，通过统一的数据服务出口，也使得资产管理和数据安全方案的实施变得更为便捷和高效。

案例二：突破传统中台建设周期长、成本高、技术门槛高的壁垒，高效整合企业数据资源

该客户是传统制造企业，规模庞大。随着企业工厂的不断增多，数据处理能力逐渐跟不上业务发展的步伐。由于尚未构建数据仓库，数据分散难以整合。传统数仓和中台的方案不仅建设周期长、成本高，更需要专业的 ETL 工程师团队，专业门槛成为最大的挑战。在此背景下，如何实现快速的数据分析和数据产品搭建与自主运维成为一大难题。

我们的方案的核心是在数据架构中引入了逻辑编织层。首先，在 ODS 层，直接从 MES 系统中的 Oracle或 MySQL 等数据库映射数据。接下来，在 DWD 层，强制实施了一个 RP 。这一步骤至关重要，因为贴源层中的数据没有历史记录，而在进行分析时，需要有一层能够沉淀历史数据。

在应用层，我们根据客户需求定制了多种报告和质量追溯应用。这些应用的视图是按需进行 RP 的，部分查询可以直接基于 DWD 层进行，Aloudata AIR 内置的 OLAP 引擎结合 RP，使查询效率得到了充分的保障。

实施这套方案后，该企业得以将所有 MES 、 SAP 和 OA 等相关数据汇总，实现了数据的融合与整合，形成了主题式的数据资产。这不仅便于数据的统一管理和指标体系的统一构建，还通过 Aloudata AIR 统一服务了各类场景，包括数字化的经营决策、生产管理以及质量追溯等。

从效果上看，一方面降低了 MES 系统的压力，另一方面使得全链路的生产追溯成为可能，彻底改变了以往依赖人工查询多个系统并通过 Excel 整合数据的繁琐方式，同时实现了多层级的经营全景视图，通过经营看板，让管理层能够看得见、看得清和看得全数据。更重要的是，通过逻辑数据编织的方式可以通过更低成本、更短周期实现数据价值。通过这套方案，该客户在 2 秒内可以实现任意维度的质量数据追溯查询。

Q&A

1.Aloudata AIR 中，很多个不同数据源，有统一的元数据视图和权限管理吗？
Aloudata AIR 提供统一的元数据视图和权限管理功能。

2.很多跑批作业是浪费的，上层查询可能并没有真正用到结果数据，造成了大量的存储和计算浪费，有没有什么方法可以解决这个问题？
Aloudata AIR 内置了灵活的 RP 回收的策略。 RP 如果是很长时间都没被命中过，那就意味着这个 RP 的数据其实是没人会去查的。所以这个时候 RP 就会被回收掉。另一种情况可能是 RP 里面有些数据，很久没有用过了，那这一部分数据可能也会被回收掉。但是回收掉的这些数据，下次还是能查的，只不过说可能会更慢。

3.Aloudata AIR 在查询下推中有什么优势？
Aloudata AIR 基本上实现了全功能的查询下推，能够最大化地将查询下推到数据源中进行处理，即使在复杂的 Join 或 AGG 操作中，Aloudata AIR 也能尽可能地将可下推的算子下推到允许下推的数据源中处理。

4.实际场景中对于 ETL 有限制因素，存在重连断点的这个情况有优化措施吗？
对于 ETL 作业失败的重连断点问题， Aloudata AIR 通过抽象 RP 和 RP 的任务依赖管理来提供优化措施。当 ETL 作业失败时，用户可以在 RP 任务依赖管理中清晰地看到失败的任务并重新运行。

5.物化视图是分区表吗？系统会自动设置分区字段吗？
RP 的生成过程与物化视图不同，但其命中过程与物化视图相似。 RP 可能对应底下的一个 ETL 作业、同步任务或实时计算作业，这与传统的物化视图有较大差别。然而，从命中的角度来看，它们都能解决物化视图的命中问题。此外， Aloudata AIR 在加工过程中能够自动识别分区，并根据源头表是否为分区表来推导是否可以进行分区构建。如果可以进行分区构建，则生成的加工作业将依据这种分区构建的逻辑来生成数据。

6.部署这个产品需要支持什么？软硬件的要求是什么？
主要取决于使用场景和数据规模。如果企业已有数仓或跑批引擎，则可以通过 Aloudata AIR 融合这些引擎的能力和数据。这种场景下，查询引擎的部分作业，就可以直接连到企业自己的引擎上面去跑。在既有引擎的情况下，如果企业场景比较简单，数据量也不大，那可能部署一台 8C 32G 的机器就够了。

7.底层的存储计算引擎是需要另外搭建吗？
底层存储计算引擎是否需要另外搭建取决于具体的使用场景和需求。如果场景中可以下推查询到已有的 Hive、Spark 等引擎，则可能只需要部署一个单机版的产品即可满足需求。然而，如果企业没有现有的引擎支持或者需要支持大数据量的构建和秒级查询等更高级的功能，则可能需要产品内置的存储计算引擎来支持运行。 Aloudata 提供了多种部署方案以适应不同的场景和需求。