1) Мы хотим видеть просто абсолютное кол-во пользователей?
2) Если пользователей изменил пол (про это как то была дискуссия в телеге, про пример об неизменных dimension как пол клиента), но это было в прошлом, теперь все бывает, и разработчик должен быть готов использовать Slowly Change Dimensions, и хотя бы согласовать, что делать с изменением. Можно просто перезаписать (Type 1) или написать, что раньше пол-то был другой (Type 2). Реальные проблемы западных инженеров!
3) А еще вопрос, интересный, если пользователь удалился из backend, он же ведь все равно остался в хранилище данных и его может надо пометить как IS_DELETED. А для этого нам уже придется сравнивать полный snapshot и текущею базу и находить удаленных клиентов.
4) И возможно, мы хотим видеть историю роста, вчера было 100 клиентов, а сегодня 110, то есть нам надо делать SNAPSHOTS раз в день.

Казалось бы такая простая задача, а сколько возможностей. Самое интересное, что практически во всех организациях, где есть хранилище данных это делают. Часто терминология разная, но идея остается прежней, и ей уже лет 30 если не больше. И для этого не нужно знать ни python, ни Hadoop, ни streaming. Просто SQL и пару приемов, как данные сделать полезными для конечного потребителя.

Поэтому прежде чем получать сертификаты dbt, snowflake, Databricks и тп, попробуйте на локально базе разобраться с этими вещами и потом будет легче делать все тоже самое но уже на modern data stack за хорошую денюшку.

Читать полностью…

Николай Валиотти из @leftjoin ежегодно проводит независимое исследование онлайн-курсов по аналитике.

Гарантия трудоустройства, новая профессия в кратчайшие сроки, высокая зарплата и успешная жизнь после прохождения курсов — так ли все прекрасно, как обещают в популярных онлайн-школах?

Так что, если вы не так давно проходили курсы или осваивали профессию аналитика в онлайн-школе, пройдите опрос и напишите свое мнение. Пожалуй, тот самый случай, когда оно искренне важно для всех.

Будет отличный вариант рассказать все хорошее или плохое про курсы, и тот случай когда можно указать Data Learn (бесплатный курс на русском - от Excel до Spark и BigData) или Surfalytics (бесплатный курс на английском, где за основу я взял data learn но улучшил).

А еще за прохождение опроса можно получить подборку бесплатных материалов на русском и английском языках про дата-аналитику, SQL и не только.

🔜 ссылка на опрос.

P.S. Ответы принимаются до 19 сентября включительно, поэтому не откладывайте это дело в долгий ящик.

P.P.S. А еще мы обсудили с Колей о подкасте, где обсудим вопрос развитие карьеры в сторону создания своего консалтинга, сложность service business, масштабирование, плюсы и минусы и вообще Коля расскажет свою история о создании успешной международной компании. Уверен будет много интересных тем подискутировать.

Читать полностью…

Недавно попалась статья Hh.ru назвал российские компании с самой высокой зарплатой курьеров. Зарплаты курьеров до 250т рублей в Москве это круто. Мне кажется в среднем BI разработчик получает до 200х тысяч. Получается отличная работа на свежем воздухе и не нужно сидеть за компьютером.

Я кстати работал курьером несколько лет, так как ничего другого не мог найти в 11м классе и на первых курсах университета. Сначала я работал в тур фирме, а потом развозил платежи от 1С конторы. И уже тогда я делегировал часть заказов своему дедушке. Правда деньги были смешные, но самый крутой навык это ориентация на местности и карте (раньше не было gps и навигаторов), а была книжка с картой Москвы. И заодно очень хорошо знал Москву.

Может есть ниша онлайн курсов курьеров и insights как совмещать 2-3 работы доставки и outsource своих заказов?!

Читать полностью…

Пример типичной организации в Северной Америке и расходов на data-инструменты. Компания на 1000+ человек.

Команда данных состоит почти из 20 человек, и структура примерно следующая:
- Director Data Engineering (подчиняется VP Engineering)
- Manager Data Engineering (Pipelines) — команда занимается интеграцией данных (загрузка данных в Staging).
- Manager Data Engineering (Data Warehouse) — команда занимается созданием хранилища данных поверх Staging, то есть моделированием данных, использует dbt и применяет бизнес-логику, чтобы создавать корпоративную модель данных и рассчитывать бизнес-показатели. Команда — смесь Data Engineering и Analytics Engineering.
- Manager Data Enablement — команда представляет собой смесь Analytics Engineering и BI-разработчиков, делает дашборды в Tableau/Looker и, по необходимости, дорабатывает модели в dbt (кустарным способом, далеким от лучших практик DE).

Инструменты, которые используются:
- Snowflake — $100k в месяц только за compute.
- Airflow — оркестрация, open source, хостится на AWS ECS.
- dbt core — SQL-трансформации, open source, запускается на AWS ECS.
- Alation — $170k в год, дата-каталог, документация по показателям. Идея была внедрить Data Governance, единый портал для бизнес-пользователей, но фактически затея провалилась.
- Looker — $120k в год, конкурирует с Tableau (Enterprise-лицензия, такая же безлимитная по пользователям, но за дорого), и поэтому Looker долго не продержится.
- Monte Carlo — $140k в год, отличный инструмент для отслеживания Data Observability, качества данных, часто выручает, когда даже dbt tests ничего не видят. Но честно говоря, дорого — это где-то 8-10% от стоимости Snowflake.
- Hightouch — $30k в год, интеграция с Salesforce, Marketo и другими инструментами. Можно условно бесплатно сделать то же самое через Python+Docker, но по опыту с такими решениями из подручных средств страдают инженеры, и у вас вечные проблемы с различными изменениями в API, rate limit и т.п.
- Fivetran — $45k в год, интеграция с API Salesforce, Gsheets, Marketo, Zendesk и т.п. Так как это малая часть данных, то и цена небольшая.

Это расценки чисто на data-команду, а ещё есть ML-команда, расходы на AWS для инфраструктуры, и самая дорогая часть всего — data platform команда, которая использует Apache Kafka и пишет в S3 данные из MongoDB, Postgres, Cloudflare, серверных логов, Syslog и т.п. Точных цифр нет, но только расходы на платформенную команду могут составлять несколько миллионов долларов.

Какие выводы из этого маленького примера:

- Аналитика — это дорого.
- Облака — это дорого.
- Compute всегда дорого.
- Storage дорого.
- Использовать вендора — очень дорого, и ещё vendor lock в придачу.
- Инженеры — очевидно дорогие.
- Использовать бесплатный open-source — тоже дорого, и часто цена команды компенсирует цену лицензии.
- А самое дорогое — это уволить старую команду и нанять новую, чтобы новая всё починила и наконец-то показала ROI аналитики (хотя если старая не смогла, то и новая не факт, что поможет; хотя если мигрировать Snowflake на Databricks или наоборот, то на пару лет все будут заняты!).

Как ни крути — всё дорого.

Поэтому, если вы внедряете решение, старайтесь сразу отслеживать все расходы и мониторить их еженедельно. Это легче, чем спустя год-два распутывать клубок из высоких расходов.

Если команда использует open-source, старайтесь, чтобы все хорошо понимали, как это работает и как это обслуживается, иначе это будет black box и технический долг. Чаще проводите ревизию и удаляйте ненужные куски кода, старые pipelines, отчёты, dbt-модели и т.п. Сделайте leaderboard и пусть у вас будут top performers — те, кто удаляет старый и ненужный код.

И самое главное, обязательно фокус на business value, хотя это и так очевидно. Нужно балансировать между тем, что нужно бизнесу прямо сейчас и тем, что будет хорошо для аналитического решения и команды.

И чисто для инженеров было бы хорошо иметь 100% прозрачность в performance review, честный разговор о перспективах в компании. А то любят наобещать всего и побольше потом, а по факту 2% индексации🦯

Читать полностью…

Знаете какой самый популярный SQL запрос у крутого дата инженера?

SELECT * FROM <TABLE NAME>

А крутого дата инженера, но с реальным опытом, будет немного другой:

SELECT * FROM <TABLE NAME>
LIMIT 10

Даже chatGPT понял, что к чему:

- does it make sense?

- Да, это шутка, и она передает смысл! Первое выражение показывает запрос новичка или “крутого” дата инженера, который хочет увидеть все данные, а второе - опытного инженера, который понимает, что часто достаточно увидеть лишь часть данных, чтобы оценить содержимое таблицы и сэкономить ресурсы.

Эта шутка подчёркивает, что опытные инженеры более прагматичны и ценят эффективность в работе с данными. Отличная шутка для тех, кто знаком с SQL и повседневными задачами дата инженеров!


Реально мой день начинается и заканчивается с этих запросов🙌

Читать полностью…

Что ещё почитать?

Удивительно, что до сих пор не постил в канал свой список любимых книг. Они действительно хорошие.

Лейл Лаундес "Как говорить с кем угодно и о чем угодно"
Джим Кэмп “Сначала скажите нет”
Брайан Трейси "Переговоры"
Stephanie Palmer “Good in a Room”
Карен Прайор «Не рычите на собаку! Книга о дрессировке людей, животных и самого себя»

Пять учебников по переговорам и общению с другими людьми. Они очень разные между собой и по формату, и по целевой аудитории, и по рекомендациям, но каждый из пяти этих взглядов на коммуникацию был мне очень полезен и каждым я активно пользуюсь.

"Думай медленно... Решай быстро", Дэниел Канеман
“The Willpower Instinct: How Self-Control Works, Why It Matters, and What You Can Do to Get More of It”, Kelly McGonigal
"The Shallows", Николас Карр

Три отличные книги о том, как люди думают и как на это можно влиять. В первую очередь интересно понимать и влиять на самого себя, конечно. И выключите, наконец, уведомления на телефоне!

“Remote. Office not required”, David Heinemeier Hansson, Jason Fried

Книга об удаленке, написанная задолго до COVID. Очень много конкретных мыслей и предложений о том, как организовать её эффективнее.

Аллен Карр "Легкий способ сбросить вес"
Алексей Филатов "Теория и практика жиросжигания"

Две лучшие книги по борьбе с лишним весом из тех, что я читал, а читал я много. По их рецептам я реально худел с минимальными усилиями. Та самая “волшебная таблетка”.

"Ценностное управление для бизнеса", Константин Харский

Культура ест стратегию на завтрак, как известно. А чтобы ценности вашей компании использовались как-то иначе, чем просто висеть на холодильнике – прочтите книгу Харского.

"Школа продаж. Что делать, если клиент не хочет покупать?" Александр Деревицкий
«Метод тыквы. Как стать лидером в своей нише без бюджета», Майк Микаловиц
“No B.S. Ruthless Management of People and Profits” Dan S. Kennedy

Учебники бизнеса. Из каждого есть что взять и с чем поспорить, но даже то, “с чем поспорить”, читается с огромным интересом.

"Разумное распределение активов", Уильям Дж. Бернстайн

Лучшая книга об инвестициях. Вы не потеряете много денег, если будете инвестировать, опираясь на её идеи.

“Onward: How Starbucks Fought for Its Life without Losing Its Soul”, Howard Schultz
“Anything You Want: 40 Lessons for a New Kind of Entrepreneur”, Derek Sivers

Две вдохновляющие истории двух совершенно разных бизнесов.

Патрик Ленсиони «Пять пороков команды. Притчи о лидерстве»
“Кто, решите вашу проблему номер один”, Джефф Смарт, Рэнди Стрит

