Stempel waktu dan Kolom ROWTIME - Panduan Developer Amazon Kinesis Data Analytics untuk Aplikasi SQL
Memahami Berbagai Waktu dalam Analitik Streaming

Setelah mempertimbangkan dengan cermat, kami memutuskan untuk menghentikan Amazon Kinesis Data Analytics untuk aplikasi SQL dalam dua langkah:

1. Mulai 15 Oktober 2025, Anda tidak akan dapat membuat Kinesis Data Analytics baru untuk aplikasi SQL.

2. 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.

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.

Anda dapat mengakses kolom ROWTIME di pernyataan SELECT seperti kolom lain di aliran dalam aplikasi Anda. Sebagai 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. 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+1) meskipun catatan tiba terlambat.