Big Data News

Part II – The Anatomy of a Review

By | Big Data News | No Comments

In Part I of this series, I have outlined some general considerations that could be summarized as discussing the spirit of the review process. In this article, I shall try to dissect and show you what a review might look like in practice – we shall examine the anatomy of a review, if you will.

Practical Guidelines for good reviews

Have a formal checklist

While I have stressed the informal part of a review more in Part I, it can help tremendously if the team can come up with a list of todos regarding every review. This checklist can then be referenced during every review. This should be an organic, ever-evolving list: if the team finds that certain items on the list become obsolete or want to add new ones, the checklist can and should be changed. Below are examples of what might be on such a list:

  • read the user story together at the beginning of a review
  • the reviewer should check out the feature branch himself and verify personally that the feature works
  • the reviewee should do a mini-demo of their feature
  • check for the existence of unit tests
  • changes conform to our code standards (linting, naming conventions, etc)

What’s the ideal review size?

Ideally, reviews should be as small as possible, while still dealing with a standalone, self-contained increment. Even if the changes will eventually be deployed along with some other changes (e.g. because a user story needs multiple changes to happen to function properly), these changes can and should be reviewed separately. If it makes sense, you can have mid-feature reviews for the same user story – and with each additional review, you should focus on the new changes, naturally.

How long should a review last?

In my humble opinion, it is more useful to have a minimum length rather than a maximum length for reviews – especially when a team first embarks on having a more formalized review process. My recommendation is thus that the team should spend at least 15 minutes discussing the changes – even if they think the changes are trivial, more often than not when examined deeper it can prove to have more depth than one had first expected.

Over the long term, the team should try to anticipate and estimate how long a review process is expected to take for each user story. This obviously depends on a lot of variables (like feature size and number of people that need to be involved) – and also on whether or not the changes are approved or rejected -, but by thinking about the review step consciously during the estimation steps, this uncertainty can become more manageable. It also helps to have an explicit subtask for the review step that automatically gets created for each user story, so as to remind everyone during estimation that the review process will take time and to enable people to log their hours during development.

How many reviewers should there be?

Obviously, there should be at least 2 participants – the reviewee, and the reviewer. More are quite welcome, though: as long as they feel like they can actively participate and add to the conversation. If the changes in question are relevant for everyone, it might make sense to have an “all hands on deck” review as well (but those instances are generally rare).

Two things to note here:

  • If you find that there is an overabundance of very active developers that want to be there for all the reviews, and you note that this is detrimental towards other development efforts, then first of all, you should tap yourself on the shoulders for having such engaged devs, and second, feel free to specify a max amount for people in each review.
  • As a reviewer, it is completely acceptable to not stay for the entire length of the review. If you feel like you have exhausted your usefulness – have provided the best comments that you could, gave feedback you could, and/or are unable to participate according to the spirit of the process – feel free to say bye and log off. Just don’t forget to approve or disapprove based on what you saw.

Where should the review take place?

Ideally, reviews should be done synchronously – by that I mean “in person”, or “online in a meeting”. Reason for this is that reviews should facilitate two-way communication, and some of the best results can only happen in this sort of environment. Every member of the team should know when reviews take place, and participation should be easy and open for anyone. This might be the most controversial of my takes, because developers tend to be more introverted, and some might find this to be slightly outside their comfort zone. Barring some insurmountable obstacles like huge time zone differences however, this is indispensable for the process to work well.

Common objections

Finally, let’s discuss some common objections one might have when first introducing regular reviews. I found the following two to be the most salient:

1. “We don’t have enough time!”

The problem with this argumentation is that it basically proposes that you can actually save time by skipping this step – but the exact opposite is true.

First of all, errors caught during the review step cost way less time and money to fix than anywhere later in the development cycle. Fixing a bug in production will at the very least involve creating a ticket, writing a ticket description, pulling a dev off of something else they could be working on, having them investigate the issue, then hopefully once they have identified it, fixing it, then waiting for the next deploy cycle to happen till it can be fixed. And speaking of which, would you rather have an end user or a client find the issues, or one of your devs?

Second, in any ongoing development effort, there will come a point where someone will have to work on part of the code that they have not written themselves. When (not if!) this happens, they will have to spend a lot of time doing codewalks with the original author(s) anyway – and God help you if they aren’t available anymore, in which case you can expect to have tickets called “Code Archeology – 3 days” pop up on your board, just so people can understand what certain parts of your codebase are doing.

2. “Noone else can really understand, and thus, review my code”

It might happen that there is only one person on the team who is an expert in one particular field – especially if they are a senior in their field. If this is the case, it is tempting to let them roam free, and accept that there is just no way to feasibly review their changes – after all, they are an expert.

This approach, however, would be a fatal mistake. Even if the colleague in question writes flawless code, this should raise all sorts of alarm bells. A single point of failure such as this can eventually have disastrous consequences if said colleague decides to leave the company (or just goes on extended vacation or falls sick).

Instead of this, have someone else from the team, preferably someone who is open to learn something new, review their code nonetheless. Even if the reviewer will at first add little more value than being a rubber duck in the review meeting (which can be surprisingly useful in and of itself), they will end up asking a lot of questions and eventually, you will find that you now have 2 people on the team who can handle that particular field. If this is your situation, consider giving the second dev the easier tasks as they come along, and have them actively develop one part to speed up the onboarding process.

The importance of getting everyone onboard

Ultimately, the biggest hurdle you might face when trying to kickstart a healthy review culture is from within the team itself. If any one on the team does not see the value of a review, they will fail to conscientiously apply themselves at it, and will ultimately undermine the process at every turn. That’s why it is important to talk this over with everyone, explain how this will benefit them personally and the project as a whole, and assuage any unrealistic expectations or fears they might have (e.g. unrealistic fears of potential repercussions for failing the review process). Ideally, have everyone actively participate in creating the review process, so they themselves can own it and apply it for their own benefit.

In conclusion, having a review process for code changes is crucial for the success of any development team. In this article, I have outlined some guidelines for a healthy review process, and tried to address a few common objections I have encountered. (If you have some other objections that you have heard, feel free to drop me an email – I’m genuinely interested!)

I hope by this point you can plainly see that the benefits of having a thorough review process far outweigh any perceived time constraints or inconveniences, and by utilizing it, development teams can improve code quality, communication, and ultimately, project success.

Part I – The relevance of a review

By | Big Data News | No Comments

Review Series

On numerous occasions I had to make a case for reviews as I had to introduce them as standard procedure to teams that wanted to improve them. I have decided to put my thoughts on the matter to writing, in the hopes that it might be helpful for others as well.

In Part I of this series, I shall discuss some general guidelines that are useful to keep in mind when trying to foster a healthy reviewer culture. In Part II, I will discuss a more operational breakdown of how reviews might look like in practice.

Part I – The Purpose of a Review

Catch bugs/errors sooner, identify improvement possibilities earlier

The sooner you catch an error in the production cycle, the easier, quicker, and ultimately cheaper it is to fix it. No bug report needs to be filed, no ticket prioritization needs to take place, no investigation into the nature of the bug needs to occur, no need to redeploy. 

A quicker feedback loop is desirable in any case, but moving this first feedback to before the code is even considered “done” by the team is even better.

Share knowledge

How many times has it happened that you got stumped with your work, only to later discover that the cause of your problems were some changes in the codebase that you had no idea about?

The review session is a fantastic opportunity for the team to get on the same page regarding the ever ongoing development effort. While dailies may give a general idea about the ongoing features, they are generally not enough to grasp the changes within the codebase. The aim should not just be to accept or reject the changes – by actively participating in a review as much as possible, we can hit two birds with one stone: the changes end up being more familiar, and it fosters a general sense of code ownership, which is imperative for a good product. 

How many reviewers should there be

The question then quickly arises – how many reviewers should there be? Clearly, there’s a balance, but generally speaking, we can say that the more active reviewers there are, the better. The review process’ benefits will start to multiply with the number of participants. However, active is the operative word here: the aim is not to have a dozen of developers silently zone out in an hour-long meeting, but rather to have as much back-and-forth between the participants as possible. We will go into more details about the operative parts in Part II.

Formal, recurring timeslot for technical debates

Having an explicit timeslot where developers can discuss technical debates can be very useful. Newly discovered tricks and tips can be shared, new tools can be brought up, and team members can get an opportunity to sync their understanding about the mid-to-long term direction in which the project is going. Therefore, it is encouraged to go above the narrow scope of the code changes at hand, and discuss how they impact the product altogether. It can also function as an early warning system for situations where upcoming requirements might need extra work in the already existing codebase.

(Note that the aim here should not be to come up with new user stories – the review should still aim to answer implementational, technological questions.)


Last but not least, frequent and thorough reviews are a godsend for junior developers. They can receive valuable feedback, ask questions they may have formulated during their efforts, and get a confidence boost that the quality of their work is up to spec.
I feel like it is worth noting 2 things here:

#1: During the review process, we are not trying to judge people, or belittle their work. We are trying to ensure that the work we release will be up to the professional standards that we expect from ourselves. It helps to explicitly separate the finished work from the person doing it – the aim is not to share blame.

#2: Even so, it is very natural to get emotionally attached to changes you have made, and precisely due to this, some reframing can go a long way: it helps if the review is not about “finding mistakes”, but rather, about trying to identify – together – with various ways how the code might be improved. Items from the thus created “Improvement Backlog” can then either be implemented in the next attempt, or be noted as technical debt / bugs to be implemented at a later date.

Final Note – The scope of the review

Above, I have encouraged you to view the review process as more than just the strict acceptance criteria of code changes. However, it is imperative to stress that the scope of the discussions should still be technical and implementational only. The aim is not to come up with new features or user stories – only deal with these inasmuch as they might impact the solution at hand and help us eventually integrate them into our already existing components.

For a more operative approach – along with some examples and details how a review might look like – check out Part II of this Review series.


Az infláció mérésének kulisszatitkai

Az infláció mérésének kulisszatitkai – Ezt kell tudnod!

By | Big Data News | No Comments

A saját bőrünkön érezhetjük a pénzünk vásárlóértékének csökkenését. Az infláció nem egy szokatlan gazdasági folyamat, ám a mértéke már több, mint egy éve szokatlanul magas, ez pedig intenzív hatással bír a mindennapjainkra. Folyamatosan emelkedő árakkal találkozhatunk az áruházak polcain a bevásárlásaink során, vagy amikor éppen valamilyen szolgáltatást veszünk igénybe. A KSH januári beszámolójából kiderült, hogy az infláció már 25,7%-ra emelkedett éves szinten hazánkban, ilyenre eddig még nem volt példa nálunk. A márciusi adatok alapján éves szinten jelenleg 25,2%-os emelkedésről beszélhetünk. Vajon ez jelentheti azt, hogy az áremelkedések elérték a csúcsot januárban és innentől csökkenésre számíthatunk?

Naponta rengeteg cikk születik az áremelkedésekről. Kulcsfontosságú a gazdaságban a mutató alakulása, de keveset tudunk arról, valójában hogyan is állapítják meg a növekedést. Mi alapján tudjuk azt mondani, hogy 36%-kal nőtt az élelmiszerek ára? Mit is értünk pontosan infláció alatt?

Az infláció számításának az alapja a fogyasztóiár-index (fogyasztói kosár), ami a háztartások saját felhasználásra vásárolt termékek és szolgáltatások időbeni árváltozását méri. Ezzel a mutatóval mérik a pénz romlását is, hiszen az idő elteltével a pénzünkért növekedő árak mellett már kevesebb terméket tudunk megvásárolni. A fogyasztóiár-indexet figyelembe veszik az adókulcsok, a kamatlábak vagy éppen a minimálbér meghatározása során. Minden országban a statisztikai hivatalok végzik ennek számítását, és érdekesség, hogy a fogyasztói kosár tartalma országonként változik, annak érdekében, hogy országspecifikus legyen.

Szakmai körökben is erősen vitatott, hogy módszertanilag vajon helyes-e az infláció mérése. Kutatók és szakértők is megkérdőjelezik olykor a fogyasztóiár-index használhatóságát az infláció mutatójaként, hiszen ez késleltetve követi le azt, így nem kapunk aktuális képet sosem. Sokak vitatják az átlagos fogyasztói kosár tartalma is.

Hogyan történik a mérés?

Az árváltozásokat egy előre meghatározott terméklista alapján mérik. A reprezentánsok árát a KSH területi munkatársai havonta írják fel az ország településein, piacokon és egyéb helyeken. A főként online vásárolt termékek/szolgáltatások (műszaki cikk, repülőjegy stb.) árának mérését az interneten keresztül végzik a kutatók. Követelmény, hogy a fogyasztói kosár az adott havi kínálatot tartalmazza, tehát ami a meghatározott mérési periódusban nem elérhető, az nem kerül bele az aktuális fogyasztói kosárba. Igyekeznek a tényleges keresletet venni a kiválasztás alapjául, így egy-egy kategóriában a legnépszerűbb termék árát jegyzik fel.

Nem elhanyagolható analitikai szempontból az összehasonlíthatóság sem, így 1992-től igyekeznek ugyanannak a választékelemnek az árát felírni, amelyekkel a felírást elkezdték. Ha valamelyik elem összeírása valamilyen okból meghiúsul, akkor az EU tagországai által előírt módszereknek megfelelően imputálják azt. A fogyasztóiár-indexet az egyes termékcsoportok árának súlyozott átlagaként adják meg. A kosárban magasabb súllyal rendelkező termékek ára jobban befolyásolja az index szintjét.

Az indexben szereplő súlyok a nemzeti számlák rendszeréből, valamint a Háztartási Költségvetési Felvételből állítják össze. A súlyozás így évente rugalmasan változik a háztartások fogyasztási szerkezete alapján. A fogyasztói szokásoknak köszönhetően kellett például a Covid-járvány miatt megváltozott szokásokat is lekövetni. A tarifás tételek (elektromos energia, vezetékes gáz, távfűtés, víz- és csatornadíjak stb.) árváltozását az új díjak fogyasztói számlán való megjelenésekor veszik számításba, tehát a most aktuális rezsiáremelések is csak 1-2 hónap múlva fognak megjelenni a jelentésekben, akkor, amikor már a fogyasztó is érzi annak hatását.

Mutatok egy részletet a listából, amelyben láthatjuk, hogy elég részletesen definiálták a termékek.

Fogyasztói reprezentánsok
Tisztított dió, csomagolt is (nem darált, nem cukrozott)
Mák, nem cukrozott (csomagolt is)
Pörkölt sósmogyoró, 80-125 g-os
Kukorica, mikrohullámú sütőben kipattogtatható, 3×90-100 g/doboz, különböző ízesítésben
Sólet ételkonzerv, 400-420 g nettó tömeg
Töltött káposzta ételkonzerv, 2 db töltelékkel, 400 g nettó tömeg
Pizza, húsos, gyorsfagyasztott, 300-500 g-os
Bébiétel, májas/húsos + zöldség-gyümölcsös, 163-220 g, üveg

Forrás: KSH

Az adatok mögött rejlő kockázatok – Hogyan kezeljük ezeket?

A KSH által alkalmazott mérés célja, hogy leképezze az átlagos fogyasztási szokásokat, így adott termékeket vesz figyelembe. Előfordulhat, hogy ha mi tipikusan csak egy boltban vásárolunk vagy speciális termékeket veszünk, azoknak másképp érzékeljük árváltozását, mint a hivatalosan közölt adatok szerint.

Lássunk néhány torzító tényezőt! Vegyük példának azt, ahogyan a külföldi utazások árát mérik.  A márciusi adatok szerint ennek ára 17%-kal drágult az elmúlt egy évben. De ha mi nem az alábbi feltételekkel üdülünk vagy nem ezeken a helyeken, akkor az árnak az alakulását akár másképp érzékelhetjük.

Fogyasztói reprezentánsok: Üdülés külföldön
Görögország, utazás repülővel (kötelező egyéb díjakkal), 3 vagy 4 csillagos hotel, félpanzió, 8 nap/7 éj
Olaszország, utazás egyénileg, 3-4 fős apartman (takarítási díjjal), 1 főre, önellátás, 8 nap/7 éj
Spanyolország, utazás repülővel (kötelező egyéb díjakkal), 3 vagy 4 csillagos hotel, félpanzió, 8 nap/7 éj
London, utazás repülővel, reggeli, fürdőszobás szállás, 4 nap, 3 éjszakára számítva
Párizs, utazás repülővel, reggeli, zuhanyzós szállás, 4 nap, 3 éjszakára számítva
Egyiptom, utazás repülővel (kötelező egyéb díjakkal), 4 vagy 5 csillagos hotel, all inclusive, 8 nap/7 éj
Síút Ausztriába, utazás egyénileg, félpanzió, síbérlettel, 6 nap/5 éj
Tunézia, utazás repülővel (kötelező egyéb díjakkal), 4 vagy 5 csillagos hotel, all inclusive, 8 nap/7 éj
Síút Olaszországba, utazás egyénileg, félpanzió, síbérlettel, 8 nap/7 éj
Horvátország, utazás egyénileg, 3 csillagos hotel, félpanzió, 8 nap/7 éj

Forrás: KSH

Arról tudunk beszélni, amiről adatunk van, a hivatalok pedig lefektetett szabályok alapján dolgoznak. A piaci lakásbérletet például 1-2%-ban számolja bele a kosárba, hiszen hivatalosan a lakosság kis százaléka bérel lakást, a valóságban a helyzet azonban más, hiszen sokan bérelnek lakást hivatalos közjegyzői okirat nélkül. Kitérhetünk még a technológiai fejlődésre is. Tegyük fel, hogy a fogyasztói kosárban benne van az iPhone 12 hónapról hónapra, melynek az ára egyre csökken, ezért lényegében defláció mérhető. Amikor kijön a legújabb változat telefonból, és a fogyasztói szokásokat lekövetve egy idő után az kerül bele a kosárba, az ezzel járó árváltozás inflációnak érzékelhető az adott kategóriában, pedig valójában csak technológiai fejlődés vagy minőségjavulás történik.

Bízhatunk-e a mérésekben?

Az előbbiek alapján felmerülhet bennünk, hogy bízhatunk-e a mérésekben? Alapvetően igen, hiszen a kutatók mindig igyekeznek meghatározni egy általános, országspecifikus fogyasztói kosarat. Csak pontos és hivatalos adatokból tudunk becsülni, így mindennek az alapja az, hogy legyenek hivatalos adataink, mint a korábban említett lakásbérleti probléma vagy átfogó adatbázis az áruházakról.

Magáncégek már végeznek olyan adatgyűjtéseket, melyek begyűjtik az összes áruházlánc termékeinek az árát, valamint a termékek vonalkódját, ezzel pedig kiküszöbölik azt a hibalehetőséget, hogy egy adott termék kerül csak be csak a mérésbe. Az olyan jellegű torzítások is elkerülhetőek az ilyesfajta módszerekkel, amikor a termék ára nem változik, de a kiszerelést csökkentik.

Mindezek mellett persze lehetne sokkal korszerűebben, teljeskörűen és alaposan mérni az inflációt. Az elmondható, hogy a hazai mérések az Eurostat iránymutatásait követve történnek, de globális szinten a módszertant mindenféleképpen lehetne fejleszteni az egységes és korszerű adatgyűjtéssel, illetve a fogyasztói kosár tartalmának fejlesztésévél.

Amennyiben további kérdésed van adatelemzési módszerekről, vagy szeretnéd megismerni, hogy hogyan tudnál adataidból értéket teremteni, vedd fel a kapcsolatot kollégáinkkal ezen a formon keresztül!

Adatvédelem 2022: segítünk megérteni, miért fontos!

By | Big Data, Big Data News, Business, Tech Trends | No Comments

Január 28-a van, az adatvédelem nemzetközi világnapja. Cégünk, a United Consult számára nem csupán ma, hanem az év minden napján szakmai minimumnak számít, hogy szem előtt tartjuk a kiberbiztonságot és preventív tanácsokkal látjuk el ügyfeleinket az adataik védelmét illetően. A mai világnap azonban remek alkalom arra, hogy felelősen gondolkodó IT-cégként a laikusok figyelmét is ráirányítsuk a téma fontosságára.

Miért van világnapja az adatvédelemnek, és miért éppen ma?

Bár az adatok, adatbázisok jelentősége látszólag csak az elmúlt 10-15 évben ugrott hatalmasat, a jogalkotók valójában már sokkal korábban rájöttek, hogy milyen értékes, ugyanakkor rendkívül szenzitív kincset jelentenek a mindenkori gazdasági és politikai hatalom számára. A megfelelően strukturált, ennélfogva könnyen kezelhető adatok birtoklása az élet megannyi területén előnyhöz juttathatta az adatgazdákat, nem csoda hát, hogy hamar visszaélések tárgyává, tolvajok célpontjává váltak a különböző adatbázisok. Az információtechnika térnyerése, a számítógépek terjedése aztán alapjaiban alakította át az adatgyűjtés és -tárolás módszereit, a jogalkotók pedig a lehetőségek mellett felismerték az ebben rejlő kockázatokat is.

1981.január 28-án Strasbourgban egyezményt írtak alá az európai államok képviselői, mely az egyének védelméről rendelkezik a személyes adatok gépi feldolgozása során. Ez az úgynevezett adatvédelmi egyezmény, a dokumentum születésének dátuma pedig a mai adatvédelmi világnap apropója.

Hack, ransomware, phishing – mindenre van megoldás!

Azt gondolom, a világnap alkalmából mindenképpen érdemes elgondolkodni azon, hogy a big data megoldások elterjedésével hogyan tekintünk 2022-ben az adatvédelem kérdésére. Napjainkban a felhők, a GDPR világában, ahol és amikor már a petabyte-ban mérhető adatmennyiség szinte mindennapos, amikor ötszázórányi videót osztanak meg a felhasználók percenként a YouTube-on, egyre fontosabb szerepet kap az adatok helyes és hatékony felhasználása mellett azok védelme is.

Minden adat tárolásánál fennáll a kiszivárgás és a jogtalan felhasználás veszélye is, ezért – mint arra már a bevezetőben is utaltam – az adatbiztonság kérdésköre jóval idősebb, mint a mai értelemben vett big data története. Gondolhatunk itt a „klasszikus” hackelésre, az úgynevezett ransomware (zsarolóvírus) támadásokra vagy éppen a phishingre (adathalászatra). Ezekre a kibervédelmi kockázatokra szerencsére megvannak a megfelelő megoldási rendszerek, melyeket az adatmennyiségre való tekintet nélkül tudnunk kell alkalmazni!

A big data terjedése új kihívásokat hozott

A big data terület biztonsági kérdéseinek talán legironikusabb része, hogy rengeteg cég és technológiai megoldás éppen a nagyobb adatmennyiség segítségével próbál megoldást találni a klasszikus biztonsági problémákra, illetve ezek révén igyekszik hatékonyan detektálni a felmerülő kockázatokat. A nagy adatvolumen ugyanakkor megnehezíti a klasszikus auditálási metódusokat, valamint a szoftverekben máshol alkalmazott titkosítási módszerek használatát. Úgy vélem ez akár ahhoz is vezethet, hogy éppen egy adott on-prem vagy cloud infrastruktúra válik a legvédtelenebbé az egész hálózaton.

Egy-egy ilyen rendszernél nemcsak a tárolási, de a be- és kimeneti védelmet is alaposan át kell gondolni; legyen szó az IoT-rendszeren keresztül bevitt adatok védtelenségéről vagy éppen egy analitikai dashboard kitettségről. Ezek a problémák az új, folyamatosan fejlődő, kiforratlan technológiákból jöhetnek, melyek esetében még nem feltétlenül a biztonság az elsődleges szempont.

Már nem csak a támadásokra kell figyelni

A big data terület rohamos fejlődése, illetve a kezelt adatbázisok méretének robbanásszerű növekedése nem csupán a gyakorlati megoldásokat, az alkalmazott kiberbiztonsági technológiákat, hanem a vonatkozó jogi környezetet illetően is változásokat hozott. Az IT világában ma már nem csak „phishing” e-mailekre kell figyelni, hanem a gyakran változó jogszabályokra (például a GDPR rendelkezésekre) is megfelelően kell reagálni. Egy-egy adatvesztésnek a jogi következményeken túl más negatív hozadéka is lehet: felgyorsult, információdús mindennapjainkban sokkal gyorsabb az esetleges bizalomvesztés is a cégekkel, termékekkel szemben, ha bármilyen jele felmerül annak, hogy a személyes adatokat nem megfelelően kezelték.

Természetesen ezeket a problémákat már meglévő és új eszközökkel is kezelni tudjuk. Az infrastruktúránkat tűzfalakkal, megfelelő autentikációs rendszerekkel biztosítani tudjuk. Sorolhatnám példaként a különböző proxykat, a cloud és on-prem autentikációs rendszereket – mint a Kerberos vagy az IAM. Hozzáteszem ugyanakkor, hogy mára szerencsére maguk a nagy felhőtechnológia-szolgáltatók is hatalmas hangsúlyt fektetnek ezekre a szolgáltatásokra.

Ez azonban még mindig csak a csata fele, hiszen a legjobban tervezett rendszerek esetében is van egy gyenge láncszem: maga az ember. Hatalmas felelősség nyomja a programozók és a big data szakemberek vállát. Az ő feladatuk ugyanis a szenzitív adatokat megtisztítani, valamint a rendszerrel kapcsolatos jogosultság-visszaélesek lehetőségét a fent említett technológiák révén minimálisra csökkenteni. Továbbra is fontos szervezeti szinten figyelni a klasszikus „social engineering” támadásokra, és megfelelő védelemmel kell ellátni minden olyan végpontot, ahol az adatunk megjelenik.

Magas prioritású feladat az adatvédelem

Összességében elmondhatjuk, hogy a big data iparág folyamatos növekedésével egyre komolyabb kihívást jelentenek az adatvédelmi kérdések, melyek megválaszolása kiemelt prioritású feladat az IT-szféra egésze számára. Mi, a United Consult munkatársai hiszünk abban, hogy csak úgy nyújthatunk minőségi és szakmailag megfelelő szolgáltatásokat partnereink és ügyfeleink számára, ha mindennapi munkánk során innovatív megoldásokkal garantáljuk az általunk kezelt adatok biztonságát.

Ha részletesebben érdekel a téma és személyesen tájékozódnál az adatvédelem kérdéseiről, keress minket az elérhetőségeinek bármelyikén, illetve figyelmedbe ajánlom a Nemzeti Adatvédelmi és Információszabadság Hatóság weboldalát is, ahol hasznos információkat találsz az aktuális szabályozásokról.

Mikor lassít az önvezető autó a zöldségesnél?

By | Big Data News, Data Science, Tech Trends | No Comments

Tudod, mi a különbség a sarki zöldséges és a képelemző algoritmus között? Az egyik kilóban, a másik pedig pixelekben méri a dinnyét. És mi a hasonlóság? Mindkettő úgy szereti, ha minél pirosabb belülről a gyümölcs. A poén persze komolytalan, a téma viszont nagyon is komoly – mutatjuk, hogyan került képbe a dinnye!

A 2010-es évek talán leglátványosabb technológiai vívmányai az önvezető autók, illetve a kép- és arcfelismerő rendszerek. Lassan egy évtizede sorra jelennek meg cikkek, tévériportok, blogbejegyzések a témában, melyekkel nem csupán az IT-szakma, de a laikus átlagember is gyakran találkozik, így viszonylag tájékozott lehet a felhasználással kapcsolatban. Azt azonban ma is kevesen tudják, hogyan is működnek ezek a rendszerek, miként „foghatja fel” egy gép, hogy mit is lát az elé táruló élő képeken vagy éppen fotókon.

E bejegyzésünkben segítünk kicsit megérteni, hogy milyen alapelvek szerint működik a képfeldolgozás, és hogy hogyan találnak meg egy-egy objektumot az algoritmusok a hatalmas pixelrengetegben. Ebben segített egy OpenCV (Open Source Computer Vision) csomag, mely bárki számára elérhető. A cikkben az alapfogalmak tisztázását követően bemutatunk két eljárást, ami segíthet a számítógép számára különböző objektumokat megtalálni, akár azonos képeken, akár teljesen más forrásból származó fotók esetében.

Kezdjük az alapoktól!

A kép képpontok, azaz a pixelek összessége,  amelyek egy mátrixba csoportosulnak, és vizuálisan felismerhető, értelmezhető alakzatokat jelenítenek meg. Ezen mátrixok nagyságát befolyásolja a kép szélessége és magassága, a rétegeit pedig a színrendszer határozza meg. A fontosabb színskálák az úgynevezett rgb, hsv, hls, luv és a yiq. A továbbiakban az rgb, tehát a red, green és blue színrendszer alkalmazásával bontjuk elemeire a képeket. Az rgb rendszer esetén a kép mátrix-összetétel a következő: a mátrix magassága, a szélessége és a színrétegek száma, ami jelen rendszer mellett három. A rétegek elemei 0-tól 255-ig terjedő egész értékű számok. Fekete-fehér kép esetén a 0 a teljesen sötét, míg a 255 a fehér árnyalatot jelenti, és hasonlóan oszlik el az rgb színskálán is: a piros árnyalat esetén például a 0 a fekete, míg a nagyobb értékek a piros erősségét írja le.

Az önvezető autók működésének alapjául szolgáló, komplex képfelismerő rendszerek képesek arra, hogy azonosítsák a különböző tereptárgyakat, a járműveket, a gyalogosokat, a jelzőtáblákat és útburkolati jeleket, hogy felismerjék a jelzőlámpák fényeit. Mi azonban kezdjük az alapoktól, az alábbi dinnyés fotóval szemléltetve a rendszer működését.

Ahogyan a példaképeken – vagyis a dinnyeszeleteken – is látszik, az első kép az eredeti, ami az összes színréteget tartalmazza, ezt követi a piros, a zöld és a kék árnyalatok kiemelése. Jól látszik, hogy a kép dimenziói nem változtak, azonban például a piros esetén a többi réteg elemei nulla értéket kaptak, azaz teljesen feketévé váltak, így a maradék réteggel megjeleníthetővé vált a kiválasztott piros réteg. Természetesen azonos módszerrel jeleníthetők meg a kék és a zöld árnyalatok is.

A cikkben kétféle objektum keresési eljárást fogok ismertetni, az úgynevezett template matching és a feature matching eljárásokat.

Template matching, avagy objektumillesztés

A legegyszerűbb objektumkeresési eljárások közé tartozik, hiszen a teljes kép egy kis részlete a keresett alakzat a képen, tehát a kicsi lényegében része a nagy képnek.

Ebben az esetben elegendő a kis és a nagy kép pixeleinek az összeegyeztetése, amihez többfajta műveletet is alkalmazhatunk, azonban a legismertebbek a következők:

  • két különböző kép pixeleinek vagy pixel csoportjai közötti korrelációs vizsgálat (lineáris kapcsolatot leíró metrika, mely értéke -1 és 1 között található, ahol az 1 az erős azonos irányú, -1 az erős ellentétes irányú és a 0 érték pedig a kapcsolat meg nem létét írja le),
  • differenciálszámítás a két kép pixel csoportjai között, ahol a hiba 0, ott lesz a teljes egyezés.

A következő képsor a folyamat lépéseit tartalmazza, aminek az első eleme a teljes kép, amiből származik a második kép, amit egyben szeretnénk is megtalálni a teljes képen. A harmadik kép egy korrelációs kép, ami egy részlet a teljes képből. Ezen jól látható, hogy kék színnel mutatja, ahol nincs pixelegyezés a nagy és a kis kép között, azonban a sárgával jelzett részen megvan a teljes egyezés. Az utolsó kép pedig a találat eredményét jeleníti meg immáron egy piros kerettel jelezve a kis kép helyzetét a teljes képen.

A bemutatott egyszerűbb módszertan alkalmazása több helyzetben is elegendő lehet, például akkor, amikor tudjuk, hogy a vizsgált képsokaságokon vannak pontok, melyek mindig állandók, és ezen objektumok mellett következhet be változás, így az állandó alakzatok helyzetéből meghatározható és feldolgozható az újdonság a képeken. Ezzel szemben indikátorként is alkalmazható, ha tudjuk, hogy egy képen csak egyetlen mátrixban történhet változás, és ennek a meg nem találása jelenti a változás megtörténtét.

Feature Matching, avagy sablonillesztés

A template matching esetén a hasonló pixelek feltárásánál nem volt szükség a kép előkészítésére, azonban ha a keresett kép nem része az eredetinek, hanem teljesen más forrásból származik, akkor ki kell emelni a különböző tulajdonságokat. Ezek segítségével az algoritmusok könnyebben találják meg a hasonló egységeket a képeken. Ilyen előkészítések lehetnek a következők:

  • a gray scaling, avagy szürke skála, aminek a segítségével meghatározhatjuk a színárnyalatok fokozatait. Ebben az esetben a kép fekete, fehér és szürke színeket tartalmaz és csupán egy réteget, nem pedig hármat, mint az rgb színrendszer esetén,
  • blurring, smoothing: zaj eltávolítása, egy előre definiált, pár képpont nagyságú mátrix mentén a teljes képen hajt végre képpontátlagolást → ennek következtében a megkapjuk azokat a képrészleteket, ahol a legnagyobb fényváltozások fellelhetők a képen. Fontos figyelni, hogy ennek következtében a kép veszít élességéből így ezt figyelembe tartva kell meghatározni ezeknek a beavatkozásoknak a súlyát.
A feature matching különböző algoritmusok összessége, amelyek együttes alkalmazásával képes megtalálni két különböző, azonban hasonló kép közötti hasonló egységeket. Ezekben a következő algoritmusok segítenek (a lista nem teljes):
  • edge detection, avagy az élek feltárása: alapvető fontossága van, hiszen a képek nagy részletességgel bírhatnak, így ennek a csökkentésére szolgál az algoritmus, aminek segítségével egyszerűbbé válik a képfeldolgozás a számunkra is fontos élek feltárásával.
  • contour detection, avagy a kontúrvonalak megtalálása: segít meghatározni egyes tárgyak formáját, kiterjedését, segítve az elválasztást a többi tárgytól.

A feature matching alkalmazása két pontból tevődik össze. Először is a korábbiakban felsorolt eszközök segítségével feltárja mindkét kép esetében a kulcsfontosságú részeket a képeken. Ezek lehetnek a különböző élek, kontúrok. Ezt követően a két kép esetén meghatározott kulcsfontosságú elemeket hasonlítja össze és rögzíti az összes egyezést. Mivel mindkét kép esetén több kulcsfontosságú elemet is vizsgál, így több esetben is előfordulhat, hogy lehetnek rosszabb és jobb egyezések is a két kép esetén. Tanácsos a folyamatot követően csak a legjobb egyezéseket kiválasztani.

A fent látható képeken megtörtént a feljebb említett szürke skálázás és a pixelek átlagolása. Az összeegyeztetés sikeresnek mondható, hiszen mind a mag, mind a héj esetében megtalálta az egyezéseket még akkor is, ha a képek teljesen más paraméterekkel rendelkeznek, és más körülmények között készítették azokat.

Az önvezető autók persze sokkal bonyolultabb és szofisztikáltabb rendszereket használnak, azonban az alapjai ezekből a folyamatokból tevődnek össze. Ezen alkalmazások segítségével képes meghatározni a sávokat, klasszifikációval a felismert táblákat és más alapvető funkciók összességét, ami a biztonságos vezetéshez szükséges. Talán egyszer majd az útszéli dinnyeárusnál is megáll, ha egy mézédes görögre vágyik a sofőr – azt ugyanis már tudjuk, hogy a dinnye felismerésére is képes a technológia.

CDP Proof Of Concept a MOL-nál – Projekt referencia

By | Big Data News, Business, Cloudera, Tech Trends | No Comments

A CDH (Cloudera Distribution Hadoop) egyik első magyarországi felhasználója a MOL csoport volt.

A MOL 2020 Q1 folyamán egy rövid, 3 hónapos POC projekt keretében azzal bízta meg a United Consult-ot, hogy tesztelje az új CDP (Cloudera Data Platform) platformot, integrálja azt a Cloud szolgáltató rendszeréhez és végezzen hatásvizsgálatot a CDP nagyvállalati környezetben történő használatóságra. Ezen túl pedig készítsen költség-kalkulációkat a lehetséges megoldások összehasonlítása érdekében.

A projekt keretében elkészítettünk egy közel 60 oldalas megvalósíthatósági tanulmányt, amely részletesen elemzi, hogy a Cloudera milyen infrastruktúrális alternatívákban telepíthető, legyen az on-premise, felhő, vagy hibrid megoldás. Az alternatívákat kiértékeltük és összehasonlítottuk olyan nagyvállalati igények mentén mint pl. skálázhatóság, biztonság, üzemeltetési elvárások, machine learning képességek, várható költségek, stb.

Ezt követően egy Proof of Concept projekt keretében alaposan megvizsgáltuk a Cloudera legújabb termékét a Cloudera Data Platformot (CDP). Megvalósítottuk a CDP – Active Directory integrációját, összekapcsoltuk a CDP-t a vállalat Azure környezetével, és üzembe helyeztük a CDP management konzolt. Számos use case megvalósításával megbizonyosodtunk róla, hogy a CDP alkalmazásával gyorsan és rugalmasan akár órák vagy percek alatt vagyunk képesek feldolgozási clustereket létrehozni, amelyek elérik a felhőben tárolt adatokat és hatékonyan összekapcsolhatóak más feldolgozó eszközökkel is mint pl. a PowerBI.

A projekt során performancia teszteket végeztünk, amely segítségével összemérhetőek a különböző méretű klaszterek feldolgozási képességei és költségszintjei.

A POC projekt során kollégáink (fejlesztés, üzemeltetés, IT security) értékes tapasztalatokat szereztek a CDP platform használatával járó előnyökről. A MOL meggyőződött róla, hogy a CDP enterprise data platform megfelelő irány lehet a jövőben a nagy mennyiségű adatfeldolgozás terén.” — Ott Károly, Innovation Manager, MOL Group

2020. 07. 23-án vállalati adatmanagement témakörben tartunk webinart , ahol bemutatjuk a MOL projekt során használt Cloudera Data Platform-ot. Többek között megvizsgáljuk azokat a problémákat és megoldásokat, amik manapság meghatározzák az adat-management legfontosabb elemeit.

Beszélünk azokról az üzleti kihívásokról, amelyekkel nap mint nap találkozhatunk, veszélyeztetik a vállalat fejlődését, a növekedés, és a hatékony teljesítmény útjában állnak. Bemutatjuk, hogy a CDP milyen módon képes támogatni a vállalati adat-management-et, és hogyan inthetünk búcsút játszi könnyedséggel a bemutatott problémáknak. Továbbá egy use-case-en keresztül betekintést nyújtunk abba, hogy hogy viselkedik a CDP éles akció közben.

Ha szeretne részt venni a webinaron, az alábbi linken jelentkezhet Ön is:

Kritikus sikertényezők: üzleti villámcsapások a hibrid felhők világában

By | Big Data News, Business, Cloudera, Tech Trends | No Comments

A cégeknek sosem volt annyi lehetőségük a rendelkezésükre álló adatot a saját előnyükre fordítani, mint napjainkban. De vajon élnek is ezzel a lehetőséggel? Van kidolgozott adatstratégiájuk? Egyáltalán hol állnak most és, hogyan látják a jövőt? Ezekre a kérdésekre kereste a választ a Harvard Business Review nevű menedzsment magazin a Cloudera felkérésére nemrég.

A Harvard Business Review Analytic Services felmérése olyan kritikus pontokra mutat rá, amelyek veszélyeztetik a vállalat fejlődését, és a növekedés, illetve a teljesítmény útjában állnak. A probléma általában abból fakad, hogy a vállalati IT-szempontok egyszerűen nem egyeznek meg az üzleti igényekkel, és a felhasználók fontosabbnak tartják a gyorsaságot a biztonsággal, a pontossággal és a maximális üzleti hatékonysággal szemben.

A felmérés 2019 végén készült mintegy 185 vezető pozícióban álló szakember bevonásával. A szakértők diverzitása több értelemben is magas. A szervezetek mérete – ahol a megkérdezettek dolgoznak – a száz főnél kisebb létszámtól egészen a tízezer fős cégóriásokig terjed, a cégek pedig lefedik a tech, a banki, a consulting és az ipari szektorokat is. A világ négy földrészéről érkeztek vissza kitöltött kérdőívek a kutatás szervezőihez.

Az eredményekből kiderült, hogy a megkérdezettek majd’ háromnegyede (73%) egyetért abban, hogy az adatforrások kulcsszerepet játszhatnak az üzleti érték megteremtésében, és több mint felük (51%) tervezi ezt multi-cloud segítségével megvalósítani.

A statisztikák alapján csupán a megkérdezett cégek 24%-a használ már jelenleg is multi-cloud megoldásokat, ami kevesebb, mint a technológiát használni kívánók fele. Természetesen a saját üzemeltetésű infrastruktúrának is van létjogosultsága, hiszen nem minden adatot szeretnénk kiadni a kezünkből. Ráadásul vannak különböző korlátozások, melyek egyenesen tiltják, hogy bizonyos adatok elhagyják az országot. Egyetlen felhőszolgáltatóval való együttműködés esetén fennállhat a vendor lock-in jelenség. Ez azt jelenti, hogy egy szervezet annyira függ egy felhőszolgáltatótól, hogy jelentős költségek nélkül képtelen másik szolgáltatóra váltani. Ez a kutatás szerint a cégek mintegy 21%-át fenyegeti.

Ahogyan a válaszadók szervezetei kezelik az adatokat:

multi-cloud kutatás

Az adatok tárolása mellett a másik fontos kérdés az adatfeldolgozás állapota volt. Mint kiderült, a cégek a keletkező adatok nagy részét eltárolják, de többnyire csak utólag dolgozzák fel azokat.

A cégek alig több mint ötöde rendelkezik stream-feldolgozó képességekkel és képes ezen beérkező adatok alapján valós idejű döntéseket hozni. Ez üzleti előnyhöz juttatja ezeket a cégeket a versenytársaikkal szemben, hiszen lehetőségük van valós időben ajánlatot adni a felhasználók viselkedése alapján, vagy akár valós idejű diagnosztikát is végezhetnek eszközeiken.


A kutatás azt is vizsgálta, hogy a szakemberek miként látják a jövőt. Az űrlapon megfogalmazott kérdés arra vonatkozott, hogy az adatelemző szervezetek mely módszereket használják most, és melyeket tervezik használni az elkövetkező három évben.

Amiket az adatelemző szervezetek bővíteni/fejleszteni terveznek az elkövetkező három évben
(összehasonlítva a jelenleg alkalmazott elemző technológiákkal)

A megkérdezett cégek szerint a hagyományos, riportok készítésére használt üzleti intelligencia és az adattárházak szerepe csökken, és a különböző, valóban intelligens feldolgozó módszerek kerülnek előtérbe. Ilyenen például a gépi tanulás módszerei, a mesterségesintelligencia-fejlesztések és az intelligens automatizációs megoldások. Ezeken a területeken 60%-os növekedést érhető el belátható időn belül a kérdőív kitöltői szerint.

A tapasztalatokat összegezve megállapítható, hogy a cégek több mint fele szeretne a multi-cloud alapú megoldások felé mozdulni, de csak a szervezetek 34%-a rendelkezik ehhez szükséges adatmenedzsment-stratégiával, és a felhőbe költözés számos egyéb nehézséget is rejt magában.

A kitöltők szerint jelentős feladat, hogy a muli-cloud környezetekben a biztonsági és governance szabályokat többszörösen kell implementálni más és más eszközökkel, hiszen a felhőinfrastruktúra használatával plusz támadási felületet biztosítunk. Úgy vélik, problémát okoz az is, hogy a jelenleg használt „legacy” alkalmazások nem felhőkompatibilisek, és egy nem felhőre optimalizált alkalmazás felhőben való futtatása jelentősen drágább lehet, mint a saját infrastruktúrán.


Ajánljuk figyelmébe a CDP vállalati adatmenedzsment-platformot, mely jelentősen megkönnyíti bigdata megoldások hibrid vagy multi-cloud környezetekben történő kialakítását.

Kérjük töltse ki az űrlapot a teljes angol nyelvű tanulmányhoz!


Mire számíthatunk a Cloudera Data Analyst vizsgáján?

By | Big Data News, Cloudera | No Comments

Nemrég sikerült teljesítenem a Data Analyst Cloudera vizsgát. De talán ne szaladjunk ennyire előre.


Miután egy kisdiák lelkesedésével kijegyzeteltem a training videók anyagát és memorizáltam a törzsanyagot, igyekeztem arra fókuszálni, hogy közepesen bonyolult feladatokat anélkül is simán teljesíteni tudjak, hogy a doksit vadul böngésznem kelljen. Igazából nem tartom a manual/dokumentáció böngészését eredendően elítélendő dolognak, ennek mellőzésére praktikus okaim voltak – a vizsgán használt virtuális masina erőforrásokban nem bővelkedik (bár egy tabon a Hue plusz egy terminál ablak simán ment neki), illetve elég könnyű kifutni az időből. A vizsgán csak a hivatalos Apache doksikat lehet használni, így azért érdemes valamennyi időt ezek, illetve a sqoop manual megismerésére is szánni, ne ott lássuk ezeket először, ha mégis bajba kerülnénk. Alternatív forrásként a neten találtam még felkészítő videókat.

A vizsga teljesen gyakorlatorientált lásd oldal alján a példát, így mindenképpen ajánlott letölteni a QuickStart-Imaget (én a docker-es verziót használtam, a soványka 8 GB RAM-ommal vígan elkocogott az Ubuntumon). A VM-ben van egy retail_db adatbázis pár táblával, azokat ha sqoop-pal behúzod Hive-ba, már el is kezdheted a gyakorlást (a root/cloudera párossal pedig hozzáférhetsz a db-hez).

Ha alapos munkát végeztél, akkor tudni fogod a HiveQL és Impala közötti különbségeket, magabiztosan tudsz írni CTAS-t, tudod használni a beépített függvényeket és tudod, hogy mikor kell over-partition-by-t használnod.

Adminisztratív teendők

Az első lépés, hogy Clouderán lévő accountodhoz kicsengeted a megfelelő összeget, erre ő küld majd egy üdvözlő emailt. Egy ponton átirányított a PSI oldalára – ez egy oldal online vizsgákra specializálódva, különös ismertetőjegye az előző évszázadra jellemző webdesign. Következő lépésként kiválasztottam a vizsga időpontját, időzónámat (ő pedig udvariasan figyelmeztetett, hogy ugyan át tudom ütemezni más időpontra a vizsgát, de erre már nincs lehetőségem az utolsó 24 órában). A PSI oldalán van egy kompatibilitás-teszt, ahhoz hogy sikerüljön ez, fel kellett tegyem a PSI egyik chrome extensionjét.

Egy virtuális gép elérésénél kritikus tud lenni a késleltetés, így ha az ember fia nem bízik a csillagok megfelelő együttállásában, kezébe veheti sorsát és foglalhat meeting roomot a Cloudera Budapesti főhadiszállásán – bízva abban hogy ott optimális technikai feltételekkel tud dolgozni.

Maga a vizsga 120 perces, de előtte 15 perc adminisztratív teendőkkel telik, így a szobát ideális elfoglalni már a vizsga kezdése előtt fél órával. A vizsga során elméletileg lehet csúszás az időben, de nálam ez nem volt számottevő.


Amikor elérkezett az idő, felkaptam kabátom, esernyőm és belötyögtem a villamossal arra a pontra, amit a google maps megjelölt. Annak ellenére, hogy már-már védjegyem az, hogy mindenhonnan kések egy picit, meglepő módon sikerült időben odaérjek. Természetesen ez sem ment abszolút zökkenőmentesen, tekintve hogy naívan két méteres ‘Cloudera’ feliratot vártam, amit nem találtam sehol. Némi útbaigazítás után megtudtam, hogy a Roosevelt irodaház hat/hetedik emeletén van a főhadiszállásuk, így betoppantam az irodaházba. Miután ízléstelen barna műbőr kabátommal nem tudtam elvegyülni az ottani öltönyös úriemberek között, kértem vendégkártyát a Clouderához. A lift kártyával működik, így a gombok kétségbeesett nyomkodása nem segít abban, hogy az ember felkerüljön a hetedik emeletre. A recepción gyorsan készítettem vendég-matricát magamnak, amit büszkén felragasztottam kabátom mellrészére. Pár perc után odaért a kontaktom, és újabb pár perc után sikerült találniuk egy másik meeting roomot, majd lekísértek a teremhez. Összességében 5-10 perc után a szobában voltam, így megkezdhettem annak átrendezését. A redőnyöket lehúzták, táblát kivitték, én pedig elpakoltam az asztalról mindent amit tudtam, elővettem laptopom és izzadt tenyérrel vártam, hogy a PSI felületén rá tudjak kattintani a vizsga megkezdése gombra.



A gombra kattintás után egy felületet kaptam, egyelőre VM nélkül, ahol egy chat ablakban egy sablonszöveg fogadott, majd kértek, hogy igazoljam magam, hordozzam körbe a laptopot a szobában, mutassam meg a szoba falait alaposan, mutassam meg az asztal felületét, stb. Mivel a vizsgáról nem készíthettem képeket, így a fenti kép csak egy google képkereséssel talált illusztráció – ám arra teljesen tökéletes, hogy megmutassa a felületet. Az ablaknak háttal nem lehetett ülni, illetve a kamerában jól látszódnom kellett (utóbbi a View webcam & desktop menüpont alatt volt ellenőrizhető a felső menüsávon). A kezdés előtt a system monitort/topot kellett mutatni. Maga a vizsga kilenc rövidebb feladatot tartalmazott. Egy feladat megoldása többnyire pár percet vett csak igénybe, a neheze annak ellenőrzése volt. Gyakori kikötésként szerepelt, hogy egy másik, létező táblával megegyező formátumot kell követni (fájlformátum, tagolás, oszlopnév), így ezt reflexszerűen tudni kellett ellenőriznem. A feladatoknál nincsenek részpontszámok és automatizáltan vannak ellenőrizve, így könnyű elcsúszni az ilyen “banánhéjakon”.
Teljesítménybeli problémákat nem tapasztaltam, a lekérdezések többsége 2-3 perc alatt lefutott. Két alkalommal hiába gépeltem szöveget, kétségbeesett billentyű-csapkodásomra sem jelent meg a virtuális gépen – ez a probléma mindkét alkalommal pár perc után magától megoldódott. A touchpaddal is volt egy kevés gondom, de erről könnyen el tudom képzelni, hogy lokális probléma volt. Miután vége lett a vizsgának, kaptam egy sablonszöveget, hogy 2-3 napon belül lesznek majd eredmények. Ezeket egyébként meglepően gyorsan megkaptam – mire az immár eléggé időszerű ebédem után visszaértem az irodába, már értesítettek is arról, hogy átmentem.

Tényleg jobb lett a levegő a karantén miatt?

By | Big Data News, Data Science | No Comments

António Guterres ENSZ-főtitkár a minap felhívást intézett a világ vezetőihez, hogy használják fel a koronavírus-járvány teremtette helyzetet a világ jobbá tételére és együttműködésükkel olyan más globális fenyegetésekkel is szálljanak szembe, mint a klímaváltozás. Mivel mi magunk, a United Consult munkatársai is elkötelezettek vagyunk a zöldebb jövő mellett, saját eszközeinkkel igyekeztünk utánajárni, hogy milyen konkrét összefüggések vannak a pandémia és a légszennyezettség csökkenése között.


Az MTI beszámolója szerint az ENSZ-főtitkár a Petersbergi Klímadialógus című kétnapos tanácskozás keretében szólalt fel videón keresztül. Guterres szerint a járvány rávilágított, hogy mennyire ki vannak szolgáltatva társadalmaink és gazdaságaink az ilyen jellegű sokkhatásoknak. Mint mondta, az egyedüli válasz ebben a helyzetben a bátor, jövőképpel rendelkező és együttműködő vezetés. „Ugyanilyen vezetésre van szükség a klímaváltozás egzisztenciális fenyegetése esetében is” – hangoztatta Guterres, aki szerint jelentős ára lesz annak, ha nem cselekszünk a klímaváltozás feltartóztatása ügyében, ugyanakkor – mint fogalmazott – a technológia a mi oldalunkon áll.

Húszéves múltra visszatekintő IT-cégként bátran megerősíthetjük az ENSZ-főtitkár szavait. A technológia valóban a jelen és a jövő szolgálatában áll, olyannyira, hogy kollégáink például már nem először hívták segítségül az adatokat és az adatelemzés módszerét a járványhelyzet kapcsán. Néhány hete arra kerestük a választ, hogy lehet-e Magyarországon adatokkal védekezni a járvány ellen, ezúttal pedig a Covid 19-járvány miatti kijárási korlátozások és légszennyezettség állapotának összefüggéseit vizsgáltuk meg.

NO2 és a hőmérséklet kapcsolata

A koronavírus-járvány kapcsán már sokat emlegetett légszennyezettség-csökkenés lehetséges okainak jártunk utána. Kíváncsiak voltunk arra, hogy a sok negatív hatással szemben ezt a pozitív változást át tudjuk-e menteni a vírus utáni időszakra.

A légszennyezettséget a levegő NO2 (nitrogén-dioxid) koncentrációján keresztül vizsgáltuk. A NO2 elsősorban a járművek üzemanyagának égéstermékeiből, valamint energia-termelésből és fűtésből származik. Ebből adódóan a hőmérséklet és a NO2 koncentráció természetesen erős kapcsolatot mutat. Mint a következő ábrán is jól látszik, a téli időszakban, amikor csúcson jár a fűtési szezon, mindig magasabb a légszennyezettség, és ahogy melegszik az idő, csökkennek az értékek.


Forrás: European Environment Agency, National Centers for Environmental Information

Mivel a koronavírus éppen ebben az amúgy is leszálló ágban ért el minket, az elemzés során figyelembe kellett vennünk az időjárási változásokat is. Ennek érdekében megnéztük, hogy tavalyhoz képest az idei tavasz gyorsabban vagy lassabban ért-e el minket. Azt tapasztaltuk, hogy a vizsgált városokban nincs szignifikáns különbség a tavalyi és az idei hőmérséklet alakulások között, így összehasonlíthattuk a tavalyi és idei NO2 értékeket.

A korlátozások hatása a légszennyezettségre

De akkor mi okozhatta mégis hirtelen a légszennyezettségi mutatók javulását a legtöbb koronavírussal sújtott országban? Nem kérdés, hogy a megbetegedéseken és az azokra adott társadalmi reakciókon túl a különböző vészhelyzeti intézkedések komoly hatással voltak minden ország működésére, ezek nyomán pedig visszaesett a közlekedés és ipari tevékenységek nagy része.

Vizsgálatunk során kísérletet tettünk arra, hogy egy időskálán bemutassuk, hogyan szigorodtak a korlátozások öt európai fővárosban. Egy 10-es skálán kategorizáltuk be az adott napi intézkedéseket az alábbi szempontok szerint:

A következőkben láthatjuk a NO2 és a korlátozások kapcsolatát. Az ábrákon feltűntettük a tavalyi és az idei év NO2 koncentrációját januártól kezdve és ezzel párhuzamosan mellé tettük, hogy a különböző városokban mikor, milyen erős korlátozások léptek érvénybe. Jól látható, hogy azokban a városokban, ahol a korlátozások erőssége elérte a legerősebb, 10-es szintet, ott jelentős csökkenést tapasztalunk a tavalyi NO2 koncentrációhoz képest.

Az eredményekből az is kitűnik, hogy bár Budapesten és Berlinben – ahol a korlátozások egyelőre megálltak a 7-es szinten és a hírek szerint nem is várható további szigorítás – is volt egy kezdeti csökkenés, hamar visszaállt a koncentráció az ilyenkor megszokott szintre.

A döntések gazdasági hatásai

Ezek a megfigyelések megerősítették, hogy a járvány miatt hozott döntések nem csupán egészségügyi, hanem komoly környezeti hatásokkal is bírnak. Mindemellett fontos szempont persze – és a döntéshozóknak természetesen ezt is mérlegelni kell –, hogy a korlátozások nem csupán a vírus terjedésének sebességét és intenzitását, illetve a légszennyezettséget befolyásolják. Az ilyen intézkedések a gazdaságra is komoly, jellemzően negatív hatással vannak. Kivételt talán csak az online kereskedelemmel, illetve bizonyos egészségügyi eszközök gyártásával és forgalmazásával összefüggő üzleti területek jelenthetnek.

A GDP adatok a márciusi-áprilisi időszakra vonatkozóan még nem álltak rendelkezésünkre, ezért a gazdasági hatások alakulásának vizsgálatára az úgynevezett PMI (beszerzési menedzser index) mutatót fogjuk használni, mely egy megkérdezésen alapuló mutató. Vállalatok vezetői nyilatkoznak az új megrendelések, készletek állománya, termelés, szállító teljesítések és a foglalkoztatási környezet változásairól. Ha a PMI értéke 50 feletti szám, akkor az gazdasági növekedést, az 50 alatti érték szűkülést, míg a kerek 50 változatlanságot vetít előre az előző hónaphoz képest.



A fentebbi ábrán jól látható, hogy a gazdaságra éppoly drasztikus, ha nem erősebb hatása lesz hosszú távon „karanténban töltött” időszaknak, mint a légszennyezettségre. Összességében tehát elmondhatjuk, hogy igen komoly döntések előtt állnak a világ kormányainak vezetői: most ugyanis – ahogyan az ENSZ-főtitkár is hangsúlyozta – fontos lépéseket tehetnének a klímaváltozás ellen, nem mindegy azonban, hogy mindezt milyen áron teszik meg. Egyelőre a jövő kérdése, hogy a világ vezetői – például a COVID 19 nyomán csökkenő légszennyezettséget látva – megtalálják-e azokat az ideális intézkedéseket, melyek hosszú távon nem teszik tönkre a gazdaságot, de mégis látható javulást hoznak a környezeti mutatókra.


Ők az anyukák kedvencei – látványos vizualizációk a trendi keresztnevekről

By | Big Data, Big Data News, Data Visualization | No Comments

Ezen a hétvégén lesz május első vasárnapja, amit Magyarországon 1925 óta az anyák napjaként ünneplünk. Az édesanyák első ajándéka újszülött gyermekeik számára a gondosan megválasztott keresztnév, mely életük végéig elkíséri őket. Anyák napja alkalmából a névadási trendeket vizsgáltuk az 1950-es évektől napjainkig.


Utánanéztünk, hogy a közel hét évtized alatt az édesanyák körében melyek voltak azok a leggyakoribb keresztnevek, amiket újszülött gyermekeiknek választottak, és hogy miként alakultak a névadási trendek Magyarországon.

Érdekes megfigyelni, hogy míg a fiúknál minden korszak között vannak átfedések, addig a lányoknál sokkal nagyobb a fluktuáció, és a top 15-ös listában többször is teljesen kicserélődnek a nevek. A látványos adatvizualizációkat figyelve – miként a való életben is – a szemünk láttára tűnnek el a Máriák és az Erzsébetek, és nem sokkal szerencsésebbek az Istvánok és a Józsefek sem. Az elemzésből kiderült, hogy míg a fiúknál már 2001 óta uralkodnak a Bencék, a lányoknál csak tíz évvel később kerültek az első helyre a Hannák.

Ráadásként pedig egy igazi kuriózum: a következő vizualizáción láthatod, hogy melyek a legnépszerűbb női és férfi keresztnevek Európa országaiban.

Európai trendek

Forrás: Belügyminisztérium Nyilvántartások Vezetéséért Felelős Helyettes Államtitkárság, Magyar Keresztnevek Tára
Vizualizáció: Flourish