En dataplatform er ikke en database. Databaser udgør grundlaget for dataplatforme, men giver dig ikke muligheden for at håndtere analyser. En dataplatform fungerer derimod som et ekstra lag oven på en database, som er optimeret til netop dette formål. Virksomheder har brug for effektive og langsigtede dataarkitekturer for at understøtte arbejdet med at holde sig opdateret på nutidens datarelaterede udfordringer. Lad os se nærmere på de funktionaliteter, der kræves for at opretholde en dataplatform.
Hvad er en dataplatform?
Først og fremmest er en dataplatform en tjeneste, der gør det muligt for dig at indsamle, behandle, gemme, få adgang til, analysere og præsentere data. Vi kan opdele det i følgende dele:
Data warehouse: Indsamling, behandling, opbevaring, adgang
Intelligens: analyse og præsentation
Data Science: statistik og kunstig intelligens
Opbevaring og behandling af data er selve kernen i en dataplatform. Dette er dog kun begyndelsen. For at skabe et overblik over de mest almindelige datahåndteringsopgaver har Medium samlet en liste over 18 kriterier, der viser, hvad en dataplatform indebærer:
1. Dataarkitektur (infrastruktur, skalering, database)
2. Import af grænseflader
3. Datatransformation (ETL)
4. Performance
5. Procesautomatisering
6. Overvågning
7. Datahistorik
8. Dataversionering
9. Surrogate Key Management
10. Analyse / rapportering
11. Data Science
12 . Ekstern adgang / API
13. Brugervenlighed
14. Flerebruger-proces
15. Dokumentation på platformen
16. Dokumentation
17. Sikkerhed
18. Omkostninger
Nedenfor giver vi dig en kort introduktion til hver af disse kriterier uden at gå ind i tekniske detaljer.
1. Dataarkitektur (infrastruktur, skalering, database)
Dataarkitekturen er et centralt aspekt i en dataplatform. For at finde en passende lagrings- og databaseløsning, der opfylder dine behov, kan du vælge mellem tre grundlæggende muligheder:
Relationsdatabase
Ældre databasesystemer med indbygget intelligens til effektiv håndtering af store datasæt har de mest udtryksfulde analyseværktøjer. Disse systemer er dog mere komplekse at vedligeholde. I dag findes de også som distribuerede systemer, der kan håndtere ekstremt store datasæt. Eksempler inkluderer PostgreSQL med Citus eller Greenplum klyngeløsning, MariaDB / MySQL med Galera Cluster, Amazon Redshift, Oracle, MSSQL osv.
NoSQL Sharding Database
Disse systemer er også designet til at håndtere ekstremt store datasæt og ofrer nogle af de klassiske egenskaber ved relationsdatabaser for at få mere kraft på andre områder. De tilbyder mindre analytisk kraft, men er lettere at administrere, har høj tilgængelighed og muliggør enkel backup. Eksempler er Cassandra, Hadoop Ecosystem, Elasticsearch, Druid, MongoDB, Kudu, InfluxDB, Kafka, neo4j, Dgraph osv.
Filbaserede systemer
Det er muligt at designe en strategi, der udelukkende er baseret på filer. Filstrukturer som Parquet giver dig mulighed for at bruge rimelig lagringsplads til at håndtere meget store datasæt fordelt på flere lagringsnoder eller i en Cloud Object Store som Amazon S3. Den største fordel er, at datalagringssystemet alene er tilstrækkeligt til at svare på dataspørgsmål.
Når du leder efter software, der understøtter din dataarkitektur, har du nogle få grundlæggende muligheder:
a. Du kan bygge din platform og stole på tjenester, der tilbydes af store cloud udbydere. På cloud-platforme som AWS, Azure eller Google Cloud kan du kombinere et udvalg af enkle tjenester for at oprette en dataplatform, der dækker de nævnte kriterier. Dette kan virke simpelt og billigt i lille skala, men kan være komplekst og dyrt, når du skalerer op og skal tilpasse.
b. Der er også platforme, der er baseret på egenstyring af hardware, herunder virtuelle maskiner i skyen og individuelle programvarestakke. Her har du maksimal fleksibilitet, men du skal også tage højde for mange af kriterierne på listen ved at skabe kode og tilpassede løsninger.
2. Ydelse
Dette er et nøglekriterium, når du vælger en platform. Ydelsen påvirkes primært af det databasesystem, du vælger. En tommelfingerregel er: Jo højere ydelseskrav, desto mere specialiseret bør dit valg af databasesystem være.
3.Datatransformation (ETL)
Data, der importeres til en dataplatform, skal normalt gennemgå nogle transformationer, før de kan bruges til analyse. Denne proces kaldes traditionelt ETL (Extract, Transform, Load). ETL gør det muligt for virksomheder at indsamle data fra flere kilder og konsolidere dem til et enkelt, centraliseret sted.
Datatransformation handler om ændring og tilrettelæggelse af data fra forskellige kilder, så de bliver lettere at bruge til andre formål. Dette kan være data fra kilder som ERP- og CRM-systemer, Excel-ark osv. Et typisk formål kan være rapportering og analyse, hvor vi efter datatransformation lægger data i et dataware house på en måde og i et format, der gør det lettere at rapportere og analysere på data, gerne på tværs af forskellige fagsystemer.
Dette er den mest tidskrævende opgave i ethvert datamiljø, og i de fleste tilfælde tager denne opgave op til 8 0% af den samlede tid. Større datalagre kan indeholde tusindvis af ETL-processer med forskellige stadier, afhængigheder og behandlingssekvenser.
4. Import af grænseflader
Vi kategoriserer dette i fire forskellige sektioner:
- Filer: Filer er stadig den mest almindelige form for data i dag.
- Web services: Mange webtjenester med relevante data er tilgængelige online.
- Databaser: Selvom mange organisationer gemmer deres data i traditionelle databaser, er direkte databaseadgang i de fleste tilfælde ikke eksponeret for internettet og er derfor utilgængelig for cloud data-platforme.
- Sanntidsstrømme: “Real-time streams” som leveres af meldingsrutere (som WAMP, MQTT, AMQP osv.) er stadig underudnyttede i dag, men får stadig større betydning med stigningen af IoT.
5. Procesautomatisering
Når du har mange kilder, mål og flere datatransformationsprocesser, har du også mange afhængigheder. Automatisering af processer er en del af enhver dataplatform og involverer en række processer med høj kompleksitet. Til planlægning af processer er der dedikerede værktøjer som Apache Airflow, Automate, Control-M eller Luigi.
6. Overvågning (monitorering)
Større datalagersystemer kan nemt indeholde hundreder af tabeller med hundreder af automatiserede ETL-processer, der styrer dataflowet. Fejl undervejs er næsten uundgåelige, og mange af disse fejl skal håndteres manuelt. For at kunne overvåge platformens processer er der behov for en løsning.
7. Datahistorik
Behovet for at administrere en længere historik med data er en del af kernen i enhver dataplatform. Selve opgaven for et datalager kan opsummeres som at samle separate dele af data til en homogen datahistorik.
Da data naturligt genereres over tid, vil der opstå et behov for at supplere et eksisterende datalager med nye data. Tekniske tidsintervaller spores i tabeller ved hjælp af dedikerede kolonner til dette. Datahistorisering er en effektiv måde at styre disse tidsintervaller på, når nye data tilføjes. Datahistorisering adskiller sig fra dataversionering, idet datahistorisering fokuserer på reelle tidsstempler, mens versionering typisk handler om tekniske indsættelsestidspunkter.
8. Dataversionering
Ved at versionere data kan du spore datakorrigeringer over tid og senere gendanne gamle analyser. Versionering giver dig mulighed for at anvende ikke-destruktive korrektioner på eksisterende data. Når du sammenligner versioneringsfunktioner, skal du overveje, hvor let det er at oprette versioner, samt hvor nemt det er at gendanne eller forespørge versioner.
Versionering kan håndteres på forskellige systemniveauer:
- Tage snapshots på lager-subsystemet (svarende til sikkerhedskopier)
- Det underliggende databasesystem kan understøtte versionssporing
- Versionering kan håndteres af datalagersystemet
- Versionering kan implementeres som en tilpasset transformationslogik i brugerområdet
9. Surrogatnøglehåndtering (surrogatnøgler)
Dataplatforme bruges til at konsolidere data fra mange kilder med forskellige identifikatorer for de respektive objekter. Dette skaber behovet for nye nøgleområder for de importerede objekter og nødvendigheden af at opretholde dem ved efterfølgende import. Disse nye nøgler kaldes surrogatnøgler. At oprette og vedligeholde disse nøgler effektivt er ingen let opgave.
10. Analyse/rapportering
Formålet med en dataplatform er at forberede rådata til analyse og lagre disse data for at kunne se historik. Analyser i en sådan platform kan udføres på flere måder.
En række Business Intelligence-værktøjer fokuserer udelukkende på opgaven med at skabe analytiske og menneskeligt læsbare dataudtræk. For at forberede data til præsentation giver en dataplatform funktioner til at oprette dataudtræk og aggregater fra større datalagre.
At besvare specifikke forretningsspørgsmål ved hjælp af intelligente forespørgsler i datalagrene kræver brugerfærdigheder i analytiske forespørgselssprog. BI-værktøjer har til formål at forenkle disse opgaver ved at tilbyde et peg-og-klik-grænseflade til at besvare grundlæggende spørgsmål som "antal besøgende per måned i butikken" eller "samlet omsætning i region X". Disse værktøjer gør det også muligt for brugere at visualisere information via omfattende grafik.
I næsten alle tilfælde vil superbrugere stadig have mulighed for at omgå disse værktøjer og udføre deres egne forespørgsler. Eksempler på populære BI-værktøjer inkluderer blandt andet Tableau, Qlik, Looker, Chartio og Superset.
11. Data Science
Træning af maskinlæringsmodeller er et krav, som nutidens dataplatforme skal kunne levere. De mest sofistikerede metoder implementeres ikke ved hjælp af SQL, men ved brug af Python eller R sammen med et bredt udvalg af specialiserede biblioteker såsom NumPy, Pandas, SciKit Learn, TensorFlow, PyTorch eller endnu mere specialiserede biblioteker til NLP eller billedgenkendelse.
Da disse opgaver ofte er beregningsmæssigt krævende, er det ofte nødvendigt med ekstra hardware ud over den eksisterende analyseinfrastruktur.
12. Ekstern adgang / API
Alle de indsamlede data på platformen skal bruges til forskellige formål. Mulige kanaler, der overvejes her, er:
- SQL-adgang til direkte analyse, herunder via BI-værktøjer
- API-adgang (REST-forespørgsel) som en tjeneste til websites eller apps
- Notifikationer via SMS/e-mail til slutbrugere eller administratorer
- Fil-eksport til videre behandling eller datalevering til andre parter
13. Brugervenlighed
Brugervenligheden af platformen afhænger af målgruppen. Hovedudfordringen er, hvor nemt det er at oprette og administrere objekter (såsom brugere, datalagre, tabeller, transformationer, rapporter osv.) på platformen.
Ofte må man afveje brugerens kontrolniveau mod platformens brugervenlighed. Her skal vi skelne mellem platformens funktionalitet og det brugergenererede indhold.
I de fleste tilfælde kræver brugergenereret indhold brug af kode, da datateknik og analyse er komplekse områder, der kræver et højt udtryksniveau.
14. Flerebrugerproces
Denne kategori evaluerer støtten til brugerinteraktioner og deling af arbejde og data. Dette aspekt involverer realtidsopdateringer af brugerhandlinger, samarbejde, deling og rollefordeling samt en mulighed for at diskutere og kommentere på platformen.
15. Dokumentation på platformen
En dataplatform bruges til at implementere en høj grad af tilpasset kompleksitet med en række brugere over en længere periode. Dette kræver detaljeret dokumentation af det brugergenererede indhold.
Her vurderer vi, hvordan platformene understøtter denne opgave. Dokumentation kan altid udarbejdes uden for platformen, men dette indebærer en risiko for informationsafvigelser, da ekstern dokumentation hurtigt kan blive forældet.
16. Brugerdokumentation
Dataplatforme kræver en vis grad af brugerfærdigheder. Korrekt dokumentation, der beskriver platformens funktioner, er derfor nødvendig for professionel brug af platformen.
17. Sikkerhed
Sikkerhed for dataplatforme kan opdeles i sikkerhed for lagring, interaktion (data i transport) og adgangskontrol.
18. Omkostninger
Der er tre store omkostningsdrivere for en dataplatform:
- Licenser
- Infrastruktur (hardware)
- Personale
I dag kan det meste af softwarestakken implementeres i høj kvalitet ved hjælp af open source-software. Licenseret software kræver dog normalt mindre vedligeholdelse og system på lavt niveau.
Hardware kan benyttes af skyudbydere på en betal-per-brug-basis. Det samme gælder for infrastruktur til opbevaring. For at estimere dine hardwareomkostninger skal du overveje en infrastruktur, der dækker følgende komponenter:
- Database
- Datatransformationer
- Analyse
- Data Science
- Automatisering
- Overvågning
- Lagring af indhold
Selvom databasen normalt er den største komponent i en dataplatform, er den langt fra den eneste.
Konklusion
Listen, udviklet af Medium, med 18 kriterier giver et grundlæggende udgangspunkt for at evaluere dataplatforme i forhold til deres egenskaber som langsigtede håndterbare dataplatforme. Disse kriterier er primært relevante for organisationer, der har til formål at samle længere datahistorikker til mere omfattende statistik og prognoser.
Dataplatforme
Tænk, hvis dine data altid kan svare dig på, om der er fare for nedetid, hvad dine kunder savner, og hvor mange timer du kan frigøre til innovation. Med en moderne dataplatform i skyen får du svar med det samme.
twoday har lang erfaring med integration af data og datasystemer gennem førende business intelligence-værktøjer og moderne dataplatforme. Vi hjælper med dataindsamling, sammenstilling, kvalitetskontrol og opdateringslogik, så informationen registreres kun én gang, og resten automatiseres.
.jpg?width=2048&height=1367&name=twoday%20G%C3%B6teborg%20-%20webres%20(105%20of%20146).jpg)