Amazon Redshift tidak akan lagi mendukung pembuatan UDF Python baru mulai Patch 198. UDF Python yang ada akan terus berfungsi hingga 30 Juni 2026. Untuk informasi lebih lanjut, lihat [posting blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Streaming konsumsi ke tampilan yang terwujud
Topik ini menjelaskan cara menggunakan tampilan terwujud untuk akses cepat ke data streaming.
Penyerapan streaming menyediakan konsumsi data berkecepatan tinggi dengan latensi rendah dari [Amazon Kinesis Data Streams atau Amazon](https://aws.amazon.com//kinesis/data-streams/) Managed [Streaming untuk Apache Kafka Kafka](https://aws.amazon.com//msk/) ke database Amazon Redshift yang disediakan atau Amazon Redshift Tanpa Server. Data mendarat di tampilan terwujud Redshift yang dikonfigurasi untuk tujuan tersebut. Ini menghasilkan akses cepat ke data eksternal. Streaming ingestion menurunkan waktu akses data dan mengurangi biaya penyimpanan. Anda dapat mengonfigurasinya untuk klaster Amazon Redshift atau untuk workgroup Amazon Redshift Tanpa Server Anda, menggunakan kumpulan kecil perintah SQL. Setelah diatur, setiap penyegaran tampilan terwujud dapat menelan ratusan megabyte data per detik.
## Bagaimana data mengalir dari layanan streaming ke Redshift
Ini membantu untuk memahami bagaimana streaming ingestion bekerja dan objek database yang digunakan dalam proses. Data mengalir langsung dari penyedia aliran data ke klaster yang disediakan Amazon Redshift atau ke grup kerja Amazon Redshift Tanpa Server. Tidak ada area pendaratan sementara, seperti ember Amazon S3. Cluster atau workgroup yang disediakan adalah konsumen aliran. Dalam database Redshift, data yang dibaca dari aliran mendarat dalam tampilan yang terwujud. Data diproses saat tiba. Misalnya, nilai JSON dapat dikonsumsi dan dipetakan ke kolom data tampilan terwujud, menggunakan SQL. Saat tampilan terwujud disegarkan, Redshift mengkonsumsi data dari pecahan data Kinesis yang dialokasikan atau partisi Kafka hingga tampilan diperbarui dengan aliran.
Kasus penggunaan untuk konsumsi streaming Amazon Redshift melibatkan data yang dihasilkan terus-menerus dan harus diproses dalam waktu singkat, atau *latensi*, dari asalnya. Ini biasa disebut analitik *dekat waktu nyata*. Sumber dapat mencakup perangkat TI, perangkat telemetri sistem, dan data klik-aliran dari situs web atau aplikasi yang sibuk.
## Praktik terbaik penguraian data untuk meningkatkan kinerja
Saat Anda mengonfigurasi konsumsi streaming, ada opsi bagaimana Anda dapat mengurai data yang masuk. Praktik dapat mencakup melakukan logika bisnis atau pemformatan saat data tiba. Kami merekomendasikan praktik terbaik berikut untuk menghindari kesalahan atau kehilangan data. Ini berasal dari pengujian internal dan membantu pelanggan mengatasi masalah konfigurasi dan penguraian masalah.
+ **Mengekstrak nilai dari data yang dialirkan** *- Jika Anda menggunakan fungsi [JSON\_EXTRACT\_PATH\_TEXT](https://docs.aws.amazon.com/redshift/latest/dg/JSON_EXTRACT_PATH_TEXT.html) dalam definisi tampilan terwujud untuk mengurai atau menghancurkan JSON yang dialirkan, ini dapat memengaruhi kinerja dan latensi secara signifikan.* Untuk menjelaskan, untuk setiap kolom yang diekstraksi menggunakan JSON\_EXTRACT\_PATH\_TEXT, JSON yang masuk diurai ulang. Setelah ini, konversi tipe data, pemfilteran, dan perhitungan logika bisnis terjadi. Ini berarti, misalnya, bahwa jika Anda mengekstrak 10 kolom dari data JSON, setiap catatan JSON diurai 10 kali, yang mencakup logika tambahan. Ini menghasilkan latensi konsumsi yang lebih tinggi. Pendekatan alternatif yang kami sarankan adalah menggunakan [fungsi JSON\_PARSE](https://docs.aws.amazon.com/redshift/latest/dg/JSON_PARSE.html) untuk mengonversi catatan JSON ke tipe data SUPER Redshift. Setelah data yang dialirkan mendarat di tampilan terwujud, gunakan PartiQL untuk mengekstrak string individu dari representasi SUPER dari data JSON. Untuk informasi selengkapnya, lihat [Menanyakan data semi-terstruktur](https://docs.aws.amazon.com/redshift/latest/dg/query-super.html).
Selain itu, perhatikan bahwa JSON\_EXTRACT\_PATH\_TEXT memiliki ukuran data maksimum 16MB. Jadi, jika ada catatan JSON yang lebih besar dari 16MB, memprosesnya dengan JSON\_EXTRACT\_PATH\_TEXT menghasilkan kesalahan.
+ **Memetakan Amazon Kinesis Data Streams aliran atau topik MSK Amazon ke beberapa tampilan terwujud** — Kami tidak menyarankan membuat beberapa tampilan terwujud untuk menyerap data dari satu aliran atau topik. Ini karena setiap tampilan yang terwujud menciptakan konsumen untuk setiap pecahan di aliran atau partisi Kinesis Data Streams dalam topik Kafka. Hal ini dapat mengakibatkan pelambatan atau melebihi throughput aliran atau topik. Ini juga dapat menghasilkan biaya yang lebih tinggi, karena Anda menelan data yang sama beberapa kali. Saat Anda mengonfigurasi konsumsi streaming, kami sarankan Anda membuat satu tampilan terwujud untuk setiap aliran atau topik.
Jika kasus penggunaan Anda mengharuskan Anda mencerna data dari satu aliran KDS atau topik MSK ke dalam beberapa tampilan terwujud, lihat [blog AWS Big Data](https://aws.amazon.com/blogs/big-data/), khususnya [Praktik terbaik untuk menerapkan analitik mendekati waktu nyata menggunakan Amazon Redshift Streaming Ingestion dengan Amazon](https://aws.amazon.com/blogs/big-data/best-practices-to-implement-near-real-time-analytics-using-amazon-redshift-streaming-ingestion-with-amazon-msk/) MSK, sebelum Anda melakukannya.
## Perilaku konsumsi streaming dan tipe data
Tabel berikut menjelaskan rincian perilaku teknis dan batas ukuran untuk berbagai tipe data. Kami merekomendasikan untuk membiasakan diri dengan ini sebelum mengonfigurasi tampilan terwujud untuk konsumsi streaming.
| Fitur atau perilaku | Deskripsi |
| --- | --- |
| Batas panjang topik Kafka | Tidak mungkin menggunakan topik Kafka dengan nama lebih dari 128 karakter (tidak termasuk tanda kutip). Untuk informasi selengkapnya, lihat [Nama dan pengenal](https://docs.aws.amazon.com/redshift/latest/dg/r_names.html). |
| Penyegaran tambahan dan JOIN pada tampilan yang terwujud | Tampilan yang terwujud harus dapat dipertahankan secara bertahap. Komputasi ulang penuh tidak dimungkinkan untuk Kinesis atau Amazon MSK karena mereka tidak menyimpan riwayat streaming atau topik selama 24 jam atau 7 hari, secara default. Anda dapat mengatur periode retensi data yang lebih lama di Kinesis atau Amazon MSK. Namun, ini dapat menghasilkan lebih banyak perawatan dan biaya. Selain itu, JOIN saat ini tidak didukung pada tampilan terwujud yang dibuat pada aliran Kinesis, atau pada topik MSK Amazon. Setelah membuat tampilan terwujud pada aliran atau topik Anda, Anda dapat membuat tampilan terwujud lainnya untuk menggabungkan tampilan terwujud streaming Anda ke tampilan, tabel, atau tampilan terwujud lainnya.
Untuk informasi selengkapnya, lihat [REFRESH MATERIALIZED VIEW](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-refresh-sql-command.html). |
| Rekam penguraian | [Penyerapan streaming Amazon Redshift tidak mendukung catatan penguraian yang telah dikumpulkan oleh Perpustakaan Produser Kinesis (Konsep Kunci KPL - Agregasi).](https://docs.aws.amazon.com/kinesis/latest/dev/kinesis-kpl-concepts.html#kinesis-kpl-concepts-aggretation) Catatan agregat dicerna, tetapi disimpan sebagai data buffer protokol biner. (Lihat [Buffer protokol](https://developers.google.com/protocol-buffers) untuk informasi lebih lanjut.) Bergantung pada bagaimana Anda mendorong data ke Kinesis, Anda mungkin perlu mematikan fitur ini. |
| Nilai duplikat di header Kafka | Klien konsumen streaming Amazon Redshift untuk topik Kafka yang bersumber dari Amazon MSK, Confluent atau Apache Kafka tidak mendukung nilai duplikat di header topik Kafka. |
| Dekompresi | `VARBYTE`tidak mendukung dekompresi. Karena itu, catatan yang berisi data terkompresi tidak dapat ditanyakan di Redshift. Dekompresi data Anda sebelum menambahkannya ke aliran Kinesis atau topik MSK Amazon. |
| Ukuran rekor maksimum | Ukuran maksimum rekaman apa pun yang dapat dikonsumsi Amazon Redshift dari layanan streaming adalah 16.777.216 byte (16 MiB), ukuran maksimum yang didukung oleh tipe data VARBYTE di Amazon Redshift. Namun, Kinesis hanya mendukung ukuran rekor maksimum 1.048.576 byte (1 MiB). Amazon MSK mendukung ukuran rekor maksimum 16.777.216 byte (16 MiB). Oleh karena itu, secara default, Amazon Redshift streaming tampilan terwujud yang dibuat pada aliran data Kinesis akan menyetel ukuran kolom tipe data VARBYTE menjadi 1.048.576 byte (1 MiB), dan tampilan terwujud streaming Amazon Redshift yang dibuat pada topik MSK Amazon akan mengatur ukuran kolom data VARBYTE menjadi 16.777.216 byte (16 MiB). Untuk informasi selengkapnya tentang batas ukuran Kinesis, buka [Kuota dan batas](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html) di Panduan Pengembang Amazon Kinesis Data Streams. |
| Catatan kesalahan | Dalam setiap kasus di mana catatan tidak dapat dicerna ke Redshift karena ukuran data melebihi maksimum, catatan itu dilewati. Penyegaran tampilan terwujud masih berhasil, dalam hal ini, dan segmen dari setiap catatan kesalahan ditulis ke tabel [SYS\_STREAM\_SCAN\_ERRORS](r_SYS_STREAM_SCAN_ERRORS.md) sistem. Kesalahan yang dihasilkan dari logika bisnis, seperti kesalahan dalam perhitungan atau kesalahan yang dihasilkan dari konversi tipe, tidak dilewati. Uji logika dengan hati-hati sebelum Anda menambahkannya ke definisi tampilan terwujud Anda. |
| Konektivitas Multi-VPC pribadi Amazon MSK | [Konektivitas pribadi Amazon MSK Multi-VPC](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html) saat ini tidak didukung untuk konsumsi streaming Redshift. Atau, Anda dapat menggunakan [VPC peering](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) untuk menghubungkan VPC atau [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)untuk menghubungkan VPC dan jaringan lokal melalui hub pusat. Salah satu dari ini dapat memungkinkan Redshift untuk berkomunikasi dengan cluster MSK Amazon atau dengan Amazon MSK Tanpa Server di VPC lain. |
| Penggunaan dan aktivasi penyegaran otomatis | Kueri penyegaran otomatis untuk tampilan atau tampilan yang terwujud diperlakukan sebagai beban kerja pengguna lainnya. Penyegaran otomatis memuat data dari aliran saat tiba.
Penyegaran otomatis dapat diaktifkan secara eksplisit untuk tampilan terwujud yang dibuat untuk konsumsi streaming. Untuk melakukan ini, tentukan `AUTO REFRESH` dalam definisi tampilan terwujud. Penyegaran manual adalah default. Untuk menentukan penyegaran otomatis untuk tampilan terwujud yang ada untuk konsumsi streaming, Anda dapat menjalankannya `ALTER MATERIALIZED VIEW` untuk mengaktifkannya. Untuk informasi selengkapnya, lihat [MEMBUAT TAMPILAN TERWUJUD atau MENGUBAH TAMPILAN](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html) [MATERIALISASI](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_MATERIALIZED_VIEW.html). |
| Konsumsi streaming dan Amazon Redshift Tanpa Server | Petunjuk penyiapan dan konfigurasi yang berlaku untuk konsumsi streaming Amazon Redshift pada klaster yang disediakan juga berlaku untuk konsumsi streaming di Amazon Redshift Tanpa Server. Penting untuk menentukan tingkat RPU yang diperlukan untuk mendukung konsumsi streaming dengan penyegaran otomatis dan beban kerja lainnya. Untuk informasi selengkapnya, lihat [Penagihan untuk Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-billing.html) Tanpa Server. |
| Node Amazon Redshift di zona ketersediaan yang berbeda dari cluster MSK Amazon | Saat Anda mengonfigurasi konsumsi streaming, Amazon Redshift mencoba terhubung ke kluster MSK Amazon di zona ketersediaan yang sama, jika kesadaran rak diaktifkan untuk Amazon MSK. Jika semua node berada di zona ketersediaan yang berbeda dari klaster Amazon Redshift, Anda dapat dikenakan biaya transfer data lintas zona ketersediaan. Untuk menghindari hal ini, simpan setidaknya satu node cluster broker MSK Amazon di AZ yang sama dengan cluster atau workgroup yang disediakan Redshift Anda. |
| Segarkan lokasi awal | Setelah membuat tampilan terwujud, penyegaran awalnya dimulai dari aliran Kinesis, atau dari offset 0 topik MSK Amazon. `TRIM_HORIZON` |
| Format data | Format data yang didukung terbatas pada format yang dapat dikonversi`VARBYTE`. Untuk informasi selengkapnya, lihat [Jenis VARBYTE](r_VARBYTE_type.md) dan [Operator VARBYTE](r_VARBYTE_OPERATORS.md). |
| Menambahkan catatan ke tabel | Anda dapat menjalankan `ALTER TABLE APPEND` untuk menambahkan baris ke tabel target dari tampilan terwujud sumber yang ada. Ini hanya berfungsi jika tampilan terwujud dikonfigurasi untuk konsumsi streaming. Untuk informasi lebih lanjut, lihat [ALTER TABLE APPEND](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_TABLE_APPEND.html).
`ALTER TABLE APPEND`operasi menyimpan kunci eksklusif saat dijalankan di Amazon Redshift streaming tampilan terwujud yang terhubung ke salah satu dari berikut ini:[See the AWS documentation website for more details](http://docs.aws.amazon.com/id_id/redshift/latest/dg/materialized-view-streaming-ingestion.html) |
| Menjalankan TRUNCATE atau DELETE | Anda dapat menghapus rekaman dari tampilan terwujud yang digunakan untuk streaming konsumsi, menggunakan yang berikut ini:[See the AWS documentation website for more details](http://docs.aws.amazon.com/id_id/redshift/latest/dg/materialized-view-streaming-ingestion.html)
`TRUNCATE`dan `DELETE` operasi menyimpan kunci eksklusif saat dijalankan di Amazon Redshift streaming tampilan terwujud yang terhubung ke salah satu dari berikut ini:[See the AWS documentation website for more details](http://docs.aws.amazon.com/id_id/redshift/latest/dg/materialized-view-streaming-ingestion.html) |
| Non-lowercase pengidentifikasi | Saat membuat streaming tampilan terwujud di Amazon Managed Streaming for Apache Kafka topik atau Kinesis Data Streams yang berisi pengidentifikasi non-huruf kecil, penyegaran otomatis mungkin gagal. Untuk mengatasinya, lakukan salah satu hal berikut:[See the AWS documentation website for more details](http://docs.aws.amazon.com/id_id/redshift/latest/dg/materialized-view-streaming-ingestion.html)Pengaturan `enable_case_sensitive_identifier` di tingkat pengguna tidak cukup untuk penyegaran otomatis, tetapi akan berfungsi untuk penyegaran manual.
Untuk informasi selengkapnya tentang pengidentifikasi peka huruf besar/kecil, lihat. [enable\_case\_sensitive\_identifier](r_enable_case_sensitive_identifier.md) |
| Idempotensi | Amazon Redshift menjamin bahwa setiap rekaman diproses tepat sekali saat menelan data dari sumber streaming. Jaminan ini berlaku untuk dua jenis sumber: Amazon Kinesis (menggunakan pengenal aliran, pecahan, dan nomor urut) dan Apache Kafka (menggunakan pengidentifikasi topik, partisi, dan offset), termasuk Amazon Managed Streaming for Apache Kafka (Amazon MSK) dan Confluent Cloud. |