oleh: David Anderson, Principal Software Practice Lead di Confluent Flink SQL adalah mesin yang kuat yang dirancang untuk memproses real-time, streaming data menggunakan bahasa SQL yang akrab dan konsep relasional yang mendasarinya. Ini telah lama menjadi solusi yang efektif untuk banyak domain aplikasi, terutama pipa ETL dan beban kerja analitis, tetapi sampai saat ini Flink SQL telah kekurangan fitur kunci yang sering diperlukan untuk aplikasi yang didorong oleh acara. Dengan perkembangan terbaru yang dijelaskan di sini, APIs relasional Apache Flink – yaitu, Flink SQL dan Table API – telah matang sampai titik di mana memanfaatkan abstraksi yang kuat dan operator built-in mereka tidak lagi memerlukan kompromi untuk memiliki akses ke primitif pemrosesan aliran tingkat rendah Flink. Semua yang dikatakan di sini berlaku sama untuk kedua Flink SQL dan Table API. Keduanya duduk di atas runtime yang sama - konsep dan kemampuan dasar sama - mereka hanya diakses dari Java atau Python, bukan SQL, jika Anda memilih untuk menggunakan Table API. Menggunakan kasus API relasional ini sangat cocok untuk dua kategori aplikasi yang luas. Agentic AI Aplikasi AI modern sering membutuhkan akses ke informasi real-time yang dinamis.Flinks SQL memfasilitasi agency AI dengan membuatnya mudah untuk menggabungkan aliran acara real-time dengan wawasan dari agen, model, dan layanan.Ini berarti bahwa saat aliran data melaluiFlinks, dapat diperkaya atau dikonfirmasi dengan menginterogasi layanan ini secara real-time, memberikan konteks yang segar dan akurat untuk pengambilan keputusan AI atau inferensi model. Shift left Dalam dunia pemrosesan data, "pindah kiri" mengacu pada melakukan transformasi dan pengayaan data sesegera mungkin dalam aliran data. API relasional Flink unggul di sini dengan memungkinkan transformasi real-time, dan pengayaan dengan dataset lain. Pengetahuan yang dikombinasikan dengan novelty Secara tradisional, SQL telah digunakan untuk kasus penggunaan operasional dan analitis.Flinks SQL mengambil konsep dan semantik yang dipikirkan dengan baik yang dikembangkan untuk Online Transaction Processing (OLTP) dan Online Analytical Processing (OLAP), dan memperluas mereka untuk memenuhi tuntutan aplikasi pengolahan aliran waktu nyata. The relational algebra remains the same Prinsip-prinsip dasar algebra relasional, yang membentuk dasar SQL, sepenuhnya disimpan dalam Flink SQL. Sementara tabel SQL tradisional statis, Flink SQL memperkenalkan konsep tabel dinamis, yang merupakan representasi logis dari aliran data yang berkelanjutan dan tidak terbatas. Tables: Aggregasi (misalnya, ‘COUNT’, ‘SUM’, ‘AVG’) diterapkan ke aliran, memberikan ringkasan real-time data. Aggregations: Flink SQL mendukung berbagai operasi gabungan, memungkinkan untuk menggabungkan data dari berbagai sumber streaming. Ini dapat berkisar dari gabungan internal dan eksternal tradisional hingga gabungan waktu yang lebih khusus. Joins: Setiap pernyataan Flink SQL terus-menerus menghitung hasil dari kueri pada aliran, memungkinkan akses langsung ke data yang sering diminta. Continuous queries (materialized views): New challenges and ideas for stream processing Di sisi lain, menerapkan konsep relasional ini ke dunia dinamis pemrosesan aliran memperkenalkan beberapa pertimbangan baru: Operasi pemrosesan aliran sering perlu mempertahankan "status" - informasi tentang peristiwa masa lalu - untuk melakukan perhitungan mereka. misalnya, agregasi perlu melacak hasilnya yang terakumulasi sebagian, dan join mungkin perlu menyimpan catatan dari satu aliran sambil menunggu catatan yang cocok dari yang lain. Pengembang yang menggunakan Flink SQL (atau Table API) harus mempertimbangkan dengan hati-hati manajemen negara, karena status yang berlebihan dapat mempengaruhi kinerja dan konsumsi sumber daya. Thinking about state: Dalam pemrosesan aliran, peristiwa dapat tiba di luar urutan atau dengan penundaan. Watermark adalah konsep penting dalam Flink SQL yang membantu mengatasi ketidaksesuaian ini dengan memberikan gagasan "keseluruhan" untuk aliran. Watermark mendefinisikan ambang batas setelah Flink mengasumsikan tidak ada lagi peristiwa dengan timestamp yang lebih awal akan tiba, memungkinkan agregasi jendela yang konsisten dan hasil tepat waktu. Watermarks: Flink SQL mencakup sejumlah versi temporal khusus dari operasi stateful, seperti agregasi jendela waktu, dan joins jendela, yang bergantung pada watermark untuk mengetahui kapan hasil mereka siap untuk diterbitkan (dan kapan keadaan yang mereka pegang dapat dibebaskan). Perkembangan terbaru Perkembangan terbaru membuat API relasional ini lebih menarik dari sebelumnya. Flink SQL dan Table API sangat dapat diperluas melalui penggunaan User-Defined Functions (UDF). ini memungkinkan Java atau Python untuk digunakan untuk menerapkan logika kustom yang tidak dapat diungkapkan secara langsung dalam SQL. UDF dapat melakukan perhitungan kompleks, memanfaatkan pustaka pihak ketiga, mengintegrasikan dengan sistem eksternal, atau menerapkan transformasi spesifik domain. UDF adalah rasa baru dari UDF yang baru saja diperkenalkan sebagai bagian dari Flink 2.1. Tidak seperti UDF tradisional, PTF dapat memproses seluruh tabel (stream) dengan cara yang canggih, menggunakan layanan status dan timer yang dikelola Flink. Process Table Functions (PTFs) Menggunakan Flink SQL Operasi bergabung menggambarkan kesamaan dan perbedaan penting dalam API relasional Flink dibandingkan dengan database SQL tradisional. bagian ini menggunakan beberapa contoh praktis untuk mengeksplorasi bagaimana konsep yang disajikan di atas dapat diterapkan pada aplikasi nyata yang menggunakan gabungan. Pertimbangkan, misalnya, bisnis online yang memproses pesanan dan pembayaran, di mana setiap pembayaran terkait dengan referensi kunci asing (orderId) ke satu pesanan. pesanan dan pembayaran adalah topik Kafka Apache, dan kami ingin membuat tema Kafka baru untuk pesanan berbayar yang akan digunakan untuk pemenuhan pesanan. Solusi sederhana yang tampaknya bekerja adalah CREATE TABLE PaidOrders AS (
  SELECT
    o.id AS orderId,
    p.id AS paymentId
  FROM
    Orders o INNER JOIN Payments p ON o.id = p.orderId
);
 Tentu saja, dalam aplikasi nyata kita akan menarik banyak informasi ke dalam output, seperti ID pelanggan, alamat pengiriman mereka, dan ID produk yang dipesan. Dalam pembahasan komunitas Flink, join seperti ini disebut “regular join” (yang berarti kami tidak melakukan sesuatu yang khusus untuk memungkinkan Flink untuk mengeksekusi lebih efisien).Dan ketika dijalankan oleh runtime streaming Flink SQL, joins reguler dapat mengejutkan mahal. Sebenarnya, berdasarkan pengetahuan kami tentang bagaimana perusahaan ini menjalankan bisnisnya, kami mungkin tahu bahwa setiap pesanan akan memiliki paling banyak satu pembayaran yang cocok, sehingga tidak perlu untuk Flink untuk menyimpan pesanan setelah titik di mana pembayaran telah diproses. Satu hal yang dapat kami lakukan untuk membuat bergabung ini lebih murah adalah dengan mengasumsikan bahwa pembayaran akan selalu terjadi dalam waktu dua jam dari pesanan (misalnya): CREATE TABLE PaidOrders AS (
  SELECT
    o.id AS orderId,
    p.id AS paymentId
  FROM
    Orders o INNER JOIN Payments p ON o.id = p.orderId
  WHERE
    p.paymentTime BETWEEN o.orderTime AND o.orderTime + INTERVAL '2' HOUR
);
 Ini akan membatasi berapa lama pesanan disimpan dalam kondisi runtime Flink, tetapi ini bukan pendekatan yang sangat memuaskan.Dari satu sisi, kita lebih suka membebaskan status pesanan segera setelah sesuai dengan pembayaran, dan di sisi lain, beberapa pembayaran mungkin tertunda selama lebih dari 2 jam.Dengan kata lain, ini adalah cara untuk mendapatkan jawaban yang tidak dapat kita percayai, dan menghabiskan lebih dari yang diperlukan untuk sampai ke sana. Sayangnya, pengayaan pesan satu-ke-satu yang idealnya kita ingin lakukan dalam kasus ini tidak dapat secara langsung diungkapkan menggunakan konsep SQL standar. Berikut adalah contoh yang disederhanakan dari apa yang mungkin terlihat: // Function that buffers one object from each side
// of the join to produce exactly one result.
public static class OrderPaymentJoin
  extends ProcessTableFunction<JoinResult> {

  public void eval(
    Context ctx,
    @StateHint(name = "result") JoinResult result,
    @ArgumentHint(SET_SEMANTIC_TABLE) Order order,
    @ArgumentHint(SET_SEMANTIC_TABLE) Payment payment
  ) {

    if (order != null) {
      if (result.orderId != null) {
        // Skip duplicates.
        return;
      } else {
        // Save the order and wait 
        // for the matching payment.
        result.orderId = order.id;
      }
    }

    if (payment != null) {
      if (result.paymentId != null) {
        // Skip duplicates.
        return;
      } else {
        // The order will precede the payment, but
        // we cannot guarantee the order will be
        // processed first. Save the payment
        // and wait for the matching order.
        result.paymentId = payment.id;
      }
    }
  
    if (result.orderId != null && 
        result.paymentId != null) {
      // Send out the final join result
      // and clear the state.
      collect(result);
      ctx.clearState("result");
    }
  }
}
 Dengan PTF ini di tempat, kueri bergabung kami menjadi CREATE TABLE PaidOrders AS (
  SELECT
    orderId,
    paymentId
  FROM
    OrderPaymentJoin(
      order => TABLE(Orders) PARTITION BY order_id,
      payment => TABLE(Payments) PARTITION BY order_id 
    )
);
 Dalam prakteknya, contoh yang disederhanakan ini dapat diperluas untuk melakukan sesuatu tentang kemungkinan mengumpulkan jumlah pesanan yang semakin meningkat (pesanan yang tidak pernah menerima pembayaran). Perkembangan lain yang menarik Native support for ML models FLIP-437 (termasuk dalam Flink 2.0) menambahkan dukungan untuk model pembelajaran mesin sebagai warga kelas satu di Flink SQL. Disaggregated state backend Komunitas Flink sedang mengembangkan pendekatan yang lebih berbasis cloud untuk manajemen negara, yang pada akhirnya akan membuatnya lebih praktis bagi aplikasi untuk menggunakan sejumlah besar negara. Ini tidak akan pernah menghilangkan kebutuhan untuk memikirkan persyaratan negara dari aplikasi streaming Anda, tetapi akan secara signifikan mengubah cara Anda harus melihat kompromi yang terlibat. Untuk pengguna API SQL dan Table Flink, bereksperimen dengan ini hanyalah masalah mengubah konfigurasi runtime Anda. Untuk lebih detail. Dokumentasi Semi-structured types Data semi-struktur menawarkan fleksibilitas yang lebih besar, seperti memungkinkan bidang untuk ditambahkan dari waktu ke waktu, bidang opsional, atau bidang yang jenisnya dapat bervariasi dari baris ke baris.Saat ini, pengguna API relasional Flink harus memilih antara ROW dengan skema ketat dan jenis statis, atau menyimpan data sebagai string JSON. menambahkan tipe VARIANT untuk mendukung data semi-struktur yang dapat disimpan dan diproses secara efisien. KPK-521 Untuk pemahaman yang lebih mendalam Untuk mempelajari lebih lanjut tentang Flink SQL, Kau akan memulai. Video ini berisi pertanyaan yang berterusan yang ada beberapa contoh yang sangat baik, jika Anda ingin menyelam lebih dalam ke dalam topik ini. Dokumentasi tentang Proses Tabel Fungsi Sean Falconer mengungkapkan mengapa . Masa depan agen AI didorong oleh peristiwa Masa depan agen AI didorong oleh peristiwa

This story contains new, firsthand information uncovered by the writer.

Audio ini diproduksi dalam bahasa asli cerita!

Apa yang perlu Anda ketahui tentang pembaruan terbaru untuk Apache Flink SQL dan Table API

About Author

KOMENTAR

HANG TAG

ARTIKEL INI DISAJIKAN PADA

Related Stories

NIGHT (continued)

And In The Open Air

Building an API-Powered Platform

PROMISES FULFILLED.

NIGHT (continued)

And In The Open Air

Building an API-Powered Platform

PROMISES FULFILLED.

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps