In de afgelopen decennia zijn de databanken en de gegevensanalyse drastisch veranderd.
Bedrijven hebben steeds complexere eisen voor het analyseren en gebruiken van data – en steeds hogere standaarden voor query-prestaties.
Het geheugen is goedkoop geworden, waardoor een vervangende set van prestatiestrategieën ondersteund in-memory analyse mogelijk is geworden.
CPU’s en GPU’s zijn toegenomen in prestaties, maar zijn ook geëvolueerd om de verwerking van data te optimaliseren.
Er zijn nieuwe soorten databases ontstaan voor verschillende use cases, elk met een eigen manier om gegevens op te slaan en te indexeren. Zo zijn bijvoorbeeld real-world objecten makkelijker weer te geven als hiërarchische en geneste datastructuren, JSON- en documentdatabases populair geworden.
Er zijn nieuwe disciplines ontstaan, waaronder data-engineering en datawetenschap, beide met tientallen nieuwste tools om specifieke analytische doelen te realiseren.
Kolomvormige datarepresentaties werden mainstream voor analytische werklasten omdat ze dramatische voordelen bieden in termen van snelheid en efficiëntie.
Met deze trends in gedachten ontstond een transparante mogelijkheid voor een typische in-memory representatie die elke motor kan gebruiken; een die modern is, die gebruik maakt van alle nieuwe prestatiestrategieën die nu beschikbaar zijn; en een die het delen van kennis tussen platforms naadloos en efficiënt creëert. dit is vaak het doel van Apache Arrow. Lees meer over het ontstaan en de geschiedenis van Apache Arrow.
Om een analogie te gebruiken, kunt u overwegen om naar Europa te reizen op vakantie voor de EU. om naar 5 landen te gaan in 7 dagen, berekent u het feit dat u gewoon een paar uur aan de grens ging doorbrengen voor de paspoortcontrole, en u een aantal van uw geld ging verliezen binnen de valutawissel. dit is vaak hoe het werken met data in-memory werkt zonder Arrow: er bestaan enorme inefficiënties om datastructuren te serialiseren en te de-serialiseren, en er wordt een replica gevormd binnen het proces, waardoor uw geheugen en CPU-resources worden verspild. In tegenstelling tot Arrow is het alsof je Europa na de EU en dus de Euro bezoekt: je wacht niet bij de grens, en er wordt overal één valuta gebruikt.
Arrow combineert de voordelen van kolomvormige datastructuren met in-memory computing. Het biedt de prestatievoordelen van die moderne technieken en zorgt tegelijkertijd voor de buigzaamheid van complexe gegevens en dynamische schema’s. En dat alles op een open source en gestandaardiseerde manier.
Apache Pijlpijl Kerntechnologieën
Apache Arrow zelf is geen opslag- of uitvoeringsmotor. het is ontworpen om een gemeenschappelijke basis te vormen voor de volgende soorten systemen:
SQL-uitvoeringsengines (zoals Drill en Impala)…
Data-analysesystemen (zoals Panda’s en Spark)
Streaming en wachtrijsystemen (zoals Kafka en Storm)
Opslagsystemen (zoals Parket, Koedoe, Cassandra en HBase)
Arrow bestaat uit verschillende verbonden technologieën die zijn ontworpen om te worden geïntegreerd in opslag- en uitvoeringsmotoren. De belangrijkste onderdelen van Arrow zijn onder andere:
Gedefinieerde Data Type Sets met zowel SQL- als JSON-types, zoals Int, BigInt, Decimal, VarChar, Map, Structure en Array.
Canonical Representations: Kolomvormige in-memory representaties van kennis ter ondersteuning van een willekeurig complexe recordstructuur die bovenop de gedefinieerde gegevenstypen is gebouwd.
Gemeenschappelijke gegevensstructuren: Pijlbewuste begeleidende gegevensstructuren, inclusief keuzelijsten, hashtabellen en wachtrijen.
Interprocescommunicatie binnen gedeeld geheugen, TCP/IP en RDMA.
Gegevensbibliotheken voor het lezen en schrijven van kolomgegevens in meerdere talen, waaronder Java, C++, Python, Ruby, Rust, Go en JavaScript.
Pijplijn- en SIMD-algoritmen voor diverse bewerkingen, waaronder bitmap-selectie, hashing, filtering, bucketing, sorteren en matchen.
Columnar In-Memory Compression inclusief een set van technieken om de efficiëntie van het geheugen uit te breiden.
Geheugenpersistentiehulpmiddelen voor kortstondige persistentie via niet-vluchtig geheugen, SSD of HDD.
Als zodanig concurreert Arrow niet met een van deze projecten. Het kerndoel is om binnen elk van deze projecten te komen tot betere prestaties en een sterkere interoperabiliteit. In feite wordt Arrow gebouwd door de hoofdontwikkelaars van de vele van deze projecten.
Prestaties
Hoe sneller een gebruiker bij de oplossing kan komen, hoe sneller hij of zij andere vragen zal stellen. Hoge prestaties leiden tot meer analyse, meer use cases en verdere innovatie. Naarmate CPU’s sneller en geavanceerder worden, is een van de belangrijkste uitdagingen ervoor te zorgen dat de verwerkingstechnologie CPU’s efficiënt gebruikt.
Arrow is specifiek ontworpen om te maximaliseren:
Cache Locality: Geheugenbuffers zijn compacte weergaven van kennis die zijn ontworpen voor hedendaagse CPU’s. De structuren zijn lineair gedefinieerd en komen overeen met typische leespatronen. Dit betekent dat gegevens van een vergelijkbaar type in het geheugen worden opgeslagen. Dit maakt het prefetching van cache eenvoudiger, waardoor CPU stalls als gevolg van cache misses en toegang tot het hoofdgeheugen worden geminimaliseerd. Deze CPU-efficiënte gegevensstructuren en toegangspatronen bereiken zowel traditionele platte relationele structuren als moderne complexe gegevensstructuren.
Pipelining: Uitvoeringspatronen zijn ontworpen om voordeel te halen uit de superscalaire en pipelined aard van recente processoren. dit wordt vaak gedaan door het minimaliseren van het aantal in-loop instructies en de complexiteit van de lus. Deze strakke lussen zorgen voor betere prestaties en minder uitval van vertakkingen.
SIMD Instructies: Single Instruction Multiple Data (SIMD) instructies maken het mogelijk dat uitvoeringsalgoritmes efficiënter werken door meerdere bewerkingen uit te voeren tijdens een enkele klokcyclus. Pijltje organiseert de gegevens die aan SIMD-bewerkingen moeten worden aangepast.
Cache locality, pipelining en superscalarbewerkingen zorgen vaak voor een 10-100x snellere uitvoering. Aangezien veel analytische werklasten CPU-gebonden zijn, vertalen deze voordelen zich in een dramatische prestatiewinst voor de eindgebruiker. Hier zijn enkele voorbeelden:
PySpark: IBM heeft een 53x hogere snelheid gemeten in de verwerking door Python en Spark na het toevoegen van ondersteuning voor Arrow in PySpark.
Parket en C++: Inlezen van gegevens in Parket van C++ met maximaal 4GB/s
Panda’s: Lezen in panda’s tot 10GB/s
Arrow bevordert ook zero-copy-datadeling. Aangezien Arrow wordt overgenomen omdat de representatie in elk systeem, kan het ene systeem gegevens doorgeven aan het andere systeem voor het verbruik. En wanneer deze systemen zich op een gelijkwaardig knooppunt bevinden, kan de hierboven beschreven kopie ook worden vermeden door gebruik te maken van gedeeld geheugen. dit suggereert dat in veel gevallen het verplaatsen van gegevens tussen twee systemen geen overhead zal hebben.
Geheugenefficiëntie
In-memory performance is geweldig, maar het geheugen is vaak schaars. Pijltje is bedoeld om te figureren, hoewel de info niet helemaal in het geheugen past. De kernopstelling bevat vectoren van kennis en verzamelingen van die vectoren (ook wel recordbatches genoemd). Recordbatches zijn meestal 64KB-1MB, rekeninghoudend met de werklast, en zijn meestal gebonden aan 2^16 records. Dit verbetert niet alleen de locatie van de cache, maar maakt ook in-memory computing mogelijk, zelfs in low-memory situaties.
Met veel Big Data clusters vanaf 100’s tot 1000’s servers, moeten systemen klaar zijn om het gemengde geheugen van een cluster te verzilveren. Arrow is bedoeld om de waarde van bewegende data op het netwerk te dempen. Het maakt gebruik van scatter/verzamelen leest en schrijft en is voorzien van een nul-serialisatie/deserialisatie ontwerp, waardoor goedkope databewegingen tussen knooppunten mogelijk zijn. Arrow werkt ook direct met RDMA-geschikte verbindingen om één geheugenraster te leveren voor grotere in-memory workloads.
Programmeertaalondersteuning
Een ander groot voordeel van het aannemen van Apache Arrow, naast sterkere prestaties en interoperabiliteit, kan een level-playing field zijn tussen verschillende programmeertalen. Traditionele gegevensuitwisseling is gebaseerd op IPC- en API-niveau-integraties. Hoewel dit vaak eenvoudig is, schaadt het de prestaties wanneer de taal van de gebruiker anders is dan de taal van het onderliggende systeem. Rekenend op de taal en dus de geïmplementeerde set van algoritmen, veroorzaakt de taaltransformatie het grootste deel van het tijdsinterval.