Crea piattaforme dati affidabili con i principi SRE di Google
Ci sono clienti che vengono da te per primi con un incidente relativo ai dati? I tuoi clienti stanno costruendo le proprie soluzioni dati a causa di dati non affidabili? Il tuo team dati dedica ore inutilmente lunghe a risolvere problemi di qualità dei dati non rilevati invece di dare priorità al lavoro strategico?
I team dati devono essere in grado di tracciare un quadro completo dello stato di salute dei loro sistemi dati per guadagnare la fiducia delle parti interessate e avere conversazioni migliori con l'azienda nel suo complesso.
Possiamo combinare le dimensioni della qualità dei dati con i principi di Site Reliability Engineering di Google per misurare lo stato dei nostri sistemi di dati. A tale scopo, valuta alcune dimensioni della qualità dei dati che abbiano senso per le tue pipeline di dati e individuale obiettivi del livello di servizio (SLO).
Cosa sono gli obiettivi del livello di servizio?
La terminologia relativa al livello di servizio che utilizzeremo in questo articolo è indicatori del livello di servizio E obiettivi del livello di servizio. I due principi sono presi in prestito da Il libro SRE di Google.
livello di servizio indicatore — una misura quantitativa attentamente definita di alcuni aspetti del livello di servizio fornito.
Gli indicatori con cui abbiamo familiarità nel mondo del software sono velocità effettiva, latenza e tempo di attività (disponibilità). Questi vengono utilizzati per misurare l'affidabilità di un'applicazione o di un sito Web.
Gli indicatori vengono poi trasformati in obiettivi delimitati da a soglia. Lo stato dell'applicazione software è ora “misurabile”, nel senso che ora possiamo comunicare lo stato della nostra applicazione ai nostri clienti.
obiettivo del livello di servizio: un valore target o un intervallo di valori per un livello di servizio misurato da uno SLI.
Comprendiamo intuitivamente la necessità di queste misure e indicatori quantitativi nelle tipiche applicazioni utente per ridurre l'attrito e stabilire la fiducia con i nostri clienti. Dobbiamo iniziare ad adottare una mentalità simile quando costruiamo pipeline di dati nel mondo dei dati.
Dimensioni della qualità dei dati tradotte nella terminologia del livello di servizio
Supponiamo che l'utente interagisca con la nostra applicazione e generi X quantità di dati ogni ora nel nostro data warehouse, se il numero di righe che entrano nel magazzino diminuisce improvvisamente drasticamente, possiamo contrassegnarlo come un problema. Quindi traccia i nostri timestamp dalle nostre pipeline per diagnosticare e trattare il problema.
Vogliamo acquisire informazioni sufficienti sui dati che entrano nei nostri sistemi in modo da poter rilevare quando si verificano anomalie. La maggior parte dei team dati tende a iniziare con Tempestività dei dati. La quantità prevista di dati arriva al momento giusto?
Questo può essere scomposto negli indicatori:
- Disponibilità dei dati: la quantità prevista di dati è arrivata/è stata resa disponibile?
- Aggiornamento dei dati: i nuovi dati sono arrivati nei tempi previsti?
Una volta che il sistema è stabile, è importante mantenere un buon rapporto con i propri clienti al fine di fissare gli obiettivi giusti che siano preziosi per i propri stakeholder.
Il concetto di soglia…
Come possiamo effettivamente capire quanti dati aspettarci e quando? Qual è la giusta quantità di dati per tutti i nostri diversi set di dati? Questo è il momento in cui dobbiamo concentrarci su soglia concetto in quanto diventa complicato.
Supponiamo di avere un'applicazione in cui gli utenti accedono al sistema principalmente durante l'orario di lavoro. Prevediamo circa 2.000 eventi USER_LOGIN all'ora tra le 9:00 e le 17:00 e 100 eventi al di fuori di tali orari. Se utilizzassimo un unico valore di soglia per l’intera giornata, ciò porterebbe a una conclusione sbagliata. Ricevere 120 eventi alle 20:00 è perfettamente ragionevole, ma sarebbe preoccupante e dovrebbe essere indagato ulteriormente se ricevessimo solo 120 eventi alle 14:00.
Per questo motivo, dobbiamo calcolare un valore atteso diverso per ogni ora del giorno per ogni diverso set di dati: questo è il valore di soglia. Sarebbe necessario definire una tabella di metadati che recuperi dinamicamente il numero di righe arrivate ogni ora per ottenere una soglia risultante che abbia senso per ciascuna origine dati.
Esistono alcune soglie che possono essere estratte utilizzando i timestamp come proxy, come spiegato sopra. Questo può essere fatto utilizzando misure statistiche come medie, deviazioni standard o percentili per scorrere la tabella dei metadati.
A seconda di quanto vuoi essere creativo, puoi anche introdurre l’apprendimento automatico in questa parte del processo per aiutarti a impostare la soglia. Altre soglie o aspettative dovrebbero essere discusse con le parti interessate in quanto deriverebbero dalla conoscenza specifica dell'azienda per sapere cosa aspettarsi.
Implementazione tecnica in Snowflake
Il primo passo per iniziare è scegliere alcuni set di dati aziendali critici su cui basarsi prima di implementare una soluzione data-ops su larga scala. Questo è il modo più semplice per acquisire slancio e percepire l'impatto dei tuoi sforzi di osservabilità dei dati.
Molti magazzini analitici dispongono già di funzionalità integrate a questo riguardo. Ad esempio, Snowflake è stato recentemente eliminato Funzioni metriche dei dati in anteprima per gli account Enterprise per aiutare i team dati a iniziare rapidamente.
Data Metrics Functions racchiude alcune delle query che potremmo scrivere per ottenere informazioni dettagliate sui nostri sistemi di dati. Possiamo iniziare con i DMF del sistema.
Dobbiamo prima sistemare alcuni privilegi…
USE ROLE ACCOUNTADMIN;GRANT database role DATA_METRIC_USER TO role jess_zhang;
GRANT EXECUTE data metric FUNCTION ON account TO role jess_zhang;
## Useful queries once the above succeeds
SHOW DATA METRIC FUNCTIONS IN ACCOUNT;
DESC FUNCTION snowflake.core.NULL_COUNT(TABLE(VARCHAR));
DATA_METRIC_USER è un ruolo del database che potrebbe sorprendere alcune persone. È importante rivedere i documenti se riscontri problemi. Il motivo più probabile è probabilmente dovuto alle autorizzazioni.
Quindi, scegli semplicemente un DMF…
-- Uniqueness
SELECT SNOWFLAKE.CORE.NULL_COUNT(
SELECT customer_id
FROM jzhang_test.product.fct_subscriptions
);
-- Freshness
SELECT SNOWFLAKE.CORE.FRESHNESS(
SELECT
_loaded_at_utc
FROM jzhang_test.product.fct_subscriptions
) < 60;
-- replace 60 with your calculated threshold value
Puoi pianificare l'esecuzione dei tuoi DMF utilizzando Programma metrico dei dati – un parametro dell'oggetto o il tuo solito strumento di orchestrazione. Sarebbe ancora necessario fare il duro lavoro per determinare le proprie soglie al fine di impostare gli SLO giusti per le proprie pipeline.
In sintesi…
I team dati devono collaborare con le parti interessate per stabilire aspettative migliori sui dati utilizzando indicatori e obiettivi del livello di servizio. L’introduzione di questi parametri aiuterà i data team a passare da una lotta antincendio reattiva a un approccio più proattivo nella prevenzione degli incidenti relativi ai dati. Ciò consentirebbe di riorientare le energie verso la fornitura di valore aziendale e la creazione di una piattaforma dati affidabile.
Se non diversamente specificato, tutte le immagini sono dell'autore.
Fonte: towardsdatascience.com
