ETL
Extract 通过接口提取源数据，例如JODBC、专用数据库接口和平面文件提取器，并参照元数据来决定数据的提取及其提取方式。
Transform 开发者将提取的数据，按照业务需要转换为目标数据结构，并实现汇总。
Load 加载经转换和汇总的数据到目标数据仓库中，可实现SQL或批量加载。
实现ETL，首先要实现ETL转换的过程。体现为以下几个方面：
1、空值处理：可捕获字段空值，进行加载或替换为其他含义数据，并可根据字段空值实现分流加载到不同目标库。
2、规范化数据格式：可实现字段格式约束定义，对于数据源中时间、数值、字符等数据，可自定义加载格式。
3、拆分数据：依据业务需求对字段可进行分解。例，主叫号 861082585313-8148，可进行区域码和电话号码分解。
4、验证数据正确性：可利用Lookup及拆分功能进行数据验证。例如，主叫号861082585313-8148，进行区域码和电话号码分解后，可利用Lookup返回主叫网关或交换机记载的主叫地区，进行数据验证。
5、数据替换：对于因业务因素，可实现无效数据、缺失数据的替换。
6、Lookup：查获丢失数据 Lookup实现子查询，并返回用其他手段获取的缺失字段，保证字段完整性。
7、建立ETL过程的主外键约束：对无依赖性的非法数据，可替换或导出到错误数据文件中，保证主键唯一记录的加载。
元数据
元数据的典型表现为对象的描述，即对数据库、表、列、列属性（类型、格式、约束等）以及主键/外部键关联等等的描述。特别是现行应用的异构性与分布性越来越普遍的情况下，统一的元数据就愈发重要了。“信息孤岛”曾经是很多企业对其应用现状的一种抱怨和概括，而合理的元数据则会有效地描绘出信息的关联性。
而元数据对于ETL的集中表现为：定义数据源的位置及数据源的属性、确定从源数据到目标数据的对应规则、确定相关的业务逻辑、在数据实际加载前的其他必要的准备工作，等等，它一般贯穿整个数据仓库项目，而ETL的所有过程必须最大化地参照元数据，这样才能快速实现ETL。
报表开发流程
-
根据产品需求说明书开发详细设计口径
-
根据技术口径创建临时表
-
编写存储过程
-
对存储过程进行单元测试并编写相关的测试文档
-
在bishow模式下的数据库建表
-
申请建表->编写建表文档
-
编写报表规范的全量文档
-
编写应用清单
-
编写vb程序
-
报表的菜单配置
-
上传整理好的菜单配置sql到cvs上
-
执行vb程序将会发现ftp上会有生成的excell文档，查看是否成功
-
对上传到cvs上的存储过程和vb进行自动编译
-
编写上线申请文档，提交给测试人员测试
数据仓库特征
数据仓库的特征 （1）数据仓库是面向主题的：传统数据库应用按照业务处理流程来组织数据，目的在于提高处理的速度。主题是一个在较高层次将数据进行归类的标准，满足该领域分析决策的需要。 （2）数据仓库是集成性的：数据仓库中的数据来自于多个应用系统，不仅要统一原始数据中的所有矛盾，如同名异义，异名同义等，而且要将这些数据统一到数据仓库的数据模式上来。 （3）数据仓库是随时间而变化的：数据仓库随着时间变化要不断增加新的内容。由于数据仓库常常用作趋势预测分析，所以需要保留足够长时间的历史数据，一般为5~10年。 （4）数据仓库是稳定的：数据仓库的这种稳定性指的是数据仓库中的数据主要供企业决策分析之用，决策人员所涉及的数据操作主要是数据查询，一般情况下并不进行数据修改。
数据仓库与数据库比较
传统的操作性数据库主要对于dba和数据库专家用于日常操作的数据量比较小的针对当前应用的数据,他们可以对这些比较细节性的数据进行增删该查,所以这些数据是不稳定的,在不断的变化中,响应时间也是比较短暂的,其中这些数据是基于ER模型的.
分析型数据仓库主要对于管理人员和分析专家用于对管理需求和决策分析的数据量比较大的属于历史性的或者派生性的面向主题的具有一定集成性的 数据,他们可以对这些综合的经过提炼的数据进行查询,所以这些数据是相对稳定的,用户也基本不会对其数据进行修改,响应时间一般在几分钟以上,其中这些数据是基于星星模型和雪花模型的.
数据仓库的基本结构
将数据源的内部数据或者外部数据进行ETL处理加载到数据仓库中,然后分析专家可以通过相应的应用工具比如OLAP( 联机分析处理（OLAP）系统是数据仓库系统最主要的应用，专门设计用于支持复杂的分析操作, 可以根据分析人员的要求快速、灵活地进行大数据量的复杂查询处理，并且以一种直观而易懂的形式将查询结果提供给决策人员)对数据仓库中的数据进行挖掘并将之通过OLAP进行可视化展示给相关的分析人员.
经分系统总体架构
sql知识
RANK() 和ROW_NUMBER()区别：RANK允许同级排名且排名不连续，ROW_NUMBER不能有同级。
避免使用in操作
sql写法注意事项
1、分区字段不可以加函数，函数操作导致无法使用分区条件，引起全表扫描，如FT_MID_SUBTOTAL_ITEM表，以sum_date字段分区，查询201001月份数据，错误写法：substr(sum_date,1,6)=’201001’，无法使用分区条件，正确写法应该是sum_date>=20010101 and sum_date<=20100131。
SELECT TX_DATE,SID,MSISDN,ACTIVITYTYPE FROM TB_SER_FETIONACTIVEUSER_DETAIL T1 WHERE TO_CHAR(TX_DATE,'YYYYMMDD')<='20100131' AND TO_CHAR(TX_DATE,'YYYYMMDD')>='20100101'
2、分区字段类型必须与比较的值类型一致，不一致的类型比较，导致分区条件无法使用。如TB_CSV_ACCEPT_FLOW_OPERATOR表，分区字段accept_month类型是char,正确的写法是accept_month=’201001’。错误写法accept_month=201001。
3、不必要的函数操作，在对字段做比较时，不建议对字段做函数操作。如：change_expire_date字段是date型，在比较时如果写成to_char(change_expire_date,’yyyymmdd’)=’20100101’则比change_expire_date=to_date(‘20100101’,’yyyymmdd’)来的低效，耗用更多的CPU资源。
4、索引的使用，索引的字段比较，比较双方的类型必须一致，否则无法使用索引，tb_acc_account表owner字段建有索引，owner是varchar2类型，正确的写法：owner=’ 595305002876112’，错误的写法：owner=595305002876112
select * from tb_acc_account where tx_month=201006 and owner=595305002876112
5、索引的过度使用，数据集市数据库对单个会话的IO没有做限制，不建议直接移值boss的写法，通过循环或游标的方式以索引来大量访问某张表。比如：希望查询几万个user_id某天的话单:
BOSS可能需要通过循环来查询：
For v in (select user_id from temp_user_id) loop
Select * from tb_seu_call_201001 where user_id=v;
End loop;
数据集市的写法：直接两表关联
Select a.*from tb_seu_call_201001 a,temp_user_id b where a.user_id=b.user_id
6、数据删除，删除全表数据请使用truncate table xxx，删除某个分区数据请使用alter table xxx truncate partition p1;
Exadata 最重要的新特性是什么？
参考答案：Smart Scan
它的作用就是把 SQL放在每个 Cell 存储节点上运行，然后每个 Cell 只返回符合条件的数据给数据库。
极大的降低了数据库服务器的负载和网络流量，并充分利用了 Cell 的计算资源和 IO 资源。
Exadata数据库，通常情况下，是否需要建立索引？为什么？
参考答案：
a)适合使用索引的场景很少，一般来说，单次访问一张表低于4%的数据量的时候，使用索引扫描的效益才会体现出来，这种情况在经分应用不多；
b)在经分应用中，各种不同的应用，对各个表所需要的筛选集各有要求，并没有集中到一些特有的字段，特定的索引满足不了大部份的应用需求；
c)每个索引占用了一张表大致20%至30%左右的磁盘空间，这造 成了较大的空间浪费；
d)EXADATA的SMART SCANS 和 存储索引特性本身已缩短了小数据量的访问时间，索引 的引入意义已经不大,不建议使用索引
oracle的trunc的用法
