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

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

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️⃣ То же - для возможности быстрой откатки на предыдущее состояние, если что-то идет не так

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

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