Satu perkara yang mengejutkan tentang data BigQuery PyPI

Anda boleh mendapatkan nombor muat turun untuk pakej PyPI (atau projek) daripada set data Google BigQuery. Anda memerlukan akaun Google dan bukti kelayakan, dan Google memberikan 1 TiB kuota percuma setiap bulan.

Setiap bulan, saya mempunyai automasi untuk mengambil nombor muat turun bagi 8,000 pakej paling popular sepanjang 30 hari lalu dan menjadikannya tersedia sebagai fail JSON dan CSV yang lebih mudah diakses di Pakej PyPI Teratas. Data ini digunakan secara meluas untuk penyelidikan dalam bidang akademik dan industri.

Walau bagaimanapun, apabila lebih banyak pakej dan keluaran dimuat naik ke PyPI, dan semakin banyak muat turun dilog, jumlah data yang dibilkan juga meningkat.

Carta ini menunjukkan jumlah data yang dibilkan setiap bulan.

Pada mulanya, saya hanya mengumpul data muat turun untuk 4,000 pakej dan ia diambil untuk dua pertanyaan: muat turun selama 365 hari dan lebih 30 hari. Tetapi setelah masa berlalu, ia mula menggunakan terlalu banyak kuota untuk memuat turun data selama 365 hari.

Jadi saya membuang data 365 hari dan meningkatkan data 30 hari daripada 4,000 kepada 5,000 pakej. Kemudian, saya menyemak jumlah kuota yang digunakan dan dinaikkan daripada 5,000 pakej kepada 8,000 pakej.

Tetapi kemudian saya melebihi kuota bulanan BigQuery sebanyak 1 data pengambilan TiB untuk Julai 2024.

Untuk mengambil data yang hilang dan menyiasat perkara yang berlaku, saya memulakan percubaan percuma Google Cloud selama 90 hari, $300 (€277.46) ?

Inilah yang saya temui!

Penemuan: kos yang lebih tinggi untuk mendapatkan data untuk muat turun dari pip sahaja berbanding daripada semua pemasang

Saya menggunakan klien pypinfo untuk membantu menanyakan BigQuery. Secara lalai, ia hanya mengambil muat turun untuk pip.

Hanya pip

Arahan ini mendapat data muat turun sehari untuk 10 pakej teratas, untuk pip sahaja:

$ pypinfo --limit 10 --days 1 "" project
Served from cache: False
Data processed: 58.21 GiB
Data billed: 58.21 GiB
Estimated cost: <pre class="brush:php;toolbar:false">$ pypinfo --all --limit 10 --days 1 "" project
Served from cache: False
Data processed: 46.63 GiB
Data billed: 46.63 GiB
Estimated cost: <pre class="brush:php;toolbar:false">SELECT
  file.project as project,
  COUNT(*) as download_count,
FROM `bigquery-public-data.pypi.file_downloads`
WHERE timestamp BETWEEN TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -2 DAY) AND TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -1 DAY)
  AND details.installer.name = "pip"
GROUP BY
  project
ORDER BY
  download_count DESC
LIMIT 10

.23 .29

Keputusan:

project	download count
boto3	37,251,744
aiobotocore	16,252,824
urllib3	16,243,278
botocore	15,687,125
requests	13,271,314
s3fs	12,865,055
s3transfer	12,014,278
fsspec	11,982,305
charset-normalizer	11,684,740
certifi	11,639,584
Total	158,892,247

Semua pemasang

Menambah bendera --semua mendapat data muat turun satu hari untuk 10 pakej teratas, untuk semua pemasang:

$ pypinfo --limit 10 --days 1 "" project
Served from cache: False
Data processed: 58.21 GiB
Data billed: 58.21 GiB
Estimated cost: <pre class="brush:php;toolbar:false">$ pypinfo --all --limit 10 --days 1 "" project
Served from cache: False
Data processed: 46.63 GiB
Data billed: 46.63 GiB
Estimated cost: <pre class="brush:php;toolbar:false">SELECT
  file.project as project,
  COUNT(*) as download_count,
FROM `bigquery-public-data.pypi.file_downloads`
WHERE timestamp BETWEEN TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -2 DAY) AND TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -1 DAY)
  AND details.installer.name = "pip"
GROUP BY
  project
ORDER BY
  download_count DESC
LIMIT 10

.23 .29

project	download count
boto3	39,495,624
botocore	17,281,187
urllib3	17,225,121
aiobotocore	16,430,826
requests	14,287,965
s3fs	12,958,516
charset-normalizer	12,781,405
certifi	12,647,098
setuptools	12,608,120
idna	12,510,335
Total	168,226,197

Jadi, kita dapat melihat kos pip sahaja lalai 25% tambahan data diproses dan data dibilkan serta kos tambahan 25% dalam dolar.

Tidak menghairankan, kiraan muat turun sebenar adalah lebih tinggi untuk semua pemasang. Kedudukan telah berubah sedikit, tetapi saya menjangkakan kami masih mendapat lebih kurang pakej yang sama dalam beribu-ribu hasil teratas.

Pertanyaan

Ia menghantar pertanyaan seperti ini kepada BigQuery hanya untuk pip:

SELECT
  file.project as project,
  COUNT(*) as download_count,
FROM `bigquery-public-data.pypi.file_downloads`
WHERE timestamp BETWEEN TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -2 DAY) AND TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -1 DAY)
GROUP BY
  project
ORDER BY
  download_count DESC
LIMIT 10

Dan untuk semua pemasang:

$ pypinfo --all --limit 100 --days 1 "" installer
Served from cache: False
Data processed: 29.49 GiB
Data billed: 29.49 GiB
Estimated cost: <pre class="brush:php;toolbar:false">SELECT
  file.project as project,
  COUNT(*) as download_count,
FROM `bigquery-public-data.pypi.file_downloads`
WHERE timestamp BETWEEN TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -2 DAY) AND TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -1 DAY)
GROUP BY
  project
ORDER BY
  download_count DESC
LIMIT 8000

.15

Pertanyaan ini adalah sama, kecuali lalai mempunyai syarat tambahan AND details.installer.name = "pip". Nampaknya munasabah kosnya lebih tinggi untuk melakukan kerja penapisan tambahan.

Pemasang

Jom lihat pemasang:

installer name	download count
pip	1,121,198,711
uv	117,194,833
requests	29,828,272
poetry	23,009,454
None	8,916,745
bandersnatch	6,171,555
setuptools	1,362,797
Bazel	1,280,271
Browser	1,096,328
Nexus	593,230
Homebrew	510,247
Artifactory	69,063
pdm	62,904
OS	13,108
devpi	9,530
conda	2,272
pex	194
Total	1,311,319,514

pip setakat ini masih paling popular, dan uv yang tidak mengejutkan juga ada di sana, dengan kira-kira 10% muat turun pip.

Yang lain adalah kira-kira 25% atau kurang daripada uv. Banyak daripada mereka adalah perkhidmatan pencerminan yang kami ingin kecualikan sebelum ini.

Saya fikir memandangkan kepentingan uv, dan jangkaan saya bahawa ia akan terus mengambil bahagian yang lebih besar daripada pai, ditambah terutamanya kos tambahan untuk penapisan dengan hanya pip, bermakna kita harus beralih kepada mengambil data untuk semua pemuat turun. Selain itu, yang lain tidak mengambil kira jumlah pai itu.

Penemuan: bilangan pakej tidak menjejaskan kos

Ini adalah kejutan terbesar. Sebelum ini saya telah menambah atau mengurangkan bilangan untuk mencuba dan kekal di bawah kuota. Tetapi ternyata tidak ada bezanya berapa banyak pakej yang anda tanya!

Saya mengambil data untuk hanya satu hari dan semua pemasang untuk had pakej yang berbeza: 1000, 2000, 3000, 4000, 5000, 6000, 7000, 8000. Contoh pertanyaan:

$ pypinfo --limit 10 --days 1 "" project
Served from cache: False
Data processed: 58.21 GiB
Data billed: 58.21 GiB
Estimated cost: <pre class="brush:php;toolbar:false">$ pypinfo --all --limit 10 --days 1 "" project
Served from cache: False
Data processed: 46.63 GiB
Data billed: 46.63 GiB
Estimated cost: <pre class="brush:php;toolbar:false">SELECT
  file.project as project,
  COUNT(*) as download_count,
FROM `bigquery-public-data.pypi.file_downloads`
WHERE timestamp BETWEEN TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -2 DAY) AND TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL -1 DAY)
  AND details.installer.name = "pip"
GROUP BY
  project
ORDER BY
  download_count DESC
LIMIT 10

.23 .29

Hasil: Menariknya, kos adalah sama untuk semua had (1000-8000): $0.31.

Berulang dengan satu hari tetapi menapis untuk pip sahaja:

Hasil: Kos meningkat kepada $0.39 tetapi sekali lagi adalah sama untuk semua had.

Mari kita ulangi dengan semua pemasang, tetapi selama 30 hari, dan kali ini pertanyaan dalam had yang berkurangan, sekiranya kami hanya membayar untuk perubahan tambahan: 8000, 7000, 6000, 5000, 4000, 3000, 2000, 1000:

Hasil: Sekali lagi, kos adalah sama tanpa mengira had pakej: $4.89 setiap pertanyaan.

Baiklah, mari kita ulangi dengan had meningkat dengan kuasa sepuluh, sehingga 1,000,000! Yang terakhir ini mengambil data untuk semua 531,022 pakej pada PyPI:

limit	projects count	estimated cost	bytes billed	bytes processed
1	1	0.20	43,447,746,560	43,447,720,943
10	10	0.20	43,447,746,560	43,447,720,943
100	100	0.20	43,447,746,560	43,447,720,943
1000	1,000	0.20	43,447,746,560	43,447,720,943
8000	8,000	0.20	43,447,746,560	43,447,720,943
10000	10,000	0.20	43,447,746,560	43,447,720,943
100000	100,000	0.20	43,447,746,560	43,447,720,943
1000000	531,022	0.20	43,447,746,560	43,447,720,943

Hasil: Sekali lagi, kos yang sama, sama ada untuk 1 pakej atau 531,022 pakej!

Penemuan: bilangan hari mempengaruhi kos

Tidak mengejutkan. Sebelum ini saya dapati 365 hari terlalu mengambil kuota dan saya boleh meneruskan dengan 30 hari.

Berikut ialah anggaran kos dan bait yang dibilkan (untuk satu pakej, semua pemasang) antara satu hingga 30 hari (f"pypinfo --all --json --indent 0 --days {days} --limit 1 '' projek "), menunjukkan peningkatan secara linear:

Kesimpulan

• Tidak kira berapa banyak pakej yang saya ambil data, saya juga boleh mengambil semua dan menyediakannya kepada semua orang, bergantung pada saiz fail data. Adalah masuk akal untuk tetap menawarkan fail yang lebih kecil dengan 8,000 atau lebih pakej: selalunya anda hanya memerlukan nombor yang besar tetapi boleh diurus.

• Kos lebih mahal untuk menapis hanya muat turun daripada pip, jadi saya telah beralih kepada mengambil data untuk semua pemasang.

• Bilangan hari mempengaruhi kos, jadi saya perlu mengurangkan ini pada masa hadapan untuk kekal dalam kuota. Sebagai contoh, pada satu ketika saya mungkin perlu menukar daripada 30 kepada 25 hari, dan kemudian daripada 25 kepada 20 hari.

Maklumat lanjut daripada penyiasatan, skrip dan fail data boleh didapati di
hugovk/top-pypi-packages#36.

Dan beritahu saya jika anda mengetahui sebarang helah untuk mengurangkan kos!

---

Foto pengepala: "The Balancing Rock, Stonehenge, Near Glen Innes, NSW" oleh Royal Australian Historical Society, tanpa sekatan hak cipta yang diketahui.

Atas ialah kandungan terperinci Satu perkara yang mengejutkan tentang data BigQuery PyPI. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!