Две лучшие книги о найме и работе с людьми. А люди – это же самое главное в бизнесе?

Мою с соавторами книгу в этот список вставлять нескромно, так что я её просто рядом поставлю. Список закончился выше.
“50 бизнес-моделей новой экономики. Уроки компаний-единорогов”, Алексей Черняк, Михаил Иванов, Александр Горный

https://50i.ru/

P.S.: меньше книг, но с более подробным комментарием о каждой – в весеннем ролике на YouTube.

https://youtu.be/fzjRJwnFWC4

#личныйопыт

Читать полностью…

Свежая книжка по DE

Data projects are an intrinsic part of an organization's technical ecosystem, but data engineers in many companies are still trying to solve problems that others have already solved. This hands-on guide shows you how to provide valuable data by focusing on various aspects of data engineering, including data ingestion, data quality, idempotency, and more.

Author Bartosz Konieczny guides you through the process of building reliable end-to-end data engineering projects, from data ingestion to data observability, focusing on data engineering design patterns that solve common business problems in a secure and storage-optimized manner.

Each pattern includes a user-facing description of the problem, solutions, and consequences that place the pattern into the context of real-life scenarios.

Throughout this journey, you'll use open source data tools and public cloud services to see how to put each pattern into practice. You'll learn:

- Challenges data engineers face and their impact on data systems
- How these challenges relate to data system components
What data engineering patterns are for
- How to identify and fix issues with your current data components
- Technology-agnostic solutions to new and existing data projects
- How to implement patterns with Apache Airflow, Apache Spark, Apache Flink, and Delta Lake

URL: https://www.oreilly.com/library/view/data-engineering-design/9781098165826/ (по подписке доступна ранняя версия)

Читать полностью…

Хорошая визуализация как работает giveaway в Телеграмме. Как обычно был хороший intention у product managers но по факту вреда от него больше. Жалко, что реальные люди могут и не выиграть. По источнику трафика все приходят по URL, где то есть агрегатор каналов с призами наверно. 😑

Читать полностью…

Отвечаю очень развернуто на вопрос как стать дата инженером. В конце бонусом рассказываю про пользу сертификации, то есть бесполезность сертификатов при поиске работы.

Читать полностью…

В итоге за три дня я смог полностью пересобрать модель безопасности для Snowflake, понять, как работает Permifrost, и разблокировать все задачи, связанные с добавлением новых объектов в хранилище данных.

Заодно появился готовый проект для Surfalytics по использованию Permifrost, который мы будем изучать.

—-
PS: В чём ценность Permifrost и такого знания? Как мне видится, это отличная галочка в резюме для Analytics/Data Engineer. Очень полезная вещь для любого проекта в Snowflake и легко описывается в формате STAR (Situation, Task, Action, Result). Этому мы тоже будем учиться в Surfalytics.

А так интересно услышать от экспертов про:
1) Использовании Permiftost или альтернатив, как например Terraform, где можно создавать все объекта и давать права в одном месте
2) В целом про best practices RBAC
3) Как это делается в BigQuery, Databricks, Redshift и тп

Читать полностью…

Увидел пост в Linkedin и перевел его в chatgpt:

Я прочитал прогноз, что к 2030 году 80% разработчиков программного обеспечения будут заменены ИИ (или, что в противном случае, зарплаты сильно снизятся).

Я также посмотрел видео на YouTube, где один парень заказал приложение у разработчиков, работающих с no-code решениями, которые оказались быстрее, дешевле и лучше, чем обычные разработчики.

Я использую и Copilot, и ChatGPT в своей работе, но все же считаю себя разработчиком программного обеспечения, и хотя я нахожу эти инструменты потрясающими, мне сложно представить, как подобные прогнозы и утверждения могут стать реальностью, особенно в такие короткие сроки.

Буду благодарен за советы, чего я не замечаю! Какие-то конкретные прорывы или разработки помимо Copilot и ChatGPT, рабочие процессы или интеграции?

Вопрос понятный и актуальный. Мне понравился коммент от Gergely Orosz (автор The Pragmatic Engineer):

Обратите внимание на то, кто делает такие прогнозы. Я вижу подобные предсказания почти исключительно от людей, работающих в компаниях с венчурным финансированием, создающих такие инструменты (их успех зависит от этого прогноза), от венчурных инвесторов, вкладывающих средства в те же компании, и от людей, которые не занимаются разработкой день за днем с использованием этих инструментов.

Я спросил разработчиков, которые используют эти инструменты каждый день, и почувствовал суровую реальность по сравнению со всем этим хайпом: ссылка.


От себя добавлю, что мне сложно предсказать, что будет с индустрией через пять лет. Возможно, такие опытные специалисты, как я, с пятнадцатилетним стажем выполнения примерно одних и тех же задач, будут востребованы в каком-то объеме. Однако начинать карьеру в качестве junior analyst в 2030 году, скорее всего, станет сложнее. Возможно, не столько из-за AI, сколько из-за количества кандидатов на рынке, которые прошли (и заплатили большие деньги) курсы и получили сертификат, подтверждающий, что они готовы "грызть" данные.

Сейчас я на собственном опыте вижу, что ChatGPT и Copilot иногда помогают мне выполнять работу быстрее, но явно не лучше. Качество работы зависит от опыта и навыков.

Например, у меня на велосипеде почти год не работал гидравлический тормоз. Я пытался его починить в мастерской, но мне говорили, что придется ждать неделю, чтобы просто прокачать масло. В итоге, времени все не хватало. И тут я зашел в небольшой магазин, и мастер за 5 минут и 10 долларов устранил проблему. Оказалось, что на моем gravel bike можно регулировать ручку тормоза под длину пальцев, и у меня она была неправильно настроена, из-за чего тормоз не работал.

