云端数据仓库的模式选型与建设

数据,对一个企业的重要性不言而喻,如何利用好企业内部数据,发挥数据的更大价值,对于企业管理者而言尤其重要。做为最传统的数据应用之一,数据仓库在企业内部扮演着重要的角色,构建并正确配置好数据仓库,对于数据分析工做相当重要。一个设计良好的数据仓库,可让数据分析师们如鱼得水;不然可能使企业陷入无休止的问题之中,并在将来的企业竞争中处于劣势。数据库

随着愈来愈多的基础设施往云端迁移,数据仓库是否也须要上云?上云后能解决常见的性能、成本、易用性、弹性等诸多问题吗?若是考虑上云,须要注意哪些方面?目前主流云厂商产品又有何特色?面对上述问题,本文尝试给出一些答案,供各位参考。本文部份内容参考了MIT大学教授David J.DeWitt的演讲材料。缓存

1、数据仓库建设

数据仓库(DW)的建设方式有不少种,企业能够根据自身需求进行选择。下图简单罗列了主要的DW建设方案并作出扩展对比。服务器

1.1 建设方案

1)商业方案网络

商业方案,是最为传统的一种,也是过去20~30年的主流方式。企业外购数仓,包括软、硬件一体交付。其典型产品不少,多为国际知名大厂,国产厂商也有部分。架构

2)自建+开源运维

这是不少互联网公司一般采用的方案,经过自建底层基础设施+部署开源软件方式完成。整个方案对企业彻底自主可控,但对自有人员技术要求较高。颇为典型的产品就是GreenPlum。函数

3)云+开源oop

这是上一种方案的变体,即Iaas层经过云厂商提供,其余仍然是自建的。当企业业务已经上云,为更好地数据集成,方便数据迁移,每每会采用此方案。性能

4)DW云大数据

企业直接选用数据仓库的云服务,而再也不独立建设。下文将针对这种状况,重点说明。

1.2 方案对比

针对上述4种方案,从成本、运维、交付、扩展、性能等多角度进行对比。

  • 成本:包括前期购买和后期运营的费用,这里也包含人员投入的折算费用。
  • 运维复杂度:主要针对企业自有技术人员的运维工做复杂度评估。
  • 交付速度:方案的总体交付速度,包括基础设施的购买、建设。
  • 扩展性:包括数仓的容量扩展和性能扩展能力的综合。
  • 性能表现:数仓的总体性能表现。

1.3 重点对比 - 性价比

从上图中可见:

方案一、2,成本、性能相对固定。其中方案1,成本较高,但性能突出;方案2(自建),则二者均为中等。

方案三、4,成本与性能都是一个区间,且范围较大。方案3,主要取决于云厂商提供的基础设施的能力。方案4,则依靠云厂商的数仓云能力。这也对云厂商产品的选择,提出了更高的要求。下文将就此展开说明。

2、云端数据仓库

2.1 云方案优点

基于上面的说明,采用数据仓库的云服务,具备较多优点,包括:

  • 更好的性价比(不管是前期购买、仍是后期运营)
  • 更快的交付速度(最快在分钟级)
  • 更优的弹性能力(扩展或压缩、计算或存储)
  • 更低的运维复杂度(无需专业人士)
  • 更简单地数据集成(若是已上同一云)
  • 更丰富的数据生态(取决于云厂商产品)

2.2 数仓关键因素

数据仓库不一样于交易型数据库,它的构建是为了便于分析海量数据,而不是处理事务。这意味着数据仓库每每比其相应的交易型数据库大几个数量级,同时对于交易型数据库的某些关键特性(例如ACID、响应时间等)可能没有那么重要。相反,数据仓库有本身的需求,亦可做为上云选择因素。

1)多种数据集成方式

将数据放入仓库并正确格式化一般是数据仓库面临的最大挑战之一。传统上,数据仓库依赖于批处理提取转换加载做业-ETL。ETL做业仍然很重要,但如今也有从流式摄取数据,甚至容许你直接对不在仓库中的数据执行查询的能力。

2)支持数据多元查询

现有数据仓库,除了要支持典型批量查询外,还须要支持诸如adhoc类的查询方式。传统大数据技术栈hadoop的MapReduce不太适用于此类查询。不少数据仓库转向大规模并行处理(MPP)数据库,其原始是将数据打散后,经过并行技术在多台服务器上执行。此外,还有相似Spark这种利用内存并行处理技术完成查询。

3)标准数据访问方式

数据仓库支持什么语言进行查询。显然,标准SQL是对用户最为友好的方式,可显著下降用户的使用门槛。此外,诸如Python、R等高级语言,也可为用户带来更多访问的方式。但有些是依赖于方言,这就须要进行仔细评估。毕竟,移植的成本是笔不小的开销。

4)灵活资源弹性能力

数据仓库都是为了处理海量数据的,但其规模变化可能很大。此外,其计算资源的需求也是会随着业务而不断变化。所以对基于云的数据仓库的资源的弹性能力要求很高,这也是区别与传统自建方式一个很是大的优点。这里的资源,不只包括计算资源、也包括数据存储资源。此外,还须要区分是否支持计算、存储的单独提供,而不是紧耦合在一块儿。

5)低廉运营维护成本

数据仓库是复杂的系统,从底层的物理资源、操做系统、仓库软件,到上层的数据对象、访问语句等。做为云上的数仓,是须要提供简单、灵活、自动化、甚至智能化的运维能力,方便客户使用进而节省用户的综合运营维护成本。

