石家庄做网站制作,苏州seo排名,焦作网站建设服务,顺德网站建设基本流程湖仓一体架构理论与实践汇总 软件研发本质上属于“手工业”。软件研发在很大程度上还是依赖于个人的能力。当软件规模较小时#xff0c;依赖“手工业”可以解决问题#xff0c;但是当软件规模大了之后再依赖“手工业”就不行了。 软件的复杂度包含两个层面#xff1a;软件…湖仓一体架构理论与实践汇总 软件研发本质上属于“手工业”。软件研发在很大程度上还是依赖于个人的能力。当软件规模较小时依赖“手工业”可以解决问题但是当软件规模大了之后再依赖“手工业”就不行了。 软件的复杂度包含两个层面软件系统层面的复杂度和软件研发流程层面的复杂度。 在软件系统层面上针对大型软件“when things worknobody knows why”俨然已经是一种常态。 对于大型软件来讲复杂才是常态不复杂才不正常。 软件系统很难一开始就做出完美的设计只能通过功能模块的衍生迭代让软件系统逐步成型然后随着需求的增加再让功能模块进行衍生迭代因此本质上软件是一点点生长出来的其间就伴随着复杂度的不断累积。 软件生长示意图 软件复杂度的分类 最常见的错误方式是采用DDDDeadline Driven Development期限驱动开发用Deadline来倒逼研发团队交付业务功能。但大量的实践经验告诉我们软件研发就是在需求范围、软件质量、时间进度这个三角中寻求平衡的。 软件研发的三角平衡 上述做法从表面上看可以更快地取得进展快速摘取成功的果实但是经过一段时间之后一般是618个月负面效果就会凸显出来会显著降低研发的速度和质量。而且这种负面效果是滞后的等问题能够被感知到的时候往往已经形成一段时间软件架构的腐化就是这样在不知不觉中形成的。 以上这种急功近利的做法本质上是将长期利益让位于短期利益过度追求短期交付效率最终的结果只能是“欲速则不达”。 正确战略方向下的“慢”远远好过错误方向下的“快”。作为技术管理者必须学会两者之间的平衡之道并为此长期承担后果。 软件工程的发展 软件工程 1.0 “软件工程1.0”即第一代软件工程自然是受建筑工程、水利工程等影响的传统软件工程。 传统软件工程主要是向土木工程和工业工程学习吸收其百年实践积累下来的方法和经验以及沉淀下来的思想。 软件工程1.0体现了以下特征 (1)产品化只是交付符合质量标准的组件、构件和系统没有认识到软件的柔性和数字化特性把软件当作传统工业的产品由此产生“软件工厂”这样的思想。 (2)结构化受传统建筑工程的影响重视框架和结构的设计表现为以架构设计为中心进行结构化分析、结构化设计、结构化编程等。 (3)过程决定结果流程质量决定产品质量一环扣一环相信良好的过程产生良好的产品关注过程胜过关注人非常关注过程评估和过程改进CMMI Capability Maturity Model Integration能力成熟度模型集成就是其典型代表。 (4)重视质量管理引入传统的质量管理体系包括以顾客为中心的全面质量管理和缺陷预防。 (5)阶段性明确需求评审通过才能开始设计设计评审通过才能开始实施编程编程结束再进行测试等瀑布模型是其典型代表模型。 (6)责任明确角色定义清晰分工细致。 (7)文档规范化强调规范的文档定义了大量的文档模板。 (8)计划性强具有完整的计划并严格控制变更。 (9)注重项目管理围绕项目开展管理工作包括风险预防、里程碑控制、关键路径法等。 软件工程 2.0 受互联网、开源软件运动、敏捷/DevOps 开发模式的影响最终形成的建立在SaaS Software as a Service软件即服务、云之上的软件工程定义为“软件工程2.0”。 开源软件运动让我们首先认识到 “软件过程”和“软件管理”并非非常重要至少不是第一要素因为第一要素还是人 其次是软件架构简单且能解耦如采用SOAService-Oriented Architecture面向服务的架构、微服务架构来解耦更具可扩展性 再者是代码的可读性、可测试性使代码具有可维护性而流程和管理虽然具有价值但作用不大。 互联网的普及、开源软件运动以及市场的变化更激烈的市场竞争、客户希望的按时高质量产品、灵活性、及时修改满足新需求等以及加上软件本身是一种知识性产品所有这些都引导人们对软件工程进行新的思考并不断认识软件工程从而在2001年17位软件开发轻量型流派掌门人联合签署了《敏捷软件开发宣言》。 之后逐渐形成了敏捷/DevOps 开发模式、精益软件开发模式等即软件工程进入2.0时代。软件工程2.0的特征可以简单概括为下列几点 (1)SaaS软件更多的是以一种服务存在。 (2)强调价值交付只做对用户有价值的事情加速价值流的流动。 (3)以人为本个体与协作胜于流程和工具充分发挥个人和团队的创造性与潜力拥抱变化敏捷开发或轻量级过程加速迭代以不变应万变。 (4)自我管理的团队像一家初创公司一样运营具有主动性并能够承担风险具有自治能力能自主建立目标和制订计划不断反思持续改进。 (5)持续性阶段性不明确持续构建、持续集成、持续测试、持续交付以时间换空间消除市场风险。 (6)开发、测试和运维的融合强调测试与开发融合开发与运维融合推崇全栈工程师等。 (7)真正把用户放在第一位用户、产品经理尽可能参与团队开发过程注重用户体验千人千面。 (8)知识管理将软件工程纳入知识管理的范畴强调将项目的计划、估算等工作授权给从事具体工作的开发人员如任务安排不再由管理者下达任务而由开发人员自主选择适合自己的任务。 (9)更有乐趣“史诗故事”、用户故事、站会等让软件开发工作更有趣、更健康。 软件工程3.0 随着将GPT-4指GPT-4及其未来升级的版本融入软件开发生命周期中开发人员的使命将会发生变化因为GPT-4重新定义了开发人员构建、维护和改进软件应用程序的方式。 之后的软件开发会依赖这种全新的语言交流方式类似于ChatGPT让这类工具理解开发人员交代的任务自主完成软件开发如理解需求、自动生成UI、自动生成产品代码、自动生成测试脚本等。 此后开发团队的主要任务不再是写代码、执行测试而是训练模型、参数调优、围绕业务主题提问或给出提示。 因此我们说GPT-4将开启“软件工程3.0”新时代2023年是软件工程3.0的元年软件工程3个时代的划分如下图 软件工程3个时代的划分 GPT-4 在 软件工程上的能力 1、软件需求获取、分析与定义 2、软件设计与体系结构提供建议、识别设计模式、分析和优化软件体系结构以及分享最佳实践和框架方面的知识为软件开发人员提供有价值的帮助等 3、代码生成和优化如代码生成、代码补全、代码评审、代码优化等工作 4、测试用例和测试代码等生成 5、错误检测和解决 6、协作和知识共享如在团队讨论、头脑风暴会议、代码审查时提供实时帮助形成会议纪要、总结理清逻辑和发现问题并提供有价值的见解等 GPT-4支持更智能、更高效和协作的开发方法给软件工程领域带来了革命性的变化。软件开发的新范式是模型驱动开发、模型驱动运维在 DevOps 两环前面加一个环形成三环联动如下图所示 软件工程3.0开发范式示意图 其中机器学习(Machine LearningML)中的要素有模型(Model)、数据(Data)而研发经过计划(Plan)、创建(Create)、验证(Verify)、打包(Package)、发布(Release)等环节进入运维运维有两个关键环节配置(Configure)和监控(Monitor)。 由此我们可以看到在软件工程3.0时代软件即模型(Software as a ModelSaaM)这个模型不同于过去软件工程1.0或软件工程2.0时代所谈到的抽象模型如UML中的模型、OMGObject Management Group对象管理组织所提的模型驱动架构(Model Driven ArchitectureMDA)中的模型 而是深度神经网络模型、大型语言模型(Large Language ModelLLM)或其他人工通用智能(Artificial General IntelligenceAGI)模型可以直接给人类提供服务的模型。 在基于MaaS的软件工程3.0时代软件以这类AI大模型的形态为用户提供各种各样的服务而且未来会成为一种常态。 框架与时代的演变 VUCA 时代 VUCA中文发音一般为“乌卡”的含义如下 ● VVolatility易变性。 ● UUncertainty不确定性。 ● CComplexity复杂性。 ● AAmbiguity模糊性。 VUCA 时代信息无时无刻不在发生变化用户的需求也无时无刻不在发生变化甚至用户自己也不知道想要什么。 MVP(最小可行产品) 21世纪初产品创新领域提出了MVPMinimum Viable Product最小可行产品来面对VUCA时代其中的思想源头是人们思维方式的迭代。 演绎、归纳和假设-演绎逻辑 而MVP就是产品人对“假设-演绎”方法论的应用。通过MVP方法不断完善产品这是一个螺旋上升的过程每一次产出既是目的也是手段。作为目的创造了用户价值满足了用户需求作为手段让我们获得反馈知道下一次迭代应该做什么。这样我们就把做产品从一次研发的“有限游戏”变成不断螺旋上升的“无限游戏”。 M2V6P 框架 在MVP的基础上笔者扩展出了自己的M2V6P方法论框架主要原因是觉得一开始就做产品还不够“低成本”其实可以更灵活。 M是Minimum最小化的意思意味着每一步都要尽量少地投入。 2V是Viable可行性和Valuable有价值这里加了一个V是因为产品创新要面临两大风险这里用Viable表示要对抗技术风险用Valuable表示要对抗市场风险。 6P的含义 第一个P是Paperwork案头研究重点考查问题是否存在是否值得解决。 第二个P是Prototype原型样机重点考查是否有解决方案。 第三个P是Product产品本身要看解决方案能不能产品化。 第四个P是Promotion营销推广考虑的是如何把数量做大。 第五个 P 是 Portfolio产品组合是在单一产品的基础上要推出更多相关的成功产品。 第六个P是People人才考虑的是更长周期即当行业兴衰不可避免时组织如何永续。 其中前两个P(PaperworkPrototype)对应前产品阶段。 中间两个P(ProductPromotion)对应单一产品阶段。 最后两个P(PortfolioPeople)对应产品矩阵阶段。 某公司数据湖仓一体化实践 某公司大数据技术的历史状况 某公司的中台产品-数字云的架构是基于Hadoop生态体系构建而成的在存储方面使用了分布式文件系统HDFS(Hadoop Distributed File System)首先利用自研的数据同步工具Data-in 定时同步业务系统的数据到数据中台然后利用不同的数据处理引擎分别进行离线和实时计算的加工。 离线数仓数仓为数据仓库的简称的加工采用Hive 作为离线数仓工具以Tez 为数据计算引擎的架构方案每天定时对数据进行加工和处理并给到业务方。 离线数仓的数据采集、计算任务的调度周期大多数都以天为颗粒度。为了能够在第二天上班前计算好报表数据数据采集任务都集中设置在凌晨执行因此凌晨成为资源消耗的高峰期。 针对需要实时处理的场景需要再投入大量资源建设一个实时数仓 由于离线与实时使用的技术栈不统一因此系统需要投入更多的资源来维护。 这样的弊端有 1、每天数据全量同步给数据库给数据库造成巨大压力也增加了业务系统的不稳定因素给集群的存储带来较大压力成本 2、集群的资源利用率不均凌晨高峰期紧张白天资源大部分处于限制状态。 离线数仓架构 数字云在实时数仓上采用的是 Lambda 架构设计之初是为了在处理大规模的数据时同时发挥流处理和批处理的优势。 通过批处理提供全面、准确的数据 通过流处理提供低延迟的数据 从而达到平衡延迟、吞吐量和容错性的目的。 Lambda架构有实时链路和批处理链路两条数据链路数据采集使用流式同步工具数据流实时地流向两条链路。 实时数仓使用Canal、Debezium等CDC(Change Data Capture)工具。 批处理链路的数据会落地到Hive数仓 实时链路为了提升数据使用的可重复性将数据写入 Kafka 消息队列。 在实际的业务场景中一般企业的做法是同时利用 Lambda 和离线数仓两种方式搭建架构。 这种架构的缺点是引入的组件多、架构复杂维护成本高实时计算和批处理的计算结果不一致会导致数据质量等问题存在两个编程接口需要开发两套程序增加了开发人员的工作量与代码的维护难度。 Lamba 架构 某公司大数据技术遇到的挑战 户业务的复杂度不断提升数据计算任务随之不断增加这在应用层面上对惟数云的技术提出了新的挑战。 (1)离线和实时的任务分离。 数据开发人员需要维护两套不同的技术代码和任务 基于Flink的实时采集运算和基于Hive的离线任务调度使数仓的开发、使用、运维都有诸多不便。同时也会导致数据计算冗余。 Flink处理当天的实时数据每日凌晨离线的Hive又将业务系统白天产生的数据重新加载一遍进行批量计算这样同一份数据在实时计算与离线计算中分别被存储起来增加了额外的存储成本而且因为离线计算需要在每日新增数据全部被重新采集后才能进行数仓模型的运算所以就使得前端数据指标的计算时间被压缩。 (2)历史数据更新困难。 在传统企业中由于交易性数据业务的特殊性需要更新历史订单数据Hadoop并不支持对行级数据的单独更新和删除操作因此需要将历史数据与变动数据进行全量匹配才能找出更改的部分需要将历史数据与变动数据进行重新合并才能实现数仓中的数据与业务系统中的数据的一致性这样通常会因为对一小部分历史数据的更新而把上千万条历史数据进行重算大大浪费了服务器的资源。 数据架构技术发展阶段 随着企业业务与技术的发展大数据架构也经历了数据仓库、数据湖、湖仓一体三个发展阶段。 数据仓库主要满足了企业内部业务部门对经营数据局部数字化分析的需求让结构化数据能够被标准化加工处理和分析应用。 2011年衍生于“数据湖”的大数据架构技术典型的开源技术是以 Hadoop 提供分布式存储和分布式计算为基础的大数据架构中的“数据湖”技术。 数据湖的特点数据存储的格式灵活多样针对结构化、非结构化的原始数据都能进行很好的兼容强调存储与使用的灵活性和兼容性方便使用者随取随用。 湖仓一体的概念于2020年被首次提出指将数据湖与数据仓库的架构进行融合是一种将数据湖的灵活性和数据仓库的易用性、规范性、高性能结合起来的新型融合技术这项技术既满足了数据仓库的规范化建设也体现了数据湖使用的便捷性。 湖仓一体技术趋势 湖仓一体技术的核心思想是将数据仓库和数据湖之间进行联通实现数据存储和计算架构的统一化与标准化。同时数仓一体技术还能够支持多种数据类型的存储和访问并通过提供统一封装的接口实现数据之间的共享。 湖仓一体技术的最大优势在于它兼具了数据仓库的高性能和标准化管理能力及数据湖的灵活性与扩展性。它能够充分利用现有的数据资源降低数据管理的成本同时提高数据分析与挖掘的效率和精度。 业界流行的“数据湖三剑客”Delta Lake、Apache Iceberg和Apache Hudi这三项技术的设计初衷都是为了解决企业在实际业务场景中遇到的数据处理问题但是由于设计思想不同它们有各自的优劣和不同应用场景下的定位。 Delta Lake Delta Lake它的设计定位于流批一体的数据处理是Databricks公司基于Spark推出的数据湖方案增强Spark在流批处理场景下支持数据库事务的ACIDACID是指数据库事务正确执行四要素的首字母缩写原子性Atomicity或称不可分割性、一致性(Consistency)、隔离性Isolation又称独立性、持久性(Durability)能力。 早期客户在建设实时数仓时通常采用 Lambda 架构该架构的实时场景使用Kafka作为存储层流批处理任务都从Kafka获取数据进行分析处理。这种情况存在一些问题Lambda架构方案需要的组件多、架构复杂Kafka存储能力有限缺失全局的 Schema 规范上下游处理时导致 Schema 不一致数据操作过程没有ACID保障可能会读到中间状态的数据不支持历史数据更新。 为此Databricks公司推出了Delta Lake方案来解决由Lambda架构维护实时、批量两套数据处理逻辑带来的重复开发、数据口径不一致、架构复杂等问题。 Apache Iceberg Apache IcebergApache Iceberg 技术定位于高性能的分析与可靠的数据管理其设计目标是一种开放通用的表格式实现方案可以认为是介于上层计算引擎和底层存储格式之间的一个中间层通过定义数据的元数据组织方式向计算引擎提供统一的类似于传统数据库中“数据表”的语义。 Netflix公司早期基于Hive构建数据湖方案但发现Hive在设计上存在诸多不足如Hive分区颗粒度太大分区的数据文件多在执行简单查询时分区裁剪阶段耗时长依赖外部数据库存储信息处理流程烦琐先要通过数据库获取分区信息再通过HDFS在每个分区上按目录遍历所有文件。当文件很大时这种遍历非常耗时。因此Netflix设计了自己的轻量级Apache Iceberg数据湖方案。 Apache Hudi Apache Hudi是Uber基于自身的业务特点发明的一个增量处理框架以低延迟和高效率为业务关键数据管道提供动力目的是解决HDFS增量的更新能力。 Hudi通过对文件的插入更新和增量拉取两种方式来实现流式入湖和增量更新的功能。 Uber的核心业务场景是将线上业务库的数据实时同步到数据中心供上层业务做分析处理。 Uber的早期方案也是基于Kafka做数据处理这种设计最大的问题是无法快速Upsert存量数据。为了解决数据的更新问题Uber团队在设计Hudi时提供了COW(Copy On Write)和MOR(Merge On Read)两种数据格式。其中MOR表是为快速更新而设计的COW表在写入时将新数据和旧数据合并后再写入全量数据写入延迟高。 上述三种数据湖技术均通过不同的方式实现了支持事务的 ACID 特性、多种存储类型HDFS、对象存储适配多种主流计算引擎(Spark、Flink)、模式演化、开放数据格式(Parquet、Arvo)历史数据回溯等。 三种技术的实现逻辑均是数据湖和数据存储的中间层核心管理能力都是基于Meta的元数据文件通过统一的处理语言来实现处理和更新底层不同类型的数据文件。Meta文件的作用类似于数据库中的Catalog和WAL能够管理Schema、事务等。 Meta文件包含大量的元数据信息基于这些元数据信息数据湖技术可以实现数据表的Schema演化、事务ACID的支持等核心特性。由于Meta文件的内容每次发生变更都会生成一份全新的Meta文件因此存在多个版本的Meta 文件这样系统在上层功能就可以实现数据的多版本控制。数据湖技术通常都会强依赖这些Meta文件来管理表信息若Meta文件被删除或者存放的目录被更改数据就会受到永久破坏。 湖仓一体实践案例 湖仓一体采用经典的分层架构模式具有高内聚、低耦合的特点可以降低数据存储的耦合各层承担各自的职责结构清晰、可扩展性高。 某公司基于Hudi的湖仓一体顶层架构设计分为三层数据存储、资源计算和数据应用。 每一层都专注于各自的领域实现最佳技术组合与实践 由于技术栈的高度标准化每一层都覆盖了前沿的创新技术从技术产生的作用这一维度每一层又可细分为多层。 综合以上湖仓一体架构设计思想所遵循的标准化、规范化、精细化、敏捷等特点企业可以灵活选择最优的方案。 但是由于湖仓架构设计覆盖面广、技术栈众多、技术细节复杂因此企业在推动建设“湖仓一体”数据中心之前需要充分考虑当前的业务场景、发展规模、企业的中远期战略规划等综合因素。 某公司数据湖仓一体顶层架构设计图 在引入Hudi之后某公司数据湖仓一体不仅可以统一对接各种格式的数据包括结构化数据和半结构化数据存储并且支持 OSS、S3、HDFS 等存储系统而且还可以提供对 ACID、表结构的变更。 另外基于对 Snapshot 读取不同历史版本数据等功能的支持惟客数据湖仓一体不仅可以管理数据湖的存储而且还可以做到对原有数据仓库进行统一管理在表结构层做到统一入口下图所示为基于Hudi架构的数据文件合并原理图 基于Hudi架构的数据文件合并原理图 该湖仓一体架构基于Flink CDC、Hudi、Hive、Presto等技术实现数据实时、增量入湖的能力同步方式支持单表、多表、整库多种模式。 数据源类型支持行业主流的数据库如典型的 MySQL、Oracle、MongoDB 等数据库。 通过Flink CDC技术监听数据库的归档日志在上层业务增加、更新数据库之后同步任务会先接收到数据变更事件再通过数据管道流向Hudi并最终落地形成文件。 Hudi内核支持 ACID 特性为了提高 Hudi 的整体读/写吞吐量使用缓冲、增量日志追加等方式写入文件系统。 Hudi写入时会先写入固定大小的instant文件块Hudi内部会维护一个 Timeline时间线并记录 instant 在时间轴上的操作。 在 Hudi 接收到Compaction合并事件后Hudi会启动独立作业执行合并动作将instant文件中记录的更新、删除等操作合并到列式存储格式的数据文件中供上游查询和分析使用。 Hudi整库同步能力可以将大量任务合并成一个任务简化了任务配置。所需的资源用量有所下降集群的资源利用率得到整体提升为企业的数字化建设降本增效。 基于商业地产客户的湖仓一体架构图 商业客户已经自建了HDFS并且在旧架构的基础上有一定的数据建设基础因此提供了一套可融合的技术架构来对旧架构进行升级基于 Flink CDC Hudi 的技术架构其能实现数据的实时秒级同步针对变动数据进行增量更新数据采集的方式包括单表和整库从架构设计上充分保证数据与数据源的一致性。 为了创建和管理基于湖仓一体的大数据运算任务某公司数据中台构建了集数据开发、数据质量管控、数据安全管理、数据服务能力等功能于一体的一站式数据开发及管理平台通过对底层复杂的大数据技术的封装形成低代码的开发能力以减少底层复杂的技术环节在保证数据安全的同时利用平台的低代码能力让数据开发人员可以快速、专注地面向业务需求的数据进行开发和运维实现了敏捷开发、质量管理、安全保障的目标对企业数据进行统一管理与运营提升了数据质量和交付效率能更快、更准、更便捷地获取与使用数据。 通过对该企业数据仓库架构的升级提高了数据计算和存储的效率节约了画像标签及数据报表的产出时间。以前基于离线计算的报表和标签由于需要进行针对历史数据的更新因此每日不得不刷新近百张数据表其中有些数据表的数据量达到数千万行历史数据从采集到合并的过程耗费近4小时的计算时间。在采用了湖仓一体架构之后利用Flink CDC可以捕获历史变动的单条数据并实时更新到数据湖让数据湖中的数据无须经过快照匹配就能与数据源保持一致整个计算过程大大缩短给后续大批量的画像标签与报表计算节约了时间充分保障了第二天数据产出的准时性。 在未升级到湖仓一体架构前运营人员每天都要观测整体的运营数据以便及时对业务进行调整。由于旧数据不支持更新操作因此每间隔一小时都要将新增数据接入与历史数据进行比对形成最新快照供前端查询但由于数据量过大基于Hive的分析查询效率较慢所以前端用户获取到最新的数据有小时级的延迟。在升级到湖仓一体架构后Flink CDC的及时入湖及上层Trino的快速访问和计算能力使数据在业务系统中更新后10秒之内就能反馈到前端业务运营报表上数据的及时性得到大大提升。 白话数据湖仓一体化 数据库 数据库主要用于「事务处理」存取款这种算是最典型的特别强调每秒能干多少事儿QPS每秒查询数、TPS每秒事务数、IOPS每秒读写数等等。 数据仓库 通常是业务发展到一定规模后业务分析师、CIO、决策者们希望从大量的应用系统、业务数据中进行关联分析最终整点“干货”出来。 比如为啥利润会下滑为啥库存周转变慢了向数据要答案整点报告、图表出来给老板汇报辅助经营决策。 可是数据库“脑容量不足”擅长事务性工作不擅长分析型的工作于是就产生了数据仓库。 虽然现在HTAP的概念很盛行也就是混合事务/分析处理用一套数据库架构来同时支持事务(OLTP)和分析(OLAP)两种需求但真正大规模的分析和洞察还是离不开数据仓库。 数据仓库相当于一个集成化数据管理的平台从多个数据源抽取有价值的数据在仓库内转换和流动并提供给BI等分析工具来输出干货。 因为分析型业务需要大量的“读”操作所以数据仓库通过“Denormalized”化的方式优化表结构减少表间联接牺牲空间来换取读性能。一张表里的冗余数据增加了但查询起来却更快了并使用列式存储优化来进一步提高查询速度、降低开销。 再结合面向分析场景的Schema设计数据仓库就可以高效率、全方位、多维度的扛起“联机分析”重任了。 数据库和数据仓库的区别 数据湖 数据库负责干事务处理相关的事数据仓库负责干业务分析相关的事还有新兴的HTAP数据库既干事务又干分析都已经这么内卷了还要数据湖来干个毛线 说白了还是企业在持续发展企业的数据也不断堆积虽然“含金量”最高的数据都存在数据库和数仓里支撑着企业的运转。 但是企业希望把生产经营中的所有相关数据历史的、实时的在线的、离线的内部的、外部的结构化的、非结构化的都能完整保存下来方便“沙中淘金”。 数据库和数据仓库都干不了这活儿怎么办呢 挖个大坑修个湖把各种数据一滚脑灌进去囤起来而且要持续灌持续囤。这就是数据湖啦 数据湖的本质是由“➊数据存储架构➋数据处理工具”组成的解决方案而不是某个单一独立产品。 ➊数据存储架构要有足够的扩展性和可靠性要满足企业能把所有原始数据都“囤”起来存得下、存得久。 一般来讲各大云厂商都喜欢用对象存储来做数据湖的存储底座比如 Amazon Web Services亚马逊云科技修建“湖底”用的“砖头”就是S3云对象存储。 ➋数据处理工具则分为两大类↓ 第一类工具解决的问题是如何把数据“搬到”湖里包括定义数据源、制定数据访问策略和安全策略并移动数据、编制数据目录等等。 如果没有这些数据管理/治理工具元数据缺失湖里的数据质量就没法保障“泥石俱下”各种数据倾泻堆积到湖里最终好好的数据湖慢慢就变成了数据沼泽。 因此在一个数据湖方案里数据移动和管理的工具非常重要。 比如Amazon Web Services提供“Lake Formation”这个工具帮助客户自动化地把各种数据源中的数据移动到湖里同时还可以调用Amazon Glue来对数据进行ETL编制数据目录进一步提高湖里数据的质量。 ETL:是英文Extract-Transform-Load的缩写用来描述将数据从来源端经过抽取extract、转换transform、加载load至目的端的过程。ETL一词较常用在数据仓库但其对象并不限于数据仓库。 第二类工具就是要从湖里的海量数据中“淘金”。 数据并不是存进数据湖里就万事大吉要对数据进行分析、挖掘、利用比如要对湖里的数据进行查询同时要把数据提供给机器学习、数据科学类的业务便于“点石成金”。 我们继续拿Amazon Web Services来举例子基于Amazon Athena这个服务就可以使用标准的SQL来对S3数据湖中的数据进行交互式查询。 再比如使用Amazon SageMake****r机器学习服务导入数据湖中的数据进行模型训练这些都是常规操作。 小结一下数据湖不只是个“囤积”数据的“大水坑”除了用存储技术构建的湖底座以外还包含一系列的数据入湖、数据出湖、数据管理、数据应用工具集共同组成了数据湖解决方案。 数据仓库和数据湖的区别 从数据含金量来比数据仓库里的数据价值密度更高一些数据的抽取和Schema的设计都有非常强的针对性便于业务分析师迅速获取洞察结果用与决策支持。 而数据湖更有一种“兜底”的感觉甭管当下有用没有/或者暂时没想好怎么用先保存着、沉淀着将来想用的时候尽管翻牌子就是了反正都原汁原味的留存了下来。 而从产品形态看数据仓库可以是独立的标准化产品拿云上数仓来举例Amazon Redshift就是一款“数仓产品”。 数据湖则是一种架构通常是围绕对象存储为“湖底座”的大数据管理方案组合。比如Amazon Web Services并没有哪个产品叫“数据湖”而是以S3为基础结合****一系列数据管理工具帮助客户构建云上“数据湖”↓ 湖仓一体化 曾经数据仓库擅长的BI、数据洞察离业务更近、价值更大而数据湖里的数据更多的是为了远景画饼。 随着大数据和AI的上纲上线原先的“画的饼”也变得炙手可热起来为业务赋能价值被重新定义。 而因为数仓和数据库的出发点不同、架构不同企业在实际使用过程中“性价比”差异很大。 数据湖起步成本很低但随着数据体量增大TCO成本会加速飙升数仓则恰恰相反前期建设开支很大。 总之一个后期成本高一个前期成本高对于既想修湖、又想建仓的用户来说仿佛玩了一个金钱游戏。 于是人们就想既然都是拿数据为业务服务数据湖和数仓作为两大“数据集散地”能不能彼此整合一下让数据流动起来少点重复建设呢 比如让“数仓”在进行数据分析的时候可以直接访问数据湖里的数据Amazon Redshift Spectrum是这么干的。再比如让数据湖在架构设计上就“原生”支持数仓能力DeltaLake是这么干。 正是这些想法和需求推动了数仓和数据湖的打通和融合也就是当下炙手可热的概念Lake House。 Lake House坊间通常称之为“湖仓一体”而Amazon Web Services则叫做“智能湖仓”。 Lake House架构最重要的一点是实现“湖里”和“仓里”的数据/元数据能够无缝打通并且“自由”流动。 湖里的“新鲜”数据可以流到仓里甚至可以直接被数仓使用而仓里的“不新鲜”数据也可以流到湖里低成本长久保存供未来的数据挖掘使用。 为了实现这个目标Amazon Web Services推出了Redshift Spectrum打通了数仓对数据湖的直接访问能够高效查询S3数据湖当中的EB级数据。 “Spectrum”是智能湖仓的核心组件被称为“Lake House引擎”它可以在湖与仓之间架起数据流动的管道↓ ➊可以将数据湖中最近几个月的“热数据”摄取到数仓中 ➋反过来也可以轻松将大量冷门历史数据从数仓转移至成本更低廉的数据湖内同时这些移到湖里的数据仍然可以被Redshift数仓查询使用; ➌处理数仓内的热数据与数据湖中的历史数据生成丰富的数据集全程无需执行任何数据移动操作 ➍生成的新数据集可以插入到数仓中的表内或者直接插入由数据湖托管的外部表中。 但是在实际业务场景下数据的移动和访问不仅限于数仓和数据湖之间搜索引擎服务、机器学习服务、大数据分析服务……都涉及到数据在本地本系统和数据湖之间的移动以及数据在不同服务之间的移动。 数据积累得越多移动起来就越困难这就是所谓的“数据重力”。 所以Lake House不仅要把湖、仓打通还要克服“数据重力”让数据在这些服务之间按需来回移动入湖、出湖、环湖…… 把数据湖和数据仓库集成起来只是第一步还要把湖、仓以及所有其他数据处理服务组成统一且连续的整体这就是Amazon Web Services为何把自家的Lake House架构称为“智能湖仓”而非“湖仓一体”。 “湖仓一体”只是开局智能湖仓才是终极 智能湖仓并非单一产品它描述的是一种架构。 这套架构以数据湖为中心把数据湖作为中央存储库再围绕数据湖建立专用“数据服务环”环上的服务包括了数仓、机器学习、大数据处理、日志分析甚至RDS和NOSQL服务等等。 大家“环湖而饲”既可以直接操纵湖内数据也可以从湖中摄取数据还可以向湖中回注数据同时环湖的服务彼此之间也可以轻松交换数据。 任何热门的数据处理服务都在湖边建好了任何对口的数据都能召之即来、挥之则去。依靠这种无缝集成和数据移动机制用户就能从容地用对的工具从对的数据中挖出干货 智能湖仓六层架构 这个六层架构从数据源定义、数据摄取和入湖入仓到湖仓打通与集成再到数据出湖、数据处理和数据消费一气呵成各种云上数据服务无缝集成在一起。 数据从各种源头“流入”到智能湖仓存储中又按需流出被处理、被消费。 在“智能湖仓”架构下企业可以轻松汇集和保存海量业务数据并随心所欲地调用各种数据服务用于BI、可视化分析、搜索、建模、特征提取、流处理等等未来新的数据源、新的分析方法也可以快速应对。 同时数据湖的存储底座S3成本低廉并有近乎无限的扩展性“湖边”大量的数据分析和处理的服务又是无长期成本的Serverless架构企业“入坑”智能湖仓之后完全没有后顾之忧。 甚至可以认为“智能湖仓”架构是比所谓“数据中台”更能落地和务实的“中台”如果数据中台是个饼那智能湖仓就是把饼“烹熟烤香”的锅~ 数据湖仓一体化的一种技术体系的实操流程 hive是基于Hadoop的一个数据仓库工具用来进行数据提取、转化、加载这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。hive数据仓库工具能将结构化的数据文件映射为一张数据库表并提供SQL查询功能能将SQL语句转变成MapReduce任务来执行。Hive的优点是学习成本低可以通过类似SQL语句实现快速MapReduce统计使MapReduce变得更加简单而不必开发专门的MapReduce应用程序。 MapReduce是一种编程模型用于大规模数据集大于1TB的并行运算。概念Map映射“和Reduce归约”是它们的主要思想。是一种面向大规模数据处理的并行计算模型和方法 Flink CDC Flink 是一个分布式计算框架。 cdc我们可以理解为可以检测某个对象的数据变更记录的工具。说的再形象点就是有一个工具在启动的时候就可以开启某个对象的监听这个对象有任何操作变更的时候这个工具都能感知到所以这样的工具我们把他称为cdc。 flink的cdc就是一个自定义的datasource他里面集成了debezium和kafka的功能简化了我们开发和运维部署debezium和kafka工具的工作。使得我们在flink里面初始化cdc的配置里面进行下配置然后我们就可以直接读取到mysql binlog这样的数据。 例如我们有一个场景需要监听mysql表的变化如果mysql的某个库的某张表里面有变化我们需要把对应的信息进行解析处理然后把数据写入新的mysql。这时候我们一般怎么做呢那肯定是先使用cancel或者Debezium监听mysql的binlog。然后把数据处理后发送到kafka然后再使用消费者从kafka里面获取数据进行业务操作。 Flink CDC 支持很多数据库如 mysql、mongodb、oceanbase、sqlserver、oracle、postgresql等等 1、分层规划 湖仓一体化四层分层架构 2、分层构建的完整流程 湖仓一体分层构建的完整流程 3、该技术体系下实现的湖仓一体的优势 1、使用 Hudi 搭建数仓 1沿用传统数仓中的分层思想 2不需要做复杂的拉链表 3不需要全量增量表延迟低近似为实时的离线数仓 4Hudi自动解决小文件问题 5所有层的数据均可在Hive中通过Hive的同步表进行查询底层只有一份数据 2、使用 HiveCatalog 持久化数据 HiveCatalog 作为表元数据持久化的介质在生产环境一般采用HiveCatalog 来管理元数据这样的好处是不需要重复使用DDL创建表只需要关心业务逻辑的SQL简化了开发流程可以节省很多时间。 在 Flink 中创建表表的元数据可以保存到 hive 的元数据中元数据不会丢失。 3、使用 Flink SQL 进行开发 基于 yarn-session 的 SQL-client 可以在提交任务时候动态申请 TM 个数。 4、引入 Hive 的系统函数作为 Flink 的内置函数 原本 Flink 中不支持 Hive 的语法例如 split在加载 hive 模块之后就可以进行使用了。 5、集成 StreamX 进行 Flink SQL 调度 4、环境准备 1、编译 Hudi 源码 安装 Maven、Java 等等组件 2、Hudi 集成 Flink 集成时可以将元数据集成至 HiveCatalog可以先默认配置个元数据操作如下 3、Hudi 集成 Hive 集成时可以初始化 Hive 元数据库。 4、准备模拟数据 通常企业在开始搭建数仓时业务系统中会存在历史数据一般是业务数据库存在历史数据而用户行为日志无历史数据。 1、日志数据 可以启动日志采集通道包括 Flume、Kafka 等之后生成日志。 Flume是Cloudera提供的一个高可用的高可靠的分布式的海量日志采集、聚合和传输的系统Flume支持在日志系统中定制各类数据发送方用于收集数据同时Flume提供对数据进行简单处理并写到各种数据接受方可定制的能力。Kafka是由Apache软件基金会开发的一个开源流处理平台由Scala和Java编写。Kafka是一种高吞吐量的分布式发布订阅消息系统它可以处理消费者在网站中的所有动作流数据。 这种动作网页浏览搜索和其他用户的行动是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop一样的日志数据和离线分析系统但又要求实时处理的限制这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理也是为了通过集群来提供实时的消息。Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下开发分布式程序。充分利用集群的威力进行高速运算和存储。Hadoop实现了一个分布式文件系统 Distributed File System其中一个组件是HDFSHadoop Distributed File System。HDFS有高容错性的特点并且设计用来部署在低廉的low-cost硬件上而且它提供高吞吐量high throughput来访问应用程序的数据适合那些有着超大数据集large data set的应用程序。HDFS放宽了relaxPOSIX的要求可以以流的形式访问streaming access文件系统中的数据。Hadoop的框架最核心的设计就是HDFS和MapReduce。HDFS为海量的数据提供了存储而MapReduce则为海量的数据提供了计算2、业务数据 可以执行模拟生成业务数据的命令如生成某天的历史数据。 5、湖仓一体之 ODS 层 ODS 层的设计要点如下 1、ODS 层的表结构设计依托于从业务系统同步过来的数据结构 2、先使用 Flink SQL 建表然后将数据源进行 insert 的操作并补齐缺失的字段 在 ODS 层实现 数据入湖操作 1用户日志 保存到 kafka 的 tpopic_log 中就成为流式数据该业务日志数据入湖时就以流式数据的方式入湖进入 hudi 中。 2业务数据 保存到 mysql 中的 gmall 表格中就成为数据库数据如果要以数据流流式数据的方式入湖则需要 ​ ① 对表格数据进行实时监控监控数据的更新、修改等通过 flinkCDC 转换为流式数据 ​ ②然后就可以入湖了insert into hudi 表 select * from gmall(数据库表)将数据写入hudi中 6、湖仓一体之 DIM 层 DIM 层设计要点 1、DIM 层的设计依据是维度建模理论该层存储维度模型的维度表。 2、日期维度采用文件导入 如商品维度表、优惠券维度表、活动维度表、地区维度表、日期维度表、用户维度表等。 7、湖仓一体之 DWS 层 设计要点 1、DWS 层的设计参考指标体系 2、DWS 层表名的命名规范为 dws_数据域_统计粒度_业务过程_统计周期 3、使用flink的sum()函数才可以回撤更新 4、维度关联的维度表选择使用hudi流读作为维度表将导致后续的维度表变化引发过期的数据大范围改变使用lookup join 读取维度表的形式不会对先前的数据进行修改但是无法实时变更。 如最近一日汇总表、某个用户消费汇总表、省域订单汇总表等 8、湖仓一体之ADS层 设计要点 1、是最终的需求层 2、要考虑后续进行可视化展示的需求 使用 flink 的 mysql-connector 连接器将结果直接导入到 mysql 中方便后续进行可视化展示。 汇总结果、统计结果再放在 hudi 中就不合适了需要放到数据仓库、数据库中。 因此需要使用 MySQL 创建目标表格存储结果数据。 9、可视化展示 这里使用 Superset 进行结果的可视化展示。 Apache Superset是一个开源的、现代的、轻量级BI分析工具能够对接多种数据源、拥有丰富的图标展示形式、支持自定义仪表盘且拥有友好的用户界面十分易用。 由于Superset能够对接常用的大数据分析工具如Trino、Hive、Kylin、Druid等且支持自定义仪表盘故可作为数仓的可视化工具应用于数据仓库的ADS 层。 湖仓一体化一种技术体系下的完整技术落地流程 网易基于 Apache Iceberg 湖仓一体系统 Arctic Arctic 是一个开放式架构下的湖仓管理系统在开放的数据格式之上Arctic 提供更多面向流和更新场景的优化以及一套可插拔的数据自优化机制和管理服务。 更关注数据库的数据如何实时的更新到湖仓里。 网易数据开发现状与痛点 1、T 1 架构 T 1 离线数据生产 数据源来自于数据库或大量的业务日志如客户端的日志、服务器的日志、传感器里收集上来的数据等。这些大量的原始数据进入到离线数仓之后会做数据分层的开发、处理。 数据分层的目的是为了实现数据的复用。需求时多样的不可能从原始数据到最终结果完整的去做一次数据存储这样会浪费大量的存储和计算成本。 这里的分层用的也是传统的分层架构ODS 层、DWS层、ADS层. 分层数据主要存在 hive中计算引擎会使用 hive sql后面转为了 spark sql。 面向解决市场会用 impala 进行数据的分析。 一般是凌晨时间进行调度第二天早上产出结果。这就是 T 1 架构。 2、T 1 架构之上引入实时链路 随着对数据延迟的要求越来越高T 1 已不满足。于是引入实时链路。 初步引入实时化 在 T 1 架构之上重构、引入了实时链路。 实时链路采用的存储为消息队列计算引擎采用 flink 这样的实时计算引擎flink 很难做到像 hive 一样的数据分层只能根据实际的需求去写个 flink 任务从源头把数据接进来经过聚合、清洗之后写到像图库这样的实时的数仓里面然后再实时的数仓里面进行分析或者接入到其他的能够支撑实时更新的系统里如数据库里。 于是就分成了两条链路 实时链路就是依据需求开发的也没有很好的设计规范。可能会存在着很多重复的计算即你有需求你就去开发。 更加复杂的实时化 随着接入实时的这条链路的业务越来越多简单的去写一个 flink 任务可能已经无法满足。实时场景下逻辑会越来越复杂比如实时场景下需要维度数据以前的维度数据对应的维度表就是存在 hive 的一张 hive 表就够了但 hive 表是没办法去做实时的点查的那就还需要一些 kv 系统比如一套 HBase。另一方面实时链路没有数据分层它的数据复用度很差资源浪费很严重因此开始在实时链路上做一些数据分层比如把清洗好的表或公共使用的表放在一个单独的 kfaka topic 里面所以存储以 kfaka 为主会引入 hbase 作为 kv然后去做简单的分层最终数据会落在 kudu 上。 然后在业务应用上面的话比如既要用到历史的数据也要用到实时的数据会把历史的 hive 数据 和 kudu 里面的最近的数据做一个业务层面上的聚合统一之后再反馈给业务系统。 3、流批分割的 Lambda 架构 流批分割的 Lambda 架构 这种流批分割的开发模式下会有以下的问题 1、数据孤岛Kudu 等要使用 hbase、kfaka、kudu 等等不同的存储系统去满足业务需求还需要同步工具将这些存储在存储系统里的实时数据同步到离线里来。 而这些存储系统就需要独立采购和部署冗余存储浪费成本难以数据复用和互通 2、研发体系割裂实时和离线是用不同语言开发的spark sql、flink sql 等 研发人效低研发规范不通用应用层视图合并复杂 3、指标和语义二义性开发语言、表的定义不一样的时候聚合时很难保证正确性 网易的湖仓一体系统 Arctic 核心技术 为了解决上述问题网易提出了 Arctic 湖仓一体系统。 Arctic 是定义在Hive/Iceberg 表格式之上计算引擎之下的 TableService并提供表结构优化以及 Kafka、redis、Hbase 等KV存储封装的实时湖仓系统。 Hive 的摄取与计算场景 上图是一个 T1 的 hive 计算场景。一个批的数据进行了 T1 或者 TH 的摄取再进行批的计算每次都进行了全量的摄取或计算在此基础上引入了 Iceberg 和 Deltalake。 Iceberg/Deltalake 的摄取与计算 抽象出 Snapshot 概念通过快照隔离实现 MVCC 和 ACID支持数据实时摄取。 Arctic 在 Iceberg 的基础上将 Batch 和 Stream 写入的文件进行区分分为 change store 和 base store。 通过异步的 optimizing 对 stream 写入的文件进行合并并提供了小文件治理、唯一键保证和 upsert 的能力。 并通过 ArcticTable 封装的接口提供 merge on read实现准实时的读写能力。 Primary Key Support Arctic Table 支持 支持 Primary Key 支持 CDC ingestion ​ 实现 Upsert 语义 主键唯一性约束实现 ​ Merge on read ​ optimize 未来扩展 SortKey/AggKey 在架构上把 Arctic Table 划分为多个 Table store流写入叫 Change store批写入叫 Base store并通过 table optimize 实现 primary key 的唯一键约束。 primary key 提供的是 upsert 语义包括 CDC ingestionBatch Insert 的时候可以实现基于组件的更新并通过 merge on read 保证唯一性约束。 每个 table store 的实现都是一个 iceberg 表未来在提供 base store 之外还会提供 SortKey、AggKey。 对 Arctic Table 做了两种 Optimize 一种是短周期的 Minor Optimize大约 5 到 10分钟执行一次主要提供小文件的治理把写入 change store 中间的 equal delete 转换 pos-delete。 另外一种是长周期的 Major Optimize大约 1 天执行一次将 insert file 和 change file 合并到 base file当合并的 major optimize 执行完成之后就只有 base 表base 文件与 hive 格式完全兼容。 Arctic Table——流批一体表支持CDC 为了增强流处理下的应用场景进行了 hidden queue 封装在 Arctic table 内部封装kafka对实时性要求高的上游任务进行双写即往 change store 写同时也写入 hidden queue下游直接从 kafka 消费以此达到秒级甚至毫秒级的 CDC。如果不开启 hidden queue上游只写 change store下游利用 iceberg incremental poll 实现分钟级别订阅整个双写过程通过 Arctic-Flink-connector 进行封装。 在双写情况下会遇到一致性问题比如上游 Flink 任务在双写的时候要保证毫秒级和秒级延迟需要先写入 kafka再写入 iceberg 文件可能会在写入的时候任务发生故障导致 iceberg 文件并没有提交而下游已经消费了未提交的数据如果上游任务做了 failover 会导致部分数据重发下游重复消费。 为解决这个问题arctic 在双写的时候用回撤方式对消息提供了最终一致性的保证所有写入 Kafka 的消息均进行了一次封装每一个消息带上上游 writer 对应的 state 周期即当前的 checkpoint 的 index。在下游任务发生 failover 之后会根据 checkpoint 恢复先发出 Flip 消息下游任务收到 Flip 消息之后会自动的从 Kafka 中扫描找到对应的需要回撤的消息并进行 retract 操作整个流程在 Arctic-flink-connector 封装屏蔽业务层面双写带来的一致性问题业务层面只需要将 Arctic 当成流表使用。 同时为了支持将 Arctic 当维表使用实现了一个 hidden 的 index内部封装了 Hbase或 Redis支持在上游写入实现双写数据写入 redis 或 HBase下游不需要关心实现细节将 Arctic 当成维表使用但这种情况下目前没有比较好的办法解决一致性未来会实现 flink1.12 中提出来的时态表 temporal join无需依赖外部 KV。 支持 Temprol join 网易云音乐的应用案例 它是一个推送系统分析有两张主站埋点的 log 日志及算法埋点的 log 日志。设备库是一个 mysql 维表同步。分析师想要知道推送的效果需要通过报表进行查询。它是通过一个 IP 的查询来回的 join 这些表走的批的流程跟原来的批计算流程完全一致。如果分析师在报表分析之后去做算法上的优化。可以在架构不发生变化的情况下立刻推送到面向流的应用同样是个 left join但是它走的流程全部是这种流的生产路径数据全部经过 kafka 做来回的校验最终推送到归因表中最后由数据应用去使用流计算出来的结果数据整个生产链路包括数据存储指标也不存在二义性只有一份的数据存储任务等实现百分百复用。 CDC:Change Data Capture 阿里阿里云 EMR DLF 构建湖仓架构 E-MapReduce简称EMR是运行在阿里云平台上的系统解决方案。EMR构建于ECS或ACK之上通过半托管的形式供您使用可以对集群具有完全的管理操作权限。 唯品会Hudi 引入 Hudi 把任务编程增量存储、增量计算以后能够大幅降低整个大数据体系机器资源的消耗包括计算资源的消耗和存储资源的消耗不管是数仓还是OLAP引擎在业务场景里都要投入较多的机器补充到整个资源池中以支持业务需求。 湖仓的引入可以控制资源的增长、提升资源的效率并且给业务带来更好的体验实现降本增效。 本身体量规模不是太大时数仓的存储和计算的集群可能就几十台或一两百台机器那么湖仓的引入所带来的资源的减少的量可能并不能体现出来。而对于机器数量比较庞大虽然不会成倍的提升但只要能提升10%-20%这个产生的边际效益就已经很大了。 单一的业务场景可能改变并不是很大但是如果这个业务的数量足够多那么带来的效果将会非常明显。 腾讯腾讯云原生湖仓一体技术在大规模数据场景中的应用实践 一、最核心的是数据湖存储。腾讯云是基于COS对象存储架构一层Table Fommat解决存算分离场景下的性能和业务需求如1、解决对象存储缺陷2、稀疏索引加速3、批流合一4、元数据增强。 二、在计算层数据湖使用的是Serverless计算服务按需弹性、无限扩容。如果需要花很多精力关注底层资源解决数据倾斜的问题根据不同的引擎使用不同的SQL语法那么业务接入或者数据变现的周期都会变得很长。基于不同的引擎会有不同的缓存加速策略目前腾讯数据湖主流使用的计算引擎是Presto、Spark。而SAAS化的元数据设计其实是整个湖也是湖仓一体最核心的内容。因为只有元数据统一才可以把湖与仓的业务真正融合起来而不仅仅是湖仓架构组合。 三、腾讯提供的SaaS级别的元数据管理是基于场景做了很多优化的。基于云上场景的元数据管理使用传统的HMS架构性能是不够的需要对依赖关系做很多优化。通过元数据的采集打通上下游主动爬取识别提供相关的元数据应用比如通过数据自动发现以及数据血缘做链路追踪。 四、最上层的Interface提供客户操作入口让客户有比较好的体验模块核心点像任务调度入湖模版等降低客户接入的成本。再就是数据权限、IDE等能力闭环业务开发需求。最右边会有云上或者作为一个产品化的功能项例如认证、权限、日志、监控、计费等。 总结下来腾讯云原生数据湖数据湖DLC和数据湖构建DLF核心价值有两点引入iceberg并且构建iceberg生态解决对象存储问题达成成本和性能效果统一元数据为更宏观的数据湖解决方案提供元数据内核。 数仓建模平台 湖仓一体方案 上图蓝色部分是数仓建模平台 绿色部分是数据湖底座。 湖仓一体统一存储设计理念很重要在腾讯目前主打还是基于COS对象存储但是平也有支持多种存储的能力。 各类型的数据通过入湖构建之后可以通过数据爬虫爬取元数据完成统一元数据构建。 在数据分析层面在数据平台开发层接入像Presto、Spark等多种引擎并与底层数据存储解耦。 腾讯的湖仓一体平台其实是基于元数据的统一在业务层面把仓与湖真正融合在一起。 统一元数据架构 腾讯元数据架构是基于特定的爬虫系统把不同源端数据爬过来再自己定义元数据模型进行采集和存储。 统一元数据不仅仅是统一数据湖也包含仓的统一打通湖到仓的元数据治理。通过如上一整套从湖到仓统一元数据架构让元数据的应用可以满足不同场景的需求。 落地文章索引设计流程 通过数据入湖到COS进行统一存储基于数据发现自动构建底层数据湖表。业务的逻辑分为两个方面一个是实时业务开发基于数据湖分析的能力敏捷支撑分析需求。第二个是基于数据湖Spark引擎小时级别去做数据指标的聚合落地周期性的快照表对接仓的标准实现分层数据建设。