A Google BigQuery már a spájzban van – és ehető (Esettanulmány)

Olvasási idő: 5 perc

Üzleti analitika egy performanciára optimalizált BigQuery adatbázison? A Google felhőalapú adattárolása veszi az akadályokat. 

A jelenlegi Google BigQuery esettanulmány egy közelmúltban befejezett analitikai projektünk technológiai tapasztalatait mutatja be. A felhőalapú adatvagyon kiaknázásnak lelkesen, de kellő szkepticizmussal futottunk neki. A projekt során azonban gyorsan túlsúlyba kerültek a pozitív élmények. A BigQuery architektúra segítségével valóban egyszerű több ezer Gbyte adatból üzletileg is értékes és változatos outputot generálni alig észrevehető válaszidő alatt. 

BigQuery üzleti szemmel

Alkalmazhatósági szemszögből megközelítve, a Google Cloud Platform big data szolgáltatásai között található BigQuery-hez fűződően a következő fő pozitívumokat lehet megfogalmazni: (1) villámgyors lekérdezések több száz, több ezer Gb adatmennyiségeken, (2) magas szintű integráltság Google ökoszisztémán belül és külső szoftverekkel, valamint (3) optimális adattárolási módszer, mely egyszerre próbál megfelelni az áttekinthetőség és redundancia-mentesség feltételeinek. A technológia gyorsan tanulható (4) és végül de nem utolsósorban, a BigQuery adattárolás valóban költséghatékony tud lenni (5). Ezen üzleti előnyöket talán nem is szükséges részletezni, hiszen alapvetően ezt ígéri a felhőalapú technológia, és ígéreteit többnyire be is váltja.

Természetesen az éremnek mindig két oldala van, ugyanakkor a másik oldalhoz nem feltétlen a “negatívumok” jelző illik, sokkal inkább az, hogy a Google BigQuery másfajta szemléletmódot igényel, mint a hagyományos adattárolási és kiaknázási technikák. Az eddigi projektek tapasztalatai azt mutatják, hogy a hagyományos technológiákhoz szokott szakembereknek kell egyfajta ráhangolódás a projekt kezdeti szakaszában. Az egyik ilyen megszokottól eltérő működés a termék árazása. Az árazás jól dokumentált, a használat jól skálázható, de mégis nehezen becsülhető előre. Mivel a költségek dinamikusan képződnek az adatok tárolásával és eljárások futtatásával, a fejlesztőktől kezdve az egész BigQuery alapú projektre jellemző lehet egy költségoptimalizálási nyomás. Ez egy analitikai projekt esetén olykor jelentősebb kihívás lehet az elemzési projektekre jellemző iteratív, agilis működés miatt; a feltárástól kezdve minden lekérdezésnek és minden újonnan eltárolt táblának ára van. Az árazás tervezése kis projektnél kis gond, nagy projektnél nagy gond.

Az árképzésnek van egy másik fontos tényezője is, ez pedig az ár fejlesztési idővel keletkezett kapcsolata. Egy lekérdezést ugyanis nem elég jól megírni, nem elég az sem hogy gyorsan fusson le, hanem az is szempont hogy olcsón fusson le. Ez természetesen akkor hangsúlyos igazán, ha egy lekérdezés utána üzembe és gyakori használatba kerül, tehát PoC fázisban kicsit szabadabb kezelhető, de később a körültekintő optimalizálás nem megúszható.  A lekérdezések “olcsósítása” szintén az új szemléletmód része,  érdemes már az adatbázis tervezésekor is és minden egyes programsor beírásánál figyelembe venni a költségtényezőt. Szerencsére a Google számos lehetőséget biztosít a költségek optimalizálására, és ezekkel bizony élni is érdemes a hatékony projekt érdekében.

Összességében azonban a szemléletmód elsajátítása megtérülő. Minimális induló költséggel lehet adatbázist kialakítani, és kiaknázni, azonban idő és tapasztalat kérdése, hogy a költség alapú megfontolások reflex szerűvé váljanak. Szerencsére nagyon hasonló feladat egy hagyományos környezetben, vagy mezei laptopon elemezni, hiszen ekkor általában a futtatási idő jelenti a szűk keresztmetszetet, ezért ez többé-kevésbé hangsúlyos tényező más környezetben is. 

A BigQuery szolgáltatás

A Google Cloud Platform (GCP) jelenlegi 6 különböző szolgáltatási köre (Computing & Hosting, Storage, Databases, Networking, Big Data és Machine learning) közül a BigQuery a Big Data kategóriába tartozik. A szolgáltatás célja, hogy a felhőben tárolt, ’big data jellegű’ adatokat egy a GCP által fejlesztett környezeten belül lehessen feldolgozni, lekérdezni és elemezni. Ehhez a BigQuery egy SQL nyelvet felhasználó platformot kínál, mely a Google kapacitásaira és technológiájára támaszkodva teszi lehetővé a hatalmas mennyiségű adatokat olvasó lekérdezések másodperceken belüli lefuttatását. A szolgáltatás három felhasználói felületet biztosít: (1) webes felület, (2) parancssori működtetés vagy (3) REST API használata más programnyelvekről, mint a Python vagy a Java. 