6)灵活使用方式

数据仓库自己是资源密集型应用,如何减低用户的使用成本,是云厂商均需考虑的。例如支持暂停与恢复功能,支持计算与存储的独立扩展等。

2.3 是否上云/如何选择?

使用数据仓库云服务,好处多多。那是否都要上云呢?这须要结合企业需求,考量如下因素来决定。

1)是否有足够的技术积累?

数据仓库自己具有较高的技术门槛,即便选择开源也须要摸索积累的过程,除非是直接使用外部商业产品。

2)是否已经在使用云?

若是已是某云的客户,那么从云作数据集成将更加容易。不然,跨云或从本地加载数据,将是一个大工程。

3)是否对可用性要求很高?

这方面各企业差别较大,如企业比较重视可用性,云厂商/商业产品无疑具备优点。

4)数据规模是否很大?

数据仓库的一个核心难点,就是支撑的数据规模。如企业数据规模很是大,将对自建方式带来很大挑战。

5)扩展需求是否强烈?

如企业在快速发展期,其数据规模、使用复杂度等变化很大,这就要求数仓具备很好的可扩展性,可快速适应企业发展。云方案相较于其余三种方案,无疑具备优点。

6)使用特征变化剧烈?

如企业的数据使用,很是具备不肯定性,即要求数仓具备很好地弹性,可根据须要灵活扩缩容;乃至对查询能力也一样有此类要求。非云的三种方案,都很难适应快速变化。

7)短时间成本压力较大?

企业有数仓需求,但短时间经过自建、外采商业都一次性投入过大,亦可考虑云方案。

3、数仓的两种模式

数仓从技术实现上,有两种大的分类。在下面说明厂商产品前,简单普及下。

3.1 Shared-Nothing

  • 节点间经过高速网络互连,访问本地资源不须要经过网络。这种方式设计简单,扩展性较好。在较好的模型设计下,数据无需移动,处理效率高。
  • 节点自己具备计算和存储资源,即二者是须要耦合在一块儿的。这是此模式的硬伤,即存储、计算没法分离,没法作到按需独立弹性。

3.2 Shared Disk/Storage

  • 节点间互相访问或节点访问存储,都是须要经过高速网络。数据自己都是存储在”远端存储”中,而非本地。网络可能成为瓶颈,受到IO传输总量的限制。网络除了承载节点间的数据交换流量外,更多的是要承担大量数据访问的流量。
  • 这种方式弹性很好,计算、存储可独立扩展。

两种方式的优劣,尚无统必定论,但较为主流是采用shared disk/storage的共享方式。但这种方式下,远端存储的性能?如何利用本地存储?网络性能对总体影响?如何实现动态资源分配?扩缩容的实现?等问题均值得研究。

4、典型数仓云服务

4.1 Amazon (AWS) Redshift

Redshift是典型的shared-nothing设计,本地挂载存储。充分利用AWS的基础服务,EC2做为计算节点,S3做为存储及故障恢复使用。优点在于经过调整和定制,性能表现突出;但其架构也决定了计算与存储不能独立缩放。

支持从多种数据源加载数据,也支持集成流式数据,但只支持结构化数据。支持直接对S3上的数据进行查询,而无需ETL。其支持PostgreSQL的方言,对有些数据类型和函数不支持。Redshift自己监控组件性能并自动恢复,其余维护工做由用户负责。平常运维工做,经过用户手工在控制台完成。

4.2 Snowflake

Snowflake是Shared-storage设计,存储与计算分离。自己构建在AWS上,充分利用AWS的基础服务能力,EC2做为计算节点,本地支持缓存,数据表存储在S3中。它提出一种“虚拟仓库”的概念,每一个查询可分配到不一样的虚拟仓库中,针对不一样的仓库也分配不一样的资源。仓库间不会影响性能,且仓库自己具备很高的弹性,可自动提供额外的计算资源。

支持结构化和半结构化数据,不须要ETL或预处理就能够摄取这些数据。虽然先不支持流式数据,但可链接到Spark以接收流数据。它使用标准SQL并作了适当扩展。其维护比较简单,不须要维护索引、清理数据等工做。

4.3 Microsoft Azure SQL Data Warehouse

SDW是Shared-Storage设计。基于微软的SQL Server PDW软件,利用Azure存储弹性能力。对T-SQL的全面兼容,可动态调整资源,可经过Ploybase支持非加载访问。

4.4 Google BigQuery

BigQuery是存储与计算分离设计,利用Google的基础服务能力,存储在Collosus FS。工做机制是将SQL查询转换为低级指令,依次执行。其彻底抽象了资源的提供、分配、维护、扩缩容等,全部都是Google自动处理。很是适合易用性做为第一诉求的场景。存储上根据处理规模、负载等状况,自动分配分片。计算上资源不专有,在内部和外部客户复用。不能显式控制单一查询的资源使用。计费上使用按计算量收费方式(TB “processed”)

使用上支持标准SQL,也支持半结构化数据类型,支持外部表。支持从Google云端加载或直接访问,也能够导入数据流。其没有索引,除了数据管理外,几乎不须要维护。

做者:韩锋

首发于做者我的公号《韩锋频道》。

来源:宜信技术学院

相关文章
相关标签/搜索