数字化转型的浪潮下，许多企业都在不断探索实践如何能将数据进行最大化价值体现。
随着数据应用的场景不断丰富，大量的结构化数据和非结构化数据陡增，数据价值的提升也给企业及开发者们带来了新的问题：巨大的数据量如何能低成本、高效地进行储存、预处理？
01/ 大数据云原生时代，湖仓一体代表了未来
湖仓一体技术的出现，实现了对数据湖与数据仓库技术融合的同时，也为用户带来了新的意义价值。作为数字化转型的其中道路之一，企业到底该怎么走湖仓一体道路？我们可以先看看它给行业带来的改变。
湖仓一体给行业带来的改变
湖仓一体化的出现，实现了数据湖和数据仓库的技术融合，完成了存储、计算引擎架构的统一标准化。对于企业来说，数据湖需要能够帮助业务解决割裂的问题，并做到实现 ETL 、 Data Pipeline 以及 OLAP 全流程。
过去典型的 Lambda 架构，离线与实时需要维护两套架构和业务代码逻辑
Kappa 架构是基于事件的，能够在实时的事务和分析工作负载的所有规模来处理所有的数据。Kappa 架构背后的核心前提是可以使用单个技术堆栈执行实时处理和批处理，而基础设施的核心是流式架构。
Kappa 架构优势：
- 使用单一架构处理所有用例（流、批处理、RPC）
- 一个始终同步的代码库
- 一套基础设施和技术
- 基础设施的核心是实时、可扩展和可靠
Kappa 架构是理想的实时数仓方案，业界最常用实现就是 Flink + Kafka，然而它也有缺陷：
- Kafka 无法支持海量数据存储
- Kafka 无法支持高效的 OLAP 查询
- 无法复用目前已经非常成熟的基于离线数仓的数据血缘
- Kafka不支持 update/upsert
基于湖仓一体的 Kappa 架构，使用数据湖替换 Kafka 消息队列，数据湖天然支持海量存储、高效查询、支持更新等的特性。然而不足的是其无法响应毫秒级场景，数据时效性降级到分钟级。
湖仓一体架构的演进，融合了离线、实时数仓的能力与优势，企业无需维护两套技术架构，在业务层面加工处理逻辑可以复用。使用一套架构解决报表分析、实时计算等场景，让企业更聚焦上层业务场景而无需关注底层架构。
02/湖仓一体是什么？
湖仓一体：存算分离架构，计算层支持主流 Flink、Spark 等计算引擎
湖仓一体作为新型的开放式架构，打通了数据仓库和数据湖，并将两者的高性能及管理能力与灵活性融合，其底层支持多种数据类型并存，能够实现数据间的相互共享。并在上层可以通过统一封装的接口进行访问，同时支持实时查询和分析，让企业在进行数据治理使能更便利。
关键技术栈
湖仓一体架构的存算分离，存储和计算引擎层面可以根据企业自身发展可以选择在HDFS和云存储方案、计算引擎进行平移，而不影响上层组件与业务。模式演化是数据湖重要特性之一，支持对表的结构进行微调，例如添加“列”，满足数据变化的需求。
湖仓一体解决三大痛点
（1）修饰原架构的不足
相比数据湖来说，湖仓一体架构能够修饰了 Hadoop 技术对于数据实时处理能力的不足，实现对实时查询和实时分析场景的支撑。与数据仓库对比，湖仓一体架构避免了数据仓库无法分析非结构化数据的问题，以及不同平台间数据移动所带来的成本。
（2）为企业实现降本增效
湖仓一体架构能够降低数据流动带来的开发成本及计算存储开销，提升企业效率。
（3）助力企业数字化转型
在企业数字化转型过程中，单一系统架构模式已然无法满足目前业务场景及发展需求。而湖仓一体架构能够帮助企业构建起全新的数据融合平台，打破数据湖与数据仓库割裂的体系。
03/
企业该如何走湖仓一体化道路？
企业是否需要自建湖仓一体？需着重考虑哪些方面？
湖仓一体作为一个新兴架构，部分企业已开始尝试接触探索。但目前很多企业还处于湖+仓的融合架构：现阶段企业引入数据湖方案，主要目的是实现实时同步加速数据入湖；供后续数仓加工过程提升数据时效性，这种融合架构数据湖通常作为数据源层供数仓使用。
企业尝试落地湖仓一体时会遇到的问题和挑战：
若团队没有足够好的数据治理或数据管理经验，面临的挑战会比较大，同时还需有效的平台支撑。
其次，对于自建湖仓一体的企业，特别是在已经有数仓的企业环境中，即将面临湖仓之间如何协同、两套系统存储打通、元数据如何保持一致性、湖和仓上不同引擎之间数据交叉引用，以及网络带宽安全等高复杂度的问题。
另外，由于湖仓一体架构底层的二元体系特性，那向上面向用户的时候，用户是不是能看到两个体系？如果用户能够看到两个体系的话，如何区分和引导？如果用户看不到的话，那底下开发需要做什么样的封装？这些都是湖仓体系中会遇到的问题。
随着企业数字化转型的深化，企业在建设数据中心时，需要投入大量人力、物力等资源，还需要具备专业的知识的高级人才。
在业务层面，IT建设本质目的是服务上层业务；而大数据技术组件众多，单一组件通常只能解决特定领域问题，因此企业在做技术和架构选型时，需要综合考虑业务场景和技术架构的贴合度。
惟客是如何将湖仓一体进行落地的？
（1) 建设湖仓一体前
数仓架构
湖仓一体架构
在使用湖仓一体之前，惟数平台的技术架构是基于开源 HDP 套件构成，数仓主要使用 Hive + Tez 引擎跑批。实时平台使用 Flink 引擎实现数据准实时落地到Hive 数仓，是典型的 Lambda 架构。
Lambda 架构缺点
结果数据口径不一致问题：因为批量和实时计算走的是两个计算框架和计算程序，算出的结果往往不同，数据结果不稳定。
批量计算性能问题：在 IoT 时代，数据量级越来越大，跑批作业在夜间只有很短几小时的时间窗口，已经无法完成整天的数据处理。如何保证每天准时出数据成为每个大数据团队头疼的问题。
运维成本问题：Lambda 架构需要在两个不同的 API 中对同样的业务逻辑进行两次编程，批量计算的 ETL 与流式计算的 Streaming 系统。针对同一个业务场景需要维护两个代码库，两套代码的维护需要投入很多人力，而经常发生逻辑没有对齐等问题。
为了解决上述问题，惟客数据团队在很早之前就开始进行数据湖技术的架构研究和引进的工作。借助数据湖特性，在数据 ETL 过程中，时效性大幅提升，其次在计算引擎方面为后续流批融合做铺垫。
开源技术日益创新，同时也是跟进开源发展前沿技术；以保持惟客在行业中立足与技术、经验的沉淀。
湖仓一体化的技术架构对企业数据能力的价值：数据湖的灵活性与生态丰富性以及数据仓库的成长性、企业能力都能被其发挥出，湖仓一体同时也能为企业实现数据资产的建立、实现数据业务化、进而推进全线业务智能化，实现数据驱动下的企业数据智能创新，全面支撑企业未来大规模业务智能落地。
（2) 建设步骤
惟客在设计湖仓一体架构过程中，融合 Lambda 和Kappa 架构优势，充分考虑数仓、数据湖技术的特点，同时保障数据大规模存储与数据处理的时效性（分钟级）。惟客基于 Hudi 构建的据湖产品便是这种融合方向的一个案例，它强化数据贴源层端的数据入湖功能，并在此基础上通过统一元数据和统一调度实现一定程度的数据聚合和应用。
湖仓基于存算分离架构构建：批流、实时流所有数据统一入湖。
Datain 离线数据流：实现离线数据湖能力，数据通过批量集成，存储到 Hudi ，再通过 Flink/Spark 计算引擎进行ETL处理。
CDC 是实时流：数据通过 CDC 实时捕获写入消息队列转存，即能实时写入 Hudi ；也可以实现实时数据ETL处理，避免多次同步业务数据库而影响业务库的稳定性。
现在有一部分企业已经有了自己的大数据架构，这些企业相对来说可能诞生的比较早，大多数都是选的 Hadoop 体系，或是自建的 Hadoop 体系，或是使用云上托管的 Hadoop 体系，这些路径该如何进行抉择？
通常需要看企业是不是希望在大数据技术栈上做更多投入：如果企业觉得没必要在基础设施上投很多资源，而是要把更多资源放在业务上，那选一个更偏全托管版的湖仓一体解决方案更有价值。反之，如果企业技术人员很多，希望底层基础设施足够灵活并且是自己可控的，就可以选择在湖上建仓的模式。
建设的成本主要来自哪里？
如果企业选择全托管的湖仓一体解决方案，则成本主要来自于对当前数据，比如数仓迁移、数据整理等一次性开支，一旦这部分工作做完，后续在数据治理上形成正循环，整体成本不会太高。如果企业选择自己维护一套湖仓一体架构，则成本主要来自持续维护和调优整套基础设施的人力成本和硬件成本。
惟客在建设湖仓一体时，企业希望把业务场景都做成实时计算或实时指标，由于实时计算的资源成本、架构复杂度很高，而且大多数情况下都是伪实时需求。因此在设计实时场景时需要明确业务边界，在有限的资源中实现业务最大化。
在数据采集方面惟客数据支持整库、多表方式实时同步入湖，但也需要考虑资源占用率，建议根据业务场景或超大表来挑选出有实时诉求的小部分表实现实时入湖。
纵观以往IT建设当中没有银弹，但湖仓一体架构作为技术型工具可以为企业提效。同时，企业也需要贴合自身业务场景、发展规划提前布局上层数据应用产品。
