Этап 1. Инициализация проекта. Пет проект: DWH
This commit is contained in:
@@ -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 - собрать на мастер.
|
||||
Reference in New Issue
Block a user