О технологических зонах и цифровых «железных занавесах»
Михаил Токовинин сгущает краски, говоря о том что мир распадается на несколько технологических зон с железными занавесами между.
С точки зрения технологий данных эффект разделения на зоны есть. В западной зоне почти все проблемы решаются Амазоном, Датабриксом и Сноуфлейком. В российской зоне и данных поменьше, и технологии другие, и практики компаний отличаются, к примеру, у всех все еще аллергия на облака. В Китае либо свои опенсорсы, редко применяемые вовне, либо свои реализации вендоров.
Это приводит к тому что если ты специалист в области данных, то еще декаду назад ты мог путешествовать между зонами и твои навыки вполне бы пригождались - всюду были одинаковые ораклы и майкрософт-стеки. А сейчас - нужен ты кому-то там со своим Гринпламом и НайФаем.
Также барьер стоит для компаний, стремящихся вывести свои разработки на соседний рынок. Ты вынужден сделать по сути новый продукт, который должен смочь работать с непривычными для него интеграциями, другой регуляторикой, другими привычками пользователя.
Одним словом, хорошая новость в том что на твой маленький рыночек, где нужна интеграция с 1С и VK/Яндекс-сервисами, никто отбирать твою долю не придет. С другой стороны - вывести свой продукт на рынок сопредельных стран будет кратно сложнее чем раньше.
———————————-
Архитектор данных
Михаил Токовинин сгущает краски, говоря о том что мир распадается на несколько технологических зон с железными занавесами между.
С точки зрения технологий данных эффект разделения на зоны есть. В западной зоне почти все проблемы решаются Амазоном, Датабриксом и Сноуфлейком. В российской зоне и данных поменьше, и технологии другие, и практики компаний отличаются, к примеру, у всех все еще аллергия на облака. В Китае либо свои опенсорсы, редко применяемые вовне, либо свои реализации вендоров.
Это приводит к тому что если ты специалист в области данных, то еще декаду назад ты мог путешествовать между зонами и твои навыки вполне бы пригождались - всюду были одинаковые ораклы и майкрософт-стеки. А сейчас - нужен ты кому-то там со своим Гринпламом и НайФаем.
Также барьер стоит для компаний, стремящихся вывести свои разработки на соседний рынок. Ты вынужден сделать по сути новый продукт, который должен смочь работать с непривычными для него интеграциями, другой регуляторикой, другими привычками пользователя.
Одним словом, хорошая новость в том что на твой маленький рыночек, где нужна интеграция с 1С и VK/Яндекс-сервисами, никто отбирать твою долю не придет. С другой стороны - вывести свой продукт на рынок сопредельных стран будет кратно сложнее чем раньше.
———————————-
Архитектор данных
Telegram
Mikhail Tokovinin
Можете называть это технологической изоляцией, можете технологическим суверенитетом, но мир на наших глазах разваливается на изолированные технологические зоны.
И речь не только про технологии, речь про всю цифровую инфраструктуру, законы, среду. Просто…
И речь не только про технологии, речь про всю цифровую инфраструктуру, законы, среду. Просто…
👍10🔥4
О технологических зонах и цифровых «железных занавесах» - 2.
Про чисто пользовательский опыт или про туризм - я спокоен.
Простое наблюдение.
Не так давно я жил в районе ВДНХ. Там много китайских туристов. Прямо напротив большой гостиницы расположен красивый магазин Азбука Вкуса. При появлении на кассе группы китайских товарищей вопрос оплаты ВиЧатом решался очень быстро. Появлялся терминал, который отлично понимал китайские порядки и работал в их технологической зоне.
Так что да, перед тем как поехать в Китай туристом, надо будет почитать, как там работает такси и оплачиваются проезд на электричке. Вряд ли для кого-то сюрприз, что Яндекс-такси и карта тройка там работать перестанут.
Я предвижу появление специальных приложений враперов между технологическими зонами. Вот просто на русторе скачиваете «такси в Китае» и ездите там. Аналогично с различными бизнес-помогаями, которые объясняют как ТАМ все устроено и например пишут интеграции с тамошними яндексами/вк/госуслугами в ваши приложения.
На этом вполне можно зарабатывать большие деньги, работая окошком в «железном занавесе».
———————————————
Архитектор данных
Про чисто пользовательский опыт или про туризм - я спокоен.
Простое наблюдение.
Не так давно я жил в районе ВДНХ. Там много китайских туристов. Прямо напротив большой гостиницы расположен красивый магазин Азбука Вкуса. При появлении на кассе группы китайских товарищей вопрос оплаты ВиЧатом решался очень быстро. Появлялся терминал, который отлично понимал китайские порядки и работал в их технологической зоне.
Так что да, перед тем как поехать в Китай туристом, надо будет почитать, как там работает такси и оплачиваются проезд на электричке. Вряд ли для кого-то сюрприз, что Яндекс-такси и карта тройка там работать перестанут.
Я предвижу появление специальных приложений враперов между технологическими зонами. Вот просто на русторе скачиваете «такси в Китае» и ездите там. Аналогично с различными бизнес-помогаями, которые объясняют как ТАМ все устроено и например пишут интеграции с тамошними яндексами/вк/госуслугами в ваши приложения.
На этом вполне можно зарабатывать большие деньги, работая окошком в «железном занавесе».
———————————————
Архитектор данных
Telegram
Архитектор Данных
Алексей, архитектор данных из ВК.
Большие данные и облака.
Для связи @alexbelozersky
Большие данные и облака.
Для связи @alexbelozersky
❤10👍5
Переезд с Docker[-Compose] на Kubernetes - мини-разбор инфраструктурного вебинара глазами архитектора данных.
Я не настоящий ДевОпс, и часто кручу что-то простое в докере и докер-компоузе. Нужен просто Аэрфлоу или Суперсет - нет ничего проще развернуть готовый компоуз с ГитХаба и (какое-то время) радоваться, что все работает. Но все мы понимаем, что это времянка и рано или поздно при выходе на продакшен с SLA-ями придется переинжинирить инсталляцию на что-то более устойчивое.
Чуть ранее я анонсировал вебинар про перенос инфрастурктуры с докера на кубер от коллег. Теперь у нас есть его запись.
В вебинаре все разложили по полочкам - почему умные делают так, какие именно недостатки в простом докере и чего именно мы добиваемся переходя на более взрослое решение на основе K8S.
💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾
Выписал себе пункты:
1️⃣ Докер - отличный старт, когда контейнеров мало и инфра небольшая.
2️⃣ Докер решает только задачу запуска контейнера. Не управления многими контейнерами, не интеграции с инструментами разработки.
3️⃣ В докере нет централизованного хранилища секретов, что приводит к хранению паролей и ключей в .env и прочих текстовых файлах, и в конце концов рано или поздно, к утечкам критических доступов.
4️⃣ То же - для сетевых практик, например разделения dev & prod
5️⃣ Docker Compose - хороший способ поддержать локальное окружение разработки.
6️⃣ Docker Compose - по дизайну односерверная инфраструктура. Он не подходит для создания хоть сколь-нибудь отказоустойчивой конфигурации, непрерывной выкатки, масштабирования.
7️⃣ На основе K8S намного легче добиться ситуации когда выкатка для разработчика - это просто коммит. То же с непрерывным обслуживанием конечных пользователей.
8️⃣ То же - для возможности быстрой откатки на предыдущее состояние, если что-то идет не так
💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾
Мне было весьма полезно, хотя бы в том плане, что есть четкий набор аргументов, чего именно мы добиваемся при переходе на Кубер. Какие реально есть аргументы переноса, допустим, небольшой аналитической инфраструктуры на кубер. Тот случай, когда вроде не вчера знаком со всеми технологиями, но нужно послушать специалиста для того, чтобы в голове все улеглось в стройную картину.
Я не настоящий ДевОпс, и часто кручу что-то простое в докере и докер-компоузе. Нужен просто Аэрфлоу или Суперсет - нет ничего проще развернуть готовый компоуз с ГитХаба и (какое-то время) радоваться, что все работает. Но все мы понимаем, что это времянка и рано или поздно при выходе на продакшен с SLA-ями придется переинжинирить инсталляцию на что-то более устойчивое.
Чуть ранее я анонсировал вебинар про перенос инфрастурктуры с докера на кубер от коллег. Теперь у нас есть его запись.
В вебинаре все разложили по полочкам - почему умные делают так, какие именно недостатки в простом докере и чего именно мы добиваемся переходя на более взрослое решение на основе K8S.
Выписал себе пункты:
Мне было весьма полезно, хотя бы в том плане, что есть четкий набор аргументов, чего именно мы добиваемся при переходе на Кубер. Какие реально есть аргументы переноса, допустим, небольшой аналитической инфраструктуры на кубер. Тот случай, когда вроде не вчера знаком со всеми технологиями, но нужно послушать специалиста для того, чтобы в голове все улеглось в стройную картину.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектор Данных
На вот этот вебинар запишитесь!
https://cloud.vk.com/events/migraciya-prilozheniya-kak-perenesti-infrastrukturu-s-monolita-v-upravlyaemyj-kubernetes-v-oblake
Ведут два абсолютных "отца" кубера и облачных миграций.
В прямом эфире показываем на реальном…
https://cloud.vk.com/events/migraciya-prilozheniya-kak-perenesti-infrastrukturu-s-monolita-v-upravlyaemyj-kubernetes-v-oblake
Ведут два абсолютных "отца" кубера и облачных миграций.
В прямом эфире показываем на реальном…
1👍11✍5🔥4❤3😎1
Запускаю курс по 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
В этом году по этим темам я провел 2 вебинара, 3 доклада на конференциях, 1 круглый стол, 2 эфира, написал несколько статей и постов.
Все это время мне много пишут в личку с техническими и организацонными вопросами: как решаются задачи Х, можно ли подружить с технологией А, как продать идею перехода на DLH руководству? Я стараюсь отвечать. Не всегда получается по двум причинам
Во-первых, вопросов бывает довольно много. После сентябрьского вебинара их было порядка двух десятков.
Во-вторых, easy-to-enter, hard-to-master. Некоторые вопросы требуют предварительного системного объяснения на уровне концепций. Некоторые моменты требуют прожарки на демо-стендах, без этого я сам порой не знаю ответа.
Совместно с Алексеем Рыбаком (@rybakalexey) мы решили запустить курс на DevHands.ru. Портал Алексея известен своими глубокими техническими материалами по Хайлоаду, СУБД, Архитектуре Системному дизайну. Для меня будет большим челленжом рассказать на том же уровне, который принят там.
Буду стараться.
Что будет на курсе
⁃ Концепции и технологии Lakehouse и смежные. Как сегодня строят хранилища в крупных мировых компаниях по последнему слову техники.
⁃ Modern Data Stack. Быстрый старт, подходы, обкатанные на уже более чем десятке проектов, как в России, так и в других локациях
⁃ Много практики. Живое подключение на собранный демо-стенд
⁃ Артефакты. Репозитории и материалы, позволяющие продолжить изучать самостоятельно или быстро запустить технологию на вашем проекте
Я благодарен всем, кто смотрел выступления, поддерживал комментариями и лайками. Без вашего интереса к теме ничего бы не вышло.
Посмотреть программу и записаться на курс можно на https://devhands.ru/lakehouse
devhands.ru
Lakehouse для аналитиков и инженеров данных
Forwarded from System Design & Highload (Alexey Rybak)
Завтра стрим с Владимиром Перепелицей
Уже завтра, 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 в календарь.
Приходите, приводите друзей! И присылайте ваши вопросы в комментарии.
Уже завтра, 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 в календарь.
Приходите, приводите друзей! И присылайте ваши вопросы в комментарии.
👍8
Архитектор Данных pinned «Запускаю курс по Lakehouse, Iceberg, Modern Data Stack. В этом году по этим темам я провел 2 вебинара, 3 доклада на конференциях, 1 круглый стол, 2 эфира, написал несколько статей и постов. Все это время мне много пишут в личку с техническими и организацонными…»
Короткие тезисы по стриму о 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️⃣ Альтернатива - садим в соседний ЦОД а-синхронную реплику и смиряемся с тем фактом, что некоторые данные при плохом раскладе мы моежм потерять
💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾
Запись стрима можно посмотреть здесь
Архитектор Данных
Монс, он же Владимир Перепелица - огромный спец в распределенных технологиях и архитектурном "харде". Один из авторов Tarantool и VK S3, на котором мы строим свои Лейкхаусы.
Тезисы, которые выписал себе по ходу стрима о Кафке, НАТСе, очередеях и стриминге данных.
Когда внедряем Kafka
О движках
О растянутых между ЦОД кластерах
Запись стрима можно посмотреть здесь
Архитектор Данных
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
System Design & Highload (Alexey Rybak)
Делюсь записью встречи с Владимиром Перепелицей
https://us06web.zoom.us/rec/share/94JNdXLPdP5d_Q-YP-sq2PW7N0YzwaIZqKgPP4D0Br85YvF25s4r4RJ3sqxsX8hc.3I6dubjviBSVnUoy?startTime=1762440616000
Passcode: $3q=stCL
Zoom разбил запись на 2 части, но в плеере будет…
https://us06web.zoom.us/rec/share/94JNdXLPdP5d_Q-YP-sq2PW7N0YzwaIZqKgPP4D0Br85YvF25s4r4RJ3sqxsX8hc.3I6dubjviBSVnUoy?startTime=1762440616000
Passcode: $3q=stCL
Zoom разбил запись на 2 части, но в плеере будет…
1👍11
Forwarded from System Design & Highload (Alexey Rybak)
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) — в комментариях к посту.
🔥 за Лейкхаус
👍 за Кликхаус, Дэвэхаус или вовсе Вудхаус🎩
Друзья, тема Lakehouse внезапно оказалась очень востребованной.
Завтра во вторник 11 ноября вечером в 18:00 МСК мы проведем с Алексеем Белозерским открытую встречу!
Обсудим:
— Зачем нужен Iceberg, как он появился, какие задачи он решает, и вообще зачем такая сложность (почему нельзя просто положить файлы в S3)
— Модули современного лейкхауса: (Движок SQL) - (Iceberg Catalog) - (Storage S3/HDFS). Каким ПО можно закрыть эти задачи.
— Демо-стенд в облаке + сборка лейкхауса на докер-компоуз на виртуалках.
— Тизер курса Алексея, подробнее про темы и практику, что именно будем поднимать, как, какими данными грузить.
Вход свободный, нужно только быть авторизованным в Zoom.
Ждем вас!
Ссылка на Zoom:
https://us06web.zoom.us/j/84649465438?pwd=G5z4EFtUO6cTe56cqg1Egbpuanv8a0.1
Календарь (ics) — в комментариях к посту.
🔥 за Лейкхаус
👍 за Кликхаус, Дэвэхаус или вовсе Вудхаус
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥24👍9❤3
Как построить и как жить в домике у озера.
Задай свой вопрос в треде, и мы обязательно его озвучим на сегодняшнем стриме.
Запись будет - это не вопрос.
Будет ли ваш голос на нем - вот в чем вопрос
Задай свой вопрос в треде, и мы обязательно его озвучим на сегодняшнем стриме.
Запись будет - это не вопрос.
Будет ли ваш голос на нем - вот в чем вопрос
Основные идеи Apache Iceberg одной картинкой
1️⃣ Метаданные важнее данных. Может лежать много паркетов, но если нет их описания в манифестах, то никто их читать не будет
2️⃣ Древовидная структура данных и метаданных, сходящаяся к одному корневому файлу. Записать и удалить много файлов - не-атомарная операция, но заменить один главный файл можно атомарно всегда в любой системе хранения. Отсюда почти-транзакционность.
3️⃣ Хранение предыдущих состояний, таблица превращается в лог состояний с возможностью прочитать любую точку в истории. Но только старые версии надо потом подчищать через обсуживающие процедуры.
4️⃣ (Мета)Каталог как вспомогательный сервис. Для MVCC и честного ACID, для хранения статистики, RBAC и других обслуживающих функций
💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾
Архитектор Данных
Архитектор Данных
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍17
Media is too big
VIEW IN TELEGRAM
О, это типичный пресейл или презентация продукта
Продукт дает вам "передовую технологию"
Вы понимаете, что не все может пройти гладко.
И вы даже выбиваете чтобы инженерному шедевру приделали на спину ручку на случай если-когда он бзданется
И вы идете вдвоем, потому что штука тяжелая, и в одного вы его обратно на ноги не поставите
И у вас даже есть бекап-план, где вы закрываете происходящее брезентом и хотя бы не так обидно
НО ВСЕ ЧЕРЕЗ Ж... все равно.
Продукт дает вам "передовую технологию"
Вы понимаете, что не все может пройти гладко.
И вы даже выбиваете чтобы инженерному шедевру приделали на спину ручку на случай если-когда он бзданется
И вы идете вдвоем, потому что штука тяжелая, и в одного вы его обратно на ноги не поставите
И у вас даже есть бекап-план, где вы закрываете происходящее брезентом и хотя бы не так обидно
НО ВСЕ ЧЕРЕЗ Ж... все равно.
😁21🙈5🤝5👌1
Forwarded from System Design & Highload (Alexey Rybak)
Делюсь записью вчерашнего видео Lakehouse для аналитиков и инженеров данных (Алексей Белозерский):
https://us06web.zoom.us/rec/share/WqJ0XEWdsgb96ZPfW4UCqfrt5yiNh9j6ZrgFSeNO2mo7TLjjIq0siNK5eUAtWcqV.PTwIDlNnpLzjB1vR?startTime=1762872622000
Passcode: 3c.!q.$*
Lakehouse, 20 ноября
https://us06web.zoom.us/rec/share/WqJ0XEWdsgb96ZPfW4UCqfrt5yiNh9j6ZrgFSeNO2mo7TLjjIq0siNK5eUAtWcqV.PTwIDlNnpLzjB1vR?startTime=1762872622000
Passcode: 3c.!q.$*
Lakehouse, 20 ноября
👍15
Архитектор Данных
Разговоры на архитекторском: ML платформа. 13 ноября мы проведем вторую серию «Разговоров на архитекторском» и в этот раз коснемся индустриальных ML платформ. Эксперт - руководитель разработки и ML OPS в крупной технологичной компании, которую вы все знаете.…
Настал этот день!
Сегодня ровно в 18:00 время московское, мы начинаем стрим по ML платформам!
С Олегом Королевым, руководителем AI Lab компании Авито мы поговорим как построить крутую AI-ML платформу в 2026 году.
Подпишитесь на канал Данные на стероидах и обязательно присоединяйтесь к стриму!
Как всегда ваши вопросы спикеру моожно задать в этом треде.
До встречи!
Сегодня ровно в 18:00 время московское, мы начинаем стрим по ML платформам!
С Олегом Королевым, руководителем AI Lab компании Авито мы поговорим как построить крутую AI-ML платформу в 2026 году.
Подпишитесь на канал Данные на стероидах и обязательно присоединяйтесь к стриму!
Как всегда ваши вопросы спикеру моожно задать в этом треде.
До встречи!
Telegram
Данные на стероидах
Разговоры на архитекторском возвращаются! Уже 13 ноября в 18:00 по мск мы в прямом эфире будем обсуждать актуальные проблемы современных ML-платформ. Рассмотрим классический ML-Ops и LLM-Ops, поговорим про инфраструктуру, а вы сможете задать свои вопросы.…
🔥11👍5❤4
Тренды на глобальном рынке разработчиков
На открытой сессии по Lakehouse задали интересный вопрос: "Если я Backend разработчик, большая ли польза учиться Lakehouse, Modern Data Stack?"
Вот на картинке хороший аргумент, что польза есть.
В моей практике было несколько примеров, когда применение подходов из арсенала инжиниринга данных на порядки ускоряло разработку, упрощало многие процессы. Вместо разработки цепочки микро-сервисов, которые должны были разбирать характеристики объектов, разделять годные и негодные, скорить по качеству, обогащать другими данными, команды применяли Airflow DAG, который батчами выполнял ту же работу.
Микросервисы сводились к набору скриптов на SQL, Python, Bash, а стабильность работы и SLA обеспечивались дата-инжиниринговыми средствами промышленной поставки данных.
В головах людей сидит, что инжиниринг данных это что-то из управленческой и финансовой отчетности, KPI или ML. Но факт тот, что применяя достижения в DE можно радикально сократить оценки и время задач, которые падают на разработку.
Более того, в эру ИИ существенно стали полезны фундаментальные знания в смежных дисциплинах. Ты знаешь на сутевом уровне как архитектурно правильно, а детали тебе расскажет ChatGPT. 10% фундамента, 90% LLM - и задача решится.
Учите Modern Data Stack, дорогие разработчики!
На открытой сессии по Lakehouse задали интересный вопрос: "Если я Backend разработчик, большая ли польза учиться Lakehouse, Modern Data Stack?"
Вот на картинке хороший аргумент, что польза есть.
В моей практике было несколько примеров, когда применение подходов из арсенала инжиниринга данных на порядки ускоряло разработку, упрощало многие процессы. Вместо разработки цепочки микро-сервисов, которые должны были разбирать характеристики объектов, разделять годные и негодные, скорить по качеству, обогащать другими данными, команды применяли Airflow DAG, который батчами выполнял ту же работу.
Микросервисы сводились к набору скриптов на SQL, Python, Bash, а стабильность работы и SLA обеспечивались дата-инжиниринговыми средствами промышленной поставки данных.
В головах людей сидит, что инжиниринг данных это что-то из управленческой и финансовой отчетности, KPI или ML. Но факт тот, что применяя достижения в DE можно радикально сократить оценки и время задач, которые падают на разработку.
Более того, в эру ИИ существенно стали полезны фундаментальные знания в смежных дисциплинах. Ты знаешь на сутевом уровне как архитектурно правильно, а детали тебе расскажет ChatGPT. 10% фундамента, 90% LLM - и задача решится.
Учите Modern Data Stack, дорогие разработчики!
2🫡15
Forwarded from Соня Рыбак | HR for Engineers
ТОП Работодателей 2025 (Forbes × РБК × Хабр)
1) Есть 4 рейтинга, каждый смотрит на работодателей по-своему
Forbes — смотрит на уровень корпоративного управление и прозрачность, социальную ответственность, экологию и благополучие сотрудников. Насколько компания зрелый, ответственный и безопасный работодатель
РБК — смотрит на условия труда, уровень зарплат, обучение, текучесть, бизнес-эффективность, инновации, деловую репутацию и юридическую чистоту. Насколько компания надежна, эффективна и конкурентоспособна на рынке
Хабр — смотрит на привлекательность бренда и узнаваемость среди разработчиков, репутацию инженерной и продуктовой культуры. Насколько компания нравится разработчикам
HH — еще не вышел, смотрит на качество найма, скорость откликов, коммуникации, отношение сотрудников и кандидатов. Как компанию воспринимает весь рынок труда, народный рейтинг работодателей
2) Рейтинг от Хабра, ТОП-30
1. Авиасейлс
2. Авито
3. 2ГИС
4. Dodo Engineering
5. Точка Банк
6. Лаборатория Касперского
7. Alfa Digital
8. Selectel
9. Ozon
10. Райффайзен Банк
11. Т-Банк
12. Lamoda
13. HeadHunter
14. Бюро 1440
15. Альфа-Банк
16. ВкусВилл
17. Positive Technologies
18. Циан
19. X5 Tech
20. YADRO
21. S7 Airlines
22. Cloud.ru
23. Контур
24. BI.ZONE
25. Okko
26. Nexign
27. Axenix
28. Северсталь
29. Яндекс
30. Холдинг T1
3) Тройное пересечение топовых групп
🤩 Forbes Платина × РБК Группа 1 × Хабр ТОП-30 — 4 компании
1) Авито
На Хабре — 2 место
В Forbes — в платиновой группе
В РБК — Группа 1
2) Т-Банк
На Хабре — 11 место
В Forbes — в платиновой группе
В РБК — Группа 1
3) Альфа-Банк
На Хабре — 15 место
В Forbes — в платиновой группе
В РБК — Группа 1
4) Яндекс
На Хабре — 29 место
В Forbes — в платиновой группе
В РБК — Группа 1
Больше таких трипл-мэтчей нет.
4) Средняя зарплата выросла на 9%
У РБК есть интересный показатель средней зарплаты. Рост 9%: 169,6К рублей в 2025 году, 155,8К в 2024.
Текущая годовая инфляция 8%, а ключевая ставка 16%. То есть фактически это означает что реального роста зарплат почти нет.
1) Есть 4 рейтинга, каждый смотрит на работодателей по-своему
Forbes — смотрит на уровень корпоративного управление и прозрачность, социальную ответственность, экологию и благополучие сотрудников. Насколько компания зрелый, ответственный и безопасный работодатель
РБК — смотрит на условия труда, уровень зарплат, обучение, текучесть, бизнес-эффективность, инновации, деловую репутацию и юридическую чистоту. Насколько компания надежна, эффективна и конкурентоспособна на рынке
Хабр — смотрит на привлекательность бренда и узнаваемость среди разработчиков, репутацию инженерной и продуктовой культуры. Насколько компания нравится разработчикам
HH — еще не вышел, смотрит на качество найма, скорость откликов, коммуникации, отношение сотрудников и кандидатов. Как компанию воспринимает весь рынок труда, народный рейтинг работодателей
2) Рейтинг от Хабра, ТОП-30
1. Авиасейлс
2. Авито
3. 2ГИС
4. Dodo Engineering
5. Точка Банк
6. Лаборатория Касперского
7. Alfa Digital
8. Selectel
9. Ozon
10. Райффайзен Банк
11. Т-Банк
12. Lamoda
13. HeadHunter
14. Бюро 1440
15. Альфа-Банк
16. ВкусВилл
17. Positive Technologies
18. Циан
19. X5 Tech
20. YADRO
21. S7 Airlines
22. Cloud.ru
23. Контур
24. BI.ZONE
25. Okko
26. Nexign
27. Axenix
28. Северсталь
29. Яндекс
30. Холдинг T1
3) Тройное пересечение топовых групп
1) Авито
На Хабре — 2 место
В Forbes — в платиновой группе
В РБК — Группа 1
2) Т-Банк
На Хабре — 11 место
В Forbes — в платиновой группе
В РБК — Группа 1
3) Альфа-Банк
На Хабре — 15 место
В Forbes — в платиновой группе
В РБК — Группа 1
4) Яндекс
На Хабре — 29 место
В Forbes — в платиновой группе
В РБК — Группа 1
Больше таких трипл-мэтчей нет.
4) Средняя зарплата выросла на 9%
У РБК есть интересный показатель средней зарплаты. Рост 9%: 169,6К рублей в 2025 году, 155,8К в 2024.
Текущая годовая инфляция 8%, а ключевая ставка 16%. То есть фактически это означает что реального роста зарплат почти нет.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤4👌3🤷♂1
Архитектор Данных
Яндекс говорит что пересобрал систему собесов Когда увидел цифру "90" и подумал что это новое число этапов собеса.
Еще вариант от подписчиков:
90+ это ожидаемый возраст на момент прохождения всех треков.
90+ это ожидаемый возраст на момент прохождения всех треков.
😁32
Forwarded from Инжиниринг Данных (Dmitry)
В статье 5 Things in Data Engineering That Have Changed In The Last 10 Years автор поделился как поменялась индустрия (западная) за последние 10 лет.
1) Компании хотят только сеньоров
Команды сильно сократились, и бизнес требует быстрых результатов → поэтому нанимают в основном опытных инженеров + AI-копилоты усилили продуктивность сеньоров. Джуниорам сложнее входить.
Это произошло в последние 2-3 года. Никому не нужны малыши без опыта. Все хотят опытных людей, чтобы пришли и сразу решали конкретные задачи. В больших компаниях еще сохранилась возможность пройти стажировку и прийти сразу с универа. Но надо, чтобы универ был топчик. Все кто ходят на курсы - мимо. Поэтому мой подход прийти seniorом без опыта выглядит особенно привлекательно в текущих реалиях. Улучшений в будущем для данной ситуации не видно. Специалисты и эксперты в ИТ появляются как грибы. Доступность образования и реклама успешных айтишников в Дубаях и на Патриках делает свое дело.🚶♀️ Все хотят хорошую зарплату и удаленную работу, но места на всех не хватит.😞
2) Cloud стал дефолтом
Раньше облако было опцией, сейчас — стандарт. Все мигрируют: Snowflake, BigQuery, Databricks. Почти никто не строит аналитику он-прем.
Полностью согласен. Я могу открыть любую вакансию в Северной Америке, Южной Америке, Европе, Австралии и тп, и там будет облако и MPP облачное хранилище с вероятностью 95%. Хотя недавно познакомился с инженером, кто пришел к нам из Comcast. Он рассказал, что у них был свой дата центр и он ставил Kafka на bare metal. Ну красавчик, только получает в несколько раз меньше.🏆
3) Перестали писать кастомные пайплайны
10 лет назад везде были самописные ETL на cron/SSIS/python скриптах. Сейчас сразу используют готовые инструменты: Airflow, dbt, EventBridge, Coalesce, etc. Нужно быстрее приносить ценность, а не строить платформу с нуля.
Доступность инструментов low-code/no-code очень сильно упрощают работу. Можно фокусироваться на бизнес проблемах и ценностях, а не трабалшуить legacy/technical debt код. Хотя уже с развитием AI IDE уже все превращается в no-code/low code. Главное базу знать и понимать основу и свою ценность для бизнеса.
4) SQL победил
Споры между SQL vs что-то ещё закончились — SQL стал универсальным стандартом. Job-market требует SQL практически везде. dbt усилил этот тренд.
Если ваш продукт не поддерживает SQL, то у вас плохой продукт. SQL наше все. Хотя некоторые аналитики обожают Pandas, и пишут что-то в своих ноутбуках. А потом инженерам нужно все это разгребать.🙅♂️
5) AI изменил рабочие процессы
AI ускоряет работу, но создаёт риск «движения вместо прогресса»: люди меньше понимают код, больше копипастят из LLM. Выигрывают те, кто умеет совмещать AI + инженерное мышление.
100% все поменялось. Я общаюсь со многими командами и вижу, что люди на самом деле не очень сильно используют все возможности. Большинство не любят перемен и не умеют учиться быстро и эффективно. Когда говорят, что AI заменит людей, чаще всего имеют в виду тех, кто не хочет или не умеет учиться. Сейчас настоящий FOMO в AI и очень важно смотреть куда дует ветер и стараться использовать в работе AI и собирать полезные use cases для вашей индустрии и вашей специализации.
Самое главное, что произошло за 10 лет, то это обесценивание денег, повышение налогов, снижение покупательной способности, отмена job security, и отсутствие стабильности.🤟
1) Компании хотят только сеньоров
Команды сильно сократились, и бизнес требует быстрых результатов → поэтому нанимают в основном опытных инженеров + AI-копилоты усилили продуктивность сеньоров. Джуниорам сложнее входить.
Это произошло в последние 2-3 года. Никому не нужны малыши без опыта. Все хотят опытных людей, чтобы пришли и сразу решали конкретные задачи. В больших компаниях еще сохранилась возможность пройти стажировку и прийти сразу с универа. Но надо, чтобы универ был топчик. Все кто ходят на курсы - мимо. Поэтому мой подход прийти seniorом без опыта выглядит особенно привлекательно в текущих реалиях. Улучшений в будущем для данной ситуации не видно. Специалисты и эксперты в ИТ появляются как грибы. Доступность образования и реклама успешных айтишников в Дубаях и на Патриках делает свое дело.
2) Cloud стал дефолтом
Раньше облако было опцией, сейчас — стандарт. Все мигрируют: Snowflake, BigQuery, Databricks. Почти никто не строит аналитику он-прем.
Полностью согласен. Я могу открыть любую вакансию в Северной Америке, Южной Америке, Европе, Австралии и тп, и там будет облако и MPP облачное хранилище с вероятностью 95%. Хотя недавно познакомился с инженером, кто пришел к нам из Comcast. Он рассказал, что у них был свой дата центр и он ставил Kafka на bare metal. Ну красавчик, только получает в несколько раз меньше.
3) Перестали писать кастомные пайплайны
10 лет назад везде были самописные ETL на cron/SSIS/python скриптах. Сейчас сразу используют готовые инструменты: Airflow, dbt, EventBridge, Coalesce, etc. Нужно быстрее приносить ценность, а не строить платформу с нуля.
Доступность инструментов low-code/no-code очень сильно упрощают работу. Можно фокусироваться на бизнес проблемах и ценностях, а не трабалшуить legacy/technical debt код. Хотя уже с развитием AI IDE уже все превращается в no-code/low code. Главное базу знать и понимать основу и свою ценность для бизнеса.
4) SQL победил
Споры между SQL vs что-то ещё закончились — SQL стал универсальным стандартом. Job-market требует SQL практически везде. dbt усилил этот тренд.
Если ваш продукт не поддерживает SQL, то у вас плохой продукт. SQL наше все. Хотя некоторые аналитики обожают Pandas, и пишут что-то в своих ноутбуках. А потом инженерам нужно все это разгребать.
5) AI изменил рабочие процессы
AI ускоряет работу, но создаёт риск «движения вместо прогресса»: люди меньше понимают код, больше копипастят из LLM. Выигрывают те, кто умеет совмещать AI + инженерное мышление.
100% все поменялось. Я общаюсь со многими командами и вижу, что люди на самом деле не очень сильно используют все возможности. Большинство не любят перемен и не умеют учиться быстро и эффективно. Когда говорят, что AI заменит людей, чаще всего имеют в виду тех, кто не хочет или не умеет учиться. Сейчас настоящий FOMO в AI и очень важно смотреть куда дует ветер и стараться использовать в работе AI и собирать полезные use cases для вашей индустрии и вашей специализации.
Самое главное, что произошло за 10 лет, то это обесценивание денег, повышение налогов, снижение покупательной способности, отмена job security, и отсутствие стабильности.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍15