BigQuery：云中的数据仓库

BigQuery: Data Warehouse in the Clouds

原文作者：Sam Taha

原文地址：https://dzone.com/articles/bigquery-data-warehouse-clouds

译者微博：@从流域到海域

译者博客：blog.csdn.net/solo95

BigQuery：云中的数据仓库

近年来，随着大数据革命的进行，如云计算，NoSQL，Columnar商店和虚拟化等技术都发生了很多变化，并涉及到了一些正在改变我们如何管理数据和IT运营的快速发展的技术。以Hadoop和NoSQL等技术为动力的大数据正在改变企业管理其数据仓库和对分析报告进行扩展的方式。存储数TB数据，甚至数PB数据，已经可以实现，现在任何企业都可以负担得起花费数百或数千个产品内核和磁盘来运行并行和分布式处理引擎，例如MapReduce。但Hadoop是否适合所有用户？他们能否找到替代品？特别是那些想要更"实时(real-time)"的大数据分析的人。请继续阅读本文。

Hadoop的一点背景

在使用Hadoop和许多相关类型的大型分布式集群系统背景下，对于任何规模的企业来说，管理数以百计（如果不是数千）的cpu，内核和磁盘都是一项严峻的系统管理挑战。基于云的Hadoop引擎（例如Amazon EMR和Google Hadoop）使这项工作变得更容易一些，但这些云解决方案对于典型的长时间运行的数据分析(实例)来说并不理想，因为需要花费时间设置虚拟实例并将数据从S3中分散出来并分配到虚拟数据节点。紧接着，在完成MapReduce / HDFS实例后，又必须拆解所有内容，以避免为长时间运行的虚拟机支付大笔资金。更不用说，在临时数据节点关闭之前，您必须将数据从HDFS复制回S3，这对于任何严谨的大数据分析都不是理想的方法。

那么事实上Hadoop和MapReduce是基于批处理的，因此不适合实时分析。因此，尽管我们在技术演进方面迈出了许多步伐，但面临管理大型Hadoop集群时系统管理方面的挑战时仍然存在问题，而基于云的Hadoop具有许多局限和限制，如前所述。在目前的形式下，基于云的Hadoop解决方案对于长时间运行的集群处理来说太昂贵，并且不适合长期的分布式数据存储。更不用说虚拟化和Hadoop在目前虚拟化和公共云硬件和软件技术的状态下不太适合 - 这是一个单独的讨论。

BigQuery替代方案

因此，如果我想构建一个严谨的企业级大数据仓库，听起来好像我必须自己构建并自行管理它。现在，进入到Google BigQuery和Dremel的场景。BigQuery在很多方面都是一个严谨的的游戏规则改变者。首先，它真正将大数据推入到云中，更重要的是，它将集群的系统管理（基本上是一个多租户Google超级集群）推入到云端，并将这种类型的管理工作留给擅长这类事情的人们（如Google）。其次，它从头到尾都是真正的多租户，所以系统资源的高效利用率大大提高，这是Hadoop目前的弱点。

将您的数据仓库放入云中

因此，现在考虑到所有这些情况，如果您可以使用BigQuery在云中构建数据仓库和分析引擎呢？BigQuery将为您提供海量的数据存储以容纳您的数据集并提供强大的SQL，如Dremel语言，用于构建分析和报告。将BigQuery看作您的数据仓库之一，您可以在BigQuery的云存储表中存储数据仓库的快速和慢速变化维度。然后使用Dremel，您可以构建接近实时并且十分复杂的分析查询，并对数TB的数据运行所有这些查询。所有这些都可以在没有购买或管理任何大数据硬件集群的情况下使用！

建模您的数据

在经典的数据仓库（DW）中，您可以使用某种雪花模式或者简化的星型模式，围绕一组事实表和维表来组织您自己的模式。这就是通常为基于RDBMS的数据仓库所做的工作。但对于任何使用HDFS，HBase和其他columnar或NoSQL数据存储的人员来说，DW的这种关系模型不再适用。在NoSQL或columnar数据存储中对DW进行建模需要采用不同的方法。在BigQuery的数据表中为DW建模时，这种关系模型是需要的。

(RDBMS = Relationship DataBase Management System, 关系型数据库管理系统，下同，即传统的数据库管理系统，使用结构化查询语言(SQL)，NoSQL与之相对。)

缓慢渐变维度(Slow Changing Dimensions)

