Leggere un warehouse in sola lettura, e cosa decide il tuo ruolo
L’accesso di cui ha bisogno un livello di governance è stretto, specifico e vale la pena nominarlo con precisione. Cosa viene letto da un catalogo, cosa significa sola lettura quando è strutturale e non promessa, perché il tuo ruolo nel warehouse resta il confine, e cosa ti dà ereditare un catalogo.
La prima domanda in qualsiasi revisione è cosa tocca davvero la cosa. La risposta è abbastanza breve da leggerla ad alta voce in riunione.
Tabelle e colonne, con i loro tipi e i loro commenti.
Tag, che sono il posto in cui una piattaforma registra proprietà, stewardship e classificazione.
Chiavi, primarie ed esterne, così come le tiene la piattaforma.
Permessi, registrati perché un rapporto possa dichiarare chi poteva vedere una cosa.
Gli oggetti contratto stessi: il modello semantico, la semantic view, la metric view.
Ogni elemento di quell’elenco è un metadato. È il tuo catalogo, il tuo vocabolario e i tuoi permessi, che insieme sono il materiale di cui è fatto un rapporto di governance. I dati delle righe sono una richiesta a parte con una risposta a parte, e sono coperti dal percorso di query governato, non dalla sincronizzazione.
Una buona domanda da fare a qualsiasi strumento che chiede accesso al warehouse: chiedi cosa conserva. Qui l’audit conserva la forma di un risultato, cioè il numero di righe, e nessuna delle celle.
Cosa significa sola lettura qui
Ci sono due modi in cui un software può essere in sola lettura, e non sono affatto equivalenti.
Il modo debole è una promessa. Il codice è pienamente capace di scrivere e si impegna a non farlo, sostenuto da un commento di revisione che un futuro contributore non leggerà mai. Il modo forte è strutturale: le classi del connettore espongono un test di connessione e un’introspezione, e non c’è alcun metodo di scrittura da sorvegliare perché nessuno è mai stato scritto. La garanzia sopravvive a un refactoring fatto da qualcuno che non ne ha mai sentito parlare.
Una seconda gamba corre accanto alle API del catalogo, e vale la pena sapere perché c’è. Parte della governance che vuoi vive nell’information schema e nelle viste di sistema dell’account, non nel catalogo REST. Leggere i tag di proprietà e i vincoli delle chiavi significa eseguire istruzioni. Quelle istruzioni sono letture, sono limitate, e sono la ragione per cui un endpoint di calcolo compare sul modulo di connessione.
Il tuo ruolo resta il confine
L’accesso viene ereditato e mai allargato. Fornisci una credenziale, ogni lettura gira come quel principal, e l’orizzonte del rapporto è l’orizzonte del ruolo. Ciò che la credenziale non può raggiungere resta fuori portata.
Tre conseguenze, tutte pratiche.
Due amministratori con ruoli diversi possono eseguire la stessa sincronizzazione e ottenere inventari diversi. Entrambi sono corretti, e la differenza tra loro è un fatto sui tuoi permessi.
Allargare ciò che il livello vede è una concessione che fa il tuo team del warehouse, nel warehouse, sotto la propria revisione, e visibile nel proprio audit.
Una credenziale limitata a un database mantiene la sincronizzazione limitata a quel database, senza una seconda impostazione da ricordare da nessuna parte.
Il valore di questo in una revisione è che cambia la domanda posta. Cosa fa uno strumento con i tuoi dati è difficile da rispondere e facile da mettere in dubbio. Cosa gli hai concesso è una domanda che il tuo team già possiede, in un sistema che già gestisce, con un audit che già legge.
Gli host che una connessione può raggiungere, e dove vive il segreto
Un modulo di connessione che accetta qualsiasi host è una superficie di request forgery con un’etichetta amichevole. Un host di warehouse deve corrispondere a uno dei veri suffissi di hostname dei fornitori prima che qualsiasi cosa lasci il processo, e gli indirizzi privati, di loopback, link-local e di metadati cloud vengono respinti alla stessa porta.
L’effetto pratico è che un errore di battitura produce un messaggio per l’operatore che nomina l’host, non una richiesta nella tua rete che riesce a metà e non viene mai spiegata.
La credenziale stessa è cifrata a riposo e non viene mai restituita. Ciò che la console rende per una connessione configurata è filtrato dal flag di segretezza della specifica del campo, non da un elenco che qualcuno mantiene a mano. Un token non può raggiungere una pagina anche quando è memorizzato a un campo di distanza da qualcosa che lo fa. Ciò che vedi è l’host, il ruolo, il warehouse, il database, e quale tipo di credenziale si è autenticato.
Quest’ultimo elemento si guadagna il posto. Una connessione che ripiega da un tipo di credenziale a un altro senza dirlo può passare inosservata e restare non riparata. Quale ha risposto viene registrato e mostrato.
Ereditare un catalogo invece di ribatterlo
Ereditare un catalogo e ribatterne uno si leggono quasi uguali in un elenco di funzioni e non si comportano affatto allo stesso modo dopo sei mesi.
Ribattere chiede a qualcuno di ridigitare proprietari, classificazioni e descrizioni in un secondo sistema. Dal giorno in cui quel lavoro finisce ci sono due registrazioni dello stesso fatto, e una di esse sta invecchiando. Ereditare significa che la prima sincronizzazione legge ciò che la tua piattaforma già contiene: tabelle, colonne, commenti, tag, chiavi e permessi, nulla di tutto questo ridigitato da nessuno.
È anche il motivo per cui la richiesta di permessi resta piccola. Uno strumento che eredita ha bisogno di letture. Uno strumento che si aspetta che tu curi al suo interno ha bisogno di un posto dove scrivere, un posto dove memorizzare, e un argomento per cui la sua copia è quella di cui dovresti fidarti.
Le convenzioni di denominazione sono trattate come arricchimento sopra ciò che è arrivato, non come requisito. Un warehouse che non corrisponde a nessuno degli schemi attesi viene comunque ingerito per intero. Il nome del livello viene letto dall’etichetta qualificata dell’oggetto stesso, e il vocabolario è aperto, così un nome di livello che nessuno ha insegnato allo strumento arriva intatto invece di collassare in sconosciuto.
Letture parziali, etichettate come parziali
Alcune letture di governance hanno bisogno di una concessione che molti account non hanno mai fatto. Leggere i riferimenti ai tag su una piattaforma richiede un privilegio sul database condiviso dell’account stesso, e quei dati sono in ritardo di un paio d’ore anche una volta concesso.
Dove la concessione manca, la lettura è a miglior sforzo: restituisce ciò che ha potuto e riferisce ciò che non ha potuto. La distinzione è tutto il punto. Uno strumento che riporta zero proprietari documentati quando intende che non è riuscito a leggere i tag di proprietà ti ha detto qualcosa di falso sulla tua documentazione, tu agirai di conseguenza, e il lavoro sarà sprecato.
Una colonna vuota e una colonna che non è stato possibile leggere sembrano identiche sullo schermo e significano cose opposte. Una è una lacuna di documentazione dalla tua parte. L’altra è una lacuna di permessi sulla connessione.
La stessa disciplina attraversa il resto del prodotto. Una mappa di lineage nomina ciò che ha completato la sua granularità. Un livello vuoto ottiene zero, non un lusinghiero cento. Una prima sincronizzazione che torna magra ti sta mostrando la tua copertura oppure i tuoi permessi, e ci si aspetta che il rapporto dica quale delle due.
Le concessioni da chiedere
Un breve elenco da portare a chi possiede il tuo warehouse.
Lettura sul catalogo o sul database che vuoi inventariare, e sul suo information schema.
Lettura sull’oggetto contratto stesso: il modello semantico, la semantic view o la metric view.
Qualunque privilegio la tua piattaforma richieda per leggere i riferimenti ai tag; senza di esso, proprietà e classificazione risultano vuote.
Un endpoint di calcolo che il ruolo è autorizzato a usare, perché alcune letture di governance sono query.
Chiedi l’insieme più piccolo che risponde alla tua prima domanda, esegui una sincronizzazione, poi leggi cosa è tornato vuoto. Concedere sulla base di prove è una conversazione molto migliore che arrivare con un elenco, e lascia il tuo team del warehouse a tenere il confine, che è esattamente dove deve stare.
Un livello semantico dà a una metrica una sola casa. Ogni strumento che calcola la metrica legge quell’unica casa. Tutti ottengono lo stesso numero. Ecco cosa significa in pratica, e cosa cambia quando gestisci più di un warehouse.
Un contratto sulle metriche è ciò a cui somiglia un livello semantico quando qualcosa lo fa davvero rispettare. Come una definizione viene fissata, cosa succede a una domanda che nomina campi di due warehouse, e perché gli identificatori che raggiungono l’SQL vengono dal contratto stesso.
Due credenziali Tableau che fanno due lavori diversi. Una porta i permessi di una persona. L’altra estende una capacità della piattaforma. Scegliere quella giusta lascia al comando di chi vede cosa un modello di permessi che hai impiegato anni a costruire.