数据仓库系列6：数据仓库建模的主要步骤是什么?

最新推荐文章于 2024-09-21 11:32:19 发布

数据小羊

最新推荐文章于 2024-09-21 11:32:19 发布

阅读量791

点赞数 19

分类专栏： # 数仓建设文章标签：数据仓库大数据

本文链接：https://blog.csdn.net/u012955829/article/details/141526877

版权

数仓建设专栏收录该内容

37 篇文章 11 订阅

订阅专栏

你是否曾经面对海量的数据感到无所适从?你是否想知道那些运转良好的数据仓库背后究竟有什么秘密?
稿定设计-4.png
今天,让我们一起揭开数据仓库建模的神秘面纱,探索那些能够将杂乱无章的数据转化为有价值洞察的关键步骤!

引言：数据仓库建模的重要性

在大数据时代,数据已经成为企业最宝贵的资产之一。然而,仅仅拥有海量数据是远远不够的。如何有效地组织、存储和分析这些数据,以支持决策制定和业务洞察,才是真正的挑战所在。这就是数据仓库建模发挥作用的地方。

数据仓库建模是一个将原始数据转化为结构化、易于查询和分析的信息资产的过程。它就像是为你的数据建造一座宏伟的宫殿,每一个房间都有其特定的用途,每一条走廊都连接着相关的信息。一个精心设计的数据仓库模型可以:

提高数据质量和一致性
加速数据分析和报告生成
支持跨部门的数据共享和协作
为机器学习和高级分析提供坚实基础

接下来,让我们深入探讨数据仓库建模的七个关键步骤,看看如何将杂乱的数据转变为有价值的商业智能。

第一步：需求分析与规划

为什么需求分析如此重要?

想象一下,你正在建造一座房子。你会直接开始砌墙和安装屋顶吗?当然不会!你首先需要了解住户的需求,规划房间的布局,考虑未来的扩展可能性。数据仓库建模也是如此。

需求分析是整个数据仓库项目的基石。它帮助我们:

明确业务目标
识别关键利益相关者
定义具体的分析需求
设定项目范围和优先级

如何进行有效的需求分析?

以下是一个结构化的需求分析流程:

召开启动会议: 邀请所有相关部门的代表参加,介绍项目目标和预期成果。
进行利益相关者访谈: 与各部门负责人、数据分析师和高级管理层进行一对一或小组访谈。
收集现有报告和分析: 审查当前使用的报表和分析工具,了解现有的数据使用模式。
定义关键业务问题: 列出数据仓库需要解答的核心业务问题。例如:
- “我们的客户终生价值(LTV)是多少?”
- “哪些产品组合最能提高客户忠诚度?”
- “我们的营销活动ROI如何?”
创建需求文档: 编写详细的需求规格说明书,包括:
- 业务目标
- 关键性能指标(KPIs)
- 数据源
- 报表和分析需求
- 用户角色和访问权限
优先级排序: 使用如MoSCoW方法(Must have, Should have, Could have, Won’t have)对需求进行分类和排序。
获得利益相关者的签字确认: 确保所有关键参与者都同意最终的需求文档。

需求分析文档示例

下面是一个简化的需求分析文档片段:

# 电商平台数据仓库需求分析文档

## 1. 业务目标
- 提高客户留存率
- 优化产品组合
- 提升营销活动效果

## 2. 关键性能指标(KPIs)
- 客户终生价值(LTV)
- 客户获取成本(CAC)
- 复购率
- 平均订单价值(AOV)
- 营销活动ROI

## 3. 数据源
- 交易系统
- CRM系统
- 网站点击流数据
- 社交媒体数据

## 4. 报表和分析需求
- 客户细分分析
- 产品关联性分析
- 营销活动效果分析
- 客户流失预警

## 5. 用户角色和访问权限
- 高级管理层: 全部KPIs和汇总报表
- 营销团队: 客户分析和营销效果报表
- 产品团队: 产品性能和客户反馈分析
- 客户服务: 客户历史和互动记录

## 6. 优先级(MoSCoW)
Must have:
- 客户购买行为分析
- 基本的销售报表

Should have:
- 客户细分分析
- 产品关联性分析

Could have:
- 预测性分析(如客户流失预警)

Won't have(本期):
- 实时个性化推荐

通过仔细的需求分析,我们为数据仓库建模奠定了坚实的基础。这个过程不仅帮助我们明确了项目目标,还为后续的设计和实现提供了清晰的路线图。

第二步：数据源识别与评估

在完成需求分析后,下一个关键步骤是识别和评估数据源。这个阶段对于确保数据仓库的完整性和可靠性至关重要。

为什么数据源识别如此重要?

数据完整性: 确保我们拥有满足所有分析需求的必要数据。
数据质量评估: 了解源数据的质量,为后续的清洗和转换工作做准备。
整合规划: 识别不同系统间的数据关系,为数据集成铺平道路。
性能考量: 评估数据量和更新频率,为物理设计提供依据。

数据源识别与评估的步骤

创建数据源清单
列出所有可能的数据源,包括:
- 内部业务系统(如ERP、CRM、HR系统)
- 外部数据源(如市场研究数据、社交媒体数据)
- 日志文件和传感器数据
数据profiling
对每个数据源进行详细分析:
- 数据结构和格式
- 数据量和增长率
- 更新频率
- 主键和外键关系
数据质量评估
评估数据的:
- 完整性: 是否存在缺失值?
- 准确性: 数据是否反映真实情况?
- 一致性: 不同系统间的数据是否一致?
- 时效性: 数据更新是否及时?
数据访问方式确定
确定如何从每个源系统提取数据:
- 直接数据库连接
- API调用
- 文件传输(如CSV、XML)
数据字典创建
为每个数据源创建详细的数据字典,包括:
- 字段名称和描述
- 数据类型和长度
- 可能的值域
- 业务规则和约束
数据血缘关系梳理
绘制数据流图,展示数据如何在不同系统间流动和转换。

数据源评估工具

在进行数据源评估时,可以使用一些工具来提高效率:

SQL Server Data Profiling Task: SQL Server Integration Services (SSIS)中的一个组件,可以生成数据profile报告。
Python pandas: 可以用于快速数据分析和profiling。
Apache Atlas: 开源的元数据管理和数据治理工具,可以帮助追踪数据血缘。
Talend Open Studio: 开源的数据集成工具,包含数据profiling功能。

数据源评估示例

让我们以一个电商平台为例,展示如何进行数据源评估:

import pandas as pd
import matplotlib.pyplot as plt

# 假设我们已经从数据库中提取了订单数据
df = pd.read_csv('orders.csv')

# 基本信息
print(df.info())

# 缺失值检查
missing_values = df.isnull().sum()
print("缺失值统计:\n", missing_values)

# 数据分布可视化
plt.figure(figsize=(10,6))
df['order_total'].hist(bins=50)
plt.title('订单金额分布')
plt.xlabel('订单金额')
plt.ylabel('频率')
plt.show()

# 异常值检测
Q1 = df['order_total'].quantile(0.25)
Q3 = df['order_total'].quantile(0.75)
IQR = Q3 - Q1
lower_bound = Q1 - 1.5 * IQR
upper_bound = Q3 + 1.5 * IQR

outliers = df[(df['order_total'] < lower_bound) | (df['order_total'] > upper_bound)]
print("异常订单数量:", len(outliers))

# 时间序列分析
df['order_date'] = pd.to_datetime(df['order_date'])
daily_orders = df.groupby('order_date').size()

plt.figure(figsize=(12,6))
daily_orders.plot()
plt.title('每日订单数量趋势')
plt.xlabel('日期')
plt.ylabel('订单数量')
plt.show()

这个Python脚本展示了如何使用pandas和matplotlib对订单数据进行基本的profiling和可视化。通过这种分析,我们可以快速了解数据的质量、分布和趋势,为后续的数据建模工作提供重要参考。

数据源评估报告示例

基于上述分析,我们可以生成一个简单的数据源评估报告:

# 订单数据源评估报告

## 1. 基本信息
- 数据源: orders.csv
- 记录数: 100,000
- 字段数: 10

## 2. 数据质量
- 缺失值: 
  * customer_id: 0.5%
  * product_id: 0.1%
  * order_total: 0%
- 异常值:
  * 订单金额异常(低于$1或高于$1000): 1.2%

## 3. 数据分布
- 订单金额:
  * 平均值: $78.5
  * 中位数: $65.0
  * 最小值: $1.99
  * 最大值: $999.99

