Модель программирования Spark для проектирования / преобразования данных в принципе более гибкая и расширяемая, чем U-SQL.
Для небольших, простых проектов вы не заметите разницы, и я бы порекомендовал вам пойти с тем, что вам знакомо.Для сложных проектов и / или проектов, в которых вы ожидаете значительного изменения требований, я настоятельно рекомендую Spark использовать один из поддерживаемых языков: Scala, Java, Python или R, а не SparkSQL.Причиной рекомендации является то, что специфичный для домена язык (Spark) Spark для преобразований данных делает эквивалент генерации кода SQL, что является хитростью, которую все инструменты BI / аналитики / хранилища используют под прикрытием для очень простого управления сложностью.Он позволяет организовывать логику / конфигурацию / настройку и управлять ими способами, которые невозможны или нецелесообразны при работе с SQL, который, мы не должны забывать, является языком старше 40 лет.
Для крайнего примерауровень абстракции, который возможен в Spark, вам может понравиться https://databricks.com/session/the-smart-data-warehouse-goal-based-data-production
Я бы также порекомендовал Spark, если вы имеете дело с грязными / ненадежными данными (JSON в вашем случае), где вы хотели бы иметь оченьконтролируемый / индивидуальный процесс приема пищи.В этом случае вы можете воспользоваться некоторыми идеями в библиотеке spark-records для пуленепробиваемой обработки данных.https://databricks.com/session/bulletproof-jobs-patterns-for-large-scale-spark-processing
Когда речь идет об использовании Spark, особенно для новых пользователей, Databricks обеспечивает наилучшую управляемую среду.В течение многих лет мы работали с клиентами, обрабатывая петабайты очень сложных данных.Люди в нашей команде, которые имеют опыт работы с SQL и не являются разработчиками программного обеспечения, используют SparkSQL в записных книжках Databricks, но они извлекают выгоду из инструментов / абстракций, которые создают для них команды по разработке данных и науке о данных.
Удачи в вашем проекте!