什么事数据湖技术?
大数据平台的架构设计里,我们最熟悉的lambda架构,kappa架构,这里都有两个概念:批处理,流处理。对应的有离线数仓,实时数仓,随着计算引擎技术的革新和业务体量的发展,人们对实时的需求越来越越强烈,批流两套体系的冗余交错的粗狂式发展阶段已经过去,企业逐步进入精细化运营,降本增效已然成为互联网黑化的热词。实时数仓的建设和批流一体建设的口号已经喊了好几年,当前实时主要技术栈有了Flink,kafka,spark,presto,druid等等新兴计算引擎,而批流一体的核心问题在于如何处理数据存储的大一统?于是有了数据湖的概念,delta,hudi,iceberg是当前数据湖领域的三剑客。
去年在快手组织的一次meetup中,有幸了解了鹅厂大佬邵赛赛分享了iceberg在腾讯的落地情况,当时颇有感触后面却没有深入了解。最近利用周末时间调研了下数据湖技术,总结一下数据湖领域的Apache 顶级项目 iceberg。
之前在做电信项目的时候,采用的是典型的Lambda架构,我有幸参与了当故事批流一体的建设,当时采用的架构是kafka + spark + hive 的批处理和 kafka + spark + hbase/kafka + flume的流处理。很显然,这种架构的痛点在于流式数据的写入落地(往往落地赶不上实时数据的生产),大量暴增的小文件,增量数据的读取。
1)数据的落地。首先一个瓶颈是,一天的实时数据量在60T,如何将其落地。我们当时采用的spark streaming程序将数据清洗格式化后写入hive表,但hdfs写入慢,kafak的消费赶不上生产。这是一个痛点。
2)数据的拉取。一个批次的数据写入,必须保证下游完整地消费。比如5分钟批次落地10个文件,下游必须知道该消费哪10个文件才是这5分钟的,不能少读也不能多读。我们当时采用了落地到hive表分钟级别分区的方案。落地到hive的一个问题便是:分区数取决于spark streaming的batch大小,这将导致大量的分区。我们将数据先落地到分钟级别分区,然后再慢慢聚合到小时,天等。
3)数据的回溯。如果上游数据有误,需要回溯修正数据。而落地Hive回溯则需要全量回溯,这个成本和代价太高。如果数据链路较长,这种痛只有经历了才能体会。
4)小文件问题。流式落地势必带来小文件问题。事后小文件的合并如何保证原子性和并发性?这是当时困惑的难点。
而数据湖便是解决这些痛点的,iceberg是数据湖领域个人认为还是很有实力的一款竞品。
Iceberg’s history
Apache Iceberg 用一句话说就是一种新的表格式的规范(table schema)。具体点呢,它是一种可以有历史跟踪的,超大规模的表格式,专门为对象存储而设计的。
首先要明白表和表格式不是一回事。表是一个具象的,而表格式是一个规范。
最初是有Netflix公司开发设计并开源的,它一出生便是数据湖领域的一批黑马,18年作为Apache顶级项目进入孵化器,20年毕业,目前已经在数据湖领域占据一席之地。当前实践大厂有腾讯,网易等,滴滴也在调研中,和Dalta Lake,Apache Hudi(阿里主推)相比,iceberg又有什么优势呢?
What is Iceberg?
iceberg是一种新定义的可伸缩的表存储格式
。
那众所周知,存储格式已经有orc parquet,avro等等,为什么还要设计一种新的存储格式iceberg呢?
iceberg允许我们在一个文件里面修改或者过滤数据,多个文件也支持。
A format?
首先从常见的Hive表说起。
Hive的核心便是将数据按照目录树的模式组织起来,不同的分区便是不同的目录。
根据where条件里指定的分区值,找到对应的分区目录。
熟悉Hive的同学可能知道它的机制是这样的:HMS负责记录这些分区的元数据信息,而实际的数据文件是存储在底层文件系统里(比如HDFS),这就带来一个问题,元数据和真实数据的存储分离成两套,这两套又是存储在彼此没有任何联系的独立的两个系统中,显然这无法保证原子性。
Iceberg‘s Goals
iceberg诞生了,它致力于:
1)提供一套静态数据交换的开放规范,维护一个清晰的格式规范,支持多语言
2)可扩展性,可靠性,原子性,云原生对象存储,多并发写(hdfs不支持多并发写)
3)修复持续的可用性问题。比如模式演进,分区隐藏,时间旅行,回滚等等。
Iceberg’s Design
iceberg记录表在所有时间的所有文件,和Delta Lake,Apache Hudi类似,支持快照snapshot(表在某个时刻的完整文件列表,每一次写操作都会生成一个新的快照)。读数据时使用当前的快照,iceberg使用乐观锁机制来创建新的快照,然后提交。
Iceberg‘s Design Benefits
这种设计的优势在于:
1)所有的修改具有原子性
2)没有耗时的文件系统操作
3)快照是索引好的,以便加速读取
4)CBO metrics 信息是可靠的(hive可能存在不统一的情况)
5)更新支持版本,支持物化视图
Iceberg at Netflix
规模:iceberg在Netflix的生产环境支撑了单表TB级别的数据,百万级别的分区数的大表,并能够提供低延迟的查询响应。
并发:iceberg在Netflix使用Flink在3个AWS regions写数据,然后通过一个Lift服务将数据移到一个region上,然后通过一个merge服务合并小文件。
可用性:数据的回滚是很平常的事。可以追踪一个任务读取的版本;发现错误版本的生产来源。
总结
总的来说,iceberg是数据湖领域的一种表格式规范,它提供了批流合一的数据存储的大一统解决方案。
本文链接: https://stefanxiepj.github.io/archives/80d2981f.html
版权声明: 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处!