基于SQL-on-Hadoop的数据仓库技术

基于SQLonHadoop的数据仓库技术数据仓库是企业统一的数据管理的方式，将不同的应用中的数据汇聚，然后对这些数据加工和多维度分析，并最终展现给用户。它帮助企业将纷繁浩杂的数据整合加工，并最终转换为关键流程上的KPI，从而为决策/管理等提供最准确的支持，并帮助预测发展趋势。因此，数据仓库是企业IT系统中非常核心的系统。根据企业构建数据仓库的主要应用场景不同，我们可以将数据仓库分为以下四种类型，每一种类型的数据仓库系统都有不同的技术指标与要求。传统数据仓库图1：传统数据仓库的架构企业会把数据分成内部数据和外部数据，内部数据通常分为两类，OLTP交易系统以及OLAP分析系统数据，他们会把这些数据全部集中起来，经过转换放到数据库当中，这些数据库通常是Teradata、Oracle、DB2数据库等。然后在这上面对数据进行加工，建立各种主题模型，再提供报表分析业务。一般来说，数据的处理和加工是通过离线的批处理来完成的，通过各种应用模型实现具体的报表加工。实时处理数据仓库随着业务的发展，一些企业客户需要对一些实时的数据做一些商业分析，譬如零售行业需要根据实时的销售数据来调整库存和生产计划，风电企业需要处理实时的传感器数据来排查故障以保障电力的生产等。这类行业用户对数据的实时性要求很高，传统的离线批处理的方式不能满足需求，因此他们需要构建实时处理的数据仓库。数据可以通过各种方式完成采集，然后数据仓库可以在指定的时间窗口内对数据进行处理，事件触发和统计分析等工作，再将数据存入数据仓库以满足其他一些其他业务的需求。因此，实时数据仓库增强了对实时性数据的处理能力要求，也要求系统的架构在技术层面上需要革命性的调整。关联发现数据仓库在一些场景下，企业可能不知道数据的内联规则，而是需要通过数据挖掘的方式找出数据之间的关联关系，隐藏的联系和模式等，从而挖掘出数据的价值。很多行业的新业务都有这方面的需求，如金融行业的风险控制，反欺诈等业务。上下文无关联的数据仓库一般需要在架构设计上支持数据挖掘能力，并提供通用的算法接口来操作数据。数据集市数据集市一般是用于某一类功能需求的数据仓库的简单模式，往往是由一些业务部门构建，也可以构建在企业数据仓库上。一般来说数据源比较少，但往往对数据分析的延时有很高的要求，并需要和各种报表工具有很好的对接。数据仓库架构的挑战到了移动互联时代，传统架构的数据仓库遇到了非常多的挑战，因此也需要对它的架构做更多的一些演变。首先最大的问题是数据增长速度非常迅速，导致原有的数据仓库在处理这些数据存在架构上的问题，无法通过业务层面的优化来解决。譬如，一个省级农信社的数据审计类的数据通常在十几TB，现有基于关系数据库或者MPP的数据仓库方案已经无法处理这么大数据，亟需一种新的更强计算能力的架构设计来解决问题。其次，随着业务的发展，数据源的类型也越来越多。很多行业的非结构化数据的产生速度非常快，使用传统Oracle/DB2的数据仓库并不能很好的处理这些非结构化数据，往往需要额外构建一些系统作为补充。再次，在一家比较大的企业内部，因为业务不同企业内部可能会有几百个数据库，各自建设方案也不同，没有一个简单的办法将数据统一到一个数据平台上。因此需要一个数据库虚拟化技术，能够通过有效的方式将各个数据库统一化，有效的进行数据分析和批处理。而在过去，这个技术并不存在。最后，过去的数据库没有提供搜索和数据挖掘的能力，而这些需求已经是企业的刚需。譬如金融行业需要使用复杂的数据挖掘方法代替传统的规则引擎来做风险控制，而这无法在基于关系数据库的方案中得到解决。随着Hadoop以及Spark技术的快速成熟，基于Hadoop/Spark的数据仓库解决方案能有效的解决这些问题和挑战。基于大数据的数据仓库关键技术图2：基于Hadoop的数据仓库架构上图是一个典型的基于Hadoop的数据仓库的架构设计。首先有一个传统数据仓库层，它包含一个集中的数据存储平台，以及元数据管理，数据稽查和数据处理的工作调度层。数据存储平台包含多种数据源，有结构化数据和非结构化数据。结构化数据的处理分为三层，按照数据模型分成贴源层、基础明细层和公共主题模型层，数据加工业务按照模型进行切分成不同的批处理业务，通过分布式计算引擎来执行离线的批处理计算。同时为了满足多个模型层的业务需求，有一个统一的资源调度层和工作流调度系统，保证每个业务能够得到给定配额的资源，确保资源分配的合理性和有效性。其次就是几个不同的应用的场景，通过资源管理层动态分配出来的逻辑集群。各个业务集群获取模型层加工的数据，并结合自身的业务使用相关的数据，同时各个业务之间也可以通过数据库联邦等技术在计算中共享数据。这类业务包含各种查询与检索业务，数据集市以及关联发现数据仓库。此外，上述方案还包括一个实时处理数据仓库。实时的数据源通过消息队列传入系统，按照数据的时间戳进行基于时间窗口的数据处理，如进行一些实时窗口上的数据统计，基于规则引擎的数据处理，甚至是数据挖掘模型的预测等。经过处理后的数据统一输入企业数据总线，其他逻辑数据仓库通过订阅服务获取相关数据。如数据集市可以从总线下订阅窗口数据直接插入内存后者SSD中，从而可以对这部分数据做实时的统计分析。此外，其他的应用也可以在企业数据总线上订阅相关的数据，从而实时的获取业务需要的数据。因此，基于Hadoop的解决方案能够用一套系统实现企业对传统数据仓库，实时处理数据仓库，关联发现数据仓库以及数据集市的需求，并通过逻辑划分的方法使用一套资源来实现，无需多个项目重复建设。从技术层面上，现有的一些SQLonHadoop引擎（如SparkSQL，CDH等）能够部分实现数据仓库的需求，但是离完整覆盖还有一些距离。一些关键的技术特点必须实现突破，才能符合企业的数据仓库建设的业务指标。主要有以下技术指标：分布式计算引擎基于关系数据库的数据仓库一个最大的痛点在于计算和处理能力不足，当数据量到达TB量级后完全无法工作。因此，分布式的计算引擎是保证新数据仓库建设的首要关键因素。这个分布式引擎必须具备以下特点：健壮稳定，必须能够7*24小时运行高负载业务高可扩展性，能够随着硬件资源的增加带来处理能力的线性增长处理能力强，能够处理从GB到几百TB量级的复杂SQL业务目前开源的MapReduce计算引擎满足健壮稳定和高可扩展性特点，但是处理能力很弱，无法有效的满足企业的性能需求；Spark在最近几年迅速发展，处理能力和扩展性都不错，但是在稳定性和健壮性方面还存在问题；其他一些SQLonHadoop方案如Flink还处在发展的早期，还不适合商用。MPP的方案都存在一些可扩展性的问题，当数据量很大的情况下（如100TB级别）无法通过硬件资源的增加来解决，只能处理特定数据量级别的需求。因此从技术选择的角度，Spark引擎如果能够有效的解决稳定性和健壮性问题，是分布式计算引擎的最佳选择。标准化的编程模型目前大部分在生产的数据仓库是基于关系数据库或者MPP数据库来实现的，一般系统规模都比较大，代码量级是数万到数十万行SQL或者存储过程。SQL99是数据仓库领域的事实标准编程模型，因此支持SQL99标准是大数据平台构建数据仓库的必备技术，而如果能够支持一些常见的SQL模块化扩展（如OraclePL/SQL,DB2SQLPL）等，将非常有利于企业将数据仓库系统从原有架构上平滑迁移到基于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成本很高，不支持StoreFile的过滤等；此外不能很好支持JSON/XML等常用数据文件的操作也是一个缺点。另外一些数据库如MongoDB对JSON等的支持非常好，但是对视频影像类非结构化数据支持不够好。一个可行的技术方案是在HBase等类似方案中增加对JSON/XML的原生编码和解码支持，通过SQL层进行计算；同时改变大对象在HBase中的存储方式，将split级别从region级别降低到columnfamily级别来减少IO成本等优化方式，来提供更有效的大对象的处理能力。实时计算与企业数据总线实时计算是构建实时处理数据仓库的基本要求，也是企业各种新业务的关键。以银行业信贷为例，以前的信贷流程是业务人员在客户申请后去工商、司法等部门去申请征信数据后评分，周期长效率低。而如果采用实时数据仓库的方案，每个客户请求进入企业数据总线后，总线上的相关的微服务就可以实时的去接入征信、司法、工商等数据，通过总线上的一些挖掘算法对客户进行评分，再进入信贷系统后就已经完成了必要的评分和信贷额度的计算等工作，业务人员只需要根据这些数据来做最终的审批，整体的流程几乎可以做到实时，极大的简化流程和提高效率。SparkStreaming和Storm都是不错的实时计算框架，相比较而言，SparkStreaming可扩展性更佳，此外如果分布式引擎使用Spark的话，还可以实现引擎和资源共享。因此我们更加推荐使用SparkStreaming来构建实时计算框架。目前开源的SparkStreaming存在一些稳定性问题，需要有一些产品化的改造和打磨，或者可以选择一些商业化的SparkStreaming版本。实时计算的编程模型是另外一个重要问题，目前SparkStreaming或者Storm还主要是通过API来编程，而不是企业常用的SQL，因此很多的线下业务无法迁移到流式计算平台上。从应用开发角度，提供SQL开发实时计算应用也是构建实时数据仓库的一个重要因素。目前一些商业化的平台已经具备通过SQL开发实时计算应用的能力。DatabaseFederation由于企业内部存在很多套系统，加上一些数据敏感等原因，不可能所有的数据都可以汇总到数据仓库里面，因此DatabaseFederation技术在很多场景下就是必须的功能。Databa