Com crear el magatzem de dades perfecte

Es van facilitar tècniques importants d'emmagatzematge

Emmagatzematge de dades: simplificat

A la superfície, sembla que les coses han canviat molt en termes d’adquisició, emmagatzematge i emmagatzematge de dades en els darrers anys. La introducció i l'adopció de NoSQL, big data, gràfics i tecnologies de transmissió semblen haver canviat el panorama, però encara hi ha alguns problemes fonamentals.

En la meva funció actual, fem servir Amazon Redshift per al nostre emmagatzematge de dades. Independentment de si hem construït un magatzem de dades tradicional amb Oracle o un llac de dades amb Hadoop, l’arquitectura bàsica continua sent la mateixa.

L’arquitectura principal consisteix en algunes àrees de preprocessament i tres àrees separades (esquemes si utilitzeu Redshift) anomenades posada en escena, masterització i informes. En aquest post, entraré en tots els detalls.

Preprocessament

Malauradament, no totes les dades es creen iguals, però són dades i, per tant, són valuoses.

Per fer front a la complexitat de les dades externes, és imprescindible fer alguns processos previs, sobretot quan es recopilen diverses fonts diferents. L’objectiu principal del pas de preprocessament és portar les dades a un format coherent que pugui carregar el magatzem de dades.

Això inclou, entre d'altres:

  • Convertiu fulls de càlcul d'Excel a CSV
  • Analitzant dades JSON (solem processar tots els objectes seguits en una sola columna i deixar que Redshift l’analitzi, però també podeu analitzar-la abans d’hora)
  • Neteja de fitxers de dades danyats o danyats

Un cop hàgiu acabat, necessitareu una ubicació central on podreu tenir aquests fitxers disponibles per carregar-los al magatzem de dades.

Un exemple podria ser posar tots els fitxers en un dipòsit d’Amazon S3. És versàtil, econòmic i s’integra amb moltes tecnologies. Si utilitzeu Redshift per al vostre magatzem de dades, també s’hi integrarà bé.

Posada en escena

La zona de prova és el pa i mantega per a qualsevol magatzem de dades.

Un bon magatzem de dades utilitza dades de moltes fonts diferents. Cada font de dades té els seus propis matisos, estils i convencions de denominació.

A la zona d’intervenció és on introduïu tot això, probablement des d’on el col·loqueu després del preprocessament (però no sempre), i el manteniu temporalment fins que es processi més a la seqüència.

Igual que la zona de càrrega en un magatzem real. El lloc on es descarrega la càrrega no és la destinació final ni la forma final dels materials o productes. És només una zona d’aturada.
Foto de Hannes Egler a Unsplash

Per primera vegada, podeu mantenir totes les dades dins dels límits del magatzem preparats per a un posterior processament i modelatge.

Personalment, crec que les dades de l’àrea de prova haurien d’estar el més a prop possible de les dades brutes (de nou, heu de fer alguns canvis, però això no hauria de canviar res a les dades brutes). Fins i tot és possible que vulgueu conservar els noms de les columnes i les taules originals. Això fa que sigui més fàcil rastrejar-lo en investigar o informar de problemes a la font.

L’àrea d’intervenció també s’ha de veure com a temporal.

Heu de conservar les dades a la zona d’intervenció durant un període de temps seleccionat i després netejar-les. Per exemple, podeu mantenir un mes continuat de finestra de dades per a càrregues fallides o altres investigacions.

Aquest és l'últim punt en què les dades s'han de considerar crues. A partir d’aquest moment, les dades s’han d’ajustar als estàndards del magatzem de dades.

mestre

A l'àrea principal, les dades entrants prenen una forma real.

L'esquema mestre hauria de contenir taules modelades correctament que es nomenin adequadament. Els noms de columnes també s’han de corregir amb els seus tipus de dades.

Això facilita la comprensió de les taules i el que contenen i millora la usabilitat. Igual que arxivar documents a la vella escola.

Foto de Drew Beamer a Unsplash

Quan moveu dades de la fase inicial al master, tingueu en compte el següent:

  • La mateixa estandardització de tots els formats de data i zones horàries (si escau)
  • Si cal, arrodoneu els números a menys decimals
  • Netejar les cadenes per tal d’evitar la insensibilitat entre majúscules o minúscules o eliminar els espais anteriors i finals
  • Normalització d’adreces en el mateix format
  • Dividiu les dades en diverses columnes o extracte de JSON
També passaria una mica de temps assegurant-me que els noms de columna de les columnes enllaçades coincideixin.

Per exemple, si teniu dades d'usuari d'alguns registres web, les vostres dades d'usuari s'emmagatzemaran a MongoDB i possiblement algunes dades publicitàries sobre usuaris. Esperem que totes aquestes fonts continguin un identificador d’usuari únic. Tot i això, potser no tots ho anomenen el mateix.

L’estandardització dels noms de les columnes facilita la comprensió intuïtiva de les dades que es poden enllaçar per a vosaltres o per a altres usuaris de les vostres dades.

Com a enginyer de dades, aquest és l’objectiu final final.

Teniu dades que es nomenen correctament segons el llenguatge empresarial i que es modelen correctament perquè puguin examinar-se o calcular-se posteriorment.

informes

Es fa el treball bàsic. Vam preparar i gravar, modelar i netejar. Ara volem que les nostres noves i brillants dades estiguin disponibles per al món. Aquí és on entra en joc el nivell d'informes.

Si utilitzeu un magatzem de dades basat en files a Oracle, és possible que pugueu crear algunes taules de dades i dades de dades en aquest moment. Aquest és un cas d’ús perfectament raonable per al nivell d’informació, ja que podeu posar qualsevol eina d’informació decent a la part superior i esteu preparat.

Tot i això, algunes d’aquestes tècniques tradicionals d’emmagatzematge de dades tenen en compte l’eficiència de solucions d’emmagatzematge basades en files, com Oracle. Aquests sistemes poden combinar dades de manera eficient, però les files amb moltes columnes són ineficients, principalment a causa de l'enfocament basat en files que ha de gestionar tota la fila, encara que només siguin necessàries algunes columnes per a la consulta.

Si utilitzeu un magatzem de dades basat en pilars com Amazon Redshift, el vostre enfocament hauria de ser diferent. Redshift no té en compte les taules àmplies i es prefereix desnormalitzar les dimensions i els fets a una taula a les múltiples.

Modelar les vostres dades d’aquesta manera quan utilitzeu Redshift té els avantatges següents:

  • Millora de l'eficiència, ja que Redshift és més feliç amb taules àmplies que amb moltes combinacions.
  • Facilitat d'ús per a usuaris finals o analistes que no estiguin familiaritzats amb els models de dades perquè no han de lluitar amb els enllaços.
  • La consulta és més senzilla, ja que totes les dades necessàries per a l’entitat que s’informa es troben en un sol lloc.
Foto de Micheile Henderson a Unsplash

Per exemple, suposem que voleu informar-vos sobre els vostres clients. Teniu una taula de clients, una taula de comandes, una taula de registres de màrqueting i algunes dades d’anàlisi web al vostre nivell mestre net i cruixent.

A Redshift, crearíeu una taula de clients dins del nivell d'informes. S'hi emmagatzemen totes les dades estàndard dels clients (menys les vostres dades personals, ja que no són necessàries per informar), com la data de registre, possiblement un codi postal, etc.

Podeu esbrinar si us heu registrat en un dispositiu mòbil o si heu instal·lat l’aplicació per a telèfons intel·ligents o l’escriptori.

Podeu enllaçar les dades de la comanda i crear algunes columnes de dades, com ara: B. l'import total fins ara, la data de la primera comanda, la data de l'última comanda i el nombre de comandes.

Al full de càlcul de Màrqueting, faríeu el mateix i crearíeu fets rellevants com el nombre de correus electrònics enviats, oberts, fets clic, etc.

A l’analítica web podeu introduir la data de la darrera visita al lloc web, el dispositiu preferit, el tipus de dispositiu més comú (escriptori, telèfon mòbil, etc.), etc.

Obtens la imatge.

Això resulta en una taula de clients súper àmplia amb totes les dimensions i fets rellevants. Els vostres analistes el poden utilitzar per calcular des de taxes d’adquisició, diferents usos del dispositiu a la vostra base de clients, clients d’alt valor (i qualsevol semblança entre ells), retenció i retenció de clients, i molt més.

Tot això des d’un mateix lloc, sense dreceres, i la major part de l’elevació com hauria de ser, amb la potència del magatzem de dades.

Els magatzems de dades no solen ser barats i estan literalment dissenyats per trencar dades. Aprofiteu-ho al màxim i feu-ho tot el que pugueu aquí. Allibereu els vostres analistes d’informes en lloc d’esperar que el servidor d’informes menys potent faci el treball dur.

Podeu trobar que hi ha més que els analistes a punt per fer-lo servir si ho feu prou fàcil i ràpid.

En total

Si seguiu aquest enfocament senzill, crec que podeu crear un magatzem de dades completament funcional que no només sigui fàcil d’ampliar, sinó que també sigui fàcil d’entendre.

És possible que vulgueu pensar en els vostres nivells de fase, mestre i informe com a elements lògics. Això us pot funcionar. Prefereixo mantenir-los separats físicament, ja que no només se sent més net, sinó que també podeu restringir el que els usuaris finals poden utilitzar i veure dels estats anteriors.