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的用法
