数据仓库详细分析和说明

Posted 2020-07-04 ArthurKingYs

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

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

传统数据仓库

图1：传统数据仓库的架构

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

实时处理数据仓库

随着业务的发展，一些企业客户需要对一些实时的数据做一些商业分析，譬如零售行业需要根据实时的销售数据来调整库存和生产计划，风电企业需要处理实时的传感器数据来排查故障以保障电力的生产等。这类行业用户对数据的实时性要求很高，传统的离线批处理的方式不能满足需求，因此他们需要构建实时处理的数据仓库。数据可以通过各种方式完成采集，然后数据仓库可以在指定的时间窗口内对数据进行处理，事件触发和统计分析等工作，再将数据存入数据仓库以满足其他一些其他业务的需求。因此，实时数据仓库增强了对实时性数据的处理能力要求，也要求系统的架构在技术层面上需要革命性的调整。

关联发现数据仓库

在一些场景下，企业可能不知道数据的内联规则，而是需要通过数据挖掘的方式找出数据之间的关联关系，隐藏的联系和模式等，从而挖掘出数据的价值。很多行业的新业务都有这方面的需求，如金融行业的风险控制，反欺诈等业务。上下文无关联的数据仓库一般需要在架构设计上支持数据挖掘能力，并提供通用的算法接口来操作数据。

数据集市

数据集市一般是用于某一类功能需求的数据仓库的简单模式，往往是由一些业务部门构建，也可以构建在企业数据仓库上。一般来说数据源比较少，但往往对数据分析的延时有很高的要求，并需要和各种报表工具有很好的对接。

数据仓库架构的挑战

到了移动互联时代，传统架构的数据仓库遇到了非常多的挑战，因此也需要对它的架构做更多的一些演变。

首先最大的问题是数据增长速度非常迅速，导致原有的数据仓库在处理这些数据存在架构上的问题，无法通过业务层面的优化来解决。譬如，一个省级农信社的数据审计类的数据通常在十几TB，现有基于关系数据库或者MPP的数据仓库方案已经无法处理这么大数据，亟需一种新的更强计算能力的架构设计来解决问题。 
其次，随着业务的发展，数据源的类型也越来越多。很多行业的非结构化数据的产生速度非常快，使用传统Oracle/DB2的数据仓库并不能很好的处理这些非结构化数据，往往需要额外构建一些系统作为补充。

再次，在一家比较大的企业内部，因为业务不同企业内部可能会有几百个数据库，各自建设方案也不同，没有一个简单的办法将数据统一到一个数据平台上。因此需要一个数据库虚拟化技术，能够通过有效的方式将各个数据库统一化，有效的进行数据分析和批处理。而在过去，这个技术并不存在。

最后，过去的数据库没有提供搜索和数据挖掘的能力，而这些需求已经是企业的刚需。譬如金融行业需要使用复杂的数据挖掘方法代替传统的规则引擎来做风险控制，而这无法在基于关系数据库的方案中得到解决。随着Hadoop以及Spark技术的快速成熟，基于Hadoop/Spark的数据仓库解决方案能有效的解决这些问题和挑战。

基于大数据的数据仓库关键技术

图2：基于Hadoop的数据仓库架构设计

上图是一个典型的基于Hadoop的数据仓库的架构设计。

首先有一个传统数据仓库层，它包含一个集中的数据存储平台，以及元数据管理，数据稽查和数据处理的工作调度层。数据存储平台包含多种数据源，有结构化数据和非结构化数据。结构化数据的处理分为三层，按照数据模型分成贴源层、基础明细层和公共主题模型层，数据加工业务按照模型进行切分成不同的批处理业务，通过分布式计算引擎来执行离线的批处理计算。同时为了满足多个模型层的业务需求，有一个统一的资源调度层和工作流调度系统，保证每个业务能够得到给定配额的资源，确保资源分配的合理性和有效性。

其次就是几个不同的应用的场景，通过资源管理层动态分配出来的逻辑集群。各个业务集群获取模型层加工的数据，并结合自身的业务使用相关的数据，同时各个业务之间也可以通过数据库联邦等技术在计算中共享数据。这类业务包含各种查询与检索业务，数据集市以及关联发现数据仓库。

