#easy

Начинаем нашу серию постов о втором факторе эффективности работы data-team и организации в целом - о процессах.

И сегодня я хочу разобрать "пирамиду потребностей Data Science".

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

1) Физиологические потребности: потребность в пище, воде, тепле и отдыхе
2) Потребность в безопасности
3) Потребность в принадлежности к обществу и в любви: романтические отношения, дружеские отношения
4) Потребность в уважении и почтении
5) Потребность в развитии потенциала и потребность в творчестве

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

Теперь давайте переложим эту идею на работу с данными. Здесь есть 6 уровней иерархии:

1) Collect - сбор данных на уровне источников. Например, сбор данных о поведении пользователей на сайте или в мобильном приложении в системы web/app аналитики, поддержка транзакционной базы данных, которая обслуживает back-end интернет-магазина и в которую записываются данные об оформленных заказах на сайте. Это также учёт лидов и сделок в CRM-системе и т.д. За этот уровень у нас отвечают веб-аналитики, back-end разработчики, администраторы баз данных и люди, которые отвечают за администрирование CRM-системы. Это первый и самый базовый уровень иерархии, так как если вы будете собирать данные на уровне источников некорректно и не в полном объёме, то в последующих ETL, анализе и data science просто нет смысла. Вы будете принимать неверные решения, а качество моделей будет очень низким.
2) Move/Store - построение ETL, data-пайплайнов, DWH/Data Lake. Когда у нас налажен сбор данных на уровне источников и данные собираются в полном объёме, мы можем переходить к построению хранилища данных или озера данных и выстраивать data-пайплайны и ETL-процессы. Здесь к работе подключаются инженеры данных. Это 2-й уровень иерархии, который отвечает за надёжные и масштабируемые потоки данных и безопасное хранение данных. Без этого вы так же можете получать данные несвоевременно и не в полном объёме, из-за чего дальнейшая аналитика и принятие решений лишены смысла.
3) Explore/Transform - очистка данных и их подготовка к дальнейшему анализу. Когда мы удовлетворили потребность в надёжных потоках данных и их безопасном хранении, мы приступаем к их подготовке для анализа. Эту задачу могут выполнять аналитики данных и инженеры данных. Здесь мы работаем с пропущенными значениями, с типами данных, чтобы потом эту информацию можно было агрегировать и анализировать. Без этого уровня процесс анализа будет сложным и непродуктивным.
4) Aggregate/Label - объединение данных, расчёт нужных метрик, построение BI, сегментация, feature engineering и обучение данных. Когда мы очистили и подготовили данные, мы можем приступать к непосредственному процессу анализа и построению BI-решений. Здесь мы ещё не накручиваем сложные ML/DL/AI алгоритмы. Наша задача - найти инсайты в исторических данных и подготовить данные для построения Data Science моделей. Без этого уровня невозможно построить качественную модель и выводить её в production.
5) Learn/Optimize - A/B тестирование, эксперименты, построение простых ML-моделей, оптимизация моделей. Так что, можно, наконец, строить космолёт? Если вы хотите просто построить модель оттока клиентов - то можно начинать делать простые алгоритмы (например, модель классификации). Если вы хотите сделать рекомендательную систему товаров на сайте, то прежде чем строить модель и выводить её в prod, нужно убедиться, что показываются действительно подходящие товары. Для этого мы, опираясь на обученные данные, делаем A/B тесты на сайте и убеждаемся, что товары действительно нужны людям, и они их покупают. На этом этапе мы также дополняем данные новыми фичами для повышения качества моделей. И уже после этого используем алгоритм и выводим в продакшн.
6) AI и Deep Learning. И, наконец, если мы убедились, что ML работает для нашего бизнеса и приносит деньги, мы можем разрабатывать более сложные алгоритмы и запихнуть нитро в нашу бизнес-машину:)

Я описал, как должен быть выстроен процесс работы с данными. Но не нужно впадать в крайность и, например, доводить инфраструктуру до идеала, вместо того, чтобы анализировать данные и принимать решения на достаточно рабочем прототипе. Здесь полезно применять Agile-подход, главной задачей которого является ускорение разработки продукта. Т.е. нам сначала нужно масштабировать систему вертикально и создать MVP (minimal viable product), потому что пока вы будете доводить до идеала инфраструктуру, конкуренты будут принимать решения и занимать прочную позицию на рынке.
После того, как вы создали MVP, вы можете масштабировать его горизонтально, т.е. латать слабые места в системе и добавлять новые фичи в ваше решение.

#easy

Всем привет.

Продолжаем нашу серию постов о процессах. Я хочу рассказать про философии и методологии ведения проектов. Думаю, многие слышали такие слова как Agile, Waterfall, Scrum и Kanban. А для некоторых это не просто слова, и они с этим сталкиваются ежедневно на своей работе. Вот про это и поговорим.

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

Сегодня начнём с Agile и Waterfall.

Agile (гибкий) - философия ведения проектов, которая была разработана 17 разработчиками ПО. Её главная задача - ускорение разработки программного обеспечения.

Главные принципы Agile:
- удовлетворение потребностей клиентов за счёт быстрой и непрерывной поставки программного обеспечения;
- гибкость в меняющихся требованиях даже на поздних стадиях разработки, постоянное получение фидбека от конечных пользователей продукта и заинтересованных лиц;
- акцент на живом общении внутри команды и экспертизе каждого из её членов. Больше акцент на людях, а не жёстко регламентированных процессах;
- доверие к команде разработки и обеспечение свободы действия;
- итеративный подход к разработке - внедрение новых фич происходит циклами. Для итераций используется понятие "спринт".

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

Недостатки Agile:
- нет жёстко зафиксированных сроков поставки продукта. При неправильной приоритезации задач и неправильном менеджменте процесс разработки может не ускориться, а, наоборот, затянуться;
- высокая потребность в кросс-функциональной команде. Так как Agile-команда, как правило, маленькая, каждый её член должен обладать высокой экспертизой во многих областях (разработке, тестировании и т.д.). Более того, такие люди должны быть глубоко осознанными и дисциплинированными, чтобы покрывать первый недостаток;
- нет подробной документации;
- требует дополнительного обучения сотрудников для перехода на эту методологию.

Как происходит процесс разработки при использовании Agile-подхода:
Во-первых, у нас есть несколько ролей:
1) Product Owner (владелец продукта) - это человек, который не обладает глубокими техническими знаниями, но обладает общим видением продукта: для чего мы его делаем и каким он должен быть.
2) Stakeholders (заинтересованные лица) - все те, кто будет пользоваться этим продуктом или как-то в нём заинтересованы.
3) Development Team (команда разработки) - непосредственно те, кто будут технически реализовывать разработку и поставку продукта.

Во-вторых, у нас есть несколько последовательных этапов в каждой итерации (спринте):
1) Requirements - здесь заинтересованные лица предлагают свои идеи по продукту и его улучшению, а владелец продукта помогает сконвертировать эти идеи в готовые требования. Этот этап характеризуется большим количеством митингов и обсуждений.
2) Plan - на этом этапе требования разбиваются на более мелкие части работы (фичи). Для этих фич выставляется приоритетность и пополняется backlog.
3) Design - здесь, как понятно из названия, мы подготавливаем дизайн решения и разрабатываем стратегию тестирования.
4) Develop - непосредственный процесс создания и улучшения продукта.
5) Testing - этап тестирования, на котором проверяется, удовлетворяет ли продукт потребностям пользователей, есть ли баги и т.д.
6) Deployment - этап развёртывания решения в production.
После всех этапов цикл повторяется снова.

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


Waterfall (водопад) - ещё одна философия и/или методология ведения проектов, которая практически полностью противоречит Agile-подходу. Её главная концепция - последовательный, линейный и строгий подход к разработке продукта.

Главные принципы Waterfall:
- линейный подход. При Waterfall нет итераций, все этапы работ выполняются в строго заданной последовательности для всего проекта (а не конкретной фичи);
- команда разработки может перейти на следующий этап только, если полностью завершён предыдущий;
- команда разработки может вернуться на предыдущий этап только, если весь процесс начнётся заново;
- каждый этап имеет жёстко определённую дату старта и окончания;
- в отличие от Agile, акцент смещается больше на строго регламентированные процессы, чем на живую коммуникацию между членами команды.

Преимущества Waterfall:
- легко использовать и управлять. Такая методология требует минимальных затрат на обучение команды по её применению;
- высокий уровень дисциплины, так как каждый этап имеет дату начала и окончания. Все дедлайны определены и удобно делиться результатами прогресса с заинтересованными лицами;
- подробная документация. Каждый этап работ задокументирован, и практически любой человек может в любой момент обратиться к документу и познакомиться с внутренней логикой решения.

Недостатки Waterfall:
- высокая чувствительность к изменениям. В отличие от Agile, если, например, на этапе тестирования обнаружится, что какую-то фичу не учли ещё на этапе сбора требований, возвращение к первому этапу может повлечь большие финансовые потери;
- заказчик увидит рабочий продукт только на конечных стадиях разработки. Т.е., в отличие от Agile, где мы можем быстро собрать MVP (minimal viable product) и предоставить его заказчику для использования, при Waterfall заказчику придётся ждать последних стадий разработки. К тому времени, продукт может потерять актуальность и так и не принесёт ценности;
- требует чётко определённых требований от заказчика и других заинтересованных лиц. Если эти люди не смогут заранее определить чёткие требования к продукту, то есть высокий риск, что всю разработку придётся начинать заново.

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

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


Ок, много теории. Приведу пару примеров, когда мы можем использовать Agile, а когда Waterfall при работе с данными.

Давайте представим, что мы, например, специализируемся на построении end-to-end BI-решений для маркетинга. В частности, для интернет-магазинов (e-commerce). Мы заранее можем определить, какие данные и в каких срезах хочет видеть заказчик в будущих дашбордах, так как потенциальный набор отчётов для e-commerce не такой большой. +мы не раз строили такое решение для других клиентов. В этом случае нам отлично подойдёт Waterfall.

Теперь давайте представим, что мы вместе с командой разработки работаем над созданием продукта на базе Machine Learning. Мы не можем заранее определить все фичи, которые в нём будут, понимание будет происходить уже в процессе разработки. В таком случае нам лучше использовать Agile-методологию.

Также есть гибридные модели, такие как Agifall или WAgile. Мы в Promodo, например, при разработке end-to-end решений используем методологию близкую к Agifall. Так как мы специализируемся на решениях для маркетинга и у нас уже есть готовые кейсы по созданию таких решений, за основу взята методология Waterfall. Но для ускорения разработки мы можем частично переходить к следующим этапам, не завершив полностью предыдущий. Такое происходит, например, когда мы понимаем, что в одном источнике данные уже корректно собираются, и мы можем уже загружать эти данные в DWH.

P.S. Следующий пост будет посвящён популярным Agile-фреймворкам - SCRUM и Kanban.

И в дополнение отличная статья, где простыми словами рассказывается про Agile. И классная визуализация, которая наглядно показывает процесс Agile-разработки.

#easy

Всем привет. Неделя была тяжёлой и наконец-то дошли руки до нового поста.

Сегодня поговорим о популярных Agile-фреймворках - SCRUM и Kanban, чтобы у вас уже полностью сложилась картина о популярных методологиях ведения проектов.

Начинаем)

SCRUM - наверное, самый популярный фреймворк для внедрения Agile. Как и Agile, SCRUM основан на итеративном подходе и предназначен для разработки сложных продуктов. Некоторые могут запутаться и задать вопрос: "Так а чем тогда отличается Agile от SCRUM?" Отвечаю: Agile - это набор принципов для ускорения разработки продукта через итеративный подход. SCRUM - это определённый свод правил, которые соответствуют принципам Agile. Т.е. можно сказать, что Agile - это философия, а SCRUM - практическая методология, которая этой философии следует. SCRUM - это Agile, но Agile - это не SCRUM:)
Надеюсь, хотя бы немного понятно.

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

Преимущества SCRUM:
- больше "прозрачности" в проекте. Ежедневные stand-up митинги позволяют всегда держать руку на пульсе. Каждый член команды понимает, что было сделано или не сделано на проекте за предыдущий день и что предстоит сделать сегодня. Такой подход позволяет прогнозировать возможные проблемы и быстро предвосхищать потенциальные проблемы. Благодаря этому, разработка продукта существенно ускоряется;
- повышенная ответственность команды. В SCRUM нет project-менеджера, который будет говорить что делать команде разработки. Здесь упор делается на автономности и профессионализме специалистов, которые могут активно общаться между собой и помогать друг другу. За счёт этого быстрее находятся оптимальные решения на проекте;
- легко учесть изменения в продукте (как и в Agile);
- снижение затрат на разработку. За счёт постоянной коммуникации внутри команды и предвосхищения возможных проблем такой подход позволяет намного быстрее исправлять ошибки, когда это ещё не стоит больших денег.

Недостатки SCRUM:
- нет чётко зафиксированных сроков поставки продукта;
- необходимы высокая экспертиза команды и затраты на обучение;
- риск "неправильного" SCRUM-мастера. SCRUM-мастер - не project-менеджер. Он не должен указывать, что и как делать. Если он захочет взять контроль над командой, эффективность может существенно упасть;
- риск плохо определённых задач. Так как нельзя точно определить, каким будет конечный продукт, иногда очень сложно чётко определить задачи по внедрению различных фич. Здесь возникает риск замедления разработки.

Как происходит процесс разработки при использовании SCRUM:
Как я писал выше, в SCRUM-команде есть чётко определённые роли. Давайте разберём их.
1) Product Owner - как я уже писал в Agile, это человек, который на верхнем уровне понимает, для чего мы делаем продукт и каким он должен быть. Он несёт6 ответственность за общение со стейкхолдерами, формирование требований и пополнение бэклога.
2) Scrum Master - это своего рода тренер команды. Он несёт ответственность за продуктивность команды, за то, чтобы команда следовала SCRUM-процессу, за организацию митингов. Он также общается с владельцем продукта, чтобы обозначить, что всё готово к следующему спринту.
3) Scrum Team - команда, которая ответственна непосредственно за процесс разработки. Обычно она состоит из 5-7 человек и в ней нет жёстко определённых ролей типа "дизайнер", "разработчик", "тестировщик" и т.д. Каждый член команды должен обладать экспертизой во всех этих областях, и каждый может выполнять задачи разного рода.

Цикл разработки по SCRUM включает в себя:
1) Product Backlog. Владелец продукта и SCRUM-команда встречаются, чтобы расставить приоритеты в бэклоге продукта. Бэклог продукта - это не список задач, которые необходимо выполнить. Это список всех желаемых фич, которые могут появиться в продукте. Команда затем берёт какую-то одну фичу и разрабатывает её в процессе спринта.
2) Sprint Planning. Перед каждым спринтом владелец продукта презентует несколько топ-фич в бэклоге продукта и команда решает, над какой фичей они будут работать в следующем спринте и пополняют уже бэклог спринта (это как раз список задач, которые нужно выполнить в течение спринта).
3) Backlog refinement/grooming (доработка/обработка бэклога). В конце каждого спринта команда и владелец продукта встречаются, чтобы удалить или, наоборот, добавить пункты в бэклоге продукта. Они могут расставить приоритетность или разбить требование на более мелкие задачи.
4) Daily Scrum meetings. Ежедневные 15-минутные митинги, где каждый член команды рассказывает, что он сделал или не сделал за предыдущий день и что ему нужно сделать сегодня.
5) Sprint review meeting. В конце каждого спринта команда презентует результаты своей работы на review-митинге. Это живая демонстрация работы продукта, а не отчёт.
6) Sprint retrospective meeting. Также в конце спринта команда проводит особую встречу, где обсуждает, как SCRUM-процесс повлиял на их работу в течение спринта, какие были проблемы и что можно улучшить в процессе работы.


Теперь о Kanban.

Kanban (в переводе с японского "визуальный знак" или "карта") - это визуальный фреймворк для реализации Agile. Kanban развила компания Toyota, которая с помощью него оптимизировала свой процесс производства, смоделировав его по образцу полок в супермаркете. Инженер Тайити Оно заметил, что в супермаркетах имеется ровно столько продуктов, чтобы удовлетворить спрос покупателей. Т.е. запасы товаров будут пополнены только в том случае, когда на полке останется пустое место. Таким образом супермаркеты существенно снижают свои расходы на хранение запасов. Toyota применила эти же принципы на своих заводах. Различные команды создавали карточку (или Kanban), чтобы сообщить, что у них есть дополнительные возможности и они готовы взять больше материалов. Позднее идея Kanban вошла и в IT-среду.
В основе Kanban-фреймворка лежит Канбан-доска. Самая простая может иметь 3 колонки: "to do", "in progress", "done". Если ваша команда, например, занимается построением data lake или data-пайплайнов, Канбан-доска может иметь такие колонки: "backlog", "ready", "coding", "testing", "approval", "done". Каждая карточка на Канбан-доске представляет собой определённую задачу. И эта карточка размещается в нужной колонке в зависимости от своего статуса.

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

Недостатки Kanban:
- риск неактуальности информации на доске. Канбан-доску нужно своевременно обновлять. Иначе, команда может работать с устаревшей и неактуальной информацией;
- риск слишком усложнить Канбан-доску. Здесь может произойти "горе от ума", на доске может быть слишком много этапов, кластеров задач. С такой доской команде может быть некомфортно работать, что снизит скорость разработки решения;
- на Канбан-доске не указываются дедлайны по задачам. Члены команды не знают, как долго должна продолжаться определённая фаза задачи.


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

Как и в случае с Agile, SCRUM отлично подходит для разработки сложных продуктов, когда заранее нельзя точно определить, какие фичи в них должны быть. Вы можете использовать SCRUM, если вы делаете, например, сложные пайплайны данных для Machine Learning, разрабатываете data lake и т.д.

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


P.S. Было бы интересно услышать, какие методологии вы используете на работе или для личных задач. Пишите в комментариях)

Визуализация, которая показывает шаги в SCRUM-процессе.

А вот визуальный концепт Kanban-доски.

Хочу поделиться с вами записью выступления Симо Ахавы на конференции Go Analytics 2019.

Симо Ахава - Analytics Developer из Финляндии, эксперт по Google Analytics и Google Tag Manager.

На выступлении он рассказал о важности коммуникации команды на проекте (как я уже говорил, коммуникация - одна из главных составляющих Agile) и data quality. Здесь он на примере построения data-пайплайнов показал, как проблемы в коммуникации влияют на качество данных и дальнейшую аналитику.

Очень актуальный и полезный доклад. Рекомендую:)

Ребята, всех с наступающим Новым годом! 🎄

Желаю всем в новом году достигнуть личных и профессиональных целей, никогда не сдаваться, ну и здоровья побольше! 😊

Спасибо, что читаете, я это очень ценю)

Ещё в конце лета посмотрел отличный вебинар Романа Бунина, на котором он рассказал про алгоритм проектирования дашборда в рамках образовательной платформы Data Learn.

Роман руководит командой визуализации в Яндекс Такси, и мне очень понравился его методичный и системный подход. Нетехническим пользователям по большому счёту всё равно, какие сложные ETL-процессы вы используете или какой DWH используете (т.е. весь back-end аналитического решения), они в этом как минимум мало разбираются. Им главное своевременно получать достоверную информацию, которую они увидят на дашборде, чтобы этот дашборд был визуально приятным и удобным. Поэтому к разработке BI-решения нужно подходить системно и со всей серьёзностью к процессу.

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

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

В общем, для BI-разработчиков и всех, кто работает с инструментами визуализации - must have для просмотра. Остальным также рекомендую в качестве data literacy)

P.S. В описании вебинара найдёте ссылки на презентацию и на доску в miro с дашбордом canvas, где визуально представлены шаги алгоритма.

А теперь вебинар от меня, который я провёл в конце ноября тоже в рамках Data Learn.

На вебинаре я пошагово разобрал кейс построения сквозной аналитики для маркетинга на Google Cloud.

Если вы владеете базовыми навыками SQL и пишете простые ETL-скрипты на Python, то после просмотра сможете тоже построить такую инфраструктуру.

Примерно такое же решение можно сделать на Amazon Web Services и Microsoft Azure.

Будут вопросы - задавайте)

P.S. Интересно услышать, кто с каким облаком работает и какие преимущества для себя нашёл. Пишите в комментариях.

Архитектура решения, про которую я рассказываю на вебинаре.

Думаю, мы максимально подробно (насколько это возможно) разобрали 2-й фактор эффективности работы с данными - "Процессы".

Мы неплохо познакомились с пирамидой потребностей Data Science, с философиями / методологиями ведения проектов, и я привёл пару вебинаров, которые касаются системного подхода работы с данными.

