初探数据湖

简单聊聊数据湖

一、 什么是数据湖

“数据湖”最近好像一下子火了，远比“数据仓库”要吃香，在做云计算的公司都在主推这一概念。关于这个概念的标准解释，不论是Wiki也好、AWS也罢，基本上都集中在几个共性上：

存储能力：支持企业数据的海量存储需求；
数据类型：支持结构化、半结构化及非结构化数据；
数据管理：完善的数据信息管理能力，包括但不限定于权限、数据格式、血缘追踪等；
个性化分析：不仅要支持离线批量处理，也要支持实时流式处理，以及交互式分析需求；
生命周期管理：原始、中间、结果数据的生产与管理；
可扩展性：当系统整体遇到瓶颈时，支持横向扩展。
可以说，数据湖是支持企业级应用的、能够适应快速发展技术趋势的一种基础设施。

二、对比数据仓库

对数据湖概念够了一定的理解后，我们就产生了新的疑问：“它跟数据仓库有什么区别？”

数据仓库，准确说，是面向历史数据沉淀和分析使用的，有三大特点：其一是集成性，由于数据来源众多，因而需要技术和规范来统一存储方式；其二是非易失和随时间变化，数据仓库存储了过去每一天的快照且通常不更新，使用者可以在任一天向前或者向后对比数据的变化；其三是面向主题，根据业务对数据进行有效的编码，让理论最佳值在应用中落地。
数据湖，准确说，其出发点是补全数据仓库实时处理能力、交互式分析能力等新技术缺失的情况。其最重要的特点，就是丰富的计算引擎：批处理、流式、交互式、机器学习，该有的，应有尽有，企业需要什么，就用什么。数据湖也有三个特征：其一是灵活性，默认业务的不确定性是常态的，在无法预期未来变化时，技术设施基础，就要具备“按需”贴合业务的能力；其二是管理性，数据湖需要保存原始信息和处理后的信息，在数据源、数据格式、数据周期等维度上，能够追溯数据的接入、存储、分析和使用等流动过程；其三是多态性，本身的引擎需要进可能的丰富，因为业务场景不固定，而多态的引擎支持、扩展能力，能够较好的适应业务的快速变化。

三、数据湖的当前架构

Hadoop架构：Hadoop是离线批处理数据的典型代表，通过HDFS + MapReduce + Yarn，解决了海量数据的处理需求。由于项目开源，因此产生了众多的衍生产品：例如Key-Value数据引擎HBase，SQL分析引擎Hive，交互式引擎Spark Streaming、Presto、Impala等。MapReduce也逐渐的晋升到了DAG模型，针对计算过程进行分解，支持并发处理，提高了整个集群的运行效率。
Lambda架构：Lambda架构的核心理念是“流批一体化”，因为随着机器性能和数据框架的不断完善，用户其实不关心底层是如何运行的，批处理也好，流式处理也罢，能按照统一的模型返回结果就可以了，这就是Lambda架构诞生的原因。现在很多应用，例如Spark和Flink，都支持这种结构，也就是数据进入平台后，可以选择批处理运行，也可以选择流式处理运行，但不管怎样，一致性都是相同的。
Kappa架构：Lambda架构虽然理念很好，但用多了会有一个问题：数据复杂性大大增加。为了解决复杂性的问题，有人提出了用一套架构解决所有问题的设想，而流行的做法就是基于流计算来做。通过加大流计算的“时间窗口”，来实现逻辑意义上的批处理操作。

四、数据湖的架构抽象

数据湖概念的诞生，其实反映了一点：那就是对于大型企业而言，数据是重要资产，已经形成了思维层面的共识。为了更好的理解数据、处理数据，就不能只有历史数据的分析能力，而要有“实时、适时、全时”的综合分析能力。如果把数据湖更加的抽象一步，自底向上，与OSI类似，数据湖的架构抽象有七层：数据源、数据收集层、数据存储层、资源管理与服务协调层、计算引擎层、数据分析层及数据可视化层。图示如下：