湖仓一体在大数据支撑上到底强到什么程度，数据处理速度快到什么程度，其实很多人根本无法准确预估。
就像1943年IBM主席在推出老沃森的时候说，世界计算机市场大概需要5台计算机就够了；微软创始人Bill Gates，在1981年的时候认为，640K内存对所有人而言应该就够用了。现在看来，显然是“啪啪打脸”，差的不是一星半点！
今天，大数据正在不断刷新人类认知！在数据量上，企业的数据已由GB增长到TB、PB甚至EB；在数据类型上，不仅可以处理结构化数据，还能处理图片、视频等非结构化数据；在数据分析时效性上，已经从离线过渡到近实时，分钟级实时，秒级实时；在数据架构上，传统的MPP、Hadoop方案，正在被湖仓一体方案代替。基于Iceberg/Hudi的实时湖仓引擎，可以更好地适应大型企业多级数据湖以及多租户数据场景。
近日，由IT168&ITPUB主办的实时数仓和湖仓一体专题研讨会圆满召开，来自金融、互联网、制造等大型企业同聚一堂，共探实时数据架构未来发展。会议期间，滴普科技FastData DLink产品线总经理冯森，以特邀嘉宾身份参加，并以《实时湖仓架构演进与技术实践》为主题，进行技术实践分享。
“作为一种新型开放式架构，湖仓一体结合数据湖和数据仓库优势，可以支持数据的分钟级实时查询、分析，包括当下流行的AI大模型场景，满足用户在流数据分析、机器学习等场景需求。” 冯森认为，湖仓一体之所以成为主流技术趋势，是因为在数字化转型背景下，大规模、高时效、智能化数据处理已是“刚需”，企业需要更强大的数据平台，来应对数据查询、数据处理、数据挖掘、数据展示以及多种计算模型并行的挑战。
那么，具体而言，企业推动湖仓一体项目落地的驱动力是什么？从传统数仓到实时数仓，如何解决数据迁移过程中遇到的问题？湖仓一体有哪些主流的技术架构？会议现场，来自不同行业的专家进行了激烈讨论！
业务诉求是什么？
在很多人的潜意识里，互联网领域是推动湖仓一体实时化数据分析的发源地，这类企业不仅数据量庞大，在业务模式上需要快速作出反应，才能赢得市场，获得核心竞争力。比如：实时营销、实时监控、用户画像分析等场景，都需要大量应用实时数据。
在互联网应用的带动下，金融、制造领域也在向实时靠拢，只不过传统IT架构太过厚重，不知道从何处开始入手，向现代化架构升级。其实，金融、制造领域对于实时数据分析需求，一直都存在，但因为受技术条件限制，企业在IT架构设计之初，无法真正满足业务需求，只得退而求其次。
云原生时代，无论是计算，还是存储，都取得了突飞猛进的发展。对于有着庞大业务体系的央国企来说，既是机遇，也是挑战。
新的数据架构支撑能力，为企业数智化发展带来了更多可能性，湖仓一体可以让企业获得更强大的统一数据管理能力，但完全抛弃过去的架构，会面临很多阻力。在过去多年信息化建设中，企业拥有各种数据库、数据仓库以及数据中台、大数据平台，不可能完全丢掉，重新设计，如何平衡各种应用或平台之间的关系？
答案是，和早期企业信息化部署战略相同，湖仓一体也是“一把手工程”，业务需求拥有最高话语权！
当传统Lambda架构暴露的问题越来越多，比如：传输链路越来越长，消耗的计算资源越来越大，分析的时效性越来越低，进行数据架构的现代化升级，就会成为自然而然的选择。原来那种T+1级别的Hive更新，在资源和性能上都比较差，包括一些索引、统计信息都需要做更多优化。
采用什么样的技术架构？
当企业决定向湖仓一体架构演变，必然会遇到各种各样的问题。比如：数据出仓繁琐，如何确保数据的一致性？如何在不需要人工干预的情况下，打通湖和仓的数据/元数据，让数据自由流动？利用湖仓来达到降本增效的目的，有哪些可观测性的指标？在解决这些具体问题之前，我们先来了解下湖仓一体主流技术架构，只有解决了架构问题，才能从根本降低湖仓一体的技术门槛！
大体来看，企业在湖仓一体架构升级上，可以分为三个梯队：
第一梯队，虽然企业意识到湖仓一体是必然趋势，但具体业务还处于传统IT架构之下，不知道如何进行技术部署。
第二梯队，企业已经在部署湖仓一体架构，通过自研路线向湖仓能力扩展。比如：基于Hadoop体系的数据湖向数据仓库能力扩展，引入数据仓库的分析功能；再比如，以数据库技术为基础，自研分布式平台，让调度、存储和计算都不依赖第三方平台；包括会充分利用云平台架构优势，打通数据湖与数据仓库的壁垒。
第三梯队，采用独立的湖仓一体解决方案提供商的方案，既兼容了Iceberg/Hudi的内核，又能充分利用到云计算的弹性，比如：企业可以按照业务需求，将数据灵活部署在公有云、私有云、裸金属等场景，实现一键入湖、统一管理、快速分析等目标。
无论企业自建、还是选择第三方解决方案，基本都会涉及到Iceberg、Hudi、Delta这三个内核技术。
在滴普科技看来，国内使用Iceberg、Hudi的企业比较多，使用Delta的企业，主要以阿里云为代表，以DLF的方式，进行产品落地。另外，DLF同时也支持 Hudi、Iceberg。整体来看，Delta开源的时间比较晚；Hudi社区相对更活跃；Iceberg在表格式上更具开放性，在计算引擎和存储的抽象上做得更好一些。那么，到底谁好谁坏，我们不做过多评价！
最早，滴普科技的FastData DLink支持Iceberg，随着新版本的更新，同时也支持了Hudi。对于用户而言，到底选择哪一个内核技术，还要根据自己的业务场景去评估。
对比来看，在ACID事务支持上，三者功能相同，基本上都是写序列化或者快照隔离的级别，和传统MPP数据库这种思路一致，我们在写一个新的快照时，可以读到历史的旧快照，这样可以做到读写分离，等新的快照事务提交之后，就可以读到新写的数据了。
同时，在Schema演进上，对于加列减列都支持；分区演进，是指可以支持从天变成小时；隐藏分区，是自动按照小时级别进行数据过滤；行级更新，包括COW/MOR这种表，这种查询方式，基本上也都支持；引擎支持上，Iceberg和Hudi的能力都比较强，可以支持Flink、Spark、Hive、Trino、Presto、Impala等12种引擎，而DeIta大概支持8种主流引擎；计算加推，包括谓词+聚合下推，只是为了更好地查询数据。
用Iceberg 、Hudi架构的核心是，为了解决传统数仓的T+1到T+0的演进，最主要的是支持流写和流读，这也是构建实时湖仓的关键。在流写支持上，三者功能相同；但在流读上，有一点差别。在开源社区版本，Hudi是可以支持append、update、delete的流读、流写，Iceberg支持append。
滴普在开源社区基础上做了改进优化，去年2月份的时候，滴普就已经支持了Iceberg CDC流读的能力。用户可以基于FastData DLink构建PB甚至EB级别的数据分析平台，构建出一个分钟级别实时的入湖项目，但在数据分析上，可以达到秒级。当然，到底什么级别，也要看业务场景，还有数据量。一般，可以做到分钟级别，最差也是小时级别的数据入湖。
解决哪些问题？
问题是，都在谈湖仓一体，滴普科技的FastData DLink有哪些差异化特色，能帮助用户解决哪些问题？
从底层来看，FastData DLink可以把不同数据源的数据统一到一个平台，包括业务库数据，kafka过来的数据，还有API数据、物联网IOT的数据，都可以入湖。FastData DLink可以把大约20种不同数据源的数据，以流批一体的方式进行入湖，包括支持离线和实时分开的一种入湖方式。
FastData DLink支持不同的存储方式，包括对象存储、块存储。表格式层，支持Iceberg 、Hudi，做了一些索引，Hudi本身的索引方式，会比Iceberg好一点。加速层，做了文件、语义、索引等一些缓存，数据可以缓存到内存或者本地SSD磁盘。
元数据这层，做了一个统一元数据，好处是什么呢？不管湖上面有什么功能，对接的是Flink还是Spark，都可以做统一的数据的视图。当然，对于外部的话，不管从CDH或者CDP迁移过来，还是想将原有应用迁入，比如Hive，也可以通过元数据这层访问到数据。另外，还可以控制数据安全，设置数据权限。
总的设计思路是，数据进来，在湖仓进行建仓分层之后，用户可以直接对接一些实时的报表，包括一些精确的场景，可以通过一些算法，也可以导入一些服务商，提供更好的并发以及时效性支撑。
FastData DLink的客户案例，遍布各行各业，包括金融、制造、能源、零售等，很多业务场景都是直接替换。
从传统的T+1变成小时、分钟甚至是秒级的业务响应能力，FastData DLink让企业距离数智化转型的目标越来越近。
借FastData DLink实时湖仓平台，企业可以把业务、生产等不同数据源的数据，边缘计算设备数据上传到一个平台，然后通过滴普数据集成工具，与FastData DLink核心平台连接，这个平台可以部署在企业的任意云上，通过集团主数据湖进行流式计算、联邦查询等。
同时，主湖和区域湖之间，要能够实时进行共享和交换，最终以实时数据的形式服务于各个应用场景，满足研发、生产、经营决策等各个环节的业务需求。
这两年，大数据领域流行一个概念，叫做NOETL或者零ETL。滴普科技在湖仓一体的技术创新，让我们看到一个新的变化，那就是大数据基础设施技术正从数据库、数据仓库、数据湖演进到湖仓一体架构，这种架构的最大优势是，全面缩短了数据链路，更好地满足业务时效性要求，为用户高效、实时、全面的数据分析服务，提供了坚实的技术底座。
所以，在梳理湖仓一体用户需求、内核技术、应用实践以及大数据发展背景之后，国家战略性企业（央国企和金融类企业）为什么开始大面积部署湖仓一体技术路线，也就不难理解了！
