Eksport terabajtów danych do zewnętrznych narzędzi analitycznych to strata czasu, zasobów i bezpieczeństwa. Oracle Machine Learning pozwala trenować modele uczenia maszynowego dokładnie tam, gdzie dane już się znajdują.

- Modele ML działające natywnie w bazie Oracle eliminują kosztowny transfer danych
- Składnia SQL pozwala DBA i programistom budować modele bez znajomości Pythona
- Scoring w czasie rzeczywistym bezpośrednio w zapytaniach SQL otwiera nowe możliwości
- Integracja z istniejącą infrastrukturą bezpieczeństwa i backupu to często pomijana zaleta
Architektura Oracle Machine Learning
Oracle Machine Learning (OML) to zestaw technologii wbudowanych w Oracle Database, który pozwala na budowę, trenowanie i wdrażanie modeli uczenia maszynowego bez opuszczania środowiska bazodanowego. Nie mówimy tu o jakimś dodatku czy zewnętrznym module; algorytmy ML są zaimplementowane bezpośrednio w jądrze bazy danych i wykonują się jako natywne operacje SQL.
W skład ekosystemu OML wchodzą następujące komponenty:
- OML4SQL (dawniej Oracle Data Mining) do budowy modeli przy użyciu PL/SQL
- OML4Py dla integracji z Pythonem
- OML4R dla użytkowników języka R
- OML Notebooks jako środowisko interaktywnej pracy
- OML Services udostępniające modele poprzez REST API
Z perspektywy DBA najistotniejszy jest fakt, że modele ML są przechowywane jako obiekty bazodanowe. Podlegają tym samym mechanizmom bezpieczeństwa, backupu i recovery co zwykłe tabele. Można na nich nadawać uprawnienia, eksportować przez Data Pump i replikować do środowisk standby.
Problem transferu danych w klasycznym podejściu
W typowym projekcie Data Science dane wędrują z produkcyjnej bazy Oracle do plików CSV, następnie do środowiska Python lub R, potem do chmurowej platformy ML, a finalnie predykcje wracają do systemu źródłowego. Przy wolumenach liczonych w setkach gigabajtów lub terabajtach ten proces generuje poważne problemy.
Po pierwsze, czas transferu. Eksport 500 GB danych przez sieć to przy optymistycznych założeniach kilka godzin. Po drugie, bezpieczeństwo. Dane osobowe i wrażliwe informacje biznesowe opuszczają kontrolowane środowisko bazodanowe. Po trzecie, spójność. W momencie gdy Data Scientist kończy trenowanie modelu, dane w produkcji zdążyły się zmienić.
Po 20 latach pracy z bazami Oracle widziałem dziesiątki projektów ML, które utknęły na etapie wdrożenia produkcyjnego. Model działał świetnie w notebookach, ale nikt nie potrafił go zintegrować z systemem transakcyjnym w sposób wydajny i bezpieczny. OML4SQL rozwiązuje ten problem w sposób elegancki.
Budowa modelu w czystym SQL
Pakiet DBMS_DATA_MINING stanowi fundament OML4SQL. Tworzenie modelu sprowadza się do wywołania procedury CREATE_MODEL z odpowiednimi parametrami. Przyjrzyjmy się praktycznemu przykładowi klasyfikacji klientów pod kątem ryzyka rezygnacji z usług.
Najpierw definiujemy ustawienia modelu w tabeli słownikowej:
BEGIN
INSERT INTO model_settings VALUES ('ALGO_NAME', 'ALGO_DECISION_TREE');
INSERT INTO model_settings VALUES ('PREP_AUTO', 'ON');
END;
Następnie tworzymy model wskazując tabelę treningową i kolumnę docelową:
BEGIN
DBMS_DATA_MINING.CREATE_MODEL(
model_name => 'CHURN_PREDICTION',
mining_function => DBMS_DATA_MINING.CLASSIFICATION,
data_table_name => 'CUSTOMER_DATA_TRAIN',
case_id_column_name => 'CUSTOMER_ID',
target_column_name => 'CHURNED',
settings_table_name => 'model_settings');
END;
To wszystko. Oracle automatycznie analizuje dane, przeprowadza preprocessing (normalizację, uzupełnianie braków, kodowanie zmiennych kategorycznych) i trenuje model. Cały proces wykonuje się wewnątrz bazy, wykorzystując jej mechanizmy równoległego przetwarzania.
Algorytmy klasyfikacyjne w praktyce
OML4SQL oferuje bogaty zestaw algorytmów klasyfikacyjnych. Decision Tree sprawdza się gdy potrzebujemy interpretowalności; możemy wyeksportować reguły i pokazać biznesowi dokładnie dlaczego model podjął daną decyzję. Random Forest daje lepszą dokładność kosztem przejrzystości. Naive Bayes działa zaskakująco dobrze przy danych tekstowych. Support Vector Machine radzi sobie z nieliniowymi zależnościami.
W sektorze finansowym klasyfikacja służy do oceny zdolności kredytowej, wykrywania fraudów kartowych i scoringu klientów. W telekomunikacji przewiduje churn i optymalizuje kampanie retencyjne. W e-commerce personalizuje rekomendacje i segmentuje użytkowników.
Regresja i prognozowanie wartości
Modele regresyjne w OML pozwalają prognozować wartości ciągłe: przychody, koszty, czas realizacji zamówienia, zużycie zasobów. Dostępne algorytmy to między innymi Generalized Linear Models, Support Vector Regression oraz Neural Networks.
Szczególnie przydatna okazuje się regresja w połączeniu z partycjonowaniem. Możemy zbudować oddzielny model dla każdego regionu sprzedażowego lub kategorii produktów, a Oracle automatycznie wybierze właściwy model podczas scoringu.
Wykrywanie anomalii bez etykietowanych danych
Anomaly Detection w OML bazuje na algorytmie One-Class SVM. Model uczy się wzorca normalnych zachowań i identyfikuje obserwacje odbiegające od tego wzorca. Nie wymaga etykietowanych danych treningowych, co jest kluczowe w scenariuszach bezpieczeństwa.
W praktyce wykorzystuję ten mechanizm do monitorowania aktywności użytkowników bazy danych. Model trenowany na historii zapytań potrafi wykryć nietypowe wzorce dostępu, które mogą świadczyć o naruszeniu bezpieczeństwa lub przejęciu konta.
Clustering czyli segmentacja bez z góry określonych kategorii
Algorytmy grupowania (k-Means, Expectation Maximization, O-Cluster) automatycznie identyfikują naturalne skupiska w danych. Klient nie musi definiować kategorii; model sam odkrywa strukturę.
Typowe zastosowania obejmują segmentację klientów pod kątem wartości życiowej, grupowanie produktów według wzorców sprzedażowych oraz identyfikację podobnych przypadków w danych medycznych.
Scoring w czasie rzeczywistym
Największą zaletą OML jest możliwość wykorzystania wytrenowanych modeli bezpośrednio w zapytaniach SQL. Funkcja PREDICTION zwraca przewidywaną klasę, PREDICTION_PROBABILITY prawdopodobieństwo, a PREDICTION_DETAILS szczegółowe informacje o decyzji modelu.
SELECT customer_id,
PREDICTION(churn_model USING *) as predicted_churn,
PREDICTION_PROBABILITY(churn_model, 1 USING *) as churn_probability
FROM customers
WHERE PREDICTION_PROBABILITY(churn_model, 1 USING *) > 0.7;
To zapytanie zwraca klientów z wysokim ryzykiem rezygnacji. Wykonuje się w czasie rzeczywistym, bez eksportu danych, bez wywołań zewnętrznych API. Model jest częścią planu wykonania zapytania i korzysta z indeksów oraz statystyk optymalizatora.
Ocena jakości modelu
OML dostarcza procedury do walidacji modeli. COMPUTE_CONFUSION_MATRIX generuje macierz pomyłek dla klasyfikacji. COMPUTE_LIFT pokazuje skuteczność modelu w porównaniu z losowym wyborem. COMPUTE_ROC analizuje krzywą ROC i oblicza pole pod krzywą (AUC).
Dobrą praktyką jest automatyczne monitorowanie jakości modeli produkcyjnych. Regularnie porównuję predykcje z rzeczywistymi wynikami i alertuję gdy metryki spadają poniżej ustalonych progów. Model, który działał świetnie rok temu, może wymagać przetrenowania gdy zmieni się profil danych.
Integracja z Pythonem i narzędziami Data Science
OML4Py pozwala Data Scientistom pracować w znajomym środowisku Pythona przy jednoczesnym wykorzystaniu mocy obliczeniowej bazy Oracle. Biblioteka oml udostępnia interfejs podobny do pandas, ale operacje wykonują się po stronie serwera bazodanowego.
Można również wdrażać modele zbudowane w scikit-learn lub TensorFlow do bazy Oracle i wywoływać je przez SQL. To pozwala zespołom Data Science zachować preferowane narzędzia przy jednoczesnym korzystaniu z zalet scoringu bazodanowego.
Kiedy OML nie jest najlepszym wyborem
OML ma swoje ograniczenia. Nie obsługuje najnowszych architektur deep learning tak dobrze jak dedykowane frameworki. Przetwarzanie obrazów czy tekstu metodami transformerowymi wymaga zewnętrznych narzędzi. Jeśli zespół Data Science jest przyzwyczajony do PyTorch lub TensorFlow, wymuszanie OML może spotkać się z oporem.
Dodatkowo licencjonowanie wymaga opcji Advanced Analytics, co dla mniejszych organizacji może stanowić barierę kosztową. Warto przeprowadzić analizę TCO uwzględniającą koszty alternatywnego podejścia z infrastrukturą ML poza bazą.
Strategiczny kierunek rozwoju
Oracle konsekwentnie rozwija koncepcję Converged Database; bazy danych będącej centralnym hubem dla różnych typów przetwarzania. Machine Learning wewnątrz bazy to element tej strategii, podobnie jak JSON, spatial, graph czy blockchain.
Trend eliminowania kopiowania danych (data gravity) widoczny jest również u innych dostawców. Snowflake wprowadza Snowpark ML, Databricks integruje się z Delta Lake. Oracle miał jednak przewagę czasową; funkcje Data Mining dostępne są w bazie od wersji 9i.