近年来，信息技术迅猛发展，伴随着云计算、大数据、人工智能等技术的快速发展和传统产业的数字化转型，数据量呈现几何级增长。根据市场研究资料显示，全球数据总量将从 2016 年的 16.1ZB 增长到 2025 年的 175ZB ，十年内将有 10 倍的增长。面对如此海量的数据，如何通过智能化手段将数据有效转化，成为企业新的挑战。

基于这样的需求，完全纯数据仓库不适宜半 / 非结构化数据的处理；而单纯的数据湖虽然适合存储数据，但它们不支持事务处理，不保证数据质量，并且缺乏一致性/隔离性。对此不少企业都曾纠结于数据湖和数据仓库的二选一，那么是否能有一种方案能将二者的优势融合，将这类“选择题”变成令人舒服的“肯定题”？如今这类肯定题已经出现：一种结合数据湖和数据仓库优势的方案诞生了——湖仓一体化。它实现了数据湖和数据仓库之间的无缝流转，打通了数据存储和计算的不同的层面，兼顾数据湖的灵活性和数据仓库的成长性，将二者有效结合起来为用户实现更低的总体拥有成本。

鱼和熊掌两手抓——“全栈式”数据平台 FastData

作为数据智能服务商，滴普科技围绕数据智能技术，构建了新一代云原生数据智能平台 FastData，它服务于企业建立流批一体和湖仓一体的数据存储计算平台和数据科学分析平台。相较于传统的数仓和数据湖产品，FastData 具备三大优势：

• 低成本：FastData 可以为企业降低底层大数据平台的建设和运维成本，减轻企业对于整个技术体系的依赖程度，相比原经典的大数据平台而言，可以节省 40%—50% 的成本。

• 高性能：FastData 在满足低成本的同时,仍具备处理 PB 级结构化、半结构化以及非结构化的数据，在实时流计算的场景可以实现秒级的同步和计算，可以满足大型企业实时或准实时的数据处理要求。

• 易使用：FastData 打造了一个 IT 工程师、数据工程师和数据科学家能够一体化操作的数据智能平台，进行数据的智能化运营。

FastData 通过湖仓一体，同时吸收了数据仓库和数据湖的优势，可以解决多模数据管理复杂的问题，实现快速分析应用与数据价值深度的发掘，加速业务价值创新，相信客户面对这样“鱼和熊掌兼得”的产品很难不心动。

同时，基于高性能分布式对象存储基础设施，FastData 采用云原生、存算分离架构，为了实现“全栈式”的数据平台级服务，滴普科技核心研发了实时PB级数据引擎 DLink、数据智能开发平台 DataFacts，用于企业数据科学分析、可视化建模、机器学习等的数据科学分析平台 DataSense，以及数据资产管理和运营平台 DXP。

我们以 FastData 中的“PB 级大心脏” DLink 为例，DLink 的核心理念就是“统一”，它基于 Iceberg、Flink 和 Trino 技术栈，提供多种数据类型的统一存储能力，支持高质量的流批一体数据整合，其特点包括海量数据存储处理、多样数据格式与来源、新数据高速产出、数据解释可变性高、数据遵循流畅一致性强、可供消费数据波动性高等。

DLink 融合了实时数仓和数据湖服务，采用存算分离架构，弹性扩展、高并发、低延时，支持 PB 级多模数据存储与处理，无缝连接大数据生态，提供一站式的数据探索（汲取）、实时开发、数据分析和数据科学（机器学习），满足 BI、实时看板等应用需求。
可见在未来数据智能赛道方向，凭借 DLink 如此强大的数据处理、探索和开发能力，将为客户的发展带来极大的技术支持。介绍了这么多，光说不练假把式，当下 DLink 已经在为企业服务了吗？没错，而且应用领域极为广泛。我们接下来就看看 DLink 在企业中的实战能力吧！

数据智能如何驱动千行万业数据转型

想了解 DLink 的实战能力，那我们就以某知名服饰集团的实时报表分析查询为例。某知名服饰集团旗下拥有多个品牌，线下门店数量总计 2100 多家，但在数字化升级中面临着亟需升级的地方：

