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

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

随着越来越多的基础设施往云端迁移，数据仓库是否也需要上云？上云后能解决常见的性能、成本、易用性、弹性等诸多问题吗？如果考虑上云，需要注意哪些方面？目前主流云厂商产品又有何特点？面对上述问题，本文尝试给出一些答案，供各位参考。本文部分内容参考了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云端加载或直接访问，也可以导入数据流。其没有索引，除了数据管理外，几乎不需要维护。

本文转载自异步社区。

原文链接：https://www.epubit.com/articleDetails?id=c3cd9c9e10514a5dab22c7b15670b09a