A BigQuery kulcseleme – A RECORD adattípus

A közismert SQL séma elemek mellett a BigQuery behoz egy új adattípust (RECORD) és egy új adat-restrikciót (REPEATED). A BigQuery úgynevezett STRUCT-okkal dolgozik, melyek olyan tömb jellegű elemek, melyek különböző típusú mezőket is tartalmazhatnak (lehet szöveg, szám, dátum, boolean, stb.). Ehhez hasonló adattárolási logika más adatbázis-kezelőkben is megjelenik, de a BigQuery erre a rendszerre nagyon hangsúlyosan támaszkodik.

Ez a BigQuery egyik legnagyobb erőssége, hiszen egyetlen táblában tartalmaz tömbösített módon adatokat, melyek így kvázi pre-join állapotban vannak és, amint kibontásra kerül a STRUCT bármely mezője, a tömbök minden eleme az adattábla összes többi mezőjével kapcsolódik.

A BigQuery optimális adattárolása tehát abban is megmutatkozik, hogy minimális szinten tartja a sorok számát, amennyiben viszont egyszerre több STRUCT-ot szükséges kibontani, minden tömbelem párosul minden tömbelemmel, mellyel a sorszám akár hatványozódhat. Az új típusú mező (REPEATED RECORD) segítségével a BigQuery megjeleníti a felhasználónak az egymással összefüggésben lévő adatsorokat, ugyanakkor optimálisan tárol abból a szempontból, hogy a párosításokat csakis az elemző végzi el, szükség esetén. Így, amikor a tömbös elemeket nem kell érinteni a munka során, a minimális méretű adattáblán lehet dolgozni, nem annak 10, 100, akár 1000-szeresén.

A BigQuery integrálhatósága Google ökoszisztémán belül és kívül

A  (1) GCP más szolgáltatásaival (Data Studio) való összehangolhatóságára, valamint (2) a Google-tól független termékekkel (Tableau) való összekapcsolhatóságra is érdemes kitérni. Az elemzések fontos része az eredmények vizualizálása, ez történhet időközi, gyors ábrákkal, melyek az elemzés menetét segítik, illetve összefoglaló, üzleti döntéshozatalt támogató dashboardok formájában is. 

Alap szintű adatvizualizációra használható a Google Data Studio (DS), a Google ökoszisztémának egy gyors adatvizualizáló eszköze, melyhez a BigQuery felületéről lehet csatlakozni. 

A GCP két módját is felkínálja a BigQuery-ről Data Studio-ra való csatlakozásnak: (1) teljes adattáblához és (2) konkrét lekérdezéshez. Az előbbi esetén a felhasználó megad egy – projekten és kapcsolódó adatforrásokon belüli – adattáblát. A konkrét query-hez való csatlakozás esetében a DS felületén megadható maga a lekérdezés, melyet a BQ SQL motorja a háttérben futtat, a DS pedig megkapja a lekérdezés eredménytábláját. A lekérdezés módosulása esetén a DS is friss adatokat vizualizál. Ez utóbbi módszer esetén azonban figyelembe kell venni, hogy az SQL lekérdezések minden egyes futtatása költségként jelenik meg a projekten, tehát a DS efféle használatakor érdemes észben tartani, hogy minden egyes ábra frissítésnek ára van. 

A DS tehát arra kiválóan alkalmas, hogy a GCP felületét ne kelljen elhagyni gyors ad-hoc vizualizációk esetén. 

A DS mellett arra is lehetőségünk van, hogy adatvizualizációinkat szofisztikáltabb, arra kialakított és fejlesztett környezetben – mint a Tableau, Qlik, MicroStrategy vagy SAP Analytics – kívánjuk megjeleníteni. Jelen projektünkben Tableau-t használtunk a végső dashboardjaink megjelenítésére.  Tableau esetében az összeköttetés meglehetősen kényelmes, hiszen adatforrásként BigQuery tábla is csatolható.

Összességében elmondható, hogy a BigQuery egyszerre képes megfelelni az IT rendszergazdáknak és az üzleti szereplőknek, ugyanis optimális architektúrája mellett az adatokat átolvashatóan, könnyen értelmezhetően jeleníti meg. Ugyan a gyakorlati használat során még tapasztaltunk kisebb finomításra szoruló jelenségeket, összességében a rendszer jól vizsgázott az analitikai projektünk során is. 

Szerzők:

Pertics Richárd – Business Analyst
Rábay Kristóf – Data Scientist

About Pertics Richárd

Jelenleg szoftverfejlesztőként és üzleti elemzőként tevékenykedem, körülbelül 2000 óta foglalkozom komolyabban adatokkal. Kezdetben fejlesztőként, később adatbányászként dolgoztam különböző pénzintézeti adattárházak környékén, fokozatosan közelebb kerülve az üzleti problémákhoz és egyéb szektorokhoz. A BI projektekben az üzleti és technológiai változatosságot kedvelem, de elsődlegesnek tartom a valódi üzleti problémák azonosítását, és azok hatékony, gyakorlatias megoldását.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.