Video: Sqoop Import and Export data from RDMBS and HDFS 2025
Der er overbevisende grunde til, at SQL har vist sig at være elastisk. IT-branchen har haft 40 års erfaring med SQL, da den blev udviklet af IBM i begyndelsen af 1970'erne. Med stigningen i vedtagelsen af relationsdatabaser i 1980'erne er SQL siden blevet en standard færdighed for de fleste it-fagfolk.
Du kan nemt se, hvorfor SQL har været så vellykket: Det er relativt nemt at lære, og SQL-forespørgsler er ret læsbare. Denne lethed kan spores tilbage til et kerneudformingspunkt i SQL - det faktum, at det er et deklarativt sprog, i modsætning til et imperative sprog.
Hvis et sprog er declarative, betyder det, at dine forespørgsler kun omhandler arten af de data, der anmodes om - ideelt set bør der ikke være noget i din forespørgsel, der bestemmer hvordan behandlingen bør udføres. Med andre ord, alt du angiver i SQL er, hvilke oplysninger du vil have tilbage fra systemet - ikke hvordan man får det.
I modsætning til, med et imperative sprog (C, for eksempel, eller Java eller Python) består din kode af instruktioner, hvor du definerer de handlinger, du har brug for systemet til at udføre.
Udover de SQL-venlige IT-professioners (nemt gearede) færdigheder er der også blevet bygget tiår af databaseprogrammer med SQL-interfaces. Når man taler om hvordan Hadoop kan supplere datalageret, er det klart, at organisationer vil gemme strukturerede data i Hadoop. Og som følge heraf løber de nogle af deres eksisterende applikationslogik mod Hadoop.
Ingen ønsker at betale for applikationer, der skal omskrives, så en SQL-grænseflade er yderst ønskelig.
Med udviklingen af SQL-grænseflader til Hadoop-data er en interessant tendens, at kommercielle forretningsanalyser og datahåndteringsværktøjer næsten hopper på Hadoop-vognen, herunder business intelligence-rapportering; statistiske pakker; Uddrag, transformere og indlæse rammer (ETL); og en række andre værktøjer. I de fleste tilfælde er interface til Hadoop data Hive.
