Data Hype
https://smartdataconf.ru/?ysclid=mpcewp332053876436
Вчера была установочная встреча с данной конференцией, результаты будут в середине июня
🔥3👍2
Forwarded from Yandex Infrastructure
Что вас ждёт в треке Infra на ❤️ ❤️ ❤️ ?
Сегодня подробнее про программу трека Infra. Знакомьтесь со спикерами и выбирайте, о чём хотели бы послушать.
❤️ — я уже зарегистрировался и жду встречу
Сегодня подробнее про программу трека Infra. Знакомьтесь со спикерами и выбирайте, о чём хотели бы послушать.
❤️ — я уже зарегистрировался и жду встречу
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3
«Наследие предков»
Наконец-то добрался до этого поста. Прошу прощения за столь долгое молчание.
За время работы в консалтинге я видел, трогал и писал множество плагинов, «фреймворков» и утилит. Но хочу сразу отметить: далеко не все подобные решения оказываются действительно удобными в эксплуатации.
Типичный пример «наследия»: автогенерация пайплайнов
Один из самых частых примеров, который я встречал в карьере, - автогенерация пайплайнов прогонки данных через системные таблицы.
Суть механики проста:
1. Вы вставляете в специальную таблицу данные - откуда и куда нужно перегнать информацию (через `INSERT`).
2. Airflow регулярно делает
3. На основе данных из таблицы автоматически генерируется DAG (Directed Acyclic Graph).
В чём подвох?
По мере развития хранилища бизнес начинает выдвигать всё более сложные требования. Это неизбежно усложняет пайплайны. А код автогенерации, как правило, писал один разработчик, которому потом и предстояло всё это поддерживать.
Сценарий развития событий часто предсказуем:
- Разработчик уходит.
- Вы становитесь следующим подрядчиком или принимаете проект.
- Документация кривая, код написан «на коленке», без линтеров и соблюдения правил.
- Вы тратите массу времени, чтобы просто разобраться в системе.
- На вас давит начальство: «Почему так долго?!»
Итог: первые разработчики подложили «бомбу с часовым механизмом», последствия которой расхлёбывают следующие команды.
Почему в бигтехах ситуация лучше?
В крупных технологических компаниях подход иной:
- Утилиты разрабатывают целые команды.
- Если инструмент полезен бизнесу, его долго поддерживают.
- Качество кода и документации изначально на высоком уровне.
Рекомендации для небольших команд (2–3 человека)
Если ваша команда невелика, но способна создавать сложные решения, не пытайтесь сразу писать масштабные проекты.
Действуйте поэтапно:
1. Напишите маленький фрагмент системы.
2. Отдайте коллегам на тестирование.
3. Как только этап пройден - отрефакторите код, исправьте баги.
4. Только после этого можно постепенно дорабатывать и улучшать решение.
Главный вывод
DWH (Data Warehouse) - это не «Диснейленд», где можно бесконечно тестировать новые аттракционы. Это сложная система, которая строится и отлаживается годами.
Обращайтесь к проверенным подходам - работы Кимбала и Иннмона уже чётко описывают, как делать правильно и каких ошибок избегать.
Коротко:
Даже если плагин ускоряет работу с данными - это круто. Но если у вас небольшая команда, не стоит параллельно разрабатывать большой проект внутри основной работы над хранилищем. Сосредоточьтесь на надёжности и поддержке.
Наконец-то добрался до этого поста. Прошу прощения за столь долгое молчание.
За время работы в консалтинге я видел, трогал и писал множество плагинов, «фреймворков» и утилит. Но хочу сразу отметить: далеко не все подобные решения оказываются действительно удобными в эксплуатации.
Типичный пример «наследия»: автогенерация пайплайнов
Один из самых частых примеров, который я встречал в карьере, - автогенерация пайплайнов прогонки данных через системные таблицы.
Суть механики проста:
1. Вы вставляете в специальную таблицу данные - откуда и куда нужно перегнать информацию (через `INSERT`).
2. Airflow регулярно делает
heartbeat SELECT к этой таблице.3. На основе данных из таблицы автоматически генерируется DAG (Directed Acyclic Graph).
В чём подвох?
По мере развития хранилища бизнес начинает выдвигать всё более сложные требования. Это неизбежно усложняет пайплайны. А код автогенерации, как правило, писал один разработчик, которому потом и предстояло всё это поддерживать.
Сценарий развития событий часто предсказуем:
- Разработчик уходит.
- Вы становитесь следующим подрядчиком или принимаете проект.
- Документация кривая, код написан «на коленке», без линтеров и соблюдения правил.
- Вы тратите массу времени, чтобы просто разобраться в системе.
- На вас давит начальство: «Почему так долго?!»
Итог: первые разработчики подложили «бомбу с часовым механизмом», последствия которой расхлёбывают следующие команды.
Почему в бигтехах ситуация лучше?
В крупных технологических компаниях подход иной:
- Утилиты разрабатывают целые команды.
- Если инструмент полезен бизнесу, его долго поддерживают.
- Качество кода и документации изначально на высоком уровне.
Рекомендации для небольших команд (2–3 человека)
Если ваша команда невелика, но способна создавать сложные решения, не пытайтесь сразу писать масштабные проекты.
Действуйте поэтапно:
1. Напишите маленький фрагмент системы.
2. Отдайте коллегам на тестирование.
3. Как только этап пройден - отрефакторите код, исправьте баги.
4. Только после этого можно постепенно дорабатывать и улучшать решение.
Главный вывод
DWH (Data Warehouse) - это не «Диснейленд», где можно бесконечно тестировать новые аттракционы. Это сложная система, которая строится и отлаживается годами.
Обращайтесь к проверенным подходам - работы Кимбала и Иннмона уже чётко описывают, как делать правильно и каких ошибок избегать.
Коротко:
Даже если плагин ускоряет работу с данными - это круто. Но если у вас небольшая команда, не стоит параллельно разрабатывать большой проект внутри основной работы над хранилищем. Сосредоточьтесь на надёжности и поддержке.
Факт, измерение и справочник: история одной подмены
Последнее время немного подгорает от того, как в аналитике мешают понятия. Измерение называют справочником, факт — просто цифрой. Пора разобраться раз и навсегда.
Откуда взялись «факт» и «измерение»?
Спойлер: их придумал не Ральф Кимбалл.
В конце 1960‑х корпорация General Mills (да, хлопья для завтрака) вместе с Дартмутским колледжем искала способ анализировать тонны данных о продажах. Тогда и родилась простая идея:
Факт — это то, что мы считаем (штуки, деньги, вес).
Измерение — это то, как мы это считаем (товар, магазин, дата, регион).
В 1970‑х модель подхватили маркетинговые гиганты AC Nielsen и IRI — они делали отчёты для ритейла и поняли, что такая схема идеально ложится на человеческое мышление.
А Кимбалл уже в 90‑х систематизировал всё это, придумал «звёзды», SCD, конформные измерения — и сделал методологию стандартом. Но сами термины старше него на 30 лет.
Почему измерение — это не справочник?
В речи разработчиков эти слова часто меняют местами. И это понятно, но архитектурно неверно.
Почему путают? Потому что 80% измерений загружаются из корпоративных справочников — «Справочник товаров», «Справочник контрагентов». Мы переносим их в DWH и по привычке называем так же.
Но на самом деле:
Справочник живёт в системе-источнике (1С, SAP). Он хранит только актуальное состояние — сегодня переписали, вчерашнего уже нет.
Измерение живёт в DWH. Оно может хранить историю изменений (например, как менялось название отдела или ценовой сегмент товара). В измерении можно строить иерархии и вычисляемые поля.
И главное: измерение может вообще не иметь справочника-источника. Классика — измерение «Дата». В учётной системе его нет, его генерируют искусственно в DWH на годы вперёд. Но аналитик всё равно скажет «подними справочник дней» — и все его поймут.
Как правильно говорить?
В чатах, на созвонах с бизнесом — называйте измерение справочником, это быстро и понятно.
В документации, схемах, архитектурных решениях — разделяйте:
Справочник — это источник (откуда взяли).
Измерение — это модель для аналитики (как организовали).
Когда мы смешиваем эти понятия, мы теряем важные возможности: историчность, иерархии, вычисления. А они — ключевая сила DWH.
Так что давайте помнить: факты и измерения пришли из 60‑х, чтобы упрощать аналитику, а не запутывать. Используйте их правильно, и ваши витрины будут стройными, а отчёты — точными.
Последнее время немного подгорает от того, как в аналитике мешают понятия. Измерение называют справочником, факт — просто цифрой. Пора разобраться раз и навсегда.
Откуда взялись «факт» и «измерение»?
Спойлер: их придумал не Ральф Кимбалл.
В конце 1960‑х корпорация General Mills (да, хлопья для завтрака) вместе с Дартмутским колледжем искала способ анализировать тонны данных о продажах. Тогда и родилась простая идея:
Факт — это то, что мы считаем (штуки, деньги, вес).
Измерение — это то, как мы это считаем (товар, магазин, дата, регион).
В 1970‑х модель подхватили маркетинговые гиганты AC Nielsen и IRI — они делали отчёты для ритейла и поняли, что такая схема идеально ложится на человеческое мышление.
А Кимбалл уже в 90‑х систематизировал всё это, придумал «звёзды», SCD, конформные измерения — и сделал методологию стандартом. Но сами термины старше него на 30 лет.
Почему измерение — это не справочник?
В речи разработчиков эти слова часто меняют местами. И это понятно, но архитектурно неверно.
Почему путают? Потому что 80% измерений загружаются из корпоративных справочников — «Справочник товаров», «Справочник контрагентов». Мы переносим их в DWH и по привычке называем так же.
Но на самом деле:
Справочник живёт в системе-источнике (1С, SAP). Он хранит только актуальное состояние — сегодня переписали, вчерашнего уже нет.
Измерение живёт в DWH. Оно может хранить историю изменений (например, как менялось название отдела или ценовой сегмент товара). В измерении можно строить иерархии и вычисляемые поля.
И главное: измерение может вообще не иметь справочника-источника. Классика — измерение «Дата». В учётной системе его нет, его генерируют искусственно в DWH на годы вперёд. Но аналитик всё равно скажет «подними справочник дней» — и все его поймут.
Как правильно говорить?
В чатах, на созвонах с бизнесом — называйте измерение справочником, это быстро и понятно.
В документации, схемах, архитектурных решениях — разделяйте:
Справочник — это источник (откуда взяли).
Измерение — это модель для аналитики (как организовали).
Когда мы смешиваем эти понятия, мы теряем важные возможности: историчность, иерархии, вычисления. А они — ключевая сила DWH.
Так что давайте помнить: факты и измерения пришли из 60‑х, чтобы упрощать аналитику, а не запутывать. Используйте их правильно, и ваши витрины будут стройными, а отчёты — точными.
🔥3💯2
Как ERP-системы перезапустили историю хранилищ данных
Продолжаем разговор о терминах и архитектуре. В прошлый раз разобрались с фактами и измерениями. Сегодня — про то, как ERP-системы в 90-е едва не похоронили DWH, а потом сами же заставили его вернуться.
90-е: хранилища данных были на пике
В начале — середине 1990-х DWH был настоящим «хот-топиком» — главной темой в корпоративном IT. Компании остро нуждались в единой версии правды для стратегических решений. Билл Инмон, которого называют отцом data warehousing, в 1992 году выпустил свою классическую книгу «Building the Data Warehouse», закрепив определение: «subject oriented, integrated, nonvolatile, time variant collection of data».
Казалось, DWH ждёт блестящее будущее. Но тут пришли они.
ERP-бум и «тюрьма для данных»
Во второй половине 1990-х начался массовый бум внедрения ERP-систем. Три фактора сыграли роль:
Проблема 2000 года (Y2K) — компании в спешке меняли старые системы.
Реинжиниринг бизнес-процессов стал главной стратегией.
Поставщики ERP (SAP, PeopleSoft) наконец-то выкатили зрелые решения.
Руководство компаний поверило: ERP даст не только операционные, но и информационные преимущества. Зачем отдельное хранилище, если ERP уже всё интегрирует?
В результате DWH стал «немодным». Проекты хранилищ замораживались, деньги уходили на ERP. Но очень быстро выяснилась горькая правда: данные в ERP-системах были, а аналитики из них — нет.
В англоязычной литературе даже появился термин «data jail» — «тюрьма для данных». ERP отлично обрабатывала транзакции, но была бесполезна для агрегации и отчётности. Компании потратили миллионы, а своевременных управленческих отчётов так и не получили.
Возвращение DWH
В конце 90-х организации начали лихорадочно интегрировать ERP с хранилищами. И тут обнаружилось, что для поддержки данных из ERP-приложений требуется существенная доработка хранилищ.
Так начался новый этап — «re-emergence of Data Warehousing» (возрождение хранилищ данных). Исследователи даже ввели термин «double learning curve» — «двойная кривая обучения»: компании вынуждены были осваивать и ERP, и DWH друг за другом, чтобы наконец получить обещанные выгоды.
Производители ERP тоже осознали проблему. В 1998 году SAP выпускает SAP Business Warehouse (BW) — собственное решение для DWH, специально заточенное под данные из SAP R/3. Это был модель-ориентированный подход, который упростил построение хранилищ для клиентов SAP.
Что мы вынесли из этой истории
ERP и DWH — не конкуренты, а взаимодополняющие слои. Транзакционные системы должны работать с текущими данными, хранилища — с историческими.
«Интегрированность» ERP — это про процессы, а не про аналитику. Без отдельного хранилища данные остаются запертыми.
История повторяется. Каждый раз, когда появляется новая «серебряная пуля» (ERP, Big Data, AI), возникает соблазн забыть про фундаментальные принципы архитектуры данных. А потом приходится возвращаться.
Так что если кто-то говорит, что DWH не нужен больше и всю аналитику будет выполнять AI прямо из ERP. Просто не слушайте этих людей и все будет у вас хорошо❤️
Продолжаем разговор о терминах и архитектуре. В прошлый раз разобрались с фактами и измерениями. Сегодня — про то, как ERP-системы в 90-е едва не похоронили DWH, а потом сами же заставили его вернуться.
90-е: хранилища данных были на пике
В начале — середине 1990-х DWH был настоящим «хот-топиком» — главной темой в корпоративном IT. Компании остро нуждались в единой версии правды для стратегических решений. Билл Инмон, которого называют отцом data warehousing, в 1992 году выпустил свою классическую книгу «Building the Data Warehouse», закрепив определение: «subject oriented, integrated, nonvolatile, time variant collection of data».
Казалось, DWH ждёт блестящее будущее. Но тут пришли они.
ERP-бум и «тюрьма для данных»
Во второй половине 1990-х начался массовый бум внедрения ERP-систем. Три фактора сыграли роль:
Проблема 2000 года (Y2K) — компании в спешке меняли старые системы.
Реинжиниринг бизнес-процессов стал главной стратегией.
Поставщики ERP (SAP, PeopleSoft) наконец-то выкатили зрелые решения.
Руководство компаний поверило: ERP даст не только операционные, но и информационные преимущества. Зачем отдельное хранилище, если ERP уже всё интегрирует?
В результате DWH стал «немодным». Проекты хранилищ замораживались, деньги уходили на ERP. Но очень быстро выяснилась горькая правда: данные в ERP-системах были, а аналитики из них — нет.
В англоязычной литературе даже появился термин «data jail» — «тюрьма для данных». ERP отлично обрабатывала транзакции, но была бесполезна для агрегации и отчётности. Компании потратили миллионы, а своевременных управленческих отчётов так и не получили.
Возвращение DWH
В конце 90-х организации начали лихорадочно интегрировать ERP с хранилищами. И тут обнаружилось, что для поддержки данных из ERP-приложений требуется существенная доработка хранилищ.
Так начался новый этап — «re-emergence of Data Warehousing» (возрождение хранилищ данных). Исследователи даже ввели термин «double learning curve» — «двойная кривая обучения»: компании вынуждены были осваивать и ERP, и DWH друг за другом, чтобы наконец получить обещанные выгоды.
Производители ERP тоже осознали проблему. В 1998 году SAP выпускает SAP Business Warehouse (BW) — собственное решение для DWH, специально заточенное под данные из SAP R/3. Это был модель-ориентированный подход, который упростил построение хранилищ для клиентов SAP.
Что мы вынесли из этой истории
ERP и DWH — не конкуренты, а взаимодополняющие слои. Транзакционные системы должны работать с текущими данными, хранилища — с историческими.
«Интегрированность» ERP — это про процессы, а не про аналитику. Без отдельного хранилища данные остаются запертыми.
История повторяется. Каждый раз, когда появляется новая «серебряная пуля» (ERP, Big Data, AI), возникает соблазн забыть про фундаментальные принципы архитектуры данных. А потом приходится возвращаться.
Так что если кто-то говорит, что DWH не нужен больше и всю аналитику будет выполнять AI прямо из ERP. Просто не слушайте этих людей и все будет у вас хорошо
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1
1С vs DWH: почему ваше хранилище данных никогда не будет работать нормально
Продолжаем разговор об архитектуре данных. В прошлый раз говорили про ERP и DWH. Сегодня — про российскую реальность, где почти любой проект хранилища данных начинается с фразы: «Ну у нас тут 1С…»
1С как новая реальность
После ухода западных ERP-вендоров 1С стала не просто популярной — она стала основной учётной системой для большинства российских компаний. От маленьких ИП до крупных холдингов — везде стоит 1С. И это наложило серьёзный отпечаток на то, как в России строят DWH.
В отличие от SAP или Oracle, 1С не проектировалась как источник для корпоративной аналитики. Это транзакционная система, которая отлично закрывает учёт, но совершенно не дружит с внешними хранилищами данных. Отсюда — целый букет проблем, с которыми сталкивается каждый DWH-архитектор в России.
Проблема №1: внутренняя кухня 1С
1С назначает SQL-таблицам имена вроде _Document292 или _AccumRg7110. Напрямую писать SQL-запросы к базе 1С — это квест для самых отчаянных. Ты никогда не знаешь, какая таблица за что отвечает, а структура меняется при каждом обновлении конфигурации.
Поэтому прямое подключение к БД 1С — это антипаттерн. Работать с 1С как с источником данных принято только через http- или веб-сервисы, на уровне приложения, а не на уровне базы. Это добавляет лишний слой абстракции и снижает производительность.
Проблема №2: платформенные ограничения
У платформы 1С:Предприятие есть жёсткое ограничение: в одном запросе нельзя одновременно использовать данные из основной базы и внешнего источника.
Что это значит на практике? Вы не можете написать один ETL-пайплайн, который тянет данные из 1С и тут же обогащает их справочниками из другой системы. Приходится делать несколько проходов, кешировать, изворачиваться. Это замедляет разработку и плодит костыли.
Проблема №3: файловый обмен — зло, но все так делают
Самый простой способ выгрузить данные из 1С — в XML, CSV или JSON. И многие компании так и делают.
Проблемы этого подхода:
Нет контроля загрузки — нельзя автоматически отследить, что данные успешно попали в DWH.
Задержки - только что обновлённые в 1С данные попадают в хранилище с опозданием.
Избыточность — чтобы сохранить целостность, приходится выгружать гораздо больше, чем нужно.
Структурный хаос - как только в 1С обновили конфигурацию, формат выгрузки ломается, и DWH перестаёт работать.
Децентрализованный ад - поддержка выгрузки распределена между разными командами, и никто не знает, кто за что отвечает.
Продолжаем разговор об архитектуре данных. В прошлый раз говорили про ERP и DWH. Сегодня — про российскую реальность, где почти любой проект хранилища данных начинается с фразы: «Ну у нас тут 1С…»
1С как новая реальность
После ухода западных ERP-вендоров 1С стала не просто популярной — она стала основной учётной системой для большинства российских компаний. От маленьких ИП до крупных холдингов — везде стоит 1С. И это наложило серьёзный отпечаток на то, как в России строят DWH.
В отличие от SAP или Oracle, 1С не проектировалась как источник для корпоративной аналитики. Это транзакционная система, которая отлично закрывает учёт, но совершенно не дружит с внешними хранилищами данных. Отсюда — целый букет проблем, с которыми сталкивается каждый DWH-архитектор в России.
Проблема №1: внутренняя кухня 1С
1С назначает SQL-таблицам имена вроде _Document292 или _AccumRg7110. Напрямую писать SQL-запросы к базе 1С — это квест для самых отчаянных. Ты никогда не знаешь, какая таблица за что отвечает, а структура меняется при каждом обновлении конфигурации.
Поэтому прямое подключение к БД 1С — это антипаттерн. Работать с 1С как с источником данных принято только через http- или веб-сервисы, на уровне приложения, а не на уровне базы. Это добавляет лишний слой абстракции и снижает производительность.
Проблема №2: платформенные ограничения
У платформы 1С:Предприятие есть жёсткое ограничение: в одном запросе нельзя одновременно использовать данные из основной базы и внешнего источника.
Что это значит на практике? Вы не можете написать один ETL-пайплайн, который тянет данные из 1С и тут же обогащает их справочниками из другой системы. Приходится делать несколько проходов, кешировать, изворачиваться. Это замедляет разработку и плодит костыли.
Проблема №3: файловый обмен — зло, но все так делают
Самый простой способ выгрузить данные из 1С — в XML, CSV или JSON. И многие компании так и делают.
Проблемы этого подхода:
Нет контроля загрузки — нельзя автоматически отследить, что данные успешно попали в DWH.
Задержки - только что обновлённые в 1С данные попадают в хранилище с опозданием.
Избыточность — чтобы сохранить целостность, приходится выгружать гораздо больше, чем нужно.
Структурный хаос - как только в 1С обновили конфигурацию, формат выгрузки ломается, и DWH перестаёт работать.
Децентрализованный ад - поддержка выгрузки распределена между разными командами, и никто не знает, кто за что отвечает.
Проблема №4: разрозненные справочники и «ручная сшивка»
В крупных компаниях — несколько баз 1С: ERP, ЗУП, WMS, управление холдингом. И у каждой — свои справочники, свои правила ведения, свои форматы.
Объединить это в единую версию данных — отдельный подвиг. Без DWH аналитика превращается в «ручную сшивку» Excel-файлов. Отчёты готовятся днями, а единой версии правды нет.
Проблема №5: архитектурные ошибки на старте
Эксперты-интеграторы, работающие на стыке 1С и BI-платформ, выделяют типичные ошибки:
«Пилот» становится «продакшеном» - на тест выделяют минимальные ресурсы, а потом запускают на них же полноценную работу. И железо, которого хватало для одного месяца данных, ломается на истории за 5 лет.
«Всё в одном» - базу, ETL, BI-сервер и приложение ставят на одну машину. Сбой в одном компоненте парализует всю аналитику.
Что в итоге
1С кардинально изменила российский DWH-ландшафт. В отличие от западных стран, где хранилища данных строятся вокруг ERP как одного из многих источников, в России 1С - это и источник, и главная головная боль.
Без DWH с 1С работать невозможно — данные «заперты» внутри системы. Но построить DWH на данных из 1С - это вызов. Требуется:
отдельный слой для извлечения данных (специализированные ETL-инструменты вроде «1С Экстрактор» или Modus ETL);
грамотная архитектура с запасом мощности;
жёсткий контроль версий конфигураций, чтобы внезапное обновление не сломало всё хранилище.
История с 1С и DWH - это классика: транзакционная система и аналитическая система не должны жить в одном теле. И пока мы это не примем, «ручная сшивка» и подгорание от отчётов будут нашими вечными спутниками😵
В крупных компаниях — несколько баз 1С: ERP, ЗУП, WMS, управление холдингом. И у каждой — свои справочники, свои правила ведения, свои форматы.
Объединить это в единую версию данных — отдельный подвиг. Без DWH аналитика превращается в «ручную сшивку» Excel-файлов. Отчёты готовятся днями, а единой версии правды нет.
Проблема №5: архитектурные ошибки на старте
Эксперты-интеграторы, работающие на стыке 1С и BI-платформ, выделяют типичные ошибки:
«Пилот» становится «продакшеном» - на тест выделяют минимальные ресурсы, а потом запускают на них же полноценную работу. И железо, которого хватало для одного месяца данных, ломается на истории за 5 лет.
«Всё в одном» - базу, ETL, BI-сервер и приложение ставят на одну машину. Сбой в одном компоненте парализует всю аналитику.
Что в итоге
1С кардинально изменила российский DWH-ландшафт. В отличие от западных стран, где хранилища данных строятся вокруг ERP как одного из многих источников, в России 1С - это и источник, и главная головная боль.
Без DWH с 1С работать невозможно — данные «заперты» внутри системы. Но построить DWH на данных из 1С - это вызов. Требуется:
отдельный слой для извлечения данных (специализированные ETL-инструменты вроде «1С Экстрактор» или Modus ETL);
грамотная архитектура с запасом мощности;
жёсткий контроль версий конфигураций, чтобы внезапное обновление не сломало всё хранилище.
История с 1С и DWH - это классика: транзакционная система и аналитическая система не должны жить в одном теле. И пока мы это не примем, «ручная сшивка» и подгорание от отчётов будут нашими вечными спутниками
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1