Архитектура хранилищ данных: традиционная и облачная

[@yusman]

Как-то все в кучу, начали про Кимбала, закончили про упокой. Человек который не в теме — ничего из написанного не поймет, а тот кто в теме и так это все это знает.

Облачные хранилища данных обычно могут выполнять сложные аналитические запросы гораздо быстрее, потому что они используют массовую параллельную обработку.

Тут облачные хранилища не причем, они даже скорее проигрывают в производительности и функционале чем МРР DWH развернутые на реальном железе.

Все эти «интеллектуальные» штуки на подобии Panoply решают только одну маленькую проблему — тупо загрузка из внешних источников(как правило рекламных площадок).

Но в целом ( если не обращать внимание на «облачность»)б что бы освежить знания, норм.

[@imnomada]

Основное преимущество облачных хранилищ в том, что можно масштабировать производительность(как вверх, так и вниз). Тоесть вот тут у меня конец месяца и много отчетов\анализа нужно сделать — добавили мощности серверу(платим больше), а все остальное время платим меньше(ну и производительность соответственно меньше). Например в Azure DWH Compute и Storage масштабируються отдельно и можно Compute убирать полностью в нерабочее время, что очень сильно снижает затраты.

[@mkrupenin]

«Как-то все в кучу, начали про Кимбала, закончили про упокой...»
Это точно… Похоже на то, как будто студента попросили сделать доклад по теме хранилищ данных. Помимо «в кучу» ещё хватает либо некорректных либо спорных интерпретаций различных понятий (например, ETL), плюс перевод ещё больше местами путает.
Я бы не рекомендовал статью для тех, кто хочет предметно разобраться в этой теме.

[@I_v_g]

Цельнастоящей статьи — дать вернеуровневый обзор по теме, без подробной детализации.

плюс перевод ещё больше местами путает

Буду признателен, если укажете на ошибки и неточности перевода.

спорных интерпретаций различных понятий (например, ETL)

Насчет описания ETL с Вами соглашусь: данные извлечаются далеко не только из транзакционных БД. Это могут быть всевозможные источники, от текстовых файлов, заканчивая любыми экзотическими решениями. Позволю себе отойти от оригинального текста и исправлю текст.

[@mkrupenin]

IMHO, оригинальная статья — неудачный верхнеуровневый обзор по теме. Как было замечено выше, тот кто не в теме, вряд ли что-то поймёт или поймёт неправильно.

Перевод нет смысла комментировать, т.к. вопросы в основном к оригиналу.

По ETL вопрос не в том, из каких иточников данные извлекаются. Про ETL написано «Данные хранятся во временной промежуточной базе данных.», а про ELT «Промежуточная база данных отсутствует». Можете на примере пояснить, что это за база такая и зачем она?

Если вам интересно, могу другие неудачные интерпретации прокомментировать.

[@I_v_g]

Можете на примере пояснить, что это за база такая и зачем она?

Подозреваю, что под «промежуточной БД» имелся в виду стейджинг, куда сливаются данные из источников в исходном качестве без обработки.

а про ELT «Промежуточная база данных отсутствует»

Популярным кейсом является хранение данных на HDFS, который не требует дизайна схемы. А уже в момент чтения, обозначаем нужную смеху поверх сырых исходных данных.

[@OasisInDesert]

Несмотря на имеющие замечания, почерпнул для себя кое что новое.