Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Optimalkan konsumen Amazon Kinesis Data Streams
Anda dapat lebih mengoptimalkan konsumen Amazon Kinesis Data Streams berdasarkan perilaku tertentu yang Anda lihat.
Tinjau topik berikut untuk mengidentifikasi solusi.
**Topics**
+ [Tingkatkan pemrosesan latensi rendah](kinesis-low-latency.md)
+ [Memproses data serial menggunakan Perpustakaan AWS Lambda Produser Amazon Kinesis](kinesis-record-deaggregation.md)
+ [Gunakan resharding, scaling, dan parallel processing untuk mengubah jumlah pecahan](kinesis-record-processor-scaling.md)
+ [Menangani catatan duplikat](kinesis-record-processor-duplicates.md)
+ [Menangani startup, shutdown, dan throttling](kinesis-record-processor-additional-considerations.md)
# Tingkatkan pemrosesan latensi rendah
*Penundaan propagasi* didefinisikan sebagai end-to-end latensi dari saat catatan ditulis ke aliran hingga dibaca oleh aplikasi konsumen. Penundaan ini bervariasi tergantung pada sejumlah faktor, tetapi terutama dipengaruhi oleh interval pemungutan suara aplikasi konsumen.
Untuk sebagian besar aplikasi, kami merekomendasikan polling setiap pecahan satu kali per detik per aplikasi. Ini memungkinkan Anda memiliki beberapa aplikasi konsumen yang memproses aliran secara bersamaan tanpa mencapai batas Amazon Kinesis Data Streams 5 panggilan per detik. `GetRecords` Selain itu, memproses batch data yang lebih besar cenderung lebih efisien dalam mengurangi jaringan dan latensi hilir lainnya dalam aplikasi Anda.
Default KCL diatur untuk mengikuti praktik terbaik pemungutan suara setiap 1 detik. Default ini menghasilkan penundaan propagasi rata-rata yang biasanya di bawah 1 detik.
Catatan Kinesis Data Streams tersedia untuk dibaca segera setelah ditulis. Ada beberapa kasus penggunaan yang perlu memanfaatkan ini dan memerlukan konsumsi data dari aliran segera setelah tersedia. Anda dapat mengurangi penundaan propagasi secara signifikan dengan mengganti pengaturan default KCL untuk melakukan polling lebih sering, seperti yang ditunjukkan pada contoh berikut.
Kode konfigurasi Java KCL:
```
kinesisClientLibConfiguration = new
KinesisClientLibConfiguration(applicationName,
streamName,
credentialsProvider,
workerId).withInitialPositionInStream(initialPositionInStream).withIdleTimeBetweenReadsInMillis(250);
```
Pengaturan file properti untuk Python dan Ruby KCL:
```
idleTimeBetweenReadsInMillis = 250
```
**catatan**
Karena Kinesis Data Streams memiliki batas `GetRecords` 5 panggilan per detik, per shard, `idleTimeBetweenReadsInMillis` menyetel properti lebih rendah dari 200ms dapat mengakibatkan aplikasi Anda mengamati pengecualian. `ProvisionedThroughputExceededException` Terlalu banyak pengecualian ini dapat mengakibatkan back-off eksponensial dan dengan demikian menyebabkan latensi tak terduga yang signifikan dalam pemrosesan. Jika Anda menyetel properti ini pada atau tepat di atas 200 ms dan memiliki lebih dari satu aplikasi pemrosesan, Anda akan mengalami pelambatan serupa.
# Memproses data serial menggunakan Perpustakaan AWS Lambda Produser Amazon Kinesis
[Amazon Kinesis Producer Library](https://docs.aws.amazon.com/kinesis/latest/dev/developing-producers-with-kpl.html) (KPL) menggabungkan rekaman kecil yang diformat pengguna ke dalam rekaman yang lebih besar hingga 1 MB untuk memanfaatkan throughput Amazon Kinesis Data Streams dengan lebih baik. Sementara KCL untuk Java mendukung deagregasi catatan ini, Anda perlu menggunakan modul khusus untuk mendeagregasi catatan saat menggunakan AWS Lambda sebagai konsumen aliran Anda. Anda dapat memperoleh kode proyek dan instruksi yang diperlukan dari GitHub [Modul Deagregasi Perpustakaan Produser Amazon Kinesis](https://github.com/awslabs/kinesis-deaggregation) untuk Lambda. AWS Komponen dalam proyek ini memberi Anda kemampuan untuk memproses data serial KPL dalam AWS Lambda, di Java, Node.js dan Python. Komponen ini juga dapat digunakan sebagai bagian dari aplikasi [KCL multi-lang](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client-multilang/src/main/java/software/amazon/kinesis/multilang/package-info.java).
# Gunakan resharding, scaling, dan parallel processing untuk mengubah jumlah pecahan
*Resharding* memungkinkan Anda untuk menambah atau mengurangi jumlah pecahan dalam aliran untuk beradaptasi dengan perubahan laju data yang mengalir melalui aliran. Resharding biasanya dilakukan oleh aplikasi administratif yang memantau metrik penanganan data shard. Meskipun KCL itu sendiri tidak memulai operasi resharding, KCL dirancang untuk beradaptasi dengan perubahan jumlah pecahan yang dihasilkan dari resharding.
Seperti disebutkan dalam[Gunakan tabel sewa untuk melacak pecahan yang diproses oleh aplikasi konsumen KCL](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable), KCL melacak pecahan dalam aliran menggunakan tabel Amazon DynamoDB. Ketika pecahan baru dibuat sebagai hasil dari resharding, KCL menemukan pecahan baru dan mengisi baris baru dalam tabel. Para pekerja secara otomatis menemukan pecahan baru dan membuat prosesor untuk menangani data dari mereka. KCL juga mendistribusikan pecahan di sungai di semua pekerja yang tersedia dan prosesor rekaman.
KCL memastikan bahwa setiap data yang ada dalam pecahan sebelum resharding diproses terlebih dahulu. Setelah data diproses, data dari pecahan baru dikirim ke prosesor rekaman. Dengan cara ini, KCL mempertahankan urutan di mana catatan data ditambahkan ke aliran untuk kunci partisi tertentu.
## Contoh: Resharding, scaling, dan parallel processing
Contoh berikut menggambarkan bagaimana KCL membantu Anda menangani penskalaan dan resharding:
+ Misalnya, jika aplikasi Anda berjalan pada satu instans EC2, dan sedang memproses satu aliran data Kinesis yang memiliki empat pecahan. Contoh yang satu ini memiliki satu pekerja KCL dan empat prosesor rekaman (satu prosesor rekaman untuk setiap pecahan). Keempat prosesor rekaman ini berjalan secara paralel dalam proses yang sama.
+ Selanjutnya, jika Anda menskalakan aplikasi untuk menggunakan instance lain, Anda memiliki dua instance yang memproses satu aliran yang memiliki empat pecahan. Ketika pekerja KCL memulai pada instance kedua, ia menyeimbangkan beban dengan instance pertama, sehingga setiap instance sekarang memproses dua pecahan.
+ Jika Anda kemudian memutuskan untuk membagi empat pecahan menjadi lima pecahan. KCL kembali mengoordinasikan pemrosesan di seluruh instance: satu instance memproses tiga pecahan, dan yang lainnya memproses dua pecahan. Koordinasi serupa terjadi saat Anda menggabungkan pecahan.
Biasanya, ketika Anda menggunakan KCL, Anda harus memastikan bahwa jumlah instance tidak melebihi jumlah pecahan (kecuali untuk tujuan siaga kegagalan). Setiap pecahan diproses oleh tepat satu pekerja KCL dan memiliki persis satu prosesor rekaman yang sesuai, jadi Anda tidak perlu beberapa contoh untuk memproses satu pecahan. Namun, satu pekerja dapat memproses sejumlah pecahan, jadi tidak apa-apa jika jumlah pecahan melebihi jumlah instance.
Untuk meningkatkan pemrosesan dalam aplikasi Anda, Anda harus menguji kombinasi dari pendekatan ini:
+ Meningkatkan ukuran instans (karena semua prosesor rekaman berjalan secara paralel dalam suatu proses)
+ Meningkatkan jumlah instance hingga jumlah maksimum pecahan terbuka (karena pecahan dapat diproses secara independen)
+ Meningkatkan jumlah pecahan (yang meningkatkan tingkat paralelisme)
Perhatikan bahwa Anda dapat menggunakan Auto Scaling untuk menskalakan instans secara otomatis berdasarkan metrik yang sesuai. Untuk informasi selengkapnya, lihat [Panduan Pengguna Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/).
Ketika resharding meningkatkan jumlah pecahan dalam aliran, peningkatan yang sesuai dalam jumlah prosesor rekaman meningkatkan beban pada instans EC2 yang menghosting mereka. Jika instans merupakan bagian dari grup Auto Scaling, dan beban meningkat cukup, grup Auto Scaling menambahkan lebih banyak instance untuk menangani peningkatan beban. Anda harus mengonfigurasi instans untuk meluncurkan aplikasi Amazon Kinesis Data Streams saat startup, sehingga pekerja tambahan dan prosesor rekaman langsung aktif di instans baru.
Untuk informasi lebih lanjut tentang resharding, lihat. [Reshard aliran](kinesis-using-sdk-java-resharding.md)
# Menangani catatan duplikat
Ada dua alasan utama mengapa catatan dapat dikirimkan lebih dari satu kali ke aplikasi Amazon Kinesis Data Streams Anda: percobaan ulang produsen dan percobaan ulang konsumen. Aplikasi Anda harus mengantisipasi dan menangani pemrosesan catatan individual dengan tepat beberapa kali.
## Produsen mencoba lagi
Pertimbangkan produser yang mengalami batas waktu terkait jaringan setelah melakukan panggilan`PutRecord`, tetapi sebelum dapat menerima pengakuan dari Amazon Kinesis Data Streams. Produser tidak dapat memastikan apakah rekaman dikirim ke Kinesis Data Streams. Dengan asumsi bahwa setiap catatan penting untuk aplikasi, produser akan ditulis untuk mencoba lagi panggilan dengan data yang sama. Jika kedua `PutRecord` panggilan pada data yang sama berhasil dilakukan ke Kinesis Data Streams, maka akan ada dua catatan Kinesis Data Streams. Meskipun kedua catatan memiliki data yang identik, mereka juga memiliki nomor urut yang unik. Aplikasi yang membutuhkan jaminan ketat harus menyematkan kunci utama dalam catatan untuk menghapus duplikat nanti saat memproses. Perhatikan bahwa jumlah duplikat karena percobaan ulang produsen biasanya rendah dibandingkan dengan jumlah duplikat karena percobaan ulang konsumen.
**catatan**
Jika Anda menggunakan AWS SDK`PutRecord`, pelajari tentang [perilaku Coba Ulang SDK di panduan](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) pengguna *AWS SDKs dan Alat*.
## Coba ulang konsumen
Percobaan ulang konsumen (aplikasi pemrosesan data) terjadi ketika prosesor rekaman dimulai ulang. Rekam prosesor untuk restart shard yang sama dalam kasus berikut:
1. Seorang pekerja berhenti secara tak terduga
1. Contoh pekerja ditambahkan atau dihapus
1. Pecahan digabungkan atau dibagi
1. Aplikasi ini digunakan
Dalam semua kasus ini, pemetaan shards-to-worker-to -record-processor terus diperbarui untuk pemrosesan keseimbangan beban. Prosesor shard yang dimigrasikan ke instance lain memulai ulang catatan pemrosesan dari pos pemeriksaan terakhir. Ini menghasilkan pemrosesan rekaman duplikat seperti yang ditunjukkan pada contoh di bawah ini. Untuk informasi selengkapnya tentang load-balancing, lihat. [Gunakan resharding, scaling, dan parallel processing untuk mengubah jumlah pecahan](kinesis-record-processor-scaling.md)
### Contoh: Percobaan ulang konsumen menghasilkan catatan yang dikirim ulang
Dalam contoh ini, Anda memiliki aplikasi yang terus membaca catatan dari aliran, menggabungkan catatan ke dalam file lokal, dan mengunggah file ke Amazon S3. Untuk mempermudah, asumsikan hanya ada 1 pecahan dan 1 pekerja yang memproses pecahan. Perhatikan contoh urutan peristiwa berikut, dengan asumsi bahwa pos pemeriksaan terakhir berada pada nomor rekor 10000:
1. Seorang pekerja membaca kumpulan catatan berikutnya dari pecahan, mencatat 10001 hingga 20000.
1. Pekerja kemudian meneruskan batch catatan ke prosesor rekaman terkait.
1. Pemroses rekaman mengumpulkan data, membuat file Amazon S3, dan mengunggah file ke Amazon S3 dengan sukses.
1. Pekerja berhenti secara tak terduga sebelum pos pemeriksaan baru dapat terjadi.
1. Aplikasi, pekerja, dan prosesor rekaman restart.
1. Pekerja sekarang mulai membaca dari pos pemeriksaan terakhir yang berhasil, dalam hal ini 10001.
Dengan demikian, catatan 10001-20000 dikonsumsi lebih dari satu kali.
### Menjadi tangguh terhadap percobaan ulang konsumen
Meskipun catatan dapat diproses lebih dari satu kali, aplikasi Anda mungkin ingin menyajikan efek samping seolah-olah catatan diproses hanya satu kali (pemrosesan idempoten). Solusi untuk masalah ini bervariasi dalam kompleksitas dan akurasi. Jika tujuan data akhir dapat menangani duplikat dengan baik, kami sarankan untuk mengandalkan tujuan akhir untuk mencapai pemrosesan idempoten. Misalnya, dengan [Opensearch](https://www.opensearch.org/) Anda dapat menggunakan kombinasi versi dan unik IDs untuk mencegah pemrosesan duplikat.
Dalam contoh aplikasi di bagian sebelumnya, ia terus membaca catatan dari aliran, menggabungkan catatan ke dalam file lokal, dan mengunggah file ke Amazon S3. Seperti yang diilustrasikan, catatan 10001 -20000 dikonsumsi lebih dari satu kali sehingga menghasilkan beberapa file Amazon S3 dengan data yang sama. Salah satu cara untuk mengurangi duplikat dari contoh ini adalah memastikan bahwa langkah 3 menggunakan skema berikut:
1. Record Processor menggunakan jumlah catatan tetap per file Amazon S3, seperti 5000.
1. Nama file menggunakan skema ini: awalan Amazon S3, shard-id, dan file. `First-Sequence-Num` Dalam hal ini, bisa jadi seperti`sample-shard000001-10001`.
1. Setelah Anda mengunggah file Amazon S3, periksa dengan menentukan. `Last-Sequence-Num` Dalam hal ini, Anda akan memeriksa di nomor rekor 15000.
Dengan skema ini, bahkan jika catatan diproses lebih dari satu kali, file Amazon S3 yang dihasilkan memiliki nama yang sama dan memiliki data yang sama. Percobaan ulang hanya menghasilkan penulisan data yang sama ke file yang sama lebih dari satu kali.
Dalam kasus operasi reshard, jumlah catatan yang tersisa di pecahan mungkin kurang dari jumlah tetap yang Anda inginkan. Dalam hal ini, `shutdown()` metode Anda harus menyiram file ke Amazon S3 dan pos pemeriksaan pada nomor urut terakhir. Skema di atas juga kompatibel dengan operasi reshard.
# Menangani startup, shutdown, dan throttling
Berikut adalah beberapa pertimbangan tambahan untuk dimasukkan ke dalam desain aplikasi Amazon Kinesis Data Streams Anda.
**Topics**
+ [Memulai produsen data dan konsumen data](#kinesis-record-processor-producer-consumer-coordination)
+ [Matikan aplikasi Amazon Kinesis Data Streams](#developing-consumers-with-kcl-shutdown)
+ [Baca pelambatan](#kinesis-record-processor-read-throttling)
## Memulai produsen data dan konsumen data
Secara default, KCL mulai membaca catatan dari ujung aliran, yang merupakan catatan yang paling baru ditambahkan. Dalam konfigurasi ini, jika aplikasi penghasil data menambahkan catatan ke aliran sebelum prosesor rekaman penerima berjalan, catatan tidak dibaca oleh prosesor rekaman setelah mereka memulai.
Untuk mengubah perilaku prosesor rekaman sehingga selalu membaca data dari awal aliran, tetapkan nilai berikut dalam file properti untuk aplikasi Amazon Kinesis Data Streams Anda:
```
initialPositionInStream = TRIM_HORIZON
```
Secara default, Amazon Kinesis Data Streams menyimpan semua data selama 24 jam. Ini juga mendukung retensi yang diperpanjang hingga 7 hari dan retensi jangka panjang hingga 365 hari. Kerangka waktu ini disebut *periode retensi*. Mengatur posisi awal ke `TRIM_HORIZON` akan memulai prosesor rekaman dengan data tertua dalam aliran, seperti yang didefinisikan oleh periode retensi. Bahkan dengan `TRIM_HORIZON` pengaturannya, jika prosesor rekaman dimulai setelah waktu yang lebih lama berlalu daripada periode retensi, maka beberapa catatan dalam aliran tidak akan lagi tersedia. Untuk alasan ini, Anda harus selalu meminta aplikasi konsumen membaca dari aliran dan menggunakan CloudWatch metrik `GetRecords.IteratorAgeMilliseconds` untuk memantau bahwa aplikasi mengikuti data yang masuk.
Dalam beberapa skenario, mungkin baik-baik saja bagi prosesor rekaman untuk melewatkan beberapa catatan pertama dalam aliran. Misalnya, Anda mungkin menjalankan beberapa catatan awal melalui aliran untuk menguji apakah aliran berfungsi end-to-end seperti yang diharapkan. Setelah melakukan verifikasi awal ini, Anda kemudian akan memulai pekerja Anda dan mulai memasukkan data produksi ke dalam aliran.
Untuk informasi selengkapnya tentang pengaturan `TRIM_HORIZON`, lihat [Gunakan iterator shard](developing-consumers-with-sdk.md#kinesis-using-sdk-java-get-data-shard-iterators).
## Matikan aplikasi Amazon Kinesis Data Streams
Ketika aplikasi Amazon Kinesis Data Streams Anda telah menyelesaikan tugas yang dimaksudkan, Anda harus mematikannya dengan menghentikan instans EC2 yang menjalankannya. Anda dapat mengakhiri instance menggunakan [Konsol Manajemen AWS](https://console.aws.amazon.com//ec2/home)atau. [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/ec2/index.html)
Setelah mematikan aplikasi Amazon Kinesis Data Streams, Anda harus menghapus tabel Amazon DynamoDB yang digunakan KCL untuk melacak status aplikasi.
## Baca pelambatan
Throughput aliran disediakan pada tingkat pecahan. Setiap pecahan memiliki throughput baca hingga 5 transaksi per detik untuk pembacaan, hingga total kecepatan baca data maksimum 2 MB per detik. Jika aplikasi (atau sekelompok aplikasi yang beroperasi pada aliran yang sama) mencoba mendapatkan data dari pecahan dengan kecepatan yang lebih cepat, Kinesis Data Streams membatasi operasi Get yang sesuai.
Dalam aplikasi Amazon Kinesis Data Streams, jika prosesor rekaman memproses data lebih cepat dari batas — seperti dalam kasus failover — pelambatan terjadi. Karena KCL mengelola interaksi antara aplikasi dan Kinesis Data Streams, pengecualian throttling terjadi dalam kode KCL daripada dalam kode aplikasi. Namun, karena KCL mencatat pengecualian ini, Anda melihatnya di log.
Jika Anda menemukan bahwa aplikasi Anda dibatasi secara konsisten, Anda harus mempertimbangkan untuk meningkatkan jumlah pecahan untuk aliran.