数据仓库、数据集市、数据湖，你的企业更适合哪种数据管理架构？

建设企业级数据平台，首先需要了解企业数据，确认管理需求，并选择一个数据管理架构。那么面对纷繁复杂的数据来源，多元化的数据结构，以及他们的管理使用需求，企业数据平台建设该从何处入手呢？哪个数据管理架构适合自己的企业呢？本篇将介绍数据仓库、数据集市、数据湖。

— 数据仓库（Data Warehouse）—

数据仓库是Bill Inmon在1991年出版的“Building the Data Warehouse”一书中所提出的定义被广泛接受：数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策（Decision Making Support）。

数据仓库是企业的统一的数据管理方式，将不同应用中的数据汇聚，然后对这些数据加工和多维度分析，并最终展现给用户。它帮助企业将纷繁浩杂的数据整合加工，并最终转换为关键流程上的KPI，从而为决策/管理等提供最准确的支持，并帮助预测发展趋势。因此，数据仓库是企业IT中非常核心的系统。

根据企业构建数据仓库的主要应用场景不同，我们可以将数据仓库分为以下两种类型，每一种类型的数据仓库系统都有不同的技术指标与要求。

• 企业数据仓库

企业会把数据分成内部数据和外部数据，内部数据通常分为两类，OLTP交易系统以及OLAP分析系统数据，他们会把这些数据全部集中起来，经过转换放到数据库当中，这些数据库通常是Teradata、Oracle、DB2数据库等。然后在这上面进行数据的加工，建立各种主题模型，再提供报表分析业务。一般来说，数据的处理和加工是通过离线的批处理来完成的，通过各种应用模型实现具体的报表加工。 

* 实时数据仓库

随着业务的发展，一些企业客户需要对一些实时的数据做一些商业分析，譬如零售行业需要根据实时的销售数据来调整库存和生产计划，风电企业需要处理实时的传感器数据来排查故障以保障电力的生产等。这类行业用户对数据的实时性要求很高，传统的离线批处理的方式不能满足需求，因此他们需要构建实时处理的数据仓库。数据可以通过各种方式完成采集，然后数据仓库可以在指定的时间窗口内对数据进行处理，事件触发和统计分析等工作，再将数据存入数据仓库以满足其他一些其他业务的需求。因此，实时数据仓库增强了对实时性数据的处理能力要求，核心的计算引擎需要基于实时计算平台，如开源的Flink或星环科技自研的Slipstream，通过实时引擎来对接机器学习、可视化分析和实时调度类应用。

 —数据集市（Data Mart）—

数据集市是一个有针对性的数据仓库版本，它包含一个较小的数据子集，这些数据对组织内的单个团队或选定用户组很重要且是必需的。由于数据集市包含较小的数据子集，因此在使用更广泛的数据仓库数据集时，数据集市使部门或业务线能够更快地发现更有针对性的洞察。最初创建数据集市的目的是应对组织在20世纪90年代建立数据仓库的困难。当时集成来自整个组织的数据需要进行大量手动编码，而且非常耗时。与集中式数据仓库相比，数据集市的范围更有限，使其实现起来更容易且更快速。到了大数据时代，虽然企业数据仓库和数据湖在各个企业都已经普及，但是每个部门自身也有对业务数据进行处理分析统计的需求，而且不涉及到和其他数据交互，因此特定的部门不希望在数据量大的数据仓库进行操作（因为操作慢，而且可能影响到其他人处理数据），所以建立一个新的存储系统，把数据仓库里关联自己的数据存储到这个系统，本质上算是数据仓库的一个子集。这个系统叫做数据集市。

