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

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

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

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

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

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

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

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

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

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

Темы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Короткие тезисы по стриму о 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️⃣ Альтернатива - садим в соседний ЦОД а-синхронную реплику и смиряемся с тем фактом, что некоторые данные при плохом раскладе мы моежм потерять

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

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

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