Комментарии 9
Ворчливо, что значит только в Европе и США? Два десятка регионов, значит, уже не считаются? :))
Эм… Дочитал. А зачем функции?
CSV кидается на GCS и импортируется напрямую, BQ умеет его напрямую с GCS впитывать. Используя партицированные таблицы данные сами разложатся по дням, надо только импорт в режиме Append делать.
А для предвычислений можно функцию на JS написать, и тогда все внутри BQ, промежуточный скрипт не нужен...
Учитывая что тарифицируются только колонки которые трогаются запросом, на стоимость итоговую не должно вроде повлиять. Только что чуть больше стоимость хранения, но зато все данные есть и в любой момент можно больше данных дёрнуть или глубже копнуть срез
Дальше, а чем кидать файл CSV в GCS? Все равно на серваке скрипт вешать, так не лучше ли сразу в BQ кидать? Вместо файла CSV появляется таблица temporary.
Про функции тоже написал, те, которые в BQ — там времени мало дается на исполнение (часто мне гугл писал, что время на исполнение вышло). Я сначала именно этими функциями и пользовался. Только язык выбрал не JS, а Python, т.к. на нем проще работать. Не впечатлило, в общем.
И, кстати, аналогичными функциями на том же самом серваке я теперь еще обращаюсь к апи стороннего сервиса, забираю данные, собираю из них общую таблицу и кладу в BQ точно так же. Этот скрипт уже работает порядка 3х часов. Сомневаюсь, что функциями, встроенными в BQ, это можно сделать. И, кстати, если пользуешься кодом, лежащим на Гугле, токены доступа к сервисам компании тоже гуглу доверяешь? Я бы так не рисковал.
Смотря какие функции, разве надо много времени на обработку одной строки? Функция обработки строки очень даже быстрая.
Мержить можно джойнами в новые таблицы. Но там просто другой подход, когда мы льем сырые данные дельт или когда у нас снапшоты событий.
Подход с предобработкой имеет право на жизнь, просто он переносит сложность в другое место. Где зачастую можно сделать легче.
Я видел громадные запросы там, где предобработка могла снизить стоимость на порядки. И я видел монстров предобработки, генерящие сотни плоских таблиц которые еле в итоге ползали :)
Когда я тестил функции, встроенные в BQ, у меня была несколько иная задача — там требовалось почистить отчет, выгружаемый из 1С, а точнее, восстановить некоторые поля (хз почему, но там не всегда, когда надо, стояли даты оплаты, хотя сумма полной оплаты была прописана. Кроме того, по некоторым специальным контрагентам требовалась еще кое-какая доработка. И, наконец, был такой замечательный кейс с перекодированием клиентов для того, чтобы присвоить им уникальные id и скрыть их персональные данные, и, кроме того, разбить их на специальные классы на основе анализа их названий. В общем, на питоне мне это было сделать проще и быстрее, но за 6 минут такая функция не справлялась.
Ну а дальше просто уже тему развивал достраиванием предобработки.
Кстати, по поводу монстров. В результате своего собственного развития я тоже потом удивлялся, как можно было изначально написать такой тупой код предобработки. Думаю, что еще через какое-то время я снова так подумаю)) Так что… tempora mutantis et nos mutamus in illis
А кроме того, надо не забывать, что в разных компаниях очень разная организация разделения труда. Если, например, программисты 1С или разработчики сайтов не в твоем отделе и перегружены более другими задачами, то приходится изловчиться, чтобы все сделать ювелирно и быстро, не ломая никакие параллельные процессы. Это также накладывает ограничения на выбор методов.
Как вы решаете проблему редактирования и удаления "свежих" данных в BQ таблице?
Пока данные из потокового буфера не будут сохранены в кластере эти строки нельзя редактировать и удалять. Эта задержка может занимать до 90 минут.
А вот та таблица, которая 2 раза в час обновляется (она нужна для рассылки алертов при анализе потока заказов и для отображения графиков текущего состояния потока), эта таблица небольшая (там срез данных только за 28 последних дней, причем далеко не все поля), она не партицирована, и каждый раз я ее полностью перетираю (write_truncate).
Иначе говоря, под более скорострельные задачи создаются более другие таблицы, и с ними нет проблем запаздываний.
Надеюсь, ответил…
Мы для операций обновления/удаления создали отдельные таблички в postgres и шедулером пишем уже из них в GBQ для манипуляций со строками после добавления которых прошло > 90 минут
Кстати, Datastudio очень тормозит на больших данных, так что под нее в любом случае лучше готовить где-то агрегацию под нужные листы отчета. Я это делаю шедулером BQ или в процессе прокачки средствами пандас на питоне.
Сказ о том, как мы BigQuery приручали