etl学习笔记-持续更新

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/weixin_38500014/article/details/79174379


关于数据的ETL
用来描述将数据从来源端经过抽取E(extract)、清洗,转换T(transform)、加载L(load)至目的端的过程。ETL一词较常用在数据仓库,但其对象并不限于数据仓库.

目标:数据优化,以最小代价将针对日常业务操作的数据转换成针对数据仓库而存储的决策支持型数据
原则:尽量利用数据中转区对运营数据进行预处理,保证数据的安全性,集成和加载的高效性,过程应该是主动‘拉取’,而不是从内部‘推送’,数据质量将保证正确性,一致性,完整性,有效性,可获取性
ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成,最后加载到数据仓库或数据集市中,成为联机分析处理、数据挖掘的基础。

目前,ETL工具的典型代表有:第三方工具提供商Informatic、Datastage、数据库厂商自带的OWB、微软DTS、Beeload、开源的Kettle……


开源的工具有eclipse的etl插件。cloveretl.



数据抽取:字段关联,全量抽取(月数据汇总,数据量大),基本上不会做增量抽取(交易上的,没天增量,数据不全),按照不同频率和周期的策略和具体的业务进行抽取,基础数据肯定是每天
数据清洗:数据替换,数据规范化,数据补缺,按照清洗规则进行清洗
数据转换:数据拆分,数据计算,关联查询,按照规则,自定义特征进行转换--数据类型转换,标准化,case when的转换
数据加载:增量加载l,全量加载,数据比对,加载至目标数据表集市或数据仓库,无时不刻的加载至集市表


先找表,取数据搞清楚
数据标准化:1/0  m/f  标准成 1/0  根据业务数据来规定
表结构标准化:字段标准化,create_date/create_time  标准化为create_time

   linux 连接数据库,运行存储过程
   
   
   流水汇总层
   导入gp--交易字段取出来--清洗--转换--加载L
   shell更新数据/业务,定时任务调用存储过程
   调度
   
   
   
   
   
   
   
   存储过程
   
  调用存储过程:call sp_name()--注意:存储过程名称后面必须加括号,哪怕该存储过程没有参数传递
   
  删除存储过程:drop procedure sp_name()
   
  不能在一个存储过程中删除另一个存储过程,只能调用另一个存储过程
  
  
  
 四舍五入
select round(123.456, 0) from dual;          回传 123
select round(123.456, 1) from dual;          回传 123.5
select round(-123.456, 2) from dual;         回传 -123.46
  
  
  
  
  
  
  
  trunc(sysdate,'yyyy') --返回当年第一天.


  trunc(sysdate,'mm') --返回当月第一天.


  trunc(sysdate,'d') --返回当前星期的第一天.
  
  
  
  年日均金额:比如说10月份的年日均=1到10月的的总金额除以1到10月份的天数
  季日均金额:比如说1月份的季日均=1月份的总额除以天数,
 比如说2月份的季日均=1月份+2月份的总额除以1月份+2月份总天数,
   比如说3月份的季日均=1月份+2月份+3月份的总额除以1月份+2月份+3月份总天数


  月日均金额:比如说10月份的月日均=10月的总金额除以10月份的天数
  
  
  保本型理财分短期,中期,长期
  非保本型理财不分
   
   
   
   
   
   
   
   
 ODS操作数据存储
 
 ODS(Operational Data Store) 是数据仓库体系结构中的一个可选部分,ODS具备数据仓库的部分特征和OLTP系统的部分特征,它是"面向主题的、集成的、当前或接近当前的、不断变化的"数据。
 1、在业务系统和数据仓库之间形成一个隔离层
 一般的数据仓库应用系统都具有非常复杂的数据来源,这些数据存放在不同的地理位置、不同的数据库、不同的应用之中,从这些业务系统对数据进行抽取并不是一件容易的事。因此,ODS用于存放从业务系统直接抽取出来的数据,这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致,因此在抽取过程中极大降低了数据转化的复杂性,而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题
 
 2、转移一部分业务系统细节查询的功能
 在数据仓库建立之前,大量的报表、分析是由业务系统直接支持的,在一些比较复杂的报表生成过程中,对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致,那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行,从而降低业务系统的查询压力。
 3、完成数据仓库中不能完成的一些功能
 一般来说,带有ODS的数据仓库体系结构中,DW层所存储的数据都是进行汇总过的数据,并不存储每笔交易产生的细节数据,但是在某些特殊的应用中,可能需要对交易细节数据进行查询,这时就需要把细节数据查询的功能转移到ODS来完成,而且ODS的数据模型按照面向主题的方式进行存储,可以方便地支持多维分析等查询功能。


 在一个没有ODS层的数据仓库应用系统体系结构中,数据仓库中存储的数据粒度是根据需要而确定的,但一般来说,最为细节的业务数据也是需要保留的,实际上也就相当于ODS,但与ODS所不同的是,这时的细节数据不是"当前、不断变化的"数据,而是"历史的,不再变化的"数据。
 

猜你喜欢

转载自blog.csdn.net/weixin_38500014/article/details/79174379