缓慢渐变维度（SCD）可以直接用BigQuery数据仓库来实现。由于通常在SCD模型中，您每次都会将新记录插入到DW中。当您从运营数据存储中创建周期性的固定时间点快照时，(使用)SCD模型很常见。例如，季度销售数据总是以某种时间戳或日期维度插入到DW表中。使用BigQuery数据存储区，您可以将每条记录放入每个包含日期/时间戳的BigQuery表中。所以你的ETL看起来像下面这样：

Key(s)... | Column... | EffectiveDate

在这种情况下，时间维度通常被直接坍缩成是事实表，并且您希望尽可能使表格非规范化，以便您的查询需要最少的连接。正如Dremel指出的那样，允许连接(存在)，但要求连接中至少有一个表是“小”的。小的意思是指少于8MB的压缩数据。

因此，现在在Dremel的SQL语言中选择一个特定的记录，对于特定的时间点，您只需执行一个正常的SQL语句，例如：

**SELECT Column1 FROM MyTable WHERE EffectiveDate = DATE\_OF\_INTEREST**

该查询将在已知日期选择一条记录。通过这种方法，您可以查询销售季度数据，例如在您知道该特定日期的记录必然存在的情况下。但是如果你想在任何时间点获得最“最新”的纪录呢？这实际上是Dremel和BigQuery擅长的，因为它为您提供了SQL功能，例如子选择(功能)，这些功能在NoSQL类型的存储引擎中通常找不到。该查询如下所示：

**SELECT Column1 FROM MyTable WHERE EffectiveDate =（SELECT EffectiveDate FROM MyTable WHERE EffectiveDate <= EffectiveDate）**

由于对子选择的性能考虑，此查询在标准RDBMS中有时被认为是不好的做法（特别是对于非常庞大的表）。但是，对于Dremel来说，考虑到Dremel查询扩展的方式以及它们不依赖索引的事实，这不算是问题。

快速渐变维度(Fast Changing Dimensions)

快速渐变维度(FCD)在典型的DW中需要更多的工作才能创建，这与BiqQuery相比没有什么不同。在FCD中，您经常从"运营数据存储"和"通过ETL获取频繁或接近实时的更改"中，将新数据移至DW中。您的ETL引擎通常必须注意何时去插入新的事实或时间维度记录，并且通常包括“终止”记录历史记录集谱系中当前记录的前一个记录。但是，通过充分利用Dremel的强大功能，只需在本地ETL引擎检测到更改时插入新记录而不终止现有的当前记录，即可在BigQuery中支持FCD。由于您可以执行上述的基于生效日期的子选择，因此现在没有理由为每个记录维护生效/终止( effective/termination)日期字段。您只需要生效日期字段。

这使得存储在BigQuery中的FCD模式模型与用于管理时间维度的SCD模型变得相同，但是存在一个问题。ETL过程必须维护BigQuery端存在记录的“Staging DW”。这个Staging DW只保存BigQuery中存在的表中最新的记录，所以这使得它能够保持精简，并且不会随着时间的推移而变大。

因此，使用此模型，您的ETL只会将更改发送到Google Cloud。这种FCD的总体方法对于建模ERP类型的数据来说非常有用，例如，在记录有生效和终止日期(effective and termination)的情况下，以及追踪变化至关重要的情况下。以下是FCD ETL流程图：

将您的数据仓库放入云中

在Grand Logic，我们提供了一种强大的新方法，通过Google云中的BigQuery数据市场构建和扩充您的内部数据仓库。利用我们的实时和可批量处理ETL引擎，我们可以将快速或缓慢移动的维度数据转换为无限容量的BigQuery表格，并允许您运行实时的SQL Dremel查询，以实现可扩展的富(文本)报告(rich reporting，富指数据量比较大)。例如，与在Hadoop中管理自己的HDFS和HBase集群相比，只需很少的前期成本和基础架构即可完成所有这些工作。

借助我们的旗舰自动化引擎和ETL引擎，JobServer，我们可以帮助您在Google云中构建功能强大的数据仓库，并提供丰富的分析功能，只需很少的前期投资即可扩展到大规模级别。您可以在您完全控制数据和报告之后才付钱。

敬请关注此博客，了解Grand Logic如何帮助您在云中构建数据仓库。我们将讨论JobServer产品的更多细节，并且我们的咨询服务将帮助您使用BigQuery。

联系我们以了解我们的JobServer产品如何帮助您将ETL和数据仓库扩展到云中。