Rumah >pembangunan bahagian belakang >Tutorial Python >Saluran Paip Data untuk berjuta filem dan juta pautan penstriman

Saluran Paip Data untuk berjuta filem dan juta pautan penstriman

Patricia Arquette
Patricia Arquetteasal
2024-12-27 15:02:10992semak imbas

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.

Gambar atau tidak berlaku!

A Data Pipeline for illion movies and million streaming links

Ini ialah paparan Runs. Setiap titik mewakili larian aliran. Aliran boleh jadi apa-apa sahaja, contohnya skrip satu langkah mudah:

A Data Pipeline for illion movies and million streaming links

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):

A Data Pipeline for illion movies and million streaming links

(imej peleraian lebih tinggi: https://i.imgur.com/LGhTUGG.png)

Jom pecahkan yang ini:

  1. Dapatkan diutamakan seterusnya filem atau rancangan tv (lihat bahagian seterusnya)
  2. Dapatkan data terkini daripada TMDB
  3. Scrape IMDb, Metacritic dan Rotten Tomato untuk markah semasa
  4. Scrape TV Tropes untuk... tropes
  5. API Huggingface untuk mengumpul data DNA (akan diterangkan di bawah)
  6. Simpan vektor dimensi tinggi untuk data DNA
  7. Simpan data hubungan untuk filem, rancangan dan pautan penstriman

Setiap langkah tersebut adalah lebih atau kurang kompleks dan melibatkan penggunaan proses tak segerak.

Di mana anda bermula? Barisan Keutamaan

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:

Lorong 1: Mengalir untuk setiap sumber data secara berasingan

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:

A Data Pipeline for illion movies and million streaming links

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.

Lorong 2: Aliran Keutamaan untuk setiap filem/tayangan secara berasingan

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.

Adakah anda dibenarkan melakukan ini? Pertimbangan Mengikis

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.

Lagi Kerja? Ya, Tuanku

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:

A Data Pipeline for illion movies and million streaming links

Editor Kincir Angin

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:

A Data Pipeline for illion movies and million streaming links

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.

Nombor. Saya suka Numbers

Saya juga!

Pada masa ini GoodWatch memerlukan sekitar 100 GB storan data berterusan:

  • 15 GB untuk data prapemprosesan mentah (MongoDB)
  • 23 GB untuk data hubungan yang diproses (Postgres)
  • 67 GB untuk data vektor (Postgres)

Setiap hari 6.500 aliran dijalankan melalui enjin orkestrasi Windmill. Ini menghasilkan volum harian sebanyak:

  • 30,000 halaman IMDb
  • 9,000 Halaman TV Tropes
  • 5.000 Halaman Tomato Busuk
  • 1.500 Gesaan muka berpeluk
  • 600 Halaman metakritik

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:

  • 10 juta pautan penstriman
  • 1 juta filem
  • 300k nilai DNA
  • 200k rancangan tv
  • 70k filem/ rancangan dengan DNA

Apakah DNA yang anda terus bercakap tentang?

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:

A Data Pipeline for illion movies and million streaming links

Ia membenarkan dua perkara:

  1. Tapis mengikut nilai DNA (menggunakan data hubungan)
  2. Cari mengikut persamaan (menggunakan data vektor)

Contoh:

  • Mood Melankolik
  • Kisah Serupa seperti Dune: Bahagian Kedua

Akan ada catatan blog khusus tentang DNA dengan lebih banyak butiran pada masa hadapan.

Menyelam Lebih Dalam ke Saluran Paip Data

Untuk memahami sepenuhnya cara saluran paip data berfungsi, berikut ialah pecahan perkara yang berlaku untuk setiap sumber data:

1. Sekali sehari, koleksi MongoDB dikemas kini dengan semua data input yang diperlukan

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.

2. Ambil data secara berterusan dan tuliskannya ke dalam koleksi MongoDB

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.

3. Sekali sehari, pelbagai aliran mengumpul data daripada koleksi MongoDB dan menulisnya ke dalam Postgres

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:

A Data Pipeline for illion movies and million streaming links

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

Penjadualan adalah semudah mentakrifkan ungkapan cron untuk setiap aliran atau skrip yang perlu dilaksanakan secara automatik:

A Data Pipeline for illion movies and million streaming links

Berikut ialah petikan semua jadual yang ditakrifkan untuk GoodWatch:

A Data Pipeline for illion movies and million streaming links

Secara keseluruhan terdapat kira-kira 50 jadual yang ditentukan.

Cabaran

Dengan data yang hebat datang tanggungjawab yang besar. Banyak yang boleh salah. Dan ia berlaku.

Pemprosesan yang sangat lambat

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]

[...]

Skrip kemaruk ingatan

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:

A Data Pipeline for illion movies and million streaming links

Pengambilan Utama

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.

Okay, okay. Cukuplah

Terfikir begitu. Biar saya pautkan beberapa sumber dan kami sudah selesai:

  • GoodWatch
  • Komuniti Perselisihan GoodWatch
  • Kincir angin
  • Komuniti Perselisihan Kincir Angin

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!

Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn