[持续更新] 数据仓库冷门知识

七里臭臭

已于 2023-12-19 22:48:49 修改

阅读量291

点赞数

文章标签：数据仓库 hive

于 2023-09-19 14:44:18 首次发布

本文链接：https://blog.csdn.net/aqilichouchou/article/details/132986735

版权

ods层是必须的吗?

ODS层在数据仓库架构中通常是必须的
ODS层用于接收和存储来自源系统的原始数据。在ODS层中，就算不进行数据抽取和清洗，大部分的表也需要存储历史数据，完成部分溯源和数仓分层中隔离上游数据的作用。

yarn的容器的填充策略（非调度策略）

在YARN中，容器的填充策略指的是如何在集群中分配和利用可用的计算资源。填充策略决定了如何选择和分配YARN的容器，以最大化资源利用率并提高作业的执行效率。举一个例子来说明容器的填充策略：假设有一个YARN集群，其中有两个节点，每个节点有4个CPU核心和8GB的内存。现在有两个作业A和B需要在该集群上运行。作业A需要2个CPU核心和4GB内存，作业B需要3个CPU核心和6GB内存。

首先，如果填充策略是"最佳适应"（Best Fit），那么YARN会尽量选择最适合作业资源需求的节点来运行任务。在这种情况下，作业A会被分配到第一个节点上，使用2个CPU核心和4GB内存，而作业B则会被分配到第二个节点上，使用3个CPU核心和6GB内存。这样，每个节点都能充分利用资源，但可能会导致节点之间的资源不均衡。
另一方面，如果填充策略是"先来先服务"（First Fit），那么YARN会按照作业的提交顺序来分配容器。在这种情况下，作业A会先被分配到第一个节点上，使用2个CPU核心和4GB内存。然后，当作业B提交时，由于第一个节点上还有剩余的资源，作业B会被分配到第一个节点上，使用剩余的2个CPU核心和4GB内存。这样，虽然第二个节点有更多的资源可用，但仍然会先填充第一个节点。

所有的ods表都映射进dw层模型里面吗?

不一定

对于一个大型的数据仓库项目，是否需要将所有的ODS表都映射进DW层模型里面，还是有些表更适合深层计算，DWS或者ADS直接引用ODS的数据，需要根据具体情况来决定。在设计数据仓库时，通常会将原始数据（ODS层）进行清洗、整合和转换，生成适用于分析和报表的数据模型（DW层）。这样可以提高数据的可用性和分析效率。然而，并不是所有的ODS表都需要映射到DW层，有些表可能更适合在深层计算（DWS或者ADS）中直接引用ODS的数据。以下是一些考虑因素：

首先需要确定业务需求，哪些数据是需要用于分析和报表的，哪些数据是用于深层计算的。有些数据可能只用于特定的计算模型或者机器学习算法，不需要映射到DW层。

其次，如果ODS表的数据量非常大，映射到DW层可能会增加数据存储和计算的负担。在这种情况下，可以考虑在深层计算层（如DWS或ADS）直接引用ODS的数据，避免冗余存储和计算。

最后，如果ODS表的数据频繁变动，可能需要更实时的数据处理和计算。在这种情况下，可以将关键的数据直接引用ODS的数据，避免数据同步的延迟。

数仓分层完整版

在数据仓库架构中，可以按照不同的目的和功能将数据划分为多个层次，以满足不同层次的数据处理和分析需求。以下是一个常见的数据仓库分层结构，从最底层的ODS到最顶层的ADS/App和DIM。

ODS（Operational Data Store）层：ODS层是数据仓库的基础层，用于接收和存储来自源系统的原始数据。在ODS层中进行数据抽取、清洗和整合，确保数据的准确性和一致性。
DW（Data Warehouse）层：
- DWD（Data Warehouse and Data Marts）层：DWD层是数据仓库的核心层，用于存储经过清洗、整合和加工后的数据。在DWD层，数据被组织成主题领域相关的维度和事实表结构，以支持复杂的查询和分析操作。此外，DWD层也可以包括一些数据集市（Data Mart），用于满足特定业务部门的需求。DWD层是DW的细节层，存储经过清洗、整合和转换的详细数据。这里的数据通常是以事实表和维度表的形式存在，用于支持复杂的分析和报表需求。
- DWB（Data Warehouse Bus）层：DWB层是用于数据仓库中不同主题领域之间的数据集成和共享的层次。它提供了一个统一的数据模型和结构，以便不同的数据集市和业务部门可以共享和访问数据。DWB层可以通过共享维度表和事实表来实现数据的集成和一致性。DWB层是DW的基础层，对DWD层的数据进行汇总和聚合，生成适合较高层次分析和报表的数据模型。这里的数据通常是以聚合表和汇总表的形式存在，提供更高的查询性能和简化的数据视图。
- DWM（Data Warehouse Metadata）层：DWM层用于存储数据仓库的元数据信息。元数据包括数据表结构、数据字段定义、数据来源、数据质量信息等，它提供了数据仓库中数据的描述和管理信息。DWM层可以支持数据仓库的数据管理、数据质量控制、数据血缘追踪等功能。DWM层是DW的管理层，用于存储与数据仓库的管理和运营相关的数据，如元数据信息、ETL日志、数据质量监控结果等。
- DWS（Data Warehouse Service）：DWS是数据仓库的服务层，主要用于提供数据访问和数据服务。DWS层的数据通常是从DWD、DWB和DWM层中提取和汇总得到的，具有较高的灵活性和可用性。在DWS层，数据被组织成服务接口或数据集市，以支持各种数据应用和业务需求的快速响应。
- DIM（Dimensional Data）层：DIM层是用于存储维度数据的层次，主要包括维度表和维度视图。维度数据描述了业务中所涉及的各种属性和指标，如时间、地理位置、产品、客户等。DIM层的数据结构通常是星型或雪花型，以支持高效的多维数据分析。
ADS（Advanced Data Store）/App层：ADS层或App层是为特定的高级分析或特定应用而设计的层次。这些层次可以根据具体需求进行设计和构建。例如，可以有专门用于机器学习、深度学习或大数据分析的层次，也可以有用于特定应用的层次，如风控、营销等。

OLAP和OLTP的区别是什么?

OLAP（联机分析处理）
OLTP（联机事务处理）

数据处理目标：

OLAP：OLAP主要用于分析和决策支持，它处理大量的历史数据，并提供复杂的数据分析和报表功能。OLAP的目标是提供高度灵活的查询、多维分析和数据挖掘等功能，以支持业务分析和决策制定。

OLTP：OLTP主要用于处理业务交易，它处理实时的业务操作和事务处理。OLTP的目标是提供高度可靠的数据处理，包括数据的插入、更新、删除和查询等操作，以支持日常的业务运作。

数据模型：

OLAP：OLAP使用多维数据模型，通常称为数据立方体或星型/雪花型模型，以支持复杂的多维分析。它将数据组织为维度和度量，并提供分层的数据聚合、切片和切块等操作。

OLTP：OLTP使用关系型数据模型，通常使用表格和关系来组织数据。它主要关注实体之间的关系和数据的一致性，以支持事务处理和数据的持久化。

数据访问方式：

OLAP：OLAP支持复杂的查询和分析操作，通常需要对大量的历史数据进行跨维度和多维度的查询。它提供灵活的数据切片、钻取、旋转和数据透视等功能，以满足不同的分析需求。

OLTP：OLTP主要支持基本的数据插入、更新、删除和查询操作，通常是针对特定的业务实体或事务进行操作。它注重快速的事务处理和高并发的数据访问。

数据量和性能要求：

OLAP：OLAP通常处理大规模的历史数据，需要处理大量的数据存储和计算。它的查询和分析操作可能涉及到复杂的数据聚合和计算，需要支持高性能的数据处理和查询响应。

OLTP：OLTP通常处理实时的业务交易和操作，对数据的实时性和一致性要求较高。它的数据量相对较小，但需要快速的事务处理和高并发的数据访问。

Impala和Trino的异同

高版本的Presto叫trino

Impala和Presto都是用于快速查询和分析大规模数据的分布式SQL查询引擎，但它们在一些方面有一些异同之处.

架构：Impala是基于Apache Hadoop生态系统中的Hive和HDFS构建的，而Presto是基于分布式计算框架Apache Spark构建的。

查询性能：Impala在执行简单的交互式查询时具有较低的延迟，并且对于大型数据集的聚合查询也具有良好的性能。而Presto更适用于执行复杂查询和跨多个数据源进行查询的场景，具有更高的灵活性。

数据源支持：Impala主要支持HDFS和Apache Kudu两种数据源，而Presto支持更多种类的数据源，包括Hive、HDFS、关系型数据库、NoSQL数据库等。

社区支持：Impala由Cloudera公司进行维护和开发，而Presto由Presto Software Foundation进行维护和开发，两者都有活跃的社区支持。

个人认为:

p的优点更加明确:

灵活异构
性能优势
开源社区
开放集成

Hive中动态分区和写死分区插入的区别

动态分区并不是一条一条插入的

在Hive中使用HQL进行动态分区插入时，实际的底层运行方式是将数据一批一批地插入到对应的分区中。
当使用HQL进行动态分区插入时，可以通过INSERT INTO TABLE … PARTITION …语句指定要插入的分区。在执行插入操作时，Hive会将数据按照指定的分区列的值进行分组，然后将每个分组的数据一批一批地插入到对应的分区中。

减少了插入操作可以减少每次插入的元数据更新操作和磁盘写入操作，提高了插入的效率。
将数据分批插入可以更好地利用计算和存储资源，避免了一次性插入大量数据对系统资源的过度消耗。

Log日志中出现的很多阶段分别是什么意思

23/10/06 04:56:47 INFO vector.VectorMapOperator: DESERIALIZE_ERRORS:0, RECORDS_IN:1760583,
23/10/06 04:56:47 INFO vector.VectorReduceSinkOperator: RS[157]: Total records written - 1760583. abort - false
23/10/06 04:56:47 INFO vector.VectorReduceSinkOperator: RECORDS_OUT_INTERMEDIATE:1760583,
23/10/06 04:56:47 INFO spark.SparkRecordHandler: processed 1726 rows: used memory = 2259762640
23/10/06 04:56:48 INFO spark.SparkRecordHandler: processing 10 rows: used memory = 2334744288
23/10/06 04:56:48 INFO executor.Executor: Finished task 31.0 in stage 3.0 (TID 187). 4010 bytes result sent to driver
23/10/06 05:00:09 INFO spark.SparkRecordHandler: processing 100 rows: used memory = 2083342328
23/10/06 06:14:41 INFO spark.SparkRecordHandler: processing 1000 rows: used memory = 917731112
23/10/06 06:14:41 INFO vector.VectorReduceSinkOperator: RS[158]: records written - 1000001

这行信息表示在VectorMapOperator阶段，反序列化操作的错误数为0，处理的记录数为1760583。
23/10/06 04:56:47 INFO vector.VectorReduceSinkOperator: RS[157]: Total records written - 1760583. abort - false

这行信息来自VectorReduceSinkOperator，表示总共写入了1760583条记录，任务没有中断（abort标志为false）。
23/10/06 04:56:47 INFO vector.VectorReduceSinkOperator: RECORDS_OUT_INTERMEDIATE:1760583,

这行表示在VectorReduceSinkOperator阶段，输出的中间记录数为1760583。
23/10/06 04:56:47 INFO spark.SparkRecordHandler: processed 1726 rows: used memory = 2259762640

这行信息表示在SparkRecordHandler阶段，处理了1726行数据，使用的内存为2259762640字节。
23/10/06 04:56:48 INFO spark.SparkRecordHandler: processing 10 rows: used memory = 2334744288

这行表示在SparkRecordHandler阶段，正在处理10行数据，使用的内存为2334744288字节。
23/10/06 04:56:48 INFO executor.Executor: Finished task 31.0 in stage 3.0 (TID 187). 4010 bytes result sent to driver

这行表示在executor.Executor阶段，任务31.0（Task ID 187）已经完成，并且产生了4010字节的结果数据被发送到驱动程序。
23/10/06 05:00:09 INFO spark.SparkRecordHandler: processing 100 rows: used memory = 2083342328

这行表示在SparkRecordHandler阶段，正在处理100行数据，使用的内存为2083342328字节。
23/10/06 06:14:41 INFO spark.SparkRecordHandler: processing 1000 rows: used memory = 917731112

这行表示在SparkRecordHandler阶段，正在处理1000行数据，使用的内存为917731112字节。
23/10/06 06:14:41 INFO vector.VectorReduceSinkOperator: RS[158]: records written - 1000001

这行信息来自VectorReduceSinkOperator,表示写入了1000001条记录。

vector.VectorMapOperator: 这个类名可能是表示一个操作，用于对向量数据进行映射（map）处理。映射操作通常是将数据从一种形式转换为另一种形式，例如转换数据格式、提取特定属性或执行某些计算。
vector.VectorReduceSinkOperator: 这个类名可能表示一个操作，用于对向量数据进行归约（reduce）处理，并将结果输出到某个目标位置（sink）。归约操作通常是将一组数据项组合成一个单一的结果，例如计算总和、找出最大值或最小值等。
vector.VectorReduceSinkOperator: 与上述类名类似，这个类名可能也是表示对向量数据进行归约处理的类。
spark.SparkRecordHandler: 这个类名与Apache Spark相关，可能是用于处理Spark记录（records）的一种处理器（handler）。SparkRecordHandler可能用于处理Spark数据流或RDD（Resilient Distributed Datasets）中的记录，包括数据的输入、输出和转换等操作。
executor.Executor: 这个类名可能与Spark中的执行器（executor）相关。Executor是Spark应用程序运行在集群中的每个节点上的一个进程，负责执行任务和与集群管理器交互。Executor可能负责管理任务的执行、资源分配和与其他节点的通信。
spark.SparkRecordHandler 和 spark.SparkRecordHandler: 这两个类名与上述的SparkRecordHandler类似，可能也是用于处理Spark数据流或RDD中的记录的处理器。
vector.VectorReduceSinkOperator: 这个类名再次出现，可能与特定的数据处理或数据流操作有关。它可能用于对向量数据进行归约处理，并将结果输出到某个目标位置。

Spark SQL执行一个任务时，它通常会经历以下几个阶段

Source阶段（数据源）：这个阶段是数据进入Spark SQL的起点。它可以是一个数据文件、数据库、或者其他的Spark任务输出。这个阶段的主要工作是从数据源中读取数据，并将其转换为Spark的数据结构。
Data Profiling（数据探查）和Schema Inference（模式推断）阶段：在这个阶段，Spark SQL会检查数据并确定数据的模式。这对于后续的数据处理非常重要，因为它可以帮助Spark理解数据并正确地执行操作。
Logical Planning（逻辑规划）阶段：在这个阶段，Spark SQL根据用户定义的查询或操作生成一个逻辑计划。这个逻辑计划描述了如何处理数据以满足查询或操作的需求。
Physical Planning（物理规划）阶段：下一个阶段是物理规划，在这个阶段，Spark SQL将逻辑计划转化为可以由集群执行的物理计划。这可能涉及到将操作划分为更小的部分，以便更有效地利用集群资源。
Execution（执行）阶段：这个阶段开始执行物理计划。数据将在集群中分发并处理，结果将用于生成最终的输出。
Sink阶段（目标）：最后，当所有的数据都被处理后，数据会写入目标位置。这可能是一个文件系统、数据库或者其他的数据存储。这个阶段并不总是存在的，如果数据在中间阶段被消费，那么可能不会有一个明确的Sink阶段。

模型建设理论

数据仓库的建设通用的涉及到三个层次：DWD（数据仓库详细层）、DM（数据仓库汇总层）和DIM（数据集市层）。
在数据模型的设计中，常见的建模方法有范式建模和维度建模。范式建模要求数据达到第三范式的要求，但会限制数据仓库模型的灵活性和性能，因此不太常用。
维度建模分为雪花模型和星型模型。星型模型由一个事实表和多个维度表组成，而雪花模型则在星型模型的基础上增加了次级维度表。
下面是对维度建模的几个考虑方面：

查询性能：在OLTP-DW环节中，雪花模型由于要做多次表联接，性能比星型模型要低；而在DW-OLAP环节中，雪花模型更有利于度量值的聚合，性能比星型模型要高。

模型复杂度：星型模型相对来说较为简单。

层次概念：雪花模型更贴近OLTP系统的结构，符合业务逻辑，层次比较清晰。

存储空间：雪花模型不会产生冗余数据，而星型模型可能会产生数据冗余。

根据以上考虑，通常情况下数据仓库建模更适合使用星型模型。星型模型在底层数据表的构建中使用冗余来提高查询效率，并且对OLAP分析引擎的支持友好。
然而，在实际项目中，最关注的是查询性能问题，而磁盘空间一般不是问题。根据项目需求，应优先考虑使用星型模型。
在观察现有ODS数据的基础上，可以得出普通的星型模型无法满足项目需求的结论。这是因为业务数据的流转经过多个事实表，并且数据粒度不同，无法很好地完成整合。
因此，可以考虑使用星座模型。星座模型由多个事实表共享维度表组成，可以看作是星型模型的集合。这种模型形式更适合复杂的场景，能够满足业务需求中主题域的交互关系。
在这种情况下，可以将主题域分别构建为单独的星座模型，维度表可以由前五个主题域共用。这样，单独的星座模型可以聚合在一起，形成一个星座模型。