Продолжаем нашу серию мини-интервью со специалистами по работе с данными.

Сегодня у нас 2 мини-сводки по структуре data teams от Антона Брызгалова и Адиля Хаштамова.

Мне очень понравилась статья Антона на Tproger о том, как он построил решение для стриминга данных на Yandex Cloud и по факту сделал собственный трекер событий для сайта и чат-ботов. Как оказалось, Антон - очень опытный специалист, который успел поработать в Яндексе и сейчас работает в роли Senior Data Engineer в компании KaiOS Tech.

Адиль - опытный разработчик и data engineer, автор Telegram-канала об инжиниринге данных, который я с удовольствием читаю и всем рекомендую. В последнее время был техническим лидом команды автоматизации маркетинга в компании Playrix.

Вот, что ребята рассказали про структуру команд в их компаниях:

Антон Брызгалов

"Ответить на вопрос проще через хронологию развития команды. Когда компания задумывается об извлечении пользы из данных, сначала нанимают аналитика (Data Analyst) или датасаентиста (Data Scientist). Эти специалисты могут самостоятельно сконвертировать данные в инсайты. Обычно работа этих специалистов business-driven: они выполняют прямые заказы бизнеса, не тратя время на переиспользование результатов работы — это дает гибкость и повышает скорость доставки результатов.

DA/DS как ремесленники: каждый из них талантлив в ручном труде, но чтобы поставить производство на поток, нужен инженер. Когда у данных появляется много пользователей, приходит время наращивать обороты «бизнеса данных» внутри компании. Тогда и появляется Data Engineer, который генерализует наработки аналитиков и датасаентистов, организуя платформу для работы с данными.

DA/DS + DE — это основной набор ролей. Чем больше становится нужда в генерализации подхода, тем больше специалистов появляется: тимлид (Team Lead) для управления командой дата-инженеров как командой разработки, проектный менеджер (Project Manager) для организации процессов, архитектор хранилища данных (роль часто совмещается с тимлидом) для принятия решений о модели данных и технической платформе, системные аналитики (System Analyst) для проектирования сущностей и поддержки знаний о домене, специалисты по Business Intelligence и разного рода аналитики с углубленной экспертизой в каждой отдельной области бизнеса.

Команда данных — это предприятие внутри компании. И оно проходит все стадии от кустарного производства до конвейеров и разделения труда.

Самая крупная аналитическая команда, в которой я работал, была в Яндекс.Такси. На момент, когда я ушел, у нас было 15 инженеров, включая архитектора (тимлида) и системного аналитика, и около 30 аналитиков данных, распределенных между разными направлениями: бизнес, маркетинг, продукт, CRM и пр. Насколько мне известно, сейчас в службе аналитики ЯТ около 100 человек."


Адиль Хаштамов

"Playrix - компания большая, в ней четко выделяются 2 направления касательно анализа данных:

1. Игровая аналитика
2. Маркетинговая аналитика

Для решения задач этих направлений существует департамент IT куда входят команды BI разработчиков, дата инженеры, full stack разработчики.

BI отдел визуализирует данные, создавая множество сложных и не очень дэшбордов. Основной инструмент Tableau.

Команда дата инженеров занимается построением дата пайплайнов, data modeling и отвечет за эффективную работу с данными. Периодически внутри компании проходят т.н. knowledge sharing презентации для улучшения коммуникации, т.к. все работают удаленно.

Full stack разработчики создают внутренние сервисы для автоматизации процессов, закрытые внутренние продукты для игровой и маркетинговой аналитики."

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

Рекомендую подписаться на канал "Data online events & Moscow meetups". Он посвящен мероприятиям по Big Data, Machine Learning, Data Science, Data Engineering, BI/DWH и другим направлениям, связанным с данными. Мероприятия проходят в Москве и онлайн.

Предложить свой ивент можно, написав @NikolayKrupiy, @Ajvol

👉🏻 Подписаться на www.tgoop.com/data_events

Всем привет.

