Setelah mempertimbangkan dengan cermat, kami memutuskan untuk menghentikan Amazon Kinesis Data Analytics untuk aplikasi SQL:
1. Mulai **1 September 2025,** kami tidak akan memberikan perbaikan bug untuk Amazon Kinesis Data Analytics untuk aplikasi SQL karena kami akan memiliki dukungan terbatas untuk itu, mengingat penghentian yang akan datang.
2. Mulai **15 Oktober 2025,** Anda tidak akan dapat membuat Kinesis Data Analytics baru untuk aplikasi SQL.
3. Kami akan menghapus aplikasi Anda mulai **27 Januari 2026**. Anda tidak akan dapat memulai atau mengoperasikan Amazon Kinesis Data Analytics untuk aplikasi SQL. Support tidak akan lagi tersedia untuk Amazon Kinesis Data Analytics untuk SQL sejak saat itu. Untuk informasi selengkapnya, lihat [Amazon Kinesis Data Analytics untuk penghentian Aplikasi SQL](discontinuation.md).
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Stempel waktu dan Kolom ROWTIME
Aliran dalam aplikasi mencakup kolom khusus yang disebut `ROWTIME`. Kolom ini menyimpan stempel waktu ketika Amazon Kinesis Data Analytics memasukkan baris di aliran dalam aplikasi pertama. `ROWTIME` mencerminkan stempel waktu tempat Amazon Kinesis Data Analytics memasukkan catatan ke aliran dalam aplikasi pertama setelah membaca dari sumber streaming. Nilai `ROWTIME` ini selanjutnya dipertahankan di seluruh aplikasi Anda.
**catatan**
Ketika Anda memompa catatan dari satu aliran dalam aplikasi ke aliran lainnya, Anda tidak perlu secara eksplisit menyalin kolom `ROWTIME`, Amazon Kinesis Data Analytics akan menyalin kolom ini untuk Anda.
Amazon Kinesis Data Analytics menjamin nilai-nilai `ROWTIME` ditingkatkan secara monoton. Anda menggunakan stempel waktu ini di kueri jendela berbasis waktu. Untuk informasi selengkapnya, lihat [Kueri Jendela](windowed-sql.md).
Anda dapat mengakses kolom ROWTIME di pernyataan `SELECT` seperti kolom lain di aliran dalam aplikasi Anda. Contoh:
```
SELECT STREAM ROWTIME,
some_col_1,
some_col_2
FROM SOURCE_SQL_STREAM_001
```
## Memahami Berbagai Waktu dalam Analitik Streaming
Selain `ROWTIME`, ada tipe waktu lain dalam aplikasi streaming waktu nyata. Ini adalah:
+ **Event time** (Waktu peristiwa) – Stempel waktu ketika peristiwa terjadi. Ini kadang-kadang juga disebut *waktu sisi klien*. Waktu ini sering kali berguna ketika digunakan dalam analitik karena merupakan waktu ketika peristiwa terjadi. Namun, banyak sumber peristiwa, seperti ponsel dan klien web, tidak memiliki jam yang dapat diandalkan, yang dapat menyebabkan waktu yang tidak akurat. Selain itu, masalah konektivitas dapat menyebabkan catatan yang muncul di aliran tidak dalam urutan yang sama dengan peristiwa yang terjadi.
+ **Ingest time** (Waktu penyerapan) – Stempel waktu ketika catatan ditambahkan ke sumber streaming. Amazon Kinesis Data Streams mencakup bidang yang disebut `APPROXIMATE_ARRIVAL_TIME` di setiap catatan yang menyediakan stempel waktu ini. Ini kadang-kadang juga disebut sebagai *waktu sisi server*. Waktu penyerapan ini sering kali mendekati waktu kejadian. Jika ada jenis keterlambatan dalam penyerapan catatan ke aliran, ini dapat menyebabkan ketidakakuratan, yang biasanya jarang terjadi. Selain itu, waktu penyerapan jarang salah, tetapi bisa terjadi karena sifat data streaming yang terdistribusi. Oleh karena itu, waktu penyerapan sebagian besar merupakan cerminan waktu peristiwa yang akurat dan berurutan.
+ **Processing time** (Waktu pemrosesan) – Stempel waktu ketika Amazon Kinesis Data Analytics memasukkan baris di aliran dalam aplikasi pertama. Amazon Kinesis Data Analytics menyediakan stempel waktu ini di kolom `ROWTIME` yang ada di setiap aliran dalam aplikasi. Waktu pemrosesan selalu meningkat secara monoton. Namun ini tidak akan akurat jika aplikasi Anda tertinggal. (Jika aplikasi tertinggal, waktu pemrosesan tidak mencerminkan waktu peristiwa secara akurat.) `ROWTIME` ini akurat dalam kaitannya dengan jam dinding, tetapi mungkin bukan waktu ketika peristiwa benar-benar terjadi.
Menggunakan setiap waktu ini dalam kueri jendela yang berbasis waktu memiliki kelebihan dan kekurangan. Sebaiknya pilih satu atau beberapa waktu ini, dan strategi untuk menangani kerugian yang relevan berdasarkan skenario kasus penggunaan Anda.
**catatan**
Jika Anda menggunakan jendela berbasis baris, waktu bukan merupakan masalah dan Anda dapat mengabaikan bagian ini.
Kami merekomendasikan strategi dua jendela yang menggunakan dua berbasis waktu, `ROWTIME` dan salah satu waktu lainnya (waktu penyerapan atau peristiwa).
+ Gunakan `ROWTIME` sebagai jendela pertama, yang mengontrol seberapa sering kueri memancarkan hasil, seperti yang ditunjukkan dalam contoh berikut. Ini tidak digunakan sebagai waktu logis.
+ Gunakan salah satu waktu lain yang merupakan waktu logis yang ingin Anda kaitkan dengan analitik Anda. Waktu ini mewakili kapan peristiwa terjadi. Pada contoh berikut, tujuan analitik adalah mengelompokkan catatan dan dan kembali menghitung dengan ticker
Keuntungan strategi ini adalah ini dapat menggunakan waktu yang mewakili kapan peristiwa terjadi. Ini dapat menangani dengan mudah ketika aplikasi Anda tertinggal atau ketika peristiwa tiba tidak sesuai urutan. Jika aplikasi tertinggal ketika membawa catatan ke aliran dalam aplikasi, catatan masih dikelompokkan berdasarkan waktu logis di jendela kedua. Kueri menggunakan `ROWTIME` untuk menjamin urutan pemrosesan. Catatan yang terlambat (stempel waktu penyerapan menunjukkan nilai sebelumnya dibandingkan dengan nilai `ROWTIME`) juga berhasil diproses.
Pertimbangkan kueri berikut terhadap aliran demo yang digunakan dalam [Latihan Memulai](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/get-started-exercise.html). Kueri menggunakan klausul `GROUP BY` dan memancarkan hitungan ticker dalam jendela tumbling satu menit.
```
CREATE OR REPLACE STREAM "DESTINATION_SQL_STREAM"
("ingest_time" timestamp,
"APPROXIMATE_ARRIVAL_TIME" timestamp,
"ticker_symbol" VARCHAR(12),
"symbol_count" integer);
CREATE OR REPLACE PUMP "STREAM_PUMP" AS
INSERT INTO "DESTINATION_SQL_STREAM"
SELECT STREAM STEP("SOURCE_SQL_STREAM_001".ROWTIME BY INTERVAL '60' SECOND) AS "ingest_time",
STEP("SOURCE_SQL_STREAM_001".APPROXIMATE_ARRIVAL_TIME BY INTERVAL '60' SECOND) AS "APPROXIMATE_ARRIVAL_TIME",
"TICKER_SYMBOL",
COUNT(*) AS "symbol_count"
FROM "SOURCE_SQL_STREAM_001"
GROUP BY "TICKER_SYMBOL",
STEP("SOURCE_SQL_STREAM_001".ROWTIME BY INTERVAL '60' SECOND),
STEP("SOURCE_SQL_STREAM_001".APPROXIMATE_ARRIVAL_TIME BY INTERVAL '60' SECOND);
```
Di `GROUP BY`, Anda pertama-tama mengelompokkan catatan berdasarkan `ROWTIME` di jendela satu menit, lalu dengan `APPROXIMATE_ARRIVAL_TIME`.
Nilai stempel waktu dalam hasil dibulatkan ke interval 60 detik terdekat. Hasil grup pertama yang dipancarkan oleh kueri menunjukkan catatan di menit pertama. Grup kedua hasil yang dipancarkan menunjukkan catatan di menit berikutnya berdasarkan `ROWTIME`. Catatan terakhir menunjukkan aplikasi terlambat dalam membawa catatan di aliran dalam aplikasi (ini menunjukkan nilai `ROWTIME` yang terlambat dibandingkan dengan stempel waktu penyerapan).
```
ROWTIME INGEST_TIME TICKER_SYMBOL SYMBOL_COUNT
--First one minute window.
2016-07-19 17:05:00.0 2016-07-19 17:05:00.0 ABC 10
2016-07-19 17:05:00.0 2016-07-19 17:05:00.0 DEF 15
2016-07-19 17:05:00.0 2016-07-19 17:05:00.0 XYZ 6
–-Second one minute window.
2016-07-19 17:06:00.0 2016-07-19 17:06:00.0 ABC 11
2016-07-19 17:06:00.0 2016-07-19 17:06:00.0 DEF 11
2016-07-19 17:06:00.0 2016-07-19 17:05:00.0 XYZ 1 ***
***late-arriving record, instead of appearing in the result of the
first 1-minute windows (based on ingest_time, it is in the result
of the second 1-minute window.
```
Anda dapat menggabungkan hasil untuk hitungan akurat akhir per menit dengan mendorong hasil ke basis data hilir. Misalnya, Anda dapat mengonfigurasi output aplikasi untuk mempertahankan hasil ke aliran pengiriman Firehose yang dapat menulis ke tabel Amazon Redshift. Setelah hasil berada di tabel Amazon Redshift, Anda dapat mengkueri tabel untuk mengomputasi total jumlah grup dengan `Ticker_Symbol`. Dalam hal `XYZ`, totalnya akurat (6\$11) meskipun catatan tiba terlambat.