Чувак - директор аналитики в Yelp (это такой сервис рекомендаций мест). У него открыто 5 вакансий. Под постом 141+ комментарий, аля возьми меня, я уже откликнулся. Интересно другое, если быстро пролистать список комментариев, то получиться 120+ это ребята из Индии. Получается, что они захватили весь рынок аналитики в Северной Америке? Почему людей из СНГ вообще нет? Наверно это связано с чем-то? Недавно товарищ, кстати Стас, которого я одного из первых обучил BI и он устроился в Ламоду, устроился в Краков в компанию на позицию SAP manager, и его менеджер и менеджер над менеджером, тоже из Индии. То есть тренд на лицо?
Linkedin
Eric Weber on LinkedIn: #data #datascience | 141 comments
I'm thrilled to share that we are *hiring* at Yelp in data science, data analytics and product management. These 5 roles are high impact and high visibility... 141 comments on LinkedIn
Forwarded from Data Coffee
Свежий эпизод подкаста “Data Coffee” про ETL и Apache Airflow с замечательной Диной Сафиной из mail-ru уже доступен к прослушиванию в ваших подкастоприемниках!
#datacoffee #podcast #data #подкаст #данные
https://anchor.fm/data-coffee/episodes/ETL--e12vknj
#datacoffee #podcast #data #подкаст #данные
https://anchor.fm/data-coffee/episodes/ETL--e12vknj
Spotify for Creators
4. ETL-инструменты (гостевой) by Data Coffee
Тема выпуска “ETL-инструменты”
В гостях у подкаста `Data Coffee` ведущий разработчик игрового хранилища mail.ru и сооснователь русскоязычного сообщества airflow - Дина Сафина (Facebook, Telegram)
Shownotes:
02:05 Два пути IT — либо кофе, либо алкоголь
04:09…
В гостях у подкаста `Data Coffee` ведущий разработчик игрового хранилища mail.ru и сооснователь русскоязычного сообщества airflow - Дина Сафина (Facebook, Telegram)
Shownotes:
02:05 Два пути IT — либо кофе, либо алкоголь
04:09…
Forwarded from Data Coffee
Хей-хей, доброе утро, ребята! Надеюсь вы вчера перевернули календарь 🗓 и достаточно нагляделись на костры рябин🔥. Го слушать свежий эпизод подкаста Data Coffee!
У нас в гостях был Паша Финкельштейн из JB, поговорили о Spark, ноутбуках (и их проблемах), и немножко затронули другие data-инструменты.
#datacoffee #data #podcast #данные #подкаст
https://anchor.fm/data-coffee/episodes/15--Spark--Pandas--Scala--Zeppelin-e16r13v
У нас в гостях был Паша Финкельштейн из JB, поговорили о Spark, ноутбуках (и их проблемах), и немножко затронули другие data-инструменты.
#datacoffee #data #podcast #данные #подкаст
https://anchor.fm/data-coffee/episodes/15--Spark--Pandas--Scala--Zeppelin-e16r13v
Spotify for Creators
15. Spark, Pandas, Scala и Zeppelin (гостевой) by Data Coffee
Тема выпуска “Spark, Pandas, Scala и Zeppelin”
В гостях у подкаста `Data Coffee` developer advocate из JetBrains - Паша Финкельштейн (Twitter, LinkedIn, Telegram)
Подкаст `Data Coffee` — информационный партнёр конференции SmartData 2021. SmartData — это большая…
В гостях у подкаста `Data Coffee` developer advocate из JetBrains - Паша Финкельштейн (Twitter, LinkedIn, Telegram)
Подкаст `Data Coffee` — информационный партнёр конференции SmartData 2021. SmartData — это большая…
Forwarded from Data Coffee
Доброго утречка, уважаемые слушатели! Подкаст “Data Coffee”🎙 спешит порадовать вас свежим эпизодом.
Поговорили в этот раз про open source BI-инструмент — Apache Superset. Не пропустите😉
#datacoffee #data #podcast #данные #подкаст
https://anchor.fm/data-coffee/episodes/18--Apache-Superset-e17q7ol
Поговорили в этот раз про open source BI-инструмент — Apache Superset. Не пропустите😉
#datacoffee #data #podcast #данные #подкаст
https://anchor.fm/data-coffee/episodes/18--Apache-Superset-e17q7ol
Spotify for Podcasters
18. Apache Superset by Data Coffee
Тема выпуска "Apache Superset"!
Подкаст `Data Coffee` — информационный партнёр конференции SmartData 2021. SmartData — это большая техническая конференция по Data Engineering. Десятки докладов, воркшопов, Q&A-сессий — первые доклады и имена спикеров уже…
Подкаст `Data Coffee` — информационный партнёр конференции SmartData 2021. SmartData — это большая техническая конференция по Data Engineering. Десятки докладов, воркшопов, Q&A-сессий — первые доклады и имена спикеров уже…
Мы добавили в slack новый канал #data_news_from_the_world которые будет вас сам кормить новостями Databricks, snowflake, Tableau и другими. А вы просто выбирайте, что вам нравится.
Forwarded from Data Coffee
Ура, сегодня воскресенье!
Кто-то отдыхает и попивает раф с банановым молоком, кто-то с утра выпил двойной эспрессо и работает над свалившейся внезапно задачей. Ну а ещё кто-то не может усидеть на месте и думает — куда же ему развиваться в целом в IT и в области данных в частности. Один из таких людей обратился к нам с просьбой помочь.
Наш постоянный слушатель пришёл за советом в области образования, а это вопрос очень серьёзный. Мы не могли просто так в паре слов упомянуть об этом в новостном выпуске, от образования ведь зависит будущее человека! Мы решили помочь нашему слушателю и сотням других людей, которые тоже сейчас сомневаются и не могут выбрать дальнейший образовательный путь, для чего обратились к нескольким data-экспертам и попросили их ответить на поставленный вопрос.
Представляем вашему вниманию специальный бонусный эпизод подкаста Data Coffee🎙и приглашаем к прослушиванию!
#datacoffee #data #podcast #данные #подкаст
https://anchor.fm/data-coffee/episodes/23-bonus-e197nft
Кто-то отдыхает и попивает раф с банановым молоком, кто-то с утра выпил двойной эспрессо и работает над свалившейся внезапно задачей. Ну а ещё кто-то не может усидеть на месте и думает — куда же ему развиваться в целом в IT и в области данных в частности. Один из таких людей обратился к нам с просьбой помочь.
Наш постоянный слушатель пришёл за советом в области образования, а это вопрос очень серьёзный. Мы не могли просто так в паре слов упомянуть об этом в новостном выпуске, от образования ведь зависит будущее человека! Мы решили помочь нашему слушателю и сотням других людей, которые тоже сейчас сомневаются и не могут выбрать дальнейший образовательный путь, для чего обратились к нескольким data-экспертам и попросили их ответить на поставленный вопрос.
Представляем вашему вниманию специальный бонусный эпизод подкаста Data Coffee🎙и приглашаем к прослушиванию!
#datacoffee #data #podcast #данные #подкаст
https://anchor.fm/data-coffee/episodes/23-bonus-e197nft
Spotify for Podcasters
23 (bonus). Куда развиваться? by Data Coffee
Бонусный эпизод подкаста Data Coffee - "Куда развиваться?"
Получили очень серьёзный вопрос от нашего постоянного слушателя, и не могли просто взять и упомянуть о нём вскользь в одном из новостных выпусков. Приложили максимум доступных ресурсов и попросили…
Получили очень серьёзный вопрос от нашего постоянного слушателя, и не могли просто взять и упомянуть о нём вскользь в одном из новостных выпусков. Приложили максимум доступных ресурсов и попросили…
Forwarded from Data Coffee
▶️3️⃣8️⃣
Ещё один эпизод в копилку “технических”. Мы добрались до Snowflake и послушали правильного для этой темы человека! В гостях подкаста Data Coffee🎙 был Антон Ревяко — автор канала “Сингулярности не будет”, фаундер holistic.dev, dwh.dev и parsers.dev, заводила в snowflake чатах и канале со snowflake новостями.
Затронули следующие темы:
— что у Snowflake “под капотом”🏗
— что такое data marketplace🛍
— masking policies🎭
— зачем нужны статические анализаторы🔍
— а также история двух кофеен и другое
Слушайте подкаст🎧, пейте кофе☕️, и конечно же наслаждайтесь☀️!
#datacoffee #data #podcast #данные #подкаст #news
https://anchor.fm/data-coffee/episodes/38--Snowflake-Data-Cloud-e1dued5
Ещё один эпизод в копилку “технических”. Мы добрались до Snowflake и послушали правильного для этой темы человека! В гостях подкаста Data Coffee🎙 был Антон Ревяко — автор канала “Сингулярности не будет”, фаундер holistic.dev, dwh.dev и parsers.dev, заводила в snowflake чатах и канале со snowflake новостями.
Затронули следующие темы:
— что у Snowflake “под капотом”🏗
— что такое data marketplace🛍
— masking policies🎭
— зачем нужны статические анализаторы🔍
— а также история двух кофеен и другое
Слушайте подкаст🎧, пейте кофе☕️, и конечно же наслаждайтесь☀️!
#datacoffee #data #podcast #данные #подкаст #news
https://anchor.fm/data-coffee/episodes/38--Snowflake-Data-Cloud-e1dued5
Spotify for Creators
38. Snowflake Data Cloud by Data Coffee
Тема выпуска Snowflake Data Cloud
В гостях у подкаста `Data Coffee` автор канала Сингулярности не будет, фаундер holistic.dev, dwh.dev и parsers.dev, заводила в snowflake чатах (ru, en) и канале со snowflake новостями — Антон Ревяко
Shownotes:
02:04 Две…
В гостях у подкаста `Data Coffee` автор канала Сингулярности не будет, фаундер holistic.dev, dwh.dev и parsers.dev, заводила в snowflake чатах (ru, en) и канале со snowflake новостями — Антон Ревяко
Shownotes:
02:04 Две…
🔥14👍5
State of the art - замечательный Landing Page, судя по-всему сделан Airbyte. Не знаю насколько можно ему верить, но зарплата в 600к в наши дни для "честных" инженеров, мне кажется, редкость, даже в долине. Хотя после массовых увольнений акции Meta, Microsoft, Amazon пошли вверх. В Канаде, по моим подсчетам, можно за год заработать 600к+ канадских, но как было сказано в видео выше, про стоимость жизни в Канаде, очень обидно отдавать 50% на налоги, при этом содержать бомжей и дармоедов и на дом мечты, да и просто на дом, все равно не хватит. Не будем о грустном, лучше про опрос.
В нем поучаствовало 886 человек. Я думаю, что это определенная аудитория, которая использует популярные решения, то есть высокая вероятность bias.
Сразу видно вывод - Insight 1: Airbyte and Fivetran are clear leaders for Data Ingestion layer. Ну, понятно же, за счёт счет банкет. Fivetran использую, работает Окей.
Как же без dbt - Insight 2: dbt has most positive sentiment for Data Transformation, but pandas is actually most used. Вообще сравнивать dbt и pandas, ну такое. Наверно где-то потерялся Excel, тем более dbt for Excel существует.
Insight 3: Snowflake and BigQuery clearly at the top for Data Warehouses; Azure Synapse lagging behind badly - я даже больше сажу, Snowflake явно лидирует. А Synapse уже заменили на Fabric. И Microsoft не будет тягаться в категории хранилищ, у них платформа, у других даже шансов нет. Обычно сравнивают Databricks vs Snowflake, ну тут решили не палить конкурента.
Insight 4: For Data Orchestration, most people are still using self hosted Airflow, but Dagster is coming up the ranks - действительно Airflow очень популярен. Про dagster не знаю, а вотPrefect используем. Да и с Airflow open source очень много проблем, никакой стабильности.
Insight 5: For Business Intelligence, the giants Looker and Tableau are still ruling the roost, but there is also significant churn from Tableau to the newer set of solutions - Power BI явно не популярен среди тех, кто использует dbt, snowflake, aiflow. Оно и понятно, это совсем другая аудитория.
Insight 6: For Data Quality, Great Expectations and Monte Carlo are leading the pack, but more people have not yet tried or explored the tools than have - мне тоже очень нравится MonteCarlo. Не раз уже спасал своими алертами. Там свои алгоритмы, которые собирают различную статистику по использованию, загрузки таблиц. Действительно полезная вещь. Но можно тоже самое и бесплатно сделать.
Insight 7: For Reverse ETL, Hightouch and Census are neck and neck, but the vast majority of the market is still up for grabs. Использую только Hightouch. До сих пор не очень понял ценность этих игрушек дорогих, все можно сделать через API, но время сокращает.
Insight 8: For Data Catalogs, DataHub, Atlan and Amundsen are leading for now, but the vast majority of the market is also up for grabs - Я сейчас работаю с Alation. И в другом месте добавляем DataHub. Все каталоги бесполезные без кураторства.
Еще из интересного список podcasts&youtube channels&data communities.
Чего не хватает:
- Решений по стримингу и возможно use cases по стримингу
- предпочтения по языку для работы с данными, не у всех же Python
- соотношения code vs SQL для работы с данными
- вообще кто-то среди них использует облачный hadoop?
- DevOps для аналитики (terraform bicep, cloud formation), git, CI/CD
В нем поучаствовало 886 человек. Я думаю, что это определенная аудитория, которая использует популярные решения, то есть высокая вероятность bias.
Сразу видно вывод - Insight 1: Airbyte and Fivetran are clear leaders for Data Ingestion layer. Ну, понятно же, за счёт счет банкет. Fivetran использую, работает Окей.
Как же без dbt - Insight 2: dbt has most positive sentiment for Data Transformation, but pandas is actually most used. Вообще сравнивать dbt и pandas, ну такое. Наверно где-то потерялся Excel, тем более dbt for Excel существует.
Insight 3: Snowflake and BigQuery clearly at the top for Data Warehouses; Azure Synapse lagging behind badly - я даже больше сажу, Snowflake явно лидирует. А Synapse уже заменили на Fabric. И Microsoft не будет тягаться в категории хранилищ, у них платформа, у других даже шансов нет. Обычно сравнивают Databricks vs Snowflake, ну тут решили не палить конкурента.
Insight 4: For Data Orchestration, most people are still using self hosted Airflow, but Dagster is coming up the ranks - действительно Airflow очень популярен. Про dagster не знаю, а вотPrefect используем. Да и с Airflow open source очень много проблем, никакой стабильности.
Insight 5: For Business Intelligence, the giants Looker and Tableau are still ruling the roost, but there is also significant churn from Tableau to the newer set of solutions - Power BI явно не популярен среди тех, кто использует dbt, snowflake, aiflow. Оно и понятно, это совсем другая аудитория.
Insight 6: For Data Quality, Great Expectations and Monte Carlo are leading the pack, but more people have not yet tried or explored the tools than have - мне тоже очень нравится MonteCarlo. Не раз уже спасал своими алертами. Там свои алгоритмы, которые собирают различную статистику по использованию, загрузки таблиц. Действительно полезная вещь. Но можно тоже самое и бесплатно сделать.
Insight 7: For Reverse ETL, Hightouch and Census are neck and neck, but the vast majority of the market is still up for grabs. Использую только Hightouch. До сих пор не очень понял ценность этих игрушек дорогих, все можно сделать через API, но время сокращает.
Insight 8: For Data Catalogs, DataHub, Atlan and Amundsen are leading for now, but the vast majority of the market is also up for grabs - Я сейчас работаю с Alation. И в другом месте добавляем DataHub. Все каталоги бесполезные без кураторства.
Еще из интересного список podcasts&youtube channels&data communities.
Чего не хватает:
- Решений по стримингу и возможно use cases по стримингу
- предпочтения по языку для работы с данными, не у всех же Python
- соотношения code vs SQL для работы с данными
- вообще кто-то среди них использует облачный hadoop?
- DevOps для аналитики (terraform bicep, cloud formation), git, CI/CD
State of data 2023
❤🔥26🗿3
Forwarded from Книжный куб (Alexander Polomodov)
Data Pipelines Pocket Reference
Прочитал по дороге из Новосибирска в Москву простую книгу про построение конвейеров данных для дата инженеров. Я высоко оценил краткость и практичность книги, а также то, что James Densmore, автор книги, имеет большой практический опыт построения дата инфраструктуры, что и делал в HubSpot. В итоге, я написал краткий обзор этой книги в своем блоге.
#Data #Databases #Engineering #SoftwareArchitecture #Software #SoftwareDevelopment #Management
Прочитал по дороге из Новосибирска в Москву простую книгу про построение конвейеров данных для дата инженеров. Я высоко оценил краткость и практичность книги, а также то, что James Densmore, автор книги, имеет большой практический опыт построения дата инфраструктуры, что и делал в HubSpot. В итоге, я написал краткий обзор этой книги в своем блоге.
#Data #Databases #Engineering #SoftwareArchitecture #Software #SoftwareDevelopment #Management
❤🔥39🦄3🍾2😭1
Forwarded from Книжный куб (Alexander Polomodov)
Apache Kafka. Потоковая обработка и анализ данныз (Kafka: The Definitive Guide)
Все привыкли, что я читаю книги достаточно быстро, но вот с этой книгой получилось не так - пока я читал перевод первого издания вышло второе:) Первое издание вышло осенью 2017 году, а второе в конце 2021. Первое издание состоит из 11 глав
1. Meet Kafka - в этой главе мы встречаемся с главным героем и знакомимся с базовыми понятиями обмена сообщениями, дальше мы узнаем про основы Kafka: сообщения и пакеты, схемы сообщений, топики и партиции, producers и consumers, а также как выглядят сами брокеры и как они объединяются в кластера.
2. Installing Kafka - здесь авторы рассказывают про установку Kafka и на что обращать внимание при выборе железа (интересно, что во втором издании авторы делают больший акцент на переезде в облака)
3. Kafka Producers: Writing Messages to Kafka - здесь обсуждаются вопросы записи в Kafka (само название говорит о том, что эта система ориентирована на писателей:) ). Здесь говорится про конфигурацию producers, сериализацию и работу с партициями
4. Kafka Consumers: Reading Data from Kafka - здесь идет речь про то, как читать из Kafka и управлять оффсетом через разные варианты коммитов: автокоммит, асинхронный и синхронный коммит
5. Kafka Internals - эта часть интересна тем, кто любит заглядывать под копот. Тут идет речь про то, как работает сам кластер, как реализуется членство в кластере, что такое контроллер, как выглядит репликация, а дальше обработка запросов (на запись и на чтение), а дальше как работает физический уровень
6. Reliable Data Delivery - здесь обсуждаются гарантии доставки и как их обеспечить за счет совместной работы producer, Kafka и consumers. Здесь как раз можно почитать про семантику at least once и exactly once в Kafka
7. Building Data Pipelines - здесь кратко рассказывается про ETL пайплайны и работу с Kafka Connect (подробнее на эту тему рекомендую почитать Data Pipelines Pocket Reference)
8. Cross-Cluster Data Mirroring - про репликацию данных между кластерами и что лучше стягивать данные с удаленного кластера, чем их пушить в удаленный кластер (если есть такая возможность)
9. Administering Kafka - вопросы администрирования Kafka, здесь зарыто достаточно сложности, но эту часть определенно стоит почитать, если у вас Kafka в production:)
10. Monitoring Kafka - здесь обсуждаются вопросы мониторинга и они по большей части относятся к мониторингу java приложений и дальше использованию JMX для получения данных для мониторинга из процессов Kafka
11. Stream Processing - это интересный раздел про потоковую обработку, который подан очень сжато, но позволяет понять область применимости Kafka Streams API
На этом книга оканчивается, но есть смысл сразу пойти и изучить второе издание, чтобы оценить накопившиеся за пять лет различия:))
#Data #Databases #Engineering #SoftwareArchitecture #Software #SoftwareDevelopment #Management #Queue
Все привыкли, что я читаю книги достаточно быстро, но вот с этой книгой получилось не так - пока я читал перевод первого издания вышло второе:) Первое издание вышло осенью 2017 году, а второе в конце 2021. Первое издание состоит из 11 глав
1. Meet Kafka - в этой главе мы встречаемся с главным героем и знакомимся с базовыми понятиями обмена сообщениями, дальше мы узнаем про основы Kafka: сообщения и пакеты, схемы сообщений, топики и партиции, producers и consumers, а также как выглядят сами брокеры и как они объединяются в кластера.
2. Installing Kafka - здесь авторы рассказывают про установку Kafka и на что обращать внимание при выборе железа (интересно, что во втором издании авторы делают больший акцент на переезде в облака)
3. Kafka Producers: Writing Messages to Kafka - здесь обсуждаются вопросы записи в Kafka (само название говорит о том, что эта система ориентирована на писателей:) ). Здесь говорится про конфигурацию producers, сериализацию и работу с партициями
4. Kafka Consumers: Reading Data from Kafka - здесь идет речь про то, как читать из Kafka и управлять оффсетом через разные варианты коммитов: автокоммит, асинхронный и синхронный коммит
5. Kafka Internals - эта часть интересна тем, кто любит заглядывать под копот. Тут идет речь про то, как работает сам кластер, как реализуется членство в кластере, что такое контроллер, как выглядит репликация, а дальше обработка запросов (на запись и на чтение), а дальше как работает физический уровень
6. Reliable Data Delivery - здесь обсуждаются гарантии доставки и как их обеспечить за счет совместной работы producer, Kafka и consumers. Здесь как раз можно почитать про семантику at least once и exactly once в Kafka
7. Building Data Pipelines - здесь кратко рассказывается про ETL пайплайны и работу с Kafka Connect (подробнее на эту тему рекомендую почитать Data Pipelines Pocket Reference)
8. Cross-Cluster Data Mirroring - про репликацию данных между кластерами и что лучше стягивать данные с удаленного кластера, чем их пушить в удаленный кластер (если есть такая возможность)
9. Administering Kafka - вопросы администрирования Kafka, здесь зарыто достаточно сложности, но эту часть определенно стоит почитать, если у вас Kafka в production:)
10. Monitoring Kafka - здесь обсуждаются вопросы мониторинга и они по большей части относятся к мониторингу java приложений и дальше использованию JMX для получения данных для мониторинга из процессов Kafka
11. Stream Processing - это интересный раздел про потоковую обработку, который подан очень сжато, но позволяет понять область применимости Kafka Streams API
На этом книга оканчивается, но есть смысл сразу пойти и изучить второе издание, чтобы оценить накопившиеся за пять лет различия:))
#Data #Databases #Engineering #SoftwareArchitecture #Software #SoftwareDevelopment #Management #Queue
❤🔥18👨💻3🍌1
Forwarded from Книжный куб (Alexander Polomodov)
Why Most Data Projects Fail and How to Avoid It • Jesse Anderson • YOW! 2022
Интересное выступление про data проекты от Jesse Anderson, автора книги "Data Teams". Автор говорит о ключевых вопросах, которые стоит задать при старте проектов
- Who - Автор говорит про правильный состав команды для data проектов. Собственно автор про это написал целую книгу и он говорит про баланс data scientists, data engineers, operations.
- What - Автор задает вопрос про бизнес значение того data продукта/проекта, которым вы занимаетесь. Автор говорит о том, что фразы "Мы делаем AI" от CEO не хватает для data strategy:) В общем, надо понимать как ваш проект принесет ценность для бизнеса. Причем помимо стратегии нужен план и его execution. Особенно во времена, когда tech компании занимаются сокращениями в направлениях, что не приносят деньги.
- When - Автор говорит о том, а когда эта бизнес ценность будет создана. Нужен проект с понятными временными границами, чтобы он не был слишокм долгим, чтобы быть отмененным где-то посердине и не слишком коротким, обещающим золотые горы, которым на самом деле будет невозможно соответствовать.
- Where - И вот мы наконец-то добрались до первого технического вопроса, а где собственно эти данные будут обрабатываться, как будет выглядеть архитектура решения. И тут для ответа тоже не хватает фразу "Мы будем использовать технологию XYZ вендора ABC". Проблема в том, что вендор может пообещать все что угодно, но это обещание не факт, что выполнимо, более того, не факт, что оно оптимально для заказчика:)
- How - Здесь речь идет про план выполнения и про фокусировку на приоритетных направлениях. Хотя часто такие data проекты пытаются успеть сразу везде, а дальше теряют эффективность на context switches и застывают на месте, переставая генерировать какую-либо ценность кроме рассказов о наступлении AI:) Автор интересно рассказывает про то, как бизнес заказчикам перпендикулярно на конкретные технические решения, но важно какую бизнес-ценность они могут получить по результатам выполнения плана.
- Why - Автор задает вопрос, а почему же эти данные обладают ценностью? Просто отгружать данные и гонять ETL/ELT пайпланы не достаточно. Важно понимать как использование данных в новых проектах позволит обеспечить нужный ROI (return on investments), причем автор говорит о том, что он ищет 10x ROI для data проектов
Напоследок автор говорит о том, что для AI и data проектов важно понимать, что такие проекты сложны и требуют навыков, людей и организационных изменений для своего успеха. И это достаточно сложно и не все способны приносить пользу в таких проектах. Конкретно, автор рассказывает про то, что если запускать data и AI проекты внутри DWH команд, то такие проекты обречены на неудачу ("the team where good data projects go to die). Это обусловлено не тем, что DWH технологии плохие, а потому, что это скорее проблема людей ("people problem"), которые очень специфично разбираются с проблемами и очень специфичным образом выстраивают свою работу. В общем, автор говорит о том, что эта не та команда, которая должна отвечать за data и AI проекты нового типа.
В конце автор рассказывает о том, как можно получить помощь с такими проектами за счет аутсорсинга (если у компании нет своей инженерной команды и культуры), за счет привлечения консультантов (правда, автор говорит о том, что консультанты по менеджменту типа BCG, Bain, Mckinsey зачастую не обладают компетенциями для помощи в таких data проектах). В конце автор упоминает свою книгу "Data teams", которую он написал для менеджеров, которым предстоит запускать data и AI проекты.
P.S.
Мне автор продал свою книгу, поэтому я добавлю ее в свой long list на чтение:)
#Management #Leadership #Data #DataScience #AI #Engineering #Software #SoftwareDevelopment #ML
Интересное выступление про data проекты от Jesse Anderson, автора книги "Data Teams". Автор говорит о ключевых вопросах, которые стоит задать при старте проектов
- Who - Автор говорит про правильный состав команды для data проектов. Собственно автор про это написал целую книгу и он говорит про баланс data scientists, data engineers, operations.
- What - Автор задает вопрос про бизнес значение того data продукта/проекта, которым вы занимаетесь. Автор говорит о том, что фразы "Мы делаем AI" от CEO не хватает для data strategy:) В общем, надо понимать как ваш проект принесет ценность для бизнеса. Причем помимо стратегии нужен план и его execution. Особенно во времена, когда tech компании занимаются сокращениями в направлениях, что не приносят деньги.
- When - Автор говорит о том, а когда эта бизнес ценность будет создана. Нужен проект с понятными временными границами, чтобы он не был слишокм долгим, чтобы быть отмененным где-то посердине и не слишком коротким, обещающим золотые горы, которым на самом деле будет невозможно соответствовать.
- Where - И вот мы наконец-то добрались до первого технического вопроса, а где собственно эти данные будут обрабатываться, как будет выглядеть архитектура решения. И тут для ответа тоже не хватает фразу "Мы будем использовать технологию XYZ вендора ABC". Проблема в том, что вендор может пообещать все что угодно, но это обещание не факт, что выполнимо, более того, не факт, что оно оптимально для заказчика:)
- How - Здесь речь идет про план выполнения и про фокусировку на приоритетных направлениях. Хотя часто такие data проекты пытаются успеть сразу везде, а дальше теряют эффективность на context switches и застывают на месте, переставая генерировать какую-либо ценность кроме рассказов о наступлении AI:) Автор интересно рассказывает про то, как бизнес заказчикам перпендикулярно на конкретные технические решения, но важно какую бизнес-ценность они могут получить по результатам выполнения плана.
- Why - Автор задает вопрос, а почему же эти данные обладают ценностью? Просто отгружать данные и гонять ETL/ELT пайпланы не достаточно. Важно понимать как использование данных в новых проектах позволит обеспечить нужный ROI (return on investments), причем автор говорит о том, что он ищет 10x ROI для data проектов
Напоследок автор говорит о том, что для AI и data проектов важно понимать, что такие проекты сложны и требуют навыков, людей и организационных изменений для своего успеха. И это достаточно сложно и не все способны приносить пользу в таких проектах. Конкретно, автор рассказывает про то, что если запускать data и AI проекты внутри DWH команд, то такие проекты обречены на неудачу ("the team where good data projects go to die). Это обусловлено не тем, что DWH технологии плохие, а потому, что это скорее проблема людей ("people problem"), которые очень специфично разбираются с проблемами и очень специфичным образом выстраивают свою работу. В общем, автор говорит о том, что эта не та команда, которая должна отвечать за data и AI проекты нового типа.
В конце автор рассказывает о том, как можно получить помощь с такими проектами за счет аутсорсинга (если у компании нет своей инженерной команды и культуры), за счет привлечения консультантов (правда, автор говорит о том, что консультанты по менеджменту типа BCG, Bain, Mckinsey зачастую не обладают компетенциями для помощи в таких data проектах). В конце автор упоминает свою книгу "Data teams", которую он написал для менеджеров, которым предстоит запускать data и AI проекты.
P.S.
Мне автор продал свою книгу, поэтому я добавлю ее в свой long list на чтение:)
#Management #Leadership #Data #DataScience #AI #Engineering #Software #SoftwareDevelopment #ML
YouTube
Why Most Data Projects Fail and How to Avoid It • Jesse Anderson • YOW! 2022
This presentation was recorded at YOW! 2022. #GOTOcon #YOW
https://yowcon.com
Jesse Anderson - Managing director of Big Data Institute, host of The Data Dream Team podcast @jessetanderson
RESOURCES
https://twitter.com/jessetanderson
https://www.jesse-anderson.com…
https://yowcon.com
Jesse Anderson - Managing director of Big Data Institute, host of The Data Dream Team podcast @jessetanderson
RESOURCES
https://twitter.com/jessetanderson
https://www.jesse-anderson.com…
❤🔥22⚡6
Forwarded from Книжный куб (Alexander Polomodov)
dbt — ядро современной платформы данных - Евгений Ермаков - SmartData 2023 (Рубрика #Architecture)
Интересный доклад Евгения Ермакова про построение дата платформы в toloka.ai, которая, получив независимость от Yandex, вынуждена была переезжать на новые технологии. В итоге, выбор пал на databricks, dbt, airflow и tableau. Автор рассказывает о том, почему был сделан такой выбор и как в итоге это все работает.
Основные моменты следующие:
- Сама toloka - это система для краудсорсинга, куда заказчики приходят с задачками навроде разметить данные, а с другой стороны на платформе зарегестрированы люди, которые их выполняют
- Архитектура базируются на трех китах:
-- Data lakehouse
-- Процессы в соответствии с подходом data mesh
-- Современный технологический стек
- До переезда на новые технологии ребята использовали много своего, часть из которого уже есть в opensource: YTsaurus, datalens
- После переезда выбрали новые технологии и dbt стал ядром системы, закрывая функциональность: data quality, data catalog/ data observability, batch processing (вместе со spark), orchestration (вместе с airflow)
- Изначально dbt (data building tool) нужен был в качестве удобного инструмента для transformation шага в ETL/ELT
- Интересно, что в концепции компании dbt есть мнение и относительно ролей, где помимо стандартных data engineers и data analysts появляется еще analytics engineer. В итоге, data engineers - это те, кто делают так, чтобы data платформа работала эффективно, data analysts ищут инсайты в данных и помогают их эффективно использовать, а вот analytics engineers - это ребята, что-то среднее между другими двумя + хорошо укладывается в концепцию data mesh, где нет централизованной дата-команды, а есть дата-команды по доменам
- Основой dbt-проекта является dbt model. Модель состоит из файла с описанием логики (.sql или .py файл) и файла с описанием конфигурации. В .sql файле есть запрос на формирование объекта, другие модели используются через ref() или source() + используется jinja шаблонизация. В .py файле возвращаем dataframe с рассчитанными данными, есть доступ ко всем возможностям pyspark + другие модели тоже используются через ref() или source()
- Материализацию запроса dbt берет на себя и есть разные стратегии, из которых самая интересная incremental
- Настройки хранятся в dbt_project.yaml и profiles.yaml
- dbt поддерживает большое количество баз данных, например, postgres, mysql, clickhouse, ...
- dbt - это консольная утилита, например, при запуске dbt build происходит сборка всех зависимостей между моделями, а также компиляция python/sql запросов и запись в manifest.json
- Команда dbt run запускает скомпилированные запросы, где запуск можно настроить по разному, но интересно запускать по графу
- Кстати, dbt умеет генерировать документацию командой dbt docs generate и дальше можно посмотреть на lineage данных
- Также мы можем писать тесты в том же месте, где мы описываем модели, а дальше запускать их при помощи dbt tests. Например, можем проверять unique или not null на поле, а также если хотим relations между моделями
- У dbt есть еще много возможностей, но про них стоит почитать самостоятельно:)
- Дальше автор рассказывает как сделать data mesh на уровне dbt + airflow. Автор рассматривает варианты вида:
-- Монолитный - один dbt проект на всю компанию
-- Микросервисный - отдельные dbt проекты на каждый домен
-- Layered - отдельные dbt проекты по уровням
-- Смешанный - анархия, где проекты создаются кто как хочет
Выбрали монолитный подход и получили аля монорепо под data mesh, в котором живут все. Обусловлено это было тем, что при микросервисном подходе ломались все связки между моделями (до 1.6 не могли называть модели одинаково в разных проектах + была проблема с импортом друг друга, так как это приводило к циклическим зависимостям).
Из интересного еще сделали конвертор графа исполнения dbt в airflow формат, чтобы запускать DAG из airflow.
В итоге, ребята реализовали свой подход к data mesh при помощи open source инструмнетов и вся схема выглядит достаточно стройно.
#Data #Datamesh #DWH #Processes #Management
Интересный доклад Евгения Ермакова про построение дата платформы в toloka.ai, которая, получив независимость от Yandex, вынуждена была переезжать на новые технологии. В итоге, выбор пал на databricks, dbt, airflow и tableau. Автор рассказывает о том, почему был сделан такой выбор и как в итоге это все работает.
Основные моменты следующие:
- Сама toloka - это система для краудсорсинга, куда заказчики приходят с задачками навроде разметить данные, а с другой стороны на платформе зарегестрированы люди, которые их выполняют
- Архитектура базируются на трех китах:
-- Data lakehouse
-- Процессы в соответствии с подходом data mesh
-- Современный технологический стек
- До переезда на новые технологии ребята использовали много своего, часть из которого уже есть в opensource: YTsaurus, datalens
- После переезда выбрали новые технологии и dbt стал ядром системы, закрывая функциональность: data quality, data catalog/ data observability, batch processing (вместе со spark), orchestration (вместе с airflow)
- Изначально dbt (data building tool) нужен был в качестве удобного инструмента для transformation шага в ETL/ELT
- Интересно, что в концепции компании dbt есть мнение и относительно ролей, где помимо стандартных data engineers и data analysts появляется еще analytics engineer. В итоге, data engineers - это те, кто делают так, чтобы data платформа работала эффективно, data analysts ищут инсайты в данных и помогают их эффективно использовать, а вот analytics engineers - это ребята, что-то среднее между другими двумя + хорошо укладывается в концепцию data mesh, где нет централизованной дата-команды, а есть дата-команды по доменам
- Основой dbt-проекта является dbt model. Модель состоит из файла с описанием логики (.sql или .py файл) и файла с описанием конфигурации. В .sql файле есть запрос на формирование объекта, другие модели используются через ref() или source() + используется jinja шаблонизация. В .py файле возвращаем dataframe с рассчитанными данными, есть доступ ко всем возможностям pyspark + другие модели тоже используются через ref() или source()
- Материализацию запроса dbt берет на себя и есть разные стратегии, из которых самая интересная incremental
- Настройки хранятся в dbt_project.yaml и profiles.yaml
- dbt поддерживает большое количество баз данных, например, postgres, mysql, clickhouse, ...
- dbt - это консольная утилита, например, при запуске dbt build происходит сборка всех зависимостей между моделями, а также компиляция python/sql запросов и запись в manifest.json
- Команда dbt run запускает скомпилированные запросы, где запуск можно настроить по разному, но интересно запускать по графу
- Кстати, dbt умеет генерировать документацию командой dbt docs generate и дальше можно посмотреть на lineage данных
- Также мы можем писать тесты в том же месте, где мы описываем модели, а дальше запускать их при помощи dbt tests. Например, можем проверять unique или not null на поле, а также если хотим relations между моделями
- У dbt есть еще много возможностей, но про них стоит почитать самостоятельно:)
- Дальше автор рассказывает как сделать data mesh на уровне dbt + airflow. Автор рассматривает варианты вида:
-- Монолитный - один dbt проект на всю компанию
-- Микросервисный - отдельные dbt проекты на каждый домен
-- Layered - отдельные dbt проекты по уровням
-- Смешанный - анархия, где проекты создаются кто как хочет
Выбрали монолитный подход и получили аля монорепо под data mesh, в котором живут все. Обусловлено это было тем, что при микросервисном подходе ломались все связки между моделями (до 1.6 не могли называть модели одинаково в разных проектах + была проблема с импортом друг друга, так как это приводило к циклическим зависимостям).
Из интересного еще сделали конвертор графа исполнения dbt в airflow формат, чтобы запускать DAG из airflow.
В итоге, ребята реализовали свой подход к data mesh при помощи open source инструмнетов и вся схема выглядит достаточно стройно.
#Data #Datamesh #DWH #Processes #Management
YouTube
Евгений Ермаков — dbt — ядро современной платформы данных
Подробнее о конференции SmartData: https://jrg.su/aTWU2K
— —
dbt — один из самых быстро набирающих популярность инструментов в сфере построения платформ и хранилищ данных. Сочетание простоты и функциональности этого инструмента подкупила и команду Toloka.ai…
— —
dbt — один из самых быстро набирающих популярность инструментов в сфере построения платформ и хранилищ данных. Сочетание простоты и функциональности этого инструмента подкупила и команду Toloka.ai…
⚡40❤🔥16💯4😭1
Forwarded from Книжный куб (Alexander Polomodov)
Code of Leadership #22 - Интервью с Дмитрием Аношиным про data engineering (Рубрика #Data)
В этом выпуске ко мне пришел в гости крутой гость, Дмитрий Аношин. Дима является экспертом в data engineering, ведет канал @rockyourdata, также Дима почти 10 лет работал западных Bigtech компаниях. Кстати, выпуск доступен в виде подкаста и в Яндекс Музыке.
Мы обсудили следующие темы:
- Как Дима входил в IT порядка 15 лет назад
- Как он развивал свои навыки как дата инженер
- Как он уехал в Канаду и адаптировался там
- Как развивалась карьера Димы в Amazon, Microsoft и что он вынес из этого опыта
- Как Дима стал создателем обучающих проектов datalearn, surfalytics, а также как ему удалось написать целую гору книг
- Как находить мотивацию для роста и развития
Если говорить подробнее про Дмитрия, то он уже больше 15 лет занимается аналитикой и инжинирингом данных, а 10 последних лет проработал в Северной Америке. Из них 5 лет в Амазоне, где работал в нескольких командах, включая Alexa AI (в Бостоне) и Customer Behaviour Analytics (в Сиэтле). Поучаствовал в действительно инновационных проектах, где драйвером являются данные. Видел и Big Data и Machine Learning в действии в масштабе крупнейшей компании мира. После Амазона работал 4 года в Microsoft Xbox и Microsoft Azure Data&AI. Активно принимал участие в развитии Microsoft продуктов для аналитики - Synapse, Fabric, Azure Databricks.
Теперь, Дмитрий помогает создавать инновационные аналитические решения, дата команды и модернизировать устаревшие решения через свою компанию rockyourdata.cloud и глобально готовит инженеров и аналитиков через свое сообщество Surfalytics.com (на английском), до этого несколько лет развивал проект Datalearn.ru, на котором делился фундаментальными знаниями и помогал бесплатно всем желающим войти в ИТ, знания там все еще актуальны.
Дмитрий написал несколько книг по аналитике и преподает несколько лет Облачные Вычисления (Cloud Computing) в партнерстве с Microsoft в Университете Виктории.
Еще из интересных проектов:
- Создал онлайн выставку писем CEO про увольнения в крупных компаниях - https://www.layoffmemos.com/
- Совместно с Московским Зоопарком и Вконтакте организовал группу по наблюдению за популяцией пеликанов и экомониторинга с использованием AI - https://www.scifly.ai/
Из последнего, Дмитрий создает главный Российский портал Дата Инженеръ посвященный карьере дата инженера, куда он планирует добавить road map для вакансий Инженера Данных, Аналитика и BI разработчика и ссылки на лучшие бесплатные ресурсы: книги, тренинги, курсы, видео, телеграмм каналы, и многое друго, что поможет понять, кто такой иженер данных и как таким стать, преимущественно на русском языке.
#Database #Architecure #Software #Data #SystemDesign #Management
В этом выпуске ко мне пришел в гости крутой гость, Дмитрий Аношин. Дима является экспертом в data engineering, ведет канал @rockyourdata, также Дима почти 10 лет работал западных Bigtech компаниях. Кстати, выпуск доступен в виде подкаста и в Яндекс Музыке.
Мы обсудили следующие темы:
- Как Дима входил в IT порядка 15 лет назад
- Как он развивал свои навыки как дата инженер
- Как он уехал в Канаду и адаптировался там
- Как развивалась карьера Димы в Amazon, Microsoft и что он вынес из этого опыта
- Как Дима стал создателем обучающих проектов datalearn, surfalytics, а также как ему удалось написать целую гору книг
- Как находить мотивацию для роста и развития
Если говорить подробнее про Дмитрия, то он уже больше 15 лет занимается аналитикой и инжинирингом данных, а 10 последних лет проработал в Северной Америке. Из них 5 лет в Амазоне, где работал в нескольких командах, включая Alexa AI (в Бостоне) и Customer Behaviour Analytics (в Сиэтле). Поучаствовал в действительно инновационных проектах, где драйвером являются данные. Видел и Big Data и Machine Learning в действии в масштабе крупнейшей компании мира. После Амазона работал 4 года в Microsoft Xbox и Microsoft Azure Data&AI. Активно принимал участие в развитии Microsoft продуктов для аналитики - Synapse, Fabric, Azure Databricks.
Теперь, Дмитрий помогает создавать инновационные аналитические решения, дата команды и модернизировать устаревшие решения через свою компанию rockyourdata.cloud и глобально готовит инженеров и аналитиков через свое сообщество Surfalytics.com (на английском), до этого несколько лет развивал проект Datalearn.ru, на котором делился фундаментальными знаниями и помогал бесплатно всем желающим войти в ИТ, знания там все еще актуальны.
Дмитрий написал несколько книг по аналитике и преподает несколько лет Облачные Вычисления (Cloud Computing) в партнерстве с Microsoft в Университете Виктории.
Еще из интересных проектов:
- Создал онлайн выставку писем CEO про увольнения в крупных компаниях - https://www.layoffmemos.com/
- Совместно с Московским Зоопарком и Вконтакте организовал группу по наблюдению за популяцией пеликанов и экомониторинга с использованием AI - https://www.scifly.ai/
Из последнего, Дмитрий создает главный Российский портал Дата Инженеръ посвященный карьере дата инженера, куда он планирует добавить road map для вакансий Инженера Данных, Аналитика и BI разработчика и ссылки на лучшие бесплатные ресурсы: книги, тренинги, курсы, видео, телеграмм каналы, и многое друго, что поможет понять, кто такой иженер данных и как таким стать, преимущественно на русском языке.
#Database #Architecure #Software #Data #SystemDesign #Management
LayoffMemos
Home
This webpage archives CEO memos regarding layoffs in the tech industry in 2022-2024. It offers a transparent view of how companies dealt with scaling down their operations, the rationale behind their decisions, and the impacts on their workforce. It provides…
2⚡39❤🔥18🍾4🎄1🗿1
Forwarded from Книжный куб (Alexander Polomodov)
What Goes Around Comes Around... And Around... Part I (Рубрика #Data)
Интересная обзорная статья 2024 года от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Оба автора являются корефееями в области баз данных: Michael создал Postgres и еще кучу других баз, а Andrew - исследователь в области баз данных, профессор и преподаватель, лекции которого доступны на Youtube.
Сама статья продолжает статью 2005 года "What Goes Around Comes Around", которую написали Michael Stonebraker и Joseph M. Hellerstein. Они проанализировали историю развития баз данных за 35 лет и предсказали что модные тогда объектные и xml базы данных не смогут обойти по реляционную модель.
С тех пор прошло порядка 20 лет и пришло время сделать новый обзор мира баз данных. Для этого авторы решили посмотреть на это с двух сторон:
- Модели данных и языки запросов
- Архитектура баз данных
Начнем с разбора существующих data models и query languages:
1. MapReduce-системы
Изначально они были разработаны в Google для обработки больших объемов данных (веб-краулер). MapReduce не использует фиксированную модель данных или язык запросов, они выполняют пользовательские операции map и reduce. Открытой версией MapReduce стал Hadoop, который сейчас не очень популярен из-за низкой производительности и заменяется более современными платформами аля Apache Spark или просто СУБД.
2. Key-Value хранилища
У них максимально простая модель данных: пары "ключ-значение". Они используются для задач кэширования (Memcached, Redis) или хранения сессий. Возможности в модели ограничены - нет индексов или операций join, что усложняет применение для сложных приложений. Многие KV-хранилища (например, DynamoDB, Aerospike) эволюционировали в более функциональные системы с поддержкой частичной структуры (JSON). Среди популярных встроенных k/v решений популярны LevelDB и RocksDB.
3. Документные базы данных
Они хранят данные в виде документов (например, в формате JSON). Изначально получили популярность благодаря простоте интеграции с веб-приложениями (например, MongoDB), предлагая подход schema on read. Интресно, что к 2020-м годам большинство документных СУБД добавили SQL-подобные интерфейсы и поддержку ACID-транзакций, а иногда и schema on write.
4. Column-Family базы данных (wide columns)
По-факту, это упрощенная версия документной модели с ограниченной вложенностью. Начиналось все с Google BigTable, а в миру есть open source реализация в виде Apache Cassandra. Изначально в Cassandra не было вторичных индексов и транзакций. Но по мере развития они появились (но там все очень интересно)
5. Поисковые движки
Они нужны для полнотекстового поиска (Elasticsearch, Apache Solr). Поддерживают индексацию текста, но ограничены в транзакционных возможностях. Реляционные СУБД также предлагают встроенный полнотекстовый поиск, но с менее удобным API.
6. Базы данных для массивов
Они предназначены для работы с многомерными массивами, например, научные данные (SciDB, Rasdaman). Ниша ограничена специфическими областями применения: геоданные, изучение генома.
7. Векторные базы данных
Используются для хранения эмбеддингов из машинного обучения (Pinecone, Milvus). Основное применение — поиск ближайших соседей в высокоразмерных пространствах. Реляционные СУБД уже начали добавлять поддержку векторных индексов.
8. Графовые базы данных
Моделируют данные как графы (узлы и связи). Примеры: Neo4j для OLTP-графов, TigerGraph для аналитики. Большинство графовых задач можно реализовать на реляционных СУБД с помощью SQL/PGQ (новый стандарт SQL:2023).
Общие выводы
- Большинство нереляционных систем либо занимают нишевые рынки, либо постепенно сближаются с реляционными СУБД.
- SQL остается основным языком запросов благодаря своей гибкости и поддержке современных приложений.
- Реляционные СУБД продолжают развиваться и интегрировать новые возможности (например, JSON, векторные индексы), что делает специализированные системы менее конкурентоспособными.
В продолжении поста будет про архитектуру баз данных.
#Data #Architecture #Software #DistributedSystems
Интересная обзорная статья 2024 года от Michael Stonebraker и Andrew Pavlo про развитие баз данных за последние 20 лет. Оба автора являются корефееями в области баз данных: Michael создал Postgres и еще кучу других баз, а Andrew - исследователь в области баз данных, профессор и преподаватель, лекции которого доступны на Youtube.
Сама статья продолжает статью 2005 года "What Goes Around Comes Around", которую написали Michael Stonebraker и Joseph M. Hellerstein. Они проанализировали историю развития баз данных за 35 лет и предсказали что модные тогда объектные и xml базы данных не смогут обойти по реляционную модель.
С тех пор прошло порядка 20 лет и пришло время сделать новый обзор мира баз данных. Для этого авторы решили посмотреть на это с двух сторон:
- Модели данных и языки запросов
- Архитектура баз данных
Начнем с разбора существующих data models и query languages:
1. MapReduce-системы
Изначально они были разработаны в Google для обработки больших объемов данных (веб-краулер). MapReduce не использует фиксированную модель данных или язык запросов, они выполняют пользовательские операции map и reduce. Открытой версией MapReduce стал Hadoop, который сейчас не очень популярен из-за низкой производительности и заменяется более современными платформами аля Apache Spark или просто СУБД.
2. Key-Value хранилища
У них максимально простая модель данных: пары "ключ-значение". Они используются для задач кэширования (Memcached, Redis) или хранения сессий. Возможности в модели ограничены - нет индексов или операций join, что усложняет применение для сложных приложений. Многие KV-хранилища (например, DynamoDB, Aerospike) эволюционировали в более функциональные системы с поддержкой частичной структуры (JSON). Среди популярных встроенных k/v решений популярны LevelDB и RocksDB.
3. Документные базы данных
Они хранят данные в виде документов (например, в формате JSON). Изначально получили популярность благодаря простоте интеграции с веб-приложениями (например, MongoDB), предлагая подход schema on read. Интресно, что к 2020-м годам большинство документных СУБД добавили SQL-подобные интерфейсы и поддержку ACID-транзакций, а иногда и schema on write.
4. Column-Family базы данных (wide columns)
По-факту, это упрощенная версия документной модели с ограниченной вложенностью. Начиналось все с Google BigTable, а в миру есть open source реализация в виде Apache Cassandra. Изначально в Cassandra не было вторичных индексов и транзакций. Но по мере развития они появились (но там все очень интересно)
5. Поисковые движки
Они нужны для полнотекстового поиска (Elasticsearch, Apache Solr). Поддерживают индексацию текста, но ограничены в транзакционных возможностях. Реляционные СУБД также предлагают встроенный полнотекстовый поиск, но с менее удобным API.
6. Базы данных для массивов
Они предназначены для работы с многомерными массивами, например, научные данные (SciDB, Rasdaman). Ниша ограничена специфическими областями применения: геоданные, изучение генома.
7. Векторные базы данных
Используются для хранения эмбеддингов из машинного обучения (Pinecone, Milvus). Основное применение — поиск ближайших соседей в высокоразмерных пространствах. Реляционные СУБД уже начали добавлять поддержку векторных индексов.
8. Графовые базы данных
Моделируют данные как графы (узлы и связи). Примеры: Neo4j для OLTP-графов, TigerGraph для аналитики. Большинство графовых задач можно реализовать на реляционных СУБД с помощью SQL/PGQ (новый стандарт SQL:2023).
Общие выводы
- Большинство нереляционных систем либо занимают нишевые рынки, либо постепенно сближаются с реляционными СУБД.
- SQL остается основным языком запросов благодаря своей гибкости и поддержке современных приложений.
- Реляционные СУБД продолжают развиваться и интегрировать новые возможности (например, JSON, векторные индексы), что делает специализированные системы менее конкурентоспособными.
В продолжении поста будет про архитектуру баз данных.
#Data #Architecture #Software #DistributedSystems
❤🔥35⚡6🐳3🎄1
Forwarded from Книжный куб (Alexander Polomodov)
Research Insights Made Simple #6 - Interview with Nikolay Golov about data platforms (Рубрика #Data)
И, продолжая тему систем хранения данных, я решил сегодня поделиться новым выпуском подкаста про инсайты. В этот раз ко мне в гости пришел Николай Голов для того, чтобы обсудить то, как строить дата платформы в 2025 году:) Коля исполняет роль head of data engineering at ManyChat, а до этого он был head of data platform в Авито. Коля знает все о том как построить OLAP и OLTP системы, интенсивно работающие с данными. Выпуск доступен в виде подкаста на Ya Music и Podster.fm
За время подкаста мы обсудили темы
- Как развивалась карьера Коли в разных компаниях и как он стал преподавать базы данных параллельно с основной работой
- Как можно строить платформы данных (централизованно, гибридно и децентрализованно)
- Как выглядят принципы федерализации данных (аля data mesh) в теории
- Во что этот подход превращается на практике
- Как строить дата платформы в стартапах, средних, а также крупных компаниях в 2025 году
- Что не так с классическими базами данных (Postgres и иже с ним)
- Что не так с MPP базами данных (Vertica, Greenplum, ClickHouse, ...)
- Как data mesh превращается в data mash и как цепочки дата продуктов работают на практике
- Как выделять базовый домен данных, чтобы уменьшить длину цепочек дата продуктов
- Почему облачные аналитические базы так быстры: колоночное хранение + разделение storage и compute
- Что такое medalion architecture
- Куда дальше будут развиваться технологии обработки данных и почему нельзя полагаться на старые подходы и ограничения
Дополнительные материалы
- Статьи из периода работы в Avito "Vertica+Anchor Modeling = запусти рост своей грибницы"
- Статья из периода работы в Manychat: 1 и 2
- Запись "Data Modeling Meetup Munich: From Data Vault to Anchor Modeling with Nikolai Golov"
- Запись "DataVault / Anchor Modeling / Николай Голов"
- Научная статья "Golov N., Ronnback L., Big Data Normalization for Massively Parallel Processing Databases" //Computer Standards & Interfaces, 09-May-2017, https://doi.org/10.1016/j.csi.2017.01.009
- Научная статья "Golov N., Filatov A., Bruskin S.,Efficient Exact Algorithm for Count Distinct Problem", Computer Algebra in Scientific Computing, July 2019
#Data #Datamesh #Processes #Management #Architecture
И, продолжая тему систем хранения данных, я решил сегодня поделиться новым выпуском подкаста про инсайты. В этот раз ко мне в гости пришел Николай Голов для того, чтобы обсудить то, как строить дата платформы в 2025 году:) Коля исполняет роль head of data engineering at ManyChat, а до этого он был head of data platform в Авито. Коля знает все о том как построить OLAP и OLTP системы, интенсивно работающие с данными. Выпуск доступен в виде подкаста на Ya Music и Podster.fm
За время подкаста мы обсудили темы
- Как развивалась карьера Коли в разных компаниях и как он стал преподавать базы данных параллельно с основной работой
- Как можно строить платформы данных (централизованно, гибридно и децентрализованно)
- Как выглядят принципы федерализации данных (аля data mesh) в теории
- Во что этот подход превращается на практике
- Как строить дата платформы в стартапах, средних, а также крупных компаниях в 2025 году
- Что не так с классическими базами данных (Postgres и иже с ним)
- Что не так с MPP базами данных (Vertica, Greenplum, ClickHouse, ...)
- Как data mesh превращается в data mash и как цепочки дата продуктов работают на практике
- Как выделять базовый домен данных, чтобы уменьшить длину цепочек дата продуктов
- Почему облачные аналитические базы так быстры: колоночное хранение + разделение storage и compute
- Что такое medalion architecture
- Куда дальше будут развиваться технологии обработки данных и почему нельзя полагаться на старые подходы и ограничения
Дополнительные материалы
- Статьи из периода работы в Avito "Vertica+Anchor Modeling = запусти рост своей грибницы"
- Статья из периода работы в Manychat: 1 и 2
- Запись "Data Modeling Meetup Munich: From Data Vault to Anchor Modeling with Nikolai Golov"
- Запись "DataVault / Anchor Modeling / Николай Голов"
- Научная статья "Golov N., Ronnback L., Big Data Normalization for Massively Parallel Processing Databases" //Computer Standards & Interfaces, 09-May-2017, https://doi.org/10.1016/j.csi.2017.01.009
- Научная статья "Golov N., Filatov A., Bruskin S.,Efficient Exact Algorithm for Count Distinct Problem", Computer Algebra in Scientific Computing, July 2019
#Data #Datamesh #Processes #Management #Architecture
YouTube
Research Insights Made Simple #6 - Interview with Nikolay Golov about data platforms
В этом выпуске подкаста про инсайты ко мне в гости пришел Николай Голов для того, чтобы обсудить то, как строить дата платформы в 2025 году:) Коля исполняет роль head of data engineering at ManyChat, а до этого он был head of data platform в Авито. Коля знает…
❤🔥35⚡9🙉3 3
Forwarded from Маргарита Репина: Disrupt & Scale
Как построить data-driven культуру, а не просто BI, в который никто не заходит?
🟣 В прошлом посте я писала:
данные ≠ актив, если вы с ними ничего не делаете.
Но чтобы начали делать, нужна не просто BI-система.
Нужна культура.
И как и всё важное в бизнесе, она начинается с головы.
Я вообще выросла в аналитической среде.
Когда я начинала карьеру в консалтинге, ни Big Data, ни ChatGPT ещё не было,
но мышление
«данные → вывод → решение»
у нас тренировали так, как будто от этого зависела судьба миллионов (и иногда — правда зависела).
🟣 Этот майндсет остался со мной до сих пор.
И я вижу: чем дальше, тем чаще компании говорят, что они аналитичные,
но при этом продолжают принимать решения на летучках в духе «ну по ощущениям».
А BI-системы — просто красивые панели, на которые никто не заходит.
Вот 5 элементов, которые реально помогают построить культуру решений на данных.
1️⃣ Всё начинается с фаундера и C-Level:
Если CEO говорит «я чувствую, что надо пушить эту фичу» и не дает задачу проверить гипотезу — всё, приехали.
Команда будет делать то же самое.
Data-driven культура начинается с того, что лидер принимает решения на данных.
✸ Он задаёт вопросы.
✸ Просит цифры.
✸ Не ведёт обсуждения в стиле «мне кажется».
2️⃣ Без инструментария — ничего не взлетит:
Не надо думать, что культура вырастет на энтузиазме.
Если у людей нет доступных и понятных дешбордов —
никакая data-driven культура не сложится.
Метрики должны быть:
✸ Привязаны к бизнес-целям
✸ Регулярно обновляемы
✸ С возможностью копать вглубь, а не просто «доход-расход»
Иначе всё закончится в Excel на 17 вкладок у одного аналитика.
3️⃣ Люди должны понимать, что их перформанс считают по данным:
Не метафорически, а буквально.
✸ Если в компании бонус зависит от бизнес-результатов —
значит, сотрудник должен видеть свои метрики.
✸ Если продуктовая команда оценивается по росту retention — она должна уметь его мерить, а не угадывать.
Когда оценка и рост человека связаны с метриками —
у него появляется привычка на них смотреть.
4️⃣ Нормализуйте «сначала смотрим → потом решаем»:
Я обожаю команды, в которых принято начинать обсуждение с цифр.
Прямо нормализовать это:
✸ Хотите запустить фичу? Где данные?
✸ Хочешь отключить воронку? Что на неё влияет?
✸ Думаешь, надо пушить что-то в маркетинге? Где проверка гипотез?
Это становится привычкой.
А привычка → поведение → культура.
5️⃣ Культуру нужно растить через обучение:
Если вы строите команду посильнее или у вас уже есть масштаб, то работа с данными = отдельная компетенция.
🟣 Что можно делать:
✸ Обучение по интерпретации ключевых метрик
✸ Мини-тренинги по юнитке, ретеншну, воронкам
✸ Кейсы «что сказали данные и к чему это привело»
✸ Отправлять на курсы или собирать внутренний чек-лист
Если компания маленькая — то хотя бы:
✸ Привычка делиться аналитикой
✸ 1 инсайт недели в чат
✸ Простые дешборды для всей команды
🟣 Пример
Плохой сценарий:
✸ «У нас упала конверсия с лендинга!!!»
✸«Паника!!!»
Хороший:
✸ «Конверсия упала, но трафик вырос в 2 раза, потому что залили TikTok с нерелевантной аудиторией. А CTR по email — остался стабильным».
Это и есть мышление на данных.
Контекст, динамика, гипотеза, вывод.
В итоге, data-driven культура — это про то, чтобы каждый в команде реально начал думать через данные, а не через «мне кажется» или «ну, так всегда делали».
Чтобы цифры стали не страшным отчётом, а привычкой — первым делом смотреть на них, задавать вопросы и искать ответы.
А как часто вы в команде обращаетесь к данным и стараетесь ли вы формировать привычку в команде? Пишите в комментариях 🚀.
#Data_driven
данные ≠ актив, если вы с ними ничего не делаете.
Но чтобы начали делать, нужна не просто BI-система.
Нужна культура.
И как и всё важное в бизнесе, она начинается с головы.
Я вообще выросла в аналитической среде.
Когда я начинала карьеру в консалтинге, ни Big Data, ни ChatGPT ещё не было,
но мышление
«данные → вывод → решение»
у нас тренировали так, как будто от этого зависела судьба миллионов (и иногда — правда зависела).
И я вижу: чем дальше, тем чаще компании говорят, что они аналитичные,
но при этом продолжают принимать решения на летучках в духе «ну по ощущениям».
А BI-системы — просто красивые панели, на которые никто не заходит.
Вот 5 элементов, которые реально помогают построить культуру решений на данных.
1️⃣ Всё начинается с фаундера и C-Level:
Если CEO говорит «я чувствую, что надо пушить эту фичу» и не дает задачу проверить гипотезу — всё, приехали.
Команда будет делать то же самое.
Data-driven культура начинается с того, что лидер принимает решения на данных.
✸ Он задаёт вопросы.
✸ Просит цифры.
✸ Не ведёт обсуждения в стиле «мне кажется».
2️⃣ Без инструментария — ничего не взлетит:
Не надо думать, что культура вырастет на энтузиазме.
Если у людей нет доступных и понятных дешбордов —
никакая data-driven культура не сложится.
Метрики должны быть:
✸ Привязаны к бизнес-целям
✸ Регулярно обновляемы
✸ С возможностью копать вглубь, а не просто «доход-расход»
Иначе всё закончится в Excel на 17 вкладок у одного аналитика.
3️⃣ Люди должны понимать, что их перформанс считают по данным:
Не метафорически, а буквально.
✸ Если в компании бонус зависит от бизнес-результатов —
значит, сотрудник должен видеть свои метрики.
✸ Если продуктовая команда оценивается по росту retention — она должна уметь его мерить, а не угадывать.
Когда оценка и рост человека связаны с метриками —
у него появляется привычка на них смотреть.
4️⃣ Нормализуйте «сначала смотрим → потом решаем»:
Я обожаю команды, в которых принято начинать обсуждение с цифр.
Прямо нормализовать это:
✸ Хотите запустить фичу? Где данные?
✸ Хочешь отключить воронку? Что на неё влияет?
✸ Думаешь, надо пушить что-то в маркетинге? Где проверка гипотез?
Это становится привычкой.
А привычка → поведение → культура.
5️⃣ Культуру нужно растить через обучение:
Если вы строите команду посильнее или у вас уже есть масштаб, то работа с данными = отдельная компетенция.
✸ Обучение по интерпретации ключевых метрик
✸ Мини-тренинги по юнитке, ретеншну, воронкам
✸ Кейсы «что сказали данные и к чему это привело»
✸ Отправлять на курсы или собирать внутренний чек-лист
Если компания маленькая — то хотя бы:
✸ Привычка делиться аналитикой
✸ 1 инсайт недели в чат
✸ Простые дешборды для всей команды
Плохой сценарий:
✸ «У нас упала конверсия с лендинга!!!»
✸«Паника!!!»
Хороший:
✸ «Конверсия упала, но трафик вырос в 2 раза, потому что залили TikTok с нерелевантной аудиторией. А CTR по email — остался стабильным».
Это и есть мышление на данных.
Контекст, динамика, гипотеза, вывод.
В итоге, data-driven культура — это про то, чтобы каждый в команде реально начал думать через данные, а не через «мне кажется» или «ну, так всегда делали».
Чтобы цифры стали не страшным отчётом, а привычкой — первым делом смотреть на них, задавать вопросы и искать ответы.
А как часто вы в команде обращаетесь к данным и стараетесь ли вы формировать привычку в команде? Пишите в комментариях 🚀.
#Data_driven
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥41💯14⚡4
Forwarded from Книжный куб (Alexander Polomodov)
Краткий обзор платформы данных Т-Банка (Рубрика #Data)
Прочитал интересную статью от коллег про про нашу data platform. Если обобщать достаточно длинную статью, то можно отметить, что платформа данных Т-Банка эволюционировала более 18 лет, следуя общеотраслевым трендам. Компания постепенно отходила от классических концепций хранилищ данных по Инмону и Кимбеллу в сторону Data Lake, а затем — к современным Lakehouse-архитектурам. Платформа сейчас обслуживает более 17 тысяч пользователей и обрабатывает свыше 144 млн запросов в месяц, что требует постоянного развития масштабируемости и производительности. Текущая архитектура включает 19 ключевых систем, которые обеспечивают полный жизненный цикл работы с данными — от сбора до визуализации и обеспечения безопасности. Вот как они сгруппированны
1. Сбор и транспортировка данных
- Data Replication: BODS (legacy) и Chrono для пакетной и потоковой репликации
- Event Sourcing: SDP (Streaming Data Transfer Platform) на основе принципов Data Mesh
- Reverse ETL: Spheradian для возврата данных в операционные системы с латентностью до 100 мс
2. Хранение данных
- Data Warehouse: GreenPlum как основная СУБД (15 кластеров, 1,7 ПБ данных)
- LakeHouse: Spark/Trino + S3 с несколькими вычислительными движками
- Real-Time Analytics: ClickHouse для быстрой аналитики на больших таблицах
3. Обработка и трансформация
- Streaming Processing: Unicorn (на Apache Flink) и NiFi
- Workflow Management: TEDI (на Apache Airflow) и Moebius для оркестрации
- Analytics Tools: Proteus (на Apache Superset) для дашбордов и Helicopter для совместной работы
4. Управление данными
- Data Discovery: Data Detective для поиска и каталогизации
- Data Governance: Data Contracts для управления поставками данных
- Data Observability: DQ Tools для контроля качества и Data Incident Management
- Data Security: SLH для управления доступом к чувствительным данным
Если хочется узнать больше, то можно почитать статью и позадавать вопросы в комментариях.
#Data #Database #Architecture #Software #Engineering #PlatformEngineering
Прочитал интересную статью от коллег про про нашу data platform. Если обобщать достаточно длинную статью, то можно отметить, что платформа данных Т-Банка эволюционировала более 18 лет, следуя общеотраслевым трендам. Компания постепенно отходила от классических концепций хранилищ данных по Инмону и Кимбеллу в сторону Data Lake, а затем — к современным Lakehouse-архитектурам. Платформа сейчас обслуживает более 17 тысяч пользователей и обрабатывает свыше 144 млн запросов в месяц, что требует постоянного развития масштабируемости и производительности. Текущая архитектура включает 19 ключевых систем, которые обеспечивают полный жизненный цикл работы с данными — от сбора до визуализации и обеспечения безопасности. Вот как они сгруппированны
1. Сбор и транспортировка данных
- Data Replication: BODS (legacy) и Chrono для пакетной и потоковой репликации
- Event Sourcing: SDP (Streaming Data Transfer Platform) на основе принципов Data Mesh
- Reverse ETL: Spheradian для возврата данных в операционные системы с латентностью до 100 мс
2. Хранение данных
- Data Warehouse: GreenPlum как основная СУБД (15 кластеров, 1,7 ПБ данных)
- LakeHouse: Spark/Trino + S3 с несколькими вычислительными движками
- Real-Time Analytics: ClickHouse для быстрой аналитики на больших таблицах
3. Обработка и трансформация
- Streaming Processing: Unicorn (на Apache Flink) и NiFi
- Workflow Management: TEDI (на Apache Airflow) и Moebius для оркестрации
- Analytics Tools: Proteus (на Apache Superset) для дашбордов и Helicopter для совместной работы
4. Управление данными
- Data Discovery: Data Detective для поиска и каталогизации
- Data Governance: Data Contracts для управления поставками данных
- Data Observability: DQ Tools для контроля качества и Data Incident Management
- Data Security: SLH для управления доступом к чувствительным данным
Если хочется узнать больше, то можно почитать статью и позадавать вопросы в комментариях.
#Data #Database #Architecture #Software #Engineering #PlatformEngineering
Хабр
Краткий обзор платформы данных Т-Банка
Привет, Хабр! Меня зовут Дима Пичугин, и уже семь лет я занимаюсь различными компонентами T Data Platform. Эта статья — результат внутреннего аудита наших инструментов, но я подумал, что она может...