Продолжаем мини-интервью с опытными специалистами по работе с данными. Своим интересным опытом поделились Олег Агапов (Data Analyst в GOG.com), Николай Валиотти (руководитель компании Valiotti Analytics) и Алексей Макаров (Product Manager в Яндекс Практикум, в прошлом Product Analyst в CoMagic). Немного слов о наших гостях:

Олег Агапов начал писать фундаментальную книгу о data-инжиниринге на GitHub. В ней уже есть 2 главы. Контент действительно достойный и заслуживает внимания. Ещё и на английском:)Также Олег оставил контакт, если кто-то захочет обсудить профессиональные моменты.

Про Николая и его компанию я узнал из выступления на Матемаркетинг 2020, где Николай рассказал про кейс построения end-to-end аналитики на Amazon Web Services с использованием ClickHouse и Kafka. Очень классный кейс, который можно позаимствовать при построении аналитики для мобильного стартапа. Также было интересно услышать от него о структуре его команды, как от руководителя. Ещё Николай ведёт интересный канал про данные и аналитику LEFT JOIN.

Про Алексея я узнал, подписавшись на его крутой канал, где он пишет про анализ данных с использованием языка Python. Если вы аналитик и хотите выйти на advanced уровень, то вам обязательно стоит на него подписаться.

Теперь переходим к самим интервью.

Олег Агапов:
"У нас в команде:
- 3 аналитика включая меня (отчеты, метрики, дашборды)
- 2 дата инженера (поддержка и настройка инфраструктуры и тулзов)
- 1.5 архитектора (создание инфраструктуры, создание внутренних инструментов)

Команда молодая, только прошлым летом набрали аналитиков и инженеров, до этого всё делал в основном сам. Мы набирали в команду фул-стек аналитиков, которые могут всё (почти) если понадобится. Поэтому чёткого разграничения по обязанностям нет, аналитики могут писать агрегации, инженеры могут делать дашборды.

Из проблем. У нас пока нет чёткого тим лида, кто будет авторитарно решать куда будет развиватся команда. Авторитарного именно в плане стратегии, а не тактики типа "будем всё писать на R".

Из достоинств. Намечаются доменные области, которые могут быть закрыты конкретным человеком. Например, есть спец по Табло и бизнесу, есть спец по определенным продуктам компании, тп. Это помогает экономить time-to-deploy (сколько проходит времени от постановки задачи до её выполнения)."

Николай Валиотти:
"В основном мы работаем с различными digital и мобильными стартапами, помогаем им выстроить end-to-end аналитику.
Другими словами, мы работаем со спектром задач от проектирования хранилища / озера данных, построения процессов инжиниринга данных до построения отчетности и иногда даже некоторых моделей машинного обучения.
Персонально я успел поработать в ряде крупных организаций и занимался анализом данных с разнообразным стеком решений, однако в последние годы перед стартом своей компании работал в стартапе, который уже тогда начал работать с так называемым modern data stack. Меня это невероятно увлекло и вдохновило на то, чтобы и другие компании могли компетентно использовать современные облачные решения и получать максимальную пользу от собственных данных.
Мы в некотором смысле стартап (по духу), хотя, конечно, больше развиваемся как традиционная консалтинговая компания. У нас небольшой штат сотрудников и соответствующих ролей, о которых речь пойдет дальше.
Поскольку работаем параллельно с несколькими проектами одновременно бОльшая часть команд кросс-функциональна, что означает, что в каждом проекте есть выделенный сотрудник, который лидирует по проекту, а другие коллеги функционально помогают ему в достижении поставленной цели.

Среди наших сотрудников имеются:
Data Engineer - работы с построением архитектуры хранилища, среди инструментов Kafka, Airflow, среди СУБД: BigQuery, Redshift, Clickhouse, Redshift, Vertica, MySQL, разумеется, SQL и Pythoh.
Analytics Engineer - работы с инструментов dbt, построение моделей данных в Looker, работа с Python для обработки данных, естественно, SQL
2x Data Analyst - мы используем ряд инструментов в зависимости от потребностей и возможностей заказчика: Tableau, Looker, Redash, PowerBI и Metabase, ребята умеют работать в этих инструментах и естественно используют SQL. Ряд задач, например, построение классификационных моделей мы строим с использованием Python, используем Jupyter, в некоторых случаях Collab.
2x Junior Data Analyst - помогают более старшим аналитикам и решают более маленькие кусочки задач с тем же стеком технологий.

В будущем планирую выстраивать организационную структуру, поскольку найм сотрудников горизонтально все-таки невозможен бесконечно и система из более 7 человек будет работать неэффективно"

Алексей Макаров:
"Сейчас я работаю в Яндекс.Практикуме, тут я продакт на факультете данных и занимаюсь развитием программы обучения, а с непосредственно аналитикой пересекаюсь не много

Ну у нас в CoMagic была очень небольшая команда по работе с данными. По факту аналитики нанимались под определенные функциональные направления. Например, отделу маркетинга нужен аналитик — они нанимали себе аналитика, который занимается маркетинговой аналитикой или подготовкой каких-то маркетинговых материалов на основе данных. Также и с продуктовой аналитикой — созрела необходимость в поддержке принятия решений среди продукт-менеджеров, нанимают продуктового аналитика. Единой аналитической команды таким образом не формируется, нет Head of Analytics, скорее каждый Head of Something нанимает себе отдельного аналитика. В этом плане аналитическая культура в CoMagic была слабоватой, так как не обеспечивается обмена знаниями

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

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

Сегодня у нас ещё одно интересное мини-интервью с Романом Буниным - руководителем команды визуализации данных в Яндекс Go.

Роман рассказал про структуру команды и как устроена работа с данными. Получилось интересно)

У Романа есть сайт и телеграм-канал, где он делится лайф-хаками визуализации данных, пишет про развитие BI-систем и, в частности, про Tableau. Рекомендую всем BI-разработчикам и всем, кто работает с визуализацией данных. Научитесь продуктовому подходу к построению дашбордов.

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

Яндекс имеет сильную data-driven культуры, поэтому в Go мы обслуживаем более 800 бизнес-пользователей, которые используют данные для принятия решений.

Основной «солдат» данных — это фуллстэк аналитик. Это супермены, которые могут сами собрать и понять боль бизнеса, подготовить данные, сделать их обработку на Питоне, построить модель и создать дашборд. Лучше всего они разбираются в аналитике, статистике и том направлении бизнеса за которое отвечают (продукт, маркетинг, найм водителей, безопасность и т.п.).

Чтобы помогать им работать с «технической» частью есть инфраструктурные команды: команда Data Management Platform, команды внутренних инструментов и моя команда по визуализации:
— DMP создает инструменты по работе с данными и новые низкоуровневые витрины данных. В их рядах дата-инженеры, партнеры по данным и системные инженеры.
— Команды внутренних инструментов разрабатывает библиотеки для питона, модели и инструменты прогнозирования, платформы для проведения A/B-тестов и системы аналитики в реальном времени. Здесь очень много разных ролей — от фронт-энд разработчиков до ML-инженеров.
— Моя команда помогает аналитикам делать правильные дашборды — мы обучаем и консультируем по работе с Табло, создаем темплейты и стайлгайды, налаживаем процессы управления контентом и делаем самые важные и большие отчеты. У нас в команде BI-разработчики и менеджер продукта.

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

Заканчиваем нашу рубрику, в которой опытные специалисты и руководители рассказывают о структуре команд по работе с данными в их компаниях.

И сегодня у нас последнее мини-интервью с Сергеем Брылем - Chief Data Science Officer в MacPaw. У Сергея есть телеграм-канал @analyzecore и блог https://www.analyzecore.com, где он в основном пишет про анализ данных, Data Science и визуализацию с использованием языка R.

Сергей Брыль:
"MacPaw мультипродуктовая компания, в текущем портфеле есть 10 продуктов, которые представлены на различных платформах. Поэтому, продуктовая аналитика для нас является ключевой экспертизой, а продуктовые аналитики - ядром команды аналитики.

