Hive:資料倉儲構建步驟
資料倉儲是面向主題的、整合的、不可更新的、隨時間的變化而不斷變化的,這些特點決定了資料倉儲的系統設計不能採用同開發傳統的OLTP資料庫一樣的設計方法。
資料倉儲系統的原始需求不明確,且不斷變化與增加,開發者最初不能確切瞭解到使用者的明確而詳細的需求,使用者所能提供的無非是需求的大的方向以及部分需求, 更不能較準確地預見到以後的需求。因此,採用原型法來進行資料倉儲的開發是比較合適的,因為原型法的思想是從構建系統的簡單的基本框架著手,不斷豐富與完 善整個系統。但是,資料倉儲的設計開發又不同於一般意義上的原型法,資料倉儲的設計是資料驅動的。這是因為資料倉儲是在現存資料庫系統基礎上進行開發,它 著眼於有效地抽取、綜合、整合和挖掘已有資料庫的資料資源,服務於企業高層領導管理決策分析的需要。但需要說明的是,資料倉儲系統開發是一個經過不斷循 環、反饋而使系統不斷增長與完善的過程,這也是原型法區別於系統生命週期法的主要特點。因此,在資料倉儲的開發的整個過程中,自始至終要求決策人員和開發 者的共同參與和密切協作,要求保持靈活的頭腦,不做或儘量少做無效工作或重複工作。
資料倉儲的設計大體上可以分為以下幾個步驟:
l 概念模型設計;
l 技術準備工作;
l 邏輯模型設計;
l 物理模型設計;
l 資料倉儲生成;
l 資料倉儲執行與維護。
下面我們六個主要設計步驟為主線,介紹在各個設計步驟中設計的基本內容。
第一節 概念模型設計
進行概念模型設計所要完成的工作是:
<1>界定系統邊界
<2>確定主要的主題域及其內容
概念模型設計的成果是,在原有的資料庫的基礎上建立了一個較為穩固的概念模型。因為資料倉儲是對原有資料庫系統中的資料進行整合和重組而形成的資料集合, 所以資料倉儲的概念模型設計,首先要對原有資料庫系統加以分析理解,看在原有的資料庫系統中“有什麼”、“怎樣組織的”和“如何分佈的”等,然後再來考慮 應當如何建立資料倉儲系統的概念模型。一方面,通過原有的資料庫的設計文件以及在資料字典中的資料庫關係模式,可以對企業現有的資料庫中的內容有一個完整 而清晰的認識;另一方面,資料倉儲的概念模型是面向企業全域性建立的,它為整合來自各個面向應用的資料庫的資料提供了統一的概念檢視。
概念模型的設計是在較高的抽象層次上的設計,因此建立概念模型時不用考慮具體技術條件的限制。
1. 界定系統的邊界
資料倉儲是面向決策分析的資料庫,我們無法在資料倉儲設計的最初就得到詳細而明確的需求,但是一些基本的方向性的需求還是擺在了設計人員的面前:
l 要做的決策型別有哪些?
l 決策者感興趣的是什麼問題?
l 這些問題需要什麼樣的資訊?
l 要得到這些資訊需要包含原有資料庫系統的哪些部分的資料?
這樣,我們可以劃定一個當前的大致的系統邊界,集中精力進行最需要的部分的開發。因而,從某種意義上講,界定系統邊界的工作也可以看作是資料倉儲系統設計的需求分析,因為它將決策者的資料分析的需求用系統邊界的定義形式反映出來。
2. 確定主要的主題域
在這一步中,要確定系統所包含的主題域,然後對每個主題域的內容進行較明確的描述,描述的內容包括:
l 主題域的公共碼鍵;
l 主題域之間的聯絡;
l 充分代表主題的屬性組。
第二節 技術準備工作
這一階段的工作包括:技術評估,技術環境準備。
這一階段的成果是:技術評估報告、軟硬體配置方案、系統(軟、硬體)總體設計方案。管理資料倉儲的技術要求與管理操作型環境中的資料與處理的技術要求區別 很大,兩者所考慮的方面也不同。我們之所以在一般情況下總是將分析型資料與操作型資料分離開來,將分析型資料單獨集中存放,也就是用資料倉儲來存放,技術 要求上的差異是一個重要原因。
1. 技術評估
進行技術評估,就是確定資料倉儲的各項效能指標。一般情況下,需要在這一步裡確定的效能指標包括:
l 管理大資料量資料的能力;
l 進行靈活資料存取的能力;
l 根據資料模型重組資料的能力;
l 透明的資料傳送和接收能力;
l 週期性成批裝載資料的能力;
l 可設定完成時間的作業管理能力。
2. 技術環境準備
一旦資料倉儲的體系化結構的模型大體建好後,下一步的工作就是確定我們應該怎樣來裝配這個體系化結構模型,主要是確定對軟硬體配置的要求;我們主要考慮相關的問題:
l 預期在資料倉儲上分析處理的資料量有多大?
l 如何減少或減輕競爭性存取程式的衝突?
l 資料倉儲的資料量有多大?
l 進出資料倉儲的資料通訊量有多大?等等。
根據這些考慮,我們就可以確定各項軟硬體的配備要求,並且在這一步工作結束時各項技術準備工作應已就緒,可以裝載資料了。這些配備有:
l 直接存取裝置(DASD);
l 網路;
l 管理直接存取裝置(DASD)的作業系統;
l 進出資料倉儲的介面(主要是資料查詢和分析工具);
管理資料倉儲的軟體,目前即選用資料庫管理系統及有關的選件,購買的DBMS產品不能滿足管理資料倉儲需要的,還應考慮自己或軟體整合商開發有關模組等等。
第三節 邏輯模型設計
在這一步裡進行的工作主要有:
l 分析主題域,確定當前要裝載的主題;
l 確定粒度層次劃分;
l 確定資料分割策略;
l 關係模式定義;
l 記錄系統定義
邏輯模型設計的成果是,對每個當前要裝載的主題的邏輯實現進行定義,並將相關內容記錄在資料倉儲的後設資料中,包括:
l 適當的粒度劃分;
l 合理的資料分割策略;
l 適當的表劃分;
l 定義合適的資料來源等。
1. 分析主題域
在概念模型設計中,我們確定了幾個基本的主題域,但是,資料倉儲的設計方法是一個逐步求精的過程,在進行設計時,一般是一次一個主題或一次若干個主題地逐 步完成的。所以,我們必須對概念模型設計步驟中確定的幾個基本主題域進行分析,並選擇首先要實施的主題域。選擇第一個主題域所要考慮的是它要足夠大,以便 使得該主題域能建設成為一個可應用的系統;它還要足夠小,以便於開發和較快地實施。如果所選擇的主題域很大並且很複雜,我們甚至可以針對它的一個有意義的 子集來進行開發。在每一次的反饋過程中,都要進行主題域的分析。
2. 粒度層次劃分
資料倉儲邏輯設計中要解決的一個重要問題是決定資料倉儲的粒度劃分層次,粒度層次劃分適當與否直接影響到資料倉儲中的資料量和所適合的查詢型別。確定資料 倉庫的粒度劃分,可以使用在粒度劃分一節中介紹的方法,通過估算資料行數和所需的DASD數,來確定是採用單一粒度還是多重粒度,以及粒度劃分的層次。
3. 確定資料分割策略
在這一步裡,要選擇適當的資料分割的標準,一般要考慮以下幾方面因素:資料量(而非記錄行數)、資料分析處理的實際情況、簡單易行以及粒度劃分策略等。數 據量的大小是決定是否進行資料分割和如何分割的主要因素;資料分析處理的要求是選擇資料分割標準的一個主要依據,因為資料分割是跟資料分析處理的物件緊密 聯絡的;我們還要考慮到所選擇的資料分割標準應是自然的、易於實施的:同時也要考慮資料分割的標準與粒度劃分層次是適應的。
4. 關係模式定義
資料倉儲的每個主題都是由多個表來實現的,這些表之間依靠主題的公共碼鍵聯絡在一起,形成一個完整的主題。在概念模型設計時,我們就確定了資料倉儲的基本 主題,並對每個主題的公共碼鍵、基本內容等做了描述在這一步裡,我們將要對選定的當前實施的主題進行模式劃分,形成多個表,並確定各個表的關係模式。
第四節 物理模型設計
這一步所做的工作是確定資料的儲存結構,確定索引策略,確定資料存放位置,確定儲存分配。
確定資料倉儲實現的物理模型,要求設計人員必須做到以下幾方面:
l 要全面瞭解所選用的資料庫管理系統,特別是儲存結構和存取方法。
l 瞭解資料環境、資料的使用頻度、使用方式、資料規模以及響應時間要求等,這些是對時間和空間效率進行平衡和優化的重要依據。
l 瞭解外部儲存裝置的特性,如分塊原則,塊大小的規定,裝置的I/O特性等。
1. 確定資料的儲存結構
一個資料庫管理系統往往都提供多種儲存結構供設計人員選用,不同的儲存結構有不同的實現方式,各有各的適用範圍和優缺點,設計人員在選擇合適的儲存結構時應該權衡三個方面的主要因素:存取時間、儲存空間利用率和維護代價。
2. 確定索引策略
資料倉儲的資料量很大,因而需要對資料的存取路徑進行仔細的設計和選擇。由於資料倉儲的資料都是不常更新的,因而可以設計多種多樣的索引結構來提高資料存取效率。
在資料倉儲中,設計人員可以考慮對各個資料儲存建立專用的、複雜的索引,以獲得最高的存取效率,因為在資料倉儲中的資料是不常更新的,也就是說每個資料儲存是穩定的,因而雖然建立專用的、複雜的索引有一定的代價,但一旦建立就幾乎不需維護索引的代價。
3. 確定資料存放位置
我們說過,同一個主題的資料並不要求存放在相同的介質上。在物理設計時,我們常常要按資料的重要程度、使用頻率以及對響應時間的要求進行分類,並將不同類 的資料分別儲存在不同的儲存裝置中。重要程度高、經常存取並對響應時間要求高的資料就存放在高速儲存裝置上,如硬碟;存取頻率低或對存取響應時間要求低的 資料則可以放在低速儲存裝置上,如磁碟或磁帶。
資料存放位置的確定還要考慮到其它一些方法,如:決定是否進行合併表;是否對一些經常性的應用建立資料序列;對常用的、不常修改的表或屬性是否冗餘儲存。如果採用了這些技術,就要記入後設資料。
4. 確定儲存分配
許多資料庫管理系統提供了一些儲存分配的引數供設計者進行物理優化處理,如:塊的尺寸、緩衝區的大小和個數等等,它們都要在物理設計時確定。這同建立資料庫系統時的考慮是一樣的。
第五節 資料倉儲的生成
在這一步裡所要做的工作是介面程式設計,資料裝入。
這一步工作的成果是,資料已經裝入到資料倉儲中,可以在其上建立資料倉儲的應用,即DSS應用。
1. 設計介面
將操作型環境下的資料裝載進入資料倉儲環境,需要在兩個不同環境的記錄系統之間建立一個介面。乍一看,建立和設計這個介面,似乎只要編制一個抽取程式就可 以了,事實上,在這一階段的工作中,的確對資料進行了抽取,但抽取並不是全部的工作,這一介面還應具有以下的功能:
l 從面向應用和操作的環境生成完整的資料;
l 資料的基於時間的轉換;
l 資料的凝聚;
l 對現有記錄系統的有效掃描,以便以後進行追加。
當然,考慮這些因素的同時,還要考慮到物理設計的一些因素和技術條件限制,根據這些內容,嚴格地制定規格說明,然後根據規格說明,進行介面程式設計。從操作型 環境到資料倉儲環境的資料介面程式設計的過程和一般的程式設計過程並無區別,它也包括偽碼開發、編碼、編譯、檢錯、測試等步驟。
在介面程式設計中,要注意:
l 保持高效性,這也是一般的程式設計所要求的;
l 要儲存完整的文件記錄;
l 要靈活,易於改動;
l 要能完整、準確地完成從操作型環境到資料倉儲環境的資料抽取、轉換與整合。
2. 資料裝入
在這一步裡所進行的就是執行介面程式,將資料裝入到資料倉儲中。主要的工作是:
l 確定資料裝入的次序;
l 清除無效或錯誤資料;
l 資料“老化” ;
l 資料粒度管理;
l 資料重新整理等。
最初只使用一部分資料來生成第一個主題域,使得設計人員能夠輕易且迅速地對已做工作進行調整,而且能夠儘早地提交到下一步驟,即資料倉儲的使用和維護。這 樣既可以在經濟上最快地得到回報,又能夠通過終端使用者的使用、儘早發現一些問題並提出新的需求,然後反饋給設計人員,設計人員繼續對系統改進、擴充套件。
第六節 資料倉儲的使用和維護
在這一步中所要做的工作有建立DSS應用,即使用資料倉儲理解需求,調整和完善系統,維護資料倉儲。
建立企業的體系化環境,不僅包括建立起操作型和分析型的資料環境,還應包括在這一資料環境中建立起企業的各種應用。資料倉儲裝入資料之後,下一步工作是: 一方面,使用資料倉儲中的資料服務於決策分析的目的,也就是在資料倉儲中建立起DSS應用;另一方面,根據使用者使用情況和反饋來的新的需求,開發人員進一 步完善系統,並管理資料倉儲的一些日常活動,如重新整理資料倉儲的當前詳細資料、將過時的資料轉化成歷史資料、清除不再使用的資料、調整粒度級別等。我們把這 一步驟稱為資料倉儲的使用與維護。
1. 建立DSS應用
使用資料倉儲,即開發DSS應用,與在操作型環境中的應用開發有著本質區別,開發DSS應用不同於聯機事務處理應用開發的顯著特點在於:
l DSS應用開發是從資料出發的;
l DSS應用的需求不能在開發初期明確瞭解;
l DSS應用開發是一個不斷迴圈的過程,是啟發式的開發。
DSS應用主要可分為兩類:例行分析處理和啟發式分析處理。例行分析處理是指那些重複進行的分析處理,它通常是屬於部門級的應用,如部門統計分析,報表分 析等等;而個人級的分析應用經常是隨機性很大的,企業經營者受到某種資訊啟發而進行的一些即席的分析處理,所以我們稱之為啟發式的分析處理。
DSS應用開發的大致步驟如下:
步驟l——確定所需的資料。為滿足DSS應用的要求,我們必須從資料倉儲中確定一個可能用到的資料範圍。這是一個試探的過程。
步驟2——程式設計抽取資料。根據上面得到的資料範圍,編寫一個抽取程式來獲得這些資料。為適應分析需求多變的特點,要求所編寫的抽取程式應該通用,易於修改。
步驟3——合併資料。如果有多個資料抽取源,要將抽取來的資料進行合併、提煉,使資料符合分析處理的要求。
步驟4——分析資料。在上步準備好的資料基礎上進行分析處理,並看所得的結果是否滿足了原始的要求,如果不能滿足,則返回步驟1,開始新的一次迴圈,否則就準備最終分析結果報告。
步驟5——回答問題。生成最終分析結果報告。—般情況下,最終的分析結果報告是在許多次的迴圈後得到的,因為一次分析處理很少是在一次迴圈後就完成的。
步驟6——例行化、一次分析處理的最後、我們要決定是否將在上面已經建立的分析處理例行化。如果建立的分析處理是重複進行的部門級的DSS應用,那麼最好 是將它例行化,這樣在進行下一次同樣的分析處理時,不必再重複上述六步的迴圈過程。而且,不斷地積累這種例行處理,形成一個集合,我們就可以通過組合這些 已有的處理來生成新的一個較大的複雜處理,或完成一個複雜處理的一部分。
2. 理解需求,改善和完善系統,維護資料倉儲
資料倉儲的開發是逐步完善的原型法的開發方法,它要求:要儘快地讓系統執行起來,儘早產生效益;要在系統執行或使用中,不斷地理解需求,改善系統;不斷地考慮新的需求,完善系統。
維護資料倉儲的工作主要是管理日常資料裝入的工作,包括重新整理資料倉儲的當前詳細資料,將過時的資料轉化成歷史資料.清除不再使用的資料,管理後設資料,等等;另外,如何利用介面定期從操作型環境向資料倉儲追加資料,確定資料倉儲的資料重新整理頻率,等等。
相關文章
- 如何構建資料倉儲模型?模型
- Hive -------- 使用mysql儲存hive後設資料,Mysql的安裝以及配置步驟HiveMySql
- 構建實時資料倉儲首選,雲原生資料倉儲AnalyticDB for MySQL技術解密MySql解密
- 使用Power BI構建資料倉儲與BI方案
- 黑猴子的家:Hive 資料倉儲位置配置Hive
- TDS 四大能力域各顯神通,構建資料湖、資料倉儲一步到位
- 《Greenplum構建實時資料倉儲實踐》簡介
- 資料量不大的資料倉儲方案有必要用 hive 嗎?Hive
- 資料倉儲元件:Hive環境搭建和基礎用法元件Hive
- HashData完成1500萬美元融資 加速構建雲原生資料倉儲
- 資料湖+資料倉儲 = 資料湖庫架構架構
- 基於OneData的資料倉儲建設
- 將資料匯入kudu表(建立臨時hive表,從hive匯入kudu)步驟Hive
- 基於Hive進行數倉建設的資源後設資料資訊統計:Hive篇Hive
- 資料倉儲建模工具之一——Hive學習第四天Hive
- 企業為什麼要建資料倉儲?
- 資料倉儲架構分層設計架構
- 資料生態第四彈 | OpenMLDB Hive Connector,架構起資料倉儲到特徵工程的生態橋樑Hive架構特徵工程
- 大資料4.1 - Flume整合案例+Hive資料倉大資料Hive
- 資料倉儲建模工具之一——Hive學習第七天Hive
- 資料倉儲建模工具之一——Hive學習第五天Hive
- 中小銀行資料倉儲建設 | 最佳實踐
- 最最最全資料倉儲建設指南,速速收藏!!
- 掌握Hive資料儲存模型Hive模型
- 資料庫倉庫系列:(一)什麼是資料倉儲,為什麼要資料倉儲資料庫
- 資料倉儲(5)數倉Kimball與Inmon架構的對比架構
- github中建立倉庫步驟Github
- 雲端資料倉儲的模式選型與建設模式
- 滴滴資料倉儲指標體系建設實踐指標
- 資料倉儲 - ER模型模型
- [數倉]資料倉儲設計方案
- 加快構建資料倉儲 甘肅銀行數字化轉型提速推進
- 分層架構在資料倉儲的應用架構
- 資料湖 VS 資料倉儲之爭?阿里提出大資料架構新概念:湖倉一體阿里大資料架構
- 為什麼要建資料倉儲,而不是直連資料來源?
- 構建良好雲平臺的7個步驟
- 資料倉儲應該用什麼方案——資料倉儲實施方案概述
- 什麼是資料倉儲