17

认识 Delta Lake:让数仓进化到数据湖

 5 years ago
source link: http://mp.weixin.qq.com/s?__biz=MzUxOTU5Mjk2OA%3D%3D&%3Bmid=2247486065&%3Bidx=2&%3Bsn=f362cd2fb352b8f55b7c4cb8c69ed4b0
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

百花齐放的大数据生态

17,18是计算引擎火热的两年,19年已然是红海了。计算引擎中的王者是Spark,综合指标最好,生态也好,当其他引擎还在ETL,交互查询,流上厮杀时,Spark已经在AI领域越走越远。

对比明显的是,计算层的上层和下层在17,18年却乏善可陈。但是到19年整个局势开发生变化,向下走是存储层Delta Lake耀眼夺目,解决了原先数仓的诸多痛点,让数仓进化到数据湖。向上走是交互应用层的Linkis一马当先,形成交互标准,粘合周边生态,很好的衔接了应用交互层和计算引擎层的衔接。

问题重重的数据存储层

前面我们提到,早先基于Hive的数仓或者传统的文件存储形式(比如Parquet/ORC),都存在一些长期难以解决的问题:

  • 小文件的问题

  • 并发读写问题

  • 有限的更新支持

  • 海量元数据(例如分区)导致Hive metastore不堪重负

细节展开的话,你会发现每一个问题又会引发众多应用场景层面的问题。

比如并发读写还有更新问题让实时数仓的实现变得很困难。小文件问题需要我们自己写合并代码,并且在合并过程中还会造成数据不可读的问题。如此种种不一而足。

为了解决这些先天不足的问题,我们只能通过复杂的架构设计来解决这些问题(美其名曰lambda架构)。比如为了解决先天不足的更新问题,我们可能需要先将数据写入一个其他的系统(如HBase),然后再将HBase导出成Parquet文件/Hive表供下游使用。在复杂的流程(超长的Pipeline)运行的过程中,还会不断涉及到Schema的变换以及磁盘的读取,所以架构复杂了不仅仅会导致运维成本高企,CPU/IO浪费也就变得异常严重。

其实上面这些问题的根源,都是因为存储层不给力,为了曲线救国,我们无奈通过架构来弥补。Delta Lake单刀直入,直接解决存储层的问题,带来的益处就是极大的简化我们的架构设计,简化运维成本,降低服务器成本。

Delta Lake 生之逢时

天下苦传统数仓久已,Delta Lake 横空出世,那么它是如何解决上面的存储层问题呢?我列举了如下几个重要的特性:

  • 以元数据也是大数据思想武装自己,设计了基于HDFS存储的元数据系统,解决metastore不堪重负的问题。

  • 支持更多种类的更新模式,比如Merge/Update/Delete等操作,配合流式写入或者读取的支持,让实时数据湖变得水到渠成。

  • 流批操作可以共享同一张表

  • 版本概念,可以随时回溯,避免一次误操作或者代码逻辑而无法恢复的灾难性后果。

Delta Lake 其实只是一个Lib库

Delta Lake 是一个lib 而不是一个service,不同于HBase,他不需要单独部署,而是直接依附于计算引擎的。 目前只支持Spark引擎。 这意味什么呢?Delta Lake 和普通的parquet文件使用方式没有任何差异,你只要在你的Spark代码项目里引入delta包,按标准的Spark datasource操作即可,可谓部署和使用成本极低。

Delta Lake到底是什么

Parquet文件 + Meta 文件 + 一组操作的API = Delta Lake.

所以Delta没啥神秘的,和parquet没有任何区别。但是他通过meta文件以及相应的API,提供众多特性功能的支持。在Spark中使用它和使用parquet的唯一区别就是把format parquet 换成 detla

和Hive如何整合

因为惯性以及历史的积累,大家还是希望能像使用hive那样使用delta,而不是去使用spark的datasource API。截止到笔者写这些文字之前,官方还没有支持。不过官方透露阿里的同学已经在做这块的整合。另外最近版本的Delta Lake已经通过Manifests机制允许比如Presto之类的读取数据了。

竞争对手

Apache Delta目前主要的竞争对手是Apache Hudi 以及 Apache IceBerg。我们统称为数据湖三驾马车。最后谁能走出来,拭目以待了。

对于这三者之间总结性质的区别和看法,我引用邵 赛的一段话,我觉得他总结的足够好了:

Iceberg 的设计初衷更倾向于定义一个标准、开放且通用的数据组织格式,同时屏蔽底层数据存储格式上的差异,向上提供统一的操作 API,使得不同的引擎可以通过其提供的 API 接入;Hudi 的设计初衷更像是为了解决流式数据的快速落地,并能够通过 upsert 语义进行延迟数据修正;Delta Lake 作为 Databricks 开源的项目,更侧重于在 Spark 层面上解决 Parquet、ORC 等存储格式的固有问题,并带来更多的能力提升。他们都提供了 ACID 的能力,都基于乐观锁实现了冲突解决和提供线性一致性,同时相应地提供了 time travel 的功能。

https://mp.weixin.qq.com/s/KqQzjgJyZmKrh8XsqjFIKg

因为引用限制的问题,大家可以看看原文。

rEj2ayN.png!web


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK