У сучасному технологічному світі, де все розвивається за допомогою даних, робота з великими обсягами інформації стала звичайною справою. Звісно, працювати з такими великими обсягами даних не завжди легко, і витрати на зберігання та обробку можуть бути дуже дорогими як з точки зору часу, так і коштів.
Майже всі, хто працює в цій сфері, використовують Google Analytics, що є чудовим інструментом для глибокого аналізу, але чи насправді ми знаємо, як використовувати дані Google Analytics найбільш оптимальним чином?
Google Analytics пропонує різноманітні варіанти звітності через свій інтерфейс, але виконання глибокого аналізу на BigQuery зазвичай є методом, який віддають перевагу аналітики даних (Data Analyst). Пряме з'єднання з BigQuery можна встановити через Google Analytics, і при бажанні можна передавати дані майже в реальному часі, а також щоденні дані.
Зв'язок BigQuery з Google Analytics
Проте, як ви можете уявити, дані з Google Analytics на потоці з високою щільністю можуть досягати дуже великих розмірів, і їх обробка на Google BigQuery іноді може бути дуже дорогою.
Нещодавно обсяги користувачів і подій на проєкті, над яким я працював, майже подвоїлися. На щастя, ці дані, які я обробляю щодня, не викликають у мене значних проблем, але важливо пам'ятати, як важлива структура таблиць BigQuery, де ми зберігаємо ці дані після їх обробки.
СКОРОТІТЬ ВИТРАТИ: ПАРТИЦІОНУВАННЯ
Тема, про яку я хочу поговорити сьогодні, — це структура PARTITION (партиціонування). Хоча це є однією з основних інформацій у цій сфері, я був справді здивований, що ця тема була так мало відома в минулому.
Як ви знаєте, дані з Google Analytics у нашому прикладі передаються щодня, і кожна подія має параметр "event_date" (дата події). Завдяки цьому полю, ми можемо легко відокремити дані для конкретного дня, який нас цікавить, з переповненої таблиці, що має мільйони рядків.
Наприклад, припустимо, що у нас є таблиця, де ми обробляємо сирі дані, що отримуємо з Google Analytics, і збираємо лише необхідні поля. У цій таблиці є тільки поле "eventdate", і структура таблиці не використовує PARTITION (партиціонування). В іншій таблиці є ще одна таблиця, яка використовує ті ж самі сирі дані, але вона є PARTITION’ed (партиціонованою) з полем "eventdate_parsed" (розібрана дата події).
SELECT
DISTINCT user_pseudo_id FROM `YOUR_PROJECT.analytics_main_table`
WHERE event_name = 'purchase' AND date(event_date) >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
Вартість обробки запиту для таблиці, що не використовує партиціонування.
SELECT
DISTINCT user_pseudo_id FROM `YOUR_PROJECT.new_table`
WHERE event_name = 'purchase' AND event_date_parsed >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)
Вартість обробки запиту для таблиці, що використовує партиціонування.
Припустимо, ми хочемо виконати один і той самий запит на обох цих таблицях: "Знайти унікальні userpsuedoid з подією 'purchase' за останні 7 днів." Коли ми хочемо використати цей самий запит на цих двох різних таблицях, вартість обробки запиту однієї таблиці складає 2.11 GB, а іншої — лише 82.84 MB. Причина цього дуже проста.
У непартиціонованій таблиці ми намагаємося знайти користувачів, чия event_date (дата події) потрапляє в останні 7 днів з 47,694,962 рядків (так, ви правильно прочитали), що в сумі становить 25.54 GB логічних байт, тому ми збільшуємо наші витрати та витрачаємо час, шукаючи серед безлічі непотрібних даних.
Інформація про зберігання сирих даних.
У партиціонованій таблиці ми спочатку виділяємо лише певну кількість даних, чия eventdateparsed (розібрана дата події) потрапляє в останні 7 днів з тієї ж кількості рядків, і потім шукаємо тільки серед цих даних. Отже, ми отримуємо значно швидший і менш витратний запит.
Схема партиціонування.
Джерело: DataSunrise_
Цю систему можна порівняти з пошуком конкретного типу книги в певному розділі дуже добре організованої бібліотеки, та пошуком конкретної книги без жодного поділу серед тисячі інших книг.
Хоча це дуже базова інформація, з різних причин може бути відсутність знань або лінощі, але повірте, це дуже простий процес, є багато організацій, які не використовують цю систему. Я вважаю, що це система, яку обов'язково треба знати та використовувати.
Створіть копію таблиці, з якою ви працюєте в BigQuery, використовуючи партиціонування, і побачите різницю на власні очі. Ось простий запит, за допомогою якого ви зможете зрозуміти, як партиціонувати вашу таблицю.
CREATE TABLE
NEW_TABLE_NAME (DATE_FIELD TIMESTAMP, OTHER_FIELDS_1 STRING, OTHER_FIELDS_2 STRING)
PARTITION BY
DATE_TRUNC("YOUR DATE_FIELD TO BE PARTITIONED", DAY)
AS (
SELECT
DATE_FIELD, OTHER_FIELDS_1
FROM
TABLE_NAME
);
Сподіваюся, це було корисно, побачимося в наступній статті.
Дякую за прочитане.
Перекладено з: Can we reduce Bigquery cost by 25 times? — Bigquery PARTITION STRUCTURE