Comments 15
Вы знаете, не дочитал. Описывается какая-то конкретная боль, при этом используются универсальные термины.
Вот мне нужно большое хранилище — допустим, хранить архив ютуба. Большое хранилище? Большое. должно быть надёжным? Должно. Производительным? Разумеется.
Интересует меня в этот момент вопрос СУБШных притоптываний про бизнес-логику? Волнуют меня в этот момент аналитики, программисты и т.д.?
А ведь тоже хранилище.
Вот мне нужно большое хранилище — допустим, хранить архив ютуба. Большое хранилище? Большое. должно быть надёжным? Должно. Производительным? Разумеется.
Интересует меня в этот момент вопрос СУБШных притоптываний про бизнес-логику? Волнуют меня в этот момент аналитики, программисты и т.д.?
А ведь тоже хранилище.
Гм, вроде статья про хранилища данных, а не хранение больших объемов, в том числе видео роликов :)
Википедия нам говорит, что хранилища данных, это:
Храни́лище да́нных (англ. Data Warehouse) — предметно-ориентированная информационная база данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Строится на базе систем управления базами данных и систем поддержки принятия решений.
То бишь да, конкретная боль, конкретно про хранилища данных. Мне вот эта конкретная боль близка, работаем хранилищами и конкретно нас волнуют заказчики, которых не волнуют архитектура, аналитики, программисты и т.д. Волнуют как раз тем, что они выдают возглас «Вперед к светлому будущему КХД», ничего не зная про онное, сколько нервов, ресурсов и времени на поход к светлому будущему затрачивается и каков процент наступления этого самого будущего :)
Википедия нам говорит, что хранилища данных, это:
Храни́лище да́нных (англ. Data Warehouse) — предметно-ориентированная информационная база данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Строится на базе систем управления базами данных и систем поддержки принятия решений.
То бишь да, конкретная боль, конкретно про хранилища данных. Мне вот эта конкретная боль близка, работаем хранилищами и конкретно нас волнуют заказчики, которых не волнуют архитектура, аналитики, программисты и т.д. Волнуют как раз тем, что они выдают возглас «Вперед к светлому будущему КХД», ничего не зная про онное, сколько нервов, ресурсов и времени на поход к светлому будущему затрачивается и каков процент наступления этого самого будущего :)
Хранилище данных — такой же универсальный термин, как, например, администратор :) На «человеческом» языке — это общие термины, в рамках определенных ИТ-контекстов, для тех, кто в теме, вполне конкретные устоявшиеся и даже стандартизированные термины с достаточно конкретным содержанием.
Отличная статья!
А с архитектурой Инмона приходилось работать? Давно интересно пощупать, что за зверь. Сам кимбаллист со стажем :)
А с архитектурой Инмона приходилось работать? Давно интересно пощупать, что за зверь. Сам кимбаллист со стажем :)
Спасибо. Я тоже недавно прочитал Антихрупкость (удивительная книга) и начал пытаться смотреть с этой точки зрения на ИТ
(Талеб даёт) рецепт антихрупкости — использование ассиметрии. Такого решения в статье не вижу. Видимо из-за выбранного определения хрупкости/антихрупкости (ИТ-системы).
Прекрасная статья. Переведено на «бумагу» все мысли которые переодически всплывают в моей голове, при работе над EDW. Эдакий манифест. Весьма годный. Добавил в закладки!
Елена Верещага адски угорела по буквам. Отвечу тоже потоком текта с минимумом абзацев. Текст написан очень хорошо но мне напомнил г-на Белковского. Так, в целом ничего. Если есть 2000-3000 таблиц нужно реинжинирить и разбираться в СУБД, Service Layer и оркестратор точно надо перебирать. Core можно условно «выкинуть» и переписать, Data Mart придется перебирать уже с учетом обратной совместимости. Primary Data Layer большая помойка туда лишь бы сгрузить. Можно сильно не менять. В тексте вы пишете что у вас кернел 20-30 таблиц в коре — это может быть правда, а может и нет, нужно разбираться и анализировать.
Процесс реинжиниринга действительно долгий, а бизнес не такой уж и динамичный раз они могут 2000-3000 таблиц хранить. Если бы бизнес был сильно динамичный то реинжиниринги стали бы давно-нормой. Так уж прям замораживать работу не стоит, но встречь предстоит много, предстоит выдергивать документацию какую можно и общаться со всеми, потому что 2000 таблиц тяжело документировать.
То что 3NF для Core — не знаю, может быть и так. Нужно подумать. Точно нужно денормализовывать Data Mart чтобы снизить нагрузки. И возможно и помойку-Primary Data Layer (скорее всего там уже денормализовано все).
Primary Data Layer работает на Write в основном, Core Read/Write, Data Mart Read. Отсюда примерный дизайн. Работы много. Мы будем сражаться и мы победим.
Процесс реинжиниринга действительно долгий, а бизнес не такой уж и динамичный раз они могут 2000-3000 таблиц хранить. Если бы бизнес был сильно динамичный то реинжиниринги стали бы давно-нормой. Так уж прям замораживать работу не стоит, но встречь предстоит много, предстоит выдергивать документацию какую можно и общаться со всеми, потому что 2000 таблиц тяжело документировать.
То что 3NF для Core — не знаю, может быть и так. Нужно подумать. Точно нужно денормализовывать Data Mart чтобы снизить нагрузки. И возможно и помойку-Primary Data Layer (скорее всего там уже денормализовано все).
Primary Data Layer работает на Write в основном, Core Read/Write, Data Mart Read. Отсюда примерный дизайн. Работы много. Мы будем сражаться и мы победим.
Интересная статья про хранилище данных.Чувствуется рука глубокой проработки)Сам вот еще изучаю бекенд, статья пригодилась для понимания некоторых «нюансов».Как бы после такой статьи у новичков не появилось чувство того, что тут все сложно совсем и не лучше перепрофилироваться в другую отрасль по IT.
ДВХ — это что-то вроде бэкенда обычных бэкендов. В какой-то мере высший пилотаж его построение. Новичок в бэкенде если и будет иметь с ними дело, то лишь как с внешней системой, с которой нужно интегрироваться. Если ДВХ построены по принципам, описанным в статье, то интеграция с ними максимально проста, вплоть до отсутствия необходимости что-то делать, кроме как описать свой бэкенд.
Отличная статья. Напрямую с хранилищами не работал, но в попытках родить модель данных для 15-летней системы, с которой работает с десяток разных команд, участвовал.
Буду периодически перечитывать для вдохновения.
Буду периодически перечитывать для вдохновения.
Посадил дед… хранилище.
Начал читать после статьи про блокировки РКН: первая мысль была о том, что в конце статьи посадили деда.
Sign up to leave a comment.
Антихрупкость архитектуры хранилищ данных