Như thể hiện tại sơ đồ, dữ liệu nguồn sẽ đi qua 3 lớp cụ thể là source systems tới staging/ODS, staging/ODS tới data warehouse và data warehouse tới data mart.
3.1.1. Quá trình tải dữ liệu từ Source system tới Staging and ODS
Hệ thống nguồn sẽ bao gồm dữ liệu từ các hệ thống khác nhau như Bank Admin, INCAS, ISAPP, GENTRONICS. Dữ liệu trích xuất từ hệ thống nguồn sẽ được tải vào vùng lưu trữ tạm thời gọi là Staging area. Dữ liệu tại đây được mapping trực tiếp 1-1 nghĩa là các trường dữ liệu sẽ được tải trực tiếp vào các bảng trong staging. Nên Staging area được coi như một backup store của dữ liệu hệ thống nguồn. Do trong q trình ETL hồn tồn có thể xảy ra lỗi khi tải dữ liệu từ khu vực xử lý sang khu vực trình bày và cần dọn dẹp lại kho và bắt đầu lại quá trình tải dữ liệu từ nguồn. Chính vì vậy cần khu vực lưu trữ tạm thời là Staging area để có thể tái sử dụng lại dữ liệu từ hệ thống nguồn mà khơng lo có sự thay đổi nào trên dữ liệu.
R1 - INCAS
R2 - PROFILE
StagingArea Data Loading and Data Migration Process
Staging DB
Hinh 3.2. Minh họa quá trình load dữ liệu vào Staging area
Dữ liệu sau khi được tải vào vùng Staging area sẽ được tải vào khu vực ODS. ODS-Kho dữ liệu hoạt động là nơi tích hợp, lưu trữ dữ liệu hoạt động từ các hệ thống nguồn khác nhau phục vụ cho nhu cầu báo cáo, ra quyết định của doanh nghiệp. Trong ODS, kho dữ liệu được làm mới theo thời gian thực. Do đó, nó được ưa thích rộng rãi cho các hoạt động thường ngày như lưu trữ hồ sơ của Nhân viên. Thời gian lưu trữ dữ liệu cho các bảng STG / ODS như sau:
- STG-tables - 5 ngày
- ODS - 1 ngày
3.1.2. Quá trình tải dữ liệu từ ODS tớiDWH
Dữ liệu từ ODS sau đó được xử lý để tải lên lớp DWH. Quá trình tải dữ liệu lên DWH là liên tục thêm bản ghi mới và tổng hợp dữ liệu theo lịch sử bản ghi cũ. Khác với ODS là liên tục cập nhật dữ liệu theo thời gian thực. Vì vậy, ODS được thiết kế để truy vấn dữ liệu trên tập dữ liệu nhỏ, trong khi kho dữ liệu DWH thực hiện các truy vấn phức tạp trên tập dữ liệu lớn
Mục tiêu của lớp data mart là để hỗ trợ yêu cầu báo cáo cho quyết định kinh doanh. Vì vậy quá trình nạp dữ liệu của Data mart bao gồm việc chuyển đổi dữ liệu sang mơ hình hình sao hoặc bơng tuyết để thuận tiện trong việc truy vấn và phân tích dữ liệu
Các quá trình sau sẽ được đưa vào quá trình tải dữ liệu của Data Mart: 1. Tạo surrogate key trong bảng chiều
2. Bảo toàn dữ liệu lịch sử cho dữ liệu
3. Xác định dữ liệu phân cấp để hỗ trợ xem chi tiết, tổng hợp và xem chi tiết thông qua các chức năng báo cáo
4. Tải dữ liệu Fact dưới dạng cấu trúc giao dịch khơng chuẩn hóa với tham chiếu dữ liệu chiều thông qua surrogate key để tạo mơ hình sao / bơng tuyết 5. Tải dữ liệu Tóm tắt tổng hợp từ dữ liệu thực tế có mức độ chi tiết thấp hơn
để hỗ trợ báo cáo cấp cao và truy cập dữ liệu nhanh hơn
3.1.4. Quá trình chạy job và thơng báo lỗi
Tồn bộ q trình tải dữ liệu trên kho EDW được thiết kế thành một công việc duy nhất chạy từ đầu đến cuối. Mỗi tầng sẽ được thiết kế một job riêng phục vụ cho công việc ETL tại tầng đó. Các job được thiết kế tại mỗi tầng sẽ được liên kết với nhau trên Server job và được thiết kế chạy tuần tự từ job tại tầng STG chạy thành cơng thì mới chạy tiếp job tại tầng ODS cứ như vậy cho đến job tại tầng DM chạy kết thúc. Nếu trong q trình chạy có bất cứ vấn đề nào sẽ ngừng job và thông báo mail ngay lập tức.
ETL Process Fiow
❖ Staging Data Load Process
Bắt đầu quá trinh,job tại tầng STG sẽ chạy đầu tiên và dữ liệu từ hệ thống nguồn được tải vào khu vực Staging. Neu phát hiện lỗi sẽ gửi gmail thông báo và dừng quy trình.
❖ DWH Data Load Process
Khi job tại tầng STG và ODS chạy thành công. Dữ liệu sẽ được load vào DWH phải đảm bảo đáp ứng được các chuẩn dữ liệu và dữ liệu IFS được tải vào các bảng đích tại DWH mà khơng bị mất dữ liệu. Nếu có phát hiện lỗi sẽ gửi gmail thơng báo và dừng quy trình.
❖ DM Data Load Process
Tuong tự job tại tầng DWH chạy thành công, dữ liệu được tải lên tầng DM. Nếu gặp phải bất kỳ vấn đề đối chiếu dữ liệu nào thì gửi thơng báo lỗi qua gmail. Nếu job chạy thành cơng thì gửi gmail thơng báo chạy thành cơng.
3.1.5. Các kiểu xử lý load dữ liệu
Khác với ODS, DWH lưu trữ dữ liệu lịch sử và hiện tại. Nên khi có sự thay đổi ở 1 bản ghi thì DWH phải cập nhật sự thay đổi đó. Sẽ có 2 loại SCD được sử dụng tại hệ thống E-banking là SCD type 1 và SCD type 2
3.1.5.1. Quá trình xử lý SCD type 1
Dữ liệu sau khi được trích xuất tại ODS sẽ so sánh với dữ liệu tại DWH thơng qua khóa natural key. Nếu có tồn tại bản ghi có cùng natural key với DWH thì sẽ dữ liệu nguồn được update vào DWH. Nếu khơng tồn tại bản ghi có cùng khóa natural key với DWH, dữ liệu được insert vào DWH.
Hình 3.4. Sơ đồ xử lý SCD type 1
3.1.5.2. Quá trình xử lý SCD type 2
Tương tự như SCD type 1, dữ liệu được trích xuất từ ODS cũng so sánh với dữ liệu tại DWH thơng qua khóa natural key. Neu khơng có bản ghi nào có cùng khóa natural key thì dữ liệu tại ODS là dữ liệu mới cần được insert vào DWH với effective start date = COB_DT và effective end date = ‘9999-12-31’. Neu bản ghi có khóa tồn tại trong DWH thì có 2 trường hợp xảy ra. Trường hợp bản ghi khơng có sự thay đổi, dữ liệu giống với bản ghi trong DWH thì kết thúc q trình tải dl. Trường hợp bản ghi có sự thay đổi so với bản ghi trong DWH thì bản ghi tại ODS được thêm mới vào và bản ghi cũ trong DWH được update lại
3.2. Nền tảng sử dụng
3.2.1. Hệ quản trị cơ sở dữ liệu Oracle
Oracle là một hệ thống phục vụ cho mục đích quản lý cơ sở dữ liệu quan hệ do nhà phát triển Oracle nghiên cứu và lập trình. Phần mềm này giữ vai trị trung tâm trong mảng cơng nghệ thơng tin của các doanh nghiệp. Nó có thể hỗ trợ đa dạng nhiệm vụ như xử lý các giao dịch, ứng dụng phân tích và hệ thống business intelligence (BI). Tương tự như những phần mềm RDBMS khác, hệ cơ sở dữ liệu Oracle được phát triển dựa trên nền tảng ngơn ngữ lập trình SQL. Ngơn ngữ này thường được giới công nghệ sử dụng để quản lý và truy vấn dữ liệu.
Oracle database được gắn với PL/SQL. Đây thực chất là một phần mềm được chính cơng ty phát triển, với mục đích phục vụ cho việc bổ sung các extension độc quyền dành cho SQL chuẩn. Bên cạnh đó, phần mềm Oracle còn cho phép người dùng có thể lập trình bằng Java kết hợp các chương trình đã viết trên PL/SQL, hay lập trình Java được gọi từ ngơn ngữ khác. Ngồi ra, Oracle database cịn kết nối các phần tử có mối liên quan với nhau giữa các bảng, bằng cách dùng cấu trúc bảng dạng hàng và cột. Nhờ thế, người dùng không cần lưu một dữ liệu trong nhiều bảng mà hệ thống vẫn dễ dàng xử lý. Điều này giúp tiết kiệm đáng kể nguồn tài nguyên dung lượng.
Mơ hình quan hệ của cơ sở dữ liệu Oracle còn cung cấp hàng loạt ràng buộc để đảm bảo tính vẹn tồn, duy trì độ chính xác cao cho dữ liệu. Đây là một phần tính năng của ACID - hệ thống các quy tắc về nguyên tử, sự thống nhất, tính độc lập, độ bền dữ liệu. ACID được thiết kế nhằm đảm bảo độ tin cậy trong quá trình xử lý các giao dịch của hệ thống lưu trữ cơ sở dữ liệu.
3.2.2. IBM InfoSphere DataStage
IBM® InfoSphere® DataStage® là một nền tảng ETL hàng đầu tích hợp dữ liệu trên nhiều hệ thống doanh nghiệp. Nền tảng có thể mở rộng cung cấp khả năng quản lý siêu dữ liệu mở rộng và kết nối doanh nghiệp. Nó tích hợp dữ liệu khơng đồng nhất, bao gồm dữ liệu lớn ở trạng thái nghỉ (dựa trên Hadoop) hoặc dữ liệu lớn đang chuyển động (dựa trên luồng), trên cả nền tảng phân tán và máy tính lớn.
Hinh 3.6. Giao diện IBM InfoSphere DataStage
IBM infosphere bao gồm các giai đoạn (stage) riêng lẻ được liên kết với nhau. Mô tả luồng dữ liệu từ nguồn đến đích (Ví dụ như hình ảnh 4.1 mơ tả luồng dữ liệu với 3 stage). Thơng thường, một giai đoạn (stage) có tối thiểu một đầu vào dữ liệu và / hoặc một đầu ra dữ liệu. Tuy nhiên, một số giai đoạn có thể chấp nhận nhiều hon một đầu vào và đầu ra dữ liệu cho nhiều hon một giai đoạn (stage).
Một số stage được sử dụng trong datastage
- Transform stage
- Filter stage
- Aggregator stage
- Remove duplicates stage
- Join stage
- Lookup stage
- Copy stage
- Sort stage
3.3. Thiết kếKho dữ liệu
3.3.1. Cấu trúc các bảng tại tầng STG
o CUSSESSIONLOG: lưu trữ các thông tin liên quan đến hoạt động
đăng nhập của khách hàng như thông tin mã người dùng, mã danh nghiệp, kênh đăng nhập, loại khách hàng, thời gian đăng nhập, số lần hành động,...
o BLENTERPRISE: bao gồm thông tin khách hàng là một tổ chức,
công ty, doanh nghiệp lớn đang sử dụng dịch vụ như mã internet banking, mã doanh nghiệp, tình trạng truy cập dịch vụ, mã gói dịch vụ sử dụng, mã chi nhánh, trạng thái thay đổi của khách hàng, số đăng ký kinh doanh của doanh nghiệp,.
o BLCUSTOMER: bao gồm các thông tin khách hàng cá nhân xoanh
quanh các thông tin cá nhân của khách hàng như mã khách hàng, tên khách hàng, họ, đệm, tên, ngày sinh, email, số điện thoại. Các thông tin liên quan đến trạng thái đăng nhập như lần đăng nhập cuối cùng, trạng thái truy cập, phương thức truy cập sử dụng, ngày đăng nhập gần nhất,...Các thông tin liên quan đến dịch vụ như mã internet banking, mã gói dịch vụ, mã thuế, tên đăng nhập,.
CUSSESSIONLOG » ID USERID ENTIRPRISEUSERID CHANNEL CUSTOMERTYPE XTIMESTAMP DURATION NUMBEROFACTION S SESSIONOATE SESSIONTIME SESSIONID BLENTERPRISE t ID ENTERPRISEID ENTERPRISENAME ACCESSSTATUS EMAIL SERVICEPACKAGEID FAX BUSINESSPHONE
MAXE NTE RPRISE USE RNUMBE R BRANCH CUSTCHANGESTATUS TAXID INDUSTRYSEGMENT BUSINESSREGNO ADMINUSERSREQUIRINGACTIONCOUNT IBUSERSREQUIRINGACTIONCOUNT BLCUSTOMER t ID CUSTOMERNUMBER IASTIOGGEDON IASTIOGGEDONTOMOBIIE ACCTSSSTATUS HOSTCUSTOMERID PERSONNAME TITU FIRSTNAME MIDDIENAME IASTNAME BIRTHDATE ISSUPERUSER EMAIIADDRESS CREATIONDATE MOBILE MEMBERTYPE BRANCHNUMBER CUSTCHANGESTATUS LOGONUSING GENDER ACCEPTEDSMSOFFERS SMSSTATUS LASTACCESSCOOEGENERATED SMSAUTHENTICATIONENABIEO RSATOKENAUTHENTICATIONENABIEO USERNAME SERVICEPACKAGEID TAXID MARITALSTATUS Hình 3.7. Các bảng trên hệ thống nguồn
IFS IB CUS NON IDV MSTR
SVC-PKG-ID
ENTP RS-EM AIL-ID
ENTP RS-TEL-N BR COB-DT SRC-SYS-CD UPDTD-BY UPDTD-DTM f ENTPRSJ DN TFTN-N BR ENTPRS-NM ACCS-STS ENTP RS-FAX-N BR GLOB-BRNCH-CD CUS-CH NG-STS TAX-IDN T FT N-N B R IN DUS-SGMNT
- Cấu trúc các bảng trên khu vực STG
Hình 3.8. Các bảng tại tầng STG
3.3.2. Cấu trúc các bảng tại tầng ODS
- Cấu trúc các bảng trên khu vực ODS:
o IFS IB IDV REF HIST: bao gồm các dữ liệu từ bảng
IBS-BLCustomer nhưng dữ liệu tập trung tới thông tin đăng nhập.
o IFS IB IDV REF USR: bao gồm các dữ liệu được lấy từ bảng
IBS-BLCustomer và dữ liệu tập trung tới thông tin của khách hàng sử dụng dịch vụ.
o IFS USR LGN DTL: bao gồm dữ liệu được lấy từ bảng IBS-
CUSSESSIONLOG
o IFS IB CUS NON IDV MSTR: bao gồm dữ liệu từ bảng IBS-
BLENTERPRISE
IFS IB IDV REF USR HIST t INTNET_BNK_ID UkSTJNTNET-LGN UkST-MOBIL-LGN LAST-LGN-DT COB-DT SRC-SYS-CD UPDTD-BY UPDTD-DTM CUS-NBR SUPPER-USR-FLAG EMAIL-ADDR MBL-NBR MBR-TYP CU S-CH NG-STS LGN-USING SMS-OFFR-DT LAST-ACCS-CD-GENRATED SMS-STS MRTL-STS IFS USR LGN DTL COB-DT SRC-SYS-CD UPDTD-BY UPDTD-DTM USR-LGN-DTL-SR-KEY CUS-NBR ENTPRS-IDNTFTN-NBR CHNL CUS-TYP LOG-DT DURN N BR-OF-ACTNS SESN-ID
IFS IB IDV REF USR COB-DT SRC-SYS-CD UPDTD-BY UPDTD-DTM ■8 CUS-NBR ACCS-STS HOST-CUS-ID CUS-NM KL FRST-NM MID-NM LAST-NM BRTH-DT SUPPER-USR-FLAG CREA-DT GLOB-BRNCH-CD GEN USR-NM SVC-PKG-ID TAX-ID
IB CUS NON IDV MSTR IB IDV REF USR HIST UPDTD-BY UPDTD-DTM SVC-PKG-ID ENTPRS-EM Al LlD ENTPRS-TEL-NBR COB-DT SRC-SYS-CD If ENTPRS-ID NTFT N-N B R ENTPRS-NM ACCS-STS ENTPRS-FAX-NeR GLOB-BRNCH-CD CUS-CH NG-STS TAXJDNTFTN-NBR INDUS-SGMNT BUSS-REGISTATION-NBR ADMINJJSR-ACTN-CNT INTNET-BN K-U SR-ACTN-CNT
V IBJDV-REF-SR.KEY CUS-NBR LAST-INTNET-LGN LAST MOBIL LGN SU PPER-US R-FLAG EMAIL-ADD R MBL-NBR MBR-TYP C U S-CH NG-STS LAST-LGN-DT MRTL-STS SMS-OFFR-DT SMS-STS LAST-ACCS-C D-G EN RATED LGN.USING EFF-STRT-DT EFF-END-DT COB-DT SRC-SYS-CD UPDTD-BY UPDTD-DTM Y INTN ET-B N KJ D
IB IDV REF USR
UPDTD-BY UPDTD DTM COB-DT SRC-SYS-CD ĩ CUS-NBR ACCS STS HOST-CUSJ D CUS-NM FRST-NM MID-NM LAST-NM BRTH-DT SUPPER-USR-FLAG CREA-DT GLOB-BRNCH-CD GEN USR-NM SVC-PKG-ID TAX-ID USR LGN DTL SRC-SYS-CD ■ UPDTD BY UPDTD-DTM COB-DT USR-LG N-DTL-SR-KEY CUS NBR « ENTPRSJDNTFTN-NBR CHNL CUS TYP LOG-DT DURN NBR-OF-ACTNS LGN TVP SR KEY ___________________________________________ Hình 3.9. Các bảng tại tầng ODS 3.3.3. Cấu trúc các bảng tại tầngDWH
Hình 3.10. Các bảng tại tầngDWH
3.3.4. Cấu trúc các bảng tại tầngDM
- BRNCH_DIM: lưu trữ dữ liệu về các chi nhánh của ngân hàng
- TM_DIM: lưu trữ dữ liệu thời gian được phân cấp theo yêu cầu phía ngân hàng
- CHNL_DIM: lưu trữ dữ liệu về phương thức truy cập
- UTIL_PRD_DIM: lưu trữ dữ liệu về các dịch vụ, tiện ích
- CUS_AGE_GRP_DIM: lưu trữ dữ liệu về chỉ tiêu từng nhóm tuổi của khách hàng
- CUS_DIM: lưu trữ thông tin về khách hàng
- CUS_TYP_DIM: lưu trữ dữ liệu về loại khách hàng
- VTGE_DIM: lưu trữ dữ liệu về chỉ tiêu thời gian gắn bó của khách hàng
- LGN_TYP_DIM: lưu trữ dữ liệu về phương thức đăng nhập
Tên bảng Ý nghĩa bảng
COB_DT Ngày tải dữ liệu vào hệ thống UPDTD_BY Ghi lại tên job
UPDTD_DTM Ghi lại thời gian dữ liệu update lần cuối
Hình 3.11. Các bảng tại tầng DM
3.4. Xây dựng quá trình ETL cho phân hệ E-banking
3.4.1. Xây dựng ETL tại tầng STG
Hệ thống nguồn bao gồm các bảng được lưu trữ trên CSDL Oracle 12c. Dữ liệu tại hệ thống nguồn thơng qua q trình ETL được lưu trữ tại khu vực lưu trữ tạm thời. Việc lưu trữ dữ liệu tại STG sẽ tránh việc phải trích xuất lại từ các nguồn nếu có sự cố xảy ra khi load dữ liệu trực tiếp từ nguồn vào DWH. Đồng thời yêu cầu transform tại tầng này đều khá đơn giản khơng địi hỏi nhiều u cầu nghiệp vụ mà chỉ cần mapping 1-1 kéo trực tiếp trường thông tin tại các bảng source sang STG. Và bổ sung 3 trường dữ liệu mới trên các bảng tại tầng STG
Thiết kế job đẩy dữ liệu lên tầng STG
Do quá trình ETL tại tầng Source-STG đều khá đơn giản nên em sẽ trình bày demo tồn bộ q trình ETL trên một job. Và dùng parallel job để thiết kế quá trình ETL tại tầng này. Parallel job là một quy trình xử lý dữ liệu bao gồm các giai đoạn (stage) riêng lẻ, mỗi giai đoạn là 1 quy trình cụ thể. Ví dụ: một giai đoạn có thể trích xuất dữ liệu từ 1 nguồn dữ liệu, trong khi giai đoạn khác chuyển đổi nó. Các giai đoạn được liên kết với nhau bằng các linked. Tại tầng STG sử dụng 3 stage sau: