我最近在How-tos专家系列介绍了如何在大数据系统上数据建模。在演讲过程中，许多与会者提出了一些非常有趣的问题。众所周知，大数据系统围绕结构需求的形式化程度较低，但是对于数据仓库继续为传统用例提供服务而言，建模仍然是非常重要的功能。我想分享一下我在本届会议期间以及访问组织时收到的一些较常见的问题，并对此做出回应。

1.在大数据环境中，是否可以使用任何建模技术来提高查询性能？

为了提高查询性能，这取决于您使用的工具。以下准则可以帮助您：

1) 确保为最终用户的查询选择最佳存储。例如，如果您正在运行许多简短查询，则应考虑使用HBase。对于长时间运行的分析查询，您可能会发现Kudu更好。理想情况下，检查要运行的查询，并为这些用例确定适当的文件格式。

2)为工作负载使用正确的查询引擎。例如，对于传统上在企业数据仓库出现的长时间运行的查询、供应仪表板或标准报表的场景而言，Hive on LLAP很棒。另一方面，Impala非常适合临时查询100TB以上的数据。在配置查询引擎时，还应确保已设置分区，收集统计信息，确保对连接进行了适当的设计，查看查询性能报告并进行了相应的优化。

3) 确保您为每种用例选择的用于检索数据的工具。例如Phoenix或带有API的HBase之类的工具来运行查询，然后使用Impala或Hive on LLAP来查询数据。

2. 我们的数据科学家喜欢非规范化表或“功能文件”。在对大数据系统进行建模时，我们还能保留这个概念吗？

绝对。这是现代数据仓库的核心功能，被称为分析基础表（ABT）。想象我们是一家主要的电信公司，拥有用于服务使用情况、来电、网络元素等的表。要在所有这些表中建立客户流失模型，我们为客户数据创建一个ABT，并在ABT基础上建立数据科学模型。我们可以按客户、按蜂窝塔、按收入模型等进行细分。ABT就像是数据集市，构建在在数据仓库顶部，无论它是否为星型模式，因此SAS、R等工具或其他需要扁平结构可以在不重组数据的情况下运行，也无需放弃其他用例就可以拥有更传统的事实和维度类型数据模型。

3. 物联网和大数据仓库是否有任何行业数据模型？

预先建立的、预定义的行业特定数据模型曾经非常重要，许多主要的数据仓库供应商都将其作为数据仓库解决方案的一部分提供。尽管我们今天仍然可以看到其中的一些模型，但是与1990年代和2000年代创建这样的模型时代相比，世界已经发生了很大的变化。我们今天使用的数据的不断变化的性质迫使我们质疑结构化规范。可以在此博客中找到一个很好的例子，该博客介绍了美国最高法院关于婚姻判决的数据模型后果（https://qntm.org/support）将数十年前使用异性规范构造建立的数据模型更改为不仅可以容纳同性婚姻，而且可以解决一个或两个伴侣离婚，再婚甚至是婚后性别变化的较大问题，使用传统结构这可能是一个挑战。因此，在大数据世界中对行业标准建模的答案是，我们不对整个行业进行建模，而是为最终用户需求建模，因此随时随地变化的多个模型可以轻松地从数据中获取。并允许在同一数据上采用多种结构来容纳每个用例，而不是要坚持一种适合所有方法的尺寸。

例如，在一家电信公司中，呼叫数据以三种或四种不同的格式存储。首先是让监视机构查看谁在呼叫谁，这可以存储为图形。第二个是可以根据移动电话号码查询HBase或Kudu存储以检索最近的10到30个调用–一个非常离散的查询。HDFS也可以用于长期分析，例如给定城市或地区每天的总通话量。归根结底，这是所有相同的数据，针对三种用例以三种方式存储，以确保获得最佳结果。工业数据模型本身并不是过时的，但需要在用例级别上通过更灵活的数据建模方法加以补充。请记住，在大数据中，我们可以在数据摄取后定义结构，并按需定义结构，从而让我们利用更现代的方法来获益。

4. 在对关系结构建模时，我们通常依靠索引来加快搜索速度。在大数据建模中，我们是否还需要担心索引机制？

是的，没有。这完全取决于文件格式和数据。例如，当使用Hadoop HDFS时，存储技术通过大规模并行性使搜索速度更快，因此您没有或不需要传统索引。ORC确实具有索引的概念，但是它也使用Bloom过滤器。例如，在电信数据模型中，我们有一个主键定义为订户的移动号码，在ORC中有诸如客户类型、客户城市、客户地址等列。我们可以在所有这些列上创建bloom filter，并且当您从该表中选择记录时，将启动过滤器，并且仅读取存在一些搜索条件数据的ORC文件（例如，城市是洛杉矶）。请记住，在大数据系统中，我们将数据分布在成百上千个分区的文件中，

5. 连接事实和维表以进行报告时需要哪种分区或存储分区？

分区可能非常有用，具体取决于所使用的存储。在大数据环境中，分区对于减少返回返回搜索结果所需检查的文件数量非常有帮助（有关更多信息，请参见上面关于Bloom Filters的响应）。例如，我们通常会按日期或非常大的数据集（甚至按小时）对事实表进行分区。对于维度，我们可以根据用例进行划分，例如，如果我们的用户定期在其区域内寻找结果，则可以按地理位置进行划分。但是，您不仅限于一种分区方法，因为您也可以进行逻辑分区，这非常有帮助，因为相同的数据将以不同的动机由不同的用户使用，因此，我们每个人都可以有多个分区服务于不同的业务需求。

6.  在为大数据建模时，与自然键相比，代理键是否有助于更好的联接性能？

是的，代理键绝对可以提供帮助。通常，我们发现代理键的连接基本上更快，尤其是当自然键为字符串列时。整数更易于比较联接性能。但是，还有其他优点。代理键可确保您与源系统更改无关。例如，如果您从内部销售人员管理工具转移到基于云的工具，则不必将旧的自然键映射到新的自然键，则替代项可以保持不变，并有助于确保数据馈入的一致性。仓库而不必更改期末报告。

7. 我们是否可以将一个具有近十亿条记录的大型事实表与多维表合并在一起，其中有些表每条记录都超过一百万条？

是的，这是现代数据仓库真正发挥作用的地方，尤其是使用最新版本的Cloudera解决方案时，这些类型的连接甚至可以非常快地完成。总体性能取决于数据和配置，因此我们建议使用Cloudera Workload XM之类的工具来提供帮助，或咨询专家来设计此类大型工作负载的数据仓库。

8. 数据模型随时间而变化。我知道我们如何在生产系统中的关系数据库中管理模式版本控制。处理大数据建模时版本控制是否有所不同？

数据建模版本控制与传统环境中的版本控制没有什么不同。例如，在Parquet和ORC中，仅添加一个新列非常容易，但删除它并不容易。更改数据类型可能需要一个函数来转换存储的数据（如字符串到整数）。通常，如果您要进行重大更改，则可能必须重新创建维度或事实表。但是，就像关系系统一样，可以使用一些技术使它变得更容易：就像不用更改列数据类型，只需添加具有新数据类型的新列即可。请记住，在大数据世界中，添加列只是在元数据中添加列定义，只有在行设置了值时，我们才添加要存储的任何数据。

9. 基于大数据的仓库与Data Vault 2.0概念基本相同吗？

Data Vault 2.0并不是基于大数据的数据仓库，也不是标准化和维建模的替代品。Data Vault 2.0是定义过渡区域的新方法，但是您仍然需要为数据仓库本身做一个传统模型。这是因为您无法使用喜爱的基于SQL的BI和分析工具来报告数据仓库-您需要一个数据模型才能理解数据。

10. 传统数据仓库快要死了吗？

传统的数据仓库并没有消亡，正在发生的事情是数据仓库作为一门学科正在有效地发展。它正在适应变化。如果您还记得，过去从上到下的建立数据仓库常常导致很高的失败率，据统计，该失败率曾经达到70-80％。想象一下，花了2到3年的时间来开发具有所有研发能力的传统数据仓库，然后发现它失败了。这意味着我们需要以一种更加敏捷的方式来开发数据仓库，从而与业务用户不断变化的需求保持同步，变得更加流畅和快速，并随时可以适应。根据项目的要求，自下而上，快速开发，部署，冲洗和重复，我们使数据仓库变得敏捷，适应性强，并且可以在数天或数周内准备就绪，而过去则需要数月甚至数年。

观看指导手册：Hadoop数据建模，以了解有关Hadoop中数据建模的最佳实践的更多信息。

来源：https://blog.cloudera.com/how-tos-for-gurus-common-questions-on-data-modeling-for-big-data/

作者介绍：Manish Maheshwari, 数据架构师和数据科学家，在构建超大型数据仓库和分析解决方案方面拥有13年以上的经验。我在Hadoop、DI和BI工具、数据挖掘和预测、数据建模方面进行了大量工作。主数据和元数据管理以及仪表板工具，精通Hadoop、SAS、R、Informatica、Teradata和Qlikview。