То есть, у него многолетний опыт, и он видит всю картину целиком. Я бы заплатил ему и 50 долларов за 10 минут работы, потому что он действительно профессионал в своем деле.

Возвращаясь к AI, по моему скромному мнению, эти инструменты пока еще плохо воспринимают (бизнес-) контекст и общую картину. Они решают точечные задачи и автоматизируют узкие бизнес-процессы (например, поддержку).

В аналитике, как правило, очень широкий и уникальный контекст. AI может создать pipeline, дашборд, собрать метрики, но пока это еще далеко от реальности, и крупные компании не скоро смогут это внедрить. До сих пор многие компании используют Teradata/Oracle с 90-х годов. У них огромные бюджеты на AI, которые раньше тратились на ML, Big Data, Cloud и т.д.

В целом, нам не стоит беспокоиться по этому поводу, ведь мы не можем контролировать этот процесс. Но мы можем контролировать свою гибкость и всегда быть открытыми к новому (гибкое мышление), чтобы учиться и развиваться, о чем я часто пишу в этом канале.

Нашим детям будет сложнее, и все, что мы можем сделать для них — это создать комфортные условия для учебы и спорта. Математика, чтение, языки и спорт — и все будет отлично!

Ладно, а как вы себе представляете AI-апокалипсис?

Лично я больше боюсь землетрясения, которое уж точно лишит всех работы в IT, как это уже бывало раньше - The M9 Cascadia Megathrust Earthquake of January 26, 1700

Читать полностью…

Последние несколько лет ежедневные стендапы по 20-30 минут стали для меня невыносимы.

Они бывают разными:

• Каждый день можно выходить к доске и переклеивать sticky notes, если вы работаете в офисе.
• Online-встречи с коллегами, где каждый делает вид, что рассказывает, что он сделал вчера и что будет делать сегодня.
• Иногда проходят встречи для cross-команд, и тогда эта канитель занимает не 15-20 минут, а 30-40 минут. У нас было так: нужно было назвать следующего человека, вести учет из 20-25 людей, кто уже говорил, а кто — нет… Для меня это был настоящий челлендж.
• Когда я работал на ГКНПЦ им. Хруничева в должности мастера участка механообработки, каждое утро я обходил токарей, фрезеровщиков и слесарей, жал им руку и спрашивал про прогресс. К сожалению, они не собирались у доски, и мне приходилось искать их по цеху. Это тоже был своеобразный, но бесполезный стендап.

В общем, за последние два года я осознал, насколько круто проводить полностью асинхронные стендапы, где каждый пишет в thread в Slack о своём прогрессе. Это сразу освобождает больше времени на работу.

Кстати, такой метод внедрил один из моих бывших менеджеров, который много лет проработал в Meta, а до этого вышел на IPO вместе с Lyft и смог купить домик в Сиэтле за 4 миллиона долларов. Он был противником бесполезных встреч и сделал все нудные процессы полностью асинхронными. Это оказалось очень эффективно.

Очевидно, что это хорошо работает с опытными специалистами. А как быть с новичками и стажерами? Здесь лучше иметь onboard-бадди или ментора, который будет работать с ними над задачами.

Теперь у меня всё просто: если на митинге больше четырёх человек, включая меня, на 99% он бесполезен, и можно не ходить. Точнее, присутствовать надо, но мыслями и делами быть в другом месте, то есть заниматься работой.

А как у вас обстоят дела с ежедневными стендапами и другими церемониями?

Читать полностью…

Несмотря на то, что Snowflake хороший продукт, у него много проблем с экономикой, которая не сходится. Изначально продукт был очень сильно раздут и мы видим как цена акций падает. А следовательно мотивация многих людей тоже может падать, ведь их total comp зависит как раз от цены компании.

Перевод поста:

Непопулярное мнение о #snowflake.

Уоррен Баффет известен тем, что никогда не инвестирует в программное обеспечение, но сделал исключение для Snowflake. Вероятно, он больше никогда не будет инвестировать в ПО, учитывая текущие результаты (цена ниже уровня IPO, отрицательная доходность за 4 года).

На мой взгляд, у Snowflake есть две большие проблемы:

1) Структурная: Snowflake должен был следовать тому же пути, что и Марк Бениофф в Salesforce. Марк обещал, что весь рынок CRM на базе локальных решений перейдет в облако, но через 25 лет только около 50% рынка находится в облаке. Марк быстро расширялся, приобретая крупные смежные бизнесы, такие как ExactTarget (автоматизация маркетинга), Mulesoft (API, обработка данных), Tableau (BI), ClickSoftware (и чуть было не LinkedIN).

Фрэнк Слутман отлично справился с задачей, заработав более $3 млрд на начальном кейсе использования облачного хранилища, но упустил возможность создания платформы. Кроме того, доходы компании полностью включают затраты на облако, так что это не чистый доход от ПО. Множитель должен быть больше похож на облачного провайдера, а не на SaaS/инфраструктуру.

Возможно, он неправильно оценил Snowflake, исходя из своего опыта в ServiceNow, которая является действительно устойчивой платформой. Snowflake следовало бы приобрести Confluent, Alation (каталог), Grafana Labs (BI + наблюдаемость), чтобы упомянуть лишь некоторых. Или сделать ставку на стартапы баз данных ClickHouse или PG. Также стоило бы агрессивно консолидировать MDS (современный стек данных), чтобы вытеснить Databricks. Более дешевые альтернативы Fivetran, DBT, Monte Carlo и т.д. Боюсь, что сейчас уже слишком поздно.

2) Тактическая: Databricks конкурирует с более дешевым озером данных и множеством вариантов запросных движков. Кроме того, в настоящее время клиенты хотят решения на основе "GenAI", и с учетом наследия структурированных данных, Snowflake не является первым местом, куда клиенты обращаются за AI.