相比较数据仓库，由于数据集市涉及的数据源集中于某个部门或者业务线的主体，因此其处理的数据会小很多，业务构建比较敏捷，对用户需求的响应也会更加迅速。对集市的用户来说，由于仅开放给某个部门或业务主体，其对多租户隔离的需求也不是很强，用户可以更加简单方便的获取数据，可以简单的通过数据报表工具或Excel等工具来做数据分析，因此对基础设施的依赖就相对比较低，建设成本也相对更低。此外，对集市的实施人员来说，涉及到要加工处理的数据比较少，数据加工时间会短很多，安全管理的要求也比较低，因此建设和运维相对更低。总体上说，因为数据集市都是集中在某个单一的业务领域，对实施人员和业务用户来说都比较敏捷和灵活。

按照集市和数据仓库或数据库的关系，数据集市也可以分为三种类型：

• 独立数据集市 ： 独立的数据集市系统，不依赖数据仓库或数据湖，一般直接从数据源系统加载必要的数据做加工后按照业务主体提供业务分析结果； 
  
•  关联数据集市： 是数据仓库或数据湖的一个部分，一般对应数据仓库的数据集市层，相关的数据加工处理由数据仓库的批处理任务完成； 
  
• 混合数据集市： 主题数据的来源包括了数据仓库、数据湖，也包括了其他的数据库。这种集市的好处是既能包含企业自顶而下设计的从数据仓库中加工而来的业务主题数据，又能满足自下而上的一线分析师的灵活提出的业务需求。
  
   数据集市的底层一般是一个独立的数据库，并且一般提供高并发的统计分析和检索服务，因此对数据库的并发计算性能要求比较高。为了保证数据集市的并发性能，关键技术包括这两种：一是数据库层采用支持高并发访问的分布式数据库来支撑，二是采用OLAP Cube技术。

分布式数据库由于其可扩展性能的优势，能够支撑更高并发的连接访问，并且分布式计算引擎的统计分析SQL的性能更强，还可以通过增加硬件资源来扩展性能，因此针对一些用户规模较大、或者BI报表涉及的报表计算非常复杂的部门或业务线，可以采用分布式数据库。

OLAP Cube技术是将一些数据建模结果预先计算出来，这样分析人员使用数据的时候就可以灵活的做各种深入分析，如数据下钻、切片等，就可以通过预计算的数据来访问，而无需去查询底层数据库或重新计算数据，因此如果访问数据能够命中Cube，业务的并发访问性能将得到极大的提升。OLAP Cube本身是采用空间换时间的优化策略，它需要用户来指定预计算的schema，此外Cube建模工具会有优化方法来减少需要持久化的Cube数据，从而减少预计算需要的处理时间和存储空间。OLAP Cube技术根据其持久化数据的方式又分为ROLAP和MOLAP，简单理解ROLAP是将建模的Cube数据持久化在数据库中，而MOLAP一般是将Cube数据持久化在报表工具或建模工具中。

— 数据湖（Data Lake）—

数据湖是一种企业数据架构的实现方式，在物理实现上是一个存储库，允许用户以任意规模存储所有结构化和非结构化数据，并支持对数据进行快速加工和分析。用户可以按原样存储数据（无需先对数据进行结构化处理），并运行不同类型的分析（从控制面板和可视化到大数据处理、实时分析和机器学习，以指导做出更好的决策。

最初创建数据湖的目的是应对数据仓库无法处理数量、速度和种类不断增加的大数据的情况。虽然数据湖比数据仓库慢，但它们的价格也更低廉，因为在采集之前几乎不需要数据准备。与数据仓库或数据集市不同的是，数据湖上存储原始数据，通常为PB级别，一般没有复杂的业务建模，主要做一些基础的数据治理或者基础性的模型建设工作，更多的为企业内部提供一个公共的数据存储和探索能力，并为下游的集市、仓库或者中台提供数据与计算能力。很多企业会同时建设数据湖和数据仓库，从而保证更好的数据架构与用户体验。

数据湖支持广泛的用例，因为在收集数据时不需要定义数据的业务目标。数据湖可以存储结构化和非结构化数据，这种灵活的存储需求对于数据科学家、数据工程师和开发人员尤其有用，让他们能够访问数据进行数据发现练习和机器学习项目。数据科学家可以使用数据湖进行概念验证。机器学习应用程序可以从能够在同一个地方存储结构化和非结构化数据中受益，这是使用关系数据库系统无法实现的。数据湖也可以用于测试和开发大数据分析项目。当应用程序开发完成并识别出有用数据后，可以将数据导出到数据仓库以供操作使用，并且可以利用自动化来实现应用程序扩展。数据湖还可以用于数据备份和恢复，因为它们能够以低成本进行扩展。数据湖非常适合存储尚未定义业务需求的“以备不时之需”数据，现在存储这些数据意味着可以在以后出现新计划时使用。

从实现方式上看，目前Hadoop是最常用的部署数据湖的技术，也有采用MPP+Hadoop的混合架构，近年也有一些基于公有云存储的数据湖方案出现和落地。

为了满足多样化的数据存储与分析的需求，在数据湖的建设中，我们需要设计确保落地后的数据湖具备以下4个关键能力：

• 数据整合能力
  数据湖需要提供相关的工具或能力，可以整合包括各种关系数据库存储的结构化数据，以及从各个其他渠道（包括互联网、内部文档、传感器）等收集和存储非结构化数据，并且具备多样化的数据整合策略，包括实时、准实时、离线整合等，允许整合过程中的数据转换等能力。
• 数据计算能力
  由于数据湖中积累了企业内部的多样化的数据，因为使用者可以打通内部各种数据，从而分析其中的数据规律，从而进一步指导和预测分析。因此，数据湖需要给使用者提供强大的数据计算能力，能够快速地从海量数据中检索到关键信息，或是能够做大量数据的碰撞找到关联关系，或是对非结构化数据进行深度的识别分析等，这些都需要数据湖的平台提供完善的数据计算能力。
• 数据治理能力
  由于数据湖中汇集了原始数据，未做复杂的数据模型加工，因此可能存在湖内的数据本身有较多质量问题的情况，或者各个数据源头的标准不统一，因此不能很好地用于指导数据分析业务。因此，数据湖的建设者需要提供工具或计算能力给使用者，可以在数据湖内做进一步的数据治理，从而提高数据质量和价值。
• 数据服务能力
  数据湖在设计的时候，需要充分考虑如何提供给更多的数据需求者来自助服务，用户可以在数据湖上发现数据、分析数据、改进数据以及最终贡献数据，从而形成一个从数据到价值链路的闭环。在这个过程中，有效的数据资产目录可以有效地帮助用户来打通数据链路，而多租户服务能力是核心的技术要求。

除了以上4个核心的功能性需求以外，还需要关注一些重要的非功能性需求，包括：

• 互操作性
  数据湖本身需要跟企业内部的各个数据系统有很好的互操作性，因此数据整合的工具或系统需要有良好的连接互通性，可以与关系数据库、NoSQL、实时数据系统、企业级对象存储等各个系统建立高效的数据交互通道。
• 有效的成本控制
  由于数据湖本身的特点，存储的数据量一般比较大，数据价值密度低，因此需要非常关注本身的成本控制，总体方案上需要较低的硬件成本和运维成本，以及较好的资源使用效率，有较好的弹性伸缩，能够支持计量计费等。
• 多租户
  数据湖一般会开放给企业内多个部门或组织共用，而每个使用者本身运行的业务各自有特殊性，譬如机器学习的任务计算复杂度高，CPU消耗大，而检索类任务磁盘IO密集使用，面向多个用户同时提供服务，如果要保证用户体验，数据湖底层需要提供良好的资源共享与隔离能力。

• 业务连续性
  此外，高可用与灾备能力也是数据湖的一个关键要素，在技术的设计上需要充分考虑相关的技术要求，从而实现极端故障下的业务快速恢复能力。

  — 小结—

  本篇介绍了数据仓库、数据集市、数据库等数据管理架构。那么对于平台建设落地，该如何根据企业数字化程度，建立一个可持续演进技术架构呢？在接下来的几篇中，我们将根据企业数字化程度，分五个阶段来介绍。下一篇：存储与算力基础建设