Membuat dan Mengonsumsi Webhook Burung
Burung
27 Jan 2022
1 min read
Intisari Utama
Webhook acara waktu nyata Bird memungkinkan pengirim menerima data acara secara instan—tanpa polling, tanpa pekerjaan cron, dan tanpa batasan tingkat yang memusingkan.
Webhook menghilangkan kerumitan pengelolaan jendela waktu, mencegah acara terlewat, dan menangani catatan duplikat.
Ideal untuk otomatisasi hilir: memperbarui daftar, memulai perjalanan, memperkaya dashboard, atau menyinkronkan sistem internal.
Tutorial ini membimbing pengirim dalam membangun jalur pengambilan AWS penuh: penyimpanan S3, pemrosesan Lambda, dan penyeimbang beban aplikasi.
S3 berfungsi sebagai lapisan penyimpanan pusat untuk payload webhook, dengan setiap batch ditulis sebagai file JSON datar.
Fungsi Lambda menangani baik pengambilan (menyimpan batch mentah) dan transformasi (mengonversi JSON menjadi CSV).
Bird mengelompokkan acara—setiap batch webhook menyertakan
x-messagesystems-batch-idunik, memungkinkan pemeriksaan pemutaran ulang dan deduplikasi.Lambda konsumen harus tetap efisien karena Bird mencoba ulang batch jika titik akhir tidak merespons dalam waktu ~10 detik.
AWS ALB direkomendasikan (dibandingkan API Gateway) untuk kesederhanaan, efektivitas biaya, dan penanganan langsung permintaan HTTP POST.
DNS (Route 53 atau penyedia eksternal) dikonfigurasi untuk memetakan nama host yang ramah ke titik akhir ALB.
Setelah pengaturan, Bird mendorong data acara langsung dan andal ke saluran AWS Anda untuk pemrosesan asinkron.
Panduan ini juga mencakup praktik terbaik: izin IAM paling sedikit-privilege, batasan penyimpanan sementara, menghindari pemicu rekursif, dan mengorganisir alur kerja multi-lambda.
Sorotan Q&A
Apa tujuan utama dari real-time event webhooks Bird?
Untuk mendorong data acara langsung ke endpoint pengirim secara real-time, memungkinkan otomatisasi segera tanpa polling atau panggilan API yang dibatasi laju.
Mengapa webhooks lebih baik daripada menarik data melalui API untuk pengirim besar?
Karena penarikan API memerlukan manajemen jendela waktu, risiko celah data atau duplikasi, dan dapat mengenai batas kecepatan—webhooks menghilangkan semua itu dengan mendorong data secara terus menerus.
Apa layanan AWS yang digunakan dalam pipeline pengambilan webhook yang direkomendasikan?
Amazon S3 (penyimpanan), AWS Lambda (pemrosesan), sebuah Application Load Balancer (pendengar HTTP), dan opsional Route 53 (DNS).
Bagaimana Bird mengelompokkan data acara?
Bird mengirimkan beberapa acara secara bersamaan dalam payload, masing-masing diberi ID batch unik (x-messagesystems-batch-id) untuk pelacakan, pengulangan, dan deduplikasi.
Apa yang memicu fungsi Lambda konsumen?
ALB meneruskan permintaan webhook POST yang masuk langsung ke Lambda, yang mengekstrak payload dan menuliskannya ke S3.
Mengapa menyimpan batch webhook mentah di S3 sebelum memprosesnya?
Untuk memastikan pengambilan cepat (<10 detik) sehingga koneksi tidak habis waktu, dan untuk memindahkan pemrosesan yang lebih berat ke pipeline async terpisah.
Apa yang dilakukan fungsi Lambda kedua?
Ini dipicu oleh objek S3 baru, memvalidasi JSON, mengonversinya ke CSV, dan menulis output yang telah diproses ke bucket S3 terpisah.
Mengapa menggunakan S3 bucket terpisah untuk file CSV yang telah diproses?
Untuk menghindari pemicu rekursif (menulis file yang telah diproses kembali ke dalam bucket yang sama akan memicu kembali Lambda tanpa henti).
Apa izin yang diperlukan oleh fungsi Lambda?
Lambda konsumen memerlukan izin S3 PutObject; Lambda pemrosesan memerlukan GetObject untuk bucket sumber dan PutObject untuk bucket tujuan.
Mengapa AWS ALB direkomendasikan dibandingkan API Gateway?
ALB lebih murah, lebih sederhana, dan ideal untuk penerusan HTTPS POST yang straightforward; API Gateway mungkin mengubah format muatan dan meningkatkan kompleksitas.
Bagaimana pengirim mengkonfigurasi webhook di Bird?
Dengan menyediakan endpoint HTTPS (rekaman DNS untuk ALB), memilih subakun, memilih acara, dan menyimpan konfigurasi webhook.
Pilihan hilir apa yang ada untuk menyimpan atau menganalisis data yang telah diproses?
Muat ke dalam basis data (PostgreSQL, DynamoDB, RDS), masukkan ke dalam sistem ETL, atau query langsung dengan alat seperti Athena.
Berikut adalah panduan sederhana untuk membantu pengirim merasa nyaman saat membuat webhook acara Bird dan mengonsumsi data menggunakan infrastruktur di AWS.
Bird’s real-time event webhooks adalah alat yang sangat berharga bagi pengirim untuk memiliki data secara otomatis didorong ke sistem mereka. Ini dapat mendorong otomatisasi hilir seperti memperbarui daftar surat, memicu perjalan surel otomatis, atau mengisi dasbor internal. Meskipun data peristiwa yang sama dapat diakses melalui antarmuka pengguna Bird menggunakan Event Search, atau secara terprogram dengan memanfaatkan Bird Events API, batasan yang ditempatkan pada jumlah catatan yang dikembalikan dalam satu permintaan atau batas laju yang ditempatkan pada ujung API dapat membuat kedua metode ini dianggap terbatas untuk pengirim besar dan canggih.
Webhooks peristiwa real-time memungkinkan pengirim untuk mengkonfigurasi endpoint di mana Bird mengirimkan data, dan data dapat dikonsumsi tanpa harus menjadwalkan pekerjaan cron yang mengambil data. Ada juga pertukaran logistik saat menarik data dibandingkan dengan memiliki data yang didorong kepada Anda, seperti harus mengidentifikasi periode waktu dan parameter apa yang harus digunakan untuk setiap permintaan API. Jika periode waktu tidak teratur, Anda berisiko kehilangan data, dan jika periode waktu tumpang tindih, Anda harus menangani catatan data duplikat. Dengan real-time webhooks, data peristiwa cukup didorong ke endpoint Anda saat tersedia di dalam Bird.
Meskipun manfaat menerima data peristiwa secara real-time untuk mendorong proses otomatisasi hilir mungkin segera dipahami oleh banyak pengirim, proses sebenarnya untuk mengimplementasikan dan mengonsumsi webhooks mungkin menakutkan. Ini bisa berlaku terutama jika Anda tidak terbiasa dengan komponen teknis dalam pembuatan endpoint dan penanganan data secara terprogram. Ada layanan yang tersedia yang akan mengonsumsi data webhook Bird dan ETL ke dalam basis data Anda secara otomatis – sebagai contoh adalah StitchData, yang telah kita blogkan di masa lalu. Namun, jika Anda ingin lebih mengontrol prosesnya, Anda dapat dengan mudah membangun komponen itu sendiri. Berikut ini adalah panduan sederhana untuk membantu pengirim merasa nyaman ketika membuat webhook peristiwa Bird dan mengonsumsi data menggunakan infrastruktur dalam AWS.
Bird’s real-time event webhooks adalah alat yang sangat berharga bagi pengirim untuk memiliki data secara otomatis didorong ke sistem mereka. Ini dapat mendorong otomatisasi hilir seperti memperbarui daftar surat, memicu perjalan surel otomatis, atau mengisi dasbor internal. Meskipun data peristiwa yang sama dapat diakses melalui antarmuka pengguna Bird menggunakan Event Search, atau secara terprogram dengan memanfaatkan Bird Events API, batasan yang ditempatkan pada jumlah catatan yang dikembalikan dalam satu permintaan atau batas laju yang ditempatkan pada ujung API dapat membuat kedua metode ini dianggap terbatas untuk pengirim besar dan canggih.
Webhooks peristiwa real-time memungkinkan pengirim untuk mengkonfigurasi endpoint di mana Bird mengirimkan data, dan data dapat dikonsumsi tanpa harus menjadwalkan pekerjaan cron yang mengambil data. Ada juga pertukaran logistik saat menarik data dibandingkan dengan memiliki data yang didorong kepada Anda, seperti harus mengidentifikasi periode waktu dan parameter apa yang harus digunakan untuk setiap permintaan API. Jika periode waktu tidak teratur, Anda berisiko kehilangan data, dan jika periode waktu tumpang tindih, Anda harus menangani catatan data duplikat. Dengan real-time webhooks, data peristiwa cukup didorong ke endpoint Anda saat tersedia di dalam Bird.
Meskipun manfaat menerima data peristiwa secara real-time untuk mendorong proses otomatisasi hilir mungkin segera dipahami oleh banyak pengirim, proses sebenarnya untuk mengimplementasikan dan mengonsumsi webhooks mungkin menakutkan. Ini bisa berlaku terutama jika Anda tidak terbiasa dengan komponen teknis dalam pembuatan endpoint dan penanganan data secara terprogram. Ada layanan yang tersedia yang akan mengonsumsi data webhook Bird dan ETL ke dalam basis data Anda secara otomatis – sebagai contoh adalah StitchData, yang telah kita blogkan di masa lalu. Namun, jika Anda ingin lebih mengontrol prosesnya, Anda dapat dengan mudah membangun komponen itu sendiri. Berikut ini adalah panduan sederhana untuk membantu pengirim merasa nyaman ketika membuat webhook peristiwa Bird dan mengonsumsi data menggunakan infrastruktur dalam AWS.
Bird’s real-time event webhooks adalah alat yang sangat berharga bagi pengirim untuk memiliki data secara otomatis didorong ke sistem mereka. Ini dapat mendorong otomatisasi hilir seperti memperbarui daftar surat, memicu perjalan surel otomatis, atau mengisi dasbor internal. Meskipun data peristiwa yang sama dapat diakses melalui antarmuka pengguna Bird menggunakan Event Search, atau secara terprogram dengan memanfaatkan Bird Events API, batasan yang ditempatkan pada jumlah catatan yang dikembalikan dalam satu permintaan atau batas laju yang ditempatkan pada ujung API dapat membuat kedua metode ini dianggap terbatas untuk pengirim besar dan canggih.
Webhooks peristiwa real-time memungkinkan pengirim untuk mengkonfigurasi endpoint di mana Bird mengirimkan data, dan data dapat dikonsumsi tanpa harus menjadwalkan pekerjaan cron yang mengambil data. Ada juga pertukaran logistik saat menarik data dibandingkan dengan memiliki data yang didorong kepada Anda, seperti harus mengidentifikasi periode waktu dan parameter apa yang harus digunakan untuk setiap permintaan API. Jika periode waktu tidak teratur, Anda berisiko kehilangan data, dan jika periode waktu tumpang tindih, Anda harus menangani catatan data duplikat. Dengan real-time webhooks, data peristiwa cukup didorong ke endpoint Anda saat tersedia di dalam Bird.
Meskipun manfaat menerima data peristiwa secara real-time untuk mendorong proses otomatisasi hilir mungkin segera dipahami oleh banyak pengirim, proses sebenarnya untuk mengimplementasikan dan mengonsumsi webhooks mungkin menakutkan. Ini bisa berlaku terutama jika Anda tidak terbiasa dengan komponen teknis dalam pembuatan endpoint dan penanganan data secara terprogram. Ada layanan yang tersedia yang akan mengonsumsi data webhook Bird dan ETL ke dalam basis data Anda secara otomatis – sebagai contoh adalah StitchData, yang telah kita blogkan di masa lalu. Namun, jika Anda ingin lebih mengontrol prosesnya, Anda dapat dengan mudah membangun komponen itu sendiri. Berikut ini adalah panduan sederhana untuk membantu pengirim merasa nyaman ketika membuat webhook peristiwa Bird dan mengonsumsi data menggunakan infrastruktur dalam AWS.
Memproses Data Webhook Event
Bergantung pada tujuan penyimpanan data acara Bird, kebutuhan Anda mungkin terpenuhi hanya dengan menyimpan payload JSON sebagai file datar. Anda mungkin juga telah memiliki proses ETL downstream yang mampu mengonsumsi dan memuat data dalam format JSON. Dalam kedua kasus ini, Anda mungkin dapat menggunakan file datar yang dibuat oleh pemrosesan lambda kami yang telah kami buat di atas sebagaimana adanya.
Atau, Anda mungkin perlu mengubah data - seperti mengonversi dari format JSON ke format CSV - atau memuat data langsung ke dalam database. Dalam contoh ini, kami akan membuat fungsi lambda sederhana yang akan mengonversi data webhook dari format JSON asli ke file CSV yang dapat dimuat ke dalam database.
Bergantung pada tujuan penyimpanan data acara Bird, kebutuhan Anda mungkin terpenuhi hanya dengan menyimpan payload JSON sebagai file datar. Anda mungkin juga telah memiliki proses ETL downstream yang mampu mengonsumsi dan memuat data dalam format JSON. Dalam kedua kasus ini, Anda mungkin dapat menggunakan file datar yang dibuat oleh pemrosesan lambda kami yang telah kami buat di atas sebagaimana adanya.
Atau, Anda mungkin perlu mengubah data - seperti mengonversi dari format JSON ke format CSV - atau memuat data langsung ke dalam database. Dalam contoh ini, kami akan membuat fungsi lambda sederhana yang akan mengonversi data webhook dari format JSON asli ke file CSV yang dapat dimuat ke dalam database.
Bergantung pada tujuan penyimpanan data acara Bird, kebutuhan Anda mungkin terpenuhi hanya dengan menyimpan payload JSON sebagai file datar. Anda mungkin juga telah memiliki proses ETL downstream yang mampu mengonsumsi dan memuat data dalam format JSON. Dalam kedua kasus ini, Anda mungkin dapat menggunakan file datar yang dibuat oleh pemrosesan lambda kami yang telah kami buat di atas sebagaimana adanya.
Atau, Anda mungkin perlu mengubah data - seperti mengonversi dari format JSON ke format CSV - atau memuat data langsung ke dalam database. Dalam contoh ini, kami akan membuat fungsi lambda sederhana yang akan mengonversi data webhook dari format JSON asli ke file CSV yang dapat dimuat ke dalam database.
Mengonfigurasi Target Endpoint Webhook
Ketika sebuah acara Bird dibuat, kami ingin data acara tersebut dialirkan secara real-time ke sebuah endpoint di AWS agar kami dapat mengkonsumsi dan menggunakan data tersebut secara programatik. Data tersebut akan dikirim dari Bird ke endpoint target, yang akan meneruskan payload ke sebuah fungsi lambda yang akan memproses dan menyimpan data tersebut di dalam keranjang S3. Diagram tingkat tinggi dari aliran data yang dijelaskan dapat dilihat di bawah ini:
Untuk menerapkan workflow ini, mari kita bangun mereka dalam urutan terbalik dimulai dengan membuat keranjang S3 di mana kita akan menyimpan data acara kita dan kemudian bekerja mundur – menambahkan setiap komponen yang memasukkan ke dalam apa yang telah kita bangun.
Ketika sebuah acara Bird dibuat, kami ingin data acara tersebut dialirkan secara real-time ke sebuah endpoint di AWS agar kami dapat mengkonsumsi dan menggunakan data tersebut secara programatik. Data tersebut akan dikirim dari Bird ke endpoint target, yang akan meneruskan payload ke sebuah fungsi lambda yang akan memproses dan menyimpan data tersebut di dalam keranjang S3. Diagram tingkat tinggi dari aliran data yang dijelaskan dapat dilihat di bawah ini:
Untuk menerapkan workflow ini, mari kita bangun mereka dalam urutan terbalik dimulai dengan membuat keranjang S3 di mana kita akan menyimpan data acara kita dan kemudian bekerja mundur – menambahkan setiap komponen yang memasukkan ke dalam apa yang telah kita bangun.
Ketika sebuah acara Bird dibuat, kami ingin data acara tersebut dialirkan secara real-time ke sebuah endpoint di AWS agar kami dapat mengkonsumsi dan menggunakan data tersebut secara programatik. Data tersebut akan dikirim dari Bird ke endpoint target, yang akan meneruskan payload ke sebuah fungsi lambda yang akan memproses dan menyimpan data tersebut di dalam keranjang S3. Diagram tingkat tinggi dari aliran data yang dijelaskan dapat dilihat di bawah ini:
Untuk menerapkan workflow ini, mari kita bangun mereka dalam urutan terbalik dimulai dengan membuat keranjang S3 di mana kita akan menyimpan data acara kita dan kemudian bekerja mundur – menambahkan setiap komponen yang memasukkan ke dalam apa yang telah kita bangun.
Buat sebuah S3 Bucket untuk Menyimpan Data Webhook
Sebelum membuat load balancer untuk menerima data, atau fungsi lambda kita untuk menyimpan data, kita perlu terlebih dahulu membuat S3 bucket di mana data akan disimpan. Meskipun S3 menyediakan penyimpanan yang sangat baik untuk data webhook, organisasi yang juga menggunakan database PostgreSQL untuk pemrosesan acara harus menerapkan prosedur backup dan restore yang tepat untuk melindungi data terstruktur mereka bersamaan dengan strategi penyimpanan S3 mereka. Untuk melakukan ini, navigasikan ke layanan S3 dalam AWS dan tekan “Create Bucket.” Anda akan diminta untuk menetapkan nama untuk bucket Anda dan menetapkan wilayah – pastikan untuk menggunakan wilayah yang sama dengan ALB dan fungsi lambda Anda. Ketika S3 bucket Anda dibuat, itu akan kosong – jika Anda ingin mengorganisir data di dalam folder, Anda dapat membuat direktori yang dimaksud sekarang, atau direktori akan dibuat ketika fungsi lambda Anda menyimpan file tersebut. Dalam contoh ini, kami menamai S3 bucket kami “bird-webhooks” dan membuat folder bernama “B Event Data” untuk menyimpan data acara kami – Anda akan melihat nama-nama ini dirujuk dalam fungsi lambda kami di bawah ini.
Sebelum membuat load balancer untuk menerima data, atau fungsi lambda kita untuk menyimpan data, kita perlu terlebih dahulu membuat S3 bucket di mana data akan disimpan. Meskipun S3 menyediakan penyimpanan yang sangat baik untuk data webhook, organisasi yang juga menggunakan database PostgreSQL untuk pemrosesan acara harus menerapkan prosedur backup dan restore yang tepat untuk melindungi data terstruktur mereka bersamaan dengan strategi penyimpanan S3 mereka. Untuk melakukan ini, navigasikan ke layanan S3 dalam AWS dan tekan “Create Bucket.” Anda akan diminta untuk menetapkan nama untuk bucket Anda dan menetapkan wilayah – pastikan untuk menggunakan wilayah yang sama dengan ALB dan fungsi lambda Anda. Ketika S3 bucket Anda dibuat, itu akan kosong – jika Anda ingin mengorganisir data di dalam folder, Anda dapat membuat direktori yang dimaksud sekarang, atau direktori akan dibuat ketika fungsi lambda Anda menyimpan file tersebut. Dalam contoh ini, kami menamai S3 bucket kami “bird-webhooks” dan membuat folder bernama “B Event Data” untuk menyimpan data acara kami – Anda akan melihat nama-nama ini dirujuk dalam fungsi lambda kami di bawah ini.
Sebelum membuat load balancer untuk menerima data, atau fungsi lambda kita untuk menyimpan data, kita perlu terlebih dahulu membuat S3 bucket di mana data akan disimpan. Meskipun S3 menyediakan penyimpanan yang sangat baik untuk data webhook, organisasi yang juga menggunakan database PostgreSQL untuk pemrosesan acara harus menerapkan prosedur backup dan restore yang tepat untuk melindungi data terstruktur mereka bersamaan dengan strategi penyimpanan S3 mereka. Untuk melakukan ini, navigasikan ke layanan S3 dalam AWS dan tekan “Create Bucket.” Anda akan diminta untuk menetapkan nama untuk bucket Anda dan menetapkan wilayah – pastikan untuk menggunakan wilayah yang sama dengan ALB dan fungsi lambda Anda. Ketika S3 bucket Anda dibuat, itu akan kosong – jika Anda ingin mengorganisir data di dalam folder, Anda dapat membuat direktori yang dimaksud sekarang, atau direktori akan dibuat ketika fungsi lambda Anda menyimpan file tersebut. Dalam contoh ini, kami menamai S3 bucket kami “bird-webhooks” dan membuat folder bernama “B Event Data” untuk menyimpan data acara kami – Anda akan melihat nama-nama ini dirujuk dalam fungsi lambda kami di bawah ini.
Buat sebuah Fungsi Lambda untuk Mengkonsumsi Data
Pemrosesan dan penyimpanan data sebenarnya akan dilakukan oleh fungsi lambda yang dipanggil oleh aplikasi load balancer (ALB) kami.
Langkah pertama adalah membuat fungsi lambda Anda dengan menavigasi ke layanan Lambda dalam AWS dan mengklik “Create Function.” Anda akan diminta untuk memberikan nama pada fungsi lambda Anda dan memilih bahasa pemrograman untuk menulis fungsi Anda. Untuk contoh ini, kami menggunakan Python sebagai bahasa runtime.
Sekarang kita perlu mengembangkan fungsi lambda kita. Untuk saat ini, mari kita asumsikan bahwa aplikasi load balancer kita telah dikonfigurasi dan meneruskan payload webhook ke fungsi lambda kita – lambda akan menerima payload termasuk header dan body lengkap. Payload diteruskan ke fungsi lambda kita menggunakan objek “event” sebagai kamus. Anda dapat merujuk pada header dan body dari payload secara independen dengan mengakses objek “headers” dan “body” dalam payload. Dalam contoh ini, kami hanya akan membaca header “x-messagesystems-batch-id,” di mana batch ID adalah nilai unik yang dibuat oleh Bird untuk batch webhook, dan menggunakannya sebagai nama file saat menyimpan body sebagai flat-file di S3; namun, Anda mungkin ingin menambahkan fungsionalitas tambahan seperti pemeriksaan autentikasi atau penanganan error, sesuai kebutuhan.
Saat menyimpan payload ke flat-file di S3, kita perlu menentukan nama bucket S3, lokasi, dan nama file dari file tempat data payload akan disimpan. Dalam fungsi lambda contoh kami, kami melakukan ini dalam fungsi “store_batch.” Dalam contoh ini, kita akan menyimpan seluruh batch sebagai satu file, yang membantu memastikan bahwa data dikumpulkan dan disimpan sebelum koneksi HTTP antara Bird dan titik akhir Anda mengalami time out. Meskipun Anda dapat menyesuaikan pengaturan waktu tunggu koneksi pada load balancer Anda, tidak ada jaminan bahwa koneksi tidak akan time out di sisi transmisi (dalam hal ini Bird) atau bahwa koneksi tidak akan dihentikan sebelum fungsi lambda Anda selesai dieksekusi. Praktik terbaik adalah menjaga fungsi konsumen Anda seefisien mungkin dan memesan kegiatan pemrosesan data untuk proses hilir sejauh mungkin – seperti mengubah payload yang diformat JSON-batch menjadi file CSV, atau memuat data event ke dalam database.
Penting untuk dicatat bahwa Anda mungkin perlu memperbarui izin untuk fungsi lambda Anda. Peran eksekusi Anda akan membutuhkan izin PutObject dan GetObject untuk S3. Praktik terbaik adalah menegakkan prinsip hak istimewa paling rendah, jadi saya sarankan mengatur izin ini hanya untuk bucket S3 tempat payload webhook akan disimpan.
Contoh fungsi lambda konsumen kami dapat ditemukan di sini.
Sebagai catatan singkat tentang batch ID: Bird akan batch events menjadi satu payload, di mana setiap batch mungkin berisi 1 hingga 350 atau lebih catatan event. Batch akan diberikan batch ID unik, yang dapat digunakan untuk melihat status batch dengan memanfaatkan Event Webhooks API atau dalam akun Bird Anda dengan mengklik webhook stream dan memilih “Batch Status.” Dalam kasus di mana payload webhook tidak dapat dikirimkan, seperti selama timeout koneksi, Bird akan secara otomatis retry batch menggunakan batch ID yang sama. Ini bisa terjadi ketika fungsi lambda Anda berjalan mendekati waktu perjalanan pulang maksimum 10 detik dan merupakan alasan untuk mengoptimalkan fungsi konsumen untuk mengurangi waktu eksekusi.
Untuk menangani semua kegiatan pemrosesan data, saya sarankan membuat fungsi lambda terpisah yang dieksekusi kapan pun file baru dibuat di bucket S3 – dengan cara ini, pemrosesan data dilakukan secara asinkron ke pengiriman data, dan tidak ada risiko kehilangan data karena koneksi terputus. Saya membahas fungsi pemrosesan lambda di bagian selanjutnya.
Pemrosesan dan penyimpanan data sebenarnya akan dilakukan oleh fungsi lambda yang dipanggil oleh aplikasi load balancer (ALB) kami.
Langkah pertama adalah membuat fungsi lambda Anda dengan menavigasi ke layanan Lambda dalam AWS dan mengklik “Create Function.” Anda akan diminta untuk memberikan nama pada fungsi lambda Anda dan memilih bahasa pemrograman untuk menulis fungsi Anda. Untuk contoh ini, kami menggunakan Python sebagai bahasa runtime.
Sekarang kita perlu mengembangkan fungsi lambda kita. Untuk saat ini, mari kita asumsikan bahwa aplikasi load balancer kita telah dikonfigurasi dan meneruskan payload webhook ke fungsi lambda kita – lambda akan menerima payload termasuk header dan body lengkap. Payload diteruskan ke fungsi lambda kita menggunakan objek “event” sebagai kamus. Anda dapat merujuk pada header dan body dari payload secara independen dengan mengakses objek “headers” dan “body” dalam payload. Dalam contoh ini, kami hanya akan membaca header “x-messagesystems-batch-id,” di mana batch ID adalah nilai unik yang dibuat oleh Bird untuk batch webhook, dan menggunakannya sebagai nama file saat menyimpan body sebagai flat-file di S3; namun, Anda mungkin ingin menambahkan fungsionalitas tambahan seperti pemeriksaan autentikasi atau penanganan error, sesuai kebutuhan.
Saat menyimpan payload ke flat-file di S3, kita perlu menentukan nama bucket S3, lokasi, dan nama file dari file tempat data payload akan disimpan. Dalam fungsi lambda contoh kami, kami melakukan ini dalam fungsi “store_batch.” Dalam contoh ini, kita akan menyimpan seluruh batch sebagai satu file, yang membantu memastikan bahwa data dikumpulkan dan disimpan sebelum koneksi HTTP antara Bird dan titik akhir Anda mengalami time out. Meskipun Anda dapat menyesuaikan pengaturan waktu tunggu koneksi pada load balancer Anda, tidak ada jaminan bahwa koneksi tidak akan time out di sisi transmisi (dalam hal ini Bird) atau bahwa koneksi tidak akan dihentikan sebelum fungsi lambda Anda selesai dieksekusi. Praktik terbaik adalah menjaga fungsi konsumen Anda seefisien mungkin dan memesan kegiatan pemrosesan data untuk proses hilir sejauh mungkin – seperti mengubah payload yang diformat JSON-batch menjadi file CSV, atau memuat data event ke dalam database.
Penting untuk dicatat bahwa Anda mungkin perlu memperbarui izin untuk fungsi lambda Anda. Peran eksekusi Anda akan membutuhkan izin PutObject dan GetObject untuk S3. Praktik terbaik adalah menegakkan prinsip hak istimewa paling rendah, jadi saya sarankan mengatur izin ini hanya untuk bucket S3 tempat payload webhook akan disimpan.
Contoh fungsi lambda konsumen kami dapat ditemukan di sini.
Sebagai catatan singkat tentang batch ID: Bird akan batch events menjadi satu payload, di mana setiap batch mungkin berisi 1 hingga 350 atau lebih catatan event. Batch akan diberikan batch ID unik, yang dapat digunakan untuk melihat status batch dengan memanfaatkan Event Webhooks API atau dalam akun Bird Anda dengan mengklik webhook stream dan memilih “Batch Status.” Dalam kasus di mana payload webhook tidak dapat dikirimkan, seperti selama timeout koneksi, Bird akan secara otomatis retry batch menggunakan batch ID yang sama. Ini bisa terjadi ketika fungsi lambda Anda berjalan mendekati waktu perjalanan pulang maksimum 10 detik dan merupakan alasan untuk mengoptimalkan fungsi konsumen untuk mengurangi waktu eksekusi.
Untuk menangani semua kegiatan pemrosesan data, saya sarankan membuat fungsi lambda terpisah yang dieksekusi kapan pun file baru dibuat di bucket S3 – dengan cara ini, pemrosesan data dilakukan secara asinkron ke pengiriman data, dan tidak ada risiko kehilangan data karena koneksi terputus. Saya membahas fungsi pemrosesan lambda di bagian selanjutnya.
Pemrosesan dan penyimpanan data sebenarnya akan dilakukan oleh fungsi lambda yang dipanggil oleh aplikasi load balancer (ALB) kami.
Langkah pertama adalah membuat fungsi lambda Anda dengan menavigasi ke layanan Lambda dalam AWS dan mengklik “Create Function.” Anda akan diminta untuk memberikan nama pada fungsi lambda Anda dan memilih bahasa pemrograman untuk menulis fungsi Anda. Untuk contoh ini, kami menggunakan Python sebagai bahasa runtime.
Sekarang kita perlu mengembangkan fungsi lambda kita. Untuk saat ini, mari kita asumsikan bahwa aplikasi load balancer kita telah dikonfigurasi dan meneruskan payload webhook ke fungsi lambda kita – lambda akan menerima payload termasuk header dan body lengkap. Payload diteruskan ke fungsi lambda kita menggunakan objek “event” sebagai kamus. Anda dapat merujuk pada header dan body dari payload secara independen dengan mengakses objek “headers” dan “body” dalam payload. Dalam contoh ini, kami hanya akan membaca header “x-messagesystems-batch-id,” di mana batch ID adalah nilai unik yang dibuat oleh Bird untuk batch webhook, dan menggunakannya sebagai nama file saat menyimpan body sebagai flat-file di S3; namun, Anda mungkin ingin menambahkan fungsionalitas tambahan seperti pemeriksaan autentikasi atau penanganan error, sesuai kebutuhan.
Saat menyimpan payload ke flat-file di S3, kita perlu menentukan nama bucket S3, lokasi, dan nama file dari file tempat data payload akan disimpan. Dalam fungsi lambda contoh kami, kami melakukan ini dalam fungsi “store_batch.” Dalam contoh ini, kita akan menyimpan seluruh batch sebagai satu file, yang membantu memastikan bahwa data dikumpulkan dan disimpan sebelum koneksi HTTP antara Bird dan titik akhir Anda mengalami time out. Meskipun Anda dapat menyesuaikan pengaturan waktu tunggu koneksi pada load balancer Anda, tidak ada jaminan bahwa koneksi tidak akan time out di sisi transmisi (dalam hal ini Bird) atau bahwa koneksi tidak akan dihentikan sebelum fungsi lambda Anda selesai dieksekusi. Praktik terbaik adalah menjaga fungsi konsumen Anda seefisien mungkin dan memesan kegiatan pemrosesan data untuk proses hilir sejauh mungkin – seperti mengubah payload yang diformat JSON-batch menjadi file CSV, atau memuat data event ke dalam database.
Penting untuk dicatat bahwa Anda mungkin perlu memperbarui izin untuk fungsi lambda Anda. Peran eksekusi Anda akan membutuhkan izin PutObject dan GetObject untuk S3. Praktik terbaik adalah menegakkan prinsip hak istimewa paling rendah, jadi saya sarankan mengatur izin ini hanya untuk bucket S3 tempat payload webhook akan disimpan.
Contoh fungsi lambda konsumen kami dapat ditemukan di sini.
Sebagai catatan singkat tentang batch ID: Bird akan batch events menjadi satu payload, di mana setiap batch mungkin berisi 1 hingga 350 atau lebih catatan event. Batch akan diberikan batch ID unik, yang dapat digunakan untuk melihat status batch dengan memanfaatkan Event Webhooks API atau dalam akun Bird Anda dengan mengklik webhook stream dan memilih “Batch Status.” Dalam kasus di mana payload webhook tidak dapat dikirimkan, seperti selama timeout koneksi, Bird akan secara otomatis retry batch menggunakan batch ID yang sama. Ini bisa terjadi ketika fungsi lambda Anda berjalan mendekati waktu perjalanan pulang maksimum 10 detik dan merupakan alasan untuk mengoptimalkan fungsi konsumen untuk mengurangi waktu eksekusi.
Untuk menangani semua kegiatan pemrosesan data, saya sarankan membuat fungsi lambda terpisah yang dieksekusi kapan pun file baru dibuat di bucket S3 – dengan cara ini, pemrosesan data dilakukan secara asinkron ke pengiriman data, dan tidak ada risiko kehilangan data karena koneksi terputus. Saya membahas fungsi pemrosesan lambda di bagian selanjutnya.
Buat sebuah Application Load Balancer
Untuk menerima payload webhook, kita perlu menyediakan endpoint untuk mengirim payload tersebut. Kita melakukannya dengan membuat application load balancer di AWS dengan menavigasi ke EC2 > Load Balancers dan mengklik “Create Load Balancer.” Anda akan diminta untuk memilih jenis load balancer yang ingin Anda buat – untuk ini, kita ingin membuat application load balancer. Kita perlu menggunakan application load balancer (ALB) untuk membangun konsumen kita karena event webhooks akan dikirim sebagai permintaan HTTP, dan ALB digunakan untuk pengalihan permintaan HTTP di dalam AWS. Kita bisa menerapkan HTTP Gateway sebagai alternatif; namun, kita menggunakan ALB untuk proyek ini karena lebih ringan dan hemat biaya dibandingkan HTTP Gateway. Penting untuk dicatat bahwa jika Anda memilih untuk menggunakan HTTP Gateway, format acara mungkin berbeda dibandingkan dengan ALB, dan oleh karena itu fungsi lambda Anda perlu menangani objek permintaan tersebut sesuai.
Setelah ALB Anda dibuat, Anda akan diminta untuk memberikan nama untuk ALB Anda dan mengonfigurasi skema dan pengaturan akses/keamanan – karena kita berencana untuk menerima data acara dari sumber eksternal (Bird), kita ingin ALB kita menghadap ke internet. Di bawah “Listeners and routing,” ALB harus mendengarkan HTTPS pada port 443, dan kita ingin membuat grup Target yang menunjuk ke fungsi lambda kita sehingga ALB kita akan meneruskan permintaan masuk ke fungsi lambda consume yang kita buat sebelumnya. Anda juga perlu memastikan bahwa security group memiliki izin untuk menerima lalu lintas melalui port 443.
Untuk menerima payload webhook, kita perlu menyediakan endpoint untuk mengirim payload tersebut. Kita melakukannya dengan membuat application load balancer di AWS dengan menavigasi ke EC2 > Load Balancers dan mengklik “Create Load Balancer.” Anda akan diminta untuk memilih jenis load balancer yang ingin Anda buat – untuk ini, kita ingin membuat application load balancer. Kita perlu menggunakan application load balancer (ALB) untuk membangun konsumen kita karena event webhooks akan dikirim sebagai permintaan HTTP, dan ALB digunakan untuk pengalihan permintaan HTTP di dalam AWS. Kita bisa menerapkan HTTP Gateway sebagai alternatif; namun, kita menggunakan ALB untuk proyek ini karena lebih ringan dan hemat biaya dibandingkan HTTP Gateway. Penting untuk dicatat bahwa jika Anda memilih untuk menggunakan HTTP Gateway, format acara mungkin berbeda dibandingkan dengan ALB, dan oleh karena itu fungsi lambda Anda perlu menangani objek permintaan tersebut sesuai.
Setelah ALB Anda dibuat, Anda akan diminta untuk memberikan nama untuk ALB Anda dan mengonfigurasi skema dan pengaturan akses/keamanan – karena kita berencana untuk menerima data acara dari sumber eksternal (Bird), kita ingin ALB kita menghadap ke internet. Di bawah “Listeners and routing,” ALB harus mendengarkan HTTPS pada port 443, dan kita ingin membuat grup Target yang menunjuk ke fungsi lambda kita sehingga ALB kita akan meneruskan permintaan masuk ke fungsi lambda consume yang kita buat sebelumnya. Anda juga perlu memastikan bahwa security group memiliki izin untuk menerima lalu lintas melalui port 443.
Untuk menerima payload webhook, kita perlu menyediakan endpoint untuk mengirim payload tersebut. Kita melakukannya dengan membuat application load balancer di AWS dengan menavigasi ke EC2 > Load Balancers dan mengklik “Create Load Balancer.” Anda akan diminta untuk memilih jenis load balancer yang ingin Anda buat – untuk ini, kita ingin membuat application load balancer. Kita perlu menggunakan application load balancer (ALB) untuk membangun konsumen kita karena event webhooks akan dikirim sebagai permintaan HTTP, dan ALB digunakan untuk pengalihan permintaan HTTP di dalam AWS. Kita bisa menerapkan HTTP Gateway sebagai alternatif; namun, kita menggunakan ALB untuk proyek ini karena lebih ringan dan hemat biaya dibandingkan HTTP Gateway. Penting untuk dicatat bahwa jika Anda memilih untuk menggunakan HTTP Gateway, format acara mungkin berbeda dibandingkan dengan ALB, dan oleh karena itu fungsi lambda Anda perlu menangani objek permintaan tersebut sesuai.
Setelah ALB Anda dibuat, Anda akan diminta untuk memberikan nama untuk ALB Anda dan mengonfigurasi skema dan pengaturan akses/keamanan – karena kita berencana untuk menerima data acara dari sumber eksternal (Bird), kita ingin ALB kita menghadap ke internet. Di bawah “Listeners and routing,” ALB harus mendengarkan HTTPS pada port 443, dan kita ingin membuat grup Target yang menunjuk ke fungsi lambda kita sehingga ALB kita akan meneruskan permintaan masuk ke fungsi lambda consume yang kita buat sebelumnya. Anda juga perlu memastikan bahwa security group memiliki izin untuk menerima lalu lintas melalui port 443.
Buat Catatan DNS untuk Load Balancer
Untuk memudahkan kita menggunakan ALB kita sebagai endpoint, kita akan membuat catatan A di DNS yang mengarah ke ALB kita. Untuk ini, kita dapat menggunakan layanan AWS Route 53 (atau penyedia DNS Anda saat ini) dan membuat catatan A untuk hostname yang ingin Anda gunakan untuk endpoint Anda (misalnya, spevents.<your_domain>). Saat bekerja dengan DNS dalam skala besar di AWS, perlu diingat bahwa ada batasan DNS yang tidak terdokumentasi yang dapat memengaruhi aplikasi berlalu lintas tinggi, terutama yang menangani banyak lalu lintas keluar seperti sistem pengiriman email. Catatan A harus dikonfigurasi untuk menunjuk ke ALB yang kami buat. Jika Anda menggunakan Route 53 untuk mengelola catatan DNS, Anda dapat merujuk instance ALB secara langsung dengan mengaktifkan “Alias” dan memilih ALB; jika tidak, jika Anda menggunakan penyedia DNS eksternal, Anda harus mengarahkan catatan A ke alamat IP publik dari instance ALB.
Saya merekomendasikan menggunakan alat seperti Postman untuk menguji bahwa semuanya telah dikonfigurasi dengan benar sebelum mengaktifkan Bird webhook Anda. Anda dapat membuat permintaan POST ke endpoint Anda dan memastikan bahwa respons diterima. Jika permintaan POST Anda tidak mengembalikan respons, Anda mungkin perlu memeriksa ulang bahwa ALB Anda mendengarkan pada port yang benar.
Untuk memudahkan kita menggunakan ALB kita sebagai endpoint, kita akan membuat catatan A di DNS yang mengarah ke ALB kita. Untuk ini, kita dapat menggunakan layanan AWS Route 53 (atau penyedia DNS Anda saat ini) dan membuat catatan A untuk hostname yang ingin Anda gunakan untuk endpoint Anda (misalnya, spevents.<your_domain>). Saat bekerja dengan DNS dalam skala besar di AWS, perlu diingat bahwa ada batasan DNS yang tidak terdokumentasi yang dapat memengaruhi aplikasi berlalu lintas tinggi, terutama yang menangani banyak lalu lintas keluar seperti sistem pengiriman email. Catatan A harus dikonfigurasi untuk menunjuk ke ALB yang kami buat. Jika Anda menggunakan Route 53 untuk mengelola catatan DNS, Anda dapat merujuk instance ALB secara langsung dengan mengaktifkan “Alias” dan memilih ALB; jika tidak, jika Anda menggunakan penyedia DNS eksternal, Anda harus mengarahkan catatan A ke alamat IP publik dari instance ALB.
Saya merekomendasikan menggunakan alat seperti Postman untuk menguji bahwa semuanya telah dikonfigurasi dengan benar sebelum mengaktifkan Bird webhook Anda. Anda dapat membuat permintaan POST ke endpoint Anda dan memastikan bahwa respons diterima. Jika permintaan POST Anda tidak mengembalikan respons, Anda mungkin perlu memeriksa ulang bahwa ALB Anda mendengarkan pada port yang benar.
Untuk memudahkan kita menggunakan ALB kita sebagai endpoint, kita akan membuat catatan A di DNS yang mengarah ke ALB kita. Untuk ini, kita dapat menggunakan layanan AWS Route 53 (atau penyedia DNS Anda saat ini) dan membuat catatan A untuk hostname yang ingin Anda gunakan untuk endpoint Anda (misalnya, spevents.<your_domain>). Saat bekerja dengan DNS dalam skala besar di AWS, perlu diingat bahwa ada batasan DNS yang tidak terdokumentasi yang dapat memengaruhi aplikasi berlalu lintas tinggi, terutama yang menangani banyak lalu lintas keluar seperti sistem pengiriman email. Catatan A harus dikonfigurasi untuk menunjuk ke ALB yang kami buat. Jika Anda menggunakan Route 53 untuk mengelola catatan DNS, Anda dapat merujuk instance ALB secara langsung dengan mengaktifkan “Alias” dan memilih ALB; jika tidak, jika Anda menggunakan penyedia DNS eksternal, Anda harus mengarahkan catatan A ke alamat IP publik dari instance ALB.
Saya merekomendasikan menggunakan alat seperti Postman untuk menguji bahwa semuanya telah dikonfigurasi dengan benar sebelum mengaktifkan Bird webhook Anda. Anda dapat membuat permintaan POST ke endpoint Anda dan memastikan bahwa respons diterima. Jika permintaan POST Anda tidak mengembalikan respons, Anda mungkin perlu memeriksa ulang bahwa ALB Anda mendengarkan pada port yang benar.
Buat Bird Webhook
Sekarang kita siap untuk membuat webhook di Bird dan menggunakan hostname yang ditentukan oleh catatan A di atas sebagai titik akhir target kami. Untuk membuat webhook, navigasikan ke bagian Webhooks dalam akun Bird Anda dan klik "Create Webhook." Anda akan diminta untuk memberikan nama untuk webhook Anda dan menyediakan URL target - target haruslah hostname dari catatan A yang Anda buat sebelumnya. Catat bahwa URL target mungkin memerlukan "HTTPS://" untuk disertakan dalam URL.
Setelah selesai, verifikasi subakun yang benar dan acara yang dipilih, dan tekan "Create Webhook" untuk menyimpan konfigurasi Anda. Data acara untuk semua jenis acara yang dipilih sekarang akan mengalir ke URL target kami dan diolah oleh ALB kami untuk pemrosesan lebih lanjut.
Sekarang kita siap untuk membuat webhook di Bird dan menggunakan hostname yang ditentukan oleh catatan A di atas sebagai titik akhir target kami. Untuk membuat webhook, navigasikan ke bagian Webhooks dalam akun Bird Anda dan klik "Create Webhook." Anda akan diminta untuk memberikan nama untuk webhook Anda dan menyediakan URL target - target haruslah hostname dari catatan A yang Anda buat sebelumnya. Catat bahwa URL target mungkin memerlukan "HTTPS://" untuk disertakan dalam URL.
Setelah selesai, verifikasi subakun yang benar dan acara yang dipilih, dan tekan "Create Webhook" untuk menyimpan konfigurasi Anda. Data acara untuk semua jenis acara yang dipilih sekarang akan mengalir ke URL target kami dan diolah oleh ALB kami untuk pemrosesan lebih lanjut.
Sekarang kita siap untuk membuat webhook di Bird dan menggunakan hostname yang ditentukan oleh catatan A di atas sebagai titik akhir target kami. Untuk membuat webhook, navigasikan ke bagian Webhooks dalam akun Bird Anda dan klik "Create Webhook." Anda akan diminta untuk memberikan nama untuk webhook Anda dan menyediakan URL target - target haruslah hostname dari catatan A yang Anda buat sebelumnya. Catat bahwa URL target mungkin memerlukan "HTTPS://" untuk disertakan dalam URL.
Setelah selesai, verifikasi subakun yang benar dan acara yang dipilih, dan tekan "Create Webhook" untuk menyimpan konfigurasi Anda. Data acara untuk semua jenis acara yang dipilih sekarang akan mengalir ke URL target kami dan diolah oleh ALB kami untuk pemrosesan lebih lanjut.
Konfigurasi Lambda untuk Mengeksekusi Ketika Data Baru Disimpan di S3
Sekarang bahwa fungsi lambda kita untuk mengonversi file dari format JSON ke CSV telah dibuat, kita perlu mengonfigurasinya agar dipicu ketika file baru dibuat di bucket S3 kita. Untuk melakukan ini, kita perlu menambahkan pemicu ke fungsi lambda kita dengan membuka fungsi lambda dan mengklik “Add Trigger” di bagian atas halaman. Pilih “S3” dan berikan nama bucket S3 tempat payload webhook mentah disimpan. Anda juga memiliki opsi untuk menentukan awalan file dan/atau akhiran untuk menyaringnya. Setelah pengaturan dikonfigurasi, Anda dapat menambahkan pemicu dengan mengklik “Add” di bagian bawah halaman. Sekarang, fungsi lambda pemrosesan Anda akan dieksekusi setiap kali file baru ditambahkan ke bucket S3 Anda.
Sekarang bahwa fungsi lambda kita untuk mengonversi file dari format JSON ke CSV telah dibuat, kita perlu mengonfigurasinya agar dipicu ketika file baru dibuat di bucket S3 kita. Untuk melakukan ini, kita perlu menambahkan pemicu ke fungsi lambda kita dengan membuka fungsi lambda dan mengklik “Add Trigger” di bagian atas halaman. Pilih “S3” dan berikan nama bucket S3 tempat payload webhook mentah disimpan. Anda juga memiliki opsi untuk menentukan awalan file dan/atau akhiran untuk menyaringnya. Setelah pengaturan dikonfigurasi, Anda dapat menambahkan pemicu dengan mengklik “Add” di bagian bawah halaman. Sekarang, fungsi lambda pemrosesan Anda akan dieksekusi setiap kali file baru ditambahkan ke bucket S3 Anda.
Sekarang bahwa fungsi lambda kita untuk mengonversi file dari format JSON ke CSV telah dibuat, kita perlu mengonfigurasinya agar dipicu ketika file baru dibuat di bucket S3 kita. Untuk melakukan ini, kita perlu menambahkan pemicu ke fungsi lambda kita dengan membuka fungsi lambda dan mengklik “Add Trigger” di bagian atas halaman. Pilih “S3” dan berikan nama bucket S3 tempat payload webhook mentah disimpan. Anda juga memiliki opsi untuk menentukan awalan file dan/atau akhiran untuk menyaringnya. Setelah pengaturan dikonfigurasi, Anda dapat menambahkan pemicu dengan mengklik “Add” di bagian bawah halaman. Sekarang, fungsi lambda pemrosesan Anda akan dieksekusi setiap kali file baru ditambahkan ke bucket S3 Anda.
Memuat Data ke dalam Database
Dalam contoh ini, saya tidak akan membahas secara detail tentang memuat data ke dalam database, tetapi jika Anda telah mengikuti contoh ini, Anda memiliki beberapa opsi:
Muat data langsung ke dalam database Anda dalam fungsi pemrosesan lambda Anda
Konsumsi file CSV Anda menggunakan proses ETL yang sudah ada
Apakah Anda menggunakan layanan database AWS, seperti RDS atau DynamoDB, atau Anda memiliki database PostgreSQL sendiri (atau sejenisnya), Anda dapat terhubung ke layanan database Anda langsung dari fungsi lambda proses Anda. Misalnya, dengan cara yang sama, kita memanggil layanan S3 menggunakan “boto3” dalam fungsi lambda kita, Anda juga dapat menggunakan “boto3” untuk memanggil RDS atau DynamoDB. Layanan AWS Athena juga dapat digunakan untuk membaca file data langsung dari file datar, dan mengakses data menggunakan bahasa kueri yang mirip dengan SQL. Saya merekomendasikan untuk merujuk ke dokumentasi masing-masing untuk layanan yang Anda gunakan untuk informasi lebih lanjut tentang cara terbaik melakukannya dalam lingkungan Anda.
Demikian pula, ada banyak layanan tersedia yang dapat membantu mengonsumsi file CSV dan memuat data ke dalam database. Anda mungkin sudah memiliki proses ETL yang sudah ada yang dapat Anda manfaatkan.
Kami berharap panduan ini bermanfaat – selamat mengirim!
Dalam contoh ini, saya tidak akan membahas secara detail tentang memuat data ke dalam database, tetapi jika Anda telah mengikuti contoh ini, Anda memiliki beberapa opsi:
Muat data langsung ke dalam database Anda dalam fungsi pemrosesan lambda Anda
Konsumsi file CSV Anda menggunakan proses ETL yang sudah ada
Apakah Anda menggunakan layanan database AWS, seperti RDS atau DynamoDB, atau Anda memiliki database PostgreSQL sendiri (atau sejenisnya), Anda dapat terhubung ke layanan database Anda langsung dari fungsi lambda proses Anda. Misalnya, dengan cara yang sama, kita memanggil layanan S3 menggunakan “boto3” dalam fungsi lambda kita, Anda juga dapat menggunakan “boto3” untuk memanggil RDS atau DynamoDB. Layanan AWS Athena juga dapat digunakan untuk membaca file data langsung dari file datar, dan mengakses data menggunakan bahasa kueri yang mirip dengan SQL. Saya merekomendasikan untuk merujuk ke dokumentasi masing-masing untuk layanan yang Anda gunakan untuk informasi lebih lanjut tentang cara terbaik melakukannya dalam lingkungan Anda.
Demikian pula, ada banyak layanan tersedia yang dapat membantu mengonsumsi file CSV dan memuat data ke dalam database. Anda mungkin sudah memiliki proses ETL yang sudah ada yang dapat Anda manfaatkan.
Kami berharap panduan ini bermanfaat – selamat mengirim!
Dalam contoh ini, saya tidak akan membahas secara detail tentang memuat data ke dalam database, tetapi jika Anda telah mengikuti contoh ini, Anda memiliki beberapa opsi:
Muat data langsung ke dalam database Anda dalam fungsi pemrosesan lambda Anda
Konsumsi file CSV Anda menggunakan proses ETL yang sudah ada
Apakah Anda menggunakan layanan database AWS, seperti RDS atau DynamoDB, atau Anda memiliki database PostgreSQL sendiri (atau sejenisnya), Anda dapat terhubung ke layanan database Anda langsung dari fungsi lambda proses Anda. Misalnya, dengan cara yang sama, kita memanggil layanan S3 menggunakan “boto3” dalam fungsi lambda kita, Anda juga dapat menggunakan “boto3” untuk memanggil RDS atau DynamoDB. Layanan AWS Athena juga dapat digunakan untuk membaca file data langsung dari file datar, dan mengakses data menggunakan bahasa kueri yang mirip dengan SQL. Saya merekomendasikan untuk merujuk ke dokumentasi masing-masing untuk layanan yang Anda gunakan untuk informasi lebih lanjut tentang cara terbaik melakukannya dalam lingkungan Anda.
Demikian pula, ada banyak layanan tersedia yang dapat membantu mengonsumsi file CSV dan memuat data ke dalam database. Anda mungkin sudah memiliki proses ETL yang sudah ada yang dapat Anda manfaatkan.
Kami berharap panduan ini bermanfaat – selamat mengirim!
