airflow从datahub获取数据到mysql数据库

使用airflow从datahub获取数据到DB,修改数据,打包csv档发送minio,task执行成功邮件通知复写等

import smtplib
import pendulum
from email.mime.text import MIMEText
from email.header import Header
from airflow import DAG
from airflow.utils.dates import days_ago
from datahub.operators.datahub_to_rdb import DatahubToRDBOperator
from datetime import datetime, timedelta
from airflow.operators.python import PythonOperator
from airflow.operators.dummy import DummyOperator
from airflow.providers.mysql.operators.mysql import MySqlOperator
import pandas as pd
import boto3
from airflow.hooks.mysql_hook import MySqlHook
import tempfile
from airflow.exceptions import AirflowException
import math


def  readdata():
    # 创建mysql引擎
    mysql_hook=MySqlHook(mysql_conn_id="数据库连接id")
    sqlalchemy_engine=mysql_hook.get_sqlalchemy_engine();
    try:
      df=pd.read_sql("SELECT *   FROM  employeeinfo  ",sqlalchemy_engine)
      print(df.head())
      print('--------------')
      print(df.info())
      #生成test.csv档,并设置索引为false
      df.to_csv(
<think> 嗯,用户这次想要了解BI数据分析的全流程,从需求调研到报表设计的完整步骤。之前用户提供的引用材料主要围绕ETL的难点和重要性,以及BI系统的基本架构。看来用户可能是一个数据分析项目的实施者或管理者,需要系统性的流程指导。 用户特别强调要包含“补充步骤”,说明ta可能已经看过基础流程,但需要更落地的细节。结合引用[1]提到“需求梳理、取数困难”和引用[4]指出ETL占项目1/3时间,应该重点强化这两个环节的实操风险点。 流程设计上需要分层说明:业务层(需求)、技术层(ETL/数仓)、应用层(报表)。引用[3]提到BI通过ETL连接各种数据库的特性,在数据采集环节要突出异构数据源处理;引用[2]强调数据仓库的核心地位,分层设计需细化到ods-dwd-dws-ads四级才够专业。 突然想到用户没提数据建模,但这是数仓建设的关键。考虑在“数据分层设计”环节补充维度建模的星型/雪花模型选择依据,引用[4]提到ETL设计影响项目成败,建模正是ETL的输入依据。 报表设计部分,用户引用[1]抱怨“把分析想法用软件实现难”,要强调工具选型建议(如Tableau轻量级、Power BI集成性好)和原型设计流程。最后质量控制容易被忽视,需单列章节说明测试方法。 </think>以下是BI数据分析从需求调研到报表设计的全流程详解及补充步骤,结合ETL、数据仓库分层等核心技术环节: --- ### **一、需求调研阶段** 1. **业务需求梳理** - 与业务部门深度访谈,明确分析目标(如销售分析、库存监控) - 定义核心指标(KPI):如销售额、转化率、库存周转率 - 输出文档:《业务需求说明书》+《指标字典》 *补充:需验证需求可行性,避免“伪需求”,优先级排序使用MoSCoW法则(Must/Should/Could/Won't)[^1]* 2. **数据源探查** - 识别数据来源:业务数据库MySQL/Oracle)、日志文件、第三方API - 评估数据质量:缺失值、一致性、时效性(如订单表与物流表的时间戳对齐) - 输出文档:《数据源映射表》+《数据质量评估报告》 --- ### **二、ETL开发阶段** #### ▶ **核心流程** ```mermaid graph LR A[Extract 数据抽取] --> B[Transform 清洗转换] B --> C[Load 加载到数仓] ``` 1. **抽取(Extract)** - 增量抽取:通过时间戳(如`last_updated > ${max_update_time}`) - 全量抽取:初始化或小规模维度表 - *补充:对敏感数据需脱敏(如手机号替换为`138****1234`)[^3]* 2. **转换(Transform)** - **数据清洗** - 处理空值:填充默认值或剔除 - 标准化:单位统一(如货币转换`USD→CNY`)、编码统一(如性别`男/女→M/F`) - **业务规则计算** - 例:毛利率公式 $$ \text{毛利率} = \frac{\text{销售收入} - \text{成本}}{\text{销售收入}} \times 100\% $$ - **维度退化**:将常用维度(如商品类别)冗余到事实表减少关联 3. **加载(Load)** - 加载策略: | 类型 | 适用场景 | |------------|-------------------------| | 全量覆盖 | 小维度表(<10万行) | | 增量追加 | 事实表(订单/日志) | | 拉链表 | 缓慢变化维度(SCD Type 2)| --- ### **三、数据仓库分层设计** #### ▶ **典型四层架构** ```sql -- ODS层(原始数据层) CREATE TABLE ods_sales_order ( order_id STRING, product_id STRING, raw_amount DECIMAL(10,2), -- 原始金额 create_time TIMESTAMP ) PARTITIONED BY (dt STRING); -- DWD层(明细数据层) CREATE TABLE dwd_fact_order ( order_id STRING, product_id STRING, cal_amount DECIMAL(10,2), -- 清洗后金额 dim_date_id INT -- 关联时间维度 ) PARTITIONED BY (dt STRING); -- DWS层(汇总数据层) CREATE TABLE dws_product_sales_daily ( product_id STRING, date_id INT, daily_sales DECIMAL(16,2), -- 当日销售额 PRIMARY KEY (product_id, date_id) ); -- ADS层(应用数据层) CREATE TABLE ads_region_sales_monthly ( region_id INT, month_id INT, total_sales DECIMAL(16,2) -- 区域月销售额 ); ``` #### ▶ **分层价值** | 层级 | 核心目标 | 数据粒度 | |------|---------------------------|----------------| | ODS | 原始数据备份 | 业务系统原貌 | | DWD | 数据标准化、维度建模 | 原子粒度 | | DWS | 预聚合提升查询性能 | 主题域汇总 | | ADS | 支撑报表/即席查询 | 业务指标 | *补充:DWD层需遵循Kimball维度建模,事实表与维度表解耦;DWS层聚合需考虑业务查询频次[^2][^4]* --- ### **四、报表设计阶段** 1. **数据模型关联** - 星型模型:事实表为核心,多维度表辐射 ```mermaid erDiagram FACT_ORDER ||--o{ DIM_PRODUCT : "product_id" FACT_ORDER ||--o{ DIM_DATE : "date_id" ``` 2. **可视化设计原则** - **指标分级**: - 核心指标大屏展示(如实时GMV) - 次要指标折叠菜单(如区域渗透率) - **交互设计**: - 下钻:从大区 → 省份 → 城市 - 联动:选择产品类别,自动过滤关联图表 3. **性能优化** - 物化视图:预计算高频复杂查询(如`CREATE MATERIALIZED VIEW mv_monthly_sales AS ...`) - 缓存机制:对静态报表结果缓存24小时 --- ### **五、补充关键步骤** 1. **数据血缘追踪** - 工具:Apache Atlas、DataHub - 追踪字段级血缘:报表指标 → DWS表 → DWD表 → ODS表 2. **自动化测试** - 数据质量规则: - 唯一性校验:`COUNT(order_id) = COUNT(DISTINCT order_id)` - 波动阈值:当日销售额环比变化 ±20%触发告警 3. **元数据管理** - 存储表结构、ETL任务依赖、指标业务含义 - 示例元数据表: | 字段名 | 业务含义 | 来源表 | 更新频率 | |--------------|----------------|--------------|----------| | daily_sales | 商品日销售额 | dws_product | 每日 | --- ### **六、全流程风险控制** - **需求变更**:建立变更评审委员会(CCB),评估影响范围 - **数据延迟**:ETL任务监控(如Airflow报警) - **指标歧义**:维护《指标口径文档》,示例: > “销售额”定义:已付款订单金额(剔除退款),含运费不含优惠券 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值