Amazone Athene is een interactieve query-service waarmee u eenvoudig gegevens kunt analyseren in Amazon eenvoudige opslagservice (Amazon S3) met standaard SQL. Athena is serverloos, dus er is geen infrastructuur om te beheren en u betaalt alleen voor de query's die u uitvoert.

Amazone-ion is een rijkelijk getypt, zichzelf beschrijvend, aanbod van hiërarchische gegevensserialisatie-indeling verwisselbaar binair en tekst voorstellingen. De tekstformaat strekt JSON (wat betekent dat alle JSON-bestanden geldige Ion-bestanden zijn), en is gemakkelijk te lezen en te schrijven, en ondersteunt rapid prototyping. De binaire representatie is efficiënt om op te slaan, te verzenden en te parseren. Het rich type-systeem biedt ondubbelzinnige semantiek voor het langdurig bewaren van gegevens die meerdere generaties software-evolutie kunnen overleven.

Athena ondersteunt nu het opvragen en schrijven van gegevens in Ion-formaat. Het Ion-formaat wordt momenteel gebruikt door interne Amazon-teams, door externe diensten zoals Amazon Quantum Ledger-database (Amazone QLDB) en Amazon DynamoDB (die kan worden geëxporteerd naar Ion), en in de open-source SQL-querytaal PartiQL.

In dit bericht bespreken we use cases en de unieke functies die Ion biedt, gevolgd door voorbeelden van het bevragen van Ion met Athena. Voor demonstratiedoeleinden gebruiken we de getransformeerde versie van de Stad Veel San Francisco gegevensset.

Kenmerken van ion

In deze sectie bespreken we enkele van de unieke functies die Ion biedt:

• Type systeem
• Dubbel formaat
• Efficiencywinst
• Scannen overslaan

Type systeem

Ion breidt JSON uit en voegt ondersteuning toe voor meer precisie Datatypen om de interpreteerbaarheid te verbeteren, de verwerking te vereenvoudigen en afrondingsfouten te voorkomen. Deze zeer nauwkeurige numerieke typen zijn essentieel voor financiële diensten, waar fracties van een cent op elke transactie optellen. Gegevenstypen die worden toegevoegd zijn gehele getallen van willekeurige grootte, binaire getallen met drijvende komma, decimalen met oneindige precisie, tijdstempels, CLOBS en BLOBS.

Dubbel formaat

Gebruikers kunnen een vertrouwde op tekst gebaseerde weergave te zien krijgen terwijl ze profiteren van de prestatie-efficiëntie van een binair formaat. De interoperabiliteit tussen de twee indelingen stelt u in staat om snel gegevens te ontdekken, te verwerken en te interpreteren in een bekende JSON-achtige weergave, terwijl onderliggende toepassingen profiteren van een vermindering van opslag, geheugen, netwerkbandbreedte en latentie van het binaire formaat. Dit betekent dat u query's in platte tekst kunt schrijven die worden uitgevoerd tegen zowel op tekst gebaseerde als binaire Ion. U kunt delen van uw gegevens herschrijven in op tekst gebaseerde Ion wanneer u tijdens de ontwikkeling door mensen leesbare gegevens nodig heeft en overschakelt naar binair in productie.

Bij het debuggen van een proces is het van vitaal belang dat systeemtechnici gegevens kunnen lokaliseren en zo snel mogelijk kunnen begrijpen. Ion biedt mechanismen om te schakelen tussen een binaire en een op tekst gebaseerde weergave, waarbij zowel de mens als de machine wordt geoptimaliseerd. Athena ondersteunt het opvragen en schrijven van gegevens in beide Ion-formaten. Het volgende is een voorbeeld van een Ion-tekstdocument uit de getransformeerde versie van het citylots dataset:

{ "type": "Feature"
, "properties": { "MAPBLKLOT": "0004002"
                 ,"BLKLOT": "0004002"
                 ,"BLOCK_NUM": "0004"
                 , "LOT_NUM": "002"
                 , "FROM_ST": "0"
                 , "TO_ST": "0"
                 , "STREET": "UNKNOWN"
                 , "ST_TYPE": null
                 , "ODD_EVEN": "E" }
, "geometry": { "type": "Polygon"
               , "coordinates": [ [ [ -122.415701204606876, 37.808327252671461, 0.0 ],
                                    [ -122.415760743593196, 37.808630700240904, 0.0 ],
                                    [ -122.413787891332404, 37.808566801319841, 0.0 ],
                                    [ -122.415701204606876, 37.808327252671461, 0.0 ] ] ] } }

Efficiencywinst

Binair gecodeerd Ion verkleint de bestandsgrootte door herhaalde waarden, zoals veldnamen, te verplaatsen naar een symbool tafel. Symbolentabellen verminderen de CPU- en leeslatentie door de validatie van tekencodering te beperken tot de enkele instantie van de waarde in de symbolentabel.

Een bedrijf dat op de schaal van Amazon opereert, kan bijvoorbeeld grote hoeveelheden applicatielogboeken produceren. Bij het comprimeren van Ion- en JSON-logboeken merkten we ongeveer 35% minder CPU-tijd om het logboek te comprimeren, wat gemiddeld ongeveer 26% kleinere bestanden opleverde. Logbestanden zijn van cruciaal belang wanneer ze nodig zijn, maar kostbaar om te behouden, dus de vermindering van de bestandsgrootte in combinatie met de verbeterde leesprestaties van symbooltabellen helpt bij het verwerken van deze logboeken. Het volgende is een voorbeeld van het verkleinen van de bestandsgrootte met de citylots JSON-dataset bij conversie naar Ion-binair met GZIP- en ZSTD-compressie:

77MB    citylots.ion
 17MB    citylots.ion.gz
 15MB    citylots.ion.zst
181MB    citylots.json
 22MB    citylots.json.gz
 18MB    citylots.json.zst

Scannen overslaan

In een tekstformaat moet elke byte worden gelezen en geïnterpreteerd, maar omdat het binaire formaat van Ion een TLV-codering (type-lengte-waarde) is, kan een toepassing elementen overslaan die niet nodig zijn. Dit verlaagt de verwerkingskosten voor query's en toepassingen die verband houden met het aandeel niet-onderzochte velden.

Forensische analyse van toepassingsloggegevens omvat bijvoorbeeld het lezen van grote hoeveelheden gegevens waarbij slechts een fractie van de gegevens nodig is voor diagnose. In deze scenario's stelt skip-scannen de binaire ionenlezer in staat om langs irrelevante velden te bewegen zonder de kosten van het lezen van het element dat in een veld is opgeslagen. Dit resulteert in gebruikers die een lager gebruik van bronnen en snellere reactietijden ervaren.

Query Ion datasets met behulp van Athena

Athena ondersteunt nu het opvragen en creëren van Ion-geformatteerde datasets via een Ion-specifieke SerDe, die in combinatie met IonInputFormat en IonOutputFormat stelt u in staat geldige Ion-gegevens te lezen en te schrijven. Met deserialisatie kunt u SELECT-query's uitvoeren op de Ion-gegevens, zodat deze kunnen worden opgevraagd om inzichten te verkrijgen. Serialisatie via CTAS- of INSERT INTO-query's stelt u in staat gegevenssets te kopiëren van bestaande tabelwaarden of nieuwe gegevens te genereren in het Ion-formaat.

De uitwisselbare aard van Ion-tekst en Ion-binair betekent dat Athena datasets kan lezen die beide soorten bestanden bevatten. Omdat Ion een superset is van JSON, kan een tabel die de Ion SerDe gebruikt ook JSON-bestanden bevatten. In tegenstelling tot de JSON SerDe, waarbij elk nieuw regelteken een nieuwe rij aangeeft, gebruikt de Ion SerDe een combinatie van haakjes sluiten en nieuwe regeltekens om nieuwe rijen te bepalen. Dit betekent dat als elk JSON-record in uw brondocumenten niet op één regel staat, deze bestanden nu in Athena kunnen worden gelezen via de Ion SerDe.

Maak externe tabellen

Athena ondersteunt het opvragen van op Ion gebaseerde datasets door te definiëren AWS lijm tabellen met de door de gebruiker gedefinieerde metadata. Laten we beginnen met een voorbeeld van het maken van een externe tabel voor een gegevensset die is opgeslagen in Ion-tekst. Het volgende is een voorbeeldrij uit de citylots dataset:

{
    type:"Feature",
    properties:{
        mapblklot:"0579021",
        blklot:"0579024",
        block_num:"0579",
        lot_num:"024",
        from_st:"2160",
        to_st:"2160",
        street:"PACIFIC",
        st_type:"AVE",
        odd_even:"E"
    },
    geometry:{
        type:"Polygon",coordinates:[[[-122.4308798855922, ...]]]
    }
}

Om een ​​externe tabel te maken waarvan de gegevens in Ion zijn opgeslagen, heb je twee syntactische opties.

Ten eerste kunt u STORED AS ION specificeren. Dit is een meer beknopte methode en kan het beste worden gebruikt voor eenvoudige gevallen waarin geen aanvullende eigenschappen vereist zijn. Zie de volgende code:

CREATE EXTERNAL TABLE city_lots_ion1 (
  type STRING,
  properties struct<
    mapblklot:string,
    blklot:string,
    block_num:string,
    lot_num:string,
    from_st:string,
    to_st:string,
    street:string,
    st_type:string,
    odd_even:string>,
  geometry struct<
    type:string,
    coordinates:array<array<array<decimal(18,15)>>>,
    multi_coordinates:array<array<array<array<decimal(18,15)>>>>>
)
STORED AS ION
LOCATION 's3://aws-bigdata-blog/artifacts/athena-ion-blog/city_lots_ion_binary/'

U kunt ook expliciet de Ion-klassenpaden specificeren in ROW FORMAT SERDE, INPUTFORMAT en OUTPUTFORMAT. In tegenstelling tot de eerste methode kunt u hier een SERDEPROPERTIES-clausule opgeven. In ons voorbeeld-DDL hebben we een SerDe-eigenschap toegevoegd waarmee waarden die buiten het Hive-gegevenstypebereik vallen, kunnen overlopen in plaats van de query te laten mislukken:

CREATE EXTERNAL TABLE city_lots_ion2(
  type STRING,
  properties struct<
    mapblklot:string,
    blklot:string,
    block_num:string,
    lot_num:string,
    from_st:string,
    to_st:string,
    street:string,
    st_type:string,
    odd_even:string>,
  geometry struct<
    type:string,
    coordinates:array<array<array<decimal(18,15)>>>,
    multi_coordinates:array<array<array<array<decimal(18,15)>>>>>
)
ROW FORMAT SERDE
  'com.amazon.ionhiveserde.IonHiveSerDe'
WITH SERDEPROPERTIES (
 'ion.fail_on_overflow'='false'
 )
STORED AS INPUTFORMAT
  'com.amazon.ionhiveserde.formats.IonInputFormat'
OUTPUTFORMAT
  'com.amazon.ionhiveserde.formats.IonOutputFormat'
LOCATION
  's3://aws-bigdata-blog/artifacts/athena-ion-blog/city_lots_ion_binary/'

Athena converteert STORED AS ION naar de expliciete klassenpaden, zodat beide tabellen er in de metastore hetzelfde uitzien. Als we in AWS Glue kijken, zien we dat beide tabellen die we zojuist hebben gemaakt hetzelfde invoerformaat, hetzelfde uitvoerformaat en dezelfde SerDe-serialisatiebibliotheek hebben.

Nu onze tabel is gemaakt, kunnen we standaard SELECT-query's uitvoeren op de city_lots_ion tafel. Laten we een query uitvoeren die de block_num uit onze voorbeeldrij met Ion-gegevens om te verifiëren dat we uit de tabel kunnen lezen:

-- QUERY
SELECT * FROM city_lots_ion1 WHERE properties.block_num='0579';

De volgende schermafbeelding toont onze resultaten.

Gebruik padextractie om uit specifieke velden te lezen

Athena ondersteunt verdere aanpassing van hoe gegevens worden geïnterpreteerd via SerDe eigenschappen. Om deze te specificeren, kunt u een clausule WITH SERDEPROPERTIES toevoegen, een subveld van het veld ROW FORMAT SERDE.

In sommige situaties geven we alleen om sommige delen van de informatie. Laten we veronderstellen dat we geen geometrie-informatie van de citylots dataset en hebben slechts enkele velden in eigenschappen nodig. Een oplossing is om een ​​zoekpad op te geven met behulp van de eigenschap Path Extractor SerDe:

-- Path Extractor property
ion.<column>.path_extractor = <search path>

Padextractors zijn zoekpaden die Athena gebruikt om de tabelkolommen toe te wijzen aan locaties in het individuele document. Volledige informatie over wat er kan worden gedaan met padextractors is beschikbaar op GitHub, maar voor ons voorbeeld richten we ons op het maken van eenvoudige paden die de namen van elk veld als index gebruiken. In dit geval heeft het zoekpad de vorm van een door spaties gescheiden set indexen (en wordt deze tussen haakjes geplaatst) die de locatie van elk gewenst stuk informatie aangeven. We wijzen de zoekpaden toe aan tabelkolommen met behulp van de eigenschap Path Extractor.

Standaard bouwt Athena padextractors dynamisch op basis van kolomnamen, tenzij overschreven. Dit betekent dat wanneer we onze SELECT-query uitvoeren op onze city_lots_ion1 tabel, bouwt Athena de volgende zoekpaden:

Default Extractors generated by Athena for city_lots_ion1.
-- Extracts the 'type' field to the 'type' column
    'ion.type.path_extractor' = '(type)'

-- Extracts the 'properties' field to the 'properties' column
    'ion.properties.path_extractor' = '(properties)'

-- Extracts the 'geometry' field to the 'geometry' column
    'ion.geometry.path_extractor' = '(geometry)'

Ervan uitgaande dat we alleen geïnteresseerd zijn in de blok- en partijinformatie van de eigenschappenstructuur en het geometrietype van de geometriestructuur, kunnen we zoekpaden bouwen die de gewenste velden uit de rij met gegevens toewijzen aan tabelkolommen. Laten we eerst de zoekpaden bouwen:

(properties mapblklot) - Search path for the mapblklot field in the properties struct
(properties blklot) - Search path for the blklot field in the properties struct
(properties block_num) - Search path for the block_num field in the properties struct
(properties lot_num) - Search path for the lot_num field in the properties struct
(geometry type) - Search path for the type field in the geometry struct

Laten we deze zoekpaden nu toewijzen aan tabelkolommen met behulp van de eigenschap Path Extractor SerDe. Omdat de zoekpaden specificeren waar naar gegevens moet worden gezocht, kunnen we onze datasets afvlakken en hernoemen om ons doel beter te dienen. Laten we voor dit voorbeeld de naam van het mapblklot veld naar map_block_lot, blklot naar block_lot, en het type geometrie dat moet worden gevormd:

 'ion.map_block_lot.path_extractor' = '(properties mapblklot)'
 'ion.block_lot.path_extractor' = '(properties blklot)'
 'ion.block_num.path_extractor' = '(properties block_num)'
 'ion.lot_num.path_extractor' = '(properties lot_num)'
 'ion.shape.path_extractor' = '(geometry type)'

Laten we dit allemaal samenvoegen en de city_blocks tafel:

CREATE EXTERNAL TABLE city_blocks (
    map_block_lot STRING,
    block_lot STRING,
    block_num STRING,
    lot_num STRING,
    shape STRING
)
ROW FORMAT SERDE
 'com.amazon.ionhiveserde.IonHiveSerDe'
WITH SERDEPROPERTIES (
 'ion.map_block_lot.path_extractor' = '(properties mapblklot)',
 'ion.block_lot.path_extractor' = '(properties blklot)',
 'ion.block_num.path_extractor' = '(properties block_num)',
 'ion.lot_num.path_extractor' = '(properties lot_num)',
 'ion.shape.path_extractor' = '(geometry type)'
 )
STORED AS ION
LOCATION 's3://aws-bigdata-blog/artifacts/athena-ion-blog/city_lots_ion_binary/'

Nu kunnen we een selectiequery uitvoeren op de city_blocks tabel en bekijk de resultaten:

-- Select Query
SELECT * FROM city_blocks WHERE block_num='0579';

Door op deze manier zoekpaden te gebruiken, is het mogelijk om scans over te slaan bij het lezen van binaire Ion-bestanden, waardoor Athena de onnodige velden kan overslaan en de totale tijd die nodig is om de query uit te voeren, wordt verkort.

Gebruik CTAS en UNLOAD voor gegevenstransformatie

Athene ondersteunt MAAK TABEL ALS SELECT (CTAS), waarmee een nieuwe tabel in Athena wordt gemaakt op basis van de resultaten van een SELECT-instructie van een andere query. Athene ondersteunt ook LOSSEN, die queryresultaten naar Amazon S3 schrijft van een SELECT-instructie naar het opgegeven gegevensformaat.

Zowel CTAS als UNLOAD hebben een eigenschap om een ​​indeling en een compressietype op te geven. Hierdoor kunt u eenvoudig Ion-gegevenssets converteren naar andere gegevensindelingen, zoals Parquet of ORC, en vice versa, zonder dat u een complexe extractie-, transformatie- en laadtaak (ETL) hoeft op te zetten. Dit is handig voor situaties waarin u uw gegevens wilt transformeren, of weet dat u herhaalde query's zult uitvoeren op een subset van uw gegevens en enkele van de voordelen wilt gebruiken die inherent zijn aan kolomindelingen. Het is vooral handig om het te combineren met padextractors, omdat we alleen de gegevens opslaan die we nodig hebben in het nieuwe formaat.

Laten we CTAS gebruiken om onze te converteren city_blocks table van Ion naar Parquet en comprimeer deze via GZIP. Omdat we padextractors hebben ingesteld voor de city_blocks tabel, hoeven we slechts een klein deel van de originele dataset te converteren:

CREATE TABLE city_blocks_parquet_gzip
WITH (format = 'PARQUET', write_compression='GZIP')
AS SELECT * FROM city_blocks;

We kunnen nu query's uitvoeren tegen de city_block_parquet_gzip table, en zou hetzelfde resultaat moeten zien. Om dit te testen, laten we dezelfde SELECT-query uitvoeren die we eerder hebben uitgevoerd op de Parquet-tabel:

SELECT * FROM city_blocks_parquet_gzip WHERE block_num='0579';

Bij het converteren van tabellen van een ander formaat naar Ion, ondersteunt Athena de volgende compressiecodecs: ZSTD, BZIP2, GZIP, SNAPPY en NONE. Naast het toevoegen van Ion als een nieuw formaat voor CTAS, hebben we de ion_encoding eigenschap, waarmee u kunt kiezen of de uitvoerbestanden worden gemaakt in Ion-tekst of Ion-binair. Hierdoor kunnen gegevens van andere formaten worden geserialiseerd naar Ion.

Laten we het origineel converteren city_lots JSON-bestand terug naar Ion, maar deze keer specificeren we dat we ZSTD-compressie en een binaire codering willen gebruiken.

Het JSON-bestand is te vinden op de volgende locatie: s3://aws-bigdata-blog/artifacts/athena-ion-blog/city_lots_json/

Omdat Ion een superset is van JSON, kunnen we de Ion SerDe gebruiken om dit bestand te lezen:

CREATE EXTERNAL TABLE city_blocks_json_ion_serde (
    map_block_lot STRING,
    block_lot STRING,
    block_num STRING,
    lot_num STRING,
    shape STRING
)
ROW FORMAT SERDE
'com.amazon.ionhiveserde.IonHiveSerDe'
WITH SERDEPROPERTIES (
'ion.map_block_lot.path_extractor' = '(properties mapblklot)',
'ion.block_lot.path_extractor' = '(properties blklot)',
'ion.block_num.path_extractor' = '(properties block_num)',
'ion.lot_num.path_extractor' = '(properties lot_num)',
'ion.shape.path_extractor' = '(geometry type)'
)
STORED AS ION
LOCATION 's3://aws-bigdata-blog/artifacts/athena-ion-blog/city_lots_json/'

Laten we nu deze tabel kopiëren naar onze gewenste binaire Ion-vorm:

CREATE TABLE city_blocks_ion_zstd
WITH (format = 'ION', write_compression='ZSTD', ion_encoding='BINARY')
AS SELECT * FROM city_blocks_parquet_gzip

Laten we tot slot onze verificatie SELECT-instructie uitvoeren om te controleren of alles correct is gemaakt:

SELECT * FROM city_blocks_ion_zstd WHERE block_num='0579'; 

Gebruik UNLOAD om Ion-gegevens op te slaan in Amazon S3

Soms willen we de gegevens gewoon opnieuw formatteren en hoeven we de aanvullende metagegevens niet op te slaan om de tabel te doorzoeken. In dit geval kunnen we UNLOAD gebruiken, waarmee de resultaten van de query in het opgegeven formaat in een S3-bucket worden opgeslagen.

Laten we het eens testen, met behulp van UNLOAD om de drivers_names tabel van Ion naar ORC, comprimeer het via ZLIB en sla het op in een S3-bucket:

UNLOAD (SELECT * FROM city_blocks_ion_zstd WHERE block_num='0579')
TO 's3://<your-s3-bucket>/athena-ion-blog/unload/orc_zlib/'
WITH (format = 'ORC', compression='ZLIB')

Wanneer u Amazon S3 incheckt, kunt u een nieuw bestand vinden in het ORC-formaat.

Conclusie

Dit bericht ging over de nieuwe functie in Athena waarmee je Ion-datasets kunt opvragen en maken met behulp van standaard SQL. We bespraken use cases en unieke kenmerken van het Ion-formaat zoals typesysteem, dubbele formaten (Ion-tekst en Ion-binair), efficiëntiewinsten en skip-scanning. U kunt aan de slag met het opvragen van een Ion-dataset die is opgeslagen in Amazon S3 door simpelweg een tabel in Athena te maken en bestaande datasets te converteren naar Ion-indeling en vice versa met behulp van CTAS- en UNLOAD-instructies.

Raadpleeg voor meer informatie over het opvragen van Ion met Athena Amazon Ion Hive SerDe.

Referenties

Over de auteurs

Pathik Sjah is Sr. Big Data Architect op Amazon Athena. Hij kwam in 2015 bij AWS en richt zich sindsdien op de big data-analyseruimte, waarbij hij klanten helpt bij het bouwen van schaalbare en robuuste oplossingen met behulp van AWS-analyseservices.

Jacob Stein werkt in het Amazon Athena-team als Software Development Engineer. Hij leidde het project om ondersteuning voor Ion in Athena toe te voegen. Hij werkt graag aan technische problemen die uniek zijn voor gegevens op internetschaal, en is gepassioneerd door het ontwikkelen van schaalbare oplossingen voor gedistribueerde systemen.

Giovanni Matteo Fumarola is de Engineering Manager van het Athena Data Lake and Storage-team. Hij is een Apache Hadoop Committer en PMC-lid. Hij richt zich sinds 2013 op de big data-analyseruimte.

Piet Ford is Sr. Technical Program Manager bij Amazon.