认识 Delta Lake

百花齐放的大数据生态

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 的功能。

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

=========
欢迎大家关注我公众号 【祝威廉】

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,560评论 4 361
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,104评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,297评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,869评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,275评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,563评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,833评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,543评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,245评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,512评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,011评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,359评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,006评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,062评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,825评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,590评论 2 273
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,501评论 2 268