理解Delta lake ，理解数据湖

目前遇到的痛点

目前的数据部门从组织架构，从个人的负责的方向，处理的任务上，基于现在的数据架构，以及数仓的建设，看起来比较合理，但是也存在非常大的问题。

目前的数据架构是从客户端上报数据，通过logserver输出到kafka，这时分为了两步取走，第一步通过flink任务，将数据写到hdfs上，然后将数据通过add partition的方式添加到hive里面。第二步是通过flink实时任务，将数据写到CK，或者其他的kakfa做一些开发。这个链路存在哪些问题呢？

1. 数据的质量

如何保证实时数据和离线数据是一致的。在开发中如果两个数据出现不一致的情况下需要费人力去修复数据。或者是新增了指标后如果发现不对，需要回滚任务，对下游的影响很大。

2. 数据的落地成本

通过一些列的链路将数据存储在hive中，需要用到flink团队开发很多的flink任务，以及调度任务将partition加到hive中。人力成本高，而且会存在小文件问题。

3. 数据的时间成本

整个的数据流程的延迟可能在2个小时或者三个小时，才能到数仓的ODS层。然后数仓在去跑自己的任务，真正让用户用上，只能是昨天的数据，或者是6-12小时前的数据。延迟性很差，只能是通过ck进行简单的分
析，不能在线分析，在线机器学习。

上面写了一些链路上的问题，那么我们在使用中有哪些问题呢。

1. 不能支持事务
2. 不能并发读写，我在写数据的时候会报file not found 异常
3. 不支持更新 update delete操作，有些脏数据我想手动更新只能是重跑整个分区或者整个表。
4. 不支持基于历史数据的查询

全新的架构

如下图所示

我们直接通过spark任务将数据存放在 Delta中。

Delta架构可以轻松解决掉上面的问题

1. 支持事务，并发读写。
2. 批流合并
3. 低延迟，高可用
4. 支持数据回滚，支持历史数据根据版本/时间戳查询，及时数据更新了，还能查到历史数据

什么是Delta

我理解下来，可以将Delta看做是一种存储方式，类似于parquet，通过这种存储，实现了支持事务，并发读写，支持数据回滚，版本查询等高级特性。

Delta 可以替换掉传统数仓吗

Delta只是一种存储方式，可以保证数据的高可用，并不能替换到数仓人员，只是可以将HIVE这个工具替换掉。需要将传统的lamda架构的思想扔掉。但是传统ETL模式还在。
因为将ODS数据存储在Delta中，并不能非常清晰的提供给分析师来用，这种数据在Delta中被称为Bronze，需要进行数据的加工，细化，升级为silver/gold的数据。也就是类比于数仓中的
ods/dm/dw分层的概念，这些传统概念还在，所以不能替换掉数仓。还是需要进行数据的加工，这是在加工的过程中，我可以更加专注于数据，而不是生产数据的过程。

Delta的缺点

1. 只能通过spark运行。
2. 对于SQL的支持不够完善，大部分功能还是通过API

我们要用会遇到哪些问题

首先我们要把现在的架构去掉。包括数据传输，数据仓库中的数据，包括数仓开发的表，当然这是很大概念，所以我们需要先从一个topic开始，建立Delta的表，创建Delta的数仓。进行和目前线上的对比
这时就会遇到一些问题：

• Spark的任务，需要平台维护。
• 元数据需要重构。

能够带来哪些收益

未知。。

后记

如果只是将一张数仓加工的dw/dm的parquet存的表，修改为delta的话，其实也可以。能够保证此表支持acid，支持历史数据查询，对一些不紧急不重要并且数据很大的可以尝试。