⚡️ Вышел отчет «Отечественные решения Data Lakehouse-круг Громова 2026»
Российский рынок Data Lakehouse перешёл от пилотных проектов к промышленным внедрениям. При этом рынок разделился на два архитектурных подхода, а информационная безопасность стала одним из главных критериев выбора платформы.
В исследование вошли 10 отечественных решений: MWS Data Lakehouse, Платформа Selena, Digital Q.DataFactory, CedrusData Platform, Data Ocean Nova, Tengri Data Platform, Arenadata Hyperwave, VK Data Platform, YTsaurus и Yandex Data Platform.
➡️ Отчёт даст ориентиры:
– чем отличаются интегрированные платформы от унифицированных систем,
– когда важнее гибкость и технологическая свобода, а когда – простота внедрения и сопровождения,
– какие компоненты и архитектурные подходы используют российские Data Lakehouse,
– на что обратить внимание при выборе платформы для корпоративного хранилища данных.
➡️ Особое внимание уделено:
– драйверам перехода на Data Lakehouse – почему технология становится востребованной и какие задачи заказчиков стимулируют её внедрение,
– информационной безопасности – RBAC, сквозному управлению доступом, аудиту и Data Lineage,
– S3-хранилищу, которое фактически становится фундаментом производительности Lakehouse,
– AI/ML и AI-агентам: полноценные агентные возможности на российском рынке пока остаются скорее исключением, чем стандартом.
📌 Исследование основано на сравнении технологических стеков, экспертной оценке решений и анализе практических сценариев их применения. Полный отчёт доступен на сайте центра «Круги Громова» – скачать бесплатно!
Получите актуальную картину российского рынка Data Lakehouse на 2026 год.
Круги Громова | Подписаться и стать частью Data-сообщества ⬅️
💡"Волшебные" требования Нфт, что может пойти не так? И почему....
Сегодня расскажу прекрасную историю "из полей", то что кажется никогда не произойдёт, но потом случается "вдруг".
Вот в уездом городе N.... А точнее в компании N, есть своя история и эта история в том числе отражается в ИТ-ландшафте, это прям как эпохи строительства отражаются в Москве.
И вот в начале 2000-х, память была дорогой, и сразу же возникали требования, что, где и как мы будем хранить, чистить, или вообще записывать на диск. Да, я помню такие требования, что мы согласно ФЗ, храним платёжные транзакции и их пишем на диск, а есть вдруг пожар, то тогда сорян.
И вот где-то с годов 2010 память стала дешевле и все начали хранить больше, разработчики уже не особо и просили требования о ротации логов, и хранилища стали большими.
А где-то с 2015 все резко решили собирать всю информацию о клиенте. Прям помню эти прекрасные постановки, когда бизнес-заказчик говорит "храните всё, потом разберёмся", потом конечно можно не наступить.
И вот 2026 год, и виток работы с подобными требованиями из разряда Нфт сделал поворот истории и замкнулся на том, что
храним слишком много, часть памяти стала для нас дорогой, и надо бы понять, что можно удалить.
И тут возникает момент "как не выплеснуть с водой ребёнка".
✅Что должны хранить по ФЗ, несколько лет?
✅Что сфоткали, потому что это внутренние регламенты и вообще контроль работы сотрудников. И уже не актуально, и можно удалить.
✅А что-то можно проанализировать, сделать выводы, а может даже сжать.
Ответов нет, есть много информации, без структуры, и самое ужасное без привязки к ключевым бизнес-объектам автоматизации.
Где же потерялись?
Да, где-то на требованиях Нфт. Потому что тренд 2020-х, забить на Нфт.
Даже, к сожалению, слышала от аналитиков такое мнение, что это "не наша часть ответственности", #смертельные_грехи_аналитика и это тоже можно понять, особенно в больших компаниях, где всё в контуре проработано, и просто Нфт пишутся копипастом, а аналитик не хочет тут быть техническим писателем и просто собирать со всех некую информацию...
А получаем проблему, которую быстро не решить, а бизнес ежедневно тратить средства на хранение ненужного #капитаночевидность
А вы пишите #Нфт❓
Есть с такими требованиями проблемы❓
Казалось бы, сколько раз уже обсудили, что такое требование, какие они бывают и почему важно начинать с требований, а не с решений.
Но я не перестаю удивляться как круг повторяется.
Из любимого:
1.У нас нет системного анализа и он нам не нужен.
2.Нфт фигня и зачем их писать, пустое.
3.Главное в бизнес-анализе процессы.
4.Микросервисы нас спасут (а теперь ещё ИИ спасёт).
5.Предметная область, что это такое? Всем же итак понятно.
Можете дополнить, то с чем вы столкнулись на этой неделе? 🔽
Поймала себя на мысли, что в живой команде, всё не очень, а где-то точно круто и хорошо.
Если у тебя что-то не так, где-то же есть идеал?)
И когда обсуждаешь проблемы команды, компании, кажется, что где-то есть идеал. И мысль идёт дальше, вот бы его найти. Но вспоминая крутые доклады на конференциях того же озона, где все работали на тайм ту маркет, и зрелые процессы, и я сразу понимаю, что мне скучно будет)))
И вот такой когнитивный диссонанс, хочется думать, что где-то есть недостижымый идеал, в котором не хочется работать 😂
Ключевой момент состоит в том, чтобы понять мы делаем "проект или продукт".
Разницу между продуктом и проектом я описывала в статье, которая до сих пор актуальна.
Очень редко я слышу от руководства, что нам ещё нужно набрать экспертизу, у нас мало проектов было на этом теме. И вот когда уже был большой обзор болей заказчика и мы вырастили внутри себя экспертизу, тогда можно говорить - мы делаем продукт.
Да, есть тиражирование, есть своё место на рынке, и сбор сразу нескольких болей заказчика, а в какой-то момент уже экспертиза выше, чем у самого заказчика.
Мне понравилась аналогия, что
стоматолог не может научиться на себе лечить зубы.
Почему я топлю всегда за изменения, настройки под заказчика, потому что хардкод быстро себя изживает, да он может быть хорош, на определённом этапе, и показывать нужные метрики. Но бизнес и ситуация во внешнем мире изменяется быстрее, чем код. Тем более no-code, low-code, и да простят меня разработки ещё и вайбкодинг.
Но так как я любитель всего добротного, качественного и на века) То я за то, чтобы ядро системы было мощным и пусть оно не изменяется, если работает. Что мы часто видим в больших компаниях с историей, что есть сердце айти-ландшафта, которое лучше не трогать, оно работает.
И мы получаем гибридное решение. Там где можно сделать гибкость и быстрое изменение, то это нужно делать (чаще всего фронты), а там где нужны мощности, защищенность и отказоустойчивость, там хоть монолит сделать можно. Не так уж он плох.
И вот, вроде бы я говорила, про продукт и проект, но фактически спустилась на рассуждения архитектуры, потому что стратегия в бизнесе напрямую отражается на стратегию айти-ландшафта.
За и против разработки универсального продукта и кастом под заказчика.
Я практически не видела проекта, где бы мне сказали, что мы делаем чисто под заказчика. Чаще всего мы делаем под заказчика, но стараемся заложить некий универсал, чтобы можно было переиспользовать или перепродавать другим.
Вцелом очень понятная идея руководства/менеджмента потратить один раз, чтобы потом как можно больше окупать.
И вот мы набираем команду профессионалов, чтобы кустарно делать космический корабль. Я тут специально пишу "кустарно", потому что этот переход к универсальному решению чаще всего был ни на чем не основан. А хуже всего, когда даже не было самого заказчика, но мы уже делали что-то абстрактно-универсальное.
Потом началась эпоха микросервисов (она вроде как продолжается), и они нам позволяют добиться гибкости под заказчика, но какой ценой?
И вцелом с этой эпохой всё больше и больше стали говорить про быстрое изменение под заказчика и пользователей. Тут тоже можно сделать универсальную базу/сердце/core с возможностью конфигурирования под заказчика.
И такое тоже было направление, у нашей команды, не совсем до конца взлетело и себя оправдало.
А теперь я снова сталкиваюсь с тем, что давайте делать кастом под заказчика. И теперь есть ИИ, и вайбкодинг. И вообще продакты, и еже с ними, настолько устали спорить с несговорчивыми разработчиками, что с удовольствием вайбкодят то что им нужно. И вот он кастом, и наконец-то получаю, то что хочу.
Так что же лучше универсальное решёние или кастом под заказчика?
Вы на какой стороне?)