Дата с Димой - эпизод 5
(YouTube, RuTube)
💡 В этом эпизоде обсуждаем свежие новости из мира BigTech, карьерные инсайты, новые технологии, оптимизацию данных, а также влиятельные стартапы и инвестиции.
🎯 Ключевые темы выпуска:
🧠 Черный юмор и интеллект - связь между чувством юмора и уровнем интеллекта.
💻 COBOL язык для не технических пользователей в 1960х - обсуждение языка программирования COBOL и его актуальности.
☁️ Snowflake и Trino - закрытие Snowflake и переход на альтернативные решения.
📊 Оптимизация Apache Spark - методы повышения производительности и эффективного использования ресурсов.
🤖 Внедрение Generative AI - как компании используют генеративный искусственный интеллект для повышения продуктивности.
📉 Сокращения в дата-командах - влияние сокращений на качество работы и аналитику.
🎓 Образование и карьера - советы по обучению и развитию карьеры в условиях снижения количества вакансий.
🛠️ Инструменты для работы с данными - использование DBT, Azure Data Factory и других инструментов в проектах.
📈 Инвестиции в AI - обсуждение инвестиций в искусственный интеллект и его влияние на рынок.
⚡ Будущее профессий - замена профессий AI и перспективы для специалистов в разных областях.
(YouTube, RuTube)
💡 В этом эпизоде обсуждаем свежие новости из мира BigTech, карьерные инсайты, новые технологии, оптимизацию данных, а также влиятельные стартапы и инвестиции.
🎯 Ключевые темы выпуска:
🧠 Черный юмор и интеллект - связь между чувством юмора и уровнем интеллекта.
💻 COBOL язык для не технических пользователей в 1960х - обсуждение языка программирования COBOL и его актуальности.
☁️ Snowflake и Trino - закрытие Snowflake и переход на альтернативные решения.
📊 Оптимизация Apache Spark - методы повышения производительности и эффективного использования ресурсов.
🤖 Внедрение Generative AI - как компании используют генеративный искусственный интеллект для повышения продуктивности.
📉 Сокращения в дата-командах - влияние сокращений на качество работы и аналитику.
🎓 Образование и карьера - советы по обучению и развитию карьеры в условиях снижения количества вакансий.
🛠️ Инструменты для работы с данными - использование DBT, Azure Data Factory и других инструментов в проектах.
📈 Инвестиции в AI - обсуждение инвестиций в искусственный интеллект и его влияние на рынок.
⚡ Будущее профессий - замена профессий AI и перспективы для специалистов в разных областях.
11⚡26❤🔥12🐳1💯1😈1💘1
Spark-митап в Москве 29 мая!
IT-компания «Криптонит» приглашает на Spark-митап: обсудим кейсы, практики применения и тренды развития!
🟢 Когда и где пройдёт?
29 мая в 18:30 в Музее криптографии
🟢 Кому Spark Meetup полезен?
🔹 инженерам данных и аналитикам данных
🔹 программистам со знанием Spark и Scala
🔹 всем смежным специальностям из телекома, банков, промышленности и ретейла
🟢 Кто будет выступать с докладами?
Эксперты из «Криптонита», Positive Technologies и М2. Программу можно посмотреть тут
🟢 Как зарегистрироваться?
Вот по этой ссылке
🟢 Будет ли трансляция?
Обязательно будет. Ссылку разместим позже на странице мероприятия — поэтому советуем зарегистрироваться на оффлайн-встречу, даже если вы не сможете прийти. Так вы точно не потеряете ссылку на онлайн
🟢 Нужно что-то платить?
Нет, митап бесплатный — ждём всех неравнодушных к программированию на Spark!
Зарегистрироваться
Реклама АО НПК «Криптонит» ИНН 9701115253 Erid:
2VtzqufQAvG
IT-компания «Криптонит» приглашает на Spark-митап: обсудим кейсы, практики применения и тренды развития!
29 мая в 18:30 в Музее криптографии
Эксперты из «Криптонита», Positive Technologies и М2. Программу можно посмотреть тут
Вот по этой ссылке
Обязательно будет. Ссылку разместим позже на странице мероприятия — поэтому советуем зарегистрироваться на оффлайн-встречу, даже если вы не сможете прийти. Так вы точно не потеряете ссылку на онлайн
Нет, митап бесплатный — ждём всех неравнодушных к программированию на Spark!
Зарегистрироваться
Реклама АО НПК «Криптонит» ИНН 9701115253 Erid:
2VtzqufQAvG
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥9⚡5🫡3💯1
Forwarded from Data Apps Design (Artemiy Kozyr)
Привет,
По следам доклада на ОФФЛАЙН митапе в Сочи:
🏆 dbt - индустриальный стандарт для трансформации данных в DWH
✍️ Позволяет писать, тестировать, документировать трансформации как SQL-код
☁️ Работает поверх современных облачных и on-premise платформ (Snowflake, BigQuery, Redshift, Databricks, Postgres и др.)
🏆 Использует лучшие практики разработки: версионирование, модульность, CI/CD, документация
Было много вопросов и заблуждений по поводу концепта dbt, поэтому дублирую:
— С т.з. манипуляции данными dbt умеет ровно столько, сколько умеет ваша аналитическая БД
— dbt не пропускает данные через себя, а лишь "раздает" команды БД, которая выполняет все операции (heavy lifting)
— dbt это просто python package с удобным CLI
— Рассматривайте dbt как мультитул-автоматизацию для работы с вашей аналитической БД
— Тема вызвала живой интерес и поток вопросов (которые продолжились после выступления)
— Отметил, что даже сложные концепты в подаче с простыми примерами и доступными формулировками легко воспринимаются даже неподготовленным слушателем
— Обрел старых (Станислав, привет 🙂!) и новых друзей и единомышленников
— Стихийно организовалась afterparty в соседнем ресторане с обсуждением смежных тем, обменом опыта и знакомствами
— Зарядился на дальнейшие планы и шаги, о которых буду сообщать
Запись, к сожалению, не велась.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥18⚡3💯3
Forwarded from Яна Тимохина | Про рост и личное (Яна Тимохина | Карьерный консультант и коуч | HR)
Сегодня прочитала в одном канале интересную мысль. СЕО одной компании (РФ) делился взглядом на сторонние проекты сотрудников.
Если коротко, он написал: личная узнаваемость — это не угроза, а актив. И для компании, и для самого человека. В его команде поощряли сотрудников выступать, делиться опытом. И даже если кто-то после этого находил более интересную работу — он был рад. Потому что это тоже заслуга команды, компании — вырастить сильного, востребованного специалиста.
И мне это близко. И не могу не вспомнить свой пример (читайте - ошибку).
Когда я еще работала HR, то ещё во время пандемии пошла учиться карьерному консалтингу и уже знакомилась с коучингом.
Цели были простые:
— применить знания внутри компании,
— и «на всякий случай». Мало ли что.
Но я так и не начала практиковать.
Почему? Где-то в разговорах промелькнула фраза: «Не хотелось бы, чтобы тебя ассоциировали с брендом компании». Я услышала. И не стала ничего делать. Только опубликовала сертификат — и всё.
По этическим причинам. Из лояльности (и из страха быть «неудобной». Ведь увольняться я не собиралась и к чему эти недопонимания...)
А потом... Прошло больше трёх лет. Переезд. Увольнение. Новая страна. Неизвестное будущее.
И я осталась без привычной опоры в виде моей работы и собственной зарплаты.
И вот тогда — пожалела. Что не начала строить свою практику параллельно с наймом.
Потому что тогда у меня уже была бы хоть какая-то узнаваемость, финансовая подушка, новый опыт в новой роли. Я бы уже успела совершить свои ошибки, нарастить навыки.
А не начинать всё с нуля в новой точке, да и еще в условиях высокой неопреденности.
Поэтому сейчас я точно знаю: личный бренд — это не про тщеславие. Это про выбор. Про свободу. Про устойчивость.
И его масштаб может быть разным. Кому-то комфортно вести блог на 300 подписчиков. Кому-то — выступать на конференциях.
Вопрос не в формате, а в том, чтобы вас видели и знали — как специалиста, как личность, как эксперта.
Потому что если вы не видимы внутри компании — вас будто бы нет. Любое повышение будет идти медленнее, если нужные люди не знают, кто вы и в чём ваша ценность.
Да, кому-то из руководителей может не понравиться, что вы развиваете что-то своё.
Есть риск, что энтузиазм «гореть» корпоративными задачами у вас снизится.
И да — это возможно.
Снимаю с себя белое пальто идеального HR, который будет говорить: «Работайте только на компанию, всё остальное — опасно и неправильно». Нет. Не нужно. Много рисков.
Компания — это не ваша семья. Это партнёрство. Где вы обмениваете своё время, энергию и компетенции на деньги и опыт.
И ваш ресурс, когда вы молоды, горите, полны сил и идей — ограничен. Помните об этом.
Поэтому, что важнее: ваша жизнь — или чей-то комфорт в корпорации?
Некоторым компаниям неудобно, когда вы просите повышения, хотите больше свободы, пробуете новое. Им проще, когда вы молчите и «благодарны за то, что есть». Но это их позиции, ведь цель у бизнеса только одна - зарабатывать.
А ваша цель какая?
📌 Если вы хотите расти в доходе, обрести свободу, накопить ценный опыт, чтобы однажды продать себя дороже — вы обязаны использовать все возможности.
Ваш главный актив — это вы.
Ваше время, энергия, навыки.
Не сливайте их в один сценарий, в который не верите на 100%.
Как я говорю своим клиентам: если компании нужно будет вас уволить — она это сделает.
Холодно. Быстро. Рационально. Потому что у неё есть своя цель — сократить расходы, сохранить бизнес, поменять стратегию.
Задайте себе вопросы:
- Что вы хотите от своей работы?
- Какие потребности она должна закрывать — кроме «выжить»?
Пока вы нужны — думайте шире.
Развивайте свой актив (себя). Выступления, проекты, соцсети, обучение — это инвестиции в ваш профессиональный капитал.
И это ваша зона ответственности - развивать свою карьреу с целью Х.
Если коротко, он написал: личная узнаваемость — это не угроза, а актив. И для компании, и для самого человека. В его команде поощряли сотрудников выступать, делиться опытом. И даже если кто-то после этого находил более интересную работу — он был рад. Потому что это тоже заслуга команды, компании — вырастить сильного, востребованного специалиста.
И мне это близко. И не могу не вспомнить свой пример (читайте - ошибку).
Когда я еще работала HR, то ещё во время пандемии пошла учиться карьерному консалтингу и уже знакомилась с коучингом.
Цели были простые:
— применить знания внутри компании,
— и «на всякий случай». Мало ли что.
Но я так и не начала практиковать.
Почему? Где-то в разговорах промелькнула фраза: «Не хотелось бы, чтобы тебя ассоциировали с брендом компании». Я услышала. И не стала ничего делать. Только опубликовала сертификат — и всё.
По этическим причинам. Из лояльности (и из страха быть «неудобной». Ведь увольняться я не собиралась и к чему эти недопонимания...)
А потом... Прошло больше трёх лет. Переезд. Увольнение. Новая страна. Неизвестное будущее.
И я осталась без привычной опоры в виде моей работы и собственной зарплаты.
И вот тогда — пожалела. Что не начала строить свою практику параллельно с наймом.
Потому что тогда у меня уже была бы хоть какая-то узнаваемость, финансовая подушка, новый опыт в новой роли. Я бы уже успела совершить свои ошибки, нарастить навыки.
А не начинать всё с нуля в новой точке, да и еще в условиях высокой неопреденности.
Поэтому сейчас я точно знаю: личный бренд — это не про тщеславие. Это про выбор. Про свободу. Про устойчивость.
И его масштаб может быть разным. Кому-то комфортно вести блог на 300 подписчиков. Кому-то — выступать на конференциях.
Вопрос не в формате, а в том, чтобы вас видели и знали — как специалиста, как личность, как эксперта.
Потому что если вы не видимы внутри компании — вас будто бы нет. Любое повышение будет идти медленнее, если нужные люди не знают, кто вы и в чём ваша ценность.
Да, кому-то из руководителей может не понравиться, что вы развиваете что-то своё.
Есть риск, что энтузиазм «гореть» корпоративными задачами у вас снизится.
И да — это возможно.
Снимаю с себя белое пальто идеального HR, который будет говорить: «Работайте только на компанию, всё остальное — опасно и неправильно». Нет. Не нужно. Много рисков.
Компания — это не ваша семья. Это партнёрство. Где вы обмениваете своё время, энергию и компетенции на деньги и опыт.
И ваш ресурс, когда вы молоды, горите, полны сил и идей — ограничен. Помните об этом.
Поэтому, что важнее: ваша жизнь — или чей-то комфорт в корпорации?
Некоторым компаниям неудобно, когда вы просите повышения, хотите больше свободы, пробуете новое. Им проще, когда вы молчите и «благодарны за то, что есть». Но это их позиции, ведь цель у бизнеса только одна - зарабатывать.
А ваша цель какая?
Ваш главный актив — это вы.
Ваше время, энергия, навыки.
Не сливайте их в один сценарий, в который не верите на 100%.
Как я говорю своим клиентам: если компании нужно будет вас уволить — она это сделает.
Холодно. Быстро. Рационально. Потому что у неё есть своя цель — сократить расходы, сохранить бизнес, поменять стратегию.
Задайте себе вопросы:
- Что вы хотите от своей работы?
- Какие потребности она должна закрывать — кроме «выжить»?
Пока вы нужны — думайте шире.
Развивайте свой актив (себя). Выступления, проекты, соцсети, обучение — это инвестиции в ваш профессиональный капитал.
И это ваша зона ответственности - развивать свою карьреу с целью Х.
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡41💯28❤🔥4🗿4
В последнем эпизоде «Дата с Димой» я рассказывал, насколько важно для карьерного роста выше уровня Senior понимать бизнес-метрики, цели компании и уметь разговаривать с руководителями бизнес-направлений на одном языке.
Умение строить отчёты, проектировать хранилища данных и интегрировать данные с ML/AI — это здорово, но если не понимать, зачем это нужно бизнесу, теряется смысл работы, становится сложно аргументировать свою ценность, и в конечном итоге работа перестаёт быть интересной.
Один из способов понять, зачем всё это нужно и какие существуют топовые use cases — это сходить на конференцию Aha!25.
Aha!25 - техническая конференция о product science, продуктовой аналитике и эффективности бизнеса. В этом году мы впервые расширяем программу до двух дней: 16 тематических потоков и более 1200 участников на одной площадке.
Ключевые темы:
- Интеграция LLM, ML и AI в цифровые сервисы
- Современные подходы к A/B-тестированию
- Оцифровка пользовательского опыта
- Применение машинного обучения в управлении продуктом
- Математическое мышление и поведенческая экономика
Приглашаем продуктовых менеджеров и аналитиков, инженеров данных, владельцев продуктов, CPO, CDO, ML-разработчиков. Программа будет полезна как новичкам, так и экспертам.
Где: МГУ, кластер «Ломоносов» (Раменский бульвар, 1).
Программа: http://ahaconf.ru/program
Билеты — на сайте!
Умение строить отчёты, проектировать хранилища данных и интегрировать данные с ML/AI — это здорово, но если не понимать, зачем это нужно бизнесу, теряется смысл работы, становится сложно аргументировать свою ценность, и в конечном итоге работа перестаёт быть интересной.
Один из способов понять, зачем всё это нужно и какие существуют топовые use cases — это сходить на конференцию Aha!25.
Aha!25 - техническая конференция о product science, продуктовой аналитике и эффективности бизнеса. В этом году мы впервые расширяем программу до двух дней: 16 тематических потоков и более 1200 участников на одной площадке.
Ключевые темы:
- Интеграция LLM, ML и AI в цифровые сервисы
- Современные подходы к A/B-тестированию
- Оцифровка пользовательского опыта
- Применение машинного обучения в управлении продуктом
- Математическое мышление и поведенческая экономика
Приглашаем продуктовых менеджеров и аналитиков, инженеров данных, владельцев продуктов, CPO, CDO, ML-разработчиков. Программа будет полезна как новичкам, так и экспертам.
Где: МГУ, кластер «Ломоносов» (Раменский бульвар, 1).
Программа: http://ahaconf.ru/program
Билеты — на сайте!
❤🔥13
Про Python сняли кино https://youtu.be/pqBqdNIPrbo?si=Go2kcWzKWIZLw_-e
YouTube
Python: The Documentary [OFFICIAL TRAILER] | Out now! 🚨
🚨 The Python Documentary premieres August 28!
---
From a side project in Amsterdam to powering AI at the world’s biggest companies - this is the story of Python. Featuring Guido van Rossum, Travis Oliphant, Barry Warsaw, and many more, our upcoming full…
---
From a side project in Amsterdam to powering AI at the world’s biggest companies - this is the story of Python. Featuring Guido van Rossum, Travis Oliphant, Barry Warsaw, and many more, our upcoming full…
🫡37❤🔥9⚡4🙈1💘1
Устроиться аналитиком в Яндекс за выходные
7–8 июня проводим Weekend Offer Analytics. До 3 июня оставьте заявку на участие, 7 июня пройдите два технические собеседования, а 8 июня познакомьтесь с командами и получите офер.
В мероприятии участвует 12 команд: Алиса и Умные устройства, Игры, R&D, Рекламные технологии, Поиск и Суперапп, Безопасность, Коммерческий департамент, Автономный транспорт, Ecom-сценарии Поиска, Качество Поиска, Международный Поиск, Карты. Вы сможете пообщаться с менеджерами и выбрать проект, который покажется самым интересным.
Узнать подробности и зарегистрироваться можно здесь.
7–8 июня проводим Weekend Offer Analytics. До 3 июня оставьте заявку на участие, 7 июня пройдите два технические собеседования, а 8 июня познакомьтесь с командами и получите офер.
В мероприятии участвует 12 команд: Алиса и Умные устройства, Игры, R&D, Рекламные технологии, Поиск и Суперапп, Безопасность, Коммерческий департамент, Автономный транспорт, Ecom-сценарии Поиска, Качество Поиска, Международный Поиск, Карты. Вы сможете пообщаться с менеджерами и выбрать проект, который покажется самым интересным.
Узнать подробности и зарегистрироваться можно здесь.
😭5🌚3
Хочу вам напомнить про полезные ресурсы:
1) datalearn учебник, где на русском есть 6,5 модулей про аналитику и инжиниринг данных и отдельный курс от Анатолия про SQL(лучше курса еще не придумали), где вы будете сами устанавливать Postgres и SQL Server и много практики https://github.com/Data-Learn/data-engineering
2) свежая версия курса на английском 3,5 модуля и дополнительный модуль 0 - https://surfalytics.com/surfalytics/2023-06-03-Introduction.html
1) datalearn учебник, где на русском есть 6,5 модулей про аналитику и инжиниринг данных и отдельный курс от Анатолия про SQL(лучше курса еще не придумали), где вы будете сами устанавливать Postgres и SQL Server и много практики https://github.com/Data-Learn/data-engineering
2) свежая версия курса на английском 3,5 модуля и дополнительный модуль 0 - https://surfalytics.com/surfalytics/2023-06-03-Introduction.html
GitHub
GitHub - Data-Learn/data-engineering: Getting Started with Data Enngineering
Getting Started with Data Enngineering. Contribute to Data-Learn/data-engineering development by creating an account on GitHub.
❤🔥118⚡19💯11🍾6
Неожиданно! Главный SaaS CRM покупает old-school ETL вендер Informatica🤪
Компания Salesforce объявила о планах приобрести платформу управления данными Informatica за приблизительно $8 миллиардов. Это станет крупнейшей сделкой Salesforce с момента покупки Slack за $28 миллиардов в 2021 году. Данная покупка направлена на усиление возможностей Salesforce в области управления данными и интеграции генеративного искусственного интеллекта (ИИ) в свои бизнес-инструменты. В частности, приобретение Informatica позволит Salesforce улучшить контроль над использованием данных, что критически важно для развития ИИ-функций, таких как платформа Agentforce, предназначенная для автоматизации задач с помощью виртуальных ИИ-агентов.
Осталось кому-нибудь купить Teradata📊
Компания Salesforce объявила о планах приобрести платформу управления данными Informatica за приблизительно $8 миллиардов. Это станет крупнейшей сделкой Salesforce с момента покупки Slack за $28 миллиардов в 2021 году. Данная покупка направлена на усиление возможностей Salesforce в области управления данными и интеграции генеративного искусственного интеллекта (ИИ) в свои бизнес-инструменты. В частности, приобретение Informatica позволит Salesforce улучшить контроль над использованием данных, что критически важно для развития ИИ-функций, таких как платформа Agentforce, предназначенная для автоматизации задач с помощью виртуальных ИИ-агентов.
Осталось кому-нибудь купить Teradata📊
🙈24🦄6❤🔥3🐳2
DuckDB предложил очень интересную альтернативу - DuckLake: SQL as a Lakehouse Format
Что это значит?
Если мы откатимся назад и повторим эволюцию аналитических решений - от классического хранилища данных до современного Lakehouse, можно выделить основные этапы:
- Data Warehouse (Хранилище данных) - хранение и вычисления происходят на одном физическом/виртуальном сервере или кластере.
- Data Lake (Озеро данных) - происходит разделение хранения и вычислений.
- Lakehouse - гибрид Data Lake и Data Warehouse. Ключевой элемент - формат таблиц (Iceberg, Delta, Hudi), который добавляет возможности управления изменениями в data lake. Эти форматы используют сложные файловые структуры (JSON, Avro) для отслеживания версий и схем.
Сегодня на рынке представлен широкий спектр инструментов и тесная интеграция между подходами. Любое решение - это всегда компромисс. Выбор зависит от бюджета, возможностей и экспертизы команды и т. д.
У Lakehouse есть важный недостаток - сложности с обеспечением атомарности операций и управлением несколькими таблицами, а также ряд других проблем. Те, кто строил Iceberg-архитектуру, могут поделиться своими ограничениями и трудностями.
DuckLake предлагает альтернативный подход: вся метаинформация (каталоги, схемы, версии) хранится в стандартной SQL-базе данных, поддерживающей ACID-транзакции и первичные ключи. Это позволяет:
- Обеспечить надежное и простое управление метаданными.
- Поддерживать транзакции, охватывающие несколько таблиц.
- Избежать сложностей, связанных с согласованностью в blob-хранилищах.
При этом данные продолжают храниться в открытых форматах, таких как Parquet, что обеспечивает совместимость и гибкость. То есть метаданные "уходят" в DuckDB - в SQL-таблицу, которая и используется в качестве каталога.
Вот такое элегантное решение. Кстати, ниша managed duckdb в публичных облаках свободна🍸
PS В Surfalytics мы делали пару проектов про DuckDB и даже есть урок в основном курсе:
Just enough DuckDB for Data Analyst | Module 2.7 | Surfalytics
И в datalearn у нас был классный обзор от Романа Зыкова:
Разработка data приложений на DuckDB
Что это значит?
Если мы откатимся назад и повторим эволюцию аналитических решений - от классического хранилища данных до современного Lakehouse, можно выделить основные этапы:
- Data Warehouse (Хранилище данных) - хранение и вычисления происходят на одном физическом/виртуальном сервере или кластере.
- Data Lake (Озеро данных) - происходит разделение хранения и вычислений.
- Lakehouse - гибрид Data Lake и Data Warehouse. Ключевой элемент - формат таблиц (Iceberg, Delta, Hudi), который добавляет возможности управления изменениями в data lake. Эти форматы используют сложные файловые структуры (JSON, Avro) для отслеживания версий и схем.
Сегодня на рынке представлен широкий спектр инструментов и тесная интеграция между подходами. Любое решение - это всегда компромисс. Выбор зависит от бюджета, возможностей и экспертизы команды и т. д.
У Lakehouse есть важный недостаток - сложности с обеспечением атомарности операций и управлением несколькими таблицами, а также ряд других проблем. Те, кто строил Iceberg-архитектуру, могут поделиться своими ограничениями и трудностями.
DuckLake предлагает альтернативный подход: вся метаинформация (каталоги, схемы, версии) хранится в стандартной SQL-базе данных, поддерживающей ACID-транзакции и первичные ключи. Это позволяет:
- Обеспечить надежное и простое управление метаданными.
- Поддерживать транзакции, охватывающие несколько таблиц.
- Избежать сложностей, связанных с согласованностью в blob-хранилищах.
При этом данные продолжают храниться в открытых форматах, таких как Parquet, что обеспечивает совместимость и гибкость. То есть метаданные "уходят" в DuckDB - в SQL-таблицу, которая и используется в качестве каталога.
Вот такое элегантное решение. Кстати, ниша managed duckdb в публичных облаках свободна
PS В Surfalytics мы делали пару проектов про DuckDB и даже есть урок в основном курсе:
Just enough DuckDB for Data Analyst | Module 2.7 | Surfalytics
И в datalearn у нас был классный обзор от Романа Зыкова:
Разработка data приложений на DuckDB
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥28🫡2
Как ВЫЙТИ из IT и стать счастливым?
Владислав Князев, тимлид из финтеха, искренне и с жизнелюбием пишет про путь от выгоревшего айтишника в надежного психолога.
Поддерживающий блог для тех, кто ищет гармонию и уверенность в себе❤️
Подпишись на @godnolytika
Владислав Князев, тимлид из финтеха, искренне и с жизнелюбием пишет про путь от выгоревшего айтишника в надежного психолога.
Поддерживающий блог для тех, кто ищет гармонию и уверенность в себе
Подпишись на @godnolytika
Please open Telegram to view this post
VIEW IN TELEGRAM
🤷18🗿9🦄7🌭6❤🔥4🍌3
Бодрая неделька выдалась, столько новинок интересных. Ведь скоро Databricks и Snowflake Summit.
Если вы будете на этих конференциях пишите в комментах, может там найдетесь, и выпьете по стаканьчику. Я сам смогу намутить pass на 1 бесплатный день на Snowflake конференцию, но этого малова-то. Если вы в Калифорнии и хотите попасть бесплатно на один день (среда) Snowlfake, я расскажу как это сделать.
1️⃣ dbt labs там выкатили большой список обновлений - dbt Launch Showcase 2025 recap
dbt MCP Server - сервер, обрабатывающий dbt-команды централизованно и ускоряющий запуск моделей, особенно в облачных и CI/CD-средах. А кто сейчас не делает MCP?
Fusion engine - движок на Rust, который анализирует SQL-код ещё до выполнения, улучшая производительность и предотвращая ошибки. Как раз был потс в январе про покупку SDF.
VS Code Extension - официальное расширение для VS Code с поддержкой Fusion, автодополнением и анализом SQL, но работает только с dbt Cloud.
dbt Canvas - визуальный интерфейс для проектирования моделей и связей между ними, ориентированный на командную работу и документирование. Получается, что главное преимущество аналитика как код уходит на 2й план. Это дает доступ простым бизнес пользователям (больше пользователей, больше лицензий?!), но по факту может изменить концепт. У меня уже коллеги интересуются как они могут модельки-то строить в канвасе.
dbt Insights - помогает отслеживать перформанс моделей и находить узкие места.
dbt Catalog - расширенный каталог моделей, колонок и источников с поиском, тегами и улучшенной навигацией по проекту. Удобно, но dbt docs и так был достаточно хорош.
Cost management dashboard - дашборд для мониторинга стоимости выполнения моделей в разных средах и выявления неэффективных запросов. Полезно, но можно и свой сделать в обычном BI.
Мы видим все больше и больше разделение dbt core (открытое ПО) и коммерческий dbt labs. Вы не поверите, но у меня даже проблемы использовать оба инструменты в командной строке, так как оба используют
2️⃣ вышел Spark 4.0. Но там нет таких красивых красочных изменений, поэтому и в новостях потише.
Spark Connect - новая клиент-серверная архитектура, позволяющая подключаться к Spark-кластерам из различных языков (Python, Scala, Go, Swift, Rust) без необходимости установки Spark локально, что упрощает разработку и масштабирование приложений.
ANSI SQL по умолчанию - включение режима ANSI SQL обеспечивает более строгую проверку данных и совместимость с другими СУБД, улучшая переносимость и предсказуемость SQL-запросов.
SQL PIPE-синтаксис - введение оператора |> для последовательного применения SQL-операций, повышая читаемость и упрощая написание сложных запросов.
SQL-скрипты с переменными и управляющими конструкциями — поддержка переменных, циклов и условий в SQL позволяет реализовывать сложную бизнес-логику непосредственно в SQL-скриптах без необходимости использования внешних языков программирования.
Тип данных VARIANT - новый тип данных (прям как у Snowflake 10 лет назад) для хранения полуструктурированных данных, таких как JSON, обеспечивая эффективную работу с вложенными структурами без необходимости явного определения схемы.
Нативная визуализация в PySpark - возможность создавать графики и диаграммы непосредственно из DataFrame в PySpark с использованием Plotly, упрощая анализ данных.
Python Data Source API - новый API, позволяющий разработчикам создавать собственные источники данных для пакетной и потоковой обработки полностью на Python, расширяя возможности интеграции.
Polymorphic Python UDTFs - поддержка пользовательских табличных функций в Python с динамической схемой, позволяя создавать гибкие и мощные трансформации данных.
Structured Logging - введение структурированного логирования в формате JSON, облегчая мониторинг и отладку приложений.
transformWithState API - новый API для обработки состояния в потоковой обработке, предоставляющий более гибкие и мощные возможности для управления состоянием в реальном времени.
PS вы можете посмотреть Snowflake Keynotes онлайн по этой ссылке
Если вы будете на этих конференциях пишите в комментах, может там найдетесь, и выпьете по стаканьчику. Я сам смогу намутить pass на 1 бесплатный день на Snowflake конференцию, но этого малова-то. Если вы в Калифорнии и хотите попасть бесплатно на один день (среда) Snowlfake, я расскажу как это сделать.
dbt MCP Server - сервер, обрабатывающий dbt-команды централизованно и ускоряющий запуск моделей, особенно в облачных и CI/CD-средах. А кто сейчас не делает MCP?
Fusion engine - движок на Rust, который анализирует SQL-код ещё до выполнения, улучшая производительность и предотвращая ошибки. Как раз был потс в январе про покупку SDF.
VS Code Extension - официальное расширение для VS Code с поддержкой Fusion, автодополнением и анализом SQL, но работает только с dbt Cloud.
dbt Canvas - визуальный интерфейс для проектирования моделей и связей между ними, ориентированный на командную работу и документирование. Получается, что главное преимущество аналитика как код уходит на 2й план. Это дает доступ простым бизнес пользователям (больше пользователей, больше лицензий?!), но по факту может изменить концепт. У меня уже коллеги интересуются как они могут модельки-то строить в канвасе.
dbt Insights - помогает отслеживать перформанс моделей и находить узкие места.
dbt Catalog - расширенный каталог моделей, колонок и источников с поиском, тегами и улучшенной навигацией по проекту. Удобно, но dbt docs и так был достаточно хорош.
Cost management dashboard - дашборд для мониторинга стоимости выполнения моделей в разных средах и выявления неэффективных запросов. Полезно, но можно и свой сделать в обычном BI.
Мы видим все больше и больше разделение dbt core (открытое ПО) и коммерческий dbt labs. Вы не поверите, но у меня даже проблемы использовать оба инструменты в командной строке, так как оба используют
dbt команду.Spark Connect - новая клиент-серверная архитектура, позволяющая подключаться к Spark-кластерам из различных языков (Python, Scala, Go, Swift, Rust) без необходимости установки Spark локально, что упрощает разработку и масштабирование приложений.
ANSI SQL по умолчанию - включение режима ANSI SQL обеспечивает более строгую проверку данных и совместимость с другими СУБД, улучшая переносимость и предсказуемость SQL-запросов.
SQL PIPE-синтаксис - введение оператора |> для последовательного применения SQL-операций, повышая читаемость и упрощая написание сложных запросов.
SQL-скрипты с переменными и управляющими конструкциями — поддержка переменных, циклов и условий в SQL позволяет реализовывать сложную бизнес-логику непосредственно в SQL-скриптах без необходимости использования внешних языков программирования.
Тип данных VARIANT - новый тип данных (прям как у Snowflake 10 лет назад) для хранения полуструктурированных данных, таких как JSON, обеспечивая эффективную работу с вложенными структурами без необходимости явного определения схемы.
Нативная визуализация в PySpark - возможность создавать графики и диаграммы непосредственно из DataFrame в PySpark с использованием Plotly, упрощая анализ данных.
Python Data Source API - новый API, позволяющий разработчикам создавать собственные источники данных для пакетной и потоковой обработки полностью на Python, расширяя возможности интеграции.
Polymorphic Python UDTFs - поддержка пользовательских табличных функций в Python с динамической схемой, позволяя создавать гибкие и мощные трансформации данных.
Structured Logging - введение структурированного логирования в формате JSON, облегчая мониторинг и отладку приложений.
transformWithState API - новый API для обработки состояния в потоковой обработке, предоставляющий более гибкие и мощные возможности для управления состоянием в реальном времени.
PS вы можете посмотреть Snowflake Keynotes онлайн по этой ссылке
Please open Telegram to view this post
VIEW IN TELEGRAM
dbt Labs
dbt Launch Showcase 2025 recap | dbt Labs
New features in dbt empower organizations to scale analytics for the age of AI
❤🔥17⚡4🍾2
Forwarded from BeOps
Вот такой сервис который сравнивает IT зарплаты из всего русского сегмента.
Как я понял, он пылесосит все открытые источники типа hh и сливает все в приятный репорт.
https://public.tableau.com/shared/3KN2X2YXN?:display_count=n&:origin=viz_share_link&:showVizHome=no
По-моему выглядит очень хорошо и полезно. Готовимся.
Как я понял, он пылесосит все открытые источники типа hh и сливает все в приятный репорт.
https://public.tableau.com/shared/3KN2X2YXN?:display_count=n&:origin=viz_share_link&:showVizHome=no
По-моему выглядит очень хорошо и полезно. Готовимся.
❤🔥52
Очень интересная точка зрения основателя Tobiko (SQLMesh) — главного конкурента dbt.
Мы тут были в восторге от новой фичи dbt: он стал значительно быстрее, потому что его переписали на Rust. Логично, что переписывание старого движка дало мощный прирост в скорости, и выбор Rust очевидно удачный.
Но мы так привыкли к "бесплатному" и хорошо работающему dbt Core, что воспринимаем это как должное. А вот из-за такой "данности" компания dbt Labs теряет деньги. А им ведь ещё нужно отчитываться перед инвесторами.
Вот с Airflow и Airbyte всегда было проще, косяк на косяке=) (вот только не говорите мне, что "готовить не умею", я бы тогда просто-бы макросы VBA "приготовил бы"🧐 )
Вот и сам текст:
dbt Fusion — это полная переработка dbt Core на языке Rust. В отличие от dbt Core, который является полностью бесплатным и с открытым исходным кодом под лицензией Apache 2.0, dbt Fusion — это не open-source проект, так как распространяется по более ограничительной лицензии Elastic 2.0.
Хотя Fusion и можно использовать бесплатно, его лицензия запрещает использование в хостинговых или управляемых решениях третьими сторонами. Возможно, это кажется незначительным, но у этого ограничения есть серьёзные последствия.
Открытый исходный код хорош тем, что он стимулирует как отдельных разработчиков, так и компании инвестировать в развитие продукта без риска. Компания может полностью полагаться на open-source решение, потому что в любом случае его можно форкнуть и использовать в своих целях, независимо от решений основного разработчика. Лицензия с ограничениями, такая как Elastic, наоборот, демотивирует компании вкладываться в развитие продукта.
Не поймите неправильно: в решении dbt Labs нет ничего неэтичного. Более того, с финансовой точки зрения для них это может быть наиболее разумным шагом. Но важно понять, как мы к этому пришли и что это может значить для будущего dbt Core.
Мне кажется, стратегия dbt заключается в том, чтобы перевести dbt Core в режим поддержки (maintenance mode), сосредоточившись на Fusion и других коммерческих продуктах. Формулировки в анонсе были выбраны очень осторожно и расплывчато. В частности, говоря о поддержке dbt Core, они упомянули только исправление багов, обновления безопасности и поддержание совместимости.
Согласно их роадмапу, они отделили dbt-язык от runtime-движка. Также отдельно подчёркивается, что Fusion и Core со временем неизбежно разойдутся, поскольку Fusion обладает возможностями, которые невозможно добавить в Core. По моему мнению, dbt Labs используют эту возможность, чтобы сосредоточиться на более ограниченном и прибыльном софте, постепенно сворачивая то, что сделало их знаменитыми, но одновременно мешает их финансовому росту.
В конечном итоге ресурсы ограничены, и компании вынуждены расставлять приоритеты исходя из интересов бизнеса.
Учитывая фундаментальное значение dbt Core для современной аналитической инфраструктуры, аналитики и инженеры данных заслуживают свободную, открытую и постоянно развивающуюся платформу для трансформации данных. В противном случае ваша карьера окажется слишком зависимой от решений одной-единственной компании. Чтобы обеспечить непрерывные инновации в области data-трансформаций, возможно, пришло время начать дискуссию об открытом стандарте описания трансформаций данных.
Посмотрим как долго SQLMesh будет открытый (то есть как долго будет экономика сходится)🔪
Мы тут были в восторге от новой фичи dbt: он стал значительно быстрее, потому что его переписали на Rust. Логично, что переписывание старого движка дало мощный прирост в скорости, и выбор Rust очевидно удачный.
Но мы так привыкли к "бесплатному" и хорошо работающему dbt Core, что воспринимаем это как должное. А вот из-за такой "данности" компания dbt Labs теряет деньги. А им ведь ещё нужно отчитываться перед инвесторами.
Вот с Airflow и Airbyte всегда было проще, косяк на косяке=) (вот только не говорите мне, что "готовить не умею", я бы тогда просто-бы макросы VBA "приготовил бы"
Вот и сам текст:
dbt Fusion — это полная переработка dbt Core на языке Rust. В отличие от dbt Core, который является полностью бесплатным и с открытым исходным кодом под лицензией Apache 2.0, dbt Fusion — это не open-source проект, так как распространяется по более ограничительной лицензии Elastic 2.0.
Хотя Fusion и можно использовать бесплатно, его лицензия запрещает использование в хостинговых или управляемых решениях третьими сторонами. Возможно, это кажется незначительным, но у этого ограничения есть серьёзные последствия.
Открытый исходный код хорош тем, что он стимулирует как отдельных разработчиков, так и компании инвестировать в развитие продукта без риска. Компания может полностью полагаться на open-source решение, потому что в любом случае его можно форкнуть и использовать в своих целях, независимо от решений основного разработчика. Лицензия с ограничениями, такая как Elastic, наоборот, демотивирует компании вкладываться в развитие продукта.
Не поймите неправильно: в решении dbt Labs нет ничего неэтичного. Более того, с финансовой точки зрения для них это может быть наиболее разумным шагом. Но важно понять, как мы к этому пришли и что это может значить для будущего dbt Core.
Мне кажется, стратегия dbt заключается в том, чтобы перевести dbt Core в режим поддержки (maintenance mode), сосредоточившись на Fusion и других коммерческих продуктах. Формулировки в анонсе были выбраны очень осторожно и расплывчато. В частности, говоря о поддержке dbt Core, они упомянули только исправление багов, обновления безопасности и поддержание совместимости.
Согласно их роадмапу, они отделили dbt-язык от runtime-движка. Также отдельно подчёркивается, что Fusion и Core со временем неизбежно разойдутся, поскольку Fusion обладает возможностями, которые невозможно добавить в Core. По моему мнению, dbt Labs используют эту возможность, чтобы сосредоточиться на более ограниченном и прибыльном софте, постепенно сворачивая то, что сделало их знаменитыми, но одновременно мешает их финансовому росту.
В конечном итоге ресурсы ограничены, и компании вынуждены расставлять приоритеты исходя из интересов бизнеса.
Учитывая фундаментальное значение dbt Core для современной аналитической инфраструктуры, аналитики и инженеры данных заслуживают свободную, открытую и постоянно развивающуюся платформу для трансформации данных. В противном случае ваша карьера окажется слишком зависимой от решений одной-единственной компании. Чтобы обеспечить непрерывные инновации в области data-трансформаций, возможно, пришло время начать дискуссию об открытом стандарте описания трансформаций данных.
Посмотрим как долго SQLMesh будет открытый (то есть как долго будет экономика сходится)
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡19🐳6🌚3❤🔥1🤷♂1
Forwarded from Книжный куб (Alexander Polomodov)
AI-помощники при работе с кодом. Взгляд в будущее - Евгений Колесников - Platform Engineering Night (Рубрика #AI)
Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже
1. Реальность разработки
По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях
- Ментальная модель - что мы хотим сделать
- Семантическая модель - как мы это будем делать
- Синтаксическая модель - непосредственно сам код
ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта.
2. Режимы работы разработчиков
Существуют два основных режима:
- Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем
- Exploration - поиск информации в документации, интернете, общение с ИИ
Понимание этих режимов критично для эффективного использования ИИ-инструментов.
3. Чего хотят разработчики от ИИ
По мнению Евгения ожидания инженеров такие
- Переложить на AI рутинные операции, например, написание юнит-тестов
- Общаться на естественном языке с последующим уточнением через промпты
- Получить детерминированные результаты от недетерминированного genAI
Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper
4. Бизнес-приоритеты
Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше
5. Проблема измерения эффективности
Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании"
6. LLM ≠ Продукт
Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели.
7. Правильные метрики
Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок.
8. Снижение хайпа - это хорошо
За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию.
9. Будущее: от генерации к агентам
Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш.
Если подводить итоги, то Евгений считает, что AI-помощники однозначно полезны, но важно понимать их ограничения и правильно интегрировать в рабочий процесс, а не гнаться за хайпом.
#AI #Software #Engineering #Architecture #Agents
Крутое выступление Евгения из команды Yandex Infrastructure, в котором он делится глубокими мыслями про развитие AI copilot инструментами. Женя выступал с этим докладом на Platform Engineering Night в Т-Банке. Я уже рассказывал про выступления моих коллег оттуда: "AI и Platform Engineering" от Игоря Маслова и "Разработка собственного AI-ассистента для кода: спринт или марафон?" Дениса Артюшина. Ребята рассказывали про наши подходы к интеграции AI в SDLC) и интересно сравнить мысли из тех докладов с идеями Жени, что я постарался изложить ниже
1. Реальность разработки
По стате разработчики пишут код всего 40 минут - 120 минут в день, при этом комитят в среднем только 40 строк кода в день. Основная проблема не в скорости печати, а в сложности мыслительных процессов, что идут на трех уровнях
- Ментальная модель - что мы хотим сделать
- Семантическая модель - как мы это будем делать
- Синтаксическая модель - непосредственно сам код
ИИ сейчас помогает в основном на последнем этапе, что объясняет ограниченность эффекта.
2. Режимы работы разработчиков
Существуют два основных режима:
- Flow - сотояние потока, когда код "летит из-под пальцев". Интересно, что в DevEx фреймворке Flow - это одна из составлящих, кстати, я делал обзор whitepaper о нем
- Exploration - поиск информации в документации, интернете, общение с ИИ
Понимание этих режимов критично для эффективного использования ИИ-инструментов.
3. Чего хотят разработчики от ИИ
По мнению Евгения ожидания инженеров такие
- Переложить на AI рутинные операции, например, написание юнит-тестов
- Общаться на естественном языке с последующим уточнением через промпты
- Получить детерминированные результаты от недетерминированного genAI
Интересно, что у Google был whitepaper буквально с таким названием "What Do Developers Want From AI?" - я его разбирал раньше, а потом еще записал эпизод подкаста "Research Insights" вместе с моим коллегой, Колей Бушковым, где мы разбирали этот whitepaper
4. Бизнес-приоритеты
Бизнес хочет сокращения time to market, снижения издержек, а также предсказуемости. Но обычно все упирают на сокращение издержек, когда говорят, что "90% кода будет писаться ИИ". Но часто это не означает увольнение 90% программистов, а увеличение продуктивности существующих команд. Евгений привел пример Дарио Амодея с его тезисами из цитаты выше - а я разбирал это выступление раньше
5. Проблема измерения эффективности
Критически относитесь к цифрам вроде "повышение продуктивности на 55%". Продуктивность - неопределенный термин, зависящий от множества факторов. Пока нет единого способа точно измерить пользу от ИИ-инструментов. Интересно, что я уже пару раз выступал с темой навроде "Зачем заниматься темой developer productivity в большой компании"
6. LLM ≠ Продукт
Использование последней языковой модели не гарантирует успех продукта. UX/UI, правильный промптинг и интеграция в рабочий процесс часто важнее, чем выбор конкретной модели.
7. Правильные метрики
Стоит измерять NPS, CSAT в связке с retention (у SourceCraft от Yandex между 60-70%), cycle time, lead time и влияние на бизнес-метрики. Метрика счастья пользователя - интегральный показатель принятия/отклонения подсказок.
8. Снижение хайпа - это хорошо
За 2023-2024 год интерес к ИИ в некоторых областях упал и это хорошо - разработчики начинают реалистично оценивать возможности и ограничения ИИ-инструментов, что ведет к более эффективному использованию.
9. Будущее: от генерации к агентам
Развитие сейчас идет от генеративных моделей к агентским. Агенты проактивно решают задачи, но пока крайне ненадежны. Следующий этап развития - сделать агентов более надежными и предсказуемыми. Чем глубже интеграция ИИ в инфраструктуру компании, тем больше выигрыш.
Если подводить итоги, то Евгений считает, что AI-помощники однозначно полезны, но важно понимать их ограничения и правильно интегрировать в рабочий процесс, а не гнаться за хайпом.
#AI #Software #Engineering #Architecture #Agents
YouTube
Евгений Колесников — «AI-помощники при работе с кодом. Взгляд в будущее»
ИИ-помощников при работе с кодом становится все больше: могут встречаться yet another LLM-wrapper или отдельные IDE. В докладе рассмотрели, какие инструменты бывают, как измерять качество и определять, что идем в правильном направлении при создании инструментов…
⚡22❤🔥8🌚1
Изучая новости отчественных облаков обратил внимание на ключевые тезисы из дискуссии «Озера данных для конкурентоспобности бизнеса».
1. Компании инвестируют в озера данных сейчас, даже если не видят большого эффекта. Через несколько лет догонять лидеров в этой гонке будет сложно.
2. Мы идем к тому, что компании, которые не используют Data Lakehouse, будут считаться отстающими на Х лет.
3. Для многих компаний работа с большими данными — инвестиция вдолгую. Впереди — выработка методологии для правильной оценки эффекта, который принесут объемы вложенных ресурсов.
4. Перед бизнесом стоит организационный вызов: нужно научить отделы внутри компаний делиться данными и, возможно, идти в сторону отраслевых хранилищ с обезличенными данными.
5. Средний объем корпоративных хранилищ данных перешагнул порог 500 Тб.
6. Подобрать инфраструктуру для работы с большими данными сложно, поскольку ошибки при выборе провайдера могут сильно помешать масштабироваться на долгой дистанции.
К самим тезисам и облачным продуктам вопросов нет - уверен, озёра данных действительно рулят: они хранят большие объёмы информации, даже в формате Iceberg. Но тема-то заявлена - «конкурентоспособность бизнеса».
Подобные посты часто публикуют и Yandex Cloud, и Arenadata. Но такой контент не создаёт ценности - он ориентирован на нетехнических пользователей. Обычно таким читателям неважно, сколько там терабайт, и вряд ли они поймут разницу между lakehouse и data warehouse.
Складывается впечатление, что компании должны внедрять озёра данных просто потому, что «все внедряют». И если вы ещё не внедрили и не мигрировали - то вам, по сути, нечем будет «мериться». Сколько у кого терабайт? Сколько кластеров? Сколько табличек?
Кстати, западные вендоры уже ушли от такого подхода. Они либо делают упор на бизнес-результат и намеренно опускают технические детали, либо наоборот - таргетируют глубоко техническую аудиторию и погружаются в детали. То есть аудиторию чётко сегментируют.
Этот подход хорошо иллюстрирует пример с резюме. Вы можете описать свой опыт через output:
- количество таблиц
- количество пайплайнов
- количество дашбордов
- количество PR
- количество строк кода
- миграция из А в Б
- внедрение А, Б, В
Но в этом мало ценности. Ценность - в outcome, в пользе, которую вы принесли. Написать резюме, в котором будет баланс между технологиями и бизнес-ценностью, - непростая задача. Особенно если его нужно уместить в две страницы.
PS мне нравятся продукты yandex, vk, arenadata, проделана колоссальная работа и созданы отличные решения. Просто улыбнул факт подачи информации о ценности для бизнеса, напомнил мне собеседования и резюме. Всегда хочется рассказать про детали, но они не так важны.
1. Компании инвестируют в озера данных сейчас, даже если не видят большого эффекта. Через несколько лет догонять лидеров в этой гонке будет сложно.
2. Мы идем к тому, что компании, которые не используют Data Lakehouse, будут считаться отстающими на Х лет.
3. Для многих компаний работа с большими данными — инвестиция вдолгую. Впереди — выработка методологии для правильной оценки эффекта, который принесут объемы вложенных ресурсов.
4. Перед бизнесом стоит организационный вызов: нужно научить отделы внутри компаний делиться данными и, возможно, идти в сторону отраслевых хранилищ с обезличенными данными.
5. Средний объем корпоративных хранилищ данных перешагнул порог 500 Тб.
6. Подобрать инфраструктуру для работы с большими данными сложно, поскольку ошибки при выборе провайдера могут сильно помешать масштабироваться на долгой дистанции.
К самим тезисам и облачным продуктам вопросов нет - уверен, озёра данных действительно рулят: они хранят большие объёмы информации, даже в формате Iceberg. Но тема-то заявлена - «конкурентоспособность бизнеса».
Подобные посты часто публикуют и Yandex Cloud, и Arenadata. Но такой контент не создаёт ценности - он ориентирован на нетехнических пользователей. Обычно таким читателям неважно, сколько там терабайт, и вряд ли они поймут разницу между lakehouse и data warehouse.
Складывается впечатление, что компании должны внедрять озёра данных просто потому, что «все внедряют». И если вы ещё не внедрили и не мигрировали - то вам, по сути, нечем будет «мериться». Сколько у кого терабайт? Сколько кластеров? Сколько табличек?
Кстати, западные вендоры уже ушли от такого подхода. Они либо делают упор на бизнес-результат и намеренно опускают технические детали, либо наоборот - таргетируют глубоко техническую аудиторию и погружаются в детали. То есть аудиторию чётко сегментируют.
Этот подход хорошо иллюстрирует пример с резюме. Вы можете описать свой опыт через output:
- количество таблиц
- количество пайплайнов
- количество дашбордов
- количество PR
- количество строк кода
- миграция из А в Б
- внедрение А, Б, В
Но в этом мало ценности. Ценность - в outcome, в пользе, которую вы принесли. Написать резюме, в котором будет баланс между технологиями и бизнес-ценностью, - непростая задача. Особенно если его нужно уместить в две страницы.
PS мне нравятся продукты yandex, vk, arenadata, проделана колоссальная работа и созданы отличные решения. Просто улыбнул факт подачи информации о ценности для бизнеса, напомнил мне собеседования и резюме. Всегда хочется рассказать про детали, но они не так важны.
⚡11❤🔥6💯6🐳2
Все знакомы с понятием Ad-hoc запросов. Обычно мы воспринимаем их негативно, так как они отвлекают, время-то и так мало.
На самом деле, ad-hoc запросы могут бысть источником quick wins, и способом быстро показать impact и завоевать доверие (earn trust).
Ad-hoc — это не бардак. Это VIP-запросы, которые показывают: вам доверяют. Ваша задача - не утонуть, а превратить это в рычаг для влияния.
Вот пример фреймфорка:
1. Принять быстро
Ответ в течение пары минут (или автоответ, если в фокусе) показывает: у нас есть процесс, а не паника.
2. Быстрое фильтрование (2 минуты):
- Это повлияет на $Xk+ или стратегию?
- Нужно на этой неделе для принятия решений?
- Делается за полдня одним аналитиком?
- Если да → делаем. Если нет - в бэклог с пометкой по приоритету.
3. Минимум, но по делу
- Отправляем краткий инсайт, график или SQL - что реально помогает. Повторилось 3 раза? → автоматизация.
📌 Чтобы не сгореть:
- Назначаем on-call-аналитика/инженера (10% времени спринта)
- Не забываем про ротацию и отслеживание нагрузки
- Повторяемые запросы → обучающие материалы или дашборды
Эскалации - через менеджера, не через «договорился в курилке».
На самом деле, ad-hoc запросы могут бысть источником quick wins, и способом быстро показать impact и завоевать доверие (earn trust).
Ad-hoc — это не бардак. Это VIP-запросы, которые показывают: вам доверяют. Ваша задача - не утонуть, а превратить это в рычаг для влияния.
Вот пример фреймфорка:
1. Принять быстро
Ответ в течение пары минут (или автоответ, если в фокусе) показывает: у нас есть процесс, а не паника.
2. Быстрое фильтрование (2 минуты):
- Это повлияет на $Xk+ или стратегию?
- Нужно на этой неделе для принятия решений?
- Делается за полдня одним аналитиком?
- Если да → делаем. Если нет - в бэклог с пометкой по приоритету.
3. Минимум, но по делу
- Отправляем краткий инсайт, график или SQL - что реально помогает. Повторилось 3 раза? → автоматизация.
📌 Чтобы не сгореть:
- Назначаем on-call-аналитика/инженера (10% времени спринта)
- Не забываем про ротацию и отслеживание нагрузки
- Повторяемые запросы → обучающие материалы или дашборды
Эскалации - через менеджера, не через «договорился в курилке».
1💯55❤🔥22🗿4⚡1
Data-driven культура часто выглядит как BI инструмент(ы) с метриками и дашбордами + хранилище данных (хотя уже модно делать Data Lakeuse на 500ТБ 🤔 ).
В идеале культура, основанная на данных, должна включать три ключевых элемента — так называемый 3P framework:
- People - вовлечённые сотрудники и поддержка со стороны руководства.
- Platform - удобные и доступные инструменты (BI-системы, дашборды, ноутбуки, хранилища и т. п.).
- Process - процессы, которые помогают извлекать инсайты и превращать их в действия, с акцентом на качество данных, метрики и бизнес-приоритеты.
В такой культуре важно позволять людям экспериментировать с данными, поощрять стремление к обучению и развитию, задавать бизнес-вопросы, формулировать гипотезы и проверять их.
Способность находить закономерности в данных, предлагать улучшения и отслеживать их влияние на бизнес — одна из ключевых ценностей data-led подхода.
Несколько практик, которые помогают достичь такого уровня зрелости:
🎮 Проведение хакатонов и вовлечение бизнес-пользователей в работу с данными.
🙂 Отправка аналитиков и инженеров "в поля", чтобы на практике понять, как устроен бизнес, как генерируются данные и как аналитические решения влияют на процессы.
⚡️ Временная интеграция аналитиков и инженеров в бизнес-команды для более глубокого погружения в задачи и контекст.
Вообще парадокс, в маленькой компании или стартапе достаточно завести эксельку и вести учет нескольких показателей и вы уже data-driven. А вот в большой корпарации у вас может быть 10 хранилищ, 5 озер, 7 BI, и армия аналитиков и инженеров, и вы нифига не data-driven🤣
В идеале культура, основанная на данных, должна включать три ключевых элемента — так называемый 3P framework:
- People - вовлечённые сотрудники и поддержка со стороны руководства.
- Platform - удобные и доступные инструменты (BI-системы, дашборды, ноутбуки, хранилища и т. п.).
- Process - процессы, которые помогают извлекать инсайты и превращать их в действия, с акцентом на качество данных, метрики и бизнес-приоритеты.
В такой культуре важно позволять людям экспериментировать с данными, поощрять стремление к обучению и развитию, задавать бизнес-вопросы, формулировать гипотезы и проверять их.
Способность находить закономерности в данных, предлагать улучшения и отслеживать их влияние на бизнес — одна из ключевых ценностей data-led подхода.
Несколько практик, которые помогают достичь такого уровня зрелости:
Вообще парадокс, в маленькой компании или стартапе достаточно завести эксельку и вести учет нескольких показателей и вы уже data-driven. А вот в большой корпарации у вас может быть 10 хранилищ, 5 озер, 7 BI, и армия аналитиков и инженеров, и вы нифига не data-driven
Please open Telegram to view this post
VIEW IN TELEGRAM
💯42
Ищете работу на международном рынке?
Тогда канал Connectable Jobs будет полезен для вас. Ребята собирают вакансии в международных стартапах с русскоязычными фаундерами, делятся важной информацией про команды и инвестиции, а также прямыми контактами HR для удобного отклика.
Вот несколько актуальных вакансий таких компаниях:
— Head of Data в Manychat
— Data Engineer в Constructor
— Lead of Engineering в Appodeal
Еще у Connectable Jobs есть отдельный канал для разработчиков и инженеров, где публикуются вакансии только в этой области.
Подписывайтесь и развивайте карьеру в будущем единороге 🚀
Тогда канал Connectable Jobs будет полезен для вас. Ребята собирают вакансии в международных стартапах с русскоязычными фаундерами, делятся важной информацией про команды и инвестиции, а также прямыми контактами HR для удобного отклика.
Вот несколько актуальных вакансий таких компаниях:
— Head of Data в Manychat
— Data Engineer в Constructor
— Lead of Engineering в Appodeal
Еще у Connectable Jobs есть отдельный канал для разработчиков и инженеров, где публикуются вакансии только в этой области.
Подписывайтесь и развивайте карьеру в будущем единороге 🚀
Telegram
Connectable Jobs
Вакансии от 300+ зарубежных компаний с русскоговорящими фаундерами или командами. Наши читатели уже получили офферы в InDrive, Revolut, Wallet, JetBrains и др. 💙
Разместить вакансию: https://forms.gle/K5KiBsaqo6Tp2sje8
Q&A: @connectable_jobs_team
Разместить вакансию: https://forms.gle/K5KiBsaqo6Tp2sje8
Q&A: @connectable_jobs_team
❤🔥6