Big data-architektúrák

A big data architektúra kezeli a hagyományos adatbázisrendszerekhez túl nagy vagy összetett adatok betöltését, feldolgozását és elemzését. A big data területére való belépés küszöbértéke a szervezetek között az eszközeiktől és a felhasználói képességeiktől függően változik. Egyes szervezetek több száz gigabájtnyi adatot kezelnek, más szervezetek pedig több száz terabájtot kezelnek. A big data-adathalmazok használatához szükséges eszközök fejlődésével a big data definíciója a kizárólag az adatméretre való összpontosítástól a speciális elemzésekből származó érték kiemelése felé tolódik el. Bár az ilyen típusú forgatókönyvek általában nagy mennyiségű adatot tartalmaznak.

Az évek során megváltozott az adatkörnyezet. Az adatok felhasználási lehetőségei és az ezekkel kapcsolatos elvárások is megváltoztak. A tárolási költségek jelentősen csökkentek, miközben az adatgyűjtés módszerei folyamatosan bővülnek. Egyes adatok gyors ütemben érkeznek, és folyamatos adatgyűjtést és megfigyelést igényelnek. Más adatok lassabban, de nagy adattömbökben érkeznek, és gyakran több évtizedes előzményadatok formájában. Előfordulhat, hogy speciális elemzési problémába ütközik, vagy olyan problémába ütközik, amely megoldásához gépi tanulás szükséges. A big data architektúrák igyekeznek megoldani ezeket a kihívásokat.

A big data-megoldások általában az alábbi számítási feladatok egy vagy több típusát foglalják magukban:

• Nagy adathalmazok kötegelt feldolgozása nyugalmi állapotban
• Big Data valós idejű feldolgozása mozgásban
• Big Data interaktív feltárása
• Prediktív elemzés és gépi tanulás

Fontolja meg a big data-architektúrákat, ha a következő feladatokat kell elvégeznie:

• Adatok tárolása és feldolgozása olyan kötetekben, amelyek túl nagyok egy hagyományos adatbázishoz
• Strukturálatlan adatok átalakítása elemzéshez és jelentéskészítéshez
• Adatok kötetlen adatfolyamainak rögzítése, feldolgozása és elemzése valós időben vagy alacsony késéssel

A big data-architektúrák összetevői

Az alábbi ábra egy big data-architektúra logikai összetevőit mutatja be. Előfordulhat, hogy az egyes megoldások nem tartalmazzák a diagram minden elemét.

A folyamat adatforrások alapján kezdődik. Az adatok adattárolásra és valós idejű üzenetbetöltésre kerülnek, amelyek csatlakoztatva vannak. Az adattárban lévő adatok kötegelt feldolgozásra kerülnek, majd vagy az elemzési adattárba és utána az elemzésbe és jelentéskészítésbe, vagy közvetlenül az elemzésbe és jelentéskészítésbe kerülnek. A valós idejű üzenetbetöltés adatai streamfeldolgozásra kerülnek. Ezután az elemzési adattárba, majd az elemzésbe és jelentéskészítésbe, vagy közvetlenül az elemzésbe és jelentéskészítésbe kerül. A gépi tanulás a kötegelt feldolgozásra és a streamfeldolgozásra mutat.

A legtöbb big data-architektúra az alábbi összetevők némelyikét vagy mindegyikét tartalmazza:

• Adatforrások: Minden big data-megoldás egy vagy több adatforrással kezdődik. Ide sorolhatóak például a következők:

  • Alkalmazásadattárak, például relációs adatbázisok.
  • Az alkalmazások által létrehozott statikus fájlok, például a webkiszolgáló naplófájljai.
  • Valós idejű adatforrások, például eszközök internetes hálózata (IoT).

• Adattárolás: A kötegfeldolgozási műveletekhez használt adatokat általában elosztott fájltárolóban tárolják, amely nagy méretű fájlokat tárolhat különböző formátumokban. Ezt a fajta tárolót gyakran nevezik data lake. A tároló implementálásának lehetőségei közé tartozik az Azure Data Lake Store, az Azure Storage blobtárolói vagy a Microsoft Fabric OneLake-je.

• Kötegelt feldolgozás: Az adathalmazok nagyok, ezért a big data-megoldások gyakran dolgoznak fel adatfájlokat hosszú ideig futó kötegelt feladatok használatával az adatok szűréséhez, összesítéséhez és más módon az elemzéshez való előkészítéséhez. Ezek a feladatok általában magukban foglalják a forrásfájlok olvasását, feldolgozását és a kimenet új fájlokba való írását. A következő lehetőségeket használhatja:

  • U-SQL-feladatok futtatása az Azure Data Lake Analyticsben.

  • Hive-, Pig- vagy egyéni MapReduce-feladatokat használhat egy Azure HDInsight Hadoop-fürtben.

  • Java-, Scala- vagy Python-programokat használhat egy HDInsight Spark-fürtben.

  • Python-, Scala- vagy SQL-nyelv használata az Azure Databricks-jegyzetfüzetekben.

  • Python-, Scala- vagy SQL-nyelv használata Fabric-jegyzetfüzetekben.

• Valós idejű üzenetbetöltés: Ha a megoldás valós idejű forrásokat tartalmaz, az architektúrának valós idejű üzeneteket kell rögzítenie és tárolnia a streamfeldolgozáshoz. Létrehozhat például egy egyszerű adattárat, amely összegyűjti a bejövő üzeneteket feldolgozás céljából. Számos megoldásnak azonban szüksége van egy üzenetbetöltési tárolóra, amely pufferként szolgál az üzenetekhez, és támogatja a vertikális felskálázási feldolgozást, a megbízható kézbesítést és más üzenetsor-kezelési szemantikát. A streamelési architektúra ezen részét gyakran streampufferelésnek is nevezik. A lehetőségek többek között a következők: Azure Event Hubs, Azure IoT Hub és a Kafka.

• Streamfeldolgozás: Miután a megoldás valós idejű üzeneteket rögzít, azokat szűréssel, összesítéssel és az adatok elemzésre való előkészítésével kell feldolgoznia. A feldolgozott streamadatok ezután egy kimeneti fogadóba lesznek írva.

  • Az Azure Stream Analytics egy felügyelt streamfeldolgozó szolgáltatás, amely folyamatosan futó SQL-lekérdezéseket használ, amelyek kötetlen streameken működnek.

  • HdInsight-fürtön vagy Azure Databricksben használhat nyílt forráskódú Apache streamelési technológiákat, például a Spark Streaminget.

  • Az Azure Functions egy kiszolgáló nélküli számítási szolgáltatás, amely képes eseményvezérelt kódot futtatni, amely ideális az egyszerűsített streamfeldolgozási feladatokhoz.

  • A Fabric eseménystreamek és Spark-feldolgozás használatával támogatja a valós idejű adatfeldolgozást.

• Gépi tanulás: A kötegelt vagy streamfeldolgozásból származó előkészített adatok elemzéséhez gépi tanulási algoritmusokkal olyan modelleket hozhat létre, amelyek kimeneteket jeleznek előre vagy adatokat osztályoznak. Ezek a modellek nagy adatkészleteken taníthatók be. Az eredményként kapott modellek segítségével elemezheti az új adatokat, és előrejelzéseket készíthet.

  Ezeket a feladatokat az Azure Machine Learning használatával végezheti el. A Machine Learning eszközöket biztosít modellek létrehozásához, betanítása és üzembe helyezéséhez. Alternatív megoldásként az Azure AI-szolgáltatások előre elkészített API-jait is használhatja olyan gyakori gépi tanulási feladatokhoz, mint a látás, a beszéd, a nyelv és a döntéshozatali feladatok.

• Elemzési adattár: Számos big data-megoldás előkészíti az adatokat az elemzéshez, majd strukturált formátumban szolgálja ki a feldolgozott adatokat, amelyet az elemzési eszközök lekérdezhetnek. A lekérdezéseket kiszolgáló elemzési adattár lehet Kimball-stílusú relációs adattárház. A legtöbb hagyományos üzletiintelligencia-megoldás ilyen típusú adattárházat használ. Másik lehetőségként bemutathatja az adatokat egy alacsony késésű NoSQL-technológián, például a HBase-en vagy egy interaktív Hive-adatbázison keresztül, amely metaadat-absztrakciót biztosít az elosztott adattárban lévő adatfájlokon.

  • Az Azure Synapse Analytics egy nagy méretű, felhőalapú adattárházak felügyelt szolgáltatása.

  • A HDInsight támogatja az Interaktív Hive, a HBase és a Spark SQL használatát. Ezek az eszközök adatokat szolgálnak ki elemzéshez.

  • A Fabric különböző adattárakat biztosít, például SQL-adatbázisokat, adattárházakat, tóházakat és eseményházakat. Ezek az eszközök adatokat szolgálnak ki elemzéshez.

  • Az Azure más elemzési adattárakat is biztosít, például az Azure Databrickset, az Azure Data Explorert, az Azure SQL Database-t és az Azure Cosmos DB-t.

• Elemzés és jelentéskészítés: A legtöbb big data-megoldás arra törekszik, hogy elemzéssel és jelentéskészítéssel betekintést nyújtson az adatokba. Annak érdekében, hogy a felhasználók elemezzék az adatokat, az architektúra tartalmazhat adatmodellezési réteget, például egy többdimenziós online elemzési kockát vagy táblázatos adatmodellt az Azure Analysis Servicesben. Az önkiszolgáló BI-t a Power BI vagy az Excel modellezési és vizualizációs technológiáival is támogathatja.

  Az adattudósok vagy adatelemzők interaktív adatfeltárással is elemezhetnek és jelenthetnek. Ezekben a forgatókönyvekben számos Azure-szolgáltatás támogatja az elemzési jegyzetfüzeteket, például a Jupytert, hogy lehetővé tegye ezeknek a felhasználóknak, hogy meglévő készségeiket a Pythonnal vagy a Microsoft R-vel használják. Nagy léptékű adatfeltáráshoz használhatja a Microsoft R Servert önállóan vagy a Spark használatával. A Fabric használatával adatmodelleket is szerkeszthet, ami rugalmasságot és hatékonyságot biztosít az adatmodellezéshez és -elemzéshez.

• Hangszerelés: A legtöbb big data-megoldás ismétlődő adatfeldolgozási műveletekből áll, amelyek munkafolyamatokba vannak ágyazva. A műveletek a következő feladatokat hajtják végre:

  • Forrásadatok átalakítása
  • Adatok áthelyezése több forrás és fogadó között
  • A feldolgozott adatok betöltése elemzési adattárba
  • Az eredmények leküldése közvetlenül egy jelentésbe vagy irányítópultra

  A munkafolyamatok automatizálásához használjon vezénylési technológiát, például az Azure Data Factoryt, a Fabricet vagy az Apache Oozie-t és az Apache Sqoopot.

Lambda architektúra

Ha nagy adathalmazokkal dolgozik, az ügyfelek számára szükséges lekérdezések futtatása hosszú időt vehet igénybe. Ezek a lekérdezések nem végezhetők el valós időben. Gyakran igényelnek olyan algoritmusokat, mint például a MapReduce , amelyek párhuzamosan működnek a teljes adathalmazban. A lekérdezés eredményeit a rendszer a nyers adatoktól elkülönítve tárolja, és további lekérdezésekhez használja.

Ennek a megközelítésnek az egyik hátránya, hogy késést eredményez. Ha a feldolgozás néhány órát vesz igénybe, előfordulhat, hogy egy lekérdezés több órás eredményeket ad vissza. Ideális esetben valós időben, esetleg pontosságvesztéssel kell eredményeket kapnia, és kombinálnia kell ezeket az eredményeket a Batch-elemzés eredményeivel.

A Lambda-architektúra két adatfolyam-elérési út létrehozásával oldja meg ezt a problémát. A rendszerbe érkező összes adat a következő két útvonalon halad végig:

• A kötegelt réteg (hideg útvonal) az összes bejövő adatot nyers formában tárolja, és kötegelt feldolgozást végez az adatokkal. A feldolgozás eredménye kötegelt nézetként lesz tárolva.

• A gyors réteg (gyakori elérésű útvonal) valós időben elemzi az adatokat. Ez a réteg a minimális késleltetésre van tervezve, a pontosság rovására.

A kötegelt réteg a kiszolgálórétegbe továbbítja az eredményeket, amely indexeli a kötegelt nézetet a hatékonyabb lekérdezés érdekében. A gyors réteg növekményes frissítésekkel frissíti a kiszolgálóréteget a legújabb adatok alapján.

Az adatfolyam-forrás az eseményadatok egységes naplója. Az adatok a sebességrétegre vagy a kötegrétegre kerülnek. A sebességrétegből egy szilárd vonal mutat az elemzési ügyfélre, egy pontozott vonal pedig a kiszolgáló rétegre. A kötegrétegből az adatok a kiszolgáló rétegbe, majd az elemzési ügyfélbe kerülnek. A sebességréteg forró útvonalként van megjelölve. A kötegréteg és a kiszolgáló réteg hideg elérési útként van megjelölve.

A gyors útszakaszba érkező adatok gyors feldolgozást igényelnek a gyorsasági réteg által előírt késési követelmények miatt. A gyors feldolgozás biztosítja, hogy az adatok készen állnak az azonnali használatra, de pontatlanságot okozhatnak. Vegyük például azt az IoT-forgatókönyvet, amelyben számos hőmérséklet-érzékelő küld telemetriai adatokat. A sebességréteg feldolgozhatja a bejövő adatok csúszó időablakát.

A hideg útvonalba áramló adatokra nem vonatkoznak ugyanazok az alacsony késési követelmények. A hideg elérési út nagy pontosságú számítást biztosít nagy adathalmazokban, de hosszú időt vehet igénybe.

Végül a forró és hideg útvonalak az analitikai ügyfélalkalmazásnál találkoznak. Ha az ügyfélnek valós időben kell megjelenítenie az adatokat, amelyek valószínűleg kevésbé pontosak, az eredményét a "hot path" útvonalból szerzi be. A kliens a hideg útvonal eredményei közül választ arra, hogy kevésbé aktuális, de pontosabb adatokat jelenítsen meg. Másként fogalmazva, a forró útvonal adataival rendelkezik egy viszonylag kis időtartamra, amely után az eredmények frissíthetők a hideg útvonal pontosabb adataival.

A kötegrétegben tárolt nyers adatok nem módosíthatók. A bejövő adatok hozzá lesznek fűzve a meglévő adatokhoz, és az előző adatok nem lesznek felülírva. Egy adott datum értékének módosítása új időbélyeggel ellátott eseményrekordként lesz tárolva. Az időbélyegzett eseményrekordok lehetővé teszik az összegyűjtött adatok előzményeinek bármely időpontban történő újraszámítását. A batch nézetnek az eredeti nyers adatokból való újrakomponálása azért fontos, mert lehetővé teszi új nézetek létrehozását a rendszer fejlődésével.

Kappa architektúra

A Lambda-architektúra hátránya az összetettsége. A feldolgozási logika két különböző helyen jelenik meg, a hideg és a forró útvonalakon, különböző keretrendszereken keresztül. Ez a folyamat duplikált számítási logikát és az architektúra összetett kezelését eredményezi mindkét útvonal esetében.

A Kappa architektúra a Lambda architektúra alternatívát jelent. Ugyanazokkal az alapvető célokkal rendelkezik, mint a Lambda-architektúra, de minden adat egyetlen útvonalon halad át egy streamfeldolgozó rendszeren keresztül.

Az adatfolyam-forrás az eseményadatok egységes naplója. Az adatok a sebességrétegbe vagy a hosszú távú tárolóba kerülnek. A forrásadatoktól a hosszú távú tárolóig tartó folyamat "eseményeket tükröz a hosszú távú tárolóba." A hosszú távú tárolás a teljesítményrétegre utal. Ez a sor ezt írja: "Naplóesemények újraszámítása a tárolóból, ha szükséges". A sebességréteg az elemzési ügyfélre mutat, és zöld színnel tagolt.

A Lambda-architektúra kötegrétegéhez hasonlóan az eseményadatok nem módosíthatók, és az összes adatot összegyűjtik az adatok egy részhalmaza helyett. Az adatok eseményfolyamként lesznek betöltve egy elosztott, hibatűrő egységes naplóba. A rendszer sorba rendezi az eseményeket, és csak új esemény hozzáfűzésekor módosítja az aktuális állapotukat. A Lambda-architektúra sebességrétegéhez hasonlóan minden eseményfeldolgozás a bemeneti adatfolyamon történik, és valós idejű nézetként marad meg.

Ha a teljes adatállományt újra kell kiszámítania (ami ekvivalens a Lambda architektúra kötegelt rétegéhez), újra futtathatja a streamet. Ez a folyamat általában párhuzamossággal, időszerű módon végzi el a számítást.

Lakehouse-architektúra

A data lake egy központosított adattár, amely strukturált adatokat (adatbázistáblákat), részben strukturált adatokat (XML-fájlokat) és strukturálatlan adatokat (képeket és hangfájlokat) tárol. Ezek az adatok nyers, eredeti formátumban jelennek meg, és nem igényelnek előre definiált sémát. A data lake nagy mennyiségű adatot képes kezelni, így alkalmas big data-feldolgozásra és -elemzésre. A data lake-k alacsony költségű tárolási megoldásokat használnak, amelyek költséghatékony módot biztosítanak a nagy mennyiségű adat tárolására.

Az adattárház egy központosított adattár, amely strukturált és félig strukturált adatokat tárol jelentéskészítési, elemzési és BI-célokra. Az adattárházak az adatok konzisztens és átfogó áttekintésével segíthetnek megalapozott döntéseket hozni.

A Lakehouse-architektúra egyesíti a data lake-k és adattárházak legjobb elemeit. A minta célja, hogy egységes platformot biztosítson, amely támogatja a strukturált és strukturálatlan adatokat is, ami hatékony adatkezelést és elemzést tesz lehetővé. Ezek a rendszerek általában alacsony költségű felhőbeli tárolást használnak nyílt formátumban, például Parquet vagy Optimalizált sor oszlopos tárolással nyers és feldolgozott adatok tárolására.

A lakehouse-architektúra gyakori használati esetei a következők:

• Egyesített elemzések: Ideális olyan szervezetek számára, amelyeknek egyetlen platformra van szükségük az előzmény- és valós idejű adatelemzéshez

• Gépi tanulás: Fejlett elemzési és gépi tanulási számítási feladatokat támogat az adatkezelési képességek integrálásával

• Adatszabályozás: Biztosítja a megfelelőséget és az adatminőséget a nagy adathalmazok között

IoT

Az IoT minden olyan eszközt jelöl, amely csatlakozik az internethez, és adatokat küld vagy fogad. Az IoT-eszközök közé tartoznak a számítógépek, a mobiltelefonok, az intelligens órák, az intelligens termosztátok, az intelligens hűtőszekrények, a csatlakoztatott autók és a szívmonitorozási implantátumok.

A csatlakoztatott eszközök száma naponta nő, és az általuk létrehozott adatok mennyisége is. Ezeket az adatokat gyakran olyan környezetekben gyűjtik, amelyek jelentős korlátozásokkal és néha nagy késéssel rendelkeznek. Más esetekben eszközök ezrei vagy milliói küldenek adatokat alacsony késésű környezetekből, ami gyors betöltést és feldolgozást igényel. Ezeket a korlátozásokat és egyedi követelményeket megfelelően kell megterveznie.

Az eseményvezérelt architektúrák központi szerepet játszanak az IoT-megoldásokban. Az alábbi ábrán az IoT logikai architektúrája látható. A diagram az architektúra eseménystreamelési összetevőit hangsúlyozza.

Az adatfolyam a bal oldali eszközökkel kezdődik, amelyek egy mezőátjáróhoz csatlakoznak, majd egy felhőátjáróhoz csatlakoznak. A felhőátjáró streamfeldolgozáson keresztül csatlakozik a különböző feladatokhoz. A feladatok közé tartozik az archivált tárolás, a valós idejű elemzések, az értesítések és a gépi tanulás. A Batch-elemzés hideg tárolásra mutat. A streamfeldolgozás az alkalmazás háttérrendszerére mutat, amely a parancsra és vezérlésre, a kiépítési API-ra és az eszközregisztrációs adatbázisra mutat. A kiépítési API az eszközregisztrációs adatbázisra mutat. A parancs és a vezérlés az eredeti mezőátjáróra és más eszközökre mutat, nem pedig az adatfolyam eredeti eszközeire.

A felhőátjáró a felhő peremén fogadja az eszközeseményeket egy megbízható, alacsony késésű üzenetküldő rendszeren keresztül.

Az eszközök eseményeket küldhetnek közvetlenül a felhőátjáróba vagy egy helyszíni átjárón keresztül. A helyi átjáró egy speciális, általában az eszközökkel egy helyen található eszköz vagy szoftver, amely fogadja az eseményeket, majd továbbítja őket a felhőátjárónak. A mezőátjáró a nyers eszközeseményeket is előfeldolgozásra használhatja, beleértve a szűrési, összesítési vagy protokollátalakítási függvények végrehajtását is.

A betöltés után az események egy vagy több streamfeldolgozón mennek keresztül, amelyek átirányíthatják az adatokat a célhelyekre, például a tároláshoz, vagy elemzést és egyéb feldolgozást végezhetnek.

A feldolgozás gyakori típusai a következők:

• Eseményadatok írása hideg tárolóba archiválás vagy kötegelt elemzés céljából.

• Gyakori elérésű elemzések. Elemezze az eseményfolyamot közel valós időben, hogy észlelje az anomáliákat, felismerje a mintákat a gördülő időablakokban, vagy riasztásokat aktiváljon, amikor egy adott feltétel lép fel a streamben.

• Az eszközöktől származó nem telemetriaüzenetek különleges típusainak, például az értesítéseknek és a riasztásoknak a kezelése.

• Gépi tanulás.

Az előző ábrán a szürke mezők olyan IoT-rendszer összetevői, amelyek nem kapcsolódnak közvetlenül az eseménystreameléshez. A teljesség érdekében a diagram tartalmazza őket.

• Az eszközregisztrációs adatbázis a kiépített eszközök adatbázisa, beleértve az eszközazonosítókat és általában az eszköz metaadatait, például a helyet.

• A kiépítési API- az új eszközök kiépítésének és regisztrálásának gyakori külső felülete.

• Egyes IoT-megoldások lehetővé teszik parancs- és vezérlőüzenetek küldését az eszközökre.

Következő lépések

• IoT Hub
• Event Hubs
• Stream Analytics
• Azure Data Explorer
• Szövet
• Azure Databricks

Kapcsolódó erőforrások

• IoT-architektúrák
• Nagy adatok architektúra stílus
• Modern elemzési architektúra az Azure Databricksszel
• Big data-architektúrák a Fabric használatával