站长工具seo综合查询下载,能看街景的软件,服务类型网站开发需要哪些技术,网站开发php支付接口导读
百度MEG上一代大数据产品存在平台分散、易用性差等问题#xff0c;导致开发效率低下、学习成本高#xff0c;业务需求响应迟缓。为了解决这些问题#xff0c;百度MEG内部开发了图灵3.0生态系统#xff0c;包括Turing Data Engine(TDE)计算存储引擎、Turing Data…导读
百度MEG上一代大数据产品存在平台分散、易用性差等问题导致开发效率低下、学习成本高业务需求响应迟缓。为了解决这些问题百度MEG内部开发了图灵3.0生态系统包括Turing Data Engine(TDE)计算存储引擎、Turing Data Studio(TDS)数据开发治理平台和Turing Data Analysis(TDA)可视化BI产品。依托图灵3.0生态我们引入了数据湖表格式Apache Iceberg利用其特性并在多种业务场景下进行优化实践解决图灵数仓业务实时数据入湖数据表历史记录更新效率低等多个痛点问题。
01 背景
1.1 图灵3.0生态概述
由于百度MEG上一代大数据产品存在平台多、易用性差及数据流转繁琐等问题。这些问题导致开发人员研发效率低及多平台间高昂的学习成本业务部门的感知则是需求交付迟缓、数据产出延迟及数据质量低等问题。为了解决上述问题我们构建了新一代大数据解决方案——“图灵3.0”旨在覆盖数据全生命周期支持全链路数据操作提供高效敏捷且统一的强大数据生态系统其中包括数据计算引擎、数据开发和数据分析三个核心部分
1. TDETuring Data Engine图灵生态的计算引擎包含基于Hive、Iceberg进行数据处理的Spark和ClickHouse高性能计算引擎。
2. TDSTuring Data Studio一站式数据开发治理平台。
3. TDATuring Data Analysis新一代可视化BI产品。
本文主要介绍数据湖表格式Iceberg在图灵3.0生态下的应用与实践。 △图灵3.0生态产品
1.2 问题
MEG数据中台基于Hive构建了离线数据仓库已支持手百搜索商业贴吧小说用增架构销售等多个业务需求但随着业务的发展业务对数据的实时性以及查询性能等有更高要求当前主要存在以下几个问题
1. 商业、电商、销售等业务周期性地更新行业等信息单次更新数据量占比小、字段少但是基于Hive的数据更新以下简称数据回溯只能通过全量覆盖写的方式实现数据回溯周期长、效率低、成本高。
2. 由于Hive在实时数据更新以及事务支持上存在一定局限性无法有效满足业务构建实时数仓的需求。
3. 在处理大规模数据集上Hive的查询性能受到如元数据的加载解析以及每次访问数据都需通过分布式文件系统listFile遍历文件列表等问题的影响导致性能降低。
基于上述问题我们通过技术调研最终引入了开源的数据湖表格式Iceberg构建数据湖存储服务并借助大数据生态的Spark、Flink等计算引擎来实现数据湖的分析将其无缝集成到图灵生态中帮助业务提效降本构建更快速、更高效、更低成本的数据中台产品。
1.3 Hive和Iceberg对比
Hive作为一个基于Hadoop生态系统的开源数据仓库工具主要用于对大规模结构化数据进行存储、查询和分析。而Iceberg作为新一代数据湖表格式提供了类似传统数据库的事务性保证和数据一致性并支持复杂的数据操作如行级更新和删除等更加适合实时更新流批一体数据场景下表列出Hive和Iceberg一些主要特性对比 1.4 Iceberg的组织结构
Iceberg文件组织分为元数据层和数据层主要包含version-hintmetadata file、snapshot file、manifest file和data file文件类型具体如下 metadata元数据层 a. version-hint该文件作为元数据索引初始文件记录了Iceberg表的版本号通过版本号找到对应的metadata file。 b. metadata file记录了Iceberg表的schemas、properties以及快照等信息。 c. snapshot filemanifest-list每次数据 commit 会生成一个新的快照保存了该快照下每个manifest file路径及对应的分区范围。 d. manifest file记录数据文件元信息包含每个数据文件的路径、文件的大小等一系列统计信息如文件每列的最大最小值、空值数等实现元数据和数据文件的关联。 data数据层 data file实际的数据文件以 parquet 等列存格式存储数据。 △Iceberg表结构 △Iceberg文件组织结构
通过上述Iceberg元数据文件组织结构Iceberg实现了文件级的元信息统计及版本化管理。
02 Iceberg能力建设与应用
2.1 图灵生态能力适配
2.1.1 统一元数据服务
由于原生iceberg缺少元数据的可视化管理能力我们通过构建统一的元数据微服务将Iceberg表和Hive表元数据进行管理对应用层提供相关表和分区的增删改查等接口统一数据存储的元数据操作入口。
该微服务主要包含常驻SparkSession模块EngineMetaService模块和元数据模块通过将SparkSession常驻为用户提供Iceberg表和Hive表元数据和分区数据的增删改查功能以及可视化的元数据管理界面。 △统一元数据服务架构
2.1.2 打通Iceberg和Hive联邦查询
为了兼容历史业务存量Hive表同时降低用户使用Iceberg的成本。我们在计算引擎层面打通Iceberg和Hive联邦查询能力并保证了Iceberg表与原有方式语法一致。
通常在一条SQL执行过程中主要可简化以下Parse、Analyzer、Optimizer、CBO四个流程。通过在Analyzer和Plan阶段进行改进优化来打通Iceberg和Hive表联邦查询。 Analyzer阶段该阶段主要是将spark未解析的逻辑计划进行解析我们通过对SparkSessionCatalog加载方式改造优先加载iceberg表使用的catalog类型如果用户SQL使用的是Iceberg表则对应会使用IcebergCatalog和iceberg数据源访问否则使用SessionCatalog与Hive数据源访问。 Optimizer阶段为加强数据安全管理我们进一步打通Iceberg表鉴权能力在基于逻辑计划生成物理计划阶段解析注入表、字段信息以及表操作类型规则并与公司内数管平台交互实现对Iceberg表和字段的鉴权 △Iceberg和Hive联邦查询适配流程
2.2 存量Hive低成本迁移Iceberg
现有数仓业务数据主要存储于Hive表为支持业务快速切换Iceberg应用新技术我们建设了存量Hive表低成本迁移至Iceberg表的能力。
以下是在实践过程中的两种迁移方案对比
方式1使用Iceberg功能migrate进行原地迁移通过社区提供的CALL migrate语法直接执行如下示例的SQL语句即可将Hive表升级为Iceberg表。
CALL catalog_name.system.migrate(db.sample, map(foo, bar));该方案操作简单且可回滚但这种方式在图灵生态落地过程中也存在一些问题
该方式会基于原Hive表的数据信息构建Iceberg元数据信息并将原Hive表名重命名为sample_backup_同时数据路径也进行重命名。 下游无法读在执行迁移过程中原Hive表对应的路径已经被重命名进而导致下游业务无法正常读取正在迁移中的表。 多表挂载冲突在业务的使用场景中存在同一份物理数据被多个Hive表挂载可能直接修改路径会导致其他表失效。
方式2基于上述问题我们进一步对现有方案进行优化不改变Hive表原有的数据路径来实现Hive低成本迁移Iceberg具体流程如下 构建Iceberg元数据直接复用Hive的分区数据新建同名的Iceberg表并重建Iceberg元数据最终新Iceberg表的元数据信息实际指向是Hive分区数据存储位置。 数据校验当Iceberg元数据构建完成后查询Iceberg表中字段数据和迁移之前Hive表字段数据进行一致性校验验证迁移是否符合预期。 读写切换数据校验完成后我们只需要将对应表的属性更新为Iceberg。因为我们已经打通了Iceberg和Hive的查询且迁移后表名未变业务可正常使用原有表名及语法进行查询和写入降低迁移成本。 △Hive迁移Iceberg整体实现流程
2.3 Iceberg在图灵的应用和性能优化
2.3.1 图灵实时数仓应用
在图灵数仓大部分场景中用户主要依托天级或小时级运行的离线Spark任务来完成数据入仓。在这种模式下难以满足部分对数据实时性要求较高的需求。
为解决该问题我们基于IcebergFlink构建的图灵实时湖仓架构整体重构流程如下图所示。该架构模式实现了数据分钟级别实时入仓显著提升了数据入仓的时效性。进一步扩展了整个图灵的应用场景。 针对数据分析和case排查等场景业务可基于图灵常驻计算引擎进行实时查询快速获取所需要的数据支持业务分析决策 针对策略迭代、特征生产以及机器学习等复杂计算场景可基于spark例行任务进行加工生产 针对策略数据调研分析、科学计算等复杂场景通过数据交互计算引擎Jupyter进行数据计算。通过构建图灵实时湖仓架构既保证了数据分析的时效性又兼顾了复杂计算任务的处理能力有效提升了业务的数据处理效率和分析决策能力。 △图灵实时湖仓架构演变
2.3.2 行级更新策略
在图灵数仓业务场景下商业、搜索、电商、销售等业务周期性地更新行业等信息。而Hive在该场景下支持相对较弱需通过全量覆盖写方式刷新数据这种方式在大数据量场景下回溯数据周期长消耗资源大所需要的人力时间成本也高。我们通过利用Iceberg行级更新的特性基于update、merge into等方式回溯进行字段变更能够很大程度的提高回溯效率降低资源和人力成本。
针对数据行级更新Iceberg提供了两种策略分别为COW(Copy on Write 写时复制) 或 MOR (Merge on Read读时合并)其中MOR根据其标记删除文件的区别又细分了两种方式Equality Delete File和Position Delete File。 关于COW和MOR更新策略的文件表现形式如下图所示我们针对不同场景采用不同更新策略 对于日常数据查询分析场景小时级天级离线例行生成加工场景由于查询次数会远多于数据更新次数可默认采用COW策略 针对一些业务更新少量字段进行长周期回溯场景以及实时场景写入频繁通过使用MOR策略来支持用户进行数据回溯变更字段信息以提升数据更新效率并节省资源。 △COW和MOR两种更新策略对比 △MOR两种删除文件类型更新字段示例
在业务进行数据回溯应用过程中我们采用MOR(Position Delete File)进行行级数据更新通过原Hive回溯和新Iceberg回溯两种方式对比在一天24小时不同分区上验证了Hive和Iceberg新旧的回溯效率如下图所示业务回溯效率整体可平均提升50%进一步地对比单次回溯一年数据消耗的计算资源量对比平均整体降低70%的计算资源消耗整体上极大提升回溯效率并降低资源成本。 △ Hive 和 Iceberg 回溯效率对比
2.3.3 Iceberg表生命周期管理和性能优化
在Iceberg应用实践的过程中针对不同业务场景遇到的问题我们汇总如下 小文件过多在实时湖仓业务场景为了要保证数据的时效性通常是分钟级别的commit操作在这种场景下单个作业执行一天则需要1440 个 commit如果执行时间更长则会产生更多的commit随着时间的累积元数据以及数据文件等都会产生大量的小文件对于整体查询的性能会产生一定的影响。 存储资源增加如果iceberg表的快照不及时进行清理可能会造成数据存储增加导致存储账号资源紧张。 缺乏分区数据统一管理在一些业务场景只需要保存一定天数的分区数据针对无用数据需要进行删除处理。 数据文件组织不均衡且无序由于表数据写入是随机无序且针对表数据文件大小会存在不均衡的情况。
针对上述问题我们通过对Iceberg表进行全生命周期管理并结合Iceberg特性优化表查询性能保障整个数据链路的稳定性整体框架如下图所示 △Iceberg表生命周期管理和性能优化流程
以上流程主要包含表数据生命周期管理和表性能优化两部分。
一方面对于表数据生命周期管理我们通过在线服务执行定时任务来实现对表数据和元数据进行全生命周期监控具体如下 数据分区过期基于用户配置的表生命周期进行分区数据删除保证数据文件按期清理。 元数据快照清理为用户提供按照时间维度天级别和按照个数维度小时级别两种快照过期策略精细化元数据快照过期处理实现存储资源的高效利用。 元数据孤儿文件清理通过天级例行任务来触发清理由于计算引擎执行任务失败等情况产生的一些没有被引用的孤儿文件避免元数据累积影响性能。
另一方面在表性能优化方面我们结合图灵数仓表使用情况并基于Iceberg原生特性为用户在平台侧提供Iceberg表优化算子如下图示例主要包含以下两种能力 小文件合并通过制定合并文件大小对表数据文件进行重写合并避免产生大量小文件。 z-order排序优化实现对表相关字段进行重排序提升查询性能。 △Iceberg表优化算子任务创建示例
我们通过对Iceberg表整体的生命周期管理实现了数据和元数据的统一治理表元数据小文件数万个降低到数百级别合理控制了元数据产生的数量并解决了数据频繁回溯场景下存储快速增加的问题。而在表查询优化方面通过在一些表的数据重分布和字段重排序应用在部分业务表查询性能提速50%。
03 未来规划
Iceberg作为图灵3.0生态中的重要组成部分基于其高时效性、行级更新能力、小文件合并以及Z-order等成体系的数据优化的技术解决方案为MEG数据中台业务提供构建湖仓一体解决数据回溯等痛点问题的能力。目前Iceberg的应用已覆盖搜索商业销售用增架构等多个业务线通过低成本助力业务将存量Hive迁移Iceberg表为业务提供高性能数据查询同时实现对业务的降本增效。此外我们也在不断完善Iceberg数据存储引擎的各项能力包含表数据智能治理、查询优化、智能索引以及特定场景的性能问题等并不断扩大Iceberg的业务覆盖范围。
