内容简介:百花齐放的大数据生态17,18是计算引擎火热的两年,19年已然是红海了。计算引擎中的王者是Spark,综合指标最好,生态也好,当其他引擎还在ETL,交互查询,流上厮杀时,Spark已经在AI领域越走越远。对比明显的是,计算层的上层和下层在17,18年却乏善可陈。但是到19年整个局势开发生变化,向下走是存储层Delta Lake耀眼夺目,解决了原先数仓的诸多痛点,让数仓进化到数据湖。向上走是交互应用层的Linkis一马当先,形成交互标准,粘合周边生态,很好的衔接了应用交互层和计算引擎层的衔接。
百花齐放的大数据生态
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
因为引用限制的问题,大家可以看看原文。
往期推荐 点击标题跳转
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- ## 进化的倒计时
- JavaScript异步进化史
- 革命与进化:全同态加密
- BackSwap银行木马进化分析
- Dridex的进化史
- ThreadLocal 的进化:TransmittableThreadLocal
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
XML 在线格式化
在线 XML 格式化压缩工具
HSV CMYK 转换工具
HSV CMYK互换工具