Власне ви праві, BigQuery та Snowflake концептуально дуже схожі. Тому більшість переваг описаних для Snowflake будуть актуальними і для BigQuery.
Але тут я акцентую саме на Snowflake і його характеристиках, оскільки це рішення більш популярне ніж BigQuery в плані вакансій.
А популярніше скоріше всього через дві причини: агресивний маркетинг Snowflake та те що його можна підняти не тільки на GCP, а на AWS та Azure
Доволі дискусивне питання. Якщо у інженера бекграунд scala чи java, то впринципі можна. Або якщо інженер дуже хоче саме на скалі писати, функціональщина це штука цікава:)
Але у інших випадках, якщо питання стоїть просто стати Дата Інженером, то python все ж кращий варіант, оскільки проектів на ньому значно більше ніж на скалі чи джаві
Погоджуюсь що необхідні базові знання клаудів, власне деякі згадані у статті, але все дуже залежить від проекту, композиції команди та стеку який там використовується, на деяких проектах знання клауду взагалі не потрібне. А ось Spark або SQL використовуються майже на всіх проектах.
На рахунок Спарку на скалі — для глибшого розуміння Спарку однозначно круто розібратись, але для початківця який хоче у Дата Інженерію може бути і занадто складно і не дуже практично, бо більшість проектів зараз на PySpark, ну і Python сама ходова мова у Даті, тому практичніше почати з цього.
На рахунок оркестратора — погоджуюсь, що потрібно вміти писати на будь якому, але спочатку потрібно розібратися хоча б що це таке та попрактикуватись хоча б в одному з них.
Це весело та захоплююче, чесно:)
Багато сучасних рішень для роботи з даними, які орієнтовані на scale-out, є надбудовами над блоб стореджами. І це не дивно, оскільки вони дешеві та надійні. Фактично блоби це клаудна альтернатива HDFS.