• 客户需要通过大屏、移动端 BI 等展示提供实时数据，来监测数据的变化；

• 业务平台需要实时业务产生的标签，进行数据查看及分析；

• 需要给数据热点、云客服、业务监控预警、业务辅助决策等场景提供数据服务。

而该项目的技术动因主要有：1.公司凌晨大批量启动调度任务，数据仓库、数据平台存储资源与其他系统公用，随着数据量及相关报表数量增加，并发调度压力越来越大；2.相关报表数据计算错误无法及时发现，影响相关决策。

2、DLink 将 ODS层 数据经过初步计算写入 DWD-数仓明细层

3、DLink 将 DWD数仓明细层 数据经过计算写入 DWS-数仓汇总层

4、最后通过 Java 应用把数据格式转换成应用层需要的格式写入 DM

5、应用层从 DM 直接取数据展示

正是有赖于 DLink 在实时计算和即席分析能力方面的支持，该实时报表查询项目数据时效性得到大幅提升：完全实现所有数据服务由 T+1 时效迈向 T+0 秒级服务；此外它满足实时业务场景需求，实现精细化运营，增加数据价值：实现实时分析、实时推荐、实时检索等场景；同时它也减轻了批量处理压力：相关业务平台和报表的实时计算的标签可迁移至实时平台进行计算减轻了批量数据处理压力，并且能将计算结果快速反应到业务平台。

此外，滴普的产品还应用在了更多行业领域。据介绍，目前滴普科技已服务 100 余家企业与用户，其中包括百丽国际、新华联、广州城投、九洲电器、重庆机电、大横琴泛旅游、乖宝宠物、科伦药业、百果园、OPPO、VIVO 等。除了与企业合作以外，滴普科技也与深圳市龙华区、佛山市顺德区、攀枝花东区等政府单位合作，以数据智能推动各行业的数字化转型升级。

打造 DEEPNOVA 社区，让技术繁荣生长

了解了这么多 FastData 的相关技术和湖仓一体的真实收益，那么开发者如何更快投身湖仓一体的技术浪潮呢？进行更进一步的交流呢？开发者社区是重要的新技术生长平台，未来数据智能技术将走向互相融合，所以滴普科技拥抱开源生态之外，也在致力于打造 DEEPNOVA 开发者社区。
DEEPNOVA 开发者社区是面向技术开发者的交流学习、生态共创平台，目的是促进圈层交流，学习互助，开拓技术视野；建立技术生态，合作共赢。DEEPNOVA 是由 DEEPEXI+SUPERNOVA 组合而成，包含了滴普科技的“建社心愿”：滴普科技为技术开发者打造的一颗超新星。俗话说得好，一个人可以走很快，但一群人可以走更远。在 DEEPNOVA，这里已经聚集了一群志同道合的技术开发者，我们正等待着作为超新星的你加入。

另外在 2022 年， DEEPNOVA 社区联合 CSDN 共同推出的“DEEPNOVA 技术荟系列公开课”，第一期将于 3 月 2 日周三 19:30-20:30 开播，直播主题为“数据智能技术前沿与挑战”，我们邀请到了杨磊大神（滴普科技 FastData 产品线总裁）作为此次的直播嘉宾，探讨如何以开放的 FastData 更好地迎接高密度数据场景的新挑战，各位技术爱好者们，咱们到时不见不散哦～

DEEPNOVA 技术荟系列公开课第一期

直播主题：数据智能技术前沿与挑战——以开放心态迎接高密度数据场景新挑战

• 厘清数据管理应用技术趋势与面临的行业挑战

• 分享滴普对于行业挑战的认知与理解

• 运用开放的 FastData 解决行业问题及实践分享

分享嘉宾：滴普科技 FastData 产品线总裁 杨磊
嘉宾介绍：杨磊，北京滴普科技有限公司 FastData 产品线总裁，中国信息协会大数据分会常务理事。资深技术专家，在操作系统、分布式软件体系、编译等领域有突出贡献，曾任大型集团企业超大规模分布式架构的核心架构师。

在华为深耕 12 年，其中 10 年为技术岗，曾任操作系统内核专家、分布式系统平台核心架构师，带领核心技术团队实现在超大规模压力下的系统稳定和扩展能力。两年担任海外 marketing 总工角色，作为技术负责人拓展海外市场，突破市场制高点。

2018 年，联合创立数据智能服务商滴普科技，基于云原生架构，打造新一代数据智能平台 FastData。FastData 是面向数据智能场景的新一代 PB 级实时数据产品，帮助企业建立流批一体和湖仓一体的新一代数据存储计算平台和数据科学分析平台。不断突破创新，已带领团队成功服务超 100 家大中型客户，覆盖先进制造、生物医药、能源出行、政务双碳、金融科技、消费流通等领域。

顶级项目。本文会从Hudi诞生背景条件出发，搞清楚Hudi最初是为了解决什么问题而出现的。

随着大数据技术的发展，逐渐发展出了两种比较成熟的计算模型：
一种是批处理模型，技术栈以Hadoop为代表，其特点是规模大，容错高，延迟高，主要应用在离线的大规模分析场景下；另一种是流处理模型，技术栈以Strom/Flink此类流处理框架为代表，其特点是延迟非常低，主要应用在要求延迟很低的实时场景下。这两种模型覆盖了绝大多数大数据的应用场景。

但是在流处理与批处理之间却存在一个模糊的边缘地带，即延迟在5分钟~1小时的范围，在这个范围内，既可以用批处理技术也可以用流处理技术，称为近实时（Near Real-time）需求。比如过去若干分钟某些维度指标的变化统计。

此类场景有有以下3个特点：
1、对延迟度要求在亚小时级别。
2、数据来源于业务数据的统计分析（可能存在多表join）。
3、数据在业务窗口期内会变化。

3、传统模型的解决方式

3.1、利用批处理解决近实时问题
批处理模型面向离线计算场景，需要将数据从业务数据库导入数仓中。这个阶段采用Select * From Where Condition查询数据的方式。Condition通常是时间维度，并且选择也会综合考虑业务数据库的受影响程度来确定启动周期，一般选择隔天的凌晨业务量小的时间段拉取前一天的数据。数据导入完成后，再进行计算作业。

当使用批处理模型来解决处理近实时场景需求时，需要将调度周期设置为5分钟~1小时，这会带来一些问题。

3.1.1业务数据库负载

Select * from Condition 是一个代价很大的操作，正常批处理都会选择业务量小的时候进行，避免影响业务。若为了支持近实时业务而将任务间隔设为每分钟或每小时，会对业务数据库产生非常大的压力，有可能对业务产生影响。

3.1.2无法忽略的数据更新

同样是Select的问题，通过SQL查询数据的方式，获取变更数据需要额外的条件，并不是所有情况都能通过select获得变更数据。这在传统的离线处理场景下，产生的影响相对较小。因为时间范围和启动周期都基本都在24H以上，绝大部分数据都不会再发生变化，且此时的数据量级为天级，数据量较大，即使有个别数据没有更新，对最终结果的影响程度也可以忽略不计。

但是在近实时场景下：因为启动周期的缩短，在这期间数据变化的概率大幅上升，同时数据总量在大幅减少。此消彼长，最终结果的正确性就无法得到保证。因此，在近实时场景下，批处理不支持数据更新的问题带来的影响，很有可能无法被忽视。

3.2、利用流处理解决近实时问题

流处理主要用来应对延迟要求低的实时计算场景，一般处理事件驱动的场景。因此，近实时场景天生可以直接使用流处理模型进行处理。但由于近实时场景的面向的事件时间在5分钟_{1小时之间，相比较于秒级时间窗口的事件，利用流处理技术处理时间窗口为5分钟}1小时的数据时，会带来更大的成本。

3.2.1、更大的内存消耗

在处理业务数据库的Changelog中的update/delete语句时，需要基于对应的历史数据进行操作，这就需要将大量的数据载入内存中。而相比较于处理秒级别的实时任务，近实时的时间窗口由于在5分钟~1小时之间，这会导致近实时任务需要数倍甚至数十倍于秒级实时任务的内存资源。

3.2.2、峰谷资源错配

因为需要实时处理，处理任务需要一直运行，占用的资源大于批处理所需的资源。当业务高峰来临时需要更多的资源用于支撑业务，这部分资源在业务低谷期来临时，就可能无法得到高效利用，如果是云上系统还好，可以将资源释放，如果是自建机房，那么多出来的资源就有可能造成浪费。

使用批处理和流处理两种处理模型处理近实时问题时，都有着各自不同的问题。批处理有无法忽视的数据更新处理问题；流处理付出的成本较高，可以说是用牛刀杀鸡。这就难免会让人陷入抉择。那能否有一种处理模型，能够刚好满足需求呢？带着这样的追求，一种新的处理模型被提了出来。

增量处理模型面向近实时场景提出，它的基本结构可以认为是全量数据存储+增量数据处理。数据导入阶段采用变更流捕获将数据导入存储引擎中，在分析计算阶段，查询增量数据进行结果计算

4.2、与传统处理模型的区别

4.2.1、与批处理的区别

与批处理相比，增量处理模型中的存储部分可以支持Update/Delete。这就可以在将批处理中数据摄取的方式从原本的查询数据这一种，拓展为既可以查询数据也可以处理Changelog。

4.2.2、与流处理的区别

与流处理相比，数据模型本质还是批，数据的处理需要周期性的导入和抽取计算，数据需要经过经历内存到磁盘再到内存的过程。

4.3、增量处理模型处理近实时场景的优点

既然增量处理模型面向近实时场景问题提出，那么增量处理在处理近实时场景时相比传统的两种处理模型具备哪些优点

4.3.1、能够应对数据变更

增量处理模型通过引入支持Update/Delete的存储引擎，具备了处理changelog的能力。在面对近实时场景中的变更数据流时，不会出现数据无法处理数据变更的问题

查询的方式来降低对数据库的影响。通常生产级别的业务数据库(OLTP)的日志在数据库本身就需要经过生成，处理，落盘归档，主从同步等一系列动作来保证生产级别的HA。只需要额外的线程获取到changelog即可。此外，通常changelog只需要一条EL作业将其先导入Kafka中作为缓冲，增量模型的EL作业只需要消费Kafka中的changelog即可。相比较于不定时的从业务数据库查询历史数据来说，负载大大降低。

4.3.3、通过批处理降低内存资源占用

增量处理模型将changelog写入存储引擎中，并从存储引擎查询需要分析的数据，相比于流处理需要将数据加载至内存中，增量处理模型的数据不需要将数据加载至内存中。

4.3.4、通过微批计算获得更灵活的调度空间

微批的方式意味着数据导入和计算作业都不需要像流处理作业一样的持续运行，这也就留出了更多的可调度空间。在同样的计算资源下，借助合理的调度系统可以同时容纳更多的计算作业同时运行，为企业节省成本。

增量模型可以说是一种特殊的批，也可以说是一种特殊的流。相比于流来说，它其实是周期性运行的批处理。相比较于批来说，它具备了处理变更事件的能力。它在解决近实时场景需求时所体现出的优点，其实都是在追求收益和成本之间的平衡。

本文介绍了Hudi需要解决的问题—近实时场景的需求，并比较了在大数据领域中两种成熟的处理模型：流处理和批处理在处理此类场景中各自的不足之处。最后介绍了一种新的增量处理模型的处理方式。

增量处理模型以CDC的方式数据摄取，以微批的方式进行计算分析，平衡了延迟和成本。为了应对数据变更，需要引入数据更新/删除操作的支持。不难发现，其中的关键点就是在传统的大数据存储引擎之上提供数据更新/删除的能力，那么Hudi又是做了哪些具体的工作来支持增量处理的实现？请关注下期专题文章。

DCT：滴普科技自研的数据采集传输服务