И мы наблюдаем как Snowflake превращается в Enterprise компанию.

Мне нравится коммент от CEO Databricks:

All these years they kept saying that Snowflake's sales team is formidable. But the truth is that you need a technical sales team. Our CRO literally has a graduate degree in engineering from Stanford and can code. This makes all the difference in the world...

Все эти годы говорили, что у Snowflake мощная команда продаж. Но на самом деле вам нужна техническая команда продаж. Наш CRO имеет диплом инженера из Стэнфорда и умеет программировать. Это меняет все…

А как вам видеться противостояние 2х компаний?

Читать полностью…

На этой неделе у нас будет потрясающий 5-дневный лагерь Surfalytics Surfing + Data в Тофино, Британская Колумбия.

Это одно из самых красивых мест в Северной Америке с особой атмосферой 💕.

Что мы будем делать?
✅ серфинг для взрослых и бодисерфинг для детей
✅ рыбалка со скал на ужин
✅ походы
✅ велопрогулки
✅ сапсерфинг
✅ сауна
✅ ежедневный книжный клуб на 60 минут
✅ вечерние обсуждения данных
✅ обмен знаниями
✅ некоторые участники запланировали интервью на эти дни и могут воспользоваться коллективной помощью ;)

PS Когда то я просто мечтал, как было бы круто так сделать, а сегодня я это делаю! Не стесняйтесь в своих хотелках🏄‍♂️

Читать полностью…

Вебинар «От сырых данных до готового AI-сервиса за 10 минут»

30 августа в 17:00 будем разбирать и выполнять тестовое задание ML-инженера в BigTech.

На собеседованиях в ИТ часто встречаются задания в стиле «описать путь от модели в локальном Jupyter-ноутбуке до готового сервиса, к которому можно обращаться по API».

На вебинаре поговорим о способах решения подобных задач и о том, как сделать из любой ML-модели готовый сервис. Дополнительно разберем основные принципы и инструменты MLOps.

Вебинар будет полезен ML и MLOps-инженерам, Data Scientists, DevOps- и Data-инженерам, менеджерам технических продуктов.

Программа

🔹 Создаем готовый ML API в Jupyter-ноутбуке.

🔹 Проводим версионирование модели, разбираем возможности и функции MLflow.

🔹 Налаживаем жизненный цикл модели.

🔹 Организовываем хранение ML-артефактов и пространство для командной работы над библиотекой моделей для разных задач.

Регистрируйтесь на вебинар — мы пришлем ссылку на трансляцию в день мероприятия, а после вышлем запись.

Зарегистрироваться бесплатно

Читать полностью…

Типичная задачка для ETL разработчик data engineer.

У нас есть приложение и у него есть backend база данных (она же OLTP).

Если вы еще изучаете, то вам нужно ответить сразу на два вопроса:
1) ETL vs ELT в чем собственно разница. Чтобы ответить, надо не chatGPT спрашивать, а прям реально самому попробовать на примере БД локальной, и прочувствовать разницу
2) OLTP vs хранилище данных, часто это называют OLAP, но я не люблю называть аналитические запросы OLAP, потому что это пересекается с MOLAP (кубы MS Analysis Services и язык MDX) или ROLAP (что по сути происходит в любом современном BI, когда с помощью запроса мы кешируем результат SQL и потом его slice and dice

У нас простая задача - нужно в отчете показать количество пользователей.

И тут сразу должны возникнуть вопросы:
Что такое пользователь?
Как его идентифицировать?
В какой таблице найти?
Как к нему подключиться?
Сколько там данных? (Строк)
А можно ли нагружать эту базу данных своими запросами? Вдруг это production БД

Ок, у нас реплика (тоже надо знать, что это такое, и как ее создают в backend). Мы можем к ней подключаться по JDBC/ODBC через SQL клиент, или даже BI инструмент, чтобы изучить данные. Как раз тот самый запрос поможет:

select * from users limit 10

Обязательно нужно узнать про уникальный ключ в этой таблице. Он нам поможет избежать дубликатов, так сказать uniqueness test. И еще можно отслеживать freshness таблица по какому-нибудь timestamp.

Дальше нам надо придумать как эту табличку тянуть в хранилище данных, обычно в staging слой. И тут есть разные способы и инструменты (их не так много). Например, мы можем использовать Change Data Capture метод, который позволяет нам копировать только свежие и измененные данные, я это еще называю incremental загрузка. Альтернатива это full reload.

Если вы посмотрите инструменты Fivetran, Airbyte, Meltano, Matillion - все они предлагают вам похожие способы забора и загрузки данных.

Ок, нам повезло - наша таблица содержит два ключевых timestamp:
- created_at
- updated_at
И мы можем использовать подход с watermark, то есть хранить последнее значение (или находить его) перед запуском загрузки, и при каждом запуске ETL job, мы просто должны:

select *
from users
where created_at >= $parameter or updated_at >= $parameter

Но не забывайте самое главное свойство ETL pipelines - idempotent - то есть если каким-то образом мы выполним один и тот же job много раз, результат будет всегда такой же.

Для этого при incremental (инкрементальной) загрузке у нас есть варианты разные DELETE/INSERT, UPSERT, MERGE, UPDATE/INSERT и зависит это от данных и возможностей базы данных.

Например для таблиц с логами, у нас история не меняется и всегда APPEND, то есть данные добавляются, и отлично подходит DELETE/INSERT, а для таблички с пользователями у нас для каждого USER_ID могу поменяться атрибуты, поэтому мы будем использовать UPSERT. Для этого важно знать уникальный ключа в таблице!

Выше я писал про свой подход с Snowflake Procedure, но это можно реализовать множеством других способов и инструментов. Главное суть остается та же.

Теперь у нас есть таблица с пользователями, которая обновляется каждый день. И у для разработчика сразу должны возникнуть вопросы к заказчику, так сказать уточнение требований отчета:

Читать полностью…

Знаете ли вы, что такое хранимые процедуры? Раньше в Oracle, SQL Server, Teradata без них никуда было не деться. На всех работах, где эти мастодонты хранилищ данных использовались, всегда применялись процедуры.

Например, Oracle PL/SQL — мощная штука, которая позволяет создавать ETL, не отходя от кассы выходя из Oracle. Это было задолго до появления всех ништяков в Python.

Я всегда думал, что хранимые процедуры для «олдов» (такой термин вообще существует?). Помню, как пришёл в Amazon в 2016 году, а там Oracle on-premises и весь ETL на PL/SQL. Прямо как в dbt: последовательность SQL-трансформаций (теперь это называется DAG), разные функции и даже возможность забирать данные из SFTP, API и других систем.

Тогда я все это дело переделал на Redshift + Matillion ETL. Подумал тогда: «Что за смех, мы тут в облаке AWS строим modern data stack (кстати, в 2016 году такой термин ещё не использовался), а они тут со своим PL/SQL и Git в Bitbucket». Теперь у нас low/no code (тоже не использовал такой термин), и я мышкой всё сделаю. И я, конечно, всё сделал, и оно до сих пор работает, но я бы им порекомендовал перейти на dbt и вообще подумать про Analytics/Infra as a code 😛

Самое интересное, что недавно у меня была задача затягивать данные из backend в Azure (Azure SQL, CosmosDB), и, очевидно, я использовал Azure Data Factory. Но ADF сам ничего не умеет. Там есть отличная интеграция между всеми сервисами Azure, и можно из любого сервиса выгрузить в Azure Storage. Но если я хочу реализовать инкрементальную загрузку, slowly changing dimensions, snapshots и т.п., мне нужно где-то хостить свою логику.

И я не придумал ничего лучше, чем использовать хранимые процедуры Snowflake. Там есть много вариантов: хочешь — пиши на SQL, хочешь — на JavaScript. В общем, я всю логику положил в Stored Procedures, и всё работает замечательно.

Вот пример:

create or replace procedure CONFIG.UPDATE_WATERMARK_JOB(SCHEMA_NAME VARCHAR, PIPELINE_NAME VARCHAR,
                                                        START_TIMESTAMP TIMESTAMP_NTZ, END_TIMESTAMP TIMESTAMP_NTZ,
                                                        SOURCE VARCHAR, TABLE_NAME VARCHAR,
                                                        LAST_CREATED_TIMESTAMP TIMESTAMP_NTZ,
                                                        LAST_UPDATED_TIMESTAMP TIMESTAMP_NTZ)
    returns VARCHAR
    language SQL
    strict
as
$$
BEGIN

    INSERT INTO raw.config.watermark_table
        (schema_name, pipeline_name, start_timestamp, end_timestamp, source, table_name, last_created_timestamp, last_updated_timestamp)
    VALUES
        (schema_name, pipeline_name, start_timestamp, CONVERT_TIMEZONE('UTC', CURRENT_TIMESTAMP()), source, table_name, last_created_timestamp, last_updated_timestamp);

    RETURN 'Success';
END;
$$;

Получается, что всё новое — это хорошо забытое старое!

Как у вас дела обстоят с хранимыми процедурами?

Читать полностью…

Системный аналитик, присоединяйся к Сберу! 👌

Мы разрабатываем аналитическую платформу по управлению эффективностью организации. Наша цель – создать «сердце» платформы: общие технологические сервисы для разработчиков и low/no-code инструменты, которыми будут пользоваться аналитики для реализации бизнес-логики.

Чем предстоит заниматься ⤵️

👉 сбором, детализацией, уточнением и согласованием требований
👉 проработкой и подготовкой типовых решений для использования общих сервисов
👉 разработкой технической документации для разработчиков
👉 контролем реализации требований на всех этапах жизненного цикла разработки.

Читай подробности и откликайся на вакансию по ссылке 💁

Читать полностью…

Где искать работу зарубежом?

Международные стартапы с русскоговорящими фаундерами или командами – один из эффективных способов получить оффер за рубежом сейчас.

Вакансии именно в таких компаниях собирают ребята в канале Connectable Jobs Abroad, а также делятся прямыми контактами HR для отклика.
Как результат – уже десятки читателей получили офферы в Neon, InDrive, 1inch, Wheely и др.

Несколько актуальных вакансий:
– Junior Product Analyst в Nexters (remote или Армения, Казахстан, Кипр. Помогают с релокацией)
– System Analyst (Back Operations for our newly acquired Bank) в Salmon (remote или помогают с релокацией на Филиппины)
– Data Analyst (AppGrowth) в Appodeal (remote)
– Data Engineer в UCRAFT (Ереван)

Еще у ребят есть отдельный канал с вакансиями только для аналитиков и дата инженеров

💙Подписывайтесь и развивайте карьеру в будущем единороге!

Читать полностью…

Визуализация дня.

Согласно нему брак заключается реже по многим причинам — высоким уровням личной задолженности (кредиты/ипотеки), снижению общественного давления и другим факторам, — но одним из главных, похоже, является равенство заработной платы.

Согласно исследованию Калифорнийского университета, каждое увеличение средней зарплаты женщин на 10% приводит к снижению числа заключаемых браков на 7%.

Как все успели жениться, замуж выйти?)

Читать полностью…

Еще одна свежая книга, которая покрывает важный термин - Data Contracts.

Poor data quality can cause major problems for data teams, from breaking revenue-generating data pipelines to losing the trust of data consumers. Despite the importance of data quality, many data teams still struggle to avoid these issues—especially when their data is sourced from upstream workflows outside of their control. The solution: data contracts. Data contracts enable high-quality, well-governed data assets by documenting expectations of the data, establishing ownership of data assets, and then automatically enforcing these constraints within the CI/CD workflow.

