百花齐放的大数据生态
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。
截止到笔者写这些文字之前，官方还没有支持。不过官方透露阿里的同学已经在做这块的整合。