ANALYTICAL BASE TABLE KAMIL STUPAK SAS INSTITUTE POLSKA REEWISE SKN BUSINESS ANALYTICS

Transkrypt

1 ANALYTICAL BASE TABLE KAMIL STUPAK SAS INSTITUTE POLSKA REEWISE SKN BUSINESS ANALYTICS

2 WPROWADZENIE: ABT A CYKL ŻYCIA MODELU ABT

3 WPROWADZENIE: DEFINICJA ABT Analytical Base Table płaska, zdenormalizowana tabela analityczna, wyliczana cyklicznie, zagregowana do poziomu obiektu analizy, zbierająca możliwie pełną informację o tym obiekcie. płaska maksymalnie zagregowana w wierszach, wiele kolumn zdenormalizowana celowo wprowadzona jest nadmiarowość przechowywanej informacji, w celu uniknięcia łączeń i przyspieszenia wykonywania zapytań i operacji tabela analityczna jako gotowe wejście do modelowania, a także na potrzeby raportów detalicznych i wysokopoziomowych wyliczana cyklicznie zazwyczaj miesięcznie (na koniec miesiąca) zagregowana do poziomu obiektu analizy najczęściej obiektem tym jest klient, choć równie dobrze może to być dowolna encja biznesowa zbierająca możliwie pełną informację o tym obiekcie kluczowy element podejścia 360º Customer View

4 WPROWADZENIE: WOLUMEN ABT Szablon tabeli ABT na poziomie klienta CUST_ID VAR_1 VAR_2 VAR_98 VAR_99 VAR_198 VAR_ ID klienta Obszar biznesowy 1 Obszar biznesowy 2 Obszar biznesowy n O jakim wolumenie zbioru mówimy? przykład: jeden z największych banków w Polsce, ABT kliencka dla CRM kilkanaście tysięcy zmiennych, kilka milionów wierszy (aktywnych klientów) zbiór sasowy, kompresja binarna, 100+ GB miesięcznie

5 WPROWADZENIE: FAQ Jakie korzyści biznesowe daje ABT? spójne, kompletne i zawsze aktualne repozytorium wiedzy błyskawiczny dostęp do dowolnej informacji o analizowanej encji automatyzacja preselekcji zmiennych do modeli predykcyjnych Gdzie tabela ABT jest już standardem? banki, telekomy, ubezpieczyciele i inne duże organizacje działy CRM, ryzyka, AML Kiedy nie warto budować tabeli ABT? gdy hurtownia danych jest niewielka gdy danych nie da się przedstawić w postaci panelowej

6 ETAPY BUDOWY ABT obszaru biznesowego Budowa DDS dla obszaru Budowa MSA dla obszaru Ustalenie ram biznesowych i technicznych Dobór wymiarów (kategorii podziału) Dobór agregatów MSA i ABT Połączenie źródeł w jedną tabelę Zebranie wystąpień encji elementarnej w okresie Odfiltrowanie jedynie śmieciowych rekordów Agregacja do analizowanej encji Wyliczenie statystyk na poziomie okresu Odfiltrowanie rekordów nie spełniających założeń Budowa ABT dla obszaru Wyliczenie statystyk na poziomie wielu okresów Merge ABT cząstkowych w finalne ABT Dołączenie do pełnego zakresu wystąpień encji Spójne potraktowanie braków danych

7 FLOW ETL: OGÓLNY ZARYS DATA QUALITY T T - n T - 1 T DWH T - n T - 1 T T - n T - 1 T DDS DATA QUALITY T - n T - 1 T T - n T - 1 T T - n T - 1 T MSA DATA QUALITY T T T ABT + + +

8 BUDOWA ABT CZĄSTKOWEJ: CASE STUDY obszaru biznesowego Budowa DDS dla obszaru Budowa MSA dla obszaru Bankowość detaliczna, dział CRM Klient indywidualny Transakcje kartami debetowymi Poziom granulacji: transakcja kartą debetową Połączenie źródeł w jedną tabelę Odfiltrowanie jedynie śmieciowych transakcji Poziom granulacji: klient Wyliczenie statystyk na poziomie miesiąca Odfiltrowanie klientów nie spełniających założeń Budowa ABT dla obszaru Poziom granulacji: klient Wyliczenie statystyk na poziomie kilku miesięcy

9 SPECYFIKACJA: OGÓLNE ZAŁOŻENIA Tworzymy wspólną dla całej organizacji tabelę ABT kliencką, czy kilka? Do zastanowienia: jaka jest obowiązująca polityka dostępu do informacji? czy występują zasadnicze różnice w warunkach wejścia klienta do tabeli? aspekt techniczny jak wielkość tabeli wpłynie na czasy przetwarzań? Zazwyczaj powstają osobne tabele ABT per punkt spojrzenia na klienta, np. według struktury organizacji: ABT kliencka dla działu CRM, ABT kliencka dla działu ryzyka, ABT kliencka dla działu AML

10 SPECYFIKACJA: OBSZAR BIZNESOWY Podstawowe założenia biznesowe warunki wejścia: klient indywidualny, posiadający co najmniej jedną aktywną kartę debetową na koniec miesiąca, transakcje wykonane kartą debetową jednolity znacznik czasu: dzień autoryzacji transakcji, księgowania, a może ładowania na hurtownię? Sens biznesowy vs. niuanse techniczne początek świata : czy interesują nas transakcje starsze niż np. 2 lata temu? inne specyficzne dla obszaru, np.: co w przypadku stornowania transakcji? Jaka kwota jeśli transakcja była przewalutowana? Dobór wymiarów (kategorii podziału) transakcja w ATM / POS / online transakcja tradycyjna / zbliżeniowa / NFC transakcja w Polsce / w UE / poza UE karta zwykła debetowa / prepaid / wirtualna bankomat nasz / obcy / zagraniczny grupy kodów MCC, np. transport / zdrowie i uroda / odzież / edukacja

11 SPECYFIKACJA: KRZYŻOWANIE WYMIARÓW Jak bardzo rozdrobniona ma być informacja? Należy unikać krzyżowania 3 lub więcej wymiarów Lepiej utworzyć 2-elementowe kombinacje bez powtórzeń Nie wszystkie punkty przecięcia niosą istotną informację Nie wszystkie punkty przecięcia mogą realnie wystąpić; warto stworzyć macierze współwystępowania wymiarów Przykładowe macierze współwystępowania: DBT (karta debetowa) PRE (karta prepaid) VIR (karta wirtualna) TRD (transakcja tradycyjna) CTL (transakcja zbliżeniowa) NFC (transakcja smartfonem) ATM (wypłata z bankomatu) TAK NIE NIE ATM (wypłata z bankomatu) TAK TAK NIE POS (zakup stacjonarny) TAK TAK NIE POS (zakup stacjonarny) TAK TAK TAK ONL (zakup przez internet) TAK NIE TAK ONL (zakup przez internet) TAK NIE NIE

12 SPECYFIKACJA: DOBÓR AGREGATÓW Dobór agregatów MSA flaga: czy dokonano transakcji liczba transakcji poprawnych / odrzuconych w miesiącu liczba dni z transakcją w miesiącu suma / średnia kwot transakcji w miesiącu minimalna / maksymalna kwota transakcji w miesiącu data ostatniej transakcji Dobór agregatów ABT stan na miesiąc przeliczenia maksimum / minimum 3- i 6-miesięczne suma / średnia 3- i 6-miesięczna liczba dni od ostatniej transakcji inne funkcje statystyczne i matematyczne? trend? seria?? Powinna nas ograniczać nie tylko wyobraźnia, ale też sens biznesowy!

13 SPECYFIKACJA: NAZEWNICTWO ZMIENNYCH Spójne nazewnictwo: zbędny pedantyzm? poszukiwanie interesującej nas zmiennej wśród tysięcy innych łatwa identyfikacja grup zmiennych w kodzie późniejszych programów konieczność dodawania sufiksów w trakcie modelowania Nazwa powinna składać się z max 6-7 członów, oddzielonych od siebie znakiem podkreślenia Każdy człon powinien mieć długość 3-4 znaków Tylko angielskie skrótowce w członach Nazwa powinna być o kilka znaków krótsza, niż technicznie dopuszczalna długość nazwy kolumny Użycie generatorów kodu nie tylko ułatwia, ale w praktyce nawet wymusza trzymanie się spójnego nazewnictwa zmiennych

14 SPECYFIKACJA: NAZEWNICTWO ZMIENNYCH Obszar biznesowy cz. 1 Obszar biznesowy cz. 2 Wymiar 1 Wymiar 2 Statystyka MSA Statystyka ABT DBC_TRN_ATM_OTH_SUM_MAX3 Debit cards Transactions ATM Other ATM Sum of Maximal withdrawal (not ours) withdrawn sum in last money 3 months

15 BUDOWA DDS DWH: TRANSAKCJE KARTOWE Wstępne filtrowanie: klient indywidualny transakcja dokonana kartą debetową data transakcji kwota transakcji > 0 niepuste ID transakcji, niepuste ID klienta Osłownikowanie wymiarów: zmienne tworzące kategoryzację transakcji powinny przyjmować ustalone w specyfikacji symboliczne wartości (3-4 znaki) w kolejnym kroku wartości będą bowiem transponowane do nazw zmiennych w MSA Budowa DDS TRN_ID CUST_ID TRN_DATE TRN_CHNL TRN_TYPE CARD_TYPE TRN_AMT TRN_STATUS ONL TRD DBT POS TRD DBT POS NFC DBT ATM TRD DBT POS TRD PRE ATM CTL DBT

16 BUDOWA MSA Budowa DDS TRN_ID CUST_ID TRN_DATE TRN_CHNL TRN_TYPE CARD_TYPE TRN_AMT TRN_STATUS ONL TRD DBT POS TRD DBT POS NFC DBT ATM TRD DBT POS TRD PRE ATM CTL DBT CCC: AAA: DDD BBB Budowa MSA CUST_ID DBC_TRN_ATM_FLG DBC_TRN_ATM_SUM DBC_TRN_ATM_MIN DBC_TRN_POS_NFC_FLG

17 BUDOWA ABT TRN_ID CUST_ID TRN_DATE TRN_CHNL TRN_TYPE CARD_TYPE TRN_AMT TRN_STATUS ONL TRD DBT POS TRD DBT POS NFC DBT ATM TRD DBT POS TRD PRE ATM CTL DBT Budowa DDS Budowa MSA Budowa ABT CUST_ID DBC_TRN_ATM_FLG DBC_TRN_ATM_SUM DBC_TRN_ATM_MIN DBC_TRN_POS_NFC_FLG

18 Budowa DDS Budowa MSA Budowa ABT Wybór narzędzia WYBÓR NARZĘDZIA NARZĘDZIE ZALETY WADY Platforma ETL-owa Dedykowany generator kodu (np. ABT Toolkit) Samodzielnie napisany prosty generator kodu + stosunkowo niewielki nakład pracy developera + joby ETL jako dokumentacja + zachowany data lineage + najszybsze rozwiązanie + minimalny wkład developera + wsad wejściowy do generatora jako dokumentacja + idealne dopasowanie do specyfiki danych + wysoka wydajność + wsad jako dokumentacja - uciążliwość wyklikiwania dla dużej liczby kolumn - konieczność dopisywania własnych transformacji - niedopasowanie do specyfiki danych (np. słaba wydajność) - trudności w modyfikowaniu - trudności w debugowaniu - bardzo duża pracochłonność po stronie developera - niska elastyczność - trudności w utrzymaniu Podejście mieszane przy użyciu różnych narzędzi Wykorzystanie platformy ETL do budowy DDS Wykorzystanie generatorów kodu do budowy MSA i ABT

19 PODSUMOWANIE Budowa DDS Budowa MSA Budowa ABT Wybór narzędzia Podsumowanie

20 DZIĘKUJĘ ZA UWAGĘ. PYTANIA?