This practical book introduces data contract architecture with a clear definition of data contracts, explains why the data industry needs them, and shares real-world use cases of data contracts in production. In addition, you'll learn how to implement components of the data contract architecture and understand how they're used in the data lifecycle. Finally, you'll build a case for implementing data contracts in your organization.

Authors Chad Sanderson and Mark Freeman will help you:

- Explore real-world applications of data contracts within the industry
- Understand how to apply each component of this architecture, such as CI/CD, monitoring, version control data, and more
- Learn how to implement data contracts using open source tools
- Examine ways to resolve data quality issues using data contract architecture
- Measure the impact of implementing a data contract in your organization
- Develop a strategy to determine how data contracts will be used in your organization

Компания Chad ищет инвестиции и я смотрел их pitch deck, пока у них как-то тухло по paying customers.

Если попростому, то data contracts это договоренность между 2мя командами о схеме и типе данных.

Например, вы забираете данные из backend OLTP. Инженеры решили поменять табличку, переименовали поле в таблицу и у вас упал ETL pipeline, ведь хранилище данных это Schema on Write. Вы его конечно почините, но так происходит часто и это влияете на качество дашбордов и в целом BI users experience.

Поэтому data contract позволяет нам проактивно мониторить этот процесс. Инженеры в backend знаю как их изменения повлияют на хранилище данных. Можно это внедрить и обычным способом, например в git кто-то из дата команды должен делать code review, чтобы знать об изменениях, но это подходит для маленьких компаний.

Читать полностью…

Arch.Meetup by Sber: современное управление архитектурой данных – регистрация открыта ✅

Уже 11 сентября в офисе Сбера и онлайн вместе с ИТ-архитекторами, data-инженерами и спикерами из трех IT-компаний поговорим об архитектуре данных и ее роли в управлении данными.
 
В программе – сразу 3 доклада, нетворкинг с большим архитектурным сообществом, выставка новых продуктов и технологий Сбера и фуршет.

О чем поговорим?
 
▪️Есть ли Архитектура данных за пределами хранилищ?
▪️Как моделировать данные на Enterprise-уровне?
▪️Как архитектура помогает в вопросах инвентаризации данных?
▪️Что такое Data API и почему мы часто говорим об интегрируемости данных?
 
 👉🏻 Подробная программа и регистрация – по этой ссылке. Успей пройти регистрацию – количество очных мест ограничено.

Читать полностью…

Решили завтра сгонять в Seattle на пару деньков пока у детей не сильная загрузка. В среду в 6 вечера буду на Lake Union с сидром и семьей, подходите пообщаемся про рынок Seattle/US.

Читать полностью…

Вот и прошел наш 6ти дневный Surfalytics meetup в красивом Тофино на острове Ванкувер на берегу открытого Тихого океана.

6 дней пролетело незаметно, было 10 семей и каждый нашел свое, все попробовали серф и влюбились в это место как мы 9 лет назад.

Мы были рады разделить эти дни с замечательной компанией и надеюсь в след году будет еще больше людей и еще больше дней.

🌊🌊🌊

Читать полностью…

Я часто слышал и видел Permifrost — утилиту для настройки прав доступа в Snowflake.

Permifrost — это Python-инструмент для управления правами доступа в Snowflake. Основная документация по его использованию доступна в проекте и на PyPI. Разработан в GitLab.

Одна из ключевых особенностей Snowflake — это удобное управление доступом с помощью Access Control Framework.

Внутри Snowflake у нас есть:
- база данных;
- внутри базы данных есть схемы;
- внутри схемы есть объекты: таблицы, вьюхи, процедуры.

Чтобы написать запрос, пользователь или сервисный пользователь должен иметь привилегии на объекты, например, на SELECT. Привилегий много, но для нас важно разделить их на категории READ, MODIFY и ADMIN — этого будет достаточно.

Все привилегии назначаются не конкретному пользователю, а роли, и уже потом мы назначаем роль пользователю.

Кроме DATABASE, ROLE, и USER есть ещё один важный элемент — это WAREHOUSE (вычислительный кластер). Часто для каждого сервиса можно выбрать свой compute, и таким образом легче отслеживать его стоимость.

Для меня все эти DBA-штучки в Snowflake довольно запутанные, и, если сильно углубляться, можно потратить много времени на планирование модели безопасности.

Безусловно, есть классные вещи, такие как IP Policy для пользователя — мы указываем список IP-адресов для сервисного пользователя, откуда могут приходить запросы. Dynamic Masking позволяет скрывать PII-данные для пользователей, у которых нет прав доступа к "красным" данным.

Обычно всё это настраивается с помощью команд GRANT, но легко потеряться в деталях. Поэтому Permifrost очень удобен: мы просто создаём YAML-файл, в котором описываем уже существующие объекты:
- ROLES (можно группировать по App, Base, Functional и т.д.; каждая роль может быть _admin, _modify, _view);
- DATABASES;
- USERS;
- WAREHOUSES.

После этого мы выполняем команду, и все GRANT/REVOKE обновляются.

Обычно Permifrost разворачивается через Dockerfile и настраивается на запуск в GitHub Actions раз в сутки (на всякий случай, но если изменения редкие, то и расписание не нужно).

Таким образом, все изменения прав происходят через YAML-файл и Pull Request, что делает их полностью прозрачными для всех.

