Архитектор Данных

Как построить и как жить в домике у озера.

Задай свой вопрос в треде, и мы обязательно его озвучим на сегодняшнем стриме.

Запись будет - это не вопрос.
Будет ли ваш голос на нем - вот в чем вопрос

Lakehouse: открытая встреча / демо, Алексей Белозерский, VKCloud

Друзья, тема Lakehouse внезапно оказалась очень востребованной.

Завтра во вторник 11 ноября вечером в 18:00 МСК мы проведем с Алексеем Белозерским открытую встречу!

Обсудим:

— Зачем нужен Iceberg, как он появился, какие задачи он решает, и вообще зачем такая сложность (почему нельзя просто положить файлы в S3)

— Модули современного лейкхауса: (Движок SQL) - (Iceberg Catalog) - (Storage S3/HDFS). Каким ПО можно закрыть эти задачи.

— Демо-стенд в облаке + сборка лейкхауса на докер-компоуз на виртуалках.

— Тизер курса Алексея, подробнее про темы и практику, что именно будем поднимать, как, какими данными грузить.

Вход свободный, нужно только быть авторизованным в Zoom.

Ждем вас!

Ссылка на Zoom:
https://us06web.zoom.us/j/84649465438?pwd=G5z4EFtUO6cTe56cqg1Egbpuanv8a0.1

Календарь (ics) — в комментариях к посту.

🔥 за Лейкхаус
👍 за Кликхаус, Дэвэхаус или вовсе Вудхаус 🎩

Короткие тезисы по стриму о Kafka от Монса

Монс, он же Владимир Перепелица - огромный спец в распределенных технологиях и архитектурном "харде". Один из авторов Tarantool и VK S3, на котором мы строим свои Лейкхаусы.

Тезисы, которые выписал себе по ходу стрима о Кафке, НАТСе, очередеях и стриминге данных.

Когда внедряем Kafka

1️⃣ Kafka - Commodity инструмент для работы с потоками данных. Если нужна СУБД, берешь Postgres, если нужен стрим, берешь Kafka.

2️⃣ Kafka добавляет в данные измерение времени. В СУБД как правило - текущий снапшот данных. В Кафке автоматически и почти бесплатно генерируются истории изменений, которые потом может прочитать любой потребитель, а не только тот, кто их генерировал.

3️⃣ Идеальный сценарий работы для Kafka - генерируем поток данных или лог изменений состояний, не зная заранее, кому и зачем он может понадобиться.


О движках

1️⃣ Kafka 4.x - переход на KRaft с Zookeeper. Отныне эта опция по умолчанию.

2️⃣ KRaft лучше и стабильнее, так как все данные и метаданные о топиках, консьюмерах хранятся в одной системе а не двух. Не тратим время на согласование из системы в систему и нет риска, что данные и метаданные в какой-то момент разъедутся.

3️⃣ Граница между движком очереди и движком стрима практически стерта сейчас. Стримы умеют в семантику очереди, очереди умеют в стримы.


О растянутых между ЦОД кластерах

1️⃣ На расстоянии между ЦОД в десятки милисекунд синхронные транзакции работают хорошо. Этого достаточно чтобы сходить туда-обратно и подтвердить, что данные зафиксированы.

2️⃣ Проблема с синхронными транзакциями начнется когда и если на один пользовательский запрос мы начинаем тратить 10-50 транзакций. Это неверная архитектура приложения. Так делать не надо.

3️⃣ Правильный путь - делаем свои 10-50 изменений в приложении и в конце подтверждаем все одной распределенной транзакцией.

4️⃣ Альтернатива - садим в соседний ЦОД а-синхронную реплику и смиряемся с тем фактом, что некоторые данные при плохом раскладе мы моежм потерять

💾💾💾💾💾💾💾💾💾💾💾💾💾💾💾💾💾

Запись стрима можно посмотреть здесь

Архитектор Данных

Архитектор Данных pinned «Запускаю курс по Lakehouse, Iceberg, Modern Data Stack. В этом году по этим темам я провел 2 вебинара, 3 доклада на конференциях, 1 круглый стол, 2 эфира, написал несколько статей и постов. Все это время мне много пишут в личку с техническими и организацонными…»

Завтра стрим с Владимиром Перепелицей

Уже завтра, 6-го ноября в 18:00 MSK состоится очередная Q&A сессия. На этот раз у нас в гостях Владимир Перепелица, эксперт в больших проектах, cоздатель S3 в облаке VK, Solution Architect в Exness, бессменный автор и ведущий одного их самых популярных курсов Devhands - интенсива по очередям (Kafka, NATS и др.).

