# AWS ให้ Aurora PostgreSQL query ข้อมูล Iceberg และ Parquet ใน Data Lake ได้โดยตรง

> AWS ประกาศเมื่อ 30 กันยายน 2026 ให้ Aurora PostgreSQL query ข้อมูล Apache Iceberg และ Parquet ใน Data Lake ร่วมกับข้อมูลธุรกรรมได้ในคำสั่งเดียว โดยฝัง DuckDB ไว้ในตัว และไม่คิดค่าบริการเพิ่ม

- ประเภท: ข่าว · หมวด: Data & Analytics
- เผยแพร่: 2026-10-02T11:03:00.000Z · อัปเดต: 2026-10-02T11:03:00.000Z
- โดย: กองบรรณาธิการ THAI DATA, THAI DATA IT BUSINESS ENTERPRISE
- ที่มา: https://thaidata.co.th/data/aws-aurora-postgresql-query-iceberg-parquet-data-lake/

## สรุปประเด็นสำคัญ

- AWS ประกาศเมื่อ **30 กันยายน 2026** ว่า Aurora PostgreSQL query ข้อมูล **Apache Iceberg และ Apache Parquet** ใน Data Lake ได้โดยตรง ด้วยไวยากรณ์ PostgreSQL เดิม ไม่ต้องสร้าง pipeline ETL
- ความสามารถนี้อาศัย **DuckDB ที่ฝังอยู่ใน Aurora PostgreSQL** โดย AWS ระบุว่า DuckLabs ทีมผู้ดูแลโครงการ DuckDB เพิ่งเข้าร่วมกับ Amazon
- รองรับ Aurora PostgreSQL **เวอร์ชัน 17 (ตั้งแต่ 17.11) และ 18 (ตั้งแต่ 18.6)** เปิดใช้ผ่าน extension ชื่อ aurora_analytics และ IAM role
- ใช้ได้ในทุก Region เชิงพาณิชย์ของ AWS **โดยไม่มีค่าบริการเพิ่ม** จ่ายเฉพาะ compute ของ Aurora ที่ query ใช้ และค่า request ของ Amazon S3
- วันเดียวกัน **Amazon S3 Tables** รองรับชนิดข้อมูลครบทุกชนิดของ Apache Iceberg V3 รวมถึง variant, geometry และ deletion vectors

Amazon Web Services (AWS) ประกาศเมื่อวันที่ 30 กันยายน 2026 ว่า Amazon Aurora PostgreSQL สามารถ query ข้อมูลที่เก็บใน Data Lake รูปแบบ Apache Iceberg และ Apache Parquet ได้โดยตรง ร่วมกับข้อมูลธุรกรรมในฐานข้อมูลภายในคำสั่งเดียว โดยใช้แอปพลิเคชันและเครื่องมือ PostgreSQL ที่มีอยู่เดิม ผลคือองค์กรไม่ต้องสร้าง pipeline เพื่อคัดลอกข้อมูลจาก Data Lake กลับเข้าฐานข้อมูลปฏิบัติการอีก ในวันเดียวกัน AWS ยังประกาศให้ Amazon S3 Tables รองรับชนิดข้อมูลครบทุกชนิดของสเปก Apache Iceberg V3

## Aurora PostgreSQL อ่าน Data Lake ได้อย่างไร

AWS อธิบายว่าก่อนหน้านี้ หากแอปพลิเคชันต้องรวมข้อมูลธุรกรรมล่าสุดใน Aurora กับข้อมูลย้อนหลังที่เก็บใน Amazon S3 วิธีที่ใช้กันทั่วไปคือสร้าง pipeline แบบ reverse ETL ซึ่งทำให้ข้อมูลซ้ำซ้อน เพิ่มต้นทุนโครงสร้างพื้นฐาน และต้องมีวิศวกรคอยดูแลให้ข้อมูลตรงกัน ปัญหานี้หนักขึ้นเมื่อองค์กรฝัง AI Agent ไว้ในแอปพลิเคชัน เพราะคาดเดาล่วงหน้าไม่ได้ว่า Agent จะต้องใช้ชุดข้อมูลใด

กลไกของฟีเจอร์ใหม่คือ **DuckDB** ระบบฐานข้อมูลเชิงวิเคราะห์แบบโอเพนซอร์ส ที่ถูกฝังไว้ใน Aurora PostgreSQL โดยตรง AWS ระบุว่า DuckLabs ซึ่งเป็นทีมผู้ดูแลโครงการ DuckDB เพิ่งเข้าร่วมกับ Amazon และฟีเจอร์นี้เป็นตัวอย่างของการนำ DuckDB มาใช้ในบริการของบริษัท การประมวลผล query เกิดขึ้นภายใน Aurora ทั้งหมด จึง query ข้อมูลปฏิบัติการล่าสุด รวมถึงข้อมูลที่ยังไม่ commit ไปพร้อมกับข้อมูลใน Data Lake ได้

แหล่งข้อมูลที่รองรับมีดังนี้

- ตาราง Apache Iceberg ที่จัดการผ่าน AWS Glue Data Catalog
- ข้อมูล Parquet และ Iceberg ที่เก็บใน Amazon S3 และ S3 Tables
- แค็ตตาล็อกภายนอกที่เข้ากันได้กับ Iceberg REST Catalog (IRC) โดยลงทะเบียนผ่านการ federation ของ AWS Glue Data Catalog

## วิธีเปิดใช้ และเงื่อนไขที่ต้องรู้

| หัวข้อ | รายละเอียดตามประกาศของ AWS |
| --- | --- |
| เวอร์ชันที่รองรับ | Aurora PostgreSQL 17 ตั้งแต่ 17.11 และ 18 ตั้งแต่ 18.6 |
| การเปิดใช้ | แนบ IAM role ที่มีฟีเจอร์ AuroraAnalytics แล้วเปิด extension `aurora_analytics` |
| การเข้าถึงข้อมูล | สร้าง foreign table ชี้ไปยังข้อมูล Iceberg หรือ Parquet หรือใช้ `IMPORT FOREIGN SCHEMA` สร้างทีละทั้งฐานข้อมูลใน Glue Data Catalog |
| การปรับประสิทธิภาพ | Predicate pushdown และ column pruning อ่านเฉพาะข้อมูลที่เกี่ยวข้อง และแคชข้อมูลที่ใช้บ่อยไว้ใน instance |
| การตรวจสอบ | ฟังก์ชัน `aurora_analytics_stat_statements()` รายงานจำนวนแถวที่สแกน ไบต์ที่อ่านจาก S3 และ cache hit |
| พื้นที่ให้บริการ | ทุก Region เชิงพาณิชย์ของ AWS และ AWS GovCloud (US) |
| ราคา | ไม่มีค่าบริการเพิ่ม จ่ายค่า compute ของ Aurora ที่ query ใช้เพิ่ม และค่า request ของ Amazon S3 |

![พารามิเตอร์ aurora_analytics.enabled ของคลัสเตอร์ในตัวอย่างของ AWS ซึ่งระบุเวอร์ชันเอนจินขั้นต่ำ 17.11](https://thaidata.co.th/images/articles/aws-aurora-postgresql-query-iceberg-parquet-data-lake/aurora-analytics-cluster-parameter.webp) _(ภาพ: Amazon Web Services)_

ในตัวอย่างของ AWS ผู้เขียนสร้าง foreign table ชี้ไปยังไฟล์ Parquet ที่เก็บประวัติธุรกรรมย้อนหลัง 5 ปีใน S3 โดยไม่ต้องระบุคอลัมน์ เพราะ Aurora อ่าน schema จาก metadata ของไฟล์เอง แล้วใช้คำสั่ง `UNION ALL` รวมกับตารางธุรกรรม 7 วันล่าสุดที่อยู่ใน Aurora ผลลัพธ์ออกมาเป็นชุดเดียว

![ผล query ในตัวอย่างของ AWS: แถวที่ระบุ recent มาจาก Aurora ส่วน historical อ่านจากไฟล์ Parquet ใน S3 โดยตรง](https://thaidata.co.th/images/articles/aws-aurora-postgresql-query-iceberg-parquet-data-lake/aurora-query-recent-and-historical.webp) _(ภาพ: Amazon Web Services)_

สำหรับ query ที่ต้องการเวลาตอบสนองระดับมิลลิวินาทีหลักเดียว AWS แนะนำให้นำข้อมูลจาก Data Lake มาเก็บเป็นตารางของ Aurora เอง ด้วยคำสั่งอย่าง `CREATE TABLE AS SELECT`, `INSERT INTO ... SELECT` หรือ `MERGE INTO` ส่วน query แบบอ่านอย่างเดียวรันบน read replica ได้ จึงแยกงานวิเคราะห์ออกจากงานธุรกรรมหลักได้ ขณะที่คำสั่งที่เขียนข้อมูลเข้า Aurora ต้องรันบน writer instance

## S3 Tables รองรับ Apache Iceberg V3 ครบทุกชนิดข้อมูล

ประกาศอีกฉบับของวันเดียวกันระบุว่า Amazon S3 Tables ซึ่งเป็นสตอเรจที่ออกแบบมาสำหรับตาราง Iceberg โดยเฉพาะ รองรับชนิดข้อมูลทั้งหมดในสเปก Apache Iceberg V3 แล้ว ผู้ใช้สร้างตาราง V3 ใหม่ หรืออัปเกรดตาราง V2 เดิมได้โดยไม่ต้องย้ายข้อมูล และ S3 Tables ยังดูแล compaction กับงานบำรุงรักษาให้ต่อไป

![Amazon S3 Tables รองรับชนิดข้อมูลของ Iceberg V3 ครบทุกชนิดตั้งแต่ 30 กันยายน 2026](https://thaidata.co.th/images/articles/aws-aurora-postgresql-query-iceberg-parquet-data-lake/amazon-s3-tables-iceberg-v3.webp) _(ภาพ: Amazon Web Services)_

| ความสามารถของ V3 | แก้ปัญหาอะไรของ V2 |
| --- | --- |
| Deletion vectors | แทนไฟล์ positional delete จำนวนมากด้วยไฟล์ไบนารีขนาดเล็ก AWS ยกตัวอย่างการลบข้อมูลผู้ใช้ 50,000 รายการจากตาราง 2 พันล้านแถว ซึ่งจะเขียนไฟล์ deletion vector เพียงไฟล์เดียว |
| Row lineage | เพิ่มฟิลด์ `_row_id` และ `_last_updated_sequence_number` ให้ทุกแถวอัตโนมัติ pipeline ปลายทางหาแถวที่เปลี่ยนได้โดยไม่ต้องสแกนทั้งตาราง |
| Variant | เก็บข้อมูลกึ่งโครงสร้างในรูปแบบคอลัมน์ แทนการเก็บ JSON เป็นข้อความที่ต้องแปลงทุกครั้งที่ query |
| Timestamp ระดับนาโนวินาที, geometry และ geography | เก็บเวลาความละเอียดสูงและข้อมูลเชิงพื้นที่เป็นชนิดข้อมูลของตัวเอง แทนการเข้ารหัสเป็นข้อความหรือตัวเลข |

## ทำไมเรื่องนี้สำคัญ

สองประกาศนี้ชี้ไปทางเดียวกัน คือเส้นแบ่งระหว่างฐานข้อมูลปฏิบัติการกับ Data Lake กำลังบางลง Apache Iceberg ซึ่ง AWS เรียกว่าเป็นมาตรฐานเปิดสำหรับจัดการชุดข้อมูลวิเคราะห์ขนาดใหญ่ กลายเป็นรูปแบบกลางที่บริการหลายตัวอ่านร่วมกันได้ เมื่อฐานข้อมูลธุรกรรมอ่าน Iceberg ได้เอง ข้อมูลหนึ่งชุดก็ไม่ต้องถูกคัดลอกไปหลายที่

อีกประเด็นคือบทบาทของ DuckDB การที่ AWS ฝังเอนจินโอเพนซอร์สตัวนี้ไว้ใน Aurora และระบุว่าการปรับปรุงของโครงการในอนาคตจะส่งผลถึง Aurora และบริการอื่นของ AWS ด้วย แสดงว่าบริษัทเลือกต่อยอดจากเอนจินที่ชุมชนใช้กันแพร่หลาย แทนการสร้างเอนจินวิเคราะห์ใหม่สำหรับงานนี้

ข้อที่ต้องระวังคือขอบเขตของฟีเจอร์ query ที่อ่านจาก Data Lake ใช้ compute ของ Aurora เอง งานวิเคราะห์ขนาดใหญ่จึงแย่งทรัพยากรกับงานธุรกรรมได้หากรันบน instance เดียวกัน และค่า request ของ S3 จะเพิ่มตามปริมาณไฟล์ที่อ่าน ฟีเจอร์นี้เหมาะกับการเติมบริบทย้อนหลังให้ธุรกรรม มากกว่าการแทนที่คลังข้อมูลสำหรับงานวิเคราะห์เต็มรูปแบบ

## สิ่งที่องค์กรควรทำ

1. **ตรวจเวอร์ชันของ Aurora PostgreSQL ที่ใช้อยู่** ฟีเจอร์นี้ต้องใช้ 17.11 หรือ 18.6 ขึ้นไป องค์กรที่ยังอยู่บนเวอร์ชันหลักที่เก่ากว่าต้องรวมการอัปเกรดไว้ในแผน
2. **ทบทวน pipeline reverse ETL ที่มีอยู่** หา pipeline ที่คัดลอกข้อมูลจาก S3 กลับเข้าฐานข้อมูลเพียงเพื่อให้แอปอ่านได้ เพราะเป็นกลุ่มแรกที่อาจเลิกใช้ได้ และลดทั้งต้นทุนกับภาระดูแล
3. **รัน query ฝั่ง Data Lake บน read replica** เพื่อไม่ให้งานสแกนข้อมูลจำนวนมากกระทบงานธุรกรรมหลัก และใช้ `aurora_analytics_stat_statements()` วัดว่าแต่ละ query อ่านข้อมูลจาก S3 เท่าใด
4. **กำหนดสิทธิ์ของ IAM role ให้แคบ** role ที่แนบกับคลัสเตอร์คือสิ่งที่เปิดให้ฐานข้อมูลเข้าถึง S3 และ Glue Data Catalog จึงควรจำกัดเฉพาะ bucket และแค็ตตาล็อกที่จำเป็น โดยเฉพาะเมื่อ Data Lake มีข้อมูลส่วนบุคคล
5. **ประเมิน Iceberg V3 ก่อนอัปเกรดตาราง** ตรวจว่าเอนจินทุกตัวที่อ่านตารางเดียวกันรองรับ V3 แล้ว ก่อนอัปเกรดตาราง V2 ที่ใช้งานจริง

## คำถามที่พบบ่อย

### Aurora PostgreSQL query ข้อมูลใน Data Lake ได้อย่างไร?

ผู้ใช้เปิด extension ชื่อ aurora_analytics แนบ IAM role ที่ให้สิทธิ์เข้าถึง Amazon S3 และ AWS Glue Data Catalog แล้วสร้าง foreign table ชี้ไปยังข้อมูล Iceberg หรือ Parquet จากนั้น query ด้วยคำสั่ง SQL ของ PostgreSQL ตามปกติ โดย DuckDB ที่ฝังอยู่ใน Aurora เป็นผู้อ่านข้อมูลฝั่ง Data Lake

### ฟีเจอร์นี้ใช้ได้กับ Aurora PostgreSQL เวอร์ชันใด?

AWS ระบุว่ารองรับ Aurora PostgreSQL สองเวอร์ชันหลัก คือเวอร์ชัน 17 ตั้งแต่ 17.11 และเวอร์ชัน 18 ตั้งแต่ 18.6

### การ query ข้อมูล Iceberg จาก Aurora มีค่าใช้จ่ายเพิ่มหรือไม่?

AWS ระบุว่าไม่มีค่าบริการเพิ่มสำหรับฟีเจอร์นี้ ผู้ใช้จ่ายเฉพาะ compute ของ Aurora ที่ query ใช้เพิ่มขึ้น และค่า request ของ Amazon S3 ที่เกิดจากการอ่านไฟล์ใน Data Lake

### Apache Iceberg V3 ต่างจาก V2 อย่างไร?

ตามประกาศของ AWS สเปก V3 เพิ่ม deletion vectors ที่แทนไฟล์ positional delete ของ V2 ด้วยรูปแบบไบนารีขนาดเล็ก เพิ่ม row lineage สำหรับติดตามแถวที่เปลี่ยน และเพิ่มชนิดข้อมูลใหม่ ได้แก่ variant สำหรับข้อมูลกึ่งโครงสร้าง timestamp ระดับนาโนวินาที geometry และ geography สำหรับข้อมูลเชิงพื้นที่ และ unknown


## แหล่งอ้างอิง

- [Amazon Aurora PostgreSQL now supports direct querying of Apache Iceberg and Parquet data in your data lake](https://aws.amazon.com/blogs/aws/amazon-aurora-postgresql-now-supports-direct-querying-of-apache-iceberg-and-parquet-data-in-your-data-lake/) — Amazon Web Services
- [Amazon S3 Tables now support all Apache Iceberg V3 data types](https://aws.amazon.com/blogs/aws/amazon-s3-tables-now-support-all-apache-iceberg-v3-data-types/) — Amazon Web Services