Rumah >pembangunan bahagian belakang >Tutorial Python >Saluran Paip Data untuk berjuta filem dan juta pautan penstriman
Feb 2023: Saya ingin melihat semua skor untuk rancangan tv filem dan tempat untuk menstrimnya pada satu halaman tetapi tidak menemui pengagregat yang menyertakan semua sumber yang berkaitan dengan saya.
Mac 2023: Jadi, saya membina MVP yang meraih markah dengan pantas dan meletakkan tapak itu dalam talian. Ia berfungsi, tetapi lambat (10 saat untuk memaparkan markah).
Okt 2023: Menyedari bahawa menyimpan data di sebelah saya adalah satu keperluan, saya menemui windmill.dev. Ia mengatasi enjin orkestrasi yang serupa dengan mudah - sekurang-kurangnya untuk keperluan saya.
Maju cepat ke hari ini dan selepas 12 bulan mengunyah data berterusan, saya ingin berkongsi bagaimana saluran paip berfungsi secara terperinci. Anda akan belajar cara membina sistem kompleks yang mengambil data daripada pelbagai sumber yang berbeza, menormalkan data dan menggabungkannya ke dalam format yang dioptimumkan untuk pertanyaan.
Ini ialah paparan Runs. Setiap titik mewakili larian aliran. Aliran boleh jadi apa-apa sahaja, contohnya skrip satu langkah mudah:
Blok di tengah mengandungi skrip seperti ini (dipermudahkan):
def main(): return tmdb_extract_daily_dump_data() def tmdb_extract_daily_dump_data(): print("Checking TMDB for latest daily dumps") init_mongodb() daily_dump_infos = get_daily_dump_infos() for daily_dump_info in daily_dump_infos: download_zip_and_store_in_db(daily_dump_info) close_mongodb() return [info.to_mongo() for info in daily_dump_infos] [...]
binatang berikut juga merupakan aliran (ingat, ini hanya salah satu daripada titik hijau):
(imej peleraian lebih tinggi: https://i.imgur.com/LGhTUGG.png)
Jom pecahkan yang ini:
Setiap langkah tersebut adalah lebih atau kurang kompleks dan melibatkan penggunaan proses tak segerak.
Untuk menentukan tajuk yang hendak dipilih seterusnya terdapat dua lorong yang diproses secara selari. Ini adalah satu lagi kawasan di mana Kincir Angin bersinar. Keselarian dan orkestrasi berfungsi dengan sempurna dengan seni binanya.
Dua lorong untuk memilih item seterusnya ialah:
Pertama sekali, tajuk yang tidak mempunyai sebarang data dilampirkan akan dipilih untuk setiap sumber data. Ini bermakna jika saluran paip Metacritic mempunyai filem yang belum dikikis, filem itu akan dipilih seterusnya. Ini memastikan bahawa setiap tajuk diproses sekurang-kurangnya sekali, termasuk yang baharu.
Setelah setiap tajuk telah melampirkan data, talian paip memilih mereka yang mempunyai data paling sedikit terkini.
Berikut ialah contoh larian aliran sedemikian, di sini dengan ralat kerana had kadar telah dicapai:
Kincir angin membolehkan anda menentukan percubaan semula untuk setiap langkah dalam aliran dengan mudah. Dalam kes ini, logiknya adalah untuk mencuba semula tiga kali sekiranya berlaku ralat. Melainkan had kadar telah dicapai (yang biasanya merupakan kod status atau mesej ralat yang berbeza), maka kami berhenti serta-merta.
Perkara di atas berfungsi, tetapi mempunyai isu yang serius: Keluaran terbaharu tidak dikemas kini tepat pada masanya. Ia boleh mengambil masa berminggu-minggu atau bahkan berbulan-bulan sehingga setiap aspek data berjaya diambil. Sebagai contoh, boleh berlaku bahawa filem mempunyai skor IMDb baru-baru ini, tetapi skor lain sudah lapuk dan pautan penstriman hilang sepenuhnya. Terutama untuk skor dan ketersediaan penstriman saya mahu mencapai ketepatan yang lebih baik.
Untuk menyelesaikan masalah ini, lorong kedua memfokuskan pada strategi keutamaan yang berbeza: Filem/tayangan yang paling popular dan sohor kini dipilih untuk muat semula data lengkap merentas semua sumber data. Saya telah menunjukkan aliran ini sebelum ini, itu yang saya rujuk sebagai binatang tadi.
Tajuk yang dipaparkan lebih kerap pada apl turut mendapat rangsangan keutamaan. Ini bermakna setiap kali filem atau rancangan muncul dalam hasil carian teratas atau apabila paparan butirannya dibuka, ia mungkin akan dimuat semula tidak lama lagi.
Setiap tajuk hanya boleh dimuat semula sekali seminggu menggunakan lorong keutamaan untuk memastikan kami tidak mengambil data yang berkemungkinan tidak berubah dalam masa yang sama.
Anda mungkin bertanya: Adakah mengikis sah? Tindakan merebut data biasanya baik. Perkara yang anda lakukan dengan data memerlukan pertimbangan yang teliti. Sebaik sahaja anda membuat keuntungan daripada perkhidmatan yang menggunakan data yang dikikis, anda mungkin melanggar terma dan syarat mereka. (lihat Landskap Undang-undang Pengikisan Web dan 'Mengikis' Hanya Akses Automatik, dan Semua Orang Melakukannya )
Undang-undang mengikis dan berkaitan adalah baharu dan selalunya belum diuji dan terdapat banyak kawasan kelabu yang sah. Saya berazam untuk memetik setiap sumber dengan sewajarnya, menghormati had kadar dan mengelakkan permintaan yang tidak perlu untuk meminimumkan kesan ke atas perkhidmatan mereka.
Hakikatnya, data tidak akan digunakan untuk mengaut keuntungan. GoodWatch akan percuma untuk digunakan untuk semua orang selama-lamanya.
Kincir angin menggunakan pekerja untuk mengedarkan pelaksanaan kod merentasi pelbagai proses. Setiap langkah dalam aliran dihantar kepada pekerja, yang menjadikan mereka bebas daripada logik perniagaan sebenar. Hanya apl utama yang mengatur kerja, manakala pekerja hanya menerima data input, kod untuk melaksanakan dan mengembalikan hasilnya.
Ia adalah seni bina cekap yang berskala dengan baik. Pada masa ini, terdapat 12 pekerja membahagikan kerja. Mereka semua dihoskan di Hetzner.
Setiap pekerja mempunyai penggunaan sumber maksimum sebanyak 1 vCPU dan 2 GB RAM. Berikut ialah gambaran keseluruhan:
Kincir Angin menawarkan pengalaman editor seperti IDE dalam penyemak imbas dengan linting, auto-format, pembantu AI dan juga pengeditan kolaboratif (yang terakhir ialah ciri berbayar). Perkara yang terbaik ialah butang ini:
Ia membolehkan saya mengulang dan menguji skrip dengan cepat sebelum menggunakannya. Saya biasanya mengedit dan menguji fail dalam penyemak imbas dan menolaknya ke git apabila saya selesai.
Hanya perkara yang tiada untuk persekitaran pengekodan optimum ialah alat nyahpepijat (titik putus & konteks berubah). Pada masa ini, saya sedang menyahpepijat skrip dalam IDE tempatan saya untuk mengatasi kelemahan ini.
Saya juga!
Pada masa ini GoodWatch memerlukan sekitar 100 GB storan data berterusan:
Setiap hari 6.500 aliran dijalankan melalui enjin orkestrasi Windmill. Ini menghasilkan volum harian sebanyak:
Angka-angka ini pada asasnya berbeza kerana dasar had kadar yang berbeza.
Sekali sehari, data dibersihkan dan digabungkan ke dalam format data akhir. Pada masa ini pangkalan data yang menguasakan kedai aplikasi web GoodWatch:
Bayangkan anda hanya boleh membezakan filem mengikut genrenya, sangat terhad bukan?
Itulah sebabnya saya memulakan projek DNA. Ia membenarkan pengkategorian filem dan rancangan mengikut atribut lain seperti Mood, Elemen Plots, Jenis Watak, Dialog atau Prop Utama .
Berikut ialah 10 teratas semua nilai DNA ke atas semua item:
Ia membenarkan dua perkara:
Contoh:
Akan ada catatan blog khusus tentang DNA dengan lebih banyak butiran pada masa hadapan.
Untuk memahami sepenuhnya cara saluran paip data berfungsi, berikut ialah pecahan perkara yang berlaku untuk setiap sumber data:
Untuk setiap sumber data terdapat aliran ìnit yang menyediakan koleksi MongoDB dengan semua data yang diperlukan. Untuk IMDb, itu hanya imdb_id. Untuk Rotten Tomatoes, tajuk dan tahun keluaran diperlukan. Ini kerana ID tidak diketahui dan kami perlu meneka URL yang betul berdasarkan nama.
Berdasarkan pemilihan keutamaan yang dijelaskan di atas, item dalam koleksi yang disediakan dikemas kini dengan data yang diambil. Setiap sumber data mempunyai koleksi mereka sendiri yang semakin lengkap dari semasa ke semasa.
Terdapat aliran untuk filem, satu untuk rancangan tv dan satu lagi untuk pautan penstriman. Mereka mengumpul semua data yang diperlukan daripada pelbagai koleksi dan menyimpannya dalam jadual Postgres masing-masing, yang kemudiannya disoal oleh aplikasi web.
Berikut ialah petikan aliran dan skrip filem salin:
Sesetengah aliran ini mengambil masa yang lama untuk dilaksanakan, kadangkala lebih lama daripada 6 jam. Ini boleh dioptimumkan dengan membenderakan semua item yang telah dikemas kini dan hanya menyalin item tersebut dan bukannya memproses kumpulan keseluruhan set data. Salah satu daripada banyak item TODO dalam senarai saya ?
Penjadualan adalah semudah mentakrifkan ungkapan cron untuk setiap aliran atau skrip yang perlu dilaksanakan secara automatik:
Berikut ialah petikan semua jadual yang ditakrifkan untuk GoodWatch:
Secara keseluruhan terdapat kira-kira 50 jadual yang ditentukan.
Dengan data yang hebat datang tanggungjawab yang besar. Banyak yang boleh salah. Dan ia berlaku.
Versi awal skrip saya mengambil masa yang lama untuk mengemas kini semua entri dalam koleksi atau jadual. Itu adalah kerana saya menyelitkan setiap item secara individu. Itu menyebabkan banyak overhed dan melambatkan proses dengan ketara.
Pendekatan yang lebih baik adalah dengan mengumpul data untuk dikemukakan dan mengumpulkan pertanyaan pangkalan data. Berikut ialah contoh untuk MongoDB:
def main(): return tmdb_extract_daily_dump_data() def tmdb_extract_daily_dump_data(): print("Checking TMDB for latest daily dumps") init_mongodb() daily_dump_infos = get_daily_dump_infos() for daily_dump_info in daily_dump_infos: download_zip_and_store_in_db(daily_dump_info) close_mongodb() return [info.to_mongo() for info in daily_dump_infos] [...]
Walaupun dengan pemprosesan kelompok, sesetengah skrip menggunakan terlalu banyak ingatan sehingga pekerjanya ranap. Penyelesaiannya adalah dengan memperhalusi saiz kelompok dengan teliti untuk setiap kes penggunaan.
Sesetengah kelompok baik untuk dijalankan dalam langkah 5000, yang lain menyimpan lebih banyak data dalam ingatan dan berjalan lebih baik dengan 500.
Kincir angin mempunyai ciri hebat untuk memerhati memori semasa skrip berjalan:
Kincir angin ialah aset yang hebat dalam mana-mana kit alat pembangun untuk mengautomasikan tugas. Ia telah menjadi penggalak produktiviti yang tidak ternilai bagi saya, membolehkan saya menumpukan pada struktur aliran dan logik perniagaan sambil menyumber luar tugas berat orkestrasi, pengendalian ralat, percubaan semula dan caching.
Mengendalikan volum data yang besar masih mencabar, dan mengoptimumkan saluran paip ialah proses yang berterusan - tetapi saya sangat gembira dengan perkembangan semuanya setakat ini.
Terfikir begitu. Biar saya pautkan beberapa sumber dan kami sudah selesai:
Tahukah anda bahawa GoodWatch ialah sumber terbuka? Anda boleh melihat semua skrip dan definisi aliran dalam repositori ini: https://github.com/alp82/goodwatch-monorepo/tree/main/goodwatch-flows/windmill/f
Beri tahu saya jika anda mempunyai sebarang soalan.
Atas ialah kandungan terperinci Saluran Paip Data untuk berjuta filem dan juta pautan penstriman. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!