## 4. 时间特征
- 数据范围: 2023-01-01 至 2023-12-31
- 峰值期: 每年11月和12月订单量显著上升

## 5. 建议
1. 对customer_id的缺失值进行调查,可能与匿名购买有关
2. 建立订单金额的合理范围检查,标记潜在的异常交易
3. 考虑增加季节性因素在数据模型中的权重

通过这样详细的数据源评估,我们不仅对数据有了深入的了解,还为后续的数据清洗、转换和建模工作提供了明确的方向。例如,我们知道需要处理少量的缺失值和异常值,还需要考虑订单数据的季节性波动。这些洞察将直接影响我们在下一步维度建模中的决策。

第三步：维度建模

完成了数据源的识别和评估后,我们就来到了数据仓库建模的核心步骤:维度建模。维度建模是一种特殊的数据建模## 第三步：维度建模

完成了数据源的识别和评估后,我们就来到了数据仓库建模的核心步骤:维度建模。维度建模是一种特殊的数据建模技术,旨在支持高效的数据查询和分析。

什么是维度建模?

维度建模是由Ralph Kimball提出的一种数据仓库设计方法。它将数据组织成两种主要类型的表:事实表和维度表。

事实表: 包含业务过程的量化指标(如销售额、数量等)
维度表: 包含描述性属性,用于分析事实(如时间、产品、客户等)

这种模型通常被称为"星型模式"或"雪花模式",因为图形化表示时看起来像星星或雪花。

维度建模的步骤

确定业务过程
识别需要建模的核心业务过程,如销售、采购、库存等。
声明粒度
确定事实表中每一行代表的最小细节级别,如单个订单项、每日销售汇总等。
识别维度
列出描述每个事实的维度,如时间、产品、客户、地点等。
识别事实
确定需要测量的指标,如数量、金额、成本等。
创建事实表
设计包含外键(指向维度表)和度量值的事实表。
创建维度表
为每个维度设计详细的属性表。
选择持续时间
决定历史数据保留的时间跨度。
确定缓慢变化维度(SCD)策略
决定如何处理维度属性随时间变化的情况。

维度建模示例: 电商销售数据

让我们以电商平台的销售数据为例,展示如何进行维度建模:

业务过程: 销售订单
粒度: 单个订单项
维度:
- 时间维度
- 产品维度
- 客户维度
- 店铺维度
事实:
- 销售数量
- 销售金额
- 折扣金额
- 成本
事实表设计:

CREATE TABLE fact_sales (
    order_item_id INT PRIMARY KEY,
    order_id INT,
    product_key INT,
    customer_key INT,
    store_key INT,
    date_key INT,
    quantity INT,
    sales_amount DECIMAL(10,2),
    discount_amount DECIMAL(10,2),
    cost_amount DECIMAL(10,2),
    FOREIGN KEY (product_key) REFERENCES dim_product(product_key),
    FOREIGN KEY (customer_key) REFERENCES dim_customer(customer_key),
    FOREIGN KEY (store_key) REFERENCES dim_store(store_key),
    FOREIGN KEY (date_key) REFERENCES dim_date(date_key)
);

维度表设计示例 (以产品维度为例):

CREATE TABLE dim_product (
    product_key INT PRIMARY KEY,
    product_id VARCHAR(50),
    product_name VARCHAR(100),
    category VARCHAR(50),
    subcategory VARCHAR(50),
    brand VARCHAR(50),
    unit_price DECIMAL(10,2),
    effective_date DATE,
    expiration_date DATE
);

持续时间: 假设我们决定保留5年的历史数据。
SCD策略: 对于产品维度,我们可能选择使用SCD Type 2,以跟踪产品属性(如价格)的历史变化。

维度建模的优势

查询性能: 星型模式优化了复杂查询的性能。
易于理解: 业务用户可以直观地理解模型结构。
灵活性: 可以轻松添加新的维度或事实。
一致性: 提供了一致的命名和结构。

通过维度建模,我们为数据仓库创建了一个强大而灵活的结构,为后续的数据分析和报告奠定了基础。

第四步：物理设计

在完成逻辑层面的维度建模后,下一步是将这个概念模型转化为实际的数据库结构。这个过程就是物理设计,它关注如何在特定的数据库管理系统中最有效地实现我们的模型。

物理设计的主要考虑因素

选择合适的数据库平台
- 关系型数据库(如Oracle, SQL Server, PostgreSQL)
- 列式存储(如Vertica, Redshift)
- MPP系统(如Greenplum, Teradata)
表的物理结构设计
- 分区策略
- 索引设计
- 压缩方法
数据类型选择
- 选择合适的数据类型以优化存储和查询性能
聚合表和物化视图
- 预计算常用的聚合结果以提高查询性能
安全性设计
- 访问控制
- 数据加密

物理设计示例

让我们以之前的电商销售数据为例,展示一些物理设计的决策:

选择数据库平台:
假设我们选择了Amazon Redshift作为我们的数据仓库平台,因为它适合处理大规模的分析查询。

表的物理结构设计:

a. 分区策略:
对于fact_sales表,我们可以按日期进行分区,以提高查询效率。

CREATE TABLE fact_sales (
    -- 其他列定义...
)
PARTITION BY RANGE (date_key) (
    PARTITION p20230101 VALUES LESS THAN (20230101),
    PARTITION p20230201 VALUES LESS THAN (20230201),
    -- 更多分区...
);

b. 索引设计:
在Redshift中,我们使用排序键和分布键来优化性能。

CREATE TABLE fact_sales (
    -- 其他列定义...
)
DISTKEY (store_key)
SORTKEY (date_key);

这里我们选择store_key作为分布键,因为查询通常会按店铺进行筛选,而date_key作为排序键,因为时间范围查询很常见。

数据类型选择:

CREATE TABLE dim_product (
    product_key BIGINT PRIMARY KEY,
    product_id VARCHAR(50) NOT NULL,
    product_name VARCHAR(100) NOT NULL,
    category VARCHAR(50) NOT NULL,
    subcategory VARCHAR(50) NOT NULL,
    brand VARCHAR(50) NOT NULL,
    unit_price DECIMAL(10,2) NOT NULL,
    effective_date DATE NOT NULL,
    expiration_date DATE NOT NULL
) DISTSTYLE ALL;  -- 小型维度表可以复制到所有节点

聚合表设计:

假设我们经常需要查询每日每个店铺的销售总额,我们可以创建一个聚合表:

CREATE TABLE agg_daily_sales_by_store AS
SELECT 
    date_key,
    store_key,
    SUM(sales_amount) as total_sales,
    SUM(quantity) as total_quantity,
    COUNT(DISTINCT order_id) as order_count
FROM fact_sales
GROUP BY date_key, store_key;

安全性设计:

-- 创建角色
CREATE ROLE sales_analyst;

-- 授予权限
GRANT SELECT ON fact_sales TO sales_analyst;
GRANT SELECT ON dim_product TO sales_analyst;
GRANT SELECT ON dim_customer TO sales_analyst;
GRANT SELECT ON dim_store TO sales_analyst;
GRANT SELECT ON dim_date TO sales_analyst;

-- 对敏感列进行掩码
CREATE MASK customer_email_mask ON dim_customer (email) 
AS 
    CASE 
        WHEN CURRENT_USER = 'admin' THEN email 
        ELSE LEFT(email, 2) || '****' || RIGHT(email, 4) 
    END;

这些物理设计决策将显著影响数据仓库的性能和可用性。正确的物理设计可以大幅提升查询速度,减少资源消耗,并确保数据的安全性。

第五步：ETL流程设计与实现

ETL(Extract, Transform, Load)是数据仓库建设中至关重要的一环。它负责将来自不同源系统的数据提取出来,经过清洗和转换,最后加载到数据仓库中。一个设计良好的ETL流程能够确保数据仓库中的数据是准确、一致和及时的。

ETL流程的主要步骤

提取(Extract):
- 从源系统中提取数据
- 处理增量更新
转换(Transform):
- 数据清洗(处理缺失值、异常值等)
- 数据标准化和统一
- 数据集成(合并来自不同源的数据)
- 数据计算和聚合
加载(Load):
- 将转换后的数据加载到目标表
- 处理历史数据(如SCD)
- 更新聚合表和物化视图

ETL设计考虑因素

性能和可扩展性: ETL流程需要能够在规定时间内处理大量数据。
错误处理: 需要有机制来处理和报告ETL过程中的错误。
数据质量: 需要实施数据质量检查和监控。
可审计性: ETL流程应该是可追踪和可审计的。
调度和监控: 需要设置合适的调度策略并监控ETL作业的执行。