Обсудим:
- Kafka 4: какие принципиальные изменения принес этот релиз? Поменялось ли что-то в Кафке в плане HA и катастрофо-устойчивости?
- Действительно ли с ростом производительности железа и возможностей облаков наступает конец хайлоада as we know it? Какие инженерные знания сейчас наиболее востребованы?

А так же многие другие вопросы (преимущественно по брокерам и очередям), которые мы собираем в клубе выпускников Devhands и в комментариях к этому посту.

Встреча состоится в Zoom в четверг 6-ноября 18:00 MSK. Встреча свободна, но нужно быть авторизованным в Zoom.
Можно добавить ics в календарь.

Приходите, приводите друзей! И присылайте ваши вопросы в комментарии.

Точно стоит послушать человека, написавшего свою СУБД (Tarantool)

Запускаю курс по Lakehouse, Iceberg, Modern Data Stack.

В этом году по этим темам я провел 2 вебинара, 3 доклада на конференциях, 1 круглый стол, 2 эфира, написал несколько статей и постов.
Все это время мне много пишут в личку с техническими и организацонными вопросами: как решаются задачи Х, можно ли подружить с технологией А, как продать идею перехода на DLH руководству? Я стараюсь отвечать. Не всегда получается по двум причинам

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

Во-вторых, easy-to-enter, hard-to-master. Некоторые вопросы требуют предварительного системного объяснения на уровне концепций. Некоторые моменты требуют прожарки на демо-стендах, без этого я сам порой не знаю ответа.

Совместно с Алексеем Рыбаком (@rybakalexey) мы решили запустить курс на DevHands.ru. Портал Алексея известен своими глубокими техническими материалами по Хайлоаду, СУБД, Архитектуре Системному дизайну. Для меня будет большим челленжом рассказать на том же уровне, который принят там.

Буду стараться.

Что будет на курсе

⁃ Концепции и технологии Lakehouse и смежные. Как сегодня строят хранилища в крупных мировых компаниях по последнему слову техники.
⁃ Modern Data Stack. Быстрый старт, подходы, обкатанные на уже более чем десятке проектов, как в России, так и в других локациях
⁃ Много практики. Живое подключение на собранный демо-стенд
⁃ Артефакты. Репозитории и материалы, позволяющие продолжить изучать самостоятельно или быстро запустить технологию на вашем проекте

Я благодарен всем, кто смотрел выступления, поддерживал комментариями и лайками. Без вашего интереса к теме ничего бы не вышло.

Посмотреть программу и записаться на курс можно на https://devhands.ru/lakehouse

Грамотные нынче инвесторы пошли

Переезд с Docker[-Compose] на Kubernetes - мини-разбор инфраструктурного вебинара глазами архитектора данных.

Я не настоящий ДевОпс, и часто кручу что-то простое в докере и докер-компоузе. Нужен просто Аэрфлоу или Суперсет - нет ничего проще развернуть готовый компоуз с ГитХаба и (какое-то время) радоваться, что все работает. Но все мы понимаем, что это времянка и рано или поздно при выходе на продакшен с SLA-ями придется переинжинирить инсталляцию на что-то более устойчивое.

Чуть ранее я анонсировал вебинар про перенос инфрастурктуры с докера на кубер от коллег. Теперь у нас есть его запись.

В вебинаре все разложили по полочкам - почему умные делают так, какие именно недостатки в простом докере и чего именно мы добиваемся переходя на более взрослое решение на основе K8S.

💾💾💾💾💾💾💾💾💾💾💾💾💾💾

Выписал себе пункты:

1️⃣ Докер - отличный старт, когда контейнеров мало и инфра небольшая.

2️⃣ Докер решает только задачу запуска контейнера. Не управления многими контейнерами, не интеграции с инструментами разработки.

3️⃣ В докере нет централизованного хранилища секретов, что приводит к хранению паролей и ключей в .env и прочих текстовых файлах, и в конце концов рано или поздно, к утечкам критических доступов.

4️⃣ То же - для сетевых практик, например разделения dev & prod

5️⃣ Docker Compose - хороший способ поддержать локальное окружение разработки.

6️⃣ Docker Compose - по дизайну односерверная инфраструктура. Он не подходит для создания хоть сколь-нибудь отказоустойчивой конфигурации, непрерывной выкатки, масштабирования.

7️⃣ На основе K8S намного легче добиться ситуации когда выкатка для разработчика - это просто коммит. То же с непрерывным обслуживанием конечных пользователей.

8️⃣ То же - для возможности быстрой откатки на предыдущее состояние, если что-то идет не так

💾💾💾💾💾💾💾💾💾💾💾💾💾💾

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

О технологических зонах и цифровых «железных занавесах» - 2.

Про чисто пользовательский опыт или про туризм - я спокоен.

Простое наблюдение.

Не так давно я жил в районе ВДНХ. Там много китайских туристов. Прямо напротив большой гостиницы расположен красивый магазин Азбука Вкуса. При появлении на кассе группы китайских товарищей вопрос оплаты ВиЧатом решался очень быстро. Появлялся терминал, который отлично понимал китайские порядки и работал в их технологической зоне.

Так что да, перед тем как поехать в Китай туристом, надо будет почитать, как там работает такси и оплачиваются проезд на электричке. Вряд ли для кого-то сюрприз, что Яндекс-такси и карта тройка там работать перестанут.

Я предвижу появление специальных приложений враперов между технологическими зонами. Вот просто на русторе скачиваете «такси в Китае» и ездите там. Аналогично с различными бизнес-помогаями, которые объясняют как ТАМ все устроено и например пишут интеграции с тамошними яндексами/вк/госуслугами в ваши приложения.

На этом вполне можно зарабатывать большие деньги, работая окошком в «железном занавесе».

———————————————

Архитектор данных

О технологических зонах и цифровых «железных занавесах»

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

С точки зрения технологий данных эффект разделения на зоны есть. В западной зоне почти все проблемы решаются Амазоном, Датабриксом и Сноуфлейком. В российской зоне и данных поменьше, и технологии другие, и практики компаний отличаются, к примеру, у всех все еще аллергия на облака. В Китае либо свои опенсорсы, редко применяемые вовне, либо свои реализации вендоров.

Это приводит к тому что если ты специалист в области данных, то еще декаду назад ты мог путешествовать между зонами и твои навыки вполне бы пригождались - всюду были одинаковые ораклы и майкрософт-стеки. А сейчас - нужен ты кому-то там со своим Гринпламом и НайФаем.

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

Одним словом, хорошая новость в том что на твой маленький рыночек, где нужна интеграция с 1С и VK/Яндекс-сервисами, никто отбирать твою долю не придет. С другой стороны - вывести свой продукт на рынок сопредельных стран будет кратно сложнее чем раньше.

———————————-

Архитектор данных

На форуме «Открытые данные» в Казани.

На техническом треке рассказал про гибкие подходы в организации данных, про облака и лейкхаусы.

Разговоры на архитекторском: ML платформа.

13 ноября мы проведем вторую серию «Разговоров на архитекторском» и в этот раз коснемся индустриальных ML платформ.

Эксперт - руководитель разработки и ML OPS в крупной технологичной компании, которую вы все знаете.

Темы.

1️⃣Платформа инференса в 2025 году. Как построить и как грамотно утилизировать большой парк современных GPU

2️⃣Классический ML и трансформерный ИИ. Может ли существовать одно без другого.

3️⃣Если ты стажер или джун и хочешь в ML, на что тебе стоит обратить внимание и что изучить

Всех ждем на стриме 13-го ноября вечером. Приходите и приводите друзей!

—————————————————

Первая часть «разговоров», где мы общались о внедрении Lakehouse с Вадимом, руководителем разработки платформы данных Х5, ждет вас в виде разбора тут или в видео формате в плейлисте

Мессенджер Макс как кладбище
Все там будем

Вот так новости

Workspace - корпоративный мессенджер, который ставится в инфраструктуру вашей компании (а еще корп почта, звонки, таск-трекер, облако для файлов, офис и тд)

Макс - все знаем что

Можно будет создать чат с подрядчиком или кандидатом, в котором будут с одной стороны внутри-корповые учетки, доступные из VK Workspace / Teams, а с другой стороны - внешние люди из Макса.

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

Как по мне - удобно, я порядком замучался копипастить разную информацию из корпового мессенджера в телегу и обратно 😄

Материалы хабрастатьи есть в видео формате:

https://t.me/analyticsfromzero/246

Написали большой хабрапост о внутрянке формата айсберг.

Постарался раскрыть вопросы

1️⃣Как перейти от навала файлов в S3/HDFS до хорошего Data Lake[House]

2️⃣Зачем нужны все эти сложности с вложенной древовидной метадатой

3️⃣Откуда берется ACID в не ACID-ном хранилище S3.

4️⃣Какие процедуры поддержки требуется применить к DLH на айсберге.

Вопросы как всегда можно задать в коментах.