此外，上述方案还包括一个实时处理数据仓库。实时的数据源通过消息队列传入系统，按照数据的时间戳进行基于时间窗口的数据处理，如进行一些实时窗口上的数据统计，基于规则引擎的数据处理，甚至是数据挖掘模型的预测等。经过处理后的数据统一输入企业数据总线，其他逻辑数据仓库通过订阅服务获取相关数据。如数据集市可以从总线下订阅窗口数据直接插入内存后者SSD中，从而可以对这部分数据做实时的统计分析。此外，其他的应用也可以在企业数据总线上订阅相关的数据，从而实时的获取业务需要的数据。

因此，基于Hadoop的解决方案能够用一套系统实现企业对传统数据仓库，实时处理数据仓库，关联发现数据仓库以及数据集市的需求，并通过逻辑划分的方法使用一套资源来实现，无需多个项目重复建设。

从技术层面上，现有的一些SQL on Hadoop引擎（如SparkSQL，CDH等）能够部分实现数据仓库的需求，但是离完整覆盖还有一些距离。一些关键的技术特点必须实现突破，才能符合企业的数据仓库建设的业务指标。主要有以下技术指标：

分布式计算引擎

基于关系数据库的数据仓库一个最大的痛点在于计算和处理能力不足，当数据量到达TB量级后完全无法工作。因此，分布式的计算引擎是保证新数据仓库建设的首要关键因素。这个分布式引擎必须具备以下特点：

1. 健壮稳定，必须能够7*24小时运行高负载业务
2. 高可扩展性，能够随着硬件资源的增加带来处理能力的线性增长
3. 处理能力强，能够处理从GB到几百TB量级的复杂SQL业务

目前开源的Map Reduce计算引擎满足健壮稳定和高可扩展性特点，但是处理能力很弱，无法有效的满足企业的性能需求；Spark在最近几年迅速发展，处理能力和扩展性都不错，但是在稳定性和健壮性方面还存在问题；其他一些SQL on Hadoop方案如Flink还处在发展的早期，还不适合商用。MPP的方案都存在一些可扩展性的问题，当数据量很大的情况下（如100TB级别）无法通过硬件资源的增加来解决，只能处理特定数据量级别的需求。

因此从技术选择的角度，Spark引擎如果能够有效的解决稳定性和健壮性问题，是分布式计算引擎的最佳选择。

标准化的编程模型

目前大部分在生产的数据仓库是基于关系数据库或者MPP数据库来实现的，一般系统规模都比较大，代码量级是数万到数十万行SQL或者存储过程。SQL 99是数据仓库领域的事实标准编程模型，因此支持SQL 99标准是大数据平台构建数据仓库的必备技术，而如果能够支持一些常见的SQL模块化扩展（如Oracle PL/SQL, DB2 SQL PL）等，将非常有利于企业将数据仓库系统从原有架构上平滑迁移到基于Hadoop的方案上来。使用非标准化的编程模型，会导致数据仓库实际建设的成本和风险无法控制。

数据操作方式的多样性

不同模型的数据加工过程要求平台具备多种数据操作的方式，可能是从某一文件或者数据库插入数据，也可能是用某些增量数据来修改或者更新某一报表等等。因此数据平台需要提供多种方式的数据操作，譬如能通过SQL的INSERT/UPDATE/DELETE/MERGE等DML来操作数据，或者能够从文件或者消息队列等数据源来加载源数据等。同时，这些操作必须支持高并发和高吞吐量的场景，否则无法满足多个业务同时服务的需求。

数据一致性保证

在各个模型层的数据加工过程中，数据表可能会有多种数据源同时来加工。以某银行的贴源层为例，一个银行的某个总数据表可能同时被各个分行的数据，以及外部数据源（如央行数据）来加工。做并发的对统一数据源加工的过程中，数据的一致性必须得到保障。因此，基于大数据平台的数据仓库也必须提供事务的保证，确保数据的修改操作满足一致性，持久性，完整性和原子性等特点。

OLAP交互式统计分析能力

对于数据集市类的应用，用户对于报表的生成速度和延时比较敏感，一般要求延时在10秒以内。传统的数据仓库需要配合一些BI工具，将一些报表提前通过计算生成，因此需要额外的计算和存储空间，并且受限于内存大小，能够处理的报表存在容量限制，因此不能完全适用于大数据的应用场景。

一些开源项目尝试通过额外的存储构建Cube来加速HBase中数据的统计分析能力，不过存在构建成本高，易出错，不能支持Ad-Hoc查询等问题，此外需要提高稳定性满足商业上的需求。

另外一些商业公司开始提供基于内存或者SSD的交互式统计分析的解决方案，通过将数据直接建立在SSD或者内存里，并通过内置索引，Cube等方式加速大数据量上统计分析速度，能够在10秒内完成十亿行级别的数据统计分析工作。这种方案通用性更强，且支持Ad-Hoc查询，是更合理的解决方案。

多类型数据的处理能力

在大数据系统中，结构化数据和非结构化数据的比例在2:8左右，文档，影像资料，协议文件，以及一些专用的数据格式等在内的非结构化数据在企业业务中非常重要，大数据平台需要提供存储和快速检索的能力。

开源HBase提供MOB技术来存储和检索非结构化数据，基本可以满足及本地的图像、文档类数据的检索，但是也存在一些问题，如Split操作IO成本很高，不支持Store File的过滤等；此外不能很好支持JSON/XML等常用数据文件的操作也是一个缺点。另外一些数据库如MongoDB对JSON等的支持非常好，但是对视频影像类非结构化数据支持不够好。

一个可行的技术方案是在HBase等类似方案中增加对JSON/XML的原生编码和解码支持，通过SQL层进行计算；同时改变大对象在HBase中的存储方式，将split级别从region级别降低到column family级别来减少IO成本等优化方式，来提供更有效的大对象的处理能力。

实时计算与企业数据总线

实时计算是构建实时处理数据仓库的基本要求，也是企业各种新业务的关键。以银行业信贷为例，以前的信贷流程是业务人员在客户申请后去工商、司法等部门去申请征信数据后评分，周期长效率低。而如果采用实时数据仓库的方案，每个客户请求进入企业数据总线后，总线上的相关的微服务就可以实时的去接入征信、司法、工商等数据，通过总线上的一些挖掘算法对客户进行评分，再进入信贷系统后就已经完成了必要的评分和信贷额度的计算等工作，业务人员只需要根据这些数据来做最终的审批，整体的流程几乎可以做到实时，极大的简化流程和提高效率。

Spark Streaming和Storm都是不错的实时计算框架，相比较而言，Spark Streaming可扩展性更佳，此外如果分布式引擎使用Spark的话，还可以实现引擎和资源共享。因此我们更加推荐使用Spark Streaming来构建实时计算框架。目前开源的Spark Streaming存在一些稳定性问题，需要有一些产品化的改造和打磨，或者可以选择一些商业化的Spark Streaming版本。

实时计算的编程模型是另外一个重要问题，目前Spark Streaming或者Storm还主要是通过API来编程，而不是企业常用的SQL，因此很多的线下业务无法迁移到流式计算平台上。从应用开发角度，提供SQL开发实时计算应用也是构建实时数据仓库的一个重要因素。目前一些商业化的平台已经具备通过SQL开发实时计算应用的能力。

Database Federation

由于企业内部存在很多套系统，加上一些数据敏感等原因，不可能所有的数据都可以汇总到数据仓库里面，因此Database Federation技术在很多场景下就是必须的功能。Database Federation技术让平台可以穿透到各个数据源，在计算过程中把数据从其他数据源中拉到集群当中来进行分布式计算，同时也把常见的数据源所具备的特性推到数据源中，减少数据的传输量。一推一拉，使得其性能表现的十分显著，对多重数据源进行交叉分析。

在这一领域有两个流派，传统的数据厂商希望用自己的SQL引擎来覆盖Hadoop，把Hadoop隐藏在他们的引擎下面，这种方式没有把计算完全分布出来。另外一种策略是利用Hadoop的SQL引擎来覆盖原来的关联数据，使原来的关联数据库能够与Hadoop作为同一种数据源来进行完全分布式的计算。这种方式会更符合未来的技术趋势，分布式计算，扩展性增强。

数据探索与挖掘能力

企业经营经常需要做出预测性分析，但预测的准确率却都保持在低水平。这由两大方面原因造成，一方面是因为过去分析的数据都是采样数据，没有大规模的软件系统来存放数据，也无法对大的数据进行分析。另一方面是计算的模型过于简单，计算能力远远不够，无法进行复杂大规模的计算分析，这使得过去的预测都相当不准确。

除此以外，做预测性分析还应具备三方面特征，要具有完成的工具。第一个工具就是要有完整的特征抽取的方式，从大量的数据当中找出特征。即使在今天拥有工具的条件下，也仍然需要人来识别这些特征，做特征抽取。第二个是要有分布式机器学习的算法。目前，这种算法的数量仍然不够全面，我们需要有更完整的机器学习算法的列表。第三点是我们要有应用的工具来帮我们建造一个完整的机器学习算法的pipeline，从而更方便的做出分析。

目前市场上有多种数据挖掘的解决方案和开发商，主要分成两类：以提供模型和可视化编程为主的方案，如SAS；以及以提供算法和标准化开发接口为主的方案，如Spark MlLib等。图形化的方案在开发商更容易，但是这些系统多数和Hadoop的兼容比较差，需要有专用系统。而类似Spark Mllib的方案能更好的和大数据结合，以及比较多的被工业界接受。

安全性和权限管理

数据的安全重要性无须赘述，安全问题在最近几年已经上升到国家层面。对于大数据平台，基于LDAP协议的访问控制和基于Kerberos的安全认证技术是比较通用的解决方案。

此外，数据的权限管理目前在Hadoop业界还处于完善阶段，应该提供一套基于SQL的数据库/表的权限控制，管理员可以设置用户对表的查询，修改，删除等权限，并包含一整套的角色设定，可以通过角色组的设置来便捷的实现用户权限控制。此外，一些应用场合需要提供对表的精确行级别控制。

混合负载管理

统一的数据仓库平台需要能够支持混合工作负载的管理方式，能够对多个租户进行资源的配额，同时也能实现资源共享，闲置资源分给其他客户，并且也能支持抢占。其次，它还需要能够支持资源和数据的隔离性，使多个租户之间互不干扰。再者，它需要具备能力把批处理任务和实时任务分开处理，对一些实时任务进行优化，从而可以支持多用户多部门多种混合复杂的应用场景。

利用容器技术可以有效的实现资源和数据的隔离性，再加上一个资源调度框架，可以实现工作负载和租户资源的配置。目前这个领域是创新的热点，涌现了很多解决方案，大概也有几个流派，一种是基于Mesosphere的技术路线，让Hadoop的应用可以在Mesosphere资源框架上运行。这个方案的弱点首先是不具备通用性，所有的大数据和数据库的框架都需要定制和改造，无法标准化。第二个弱点在于隔离性太弱。另外一种是使用Kubernetes + Docker的方式，所有应用容器化，由Kubernetes提供资源调度和多租户管理，因此更加标准化，方便统一化部署和运维，目前我们认为是更好的解决方案。

微服务架构

随着平台技术的进步，应用系统的设计也将发生重大变化。以前一套系统包括前端、中间件、数据库都多个模块，系统耦合性高，构建复杂。未来的数据仓库上的应用系统可以微服务化，所有的功能由小的服务模块组建的，依靠依赖性让系统自动把应用打包集装，极大地促进了应用迁移的便捷性。有了这样一个系统之后，我们可以轻易的建造有几万个容器组成的应用系统，在上面可以运行几千个应用，它的扩展性可以在几分钟之内扩展到上千容器的规模。同时，它的资源隔离性也很好，满足对多租户的要求，进行资源的隔离、共享、抢占。

对未来的展望

这篇文章介绍了数据仓库的一些特性，以及构建基于Hadoop的数据仓库的关键技术。随着近年来大数据技术的高速演变，我们预计未来三年当中数据库以及数据仓库技术会发生的巨大变化。正如Gartner所预计的，我们的大部分企业客户会把数据仓库从以前的传统数据仓库转移到逻辑数据仓库中，Hadoop在其中会扮演非常重要的角色，很多企业应用也已经开始把Hadoop作为数据仓库的重要组成部分。2016年2月Gartner即将发布数据仓库的魔力象限，届时可以看到Hadoop技术作为数据仓库的技术方案被市场的接受程度。

数据平台市场每年创造的价值巨大，但大部分被Oracle、IBM、Teradata等国外巨头瓜分。因此我们希望更多的国内同行能够投入到基于Hadoop的数据仓库平台的研发之中，打造出大数据时代的杰出数据仓库产品，摆脱国外巨头对这个行业的垄断，帮助中国科技在企业服务领域实现质的突破。