Lag 1 av Big Data Stack: Sikkerhetsinfrastruktur - dummies

Sikkerhets- og personvernkrav, lag 1 i den store datastakken, ligner til kravene til konvensjonelle datamiljøer. Sikkerhetskravene må være nøye tilpasset spesifikke forretningsbehov. Noen store utfordringer oppstår når store data blir en del av strategien:

• Datatilgang: Brukertilgang til rå eller beregnede store data har omtrent samme tekniske krav som ikke-store dataimplementeringer. Dataene skal kun være tilgjengelige for de som har et legitimt forretningsbehov for å undersøke eller interagere med det. De fleste kjerneplattformene for datalagring har strenge sikkerhetsordninger og forsterkes med en føderert identitetsfunksjon, og gir passende tilgang på tvers av de mange lagene i arkitekturen.

• Programtilgang: Programtilgang til data er også relativt enkel fra et teknisk perspektiv. De fleste programmeringsgrensesnitt (APIer) gir beskyttelse mot uautorisert bruk eller tilgang. Dette beskyttelsesnivået er trolig tilstrekkelig for de fleste store dataimplementeringer.

• Datakryptering: Datakryptering er det mest utfordrende aspektet av sikkerhet i et stort datamiljø. I tradisjonelle miljøer, krypterer og dekrypterer data virkelig systemets ressurser. Dette problemet forverres med store data. Den enkleste tilnærmingen er å gi mer og raskere beregningsevne. En mer temperert tilnærming er å identifisere dataelementene som krever dette sikkerhetsnivået og krypterer bare de nødvendige elementene.

• Trusselsdeteksjon: Inkluderingen av mobile enheter og sosiale nettverk øker eksponentielt både mengden data og mulighetene for sikkerhetstrusler. Det er derfor viktig at organisasjoner tar en multiperimeter tilnærming til sikkerhet.

Så, fysisk infrastruktur gjør at alt og sikkerhetsinfrastruktur beskytter alle elementene i ditt store datamiljø. Det neste nivået i stabelen er grensesnittene som gir toveis tilgang til alle komponentene i stabelen - fra bedriftens applikasjoner til datafeed fra Internett.

En viktig del av utformingen av disse grensesnittene er å skape en konsistent struktur som kan deles både inne og kanskje utenfor bedriften, samt med teknologipartnere og samarbeidspartnere.

I flere tiår har programmerere brukt APIer for å gi tilgang til og fra programvareimplementeringer. Verktøy- og teknologileverandører vil gå langt for å sikre at det er en relativt enkel oppgave å lage nye applikasjoner som bruker sine produkter.Selv om det er veldig hjelpsomt, er det noen ganger nødvendig for IT-fagfolk å lage egendefinerte eller proprietære APIer eksklusive til selskapet.

Det kan hende du må gjøre dette for konkurransefortrinn, et behov som er unikt for organisasjonen din, eller noen andre virksomhetsbehov, og det er ikke en enkel oppgave. APIer må være godt dokumentert og vedlikeholdt for å bevare verdien til virksomheten. Av denne grunn velger enkelte selskaper å bruke API-verktøy for å få en start på denne viktige aktiviteten.

API-toolkits har et par fordeler over internt utviklede APIer. Den første er at API-verktøyene er produkter som er opprettet, administrert og vedlikeholdt av en uavhengig tredjepart. For det andre er de designet for å løse et bestemt teknisk krav.

Store data utfordringer krever en litt annen tilnærming til API utvikling eller adopsjon. Fordi mye av dataene er ustrukturert og genereres utenfor kontrollen av virksomheten din, oppstår en ny teknikk, kalt Natural Language Processing (NLP), som den foretrukne metoden for grensesnitt mellom store data og dine applikasjonsprogrammer.

NLP lar deg formulere spørringer med naturlig språk syntaks i stedet for et formelt spørrespråk som SQL. For de fleste store datateknologier vil det være mye lettere å spørre "List alle giftige mannlige forbrukere mellom 30 og 40 år gammel, som bor i det sørøstlige USA og er fans av NASCAR" enn å skrive en 30-linjers SQL-spørring for svaret.

Fordi de fleste datainnsamling og bevegelse har svært liknende egenskaper, kan du designe et sett av tjenester for å samle, rense, transformere, normalisere og lagre store dataposter i lagringssystemet du ønsker.

For å skape så mye fleksibilitet som nødvendig, kan fabrikken kjøres med grensesnittbeskrivelser skrevet i Extensible Markup Language (XML). Dette abstraksjonsnivået gjør at bestemte grensesnitt kan opprettes enkelt og raskt uten at det må bygges spesifikke tjenester for hver datakilde.

I praksis kan du lage en beskrivelse av SAP eller Oracle applikasjonsgrensesnitt ved hjelp av noe som XML. Hvert grensesnitt vil bruke samme underliggende programvare for å migrere data mellom det store datamiljøet og produksjonsprogrammiljøet uavhengig av spesifikasjonene til SAP eller Oracle. Hvis du trenger å samle data fra sosiale nettsteder på Internett, vil øvelsen være identisk.

Beskriv grensesnittene til nettstedene i XML, og bruk deretter tjenestene for å flytte dataene frem og tilbake. Vanligvis dokumenteres disse grensesnittene for bruk av interne og eksterne teknologer.