En dataplattform er ikke en database. Databaser er grunnlaget for dataplattformer og gir deg ikke muligheten til å håndtere analyser. En dataplattform derimot, fungerer som et ekstra lag på toppen av en database, som er optimalisert for å tjene dette formålet. Virksomheter trenger effektive og langsiktige dataarkitekturer for å støtte opp i arbeidet med å holde seg oppdatert på dagens datarelaterte utfordringer. La oss se nærmere på funksjonalitetene som kreves for å opprettholde en grunnleggende dataplattform.
Hva er en dataplattform?
Først og fremst, en dataplattform er en tjeneste som lar deg innhente, behandle, lagre, få tilgang til, analysere og presentere data, skriver Medium. Vi kan bryte det ned i følgende deler:
- Datavarehus: innhenting, prosess, lagring, tilgang
- Intelligens: analyse og presentasjon
- Data Science: statistikk og kunstig intelligens
Lagring og behandling av data er selve kjernen i dataplattformen. Dette er imidlertid bare begynnelsen. For skape en oversikt over de vanligste data management oppgavene, har Medium samlet en liste over 18 kriterier som viser hva en dataplattform innebærer:
- Dataarkitektur (infrastruktur, skalering, database)
- Import av grensesnitt
- Datatransformasjon (ETL)
- Performance
- Prosessautomatisering
- Overvåkning (monitoring)
- Datahistorikk
- Dataversjonering
- Surrogate Key Management
- Analyse / rapportering
- Data Science
- Ekstern tilgang / API
- Brukervennlighet
- Flerbrukerprosess
- Dokumentasjon på plattformen
- Dokumentasjon
- Sikkerhet
- Kostnader
Nedenfor gir vi deg en kort introduksjon til hver av disse kriteriene uten å gå inn på tekniske detaljer.
1. Dataarkitektur (infrastruktur, skalering, database)
Dataarkitekturen er et sentralt aspekt i en dataplattform. For å finne en passende lagrings- og databaseløsning som tilfredsstiller dine behov, kan du velge mellom tre grunnleggende alternativer:
Relasjonsdatabase
Eldre databasesystemer med innebygd intelligens for effektiv håndtering av store datasett har de mest uttrykksfulle analyseverktøyene. Disse er imidlertid mer komplekse når det gjelder vedlikehold. I dag er disse systemene også tilgjengelige som distribuerte systemer og kan håndtere ekstremt store datasett. Eksempler inkluderer PostgreSQL med Citus eller Greenplum klyngeløsning, MariaDB / MySQL med Galera Cluster, Amazon Redshift, Oracle, MSSQL, etc.
NoSQL Sharding Database
Disse systemene er også designet for å håndtere ekstremt store datasett og ofrer noen av de klassiske egenskapene til relasjonsdatabaser for å få mer kraft på andre områder. De tilbyr mye mindre analytisk kraft, men er lettere å administrere, har høy tilgjengelighet og muliggjør enkle sikkerhetskopier. Det etterstrebes å etterligne den analytiske kraften til SQL som er tilgjengelig i relasjonsdatabase-verdenen med tilleggsverktøy som Impala eller Hive. Hvis du har enorme mengder data, spesifikke krav til streaming eller sanntidsdata, bør du ta en titt på disse spesialiserte datasystemene. Eksempler er Cassandra, Hadoop Ecosystem, Elasticsearch, Druid, MongoDB, Kudu, InfluxDB, Kafka, neo4j, Dgraph, etc.
Filbaserte systemer
Det er mulig å utforme en strategi som er basert utelukkende på filer. Filstrukturer som Parquet lar deg bruke rimelig lagringsplass for å imøtekomme veldig store datasett fordelt over en rekke lagringsnoder eller i en Cloud Object Store som Amazon S3. Den største fordelen er at datalagringssystemet alene er tilstrekkelig til å svare på dataspørsmål. I de to eksemplene som er beskrevet ovenfor, må du tvert imot kjøre tjenester på ekstra beregningsnoder for å svare på dataspørsmål.
Når du leter etter software som støtter dataarkitekturen din, har du noen få grunnleggende alternativer:
1. Du kan bygge plattformen din og stole på tjenester som tilbys av store skyleverandører. På skyplattformer som AWS, Azure eller Google Cloud kan du koble sammen et utvalg av enkle tjenester for å opprette en dataplattform som dekker vår liste over kriterier. Dette kan se enkelt og billig ut i liten skala, men kan vise seg å være ganske komplisert og dyrt når du skalerer opp og trenger å tilpasse.
2. Derimot er det plattformer basert på egenstyrt maskinvare, inkludert virtuelle maskiner i skyen og individuelle programvarestabler. Her har du maksimal fleksibilitet, men du må også ta opp mange av kriteriene på listen vår ved å lage koden og tilpassede løsninger.
2. Ytelse
Dette er et nøkkelkriterie når det gjelder valg av plattform. Ytelse påvirkes for det meste av databasesystemet du velger. Vår tommelfingerregel er: Jo høyere ytelseskrav du har, desto mer spesialisert bør valget av ditt databasesystem være.
3. Data Transformasjon (ETL)
Data importert til en dataplattform må vanligvis gjennomgå noen transformasjoner før de kan brukes til analyse. Denne prosessen kalles tradisjonelt ETL (Extract, Transform, Load). ETL gjør det mulig for virksomheter å samle inn data fra flere kilder og konsolidere dem til et enkelt, sentralisert sted.
Datatransformasjon handler om endring og tilrettelegging av data fra ulike kilder på en slik måte at data blir lettere å benytte til andre formål. Dette kan være data fra kilder som ERP- og CRM-systemer, Excel-ark og så videre. Et typisk formål kan være rapportering og analyse, hvor vi etter datatransformasjonen legger data i et datavarehus på en slik måte og i et slikt format at det blir enklere å rapportere og analysere på data, gjerne på tvers av ulike fagsystemer.
Dette er den mest tidkrevende oppgaven i ethvert datamiljø. I de fleste tilfeller tar denne oppgaven opptil 80% av den samlede tiden. Større datalager kan inneholde tusenvis av ETL-prosesser med forskjellige stadier, avhengigheter og prosesseringssekvenser.
Les mer: Datatransformasjon: Hva, hvordan og hvorfor
4. Import av grensesnitt
Vi kategoriserer dette inn i fire ulike seksjoner:
1. Filer: Filer er fortsatt den vanligste formen for data i dag.
2. Web services: Mange nettjenester med relevante data er tilgjengelige online.
3. Databaser: Selv om mange organisasjoner lagrer dataene sine i tradisjonelle databaser, er direkte databasetilgang i de fleste tilfeller ikke eksponert for internett og er derfor utilgjengelig for skydataplattformer. Webtjenester kan plasseres mellom lokale databaser og skytjenester for å håndtere sikkerhetsaspekter og tilgangskontroll.
4. Sanntidsstrømmer: “Real-time streams“ som leveres av meldingsrutere (slik som WAMP, MQTT, AMQP, etc.) er fremdeles underutnyttet i dag, men får stadig større betydning med økningen av IoT.
5. Prosessautomatisering
Når du har mange kilder, mål og flere datatransformasjons-prosesser, har du også mange avhengigheter. Automatisering av prosesser er en del av enhver dataplattform og involverer en rekke prosesser med høy kompleksitet. For planlegging av prosesser har en rekke dedikerte verktøy som Apache Airflow, Automate, Control-M eller Luigi blitt gjort tilgjengelig.
Prosessautomatisering krever at du administrerer utvalget av data som skal behandles. For eksempel i et trinnvis opplastningsscenario, må hver prosessutførelse trinnvis plukke spesifikke biter av kildedata for å overføre til målet. Data Scope Management implementeres vanligvis med en meta-datadrevet tilnærming. Det er dedikerte tabeller med metadata som holder oversikt over prosesstilstanden for hver del og kan spørres for å koordinere behandlingen av alle biter.
Les mer: Automatisering av datavarehuset
6. Overvåkning (monitorering)
Større datalagersystemer kan lett inneholde hundrevis av tabeller med hundrevis av automatiserte ETL-prosesser som administrerer dataflyten. Feil underveis er nesten uunngåelig. Mange av disse feilene må håndteres manuelt. Med denne mengden kompleksitet trenger du en måte å overvåke prosessene på plattformen på.
7. Datahistorikk
Behovet for å administrere lengre historikk med data er en del av kjernen i enhver dataplattform. Selve oppgaven til et datavarehus kan oppsummeres som å slå sammen separate biter av data til en homogen datahistorikk.
Ettersom data naturlig genereres over tid, vil det oppstå et behov for å supplere et eksisterende datalager med nye data. Teknisk sett spores tidsintervaller i tabeller ved hjelp av dedikerte kolonner for dette. Datahistorisering er en effektiv måte å kunne styre disse tidsintervallene når nye data kommer. Datahistorisering er forskjellig fra dataversjonering i den forstand at datahistorisering er opptatt av virkelige tidsstempler, mens versjonering vanligvis er opptatt av tekniske innsettingsstempler.
8. Dataversjonering
Ved å versjonere data kan du spore datakorrigeringer over tid, for å senere kunne gjenopprette gamle analyser. Versjonering lar deg bruke ikke-destruktive korreksjoner på eksisterende data. Når du sammenligner versjonsfunksjoner, må du vurdere hvor enkelt det er å lage versjoner og hvor enkelt det er å gjenopprette eller spørre om versjoner. Versjonering kan håndteres på forskjellige systemnivåer:
- Ta snapshots på subsystem for lagring (ligner på sikkerhetskopier)
- Det underliggende databasesystemet kan komme med støtte for versjonssporing
- Versjonering kan håndteres av datalagersystemet
- Versjonering kan implementeres som en tilpasset transformasjonslogikk i brukerområdet
9. Surrogate Key Management (surrogatnøkler)
Dataplattformer brukes til å konsolidere data fra mange kilder med forskjellige identifikatorer for de respektive objektene. Dette skaper behovet for nye nøkkelområder for de importerte objektene og behovet for å opprettholde dem gjennom påfølgende import. Disse nye nøklene kalles surrogatnøkler. Å lage og vedlikeholde disse nøklene effektivt er ingen enkel oppgave.
10. Analyse / rapportering
Formålet med en dataplattform er å forberede rådata til analyse og lagre disse dataene for å kunne se historikk. Analyser i en slik plattform kan utføres på en rekke måter.
En rekke Business Intelligence verktøy er bare opptatt av oppgaven med å lage analytiske og menneskelig lesbare dataekstrakter. For å forberede data til å bli presentert, gir en dataplattform deg funksjoner for å lage dataekstrakter og aggregater fra større datalagre.
Å svare på spesifikke forretningsspørsmål, ved hjelp av intelligent spørring i datalagrene, krever brukerferdigheter i analytiske spørrespråk. BI-verktøy har som mål å forenkle disse oppgavene ved å tilby pek-og-klikk-grensesnitt for å svare på grunnleggende spørsmål som «antall besøkende per måned i butikken» eller «sum av omsetning i region X». Disse verktøyene gjør det også mulig for brukere å visualisere informasjonen via omfattende grafikk. I nesten alle tilfeller vil superbrukere fortsatt være i stand til å omgå disse verktøyene og utføre sine egne spørsmål. Eksempler på populære BI-verktøy er blant annet Tableau, Qlik, Looker, Chartio og Superset.
11. Data Science
Opplæring av maskinlæringsmodeller er et krav som dagens dataplattformer må levere på. De mest sofistikerte metodene implementeres ikke ved hjelp av SQL, men Python eller R sammen med et bredt utvalg av spesialiserte biblioteker som NumPy, Pandas, SciKit Learn, TensorFlow, PyTorch eller enda mer spesialiserte biblioteker for NLP eller bildegjenkjenning. Siden disse oppgavene kan være krevende beregningsmessig, er det ofte nødvendig med ekstra hardware i tillegg til den eksisterende analysemaskinvaren.
Les mer: Tekst er også data – slik får du verdi ut av det naturlige språk
12. Ekstern tilgang / API
Alle de innsamlede dataene på plattformen skal brukes til forskjellige formål. Mulige kanaler som vurderes her er:
a) SQL Access for direkte analyse også av f.eks. BI-verktøy
b) API-tilgang (REST-forespørsel) som en tjeneste for nettsteder eller apper
c) Varsler via SMS/e-post for sluttbrukere eller administratorer
d) Fileksport for videre behandling eller datalevering til andre parter
13. Brukervennlighet
Brukervennligheten til plattformen avhenger av målgruppen. Hovedproblemet her er hvor enkelt det er å opprette og administrere objekter (som brukere, datalager, tabeller, transformasjoner, rapporter osv.) på plattformen. Ofte må man velge mellom det kontrollnivået en bruker får og nivået på enkelhet. Her må vi skille mellom funksjonaliteten som plattformen gir og det brukergenererte innholdet på plattformen. I de fleste tilfeller krever brukergenerert innhold bruk av kode, siden hele emnet datateknikk og analyse er av natur komplisert og krever høyt uttrykksnivå.
14. Flerbrukerprosess
Denne kategorien evaluerer støtten for brukerinteraksjoner og deling av arbeid og data. Dette aspektet involverer sanntidsoppdateringer av brukerhandlinger, samarbeid, deling og rolleoppgaver, samt en måte å diskutere og kommentere plattformen på.
15. Dokumentasjon på plattformen
En dataplattform brukes til å implementere en høy grad av tilpasset kompleksitet med en rekke brukere over en lengre periode. Dette krever detaljert dokumentasjon av det brukerleverte innholdet. Her vurderer vi hvordan plattformene støtter denne oppgaven. Dokumentasjon kan alltid utarbeides utenfor plattformen, men dette innebærer en risiko for informasjonsavvik da ekstern dokumentasjon raskt blir utdatert.
16. Brukerdokumentasjon
Dataplattformer krever en viss grad av brukerferdigheter. Riktig dokumentasjon som beskriver plattformfunksjonene er derfor nødvendig for profesjonell bruk av plattformen.
17. Sikkerhet
Sikkerhet for dataplattformer kan skilles i sikkerhet for lagring, interaksjon (data i transport) og tilgangskontroll.
18. Kostnader
Det finnes tre store kostnadsdrivere for en dataplattform:
- Lisenser
- Infrastruktur (maskinvare)
- Personale
I dag kan det meste av programvarestakken implementeres i høy kvalitet ved hjelp av åpen tilgangsprogramvare. Lisensiert programvare krever imidlertid vanligvis mindre vedlikehold og system på lavt nivå.
Maskinvare kan brukes av skyleverandører på en betal-per-bruk-basis. Det samme gjelder også infrastruktur for lagring. For å estimere maskinvarekostnadene dine, må du vurdere en infrastruktur som dekker følgende komponenter:
- Database
- Datatransformasjoner
- Analyse
- Data Science
- Automasjon
- Overvåkning
- Lagring av innhold
Selv om databasen vanligvis er den største komponenten i en dataplattform, er den langt ifra den eneste.
Konklusjon
Listen, utviklet av Medium, med 18 kriterier gir et grunnleggende utgangspunkt for å evaluere dataplattformer når det gjelder deres egenhet som langsiktige håndterbare dataplattformer. Disse kriteriene er primært relevante for organisasjoner som tar sikte på å samle lengre datahistorikker for mer omfattende statistikk og prognoser.