Registrera sig
Stora data

Berikande metadata för korrekt text-till-SQL-generering för Amazon Athena | Amazon webbtjänster

Tycka om
Gillade
Återutgiven av Platon
Återutgiven av Platon

Datum:

21 MinLäsa
Visningar: 205

Att extrahera värdefulla insikter från massiva datamängder är avgörande för företag som strävar efter att få en konkurrensfördel. Företagsdata förs in i datasjöar och datalager för att utföra analytiska, rapporterings- och datavetenskapliga användningsfall med hjälp av AWS-analystjänster som Amazonas Athena, Amazon RedShift, Amazon EMR, Och så vidare. Amazonas Athena tillhandahåller interaktiv analystjänst för att analysera data i Amazon Simple Storage Service (Amazon S3). Amazon RedShift används för att analysera strukturerad och semistrukturerad data över datalager, operativa databaser och datasjöar. Amazon EMR tillhandahåller en stordatamiljö för databearbetning, interaktiv analys och maskininlärning med ramverk med öppen källkod som Apache Spark, Apache Hive och Presto. Dessa databehandlings- och analystjänster stödjer Structured Query Language (SQL) för att interagera med data.

Att skriva SQL-frågor kräver inte bara att komma ihåg SQL-syntaxreglerna, utan också kunskap om tabellernas metadata, vilket är data om tabellscheman, relationer mellan tabellerna och möjliga kolumnvärden. Stor språkmodell (LLM)-baserad generativ AI är en ny tekniktrend för att förstå en stor mängd information och hjälpa till med komplexa uppgifter. Kan det också hjälpa att skriva SQL-frågor? Svaret är ja.

Generativa AI-modeller kan översätta naturliga språkfrågor till giltiga SQL-frågor, en funktion som kallas text-till-SQL-generering. Även om LLM:er kan generera syntaktisk korrekta SQL-frågor, behöver de fortfarande tabellens metadata för att skriva korrekt SQL-fråga. I det här inlägget visar vi den kritiska rollen för metadata i text-till-SQL-generering genom ett exempel implementerat för Amazon Athena med Amazonas berggrund. Vi diskuterar utmaningarna med att underhålla metadata samt sätt att övervinna dessa utmaningar och berika metadata.

Lösningsöversikt

Det här inlägget visar text-till-SQL-generering för Athena med hjälp av ett exempel implementerat med hjälp av Amazonas berggrund. Vi använder Antropics Claude 2.1 grundmodell (FM) i Amazon Bedrock som LLM. Amazon Bedrock-modeller åberopas med hjälp av Amazon SageMaker. Arbetsexempel är utformade för att visa hur olika detaljer som ingår i metadatan påverkar SQL som genereras av modellen. Dessa exempel använder syntetiska datauppsättningar skapade i AWS-lim och Amazon S3. Efter att vi har granskat betydelsen av dessa metadatadetaljer kommer vi att fördjupa oss i de utmaningar som uppstår när vi samlar in den nödvändiga nivån av metadata. Därefter kommer vi att utforska strategier för att övervinna dessa utmaningar.

Exemplen som implementeras i arbetsflödet illustreras i följande diagram.

lösningsarkitekturen och arbetsflödet

Figur 1. Lösningsarkitekturen och arbetsflödet.

Arbetsflödet följer följande sekvens:

  1. En användare ställer en textbaserad fråga som kan besvaras genom att fråga relevanta AWS Glue-tabeller genom Athena.
  2. Tabellmetadata hämtas från AWS Glue.
  3. Tabellernas metadata och SQL-genereringsinstruktioner läggs till i promptmallen. Claude AI-modellen anropas genom att skicka prompten och modellparametrarna.
  4. Claude AI-modellen översätter användarens avsikt (fråga) till SQL baserat på instruktionerna och tabellernas metadata.
  5. Den genererade Athena SQL-frågan körs.
  6. Den genererade Athena SQL-frågan och SQL-frågeresultaten returneras till användaren.

Förutsättningar

Dessa förutsättningar ges om du vill prova detta exempel själv. Du kan hoppa över detta förutsättningsavsnitt om du vill förstå exemplet utan att implementera det. Exemplet handlar om att anropa Amazon Bedrock-modeller med SageMaker, så vi måste ställa in några resurser i ett AWS-konto. Den relevanta CloudFormation-mallen, Jupyter Notebooks och information om att lansera nödvändiga AWS-tjänster behandlas i det här avsnittet. CloudFormation-mallen skapar SageMaker-instansen med nödvändiga S3-bucket- och IAM-rollbehörigheter för att köra AWS Glue-kommandon, Athena SQL och anropa Amazon Bedrock AI-modeller. De två Jupyter-anteckningsböckerna (0_create_tables_with_metadata.ipynb och 1_text-to-sql-for-athena.ipynb) tillhandahåller fungerande kodavsnitt för att skapa de nödvändiga tabellerna och generera SQL med Claude AI-modellen på Amazon Bedrock.

Ge Anthropics Claude behörigheter på Amazon Bedrock 

  • Ha en AWS-konto och logga in med AWS Management Console.
  • Ändra AWS-regionen till USA Väst (Oregon).
  • Navigera till AWS servicekatalog konsol och välj Amazonas berggrund.
  • Välj på Amazon Bedrock-konsolen Modell Access i navigeringsfönstret.
  • Välja Hantera modellåtkomst.
  • Välj Claude
  • Välja Begär modellåtkomst om du begär åtkomst till modellen för första gången. Välj annars Spara ändringar.

Distribuera CloudFormation-stacken

BDB-4100-CFN-Launch-Stack

Efter att ha startat CloudFormation-stacken:

  • På Skapa stack sida, välj Nästa
  • På Ange stapeldetaljer sida, välj Nästa
  • På Konfigurera stackalternativ sida, välj Nästa
  • På Granska och skapa sida, Välj Jag erkänner att AWS CloudFormation kan skapa IAM-resurser
  • Välja Skicka

Ladda ner Jupyter Notebooks till SageMaker 

  • I AWS Management Console väljer du namnet på den region som för närvarande visas och ändrar den till USA Väst (Oregon).
  • Navigera till AWS Service Catalog-konsolen och välj Amazon SageMaker.
  • Välj på Amazon SageMaker-konsolen Notebook i navigeringsfönstret.
  • Välja Notebook-instanser.
  • Välj SageMakerNotebookInstance skapad av texttosqlmetadata CloudFormation stack.
  • Enligt Actionsväljer Öppna Jupyter
  • Navigera till jupyter konsol, välj Nya, och välj sedan Konsol.
  • Kör följande Shell-skriptkommandon i konsolen för att kopiera Jupyter Notebooks. 
    cd /home/ec2-user/SageMaker
BASE_S3_PATH="s3://aws-blogs-artifacts-public/artifacts/BDB-4265"
aws s3 cp "${BASE_S3_PATH}/0_create_tables_with_metadata.ipynb" ./
aws s3 cp "${BASE_S3_PATH}/1_text_to_sql_for_athena.ipynb" ./

  • Öppna varje nedladdad anteckningsbok och uppdatera värdena för athena_results_bucket, aws_regionoch athena_workgroup variabler baserade på utdata från texttosqlmetadata CloudFormation

Lösning implementering

Om du vill prova det här exemplet själv, prova CloudFormation-mallen som finns i föregående avsnitt. I de efterföljande avsnitten kommer vi att illustrera hur varje element i metadata som ingår i prompten påverkar SQL-frågan som genereras av modellen.

  1. Stegen i 0_create_tables_with_metadata.ipynb Jupyter Notebook skapar Amazon S3-filer med syntetiska data för anställda och avdelningsdatauppsättningar employee_dtls och department_dtls Limma tabeller som pekar på dessa S3-hinkar och extraherar följande metadata för dessa två tabeller. 
    CREATE EXTERNAL TABLE employee_dtls (
	id int COMMENT 'Employee id',
	name string COMMENT 'Employee name',
	age int COMMENT 'Employee age',
	dept_id int COMMENT 'Employee Departments ID',
	emp_category string COMMENT 'Employee category. Contains TEMP For temporary, PERM for permanent, CONTR for contractors ',
	location_id int COMMENT 'Location identifier of the Employee',
	joining_date date COMMENT 'Joining date of the Employee',
	CONSTRAINT pk_1 PRIMARY KEY  (id) ,
	CONSTRAINT FK_1 FOREIGN KEY (dept_id) REFERENCES department_dtls(id)
) 
PARTITIONED BY (
	region_id string COMMENT 'Region identifier. Contains AMER for Americas, EMEA for Europe, the Middle East, and Africa, APAC for Asia Pacific countries'
);

CREATE EXTERNAL TABLE department_dtls (
	id int COMMENT 'Department id',
	name string COMMENT 'Department name',
	location_id int COMMENT 'Location identifier of the Department'
)

  2. Metadata som extraherades i föregående steg ger kolumnbeskrivningar. För den region_id partitionskolumn och emp_category kolumnen ger beskrivningen möjliga värden tillsammans med deras betydelse. Metadata har också information om begränsningar för främmande nyckel. AWS Glue tillhandahåller inte ett sätt att specificera primärnyckeln och främmande nyckelbegränsningar, så använd anpassade nycklar i AWS Glue-tabellnivåparametrarna som ett alternativ för att samla in primärnyckeln och främmande nycklar medan du skapar AWS Glue-tabellen. 
    # Define the table schema
employee_table_input = {
    'Name': employee_table_name,
    'PartitionKeys': [
        {'Name': 'region_id', 'Type': 'string', 'Comment': 'Region identifier. Contains AMER for Americas, EMEA for Europe, the Middle East, and Africa, APAC for Asia Pacific countries'}
    ],
    'StorageDescriptor': {
        'Columns': [
            {'Name': 'id', 'Type': 'int', 'Comment': 'Employee id'},
       …
        ],
        'Location': employee_s3_path,
     …
    'TableType': 'EXTERNAL_TABLE',
    'Parameters': {
        'classification': 'csv',
        'primary_key': 'CONSTRAINT pk_1 PRIMARY KEY  (id)',
        'foreign_key_1': 'CONSTRAINT FK_1 FOREIGN KEY (dept_id) REFERENCES department_dtls(id)'          
    }
}

# Create the table
response = glue_client.create_table(DatabaseName=database_name, TableInput=employee_table_input)

  3. Stegen i 1_text-to-sql-for-athena.ipynb Jupyter notebook skapa följande omslagsfunktion för att interagera med Claude FM på Amazon Bedrock för att generera SQL baserat på användartillhandahållen text inlindad i en prompt. Denna funktion hårdkodar modellens parametrar och modell-ID för att demonstrera den grundläggande funktionaliteten. 
    def interactWithClaude(prompt):

    body = json.dumps(
        {
            "prompt": prompt,
            "max_tokens_to_sample": 2048,
            "temperature": 1,
            "top_k": 250,
            "top_p": 0.999,
            "stop_sequences": [],
        }
    )
    modelId = "anthropic.claude-v2"  
    accept = "application/json"
    contentType = "application/json"
    response = bedrock_client.invoke_model(
        body=body, modelId=modelId, accept=accept, contentType=contentType
    )
    response_body = json.loads(response.get("body").read())
    response_text_claude = response_body.get("completion")
    return response_text_claude

  4. Definiera följande uppsättning instruktioner för att generera Athena SQL-fråga. Dessa SQL-genereringsinstruktioner anger vilken beräkningsmotor som SQL-frågan ska köras på och andra instruktioner för att vägleda modellen i genereringen av SQL-frågan. Dessa instruktioner ingår i uppmaningen som skickas till Bedrock-modellen. 
    athena_sql_generating_instructions = """
Read database schema inside the <database_schema></database_schema> tags which contains a list of table names and their schemas to do the following:
    1. Create a syntactically correct AWS Athena query to answer the question.
    2. For tables with partitions, include the filters on the relevant partition columns.
    3. Include only relevant columns for the given question.
    4. Use only the column names that are listed in the schema description. 
    5. Qualify column names with the table name.
    6. Avoid joins to a table if there is no column required from the table.
    7. Convert Strings to Date type while filtering on Date type columns
    8. Return the sql query inside the <SQL></SQL> tab.
"""

  5. Definiera olika promptmallar för att visa vikten av metadata i text-till-SQL-generering. Dessa mallar har platshållare för SQL-frågegenererande instruktioner och tabellmetadata. 
    athena_prompt1 = """
Human:  You are an AWS Athena query expert whose output is a valid sql query. You are given the following Instructions for building the AWS Athena query.
<Instructions>
{instruction_dtls}
</Instructions>
        
Only use the following tables defined within the database_schema and table_schema XML-style tags:

<database_schema>
<table_schema>
CREATE EXTERNAL TABLE employee_dtls (
  id int,
  name string,
  age int ,
  dept_id int,
  emp_category string ,
  location_id int ,
  joining_date date
) PARTITIONED BY (
  region_id string
  )
</table_schema>

<table_schema>
CREATE EXTERNAL TABLE department_dtls (
  id int,
  name string ,
  location_id int 
)
</table_schema>
</database_schema>

Question: {question}

Assistant: 
"""

  6. Generera den sista prompten genom att skicka frågan och instruktionerna som argument till promptmallen. Anropa sedan modellen. 
    question_asked = "List of permanent employees who work in North America and  joined after Jan 1 2024"
prompt_template_for_query_generate = PromptTemplate.from_template(athena_prompt1)
prompt_data_for_query_generate = prompt_template_for_query_generate.format(question=question_asked,instruction_dtls=athena_sql_generating_instructions)
llm_generated_response = interactWithClaude(prompt_data_for_query_generate)
print(llm_generated_response.replace("<sql>", "").replace("</sql>", " ")  )

  7. Modellen genererar SQL-frågan för användarfrågan genom att använda instruktionerna och tabelldetaljerna i prompten. 
    SELECT employee_dtls.id, employee_dtls.name, employee_dtls.age, employee_dtls.dept_id, employee_dtls.emp_category
FROM employee_dtls 
WHERE employee_dtls.region_id = 'NA' 
  AND employee_dtls.emp_category = 'permanent'
  AND employee_dtls.joining_date > CAST('2024-01-01' AS DATE)

Betydelsen av uppmaningar och metadata i text-till-SQL-generering

Att förstå detaljerna i tabeller och data de innehåller är viktigt för både mänskliga SQL-experter och generativ AI-baserad text-till-SQL-generering. Dessa detaljer, gemensamt kända som metadata, ger ett avgörande sammanhang för att skriva SQL-frågor. För text-till-SQL-exemplet som implementerades i föregående avsnitt använde vi uppmaningar för att förmedla specifika instruktioner och tabellmetadata till modellen, vilket gjorde det möjligt för den att utföra användaruppgifter effektivt. En fråga uppstår på vilken nivå av detaljer vi behöver inkludera i tabellens metadata. För att förtydliga denna punkt bad vi modellen att generera SQL-fråga för samma fråga tre gånger med olika uppmaningar varje gång.

Fråga utan metadata

För det första testet använde vi en grundläggande prompt som bara innehöll SQL-genereringsinstruktionerna och ingen tabellmetadata. Den grundläggande prompten hjälpte modellen att generera en SQL-fråga för den givna frågan, men den är inte till hjälp eftersom modellen gjorde antaganden om tabellnamn, kolumnnamn och bokstavliga värden som används i filteruttrycken.

Fråga: Lista över fast anställda som arbetar i Nordamerika och anslöt sig efter 1 januari 2024.

Snabb definition:

Human: You are an Amazon Athena query expert whose output is a valid sql query. You are given the following Instructions for building the Amazon Athena query.
<Instructions>
{instruction_dtls}
</Instructions>

Question: {question}
Assistant:

SQL-fråga genererad:

SELECT emp.employee_id, emp.first_name, emp.last_name, emp.department_id
FROM employee emp
WHERE emp.contract = 'Permanent'
AND emp.region = 'North America'
AND CAST(emp.start_date AS  DATE) > CAST('2024-01-01' AS DATE)

Fråga med grundläggande metadata

För att lösa problemet med antagna tabellnamn och kolumnnamn lade vi till tabellmetadata i DDL-format i den andra prompten. Som ett resultat använde modellen de korrekta kolumnnamnen och datatyperna och begränsade DATE casting till ett bokstavligt strängvärde. Den fick SQL-frågan syntaktisk korrekt, men ett problem kvarstår: modellen antog de bokstavliga värden som användes i filteruttrycken.

Fråga: Lista över tillsvidareanställda som arbetar i Nordamerika och började efter 1 januari 2024.

Snabb definition:

Human: You are an Amazon Athena query expert whose output is a valid sql query. You are given the following Instructions for building the Amazon Athena query.
<Instructions>
{instruction_dtls}
</Instructions>

Only use the following tables defined within the database_schema and table_schema XML-style tags:

<database_schema>
<table_schema>
CREATE EXTERNAL TABLE employee_dtls (
  id int,
  name string,
  age int ,
  dept_id int,
  emp_category string ,
  location_id int ,
  joining_date date
) PARTITIONED BY (
  region_id string
  )
</table_schema>

<table_schema>
CREATE EXTERNAL TABLE department_dtls (
  id int,
  name string ,
  location_id int 
)
</table_schema>
</database_schema>

Question: {question}
Assistant:

SQL-fråga genererad:

SELECT employee_dtls.id, employee_dtls.name, employee_dtls.age, employee_dtls.dept_id, employee_dtls.emp_category
FROM employee_dtls 
WHERE employee_dtls.region_id = 'NA' 
  AND employee_dtls.emp_category = 'permanent'
  AND employee_dtls.joining_date > CAST('2024-01-01' AS DATE)

Fråga med berikad metadata

Nu måste vi ta reda på hur vi tillhandahåller de möjliga värdena för en kolumn till modellen. Ett sätt kan vara att inkludera metadata i kolumnen för kolumner med låg kardinalitet. Så vi lade till kolumnbeskrivningar tillsammans med möjliga värden i den tredje prompten. Som ett resultat inkluderade modellen de korrekta bokstavliga värdena i filteruttrycken och gav en korrekt SQL-fråga.

Fråga: Lista över fast anställda som arbetar i Nordamerika och anslöt sig efter 1 januari 2024.

Snabb definition:

Human: You are an Amazon Athena query expert whose output is a valid sql query. You are given the following Instructions for building the Amazon Athena query.
<Instructions>
{instruction_dtls}
</Instructions>

Only use the following tables defined within the database_schema and table_schema XML-style tags:

<database_schema>
<table_schema>
CREATE EXTERNAL TABLE employee_dtls (
id int COMMENT 'Employee id',
name string COMMENT 'Employee name',
age int COMMENT 'Employee age',
dept_id int COMMENT 'Employee Departments ID',
emp_category string COMMENT 'Employee category. Contains TEMP For temporary, PERM for permanent, CONTR for contractors ',
location_id int COMMENT 'Location identifier of the Employee',
joining_date date  COMMENT 'Employee joining date',
CONSTRAINT pk_1 PRIMARY KEY  (id) ,
CONSTRAINT FK_1 FOREIGN KEY (dept_id) REFERENCES department_dtls(id)
) PARTITIONED BY (
region_id string COMMENT 'Region identifier. Contains AMER for Americas, EMEA for Europe, the Middle East, and Africa, APAC for Asia Pacific countries'
)
</table_schema>

<table_schema>
CREATE EXTERNAL TABLE department_dtls (
id int COMMENT 'Department id',
name string COMMENT 'Department name',
location_id int COMMENT 'Location identifier of the Department'
)
</table_schema>
</database_schema>

Question: {question}
Assistant:

SQL-fråga genererad:

SELECT employee_dtls.id, 
employee_dtls.name
FROM employee_dtls 
WHERE employee_dtls.emp_category = 'PERM'
  AND employee_dtls.region_id = 'AMER' 
  AND employee_dtls.joining_date > CAST('2024-01-01' AS DATE)

Fråga med begränsningar för främmande nyckel i metadata

Observera att när vi lade till de finare detaljerna i metadata för den tredje prompten, inkluderade vi också begränsningar för främmande nyckel. Detta görs för att hjälpa modellen att generera SQL för avancerade frågor som kräver joins. Att lägga till begränsningar för främmande nyckel till metadata hjälper modellen att identifiera de korrekta kolumnerna som ska användas i kopplingsvillkoren. För att demonstrera detta bad vi modellen att skriva SQL för att visa avdelningsdetaljer tillsammans med personalens detaljer. För att visa avdelningsinformationen behöver vi department_dtls tabell. Modellen tillade department_dtls tabell till SQL-frågan och identifierade de högra kolumnerna för kopplingsvillkoret baserat på detaljer om främmande nyckelrestriktioner som ingår i metadata.

Fråga: Lista över fast anställda som arbetar i Nordamerika och anslöt sig efter 1 januari 2024.

SQL-fråga genererad:

SELECT
  employee_dtls.name AS employee_name,
  employee_dtls.age,
  department_dtls.name AS department_name
FROM employee_dtls 
JOIN department_dtls 
  ON employee_dtls.dept_id = department_dtls.id
WHERE 
  employee_dtls.emp_category = 'PERM'
  AND employee_dtls.region_id = 'AMER' 
  AND employee_dtls.joining_date > CAST('2024-01-01' AS DATE)

Ytterligare observationer

Även om modellen inkluderade relevanta medarbetarattribut i SELECT-satsen, varierade den exakta listan med attribut som den inkluderade varje gång. Även för samma snabba definition gav modellen en varierande lista med attribut. Modellen använde slumpmässigt en av de två metoderna för att gjuta strängens bokstavliga värde till datumtyp. Den första metoden använder CAST('2024-01-01' AS DATE) och den andra metoden använder DATE '2024-01-01'.

Utmaningar med att underhålla metadata

Nu när du förstår hur underhåll av detaljerad metadata tillsammans med främmande nyckelbegränsningar hjälper modellen att generera korrekta SQL-frågor, låt oss diskutera hur du kan samla in nödvändiga detaljer om tabellmetadata. Datasjö- och databaskatalogerna stöder insamling och sökning av metadata, inklusive tabell- och kolumnbeskrivningar. Att se till att dessa beskrivningar är korrekta och uppdaterade innebär dock flera praktiska utmaningar, som:

  1. Att skapa databasobjekt med användbara beskrivningar kräver samarbete mellan tekniska och affärsmässiga team för att skriva detaljerade och meningsfulla beskrivningar. Eftersom tabeller genomgår schemaändringar kan uppdatering av metadata för varje ändring vara tidskrävande och kräva ansträngning.
  2. Att underhålla listor med möjliga värden för kolumnerna kräver kontinuerliga uppdateringar.
  3. Att lägga till datatransformationsdetaljer till metadata kan vara utmanande på grund av den spridda karaktären hos denna information över databehandlingspipelines, vilket gör det svårt att extrahera och införliva i metadata på tabellnivå.
  4. Att lägga till datalinjedetaljer till metadata ställs inför utmaningar på grund av den fragmenterade karaktären hos denna information över databearbetningspipelines, vilket gör extraktion och integration i metadata på tabellnivå komplex.

Specifikt för AWS Glue Data Catalog uppstår fler utmaningar, till exempel följande:

  1. Att skapa AWS Glue-tabeller via sökrobotar genererar inte automatiskt tabell- eller kolumnbeskrivningar, vilket kräver manuella uppdateringar av tabelldefinitioner från AWS Glue-konsolen.
  2. Till skillnad från traditionella relationsdatabaser, definierar eller tillämpar AWS Glue-tabeller inte uttryckligen primärnycklar eller främmande nycklar. AWS Glue-tabeller fungerar på ett schema-på-läs-bas, där schemat härleds från data när du frågar. Därför finns det inget direkt stöd för att specificera primärnycklar, främmande nycklar eller kolumnbeskrivningar i AWS Glue-tabeller som det finns i traditionella databaser.

Berika metadata

Listade här några sätt som du kan övervinna de tidigare nämnda utmaningarna med att underhålla metadata.

  • Förbättra tabell- och kolumnbeskrivningarna: Att dokumentera tabell- och kolumnbeskrivningar kräver en god förståelse för affärsprocessen, terminologi, akronymer och domänkunskap. Följande är de olika metoderna du kan använda för att få dessa tabell- och kolumnbeskrivningar till AWS Glue Data Catalog.
    • Använd generativ AI för att skapa bättre dokumentation: Företag dokumenterar ofta sina affärsprocesser, terminologier och akronymer och gör dem tillgängliga via företagsspecifika portaler. Genom att följa namnkonventioner för tabeller och kolumner kan enhetlighet i objektnamn uppnås, vilket gör dem mer relaterade till affärsterminologi och akronymer. Genom att använda generativa AI-modeller på Amazon Bedrock kan du förbättra tabell- och kolumnbeskrivningarna genom att mata modellerna med affärsterminologi och akronymdefinitioner tillsammans med databasschemaobjekten. Detta tillvägagångssätt minskar tiden och ansträngningen som krävs för att skapa detaljerade beskrivningar. Den nyligen släppta metadatafunktionen i Amazon DataZone, AI-rekommendationer för beskrivningar i Amazon DataZone, följer dessa principer. När du har skapat beskrivningarna kan du uppdatera kolumnbeskrivningarna med något av följande alternativ.
      • Från AWS Glue katalog UI
      • Använda AWS Glue SDK liknande Steg 3a : Skapa employee_dtls Limtabell för förfrågningar från Athena i 0_create_tables_with_metadata.ipynb Jupyter Notebook
      • Lägg till KOMMENTARER i DDL-skriptet i tabellen. 
        CREATE EXTERNAL TABLE <table_name> 
( column1 string COMMENT '<column_description>' ) 
PARTITIONED BY ( column2 string COMMENT '<column_description>' )

  • För AWS Glue-tabeller katalogiserade från andra databaser:
    • Du kan lägga till tabell- och kolumnbeskrivningar från källdatabaserna med hjälp av sökroboten i AWS Glue.
    • Du kan konfigurera Alternativet EnableAdditionalMetadata Crawler för att genomsöka metadata som kommentarer och rådatatyper från de underliggande datakällorna. AWS Glue-sökroboten kommer sedan att fylla i ytterligare metadata i AWS Glue Data Catalog. Detta ger ett sätt att dokumentera dina tabeller och kolumner direkt från metadata som definieras i den underliggande databasen.
  • Förbättra metadata med dataprofilering: Som visades i föregående avsnitt hjälpte tillhandahållandet av värdelistan i kolumnen för anställdkategori och deras betydelse att generera SQL-frågan med mer exakta filtervillkor. Vi kan tillhandahålla en sådan lista med värden eller dataegenskaper i kolumnbeskrivningarna med hjälp av dataprofilering. Dataprofilering är processen att analysera och förstå data och dess egenskaper som distinkta värden. Genom att använda dataprofileringsinsikter kan vi förbättra kolumnbeskrivningarna.
  • Förbättra metadata med detaljer om partitioner och en rad partitionsvärden: Som visades i föregående avsnitt hjälpte tillhandahållandet av listan över partitionsvärden och deras betydelse i partitionskolumnbeskrivningen till att generera SQL med mer exakta filtervillkor. För listpartitioner kan vi lägga till listan med partitionsvärden och deras betydelser till partitionskolumnbeskrivningen. För intervallpartitioner kan vi lägga till mer sammanhang på kornen av värdena som dagligen, månadsvis och ett specifikt intervall av värden till kolumnbeskrivningen.

Berika uppmaningen

Du kan förbättra uppmaningarna med frågeoptimeringsregler som partitionsbeskärning. I den athena_sql_generating_instructions, definieras som en del av 1_text-to-sql-for-athena.ipynb Jupyter Notebook, vi har lagt till en instruktion "För tabeller med partitioner, inkludera filtren i de relevanta partitionskolumnerna". Denna instruktion vägleder modellen om hur man hanterar partitionsbeskärning. I exemplet observerade vi att modellen lade till det relevanta partitionsfiltret på region_id partitionskolumn. Dessa partitionsfilter kommer att påskynda exekveringen av SQL-frågan och är en av de bästa frågeoptimeringsteknikerna. Du kan lägga till fler sådana frågeoptimeringsregler i instruktionerna. Du kan förbättra dessa instruktioner med relevanta SQL-exempel.

Städa

För att rensa upp resurserna, börja med städa upp S3-hinken som skapades av CloudFormation-stacken. Ta sedan bort CloudFormation-stacken med följande steg.

  • I AWS Management Console väljer du namnet på den region som för närvarande visas och ändrar den till USA Väst (Oregon).
  • Navigera till AWS molnformation.
  • Välja Stacks.
  • Välja texttosqlmetadata
  • Välja Radera.

Slutsats

Exemplet som presenteras i inlägget belyser vikten av berikad metadata för att generera korrekt SQL-fråga med hjälp av text-till-SQL-funktionerna i Anthropics Claude-modell på Amazon Bedrock och diskuterar flera sätt att berika metadata. Amazon Bedrock är i centrum för denna text-till-SQL-generation. Amazon Bedrock kan hjälpa dig att bygga olika generativa AI-applikationer inklusive användningsfallet för generering av metadata som nämns i föregående avsnitt. För att komma igång med Amazon Bedrock rekommenderar vi att du följer snabbstarten i GitHub repo och bekanta dig med att bygga generativa AI-applikationer. Efter att ha blivit bekant med generativa AI-applikationer, se GitHub Text-to-SQL-workshop för att lära dig mer text-till-SQL-tekniker. Se Bygg en robust text-till-SQL-lösning och Bästa metoder för text-till-SQL för den rekommenderade arkitekturen och bästa praxis att följa när du implementerar text-till-SQL-generering.

Om författaren

Naidu Rongali är en Big Data och ML ingenjör på Amazon. Han designar och utvecklar databehandlingslösningar för dataintensiva analytiska system som stödjer Amazons detaljhandelsverksamhet. Han har arbetat med att integrera generativa AI-funktioner i datasjö- och datalagersystemen med hjälp av Amazon Bedrock AI-modeller. Naidu har ett PG-diplom i tillämpad statistik från Indian Statistical Institute, Calcutta och BTech i Electrical and Electronics från NIT, Warangal. Utanför sitt arbete utövar Naidu yoga och går ofta på vandring.

Relaterade artiklar

plats_img

Senaste artiklar

plats_img
Premium innehåll

Copyright @ 2024 Plato Technologies Inc.