Video: Frukostseminarium 160512: BI som skapar ett agerande i linje med strategin. På riktigt. 2024
Det finns tvingande skäl att SQL har visat sig vara elastisk. IT-industrin har haft 40 års erfarenhet av SQL, eftersom den först utvecklades av IBM i början av 1970-talet. Med ökningen av antagandet av relationsdatabaser på 1980-talet har SQL sedan dess blivit en standard färdighet för de flesta IT-proffs.
Du kan enkelt se varför SQL har varit så framgångsrik: Det är relativt lätt att lära sig, och SQL-frågor är ganska läsbara. Denna lätthet kan spåras tillbaka till en kärndesignpunkt i SQL - det faktum att det är ett deklarativt språk, i motsats till ett imperativt språk.
För att ett språk ska vara deklarativt betyder att dina frågor endast handlar om vilken typ av data som begärs. Det borde helst inte vara något i din fråga som bestämmer hur behandlingen bör utföras. Med andra ord, allt du anger i SQL är vilken information du vill ha tillbaka från systemet - inte hur man får det.
I motsats till, med ett imperativt språk (C, till exempel, Java eller Python) består din kod av instruktioner där du definierar de åtgärder du behöver för att systemet ska kunna utföras.
Förutom de lättanställda färdigheterna hos dina SQL-vänliga IT-proffs har decennier av databasprogram också byggts med SQL-gränssnitt. När vi talar om hur Hadoop kan komplettera datalagret är det tydligt att organisationer lagrar strukturerad data i Hadoop. Och som ett resultat kommer de att köra lite av deras befintliga applikationslogik mot Hadoop.
Ingen vill betala för ansökningar omskrivas, så ett SQL-gränssnitt är mycket önskvärt.
Med utvecklingen av SQL-gränssnitt till Hadoop-data är en intressant trend att kommersiella affärsanalyser och datahanteringsverktyg nästan hoppar på Hadoop-vagnen, inklusive rapportering av företagsinformation, statistiska paket Utdrag, transformera och ladda ramar (ETL); och en mängd andra verktyg. I de flesta fall är gränssnittet till Hadoop-data Hive.
