Этап 1. Инициализация проекта. Пет проект: DWH

2026-04-21 21:05:39 +03:00
parent 863b58480e
commit 8913ccb25e
5 changed files with 46 additions and 0 deletions
@@ -0,0 +1,9 @@
+Задание 1
+    - запос не будет локальным
+    - гринплам будет делать data motion
+
+Задание 2
+    - distributed by не подходит, тк таблица не будет учавствовать в join
+
+Задание 3
+    - можно добавить event_id и распределять по нему, или же сделать destributed randomly
@@ -0,0 +1,6 @@
+Задание 1
+    - если orders DISTRIBUTED BY user_id, то будет 'Seq Scan on orders' -> 'HashAggregate'. Redistribute Motion(по user_id) пропадет, потому что все уже распределено по user_id;
+
+Задание 2
+    - Это называется Skew.
+    - Чтобы избежать skew, нужно выбрать столбец для распределения с нормальной кардинальностью. Или делать destributed randomly если не нужно join.
@@ -0,0 +1,10 @@
+Задание 1
+    - данные физически находятся в Hive;
+    - писать обратно в Hive нельзя, тк таблица не writable;
+    - не знаю, в теорри это не сказано - думаю будет ошибка. После того как загуглил:
+        1) если в hive добавились новые столбцы, то при чтении все будет отображаться так, как было во время создание внешней таблицы в greenplum, без ошибок;
+        2) если в hive удалась часть столбцов, то возникнет ошибка тк, в greenplum по сути будут лишние столбцы.
+
+Задание 2
+    - данные не копируются в greenplum, а только читаются из s3;
+    - я думаю в момент создания таблицы - быстрее external, тк ничего не копируется фищически, но при чтении должен быть быстрее CREATE TABLE AS SELECT, тк данные физически хранятся на нашем сервере, а не где-то в облаке.
@@ -0,0 +1,17 @@
+Задание 1:
+- Будут собираться все 10млн строк с разных сегментов, а тольок потом сработает LIMIT. Это очень дорого стоит, и медленно тк очень много данных в пустую соединятся в мастер.
+- Я думаю можно к текущему запросу добавить DENSE_RANK по total и написать условие where -тут имя dense_rank- <= 10.
+!!! В теории не сказано про работу order by - пришлось загуглить !!!
+
+Задание 2:
+- PARTITION BY по. region_id, а должен быть по order_id, чтобы работало без задержек, а при текущем варианте запроса будет происходить data motion как я понял, а это лишние вычисления.
+- Тогда надо распределять таблицу по region_id полагаю.
+
+Задание 3:
+- Ответ до подсказки: думаю все будет нормально, данные просто сгруппируются и вставятся, никаких зарежек быть не должно.
+- Ответ после подсказки: greenplum будет пересылать(data motion) user_id между сегментами, чтобы собрать их в группы, а только потом собирать в мастер и инсертить, инсерт уже поидее будет происходить хорошо, тк данные после data motion будут лежать нормально.
+- Orders надо дестрибьютить по user_id, тогда все четко и быстро будет - и group by, и join.
+
+Задание 4:
+- Я хочу увидеть Motion, Broadcast, Gather
+- Что означает Broadcast Motion, Redistribute Motion, Gather Motion? - в душе ни чаю, там вопрос с ответом сразу, взял оттуда: Broadcast Motion - разослать копии каждой строки на все сегменты; Redistribute Motion - перераспределить по новому ключу; Gather Motion - собрать на мастер.