Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Menggunakan EXPLAIN dan EXPLAIN ANALYZE di Athena Parameter`EXPLAIN`pernyataan menunjukkan rencana eksekusi logis atau didistribusikan dari pernyataan SQL tertentu, atau memvalidasi pernyataan SQL. Anda dapat menampilkan hasil dalam format teks atau dalam format data untuk rendering ke grafik. **catatan** Anda dapat melihat representasi grafis dari rencana logis dan terdistribusi untuk kueri Anda di konsol Athena tanpa menggunakan sintaks. `EXPLAIN` Untuk informasi selengkapnya, lihat [Lihat rencana eksekusi untuk kueri SQL](query-plans.md). `EXPLAIN ANALYZE`Pernyataan tersebut menunjukkan rencana eksekusi terdistribusi dari pernyataan SQL tertentu dan biaya komputasi setiap operasi dalam kueri SQL. Anda dapat menampilkan hasil dalam format teks atau JSON. ## Pertimbangan dan batasan `EXPLAIN ANALYZE`Pernyataan `EXPLAIN` dan di Athena memiliki batasan sebagai berikut. + Karena`EXPLAIN`pertanyaan tidak memindai data apapun, Athena tidak mengenakan biaya untuk mereka. Namun, karena `EXPLAIN` kueri melakukan panggilan AWS Glue untuk mengambil metadata tabel, Anda mungkin dikenakan biaya dari Glue jika panggilan melebihi batas tingkat [gratis untuk](https://aws.amazon.com/free/?all-free-tier.sort-by=item.additionalFields.SortRank&all-free-tier.sort-order=asc&awsf.Free%20Tier%20Categories=categories%23analytics&all-free-tier.q=glue&all-free-tier.q_operator=AND) lem. + Karena `EXPLAIN ANALYZE` kueri dijalankan, mereka memindai data, dan Athena mengenakan biaya untuk jumlah data yang dipindai. + Informasi pemfilteran baris atau sel yang ditentukan dalam Lake Formation dan informasi statistik kueri tidak ditampilkan dalam output dan. `EXPLAIN` `EXPLAIN ANALYZE` ## JELASKAN sintaks ``` EXPLAIN [ ( option [, ...]) ] statement ``` *option* dapat berupa salah satu status berikut: ``` FORMAT { TEXT | GRAPHVIZ | JSON } TYPE { LOGICAL | DISTRIBUTED | VALIDATE | IO } ``` Jika `FORMAT` opsi tidak ditentukan, output default ke format. `TEXT` `IO`Jenis ini memberikan informasi tentang tabel dan skema yang dibaca kueri. ## JELASKAN ANALYSIS sintaks Selain output yang disertakan`EXPLAIN`, `EXPLAIN ANALYZE` output juga mencakup statistik runtime untuk kueri yang ditentukan seperti penggunaan CPU, jumlah baris input, dan jumlah baris output. ``` EXPLAIN ANALYZE [ ( option [, ...]) ] statement ``` *option* dapat berupa salah satu status berikut: ``` FORMAT { TEXT | JSON } ``` Jika `FORMAT` opsi tidak ditentukan, output default ke format. `TEXT` Karena semua kueri untuk `EXPLAIN ANALYZE` adalah`DISTRIBUTED`, `TYPE` opsi tidak tersedia untuk`EXPLAIN ANALYZE`. *statement* dapat berupa salah satu status berikut: ``` SELECT CREATE TABLE AS SELECT INSERT UNLOAD ``` ## JELASKAN contoh Contoh berikut untuk `EXPLAIN` kemajuan dari yang lebih mudah ke yang lebih kompleks. ### Contoh 1: Gunakan pernyataan EXPLOW untuk menampilkan rencana kueri dalam format teks Dalam contoh berikut, `EXPLAIN` menunjukkan rencana eksekusi untuk `SELECT` kueri pada log Elastic Load Balancing. Format default ke output teks. ``` EXPLAIN SELECT request_timestamp, elb_name, request_ip FROM sampledb.elb_logs; ``` #### Hasil ``` - Output[request_timestamp, elb_name, request_ip] => [[request_timestamp, elb_name, request_ip]] - RemoteExchange[GATHER] => [[request_timestamp, elb_name, request_ip]] - TableScan[awsdatacatalog:HiveTableHandle{schemaName=sampledb, tableName=elb_logs, analyzePartitionValues=Optional.empty}] => [[request_timestamp, elb_name, request_ip]] LAYOUT: sampledb.elb_logs request_ip := request_ip:string:2:REGULAR request_timestamp := request_timestamp:string:0:REGULAR elb_name := elb_name:string:1:REGULAR ``` ### Contoh 2: Gunakan EXPLOW untuk membuat grafik rencana kueri Anda dapat menggunakan konsol Athena untuk membuat grafik rencana kueri untuk Anda. **Masukkan `SELECT` pernyataan seperti berikut ini ke dalam editor kueri Athena, lalu pilih JELASKAN.** ``` SELECT c.c_custkey, o.o_orderkey, o.o_orderstatus FROM tpch100.customer c JOIN tpch100.orders o ON c.c_custkey = o.o_custkey ``` Halaman **Jelaskan** editor kueri Athena terbuka dan menunjukkan kepada Anda rencana terdistribusi dan rencana logis untuk kueri tersebut. Grafik berikut menunjukkan rencana logis untuk contoh. ![\[Grafik rencana kueri yang diberikan oleh editor kueri Athena.\]](http://docs.aws.amazon.com/id_id/athena/latest/ug/images/athena-explain-statement-tpch.png) **penting** Saat ini, beberapa filter partisi mungkin tidak terlihat di grafik pohon operator bersarang meskipun Athena menerapkannya ke kueri Anda. Untuk memverifikasi efek filter tersebut, jalankan `EXPLAIN` atau `EXPLAIN ANALYZE` pada kueri Anda dan lihat hasilnya. Untuk informasi selengkapnya tentang menggunakan fitur grafik paket kueri di konsol Athena, lihat. [Lihat rencana eksekusi untuk kueri SQL](query-plans.md) ### Contoh 3: Gunakan pernyataan EXPLOW untuk memverifikasi pemangkasan partisi Saat Anda menggunakan predikat penyaringan pada bukti kunci dipartisi untuk kueri tabel dipartisi, mesin permintaan berlaku predikat untuk bukti kunci dipartisi untuk mengurangi jumlah data yang dibaca. Contoh berikut menggunakan`EXPLAIN`query untuk memverifikasi partisi pemangkasan untuk`SELECT`query pada tabel dipartisi. Pertama,`CREATE TABLE`pernyataan menciptakan`tpch100.orders_partitioned`tabel. Tabel dipartisi pada kolom`o_orderdate`. ``` CREATE TABLE `tpch100.orders_partitioned`( `o_orderkey` int, `o_custkey` int, `o_orderstatus` string, `o_totalprice` double, `o_orderpriority` string, `o_clerk` string, `o_shippriority` int, `o_comment` string) PARTITIONED BY ( `o_orderdate` string) ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe' STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat' LOCATION 's3://amzn-s3-demo-bucket//' ``` Parameter`tpch100.orders_partitioned`tabel memiliki beberapa partisi pada`o_orderdate`, seperti yang ditunjukkan oleh`SHOW PARTITIONS`Perintah. ``` SHOW PARTITIONS tpch100.orders_partitioned; o_orderdate=1994 o_orderdate=2015 o_orderdate=1998 o_orderdate=1995 o_orderdate=1993 o_orderdate=1997 o_orderdate=1992 o_orderdate=1996 ``` Berikut`EXPLAIN`query memverifikasi partisi pemangkasan pada ditentukan`SELECT`. ``` EXPLAIN SELECT o_orderkey, o_custkey, o_orderdate FROM tpch100.orders_partitioned WHERE o_orderdate = '1995' ``` #### Hasil ``` Query Plan - Output[o_orderkey, o_custkey, o_orderdate] => [[o_orderkey, o_custkey, o_orderdate]] - RemoteExchange[GATHER] => [[o_orderkey, o_custkey, o_orderdate]] - TableScan[awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=orders_partitioned, analyzePartitionValues=Optional.empty}] => [[o_orderkey, o_custkey, o_orderdate]] LAYOUT: tpch100.orders_partitioned o_orderdate := o_orderdate:string:-1:PARTITION_KEY :: [[1995]] o_custkey := o_custkey:int:1:REGULAR o_orderkey := o_orderkey:int:0:REGULAR ``` Teks tebal dalam hasil menunjukkan bahwa predikat`o_orderdate = '1995'`diterapkan pada`PARTITION_KEY`. ### Contoh 4: Gunakan kueri EXPLOW untuk memeriksa jenis join order dan join Berikut`EXPLAIN`memeriksa kueri`SELECT`perintah bergabung pernyataan dan bergabung jenis. Gunakan kueri seperti ini untuk memeriksa penggunaan memori kueri sehingga Anda dapat mengurangi kemungkinan mendapatkan`EXCEEDED_LOCAL_MEMORY_LIMIT`kesalahan. ``` EXPLAIN (TYPE DISTRIBUTED) SELECT c.c_custkey, o.o_orderkey, o.o_orderstatus FROM tpch100.customer c JOIN tpch100.orders o ON c.c_custkey = o.o_custkey WHERE c.c_custkey = 123 ``` #### Hasil ``` Query Plan Fragment 0 [SINGLE] Output layout: [c_custkey, o_orderkey, o_orderstatus] Output partitioning: SINGLE [] Stage Execution Strategy: UNGROUPED_EXECUTION - Output[c_custkey, o_orderkey, o_orderstatus] => [[c_custkey, o_orderkey, o_orderstatus]] - RemoteSource[1] => [[c_custkey, o_orderstatus, o_orderkey]] Fragment 1 [SOURCE] Output layout: [c_custkey, o_orderstatus, o_orderkey] Output partitioning: SINGLE [] Stage Execution Strategy: UNGROUPED_EXECUTION - CrossJoin => [[c_custkey, o_orderstatus, o_orderkey]] Distribution: REPLICATED - ScanFilter[table = awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=customer, analyzePartitionValues=Optional.empty}, grouped = false, filterPredicate = ("c_custkey" = 123)] => [[c_custkey]] LAYOUT: tpch100.customer c_custkey := c_custkey:int:0:REGULAR - LocalExchange[SINGLE] () => [[o_orderstatus, o_orderkey]] - RemoteSource[2] => [[o_orderstatus, o_orderkey]] Fragment 2 [SOURCE] Output layout: [o_orderstatus, o_orderkey] Output partitioning: BROADCAST [] Stage Execution Strategy: UNGROUPED_EXECUTION - ScanFilterProject[table = awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=orders, analyzePartitionValues=Optional.empty}, grouped = false, filterPredicate = ("o_custkey" = 123)] => [[o_orderstatus, o_orderkey]] LAYOUT: tpch100.orders o_orderstatus := o_orderstatus:string:2:REGULAR o_custkey := o_custkey:int:1:REGULAR o_orderkey := o_orderkey:int:0:REGULAR ``` Contoh kueri dioptimalkan menjadi silang bergabung untuk performa yang lebih baik. Hasil menunjukkan bahwa`tpch100.orders`akan didistribusikan sebagai`BROADCAST`distribusi jenis. Ini berarti bahwa`tpch100.orders`tabel akan didistribusikan ke semua simpul yang melakukan operasi bergabung. Parameter`BROADCAST`jenis distribusi akan mengharuskan semua hasil disaring dari`tpch100.orders`tabel masuk ke dalam memori dari setiap simpul yang melakukan bergabung operasi. Namun,`tpch100.customer`tabel lebih kecil dari`tpch100.orders`. Karena`tpch100.customer`membutuhkan lebih sedikit memori, Anda dapat menulis ulang kueri ke`BROADCAST tpch100.customer`Sebagai gantinya`tpch100.orders`. Ini mengurangi kemungkinan kueri menerima`EXCEEDED_LOCAL_MEMORY_LIMIT`kesalahan. Strategi ini mengasumsikan poin-poin berikut: + Parameter`tpch100.customer.c_custkey`unik di`tpch100.customer`tabel. + Ada hubungan one-to-many pemetaan antara `tpch100.customer` dan`tpch100.orders`. Contoh berikut menunjukkan kueri ditulis ulang. ``` SELECT c.c_custkey, o.o_orderkey, o.o_orderstatus FROM tpch100.orders o JOIN tpch100.customer c -- the filtered results of tpch100.customer are distributed to all nodes. ON c.c_custkey = o.o_custkey WHERE c.c_custkey = 123 ``` ### Contoh 5: Gunakan kueri EXPLOW untuk menghapus predikat yang tidak berpengaruh Anda dapat menggunakan`EXPLAIN`query untuk memeriksa efektivitas penyaringan predikat. Anda dapat menggunakan hasil untuk menghapus predikat yang tidak berpengaruh, seperti dalam contoh berikut. ``` EXPLAIN SELECT c.c_name FROM tpch100.customer c WHERE c.c_custkey = CAST(RANDOM() * 1000 AS INT) AND c.c_custkey BETWEEN 1000 AND 2000 AND c.c_custkey = 1500 ``` #### Hasil ``` Query Plan - Output[c_name] => [[c_name]] - RemoteExchange[GATHER] => [[c_name]] - ScanFilterProject[table = awsdatacatalog:HiveTableHandle{schemaName=tpch100, tableName=customer, analyzePartitionValues=Optional.empty}, filterPredicate = (("c_custkey" = 1500) AND ("c_custkey" = CAST(("random"() * 1E3) AS int)))] => [[c_name]] LAYOUT: tpch100.customer c_custkey := c_custkey:int:0:REGULAR c_name := c_name:string:1:REGULAR ``` Parameter`filterPredicate`dalam hasil menunjukkan bahwa optimizer menggabungkan tiga predikat asli menjadi dua predikat dan mengubah urutan aplikasi mereka. ``` filterPredicate = (("c_custkey" = 1500) AND ("c_custkey" = CAST(("random"() * 1E3) AS int))) ``` Karena hasil menunjukkan bahwa predikat`AND c.c_custkey BETWEEN 1000 AND 2000`tidak berpengaruh, Anda dapat menghapus predikat ini tanpa mengubah hasil kueri. Untuk informasi tentang istilah yang digunakan dalam hasil`EXPLAIN`kueri, lihat[Pahami Athena JELASKAN hasil pernyataan](athena-explain-statement-understanding.md). ## JELASKAN CONTOH ANALISIS Contoh berikut menunjukkan contoh `EXPLAIN ANALYZE` query dan output. ### Contoh 1: Gunakan EXPLOW ANALYZE untuk menampilkan rencana kueri dan biaya komputasi dalam format teks Dalam contoh berikut, `EXPLAIN ANALYZE` menunjukkan rencana eksekusi dan biaya komputasi untuk `SELECT` kueri pada CloudFront log. Format default ke output teks. ``` EXPLAIN ANALYZE SELECT FROM cloudfront_logs LIMIT 10 ``` #### Hasil ``` Fragment 1 CPU: 24.60ms, Input: 10 rows (1.48kB); per task: std.dev.: 0.00, Output: 10 rows (1.48kB) Output layout: [date, time, location, bytes, requestip, method, host, uri, status, referrer,\ os, browser, browserversion] Limit[10] => [[date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion]] CPU: 1.00ms (0.03%), Output: 10 rows (1.48kB) Input avg.: 10.00 rows, Input std.dev.: 0.00% LocalExchange[SINGLE] () => [[date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion]] CPU: 0.00ns (0.00%), Output: 10 rows (1.48kB) Input avg.: 0.63 rows, Input std.dev.: 387.30% RemoteSource[2] => [[date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion]] CPU: 1.00ms (0.03%), Output: 10 rows (1.48kB) Input avg.: 0.63 rows, Input std.dev.: 387.30% Fragment 2 CPU: 3.83s, Input: 998 rows (147.21kB); per task: std.dev.: 0.00, Output: 20 rows (2.95kB) Output layout: [date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion] LimitPartial[10] => [[date, time, location, bytes, requestip, method, host, uri, status, referrer, os,\ browser, browserversion]] CPU: 5.00ms (0.13%), Output: 20 rows (2.95kB) Input avg.: 166.33 rows, Input std.dev.: 141.42% TableScan[awsdatacatalog:HiveTableHandle{schemaName=default, tableName=cloudfront_logs,\ analyzePartitionValues=Optional.empty}, grouped = false] => [[date, time, location, bytes, requestip, method, host, uri, st CPU: 3.82s (99.82%), Output: 998 rows (147.21kB) Input avg.: 166.33 rows, Input std.dev.: 141.42% LAYOUT: default.cloudfront_logs date := date:date:0:REGULAR referrer := referrer:string:9:REGULAR os := os:string:10:REGULAR method := method:string:5:REGULAR bytes := bytes:int:3:REGULAR browser := browser:string:11:REGULAR host := host:string:6:REGULAR requestip := requestip:string:4:REGULAR location := location:string:2:REGULAR time := time:string:1:REGULAR uri := uri:string:7:REGULAR browserversion := browserversion:string:12:REGULAR status := status:int:8:REGULAR ``` ### Contoh 2: Gunakan EXPLOW ANALYZE untuk menampilkan rencana kueri dalam format JSON Contoh berikut menunjukkan rencana eksekusi dan biaya komputasi untuk `SELECT` kueri pada CloudFront log. Contoh menentukan JSON sebagai format output. ``` EXPLAIN ANALYZE (FORMAT JSON) SELECT * FROM cloudfront_logs LIMIT 10 ``` #### Hasil ``` { "fragments": [{ "id": "1", "stageStats": { "totalCpuTime": "3.31ms", "inputRows": "10 rows", "inputDataSize": "1514B", "stdDevInputRows": "0.00", "outputRows": "10 rows", "outputDataSize": "1514B" }, "outputLayout": "date, time, location, bytes, requestip, method, host,\ uri, status, referrer, os, browser, browserversion", "logicalPlan": { "1": [{ "name": "Limit", "identifier": "[10]", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host",\ "uri", "status", "referrer", "os", "browser", "browserversion"], "details": "", "distributedNodeStats": { "nodeCpuTime": "0.00ns", "nodeOutputRows": 10, "nodeOutputDataSize": "1514B", "operatorInputRowsStats": [{ "nodeInputRows": 10.0, "nodeInputRowsStdDev": 0.0 }] }, "children": [{ "name": "LocalExchange", "identifier": "[SINGLE] ()", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host",\ "uri", "status", "referrer", "os", "browser", "browserversion"], "details": "", "distributedNodeStats": { "nodeCpuTime": "0.00ns", "nodeOutputRows": 10, "nodeOutputDataSize": "1514B", "operatorInputRowsStats": [{ "nodeInputRows": 0.625, "nodeInputRowsStdDev": 387.2983346207417 }] }, "children": [{ "name": "RemoteSource", "identifier": "[2]", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host",\ "uri", "status", "referrer", "os", "browser", "browserversion"], "details": "", "distributedNodeStats": { "nodeCpuTime": "0.00ns", "nodeOutputRows": 10, "nodeOutputDataSize": "1514B", "operatorInputRowsStats": [{ "nodeInputRows": 0.625, "nodeInputRowsStdDev": 387.2983346207417 }] }, "children": [] }] }] }] } }, { "id": "2", "stageStats": { "totalCpuTime": "1.62s", "inputRows": "500 rows", "inputDataSize": "75564B", "stdDevInputRows": "0.00", "outputRows": "10 rows", "outputDataSize": "1514B" }, "outputLayout": "date, time, location, bytes, requestip, method, host, uri, status,\ referrer, os, browser, browserversion", "logicalPlan": { "1": [{ "name": "LimitPartial", "identifier": "[10]", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host", "uri",\ "status", "referrer", "os", "browser", "browserversion"], "details": "", "distributedNodeStats": { "nodeCpuTime": "0.00ns", "nodeOutputRows": 10, "nodeOutputDataSize": "1514B", "operatorInputRowsStats": [{ "nodeInputRows": 83.33333333333333, "nodeInputRowsStdDev": 223.60679774997897 }] }, "children": [{ "name": "TableScan", "identifier": "[awsdatacatalog:HiveTableHandle{schemaName=default,\ tableName=cloudfront_logs, analyzePartitionValues=Optional.empty},\ grouped = false]", "outputs": ["date", "time", "location", "bytes", "requestip", "method", "host", "uri",\ "status", "referrer", "os", "browser", "browserversion"], "details": "LAYOUT: default.cloudfront_logs\ndate := date:date:0:REGULAR\nreferrer :=\ referrer: string:9:REGULAR\nos := os:string:10:REGULAR\nmethod := method:string:5:\ REGULAR\nbytes := bytes:int:3:REGULAR\nbrowser := browser:string:11:REGULAR\nhost :=\ host:string:6:REGULAR\nrequestip := requestip:string:4:REGULAR\nlocation :=\ location:string:2:REGULAR\ntime := time:string:1: REGULAR\nuri := uri:string:7:\ REGULAR\nbrowserversion := browserversion:string:12:REGULAR\nstatus :=\ status:int:8:REGULAR\n", "distributedNodeStats": { "nodeCpuTime": "1.62s", "nodeOutputRows": 500, "nodeOutputDataSize": "75564B", "operatorInputRowsStats": [{ "nodeInputRows": 83.33333333333333, "nodeInputRowsStdDev": 223.60679774997897 }] }, "children": [] }] }] } }] } ``` ## Sumber daya tambahan Untuk informasi tambahan, lihat sumber daya berikut. + [Pahami Athena JELASKAN hasil pernyataan](athena-explain-statement-understanding.md) + [Lihat rencana eksekusi untuk kueri SQL](query-plans.md) + [Lihat statistik dan detail eksekusi untuk kueri yang diselesaikan](query-stats.md) + Dokumentasi Trino [https://trino.io/docs/current/sql/explain.html](https://trino.io/docs/current/sql/explain.html) + Dokumentasi Trino [https://trino.io/docs/current/sql/explain-analyze.html](https://trino.io/docs/current/sql/explain-analyze.html) + [Optimalkan Kinerja Kueri Federasi menggunakan JELASKAN dan JELASKAN ANALISIS di Amazon](https://aws.amazon.com/blogs/big-data/optimize-federated-query-performance-using-explain-and-explain-analyze-in-amazon-athena/) Athena di Blog *AWS Big* Data. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/7JUyTqglmNU/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/7JUyTqglmNU) # Pahami Athena JELASKAN hasil pernyataan Topik ini memberikan panduan singkat untuk istilah operasional yang digunakan di Athena`EXPLAIN`. ## JELASKAN jenis keluaran pernyataan `EXPLAIN`output pernyataan dapat menjadi salah satu dari dua jenis: + **Rencana logis** - Menunjukkan rencana logis yang digunakan mesin SQL untuk mengeksekusi pernyataan. Sintaks untuk opsi ini`EXPLAIN`atau`EXPLAIN (TYPE LOGICAL)`. + **Rencana terdistribusi** - Menunjukkan rencana eksekusi di lingkungan terdistribusi. Output menunjukkan fragmen, yang memproses tahap. Setiap fragmen rencana diproses oleh satu atau lebih simpul. Data dapat dipertukarkan antara simpul yang memproses fragmen. Sintaks untuk opsi ini`EXPLAIN (TYPE DISTRIBUTED)`. Dalam output untuk rencana terdistribusi, fragmen (tahap pemrosesan) ditunjukkan oleh `Fragment` *number* [*fragment\$1type*], di mana *number* bilangan bulat berbasis nol dan *fragment\$1type* menentukan bagaimana fragmen dieksekusi oleh node. Jenis fragmen, yang memberikan wawasan tata letak Data Exchange, dijelaskan dalam tabel berikut. **Jenis fragmen rencana terdistribusi** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/athena/latest/ug/athena-explain-statement-understanding.html) ## .exchange Istilah terkait pertukaran menggambarkan bagaimana data dipertukarkan antara simpul pekerja. Transfer dapat berupa lokal atau remote. **LocalExchange [*exchange\$1type*] ** Transfer data secara lokal dalam simpul pekerja untuk berbagai tahap kueri. Nilai untuk *exchange\$1type* dapat menjadi salah satu jenis pertukaran logis atau terdistribusi seperti yang dijelaskan nanti di bagian ini. **RemoteExchange [*exchange\$1type*] ** Transfer data antara simpul pekerja untuk berbagai tahap kueri. Nilai untuk *exchange\$1type* dapat menjadi salah satu jenis pertukaran logis atau terdistribusi seperti yang dijelaskan nanti di bagian ini. ### Jenis Pertukaran Logis Jenis pertukaran berikut menggambarkan tindakan yang diambil selama fase pertukaran dari rencana logis. + **`GATHER`**— Sebuah simpul pekerja tunggal mengumpulkan output dari semua simpul pekerja lainnya. Misalnya, tahap terakhir dari kueri pilih mengumpulkan hasil dari semua simpul dan menulis hasilnya ke Amazon S3. + **`REPARTITION`**— Mengirim data baris ke pekerja tertentu berdasarkan skema partisi yang diperlukan untuk diterapkan ke operator berikutnya. + **`REPLICATE`**— Salinan data baris untuk semua pekerja. ### Jenis Pertukaran Terdistribusi Jenis pertukaran berikut menunjukkan tata letak data saat mereka dipertukarkan antara simpul dalam rencana terdistribusi. + **`HASH`**— Pertukaran mendistribusikan data ke beberapa tujuan menggunakan fungsi hash. + **`SINGLE`**— Pertukaran mendistribusikan data ke satu tujuan. ## Pemindaian Istilah berikut menjelaskan bagaimana data dipindai selama kueri. **TableScan ** Memindai data sumber tabel dari Amazon S3 atau konektor Apache Hive dan berlaku pemangkasan partisi yang dihasilkan dari predikat filter. **ScanFilter ** Memindai data sumber tabel dari Amazon S3 atau konektor Hive dan berlaku pemangkasan partisi yang dihasilkan dari predikat filter dan dari predikat filter tambahan tidak diterapkan melalui pemangkasan partisi. **ScanFilterProject ** Pertama, memindai data sumber tabel dari Amazon S3 atau konektor Hive dan berlaku pemangkasan partisi yang dihasilkan dari predikat filter dan dari predikat filter tambahan tidak diterapkan melalui pemangkasan partisi. Kemudian, memodifikasi tata letak memori data output ke proyeksi baru untuk meningkatkan performa tahap selanjutnya. ## Join Bergabung data antara dua tabel. Bergabung dapat dikategorikan berdasarkan bergabung jenis dan jenis distribusi. ### Bergabunglah dengan tipe Bergabung jenis menentukan cara tempat bergabung operasi terjadi. **CrossJoin**— Menghasilkan produk Cartesian dari dua tabel yang digabungkan. **InnerJoin**— Memilih catatan yang memiliki nilai yang cocok di kedua tabel. **LeftJoin**— Memilih semua catatan dari tabel kiri dan catatan yang cocok dari tabel kanan. Jika tidak ada pertandingan terjadi, hasil di sisi kanan adalah NULL. **RightJoin**— Memilih semua catatan dari tabel kanan, dan catatan yang cocok dari tabel kiri. Jika tidak ada pertandingan terjadi, hasil di sisi kiri adalah NULL. **FullJoin**— Memilih semua catatan di mana ada kecocokan di catatan tabel kiri atau kanan. Tabel gabungan berisi semua catatan dari kedua tabel dan mengisi NULLs untuk kecocokan yang hilang di kedua sisi. **catatan** Untuk alasan performa, mesin permintaan dapat menulis ulang kueri bergabung ke jenis bergabung yang berbeda untuk menghasilkan hasil yang sama. Sebagai contoh, batin bergabung kueri dengan predikat pada satu tabel dapat ditulis ulang menjadi`CrossJoin`. Ini mendorong predikat ke fase pemindaian tabel sehingga data yang lebih sedikit dipindai. ### Bergabunglah dengan jenis distribusi jenis distribusi menentukan bagaimana data dipertukarkan antara simpul pekerja saat bergabung operasi dilakukan. **Dipartisi**— Kedua tabel kiri dan kanan hash-dipartisi di semua simpul pekerja. distribusi dipartisi mengkonsumsi lebih sedikit memori di setiap simpul. distribusi dipartisi dapat jauh lebih lambat dari direplikasi bergabung. Dipartisi bergabung cocok saat Anda bergabung dua tabel besar. **Replikasi**— Satu tabel hash-dipartisi di semua simpul pekerja dan tabel lainnya direplikasi ke semua simpul pekerja untuk melakukan operasi bergabung. Distribusi direplikasi dapat jauh lebih cepat daripada dipartisi bergabung, tetapi mengkonsumsi lebih banyak memori di setiap simpul pekerja. Jika tabel yang direplikasi terlalu besar, node pekerja dapat mengalami out-of-memory kesalahan. Replikasi bergabung cocok saat salah satu tabel bergabung kecil.