Пример статьи по теме: Snowflake RBAC Implementation with Permifrost
Пример реализации от Meltano: [GitHub link](https://github.com/meltano/squared/blob/main/data/utilities/permifrost/roles.yml)

Теперь расскажу, как мне пришлось разбираться с этой штукой.

В проекте, который мне нужно было просмотреть и подправить, где до меня консультанты внедряли Snowflake и dbt, необходимо было создавать новые таблицы и давать права на чтение. Но почему-то на следующий день все мои GRANTы пропадали.

Потом я создал нового пользователя для BI и дал ему права на чтение всех баз данных, но на следующий день всё снова пропало.

В документации и репозитории была информация о Permifrost, но не было самого YAML-файла с конфигурацией, и вообще было непонятно, как изначально создавалась структура в Snowflake. Но по названиям было очевидно, что использовался какой-то шаблон.

Я написал консультантам, они ответили в духе «мы ничего не знаем, лошадь не моя». Мне всё равно нужно было создать модель безопасности и взять ситуацию под контроль. Очевидное решение — использовать Permifrost.

Проблема была в том, что если я начну менять права, то мой Permifrost может забрать права у сервисных пользователей, баз данных и т.д. А я тогда ещё не до конца понимал, как всё взаимосвязано.

Следуя любимым Amazon Leadership Principles — Bias for Action, Ownership, Deliver Results — я сразу начал менять продакшн в 10 вечера. Сначала отвалился Fivetran, затем оказалось, что у меня нет даже пароля от сервисного пользователя Fivetran. Методом научного тыка я разобрался, как выстроить взаимосвязь между YAML-спеком и Snowflake, сбросил пароль пользователя, и вроде бы Fivetran заработал. На следующий день я сломал dbt, но потом всё пошло быстрее.

Читать полностью…

Пора узнать аудиторию получше

Исследования аудитории необходимы, если бизнес не хочет тратить рекламный бюджет впустую. Когда проводить исследования, как они устроены и чем полезны — разберём 5 сентября на бесплатном вебинаре.

Вы узнаете:

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

Спикер — руководитель проектов исследований МТС Ads. Расскажет, как применять результаты исследований на практике, покажет кейсы и ответит на вопросы слушателей.

📅 5 сентября в 12:00 МСК
📌Онлайн

Участие бесплатное, но нужна регистрация.

Зарегистрироваться

Реклама. ПАО «МТС» ИНН 7740000076

Читать полностью…

10 лет назад все бежали в public cloud, а теперь повернулись на 180 градусов и бегут из public cloud. Интересный тренд. Думаю мы еще увидим много интересного как тренды меняются.

Может оно и хорошо, что в РФ Яндекс и ВК облака еще не так сильно популярны, так сказать проскочили тренд и теперь снова в тренде на on-premise:)

Читать полностью…

У Microsoft утекли зарплаты в США. В принципе зарплаты похожи на реальность, в Канаде все тоже самое но в Канадских долларах, и на 15-20% меньше.

Источник https://www.businessinsider.com/microsoft-spreadsheet-shows-pay-engineers-2024-8

Чтобы было понятно:
61, 62 - middle
63, 64 - senior
65, 66 - principal (staff нет позиции)

Более детально по уровням можно смотреть на levels fyi сайте, там можно сравнить другие тех компании и их роли.

Еще в Microsoft нет позиции Data Engineer, это Software Engineer. В описании позиции сложно понять, что будет делать человек, и только по стеку можно догадаться, что это про “хранилище данных”. Но как правило будет C# и Windows ноутбук. Навыки сложно конвертировать за пределами Microsoft.

Внутри Microsoft ужасный refer, если в Amazon можно было прыгать из команды в команду легко, то в Microsoft это практически не возможно, менеджеры ничего не могут сделать и просто вам не отвечают.

Читать полностью…

В субботу мы с Ромой Буниным очень классно посидели онлайн, 2,5 часа пролетело не заметно.

За это время он меня пособеседовал на позицию BI разработчика/Аналитика и рассказал про зарплаты в Амстердаме.

Рома очень классно проводит собеседование и у него высокие ожидания по разработке дашбордов, качеству визуализации, и главное коммуникации с бизнес пользователями, чтобы докопаться до сути бизнес проблемы. И вообще у него высокий emotional intelligence и сильные soft skills, что делает его классным лидером для своей команды и компании.

На интервью:
- работал в Tableau
- писал SQL
- рассказывал на пример дашборда о его проблемах и возможностях улучшений
- пострарался решить бизнес кейс и сам увидел на своем опыте как сложно быть аналитиком

Ссылка на пост и видео /channel/revealthedata/1279

UPD: ссылка на dzen https://dzen.ru/video/watch/66c2ec9068b5661787f78482

Читать полностью…

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

Встречайте, Trauma-Informed <key word>

Если что Trauma-Informed Analytics & Data Engineering я уже занял. Но для вас есть опции:

->Trauma-Informed Excel Analytics
->Trauma-Informed burnout
->Trauma-Informed 1С разработка


Из ЖПТ:

Trauma-Informed — это подход, который учитывает воздействие травмы на человека и ориентирован на создание безопасной, поддерживающей среды, способствующей восстановлению и благополучию. Этот подход особенно важен в таких сферах, как образование, здравоохранение, социальная работа и психотерапия. Он включает понимание того, как травматические события могут влиять на поведение, эмоции и когнитивные процессы человека, и адаптирует методы взаимодействия с учетом этих факторов.

Основные принципы Trauma-Informed подхода включают:

1. Безопасность: Создание физически и эмоционально безопасной среды для всех участников.
2. Доверие и Прозрачность: Поддержание доверительных и честных отношений, открытая коммуникация и уважение к личным границам.
3. Поддержка: Обеспечение эмоциональной поддержки и оказание помощи в восстановлении после травмы.
4. Сотрудничество: Включение человека в процесс принятия решений, уважение его выбора и предпочтений.
5. Учет культурных, гендерных и исторических факторов: Признание и уважение различий, связанных с культурным, гендерным или историческим контекстом.
6. Предотвращение повторной травматизации: Избегание ситуаций, которые могут напомнить о травме и вызвать повторное переживание травматического опыта.

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

Читать полностью…