Пора приступать к 3 фактору - "Структура".

И появилась у меня такая идея: сделать 1 или 2 поста на эту тему в формате интервью с несколькими опытными специалистами, которые поработали в компаниях разных размеров. Узнать, из каких ролей состоит команда по работе с данными в их компаниях и какие функции они выполняют.

Как вам такой формат?

Начинаем нашу серию постов о 3 факторе эффективности работы data team - "Структура".

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

Серия постов будет в формате 1-2 мини-интервью на пост, чтобы не было каши.

Первым человеком, с которым я пообщался на эту тему, был Дмитрий Аношин - Role Senior Data Engineer в Microsoft (до этого 5 лет работал в Amazon). Дима дал краткую сводку по тому, на каких проектах он работал в Amazon, над чем сейчас работает в Microsoft, какие роли были в командах проектов и с какими проблемами в структуре он столкнулся.

Цитирую:
"Смотри: Amazon:
1) Amazon Marketplace: Role BI+Data Engineer, работал с BIE
В качестве BI:
- установка Tableau Server
- Миграция SQL+Excel отчетов на Tableau
- Self-Service implementation
- Office Hours + Training (Adoption of BI)

В качестве Data Engineer:
-Миграция on premise Oracle DW + PL/SQL ETL на Amazon Redshift, работал с DBA, SDE
-Поиск и выбор Cloud ETL -> Matillion ETL и миграция всего с PL/SQL на ETL + переработка бизнес логики
-Использование AWS EMR+Spark (PySpark) для решения задачи с обработкой веб логов, так как ETL+DW просто не вывозили объем. Результат Spark был в Parquet в S3 (по сути озеро данных) и доступ к нему был через Athena и Redshift Spectrum
- Streaming данных из DynamoDB в real-time через DynamoDB Streams + Kinesis Firehose + Glue

2) Amazon Alexa BI: Role Data Engineer, работал с Product Managers, SDE и BIE
- Внедрение ETL Matillion ETL
- Создание тестовой/боевой системы в ETL и DW (Amazon Redshift)
- Оптимизация Tableau Data Sources (в среднем по 150млн строк было в одном data source)
- Разработка новой платформы для Alexa c названием Sputnik. С использованием новых нод Redshift RA3. Объем данных планировался 120ТБ в год.
- Работал вместе с Data Science над созданием Alexa Churn модели; моя задача была масштабировать модель и подготовка данных на AWS SageMaker

3) Amazon Customer Behaviour Analytics: Role Data Engineer, работал с ML, Data Science + Product Managers
- создание Big Data системы для ML модели. По сути задача системы была - feature engineering, нужно было процедить 700ТБ данных за год (clickstream + backend). Использовали EMR+Spark, логика была на SparkSQL и иногда Scala.
- моя задача была автоматизация всей этой истории, ее безопасность, privacy (GDPR и тп), и качество данных через Spark библиотеку deeque
- Дальше они уже сами брали данные через GPU EC2 instance и строили нейронную сеть (deep learning)

4) Microsoft Xbox game studios: Role Sr. Data Engineer, работаю с BIE, ML, Producers (вместо Product Managers), Artists (designers) и инженерами (SDE).
-моя задача создать новую платформу под новую игру, планирую делать Delta Lake на Databricks (активно изучаю)
-сейчас пока все на HDInsight+Hive (процессинг сырых данных) + SQL Server (dimensional model)
-дашборды в Power BI (который я не люблю после Табло)
-также для операционной аналитики Azure Data Explorer (аналог Splunk и Elastic Search)
-активно используем Azure DevOps (Git + Pipelines) и Microsoft Visual Studio в качестве IDE. Разбираюсь в CI/CD, очень крутая тема конечно, но надо время, чтобы въехать."

Главная проблема в структуре, с которой Дима столкнулся - когда в одной команде работают и разработчики программного обеспечения, и дата-инженеры. Он, как дата-инженер, выступал за простоту решения в виде использования ETL-инструментов с графическим интерфейсом, которые при этом полностью решали задачу проекта, а разработчики больше выступали за использование кода. В общем, договориться было сложно)Это тормозило разработку решения и потом было сложно найти, кто прав, кто виноват.

В дополнение видео от Димы о его 5-летнем опыте работы в Amazon.