下载掌阅APP，畅读海量书库
立即打开
任何企业的日常运营都需要用到多个系统来支撑业务，当企业业务人员需要多个系统的数据进行决策的时候，就需要依赖业务系统数据的集中化管理。1990年，Bill Inmon提出数据仓库的概念，基于数据仓库理论中定义的数据存储架构并结合数据建模理论，可以整合不同OLTP系统中累积的大量数据，并构建企业商业智能（BI），以帮助决策者拟定角色或快速应对外在环境变动。
20世纪90年代，以Oracle、DB2、Teradata为代表的关系型数据库占数据库的主导地位，但随着Google在2003年发布了关于分布式文件系统的论文“Google File System”，自此拉开了以Hadoop为首的大数据时代。经过近10年左右的发展，实时计算组件逐步成熟，关于数据架构的发展也逐步进入另外一个阶段。
然而，从数据仓库概念提出到现在，数据架构发生了一系列变化，主要可以分为如下5个：传统数据仓库架构、传统大数据架构、流式计算架构、Lambda架构以及Kappa架构。接下来我们针对这5个架构的特点进行详细阐述。
前面第2章已经介绍过，数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。它帮助企业打破数据孤岛，提高企业数据利用率，实现数据共享。总的来说，数据仓库的主要目的是协助企业进行支持管理决策，这也是经常提及的BI系统的核心功能。
从数据仓库的核心构成来看它主要分为两部分，从技术层面来看为数据仓库所采用的数据存储技术；从业务层面来看为构成数据仓库的数据模型。而传统数据仓库中的“传统”主要针对的是数据仓库所采用的数据存储技术，与后面的大数据技术区分开。
如本节概述中所提到的内容，这一时期的数据仓库存储的主要是基于传统技术的关系型数据，而非基于后面的大数据技术；数据源都是结构化数据而非大数据时代的半结构化或者非结构化数据；数据抽取的方式都是基于定时批处理的ETL作业等。此时数据仓库提供的数据应用服务主要是偏重数据分析的应用场景，并且数据仓库与下游平台的系统交互往往都是基于结构化数据的方式进行交互（例如数据文件），基本上不存在API层面的交互。
这个时期的数据仓库架构主要包含如下几部分：数据调度平台、数据管控平台以及数据分发平台。其中调度平台以及管控平台在之前的章节都有提及，这里不再赘述，而数据分发平台主要是对数据仓库需要推送给下游的数据文件进行集中化管理，减少数据仓库平台的压力，并且方便对于数据的追踪加密或者定制化管理等。传统数据仓库的典型架构如图5-1所示。
后面的架构迭代主要是从技术上驱动数据仓库的架构迭代发展，例如拓展数据源种类、提供多样化的数据服务方式以及提升数据时效性。然而需要注意的是，无论技术如何迭代，数据仓库的业务层面的特点，即构成数据仓库的数据模型的方式以及特点并未随着技术的发展而发生较大变化。
Tips 现在的数据架构慢慢从数据思维发展成应用思维，这种变化的原因是早期的数据仓库从业人员都是ETL人员，并不会使用高级语言进行开发，而随着大数据逐步发展，需要使用高级语言进行开发，应用人员逐步增加导致系统的发展以及设计越发偏向应用。
此外也存在一些基于分布式架构构建的数据仓库，例如分布式数据库Greenplum也是传统数据仓库架构中一款比较流行的应用。
图5-1 传统数据仓库的典型架构
Google在2003～2006年期间的三篇论文“Google File System”“MapReduce”以及“BigTable”拉开大数据架构的热潮。
这一时期的数据仓库主要是基于大数据架构建立的，例如采用HDFS、Hive、HBase、Pig、Sqoop等组件搭建而成。说到这里可能有读者会有疑问，为什么依然称作传统的大数据架构呢？这里的传统并不是代表技术层面的传统，因为已经采用了大数据技术，而是代表该时期的数据仓库的目的依然主要是服务企业数据决策，即BI决策。
从好的方面来看，技术层面的更替极大地扩展了企业可以利用的数据范围，例如以前无法使用的半结构化数据以及非结构化数据都基于MapReduce技术可以被企业利用起来，数据范围更广，数据类型变得更加多样化；从不好的方面来看，由于采用完全不同于传统数据仓库的技术组件，企业如果想采用大数据架构搭建数据仓库，基本上都需要重建数据仓库，重新开发相关的业务逻辑等。基于大数据架构的数据仓库如图5-2所示。
图5-2 基于大数据架构的数据仓库
这个时期数据仓库的相关主要模块以及开发语言已经发生变化，详细对比如表5-1所示。
表5-1 传统数据仓库与大数据仓库架构对比
从表5-1可以看到，大数据架构下的技能要求与传统数据仓库从业人员的要求相比已经发生较大的改变。传统的脚本语言已经有向高级语言发展的趋势，使用的工具也发生了较大的变化，例如从关系型数据库到HBase等非关系型数据库，应用开发人员已经深度介入到具体的数据架构中，应用开发人员对于数据架构的影响会在本书的第四部分进行分析。
大数据组件不仅提供支持传统数据批处理的组件，同样提供部分流式计算的组件以满足一些实时场景。
无论是传统数据仓库架构还是大数据架构，主要都依赖于数据批处理来满足企业数据需求，然而随着部分支持流式计算的组件出现，例如Flume、Kafka、Storm、Spark Streaming等，流式计算架构应运而生。至此大数据相关组件不仅支持离线的数据处理场景，也同时支持实时的数据处理场景。
相比传统大数据架构，流式计算架构完全去除了ETL作业而采用消息的方式进行数据传输。当实时数据接入系统后，按照既定的时间窗口，例如每10 s、每5 min进行数据处理，处理完成之后将数据的结果再次推送到消息队列中，让下游的消费者进行后续的操作。
这样做的好处与坏处都相当明显。从好处来看，数据处理的效率非常高，只要上游有数据产生，那么按照既定的逻辑处理后的数据在非常低的延迟就可以被下游应用消费；从坏处来看，由于实时数据只能按照时间窗口进行数据处理，因此无法满足针对历史数据进行处理的需求。此外在流式计算架构中，如果系统的指标或者逻辑发生修改，数据需要从消息源头重新进行计算。
基于上述的现状，流式计算架构应用于一些非核心的场景中，例如日志告警、资源监控等。这些数据对于历史数据的依赖不高且指标相对固定，不会频繁变化。常见的流式计算架构如图5-3所示。
图5-3 常见的流式计算架构
传统数据仓库架构、大数据架构或者流式计算架构都是属于数据仓库范畴的架构应用，并未进入数据湖阶段，接下来的架构主要是基于数据湖阶段而进行展开的。
Lambda作为希腊语中的第十一个字母，代号为λ。Lambda架构主要是为数据湖而生的，在Tomcy John的“Data Lake for Enterprises”一书中详细阐述了如何利用Lambda架构去构建企业数据湖。
Lambda架构中主要存在两条核心的数据处理链路：第一条为离线数据处理，即我们常说的批处理；第二条为实时数据处理，依照流式架构满足数据的实时型需求，进行数据增量的计算。离线的数据架构保证数据最终的一致性。换句话说，因为批处理往往采用的是 T + N 的模式，在 T 日，实时层提供 T 日的数据应用，离线层提供历史数据的查询功能；当 T 日结束后，离线层与实时层的数据进行同步，保证数据最终的一致性。常见的Lambda架构如图5-4所示。
图5-4 常见的Lambda架构
Lambda架构是完全基于Hadoop相关组件构建的（按照Wiki百科的定义），这也是在传统的数据仓库架构中，利用一些数据ETL组件或者非大数据组件构建的离线处理层以及实时层并不能称为Lambda架构的原因。
Tips 传统数据架构中离线层采用Informatica，实时计算层采用RabbitMQ或者ActiveMQ，两者一起构建并不能称为Lambda架构。
虽然Lambda架构是基于大数据架构构建的，但是它包含的离线层、背后的数据模型依然与传统数据仓库的数据模型类似，并没有本质上的区别。
Kappa作为希腊语中的第十个字母，代号为κ。正如Lambda架构是为数据湖而生一样，Kappa架构也是数据湖的另外一种架构方式。Kappa在Lambda 的基础上进行了优化，将实时部分和流部分进行了合并，将数据通道以消息队列替代在Lambda中的离线层，将实时层进行拓展，以满足企业对于数据的实时性要求。
5.1.3节中提到的流式计算架构与这里的Kappa架构从技术层面上看并没有本质的区别，但是流式计算架构是作为数据仓库的补充，而Kappa架构是作为数据湖的架构，定位发生大的变化。在数据湖中，历史数据进行了存储，当需要进行离线分析或者再次计算的时候，则将数据湖的数据再次经过消息队列重播一次则可。常见的Kappa架构如图5-5所示。
图5-5 常见的Kappa架构
从架构层面来看，Kappa架构清晰、简单。它移除了Lambda架构中的离线层部分，以数据重播的方式，实现系统对于历史数据的支持。但在Kappa架构中，需要考虑实施的复杂度，以及对于历史数据重播的支持。
上面提到Lambda架构中包含的离线部分与传统数据仓库的数据模型类似，但是Kappa架构中已经不包含传统的数据建模的体系框架，并且实时架构中模型层的建设思路已经不同于传统数据仓库的建设思路，同时这个阶段更多的是由应用开发人员主导整个数据架构的搭建，这些现象都是底层技术发生变化所带来的。
数据湖的建设对于企业的意义毋庸置疑，为此接下来我们将着重讨论Lambda架构与Kappa架构的组成，深入地了解架构的异同点，加深读者对这两种架构的理解。
