Обработка данных - BigQuery против Data Proc + BigQuery

Question

У нас есть большие объемы (от 10 до 400 миллиардов) необработанных данных в таблицах BigQuery. У нас есть требование обрабатывать эти данные для преобразования и создания данных в форме таблиц звездообразной схемы (вероятно, другого набора данных в большом запросе), к которым затем можно получить доступ с помощью atscale.

Нужны плюсы и минусы между двумя вариантами ниже: 1. Записать комплекс SQL в BigQuery, который считывает исходный набор данных формы данных и затем загружает его в целевой набор данных (используется Atscale). 2. Используйте PySpark или MapReduce с BigQuery соединителями из Dataproc, а затем загрузите данные в BigQuery целевой набор данных.

Сложность наших преобразований заключается в объединении несколько таблиц с разной степенью детализации с использованием аналитических функций для получения необходимой информации и т. д. c. В настоящее время эта логика c реализована в vertica с использованием нескольких временных таблиц для более быстрой обработки, и мы хотим переписать эту логику обработки c в GCP (Big Query или Data Pro c)

Answer 1

Я успешно выбрал вариант 1: Big Query очень способен выполнять очень сложное преобразование с SQL, кроме того, вы также можете запускать их постепенно с помощью декораторов временного диапазона. Обратите внимание, что для передачи данных в BigQuery требуется много времени и ресурсов. При запуске BigQuery SQL данные никогда не покидают BigQuery, и у вас уже есть все необработанные журналы. Поэтому до тех пор, пока ваша проблема может быть решена с помощью серии SQL, я считаю, что это лучший способ для go.

Мы переехали из кластера отчетности Vertica, успешно переписав ETL в прошлом году, с вариантом 1.

Примерно за год go я написал PO C, сравнивающий DataFlow и серию заданий BigQuery SQL, организованных с помощью potens.io рабочего процесса, позволяющего SQL распараллеливать в шкала.

У меня был хороший месяц, чтобы написать DataFlow в Java с 200+ точками данных и сложным преобразованием с ужасной возможностью отладки одновременно. И неделю, чтобы сделать то же самое, используя серию SQL с potens.io , используя облачную функцию для Оконных таблиц и распараллеливание с кластеризацией временных таблиц. Я знаю, что с тех пор в CloudDataFlow было много улучшений, но в то время DataFlow работал нормально только в миллионном масштабе и никогда не завершался при вводе миллиардов записей (основная причина, по которой количество случайных чисел перемешивалось чуть меньше миллиардов записей, причем каждая запись имела более 200 записей колонны). И подход SQL произвел всю необходимую агрегацию за 2 часа для десятка миллиардов. Отладка и простота устранения неполадок с potens.io тоже очень помогли.

Answer 2

И BigQuery, и DataProc могут обрабатывать огромные объемы сложных данных.

Я думаю, что вы должны учитывать два момента:

1. Какое преобразование вы бы сделали нравится делать в ваших данных?

   Оба инструмента могут выполнять сложные преобразования, но вы должны учитывать, что PySpark предоставит вам полную возможность обработки языка программирования, в то время как BigQuery предоставит вам SQL преобразования и некоторые скриптовые структуры. Если только SQL и простые структуры сценариев могут решить вашу проблему, BigQuery - вариант. Если вам нужны сложные сценарии для преобразования ваших данных или если вы думаете, что вам понадобится создать некоторые дополнительные функции, включающие преобразования в будущем, PySpark может быть лучшим вариантом. Справочник сценариев BigQuery здесь
   
   

2. Цены

   BigQuery и DataProc имеют разные системы ценообразования , Если в BigQuery вам нужно заботиться о том, сколько данных вы будете обрабатывать в своих запросах, в DataProc вам нужно заботиться о размере вашего кластера и конфигурации виртуальной машины, сколько времени будет работать ваш кластер и о некоторых других конфигурациях. , Вы можете найти справочную информацию о ценах для BigQuery здесь и для DataProc здесь . Кроме того, вы можете смоделировать цены в калькуляторе Google Cloud Platform

. Я предлагаю вам создать простое ПО C для вашего проекта в обоих инструментах, чтобы узнайте, какой из них имеет для вас наилучшую экономическую выгоду.

Надеюсь, эта информация поможет вам.