ETL实现示例

让我们以Python和SQL为例,展示一个简单的ETL流程:

import pandas as pd
import psycopg2
from sqlalchemy import create_engine

# 连接到源数据库和目标数据库
source_conn = psycopg2.connect("dbname=source_db user=user password=pass")
target_engine = create_engine('postgresql://user:pass@localhost:5432/dw_db')

# 提取数据
def extract():
    df = pd.read_sql_query("""
        SELECT o.order_id, o.order_date, c.customer_id, p.product_id, 
               oi.quantity, oi.price
        FROM orders o
        JOIN order_items oi ON o.order_id = oi.order_id
        JOIN customers c ON o.customer_id = c.customer_id
        JOIN products p ON oi.product_id = p.product_id
        WHERE o.order_date >= (SELECT MAX(date_key) FROM dw_db.fact_sales)
    """, source_conn)
    return df

# 转换数据
def transform(df):
    # 数据清洗
    df = df.dropna()  # 删除包含空值的行
    
    # 标准化日期格式
    df['order_date'] = pd.to_datetime(df['order_date']).dt.strftime('%Y%m%d')
    
    # 计算销售额
    df['sales_amount'] = df['quantity'] * df['price']
    
    # 查找维度键
    df['date_key'] = df['order_date']
    df['customer_key'] = df['customer_id'].map(get_customer_key)
    df['product_key'] = df['product_id'].map(get_product_key)
    
    return df

# 加载数据
def load(df):
    df.to_sql('fact_sales', target_engine, if_exists='append', index=False)

# 主ETL流程
def etl():
    try:
        df = extract()
        df = transform(df)
        load(df)
        print("ETL process completed successfully.")
    except Exception as e:
        print(f"ETL process failed: {str(e)}")

# 运行ETL
if __name__ == "__main__":
    etl()

这个简单的ETL脚本展示了如何从源系统提取数据,进行一些基本的转换,然后将数据加载到数据仓库中。在实际生产环境中,ETL流程通常会更加复杂,可能涉及多个数据源、复杂的转换逻辑和错误处理机制。

ETL最佳实践

增量加载: 尽可能使用增量加载而不是全量加载,以提高效率。
并行处理: 利用并行处理技术来加速ETL过程。
数据质量检查: 在ETL过程中实施数据质量检查,及时发现和处理问题。
日志记录: 详细记录ETL过程,便于问题排查和审计。
版本控制: 对ETL代码进行版本控制,便于管理和回滚。
测试: 建立完善的测试流程,包括单元测试和集成测试。
文档化: 详细记录ETL流程设计和实现细节,便于维护和交接。

通过精心设计和实现ETL流程,我们可以确保数据仓库中的数据始终保持高质量和最新状态,为后续的数据分析和决策支持提供可靠的基础。

第六步：前端报表与分析工具集成

数据仓库建模的最终目标是为业务用户提供有价值的洞察。因此,将数据仓库与前端报表和分析工具进行有效集成是至关重要的一步。

前端工具的选择

选择合适的前端工具需要考虑以下因素:

用户需求: 不同角色的用户可能需要不同类型的报表和分析功能。
数据复杂度: 工具应能处理数据仓库中的复杂查询和大量数据。
易用性: 工具应该对非技术用户友好。
可视化能力: 强大的数据可视化功能可以更好地展示洞察。
集成性: 工具应易于与现有数据仓库和其他系统集成。
安全性: 应支持细粒度的访问控制和数据安全功能。

常见的前端工具包括:

Tableau
Power BI
Looker
QlikView
Apache Superset

集成步骤

连接配置:
设置数据仓库和前端工具之间的连接。这通常涉及提供数据库连接字符串、身份验证信息等。
数据模型映射:
在前端工具中创建与数据仓库模型对应的数据模型或语义层。
创建核心报表和仪表板:
基于常见的业务需求,创建一套核心报表和仪表板。
设置安全性和权限:
配置用户访问权限,确保数据安全。
性能优化:
优化查询性能,可能需要在数据仓库中创建额外的聚合表或物化视图。
用户培训:
对业务用户进行培训,使其能够有效使用工具。

集成示例: 使用Tableau连接数据仓库

以下是使用Tableau连接到我们之前设计的数据仓库的步骤:

建立连接:
- 打开Tableau Desktop
- 选择"连接到服务器" > “更多” > “Amazon Redshift”
- 输入服务器信息、数据库名称、用户名和密码
创建数据模型:
- 在Tableau中,将fact_sales表拖到画布上
- 将相关的维度表(dim_product, dim_customer, dim_store, dim_date)连接到fact_sales表

创建计算字段:

// 计算利润
[Profit] = [Sales Amount] - [Cost Amount]

// 计算利润率
[Profit Margin] = [Profit] / [Sales Amount]

创建仪表板:
- 创建一个显示每日销售趋势的折线图
- 创建一个按产品类别显示销售额的条形图
- 创建一个显示top 10客户的表格
- 添加日期、产品类别和店铺的过滤器
设置权限:
- 在Tableau Server上创建用户组(如"销售分析师", “市场经理”)
- 为不同的仪表板和数据源设置适当的访问权限
发布到Tableau Server:
- 将创建好的仪表板发布到Tableau Server
- 设置自动刷新计划,确保数据及时更新
  
  通过这样的集成,业务用户可以方便地访问和分析数据仓库中的数据,而无需直接编写SQL查询。

第七步：性能优化与维护

数据仓库的建设不是一次性的工作,而是一个持续优化和维护的过程。随着数据量的增长和业务需求的变化,我们需要不断调整和优化数据仓库的性能。

性能优化策略

查询优化:
- 分析慢查询日志,找出性能瓶颈
- 优化SQL语句,如使用适当的索引、避免全表扫描等
- 考虑使用查询重写技术
索引优化:
- 根据查询模式创建合适的索引
- 定期重建和维护索引
- 删除不必要的索引以减少维护开销
分区策略调整:
- 根据数据访问模式调整分区策略
- 考虑使用分区裁剪技术提高查询效率
数据分布优化:
- 在MPP系统中,优化数据的分布策略以减少数据移动
物化视图和聚合表:
- 为常用的聚合查询创建物化视图
- 定期刷新物化视图和聚合表
资源管理:
- 实施工作负载管理,为不同类型的查询分配适当的资源
- 使用查询优先级和并发控制机制

维护任务

数据备份和恢复:
- 实施定期备份策略
- 测试恢复过程,确保数据可以在需要时快速恢复
数据清理:
- 定期清理历史数据
- 归档不再频繁访问的数据
统计信息更新:
- 定期更新数据库统计信息,以帮助查询优化器做出更好的决策
监控和告警:
- 设置性能监控工具
- 配置关键指标的告警阈值
安全审计:
- 定期审查访问权限
- 监控异常的数据访问模式
版本升级:
- 及时应用数据库和ETL工具的安全补丁
- 评估新版本的特性,考虑是否升级

性能优化示例: 优化慢查询

假设我们发现以下查询性能较差:

SELECT 
    d.year,
    d.month,
    p.category,
    SUM(f.sales_amount) as total_sales
FROM 
    fact_sales f
JOIN 
    dim_date d ON f.date_key = d.date_key
JOIN 
    dim_product p ON f.product_key = p.product_key
WHERE 
    d.year = 2023
GROUP BY 
    d.year, d.month, p.category
ORDER BY 
    d.year, d.month, total_sales DESC;

我们可以通过以下步骤优化这个查询:

创建合适的索引:

CREATE INDEX idx_fact_sales_date_product ON fact_sales(date_key, product_key);
CREATE INDEX idx_dim_product_category ON dim_product(category);

预聚合数据:

CREATE MATERIALIZED VIEW mv_monthly_sales_by_category AS
SELECT 
    d.year,
    d.month,
    p.category,
    SUM(f.sales_amount) as total_sales
FROM 
    fact_sales f
JOIN 
    dim_date d ON f.date_key = d.date_key
JOIN 
    dim_product p ON f.product_key = p.product_key
GROUP BY 
    d.year, d.month, p.category;

-- 创建索引以加速查询
CREATE INDEX idx_mv_monthly_sales ON mv_monthly_sales_by_category(year, month, total_sales);

修改原查询以使用物化视图:

SELECT 
    year,
    month,
    category,
    total_sales
FROM 
    mv_monthly_sales_by_category
WHERE 
    year = 2023
ORDER BY 
    year, month, total_sales DESC;