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

2019-09-05

JiangRen Mr

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

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

一、数据仓库建设

数据仓库(DW)的建设方式有很多种,企业可以根据自身需求进行选择。下图简单罗列了主要的DW建设方案并做出扩展对比。

1.1 建设方案

1)商业方案

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

2)自建+开源

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

3)云+开源

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

4)DW云

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

1.2 方案对比

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

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

1.3 重点对比 - 性价比

从上图中可见:

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

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

二、云端数据仓库

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.1 Shared-Nothing

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

3.2 Shared Disk/Storage

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

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

四、典型数仓云服务

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云端加载或直接访问,也可以导入数据流。其没有索引,除了数据管理外,几乎不需要维护。

 

本文章转载自SegmentFault。

近期开课hot
logo

Follow Us

linkedinfacebooktwitterinstagramweiboyoutubebilibilitiktokxigua

We Accept

/image/layout/pay-paypal.png/image/layout/pay-visa.png/image/layout/pay-master-card.png/image/layout/pay-stripe.png/image/layout/pay-alipay.png

地址

Level 10b, 144 Edward Street, Brisbane CBD(Headquarter)
Level 8, 11 York st, Wynyard, Sydney CBD
Business Hub, 155 Waymouth St, Adelaide SA 5000

Disclaimer

footer-disclaimerfooter-disclaimer

JR Academy acknowledges Traditional Owners of Country throughout Australia and recognises the continuing connection to lands, waters and communities. We pay our respect to Aboriginal and Torres Strait Islander cultures; and to Elders past and present. Aboriginal and Torres Strait Islander peoples should be aware that this website may contain images or names of people who have since passed away.

匠人学院网站上的所有内容,包括课程材料、徽标和匠人学院网站上提供的信息,均受澳大利亚政府知识产权法的保护。严禁未经授权使用、销售、分发、复制或修改。违规行为可能会导致法律诉讼。通过访问我们的网站,您同意尊重我们的知识产权。 JR Academy Pty Ltd 保留所有权利,包括专利、商标和版权。任何侵权行为都将受到法律追究。查看用户协议

© 2017-2024 JR Academy Pty Ltd. All rights reserved.

ABN 26621887572