На данный момент мы развиваем 6 направлений, которые входят в структуру Data Science Department. Важность и независимость аналитической функции в компании обеспечивается через то, что я представляю ее интересы на уровне Executive team.

Product Analytics. Мы пришли к выводу, что продуктовая аналитика должна быть глубоко интегрирована в продуктовую команду. С самого начала аналитики должны помочь разработать показатели успеха продукта, измерять прогресс и помогать выявлять риски и области роста для бизнеса. Более того, их понимание, основанное на данных, должно быть постоянным вкладом в разработку продукта. Функционально они подчиняются Chief Data Science Officer, а линейно - соответствующим продуктовым менеджерам.

Такой тип организационной структуры дает нам возможность:

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

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

С другой стороны, такая структура предполагает достаточно высокие требования к продуктовым аналитикам как в hard, так и soft skills.

Другие направления построены на специализированной глубокой экспертизе и в организационной структуре представлены в виде сервисов (или экспертных центров).

DataHub - тут сосредоточена наша data инженерная экспертиза. Команда DataHub делает возможной тонко-настраиваемую аналитику с помощью кастомных технических решений и интеграций с продуктами и сервисами.

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

AI Lab. Миссия команды повышать эффективность процессов и ежедневных решений с помощью Machine Learning.

Этот сервис отвечает за два вектора развития:

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

Market & Customer/User Research - сервис, который дает нам аналитику из внешнего мира о:

- рынках и аудиториях, их особенностях
- пользовательском опыте

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

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

Internal Analytics - наше экспериментальное направление. Идея: анализировать данные, которые мы генерируем как компания и использовать их для принятия решений. Это направление ценно еще и тем, что работает над развитием дата-дривен культуры в поддерживающих сервисах и популяризирует подход в самых разных подразделениях компании.

Что касается организационной структуры направления, мы достаточно гибкие и готовы к быстрым изменения. Постоянно проверяем все ли работает как мы задумывали и, при необходимости, внедряем изменения."

Всем привет. На этих выходных хочу закончить разбор всех 4-х факторов эффективности работы компании в целом и data team, в частности.

Мы закончили наш цикл мини-интервью со специалистами и руководителями разных компаний, которые были посвящены 3 фактору эффективности - "Структура команды".

Исходя из всех интервью можно сделать такие выводы:
- Структура команды зависит от 2-х главных факторов: уровень развития data-driven культуры и размер компании. Именно в такой последовательности, так как без культуры работы с данными большие компании не будут уделять должное внимание аналитической функции и структуре.
- Команда по работе с данными - это предприятие внутри предприятия. Т.е. подразделение, отвечающее за данные и аналитику переживает такие же стадии развития, как обычное предприятие (при условии развития, конечно): сначала оно имеет в своём штате небольшое количество сотрудников-универсалов, назовём их full-stack аналитиками, которые самостоятельно могут собрать данные, обработать их, визуализировать, проанализировать и сделать выводы из них. По мере развития компании, увеличивается количество бизнес-процессов и данных. Необходимо использовать более сложные технологии, в которых нужно иметь глубокую экспертизу. Становится очень проблематично одному специалисту быть экспертом во всех сферах (инжиниринге, аналитике и data science). Поэтому команда плавно расширяет штат и переходит к разделению труда.
- Работа с данными стала мейнстримом сравнительно недавно, поэтому сложно сказать, какая структура команды наиболее эффективная. Многие компании довольно гибкие в этом плане и методом проб и ошибок, экспериментами нащупывают наиболее подходящую под их бизнес-нужды структуру.

Получилась очень классная рубрика. Думаю, в будущем сделаем интервью и на другие темы)

P.S. Завтра опубликую пост о последнем факторе и начнём двигаться уже к техническим концепциям и конкретным инструментам.

Заканчиваем цикл постов о 4-х факторах эффективности работы компании и подразделения по работе с данными, в частности. И сегодня пост посвящён последнему 4 фактору - "Система единых взглядов и ценностей".

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

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

Из этого всего я сделал один вывод: людей недостаточно раскрывают на собеседованиях. Компания попросту теряет деньги, выплачивая им зарплату на испытательном сроке, и весь процесс найма сотрудника нужно начинать сначала. При этом коллеги уже загибаются от нагрузки и начинают выгорать от работы. В общем последствия неправильного найма могут быть очень неблагоприятными.
Безусловно, не будет такого, что в 100% случаев вы будете нанимать нужных вам людей, для этого и даётся испытательный срок, чтобы удостовериться в сотруднике. Но определённо нужно стремиться к уменьшению % сотрудников, которые не проходят ИС. Это очень важный процесс, который определяет эффективность и экспертизу рекрутинга в компании и её менеджмента.
Поэтому, я считаю, даже к junior-специалистам нужно предъявлять высокие требования по софт-скиллам и постараться их раскрыть на собеседованиях, насколько это возможно. Дообучить человека, который не владеет каким-то конкретным инструментом, можно в относительно короткий срок (при наличии базовых знаний). А вот изменить способ мышления - это долгая и кропотливая работа, которая, в первую очередь, зависит от самого человека. У вас, как руководителя, есть заботы по улучшению качества продукта и процессов. И уделять кучу внимания изменению способа мышления и характера сотрудника, как минимум странно.

Теперь о том, как по моему мнению можно усовершенствовать процесс найма.

Можно выделить 4 основные ценности, которым стоит следовать компаниям, отдельным подразделениям и отдельным сотрудникам для эффективной работы:

1) Бизнес-ориентированность
2) Честность между людьми внутри компании
3) Проактивность
4) Постоянное стремление к саморазвитию

Как по мне, можно строить процесс собеседования кандидатов, опираясь на эти 4 ценности.

Под бизнес-ориентированностью я полагаю умение смотреть на свою работу с точки зрения эффективности бизнеса заказчика и бизнеса компании, в которой вы работаете. Я люблю упоминать именно этот термин, а не "Клиентоориентированность", так как для меня клиентоориентированность - это всегда следовать правилу "клиент всегда прав". Я не согласен с таким подходом, так как заказчик нанимает вас как экспертов, а не рабочие руки, которые просто выполняют то, что он говорит. Если вы не согласны с заказчиком и считаете, что есть более оптимальный вариант решения для его бизнеса, нужно ему об этом сказать, опираясь на цифры, кейсы и лучшие практики рынка. Это и есть бизнес-ориентированность.
Проверить это качество у кандидата можно простым моделированием бизнес-ситуации. Например, вы выступаете в роли заказчика, а кандидат - в роли исполнителя. Вы можете предложить какое-то даже абсурдное решение и сказать: "Вот, я хочу сделать вот так". Вот здесь как раз и раскрывается компетентность и потенциал кандидата. Можно посмотреть, согласится он с вами или предложит другое решение и будет отстаивать его, опираясь на цифры, факты и кейсы, при этом сохраняя к вам уважение.
Я однажды собеседовался в компанию, и как раз на этом посыпался. Директор компании сказал, что мне не хватает критического мышления. Я был очень расстроен тогда сначала, а потом осознал, что мне указали на мой недостаток, и это может быть точкой роста. Это собеседование стало переломным для меня, и сейчас я всегда стараюсь вступать в конструктивную дискуссию, если я с чем то не согласен, и стараюсь искать всегда оптимальные решения для бизнеса.

Теперь о честности. Честность сложно проверить какими-то тестами. Разве что вы владеете психоанализом:))
Чтобы определить, честен с вами человек или нет, нужно обладать большим опытом и хорошей интуицией. Уметь чувствовать людей. Вообще я считаю интуицию - одним из главных качеств хорошего руководителя.

Проактивность. Для меня проактивность - это выход за рамки должностных инструкций. Когда вы не просто выполняете свою работу, а думаете о том, как улучшить продукт, оптимизировать процесс работы (как своей, так и компании).
На собеседованиях можно спросить у человека, как он пытался улучшить продукт или процесс, что он для этого делал, с какими проблемами столкнулся. Обычно проактивный человек будет рассказывать об этом в подробностях и не будет "лить воду".

Стремление к саморазвитию. Очень важное качество, я бы сказал - движущая сила сотрудников. Если люди постоянно стремятся развивать свои софт и хард-скиллы, шансы на рост компании увеличиваются в десятки раз.
На собеседованиях можно спрашивать у кандидата, как он совершенствует свои навыки, какие книги или статьи он читает, какие видео смотрит, как тренирует свои навыки и т.д. При этом вопросы лучше задавать в формате "Какую последнюю книгу вы прочитали? Какие выводы сделали?", "Какую статью прочитали, с чем были не согласны?" Так как есть кандидаты, которые любят врать на собеседованиях:) А такие вопросы могут застать врасплох.


Думаю, тему раскрыл.

P.S. Про все факторы эффективности более подробно можно прочитать в книге "Идеальный руководитель" Ицхака Адизеса. Про общие взгляды и ценности там целых 2 главы)

P.S.S. Следующий пост будет посвящён технологиям и инструментам, которые имеет смысл применять на определённой стадии развития онлайн-бизнеса.

Про Snowflake я писал не раз и даже общался с компаниями в Москве, кто хочет внедрять технологию. Приходили и рекрутеры, кто хочет специалистов по Snowflake. Так что наш следующий вебинар очень в тему. И он в тему модуля 6 #datalearn про современные аналитические DW. Я бы даже отнес его к Lakehouse.

https://youtu.be/XJa3gGWidg0

Из нашего slack:

Мальчишки, девчонки, а также их родители, про Snowflake историю в понедельник 8 февраля в 20:00 по мск послушать не хотите ли? Николай Голов подготовил отличный доклад. Ему есть чего рассказать и чему поучить!

Как всегда всем быть, те кто смотрит лекции будущие Олимпийские чемпионы в дата мире 😊
🔔 Что нужно сделать:
📌 Перейти по ссылке и поставить колокольчик, чтобы в понедельник не пропустить
📌 Отложить все дела на понедельник
📌 В понедельник в 20:00 быть на вебинаре

И ПОДПИШИТЕСЬ НА НАШ ЮТУБ

В следующий четверг 18.02 буду выступать в Киеве на Kyiv Analytics Ads Beer Talk.

Расскажу о том, как дёшево и эффективно работать с Google BigQuery, и на какие грабли я наступал при работе с Google Cloud.

Кто хочет в непринуждённой обстановке поговорить об аналитике, инжиниринге, покушать снеки и выпить вкусного пива, приходите😉

Зовсім скоро, вже наступного тижня (18 лютого 19:00) — Kyiv Analytics Ads Beer Talk #11!

Спікери:

Головатий Петро - Product analyst в SE Ranking
Тема: "Power BI - місце зустрічі ваших даних"

Євген Фішбейн - Web Analyst в DEPLABS
Тема: "DataLayer QA Automation"

Danylo Burykin - Google Ads at www.top-rated.team
Тема: "Фриланс на Upwork"

Соловйов Денис - Web-аналітик і Data Engineer в Promodo
Тема: Як працювати з Google Cloud і витрачати менш ніж $100 на місяць "

п'ємо пиво, їмо снеки))

https://secure.wayforpay.com/payment/kyiv_analytics_beer11

Всем привет👋 Пока ездил в Киев, написал большой и, надеюсь, интересный пост:)

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

Давайте опишем эволюцию аналитики на примере интернет-магазина спортивной одежды.

ЭТАП 1️⃣
Мы только начинаем: закупили первую партию товаров, заказали за недорогую цену разработку интернет-магазина, вложили деньги в какие-то маркетинговые активности. Скорее всего, мы работаем одни или нам помогает пара человек. В общем, о каком-то штате сотрудников тут речи не идёт.

Денежные ресурсы ограничены, но уже на первом этапе важно начинать собирать данные и проводить какую-то аналитику для принятия решений. Сейчас нам важно в первую очередь анализировать эффективность каналов трафика, по которым люди переходят на сайт, и поведение пользователей на сайте, так как сайт является основной точкой продаж. Нужно понять, что людям нравится на сайте, что не нравится, что мешает им совершить заказ. Есть хорошая новость – в отличие от оффлайн-магазинов, это достаточно легко отследить)

На данном этапе хорошо подойдут бесплатные инструменты веб-аналитики, такие как Google Analytics или Яндекс Метрика (для российского рынка). Важно хотя бы на базовом уровне понимать работу этих инструментов и знать, как анализировать базовые отчёты. Здесь очень важно завести привычку регулярно (раз в день, 3 раза в неделю и т.д.) анализировать данные и тестировать различные гипотезы по улучшению сайта и маркетинга.

В качестве инструмента для фиксации сделок пока подойдёт обычный Google Spreadsheet (или Excel)


ЭТАП 2️⃣
Мы немного наладили различные бизнес-процессы (закупки, продажи, финансы, маркетинг), завели привычку регулярно анализировать данные. У нас уже есть небольшой штат сотрудников (до 20 человек) и отдел продаж. Продажи начинают стабилизироваться.

Здесь уже можно задуматься о внедрении CRM-системы (amoCRM, retailCRM, 1C, Bitrix, Salesforce и др.).
Также мы можем захотеть видеть уже полный путь клиента (от перехода на сайт до конечной сделки, которая фиксируется либо в Google Spreadsheets, либо в CRM) и понимать эффективность маркетинговых каналов в разрезе конечных продаж. Если вы пока не можете выделить много ресурсов на аналитику, то можно объединять данные веб-аналитики и данные о конечных сделках в Google Spreadsheets или в BI-инструменте (Google Data Studio, Klipfolio, Power BI). В идеале это автоматизировать, но, если с этим пока сложно, можно и вручную объединять. Можно также использовать недорогие решения «из коробки» - различные сервисы сквозной аналитики (типа Roistat, K50, Calltouch).
Если вы готовы вкладывать больше ресурсов, то можно уже сейчас задуматься о построении собственного хранилища (DWH) для хранения всех данных вашей компании. На данном этапе вы можете использовать решения на базе реляционных СУБД, таких как MySQL, MS SQL, PostgreSQL. Но если вы понимаете, что объём данных в будущем будет расти и вам нужно масштабируемое решение, я бы рекомендовал сразу использовать аналитические базы данных, такие как Google BigQuery, Snowflake, Clickhouse, Amazon Redshift или Azure Synapse.

Также можно использовать как ETL-инструменты, так и делать ELT, используя микс инструментов. Например, чтобы легко и недорого делать ETL, можно развернуть на сервере Pentaho Data Integration. Для ELT можно использовать инструменты по загрузке данных из различных источников в хранилище (Stitch, Renta, OWOX, Matillion Data Loader) в связке с инструментами для трансформации данных (например, dbt). При ELT трансформации можно также делать, используя внутренние возможности хранилищ (например, Scheduled Queries в BigQuery).

Для Extract and Load лично я предпочитаю использовать свои ETL-скрипты, которые запускаются в serverless среде (Google Cloud Functions, Google Cloud Run, Amazon Lambda и др.) Такой подход максимально удешевляет решение, но, если у вас нет достаточной экспертизы в написании кода и вам проще использовать готовые решения – используйте их, главное решить задачу бизнеса.

В качестве BI подойдёт любой удобный для вас инструмент.


ЭТАП 3️⃣
После вывода бизнеса на стабильный поток продаж, базового налаживания бизнес-процессов, мы хотим развивать и расширять наш бизнес. Мы можем увеличить количество каналов коммуникации с потенциальными клиентами (например, заказать разработку мобильного приложения), открыть оффлайн-точки продаж и т.д.

Здесь мы можем добавить в свой арсенал сервисы мобильной аналитики, такие как Firebase Analytics, AppsFlyer, AppMetrika, Adjust и др.

Также на этом этапе имеет смысл смотреть не только отчёты в BI-инструменте или в инструментах web/app аналитики, но и проводить более глубокую аналитику с использованием SQL, Python или R. Т.е. здесь мы можем подключать такие инструменты как Jupyter Notebook или R Studio.

ЭТАП 4️⃣
Мы уже неплохо раскачали наш бренд, на наш сайт и приложение ежедневно переходит несколько миллионов людей. Увеличивается количество источников данных и объём данных. Ещё больше растёт потребность в грамотной аналитике и текущей инфраструктуры уже недостаточно. Нам хочется получать «сырые» данные (без предагрегаций и агрегаций), чтобы получать большую гибкость в анализе данных.

На этом этапе мы можем уже строить платформу данных (Data Lake + DWH) или Lakehouse. Для этих целей мы можем использовать такие инструменты и их связки:
- Amazon S3 + Amazon Redshift + Amazon Athena/Amazon Redshift Spectrum
- Delta Lake (Databricks)
- Google Cloud Storage + Google BigQuery
- Azure Data Lake Storage + Azure Synapse
- HDFS + Hive (Hadoop)

Также на этом этапе уже имеет смысл использовать облачные ETL-инструменты и оркестраторы с гибкими возможностями: Azure Data Factory, Amazon Glue, Google Cloud Dataflow, Matillion ETL, Fivetran, Apache Airflow, Luigi, Apache Nifi и т.д.

Для обработки больших массивов данных отлично подойдут Apache Spark, Databricks, Amazon Elastic MapReduce, Google Cloud Dataproc.

Также здесь важно использовать продуктовый подход к разработке инфраструктуры, т.е. внедрять Agile и DevOps практики: использование версионирования кода (Git), построение CI/CD пайплайнов (например, с использованием Azure DevOps, Google Cloud Build, AWS CodePipeline, Jenkins), поднятие кластера контейнеров (с использованием Docker и Kubernetes), использование Infrastructure as Code (Terraform, AWS CloudFormation и др.).

Для получения «сырых» данных мы можем также использовать стриминг и соответствующие инструменты: Apache Kafka, Amazon Kinesis, Google Cloud Pub/Sub, Spark Streaming, Azure Event Hub

ЭТАП 5️⃣
После выстраивания BigData архитектуры (создания платформы данных и настройки стриминга) мы можем проводить продвинутую аналитику, строить ML и DL алгоритмы и выводить их в продакшн. В инструментах для Data Science я не очень силён. Знаю только, что дата-сайнтисты используют Jupyter Notebook, AWS Sagemaker, Google Cloud AI Platform и др.

Запись с моего выступления на Kyiv Analytics Ads Beer Talks. Рассказал о том, как тратить меньше 100$ в месяц на аналитику, используя Google Cloud и BigQuery.

Что читать DE в телеге?

Сегодня подборка полезных TG-каналов для дата-инженера:

• Инжиниринг данных https://www.tgoop.com/rockyourdata Канал Дмитрия Аношина, эксперта по BI. Автор также ведет курс datalearn.ru, где обучает дата-инжиниринг (бесплатно)
• Data Eng https://www.tgoop.com/dataeng Всё, что вы хотели знать про построение инфраструктуры для хранения, обработки и эффективного анализа гигантского объёма данных.
• Moscow Spark https://www.tgoop.com/moscowspark Чат московского community Apache Spark.
• DE or DIE Chat https://www.tgoop.com/deordie_chat Чат сообщества DE or DIE, созданный дата инженерами. Поддерживают ребята из DoDo Engineering. Проводят митапы DE or DIE вместе с NewProLab
• Smart Data https://www.tgoop.com/smart_data_channel Канал про Data Engineering, аналитику и данные.
• Я у мамы Data Engineer! https://www.tgoop.com/ohmydataengineer
• Data online events & Moscow meetups https://www.tgoop.com/data_events Очень полезный канал - все ивенты, связанные с данными
• Data jobs feed https://www.tgoop.com/datajobschannel Канал с вакансиями в сфере обработки данных (инженеры, аналитики). Полезно для понимания тенденций на рынке и востребованных навыков

Если знаете еще полезные каналы - пишите в комментариях!

Дорогие девушки, поздравляю всех с праздником весны - 8 марта🌸

Желаю вам всегда чувствовать в себе женственность и нежность😊

И пусть вам будет не страшна Big Data😉