Questa è la seconda parte di una serie dedicata alla fraud detection automatizzata su un cloud data warehouse. L’idea è semplice: spostare un dataset di transazioni con carta di credito da un database sorgente a BigQuery, e poi addestrare direttamente in BigQuery ML un modello di classificazione per prevedere le transazioni fraudolente, senza gestire infrastruttura ML separata.
Dal database a BigQuery
Configurare BigQuery come destinazione richiede il Project ID e l’assegnazione del ruolo BigQuery User al service account. Come sorgente si usa un database SQL Server, collegato con un connettore che supporta CDC oppure la change detection log-free (Teleport). In fase di selezione conviene limitare la sync alle sole tabelle utili — nel caso, lo schema financial_services e la tabella delle transazioni — bloccando il resto. È disponibile anche l’hashing a livello di colonna per anonimizzare i dati PII mantenendoli utilizzabili nei workflow ML a valle. I dati in transito sono cifrati via TLS e quelli temporaneamente in servizio con AES256.
Sync incrementale e schema drift
Una volta impostata la sync, le modifiche DML e DDL vengono catturate automaticamente e propagate a BigQuery, gestendo lo schema drift senza codice. La frequenza di polling è configurabile: default ogni sei ore, ma regolabile da un minuto fino a 24 ore in base ai requisiti di freschezza del dato per l’applicazione di fraud detection.
Il modello in BigQuery ML
Il dataset di riferimento contiene 284.807 transazioni europee di settembre 2013, di cui 492 fraudolente (0,172%): un classico caso di forte sbilanciamento delle classi. Ha 30 feature — V1-V28 trasformate via PCA, più Time, Amount e Class (1 per frode, 0 altrimenti) — raccolte da Worldline e dal ULB Machine Learning Group. Il modello si crea con una query SQL, usando MODEL_TYPE='logistic_reg', INPUT_LABEL_COLS=['class'] per la label e AUTO_CLASS_WEIGHTS=TRUE per compensare lo sbilanciamento. La previsione si ottiene poi con ML.PREDICT, che restituisce per ogni transazione la probabilità associata alla classe.
- Il pattern separa nettamente il data movement (verso BigQuery) dalla parte ML, gestita in SQL con BigQuery ML.
- Su dataset fortemente sbilanciati,
AUTO_CLASS_WEIGHTSè l’opzione chiave per non ignorare la classe minoritaria. - Frequenza di sync e hashing delle colonne PII vanno tarati sui requisiti di freschezza e privacy.
Fonte: Automating credit card fraud detection with Google BigQuery ML and Fivetran — https://www.fivetran.com/blog/automating-credit-card-fraud-detection-with-google-bigquery-ml-and-fivetran
Hai qualcosa da aggiungere? Unisciti alla discussione.