大数据架构设计-lambda、kappa、以及delta lake详解

本篇着重从以下几个方面展开说明：

1. 大数据架构的发展史
2. 不同架构的使用场景
3. data lake的优越感
4. 后hadoop时代的架构怎么发展

1、大数据架构的发展史

1.1、技术栈

在搜索整理大数据架构的发展史之前，我必须要指出大数据都包含什么，内在决定了外在表现。
我们知道hadoop其实是一个大象，那么这头大象的五脏六腑包含什么，每个都是什么构造，知道了这些，我们才能说这头大象应该怎么由哪些脏器构成才能实现我们称霸世界的决心呢？

就和我一直在和同事贯彻的思想一样，在学习大数据的时候，必须按照数据的流转来看，我们将数据看做水，为了让水更好的到达田地我们需要修筑一条水渠，就是我们常说的pipline。那么数据流从源头到最终的目的地必须经过的处理过程：

1. 数据接入，包含数据源的管理
2. 数据整合，将不同源的数据做标准化处理，不然黄河是黄河的，小溪是小溪的
3. 数据处理，包含异常数据的过滤、限流等
4. 数据存储，包含存储介质，存储方式等
5. 数据加工，将整合后的数据按照业务的要求进行统一指标加工；
6. 数据服务，将加工后的数据通过接口或者其他形式提供给客户；
7. 数据展示，让客户能直观的看到最终的数据形态；

与此同时，我们还需要一些辅助的管理系统帮助我们更好的建设业务：

1. 数据源管理系统
2. ETL系统
3. 元数据管理服务系统
4. 系统监控系统
5. 异常提示及告警系统

基本上通过上述的步骤，我们就能实现农业现代化。。。。。。当然每个细节中会有很多的技术和知识点需要我们一步一步的进行挖掘、学习和总结。

1.2、架构发展史

lambda架构
lamda架构具体是谁提出的，我也懒得查了，我们只总结中心思想：离线+实时

有过大数据开发经验的同事一看这个就知道了，哦，原来我们常说的离线+实时就是lambda架构呀，这不是目前行业内大部分公司在用的架构吗？是的，做架构将就知道的多，别人家一说你们公司用没用lambda架构你不知道，一说离线+实时你就知道了。

其实从我2015年开始做大数据以来到现在，目前很多的公司还是没有实现lambda架构，基本都依靠离线t+1这种模式提供服务，当然也有一些电商公司对pv，uv这些计算使用一些简单的实时流处理架构。

lambda架构不止

kappa

完全的流式处理，典型的架构代表是：kafka+spark-streaming/flink/storm+hbase/redis

现在因为阿里对Flink的重大贡献，社区和各大公司也为了精简开发人员和运维人员成本，主要推行基于Flink的批流一体化的架构节约成本，当然这个架构也对于开发人员在批流一体化过程中的结果融合有相当的功力；

delta lake

为什么都有比较好的这种架构，我们还需要了解和学习data lake？这需要从当前的架构的缺点出发来认识数据湖的好处。

不管是lambda还是kappa架构，和深度学习一样，对于数据的处理我们追求与端对端的数据流，传统的架构做的不好的地方：

1. 数据流程长
2. 开发难度大
3. 系统管理难
4. 数据质量难保证
5. 元数据管理系统难以真正发挥作用

总之一句话：不能让客户和开发人员向使用MySQL一样，通过简单的SQL语句实现数据的全流程操作；
举个例子：有个业务需求，客户要求对某一个指标进行持续不断的增量计算，来一条数据就计算一条数据，而不是针对全量数据进行重复计算。这种情况很快的会想到使用kappa架构即可，但是随着数据源的不断增多，你的实时代码需要进行不断调整和上线，这伴随的压力是多么的大！除此之外，为了保证数据的质量，你可能会想到使用lambda架构：离线保证准确性，实时保证数据延迟性，最后再将这两种流程下的结果进行merge并提供，这会引起的开发人员的增多和运维压力的增大！

那么delta lake有别于其他架构，到底解决了什么痛点问题：

1. 数仓的update，merge
2. 数据的同时读写和数据的一致性
3. 支持事务
4. 修改业务代码而不影响线上服务
5. 良好的迟到数据处理机制

做过数仓的大数据开发人员看到这里会不会眼睛一亮呢？竟然可以解决这些问题，不可思议，虽然有些问题可以通过方案的组合进行解决，但是有的问题根本解决不了呀！比如支持事务这在某些架构师的严重大数据根本实现不了，再比如表的update和merge，我们通常需要创建一个原始表和一个增量表，通过表的join完成数据的update操作等等！

2、delta lake

数据湖通过一个delta中间层来实现这些方案，具体的表结构如下图所示：
图片引用地址

仔细看一下这个表的结构，这里date是作为分区字段，分区下保存该分区的数据文件，同时看到与分区字段平级的还有一个_delta_log目录，这个是干什么的？这个对应关系数据库中的事务日志，记录的是表的变更记录，有点类似于MySQL的binlog文件。

3、总结

比较了比较热门的几种架构以后，我们适当性的做一个总结：

1. 目前还是以lambda架构为主流
2. 批流一体化的架构成为现在乃至未来2-3年重点发展的大数据技术
3. 伴随皮瘤一体化的架构，delta lake技术会被更多的公司采用；
4. 因为delta lake的特性会产生很多的小的事务日志文件，目前阶段还是主要依托spark的优势进行发展
5. 结合delta lake技术，我们的开发人员可以更好的构建业务端对端数据流

下节分享什么呢？每个组件和实战过程中遇到的问题都会在专门的分栏中免费给大家开放，有想了解的可以提建议，要不下次在spark专栏中分享spark如何集成和使用delta lake以及传统lambda架构中怎么实现数仓数据的update。