1-2 邵赛赛-湖仓一体在腾讯的实践落地

湖仓一体在腾讯的落地实践 演讲人：邵赛赛 个人介绍 •腾讯大数据实时湖仓团队负责人，负责流、批、湖等项目 •ApacheMember，ApacheSparkPMCMember •曾就职于Hortonworks，Intel，多年开源大数据从业经验 目录 1 湖仓一体技术诞生的背景和现状 2 湖仓一体技术现存的问题 3 腾讯在湖仓一体上的工作 4 后续的规划 湖仓的演进（1） 数据仓库（90s） 数据湖–数仓两层架构 （10s） BIReports BIReports 数据科学机器学习 DataWarehouse 优点： •高效处理结构化数据 缺点： •无法处理半/非结构化数据，无法支持多计算范式 DataWarehouse 优点： •支持各类型数据存储、分析 缺点： •缺乏数仓的高阶特性 DataLake StructuredData Structured,Semi-structured&UnstructuredData 湖仓的演进（2） 仓、湖、流-孤岛式架构 （15s） BIReports数据科学机器学习 一致性 保持数据湖和数仓数据一致性非常困难且耗费成本 仓 湖 流 Batch Ad-hoc Streaming 受限的进阶分析 基于海量数据的进阶分析非常低效（数据出仓） 数据成本 多份数据拷贝（仓、湖、流）带来了加倍的成本 解决之道–湖仓一体 BI 湖仓一体架构（20s） Reports数据科学机器学习 元数据、缓存、索引层 1.湖上可靠的数据管理 2.支持机器学习和数据科学 3.最先进的SQL性能 一种开放的，高性能的数据组织格式 一套开放、标准的API 一个极致优化的执行引擎 DataLake Structured,Semi-structured&UnstructuredData 湖仓一体技术 3种主流开源技术 湖仓一体技术的优势 UberNetflixDatabricks ●构建于存储格式之上的数据组织方式 ●提供ACID能力，提供一定的事务特性和并发能力 ●提供行级别的数据修改能力 ●具备表结构进化能力2021年Lakehouse技术首次进入Gartner成熟度曲线 优化数据入湖流程 •提供ACID事务能力，上游数据写入即可见，不影响当前数据处理任务，这大大简化了ETL •提供Upsert能力，可以极大地缩小数据入湖延迟 统一数据存储和灵活的文件组织 •批任务和流任务可以使用相同的存储模型，数据不再孤立。 •支持隐藏分区和分区进化，方便业务进行数据分区策略更新 支持更多的分析引擎 •优秀的内核抽象使之不绑定于特定引擎 ，目前在支持的有Spark,Flink,Presto,Hive •提供了javanativeAPI，不用特定引擎也可以访问表 增量读取处理能力 •支持通过流式方式读取增量数据 •SparkStructuredStreaming支持 •FlinkTableSource支持 湖仓一体落地场景–加速数据入湖 复杂的增量入库方案来保证exactly-once和数据去重 利用HDFSrename操作的原子性和复杂的命名规则来保证一致性、可见性 利用调度引擎来构建依赖关系，避免读写冲突 ••Iceberg/Hudi格式是Hive/Spark兼容的可读写的表格 式，可以直接使用Hive/Spark进行处理，无须再次将 • 数据导入到数仓中 •Iceberg/Hudi支持读写分离，写入并且commit后的数 •据下游立即可见，因此可以实时读取到新增的数据， 降低整体时延 湖仓一体落地场景–构建CDCPipeline 1.统一数据总线，扩展性好，方案成熟，组件维护成本高 2.链路更简单，存储成本低，扩展性稍差 湖仓一体落地场景–近实时的流批一体架构 湖仓一体落地场景–更好的Hive表 数据治理的问题数据查询的问题 PARTITIONEDBYMONTH(date)2008-11-012008-12-01 PARTITIONEDBYDAY(date) 2009-01… 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1.无法支持表结构进化 1.缺乏ACID能力 C 3 B 1 col_2 col_1 读写 2.缺乏高效的dataskipping能力 2009-01-01 C 3 B 1 col_2 col_1 col_1 col_2 1 D 3 C 2.无法支持行级数据修正 目录 1 湖仓一体技术诞生的背景和现状 2 湖仓一体技术现存的问题 3 腾讯在湖仓一体上的工作 4 后续的规划 湖仓一体内核的性能 数据治理 •高并发、准实时写入所引入的海量小文件问题 •海量元数据造成的QueryPlan时延 查询性能 •如何平衡读写性能，既能保证写的性能的同时能更快地查询 •如何自动加速查询，发挥极速性能 流批一体 •如何平衡流批读写的性能 湖仓一体技术的实时性限制 存储能力的不同计算对存储的需求不同 ObjectStorage block block block block QueueStorage 数据新鲜度 流式计算 离线计算 数据成本数据查询时延 优势 劣势 ObjectStorage 高吞吐、低成本、大规模 高延迟，Posix支持有限（不可修改） QueueStorage 低延迟、高响应 顺序读写，不可修改 流式计算 离线计算 访问要求 低延迟、高响应 高吞吐、低响应 访问方式 记录级别的读写 文件（行列）级别的读写 存储周期 短（一般7天） 长（保存较长历史数据） 目录 1 湖仓一体技术诞生的背景和现状 2 湖仓一体技术现存的问题 3 腾讯在湖仓一体上的工作 4 后续的规划 优化湖仓一体技术–内核优化 功能优化 •大宽表支持，支持超万列宽表写入 •流转批，兼容周期调度任务 •流式写入支持去重、增量读取、流量控制 性能优化 •元数据读取加速，引入Alluxio •复杂类型列剪支优化，基于列信息任务切分优化 •V2表layout改进与合并加速 •向量化,Async-IO，CBO等查询加速 第三方测试效果 优化湖仓一体技术–二级索引 Parquet内置bloomfilter •Pros:内嵌parquet文件，无需额外文件以及过滤逻辑 •Cons:空间浪费，影响写入；全局索引（bloomfilter,bitmap) •Pros:支持多文件格式，异步构建空间节省 ，数据准确，不影响写入 •Cons:独立文件，独立filter逻辑 CREATEINDEXindex_nameON[TABLE]table_nameUSINGBLOOMFILTER ([colName1[options]][,...])] [options]OPTIONS([key1[=]val1][,...] 0 File1 Puffin offseftil1 File3 Partition … … offset4 File2 offset3 File2 offset2 e IndexData )ManifestFile 优化湖仓一体技术–二级索引 数据规模 单分区，2500个文件，4.1亿records/260G 点查Query select*fromxxx wherepartition_time=xxxandsite_set=xx andposition_set=x andaction_info.request_info.id=‘xxx'; 优化湖仓一体技术–流批一体的实时湖仓架构 基于FLIP-188，MQ+数据湖融合方案 流批表流批表 Streaming Streaming Join Filte r Aggregation batch batch backfil l 流批一体表 •HiddenMQ+表格式 •统一流批Schema 流批一体引擎（Flink） •完整的批流一体的语义支持 •批、流任务调度和优化的支持 Source2 Sink Source1 优点： •引擎和表的流批一体，降低业务架构复杂度 •屏蔽流批差异，统一SQL操作 •提升时效性，兼顾流式和湖仓 LogStoreStreamingRead write FileStore BatchRead 下游作业交互式查询 湖仓一体存储 Caching Indexing Sorting Clustering RowTTL ColumnTTL Merge Binpack 优化湖仓一体技术–自动数据治理 自动数据治理–小文件合并 分区小文件状态表示 table … Summary •均方误差MSE，MSE值越大表示分区内小文件比例越大。 SnapshotEvent N=分区内文件个数Target=目标文件大小 Actual=min（实际文件大小,Target） 分区小文件状态更新 •增量误差 •更新分区小文件状态 Partition-0 SE SE SE T PartitionData SE 2021/8/1 52430 2021/8/2 261324 2021/8/3 97344 …… …… 2021/8/31 213444 MSE>T T MSE =(MSE *N+SE)/(N+M) Partition-1 MSE<T new old ActualFileSizeDiff(Target– Actual) Threshold 数据有效过滤80%+ 查询计算资源降低6倍+ CREATETABLElo_icebergUSINGiceberg ASSELECT*FROMlineorder JOINdatesONlo_orderdate=d_datekeyJOINcustomerONlo_custkey=c_custkeyJOINsupplierONlo_suppkey=s_suppkeyJOINpartONlo_partkey=p_partkeyDISTRIBUTEBYrandom(); 自动数据治理–自动重分布优化 OriginalQuery OPTIMIZETABLE100_ssb.lo_iceberg_10000BINPACK; OPTIMIZETABLE100_ssb.lo_iceberg_10000ZORDERBYc_region,s_region,d_year; 100%代表数据没有Skipping 自动数据治理–自动索引 •自动索引推荐 •根据scan上报filter信息 •支持bloomfilter和bitmap •自动统计数据构建 •更准确的查询初始计划,更准确的join顺序,更准确的任务切分 •基于thetasketch框架，支持表级别stats和分区级别stats的增量构建 1 湖仓一体技术诞生的背景和现状 2 湖仓一体技术现存的问题 3 腾讯在湖仓一体上的工作 4 后续的规划 湖仓一体的演进 湖仓流一体-实时湖仓架构 Ad-hocBatchStreaming BIReports数据科学机器学习 实时湖仓一 体存储 元数据、缓存、索引优化层 THANKYOU!