Хоть в загаловке и сказано про "почему не стоит создавать их под каждый запрос", но ответа в целом нет, кроме одного абзаца и то спорного...
Самый главный момент, который вы упустили/опустили - это то, что вставка данных замедляется пропорционально количеству проекций. Так же вы не указали, как именно увеличевается занимаемое место на диске, в чем отличие сегментированных проекций от обычных, что такое супер-проекция и в чем её отличие от обычных, в общем, продолжать можно много, тема очень обширная, а статья совсем уж слабая...
Ответ 200 OK не гарантирует от КХ получения этих данных после. Как и сколько вы выжидаете, что все данные доехали? Или же вы не сталкивались в этой проблемой?
Поясните, каким образом у вас "КХ хорошо работает с сырыми данными", если эти данные находятся в s3, а оптимизатор в КХ оставляет желать лучшего (даже в версии 22.8)?
Использование pl/sql в том же оракле - по факту это тоже ELT. Технология эта вообще не облачная, а используется она очень и очень давно, я бы даже не удивился, если дольше, чем ETL...
Это чуть больше полумиллиона в месяц на прибор, а это значит, что можно сделать команду от 2 до 20 человек в зависимости от квалификации и опыта, включая студентов.
Хоть в загаловке и сказано про "почему не стоит создавать их под каждый запрос", но ответа в целом нет, кроме одного абзаца и то спорного...
Самый главный момент, который вы упустили/опустили - это то, что вставка данных замедляется пропорционально количеству проекций. Так же вы не указали, как именно увеличевается занимаемое место на диске, в чем отличие сегментированных проекций от обычных, что такое супер-проекция и в чем её отличие от обычных, в общем, продолжать можно много, тема очень обширная, а статья совсем уж слабая...
CTRL+D
Проблема не в медленной вертике в режиме eon, проблема в данных, что они лежат в стороне на s3...
Спустя сотню другую дагов вы упретесь в дагпроцессинг и начнутся проблемы.
Вы изобрели blackbox_exporter?
Понятно, спасибо.
Ответ 200 OK не гарантирует от КХ получения этих данных после. Как и сколько вы выжидаете, что все данные доехали? Или же вы не сталкивались в этой проблемой?
Тогда как вы достигаете консистентности сырых данных при загрузке в КХ? Ведь КХ не гарантирует этого...
Поясните, каким образом у вас "КХ хорошо работает с сырыми данными", если эти данные находятся в s3, а оптимизатор в КХ оставляет желать лучшего (даже в версии 22.8)?
Вы извините, но в календаре есть ссылка на подключение с нужной конфой, а оповещения от календаря позволяют подключиться в два клика.
Могу вас увереть, заповедь 7 точно не аксиома, довольно часто бывают нужные вещи прямо в вопросе...
Утрируя: не все знают баш, но haproxy через баш как-то надо ставить и разбираться, почему то или иное не работает.
А для чего пополнять nintendo eshop или playstation store, которые не работают у нас в стране?
ELT решения - это когда трансформация делается на уровне уже сохраненных данных, а Oracle DI - это ETL решение...
Использование pl/sql в том же оракле - по факту это тоже ELT. Технология эта вообще не облачная, а используется она очень и очень давно, я бы даже не удивился, если дольше, чем ETL...
У меня только один вопрос, вот вы сравнили с пирамидой работу экономической системы Китая, но ведь это равноправно и к мировой экономике?
Не понимаю, откуда вы взяли 7Тб сырых данных, но на текущий момент, это чуть более 13Тб BL слоя only
Я без понятия, что у вас за 8 лет опыта, но мои 6 лет говорят, что если разделить это цифры на 5 нод, ничего сверхъестественного в этом не будет.
Не будет больно, дешевле оракла почти на порядок...
Это чуть больше полумиллиона в месяц на прибор, а это значит, что можно сделать команду от 2 до 20 человек в зависимости от квалификации и опыта, включая студентов.