Записал подкаст с Дмитрием Аношиным — инженером данных Amazon и автором канала Инжиниринг Данных и основателем проекта Datalearn.

Разговор получился довольно философским, много про развитие специалиста и путь Димы. У Димы очень интересный подход к построению карьеры — супер креативный и проактивный. Тот случай, когда построение нетворкинга явно дает свои плоды.

В этот раз снова ничего не смотрели, поэтому можно просто послушать подкаст. Но! В прошлый раз, когда я спрашивал про аудио-подкаст или видео, мне написала коллега, что ей бы вообще подошёл бы текст. Я подготовкой текста заниматься не готов и она решила мне с этим помочь. Если вам нравится текстовый формат — пишите и может сделаем это постоянной практикой. Так что за конспект, все спасибки Наташе Shirosayuri! Текст ниже под видео.

0:00 Как дела, чем занимаешься?

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

2:01 Почему сейчас сложнее войти в профессию?

Я начинал десять лет назад, и мне повезло — я занимаюсь одним и тем и развивался вместе с индустрией. Когда я начинал было IBM SPSS, Business Object, MIcroStrategy, Cognos, Oracle BI. Сейчас инструментов очень много, поэтому разобраться в них по-началу может быть сложно. Ещё очень много проблем с вордингом — все пишут в вакансиях по-разному и не понятно, чем именно будешь заниматься.

6:03 Как ты переехал и искал работу?

У меня была идея фикс — что нужно переехать. Я активно занимался нетворкингом — писал всем вендорам и пытался найти связи, хотел очень хотел уехать в Tableau в Австралию, но не получилось. Здесь важный момент, что мой подход: я пытаюсь сразу, если у меня доступ куда-то есть, максимально общаюсь везде, пишу и т. п. Например, я находил какие-то интересные презентации, которые потом переделывал, переписывал, публиковал от себя. Для своего блога кривого что-то писал. Даже заводит инстаграм аккаунт @tableau_official (у них его тогда ещё не было) и довольно долго его вёл, это было где-то в 2012-2013.

Ещё, скажем, я не могу назвать себя экспертом в чём-то одном. У меня такой подход: я пытаюсь максимально широко брать, там-сям, самую суть выдёргивать из этого всего и как-то использовать. Я даже иногда людям завидую, которые занимаются, например, только Tableau: они могут классные вещи делать. Я его поверхностно знаю, могу быстро разобраться и, если надо, научиться, но красивый дашборд я не сделаю. Я знаю, где посмотреть, но сам сделать с ходу не смогу.

13:36 Аналитик — специалист на все руки, или должен хорошо знать только какую-то область?

Сразу скажу, что западный рынок очень сильно отличается. Думаю, это связано с тем, что у компаний нет таких жёстких условий экономить на всём деньги. Доходит вплоть до того, что есть специалисты в командах, которые занимаются только визуализацией данных. Человек умеет круто нарисовать дашборд в Tableau. И он при этом очень востребованный. В Америке, в Европе ты найдёшь работу со знанием только Tableau, но это всё равно тебя загоняет в рамке. Например, я в Amazon’e практически каждую неделю провожу собеседования, не важно, data engineer, BI-engineer. Там огромный список компетенций. Они хотят видеть, чтобы человек sql знал, моделирование, хотя оно ему даже и не нужно и в Amazon’e его не используют. В общем, если компания маленькая — то нужно быть специалистом на все руки, если большая — то, круто быть узким спецом, но это ограничивает твой поиск.

22:03 Чем занимается data engineer в Amazon’e?

Я хотел рассказать про data engineer’a, откуда это появилось. Потому что я всегда был BI-разработчиком. Как я говорил, когда я начинал работать там было всего 4 разновидности вакансий. И мне нравилось быть BI-разработчиком, потому что на вопрос, а это кстати полезный ответ на собеседовании, когда у тебя спрашивают: «почему ты любишь быть BI-разработчиком?», — ты легко отвечаешь: «А я между IT и бизнесом». Когда переехал в Канаду, работал здесь BI-разработчиком и искал только такую позицию, откликнулся в Amazon на эту вакансию, а когда меня взяли на работу, у меня титул был BI-разработчика, а роль в системе — дата инженер. Я внимания тогда не обратил, первые два года вообще не парился, кто такой дата инженер.

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

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

В целом у для Data Engineer’s в Амазоне есть три типа заказчиков: bi-разработчики, software development engineer и команды machine learning .

Для первых — результат работы это дашборды в Табло. Здесь используется продуктовый подход, для каждого дашборда есть product-менеджер, который отвечает за фичи. Нужно добавить фильтр — это новая фича твоего продукта. Менеджер приходит и говорит: нужно добавить новую фичу. Для тебя, как для дата-инженера, это значит: найти данные. Может быть их трансформировать, построить пайплайн, загрузить их себе. Придумать, как их соединить с тем, что уже есть, всё это автоматизировать, проверить, и предоставить доступ для разработчика bi, чтобы он взял этот дашборд докрутил.

Другая популярная история — с командами разработчиков, software develompent engineers. Если они строят кастомный интерфейс (вместо табло делают свой фронтенд), то им нужны данные. Задача дата-инженера — приготовить им данные и автоматизировать, чтобы их приложение смотрело куда-то. Он может использовать какой-нибудь sql-engine, и тебе надо подготовить всё для этого. А потом приходит какой-нибудь менеджер и говорит, что пользователи захотели новую фичу. Например, искать по тексту. Или, сказали, что когда ищут по тексту, то слишком долго грузится. Значит надо сделать так, чтобы грузилось быстрее. Либо подобрать другой движок, либо другую технологию. Тебе, как дата-инженеру, надо отвечать на это всё. С разработчиками работать сложнее всего потому что у них свой подход на создание пайплайнов, хранилищ данных, если у них вообще термин такой есть: у них структуры данных, структуры хранения. С ними больше всегда конфронтаций: кто прав, кто виноват, как делать. Это не лично моё мнение, я говорил с другими дата-инженерами. Все говорят, что это тяжело. В Amazon’e сейчас все эти историю про работу с разработчиками-программистами идут в мой опыт. Так что когда меня будут спрашивать про сложные ситуации: «Опишите ситуацию, когда вы с кем-то поспорили или случилась сложная ситуация, как вы из неё выбрались?» Я сразу расскажу, что была команда разработчиков, мы с ними совсем не могли сработаться, но в итоге нашли общий язык. Они говорили про свои concern-ы, я слушаю их, мы пишем архитектурные документы, они их ревьюируют, оставляют комментарии, я отвечаю. Получается коллаборация. Это мегакейс, как мы работаем с программистами.

Последний кейс — это работа с data scientist и machine learning. С data scientist’ами работать лучше всего. Хуже всего с программистами, Когда мы работаем с data scientist, они в нас души не чают, потому что они фокусируются на проблемах. Берут dataset’ы, например, в питоне начинают что-то делать, чтобы посчитать модель. У них возникает проблема номер 1: на ноутбуке не хватает памяти чтобы взять большой dataset, им надо это масштабировать. Они не знают, как в облаке дать разрешение на доступ из другого аккаунта. Ты им помогаешь, и они нереально благодарны. Получается, задача дата-инженера когда он работает с data scientist’ом: убрать road blockers для ребят и помогать отправить модель в production. Таким образом, дата-инженер — это человек, который поможет data scientist’у решить все эти проблемы. Например, в моей новой команде нет других дата-инженеров, нет других разработчиков ПО, есть только data scientist’ы и product-менеджер. Таким образом, у меня теперь полная свобода действий.

43:34 Как у вас организован Data Governance?

В Amazon’e со скоростью, с которой мы двигаемся и с какой фичи сыпятся, — мы мало этим занимаемся. То есть главный concern — безопасность и качество данных, чтобы показатели были правильные и как ты собираешься проверять эти данные. Я считаю, что data governance это комплекс. Туда входит и безопасность, и качество, то есть ты про это переживаешь. Ещё один аспект — это data catalog. То есть у тебя есть модель данных, описание. В Amazon’e есть внутренние инструменты, где ты можешь хранить каталог данных. Но поему опыту, несмотря на то, что тебя часто спрашивают про модели данных, у тебя по факту не всегда хватает времени их сделать. Это не моя сильная сторона, теоретически и про необходимость я знаю, но это как бы trade off для меня. Либо скорость, либо надёжность.

47:05 Какие есть рекомендации для разработки модели данных?

Тут всё просто, я всю логику храню в базе данных. Я должен показывать в Tableau именно тот кусок, который будет удобно работать в Tableau. Если им не подходит длинная или широкая таблица, значит я такую таблицу не должен делать, иначе неразбериха потом будет. Мне будет лучше сделать несколько таблиц. Мы часто делаем в Tableau data blending, и ты можешь уже и разную гранулярность показывать на конкретном view, на конкретном дашборде можешь сджойнить и показать.

Я не фанат огромных таблиц. Они классные, когда у тебя row level data, когда ты в staging эти данные собираешь, пусть они будут любого размера, но когда ты будешь уже показывать метрики, то я постараюсь максимально разграничить. В таблице должны лежать метрики, аддитивные друг с другом. Иначе, если мы туда положим разные вещи, и будем думать, что бизнес-пользователь знает, как с этим работать, он обязательно сделает всё наоборот. Моя задача таким образом: максимально разложить на кусочки.

51:28 Экстракт или live

Про это я могу рассказать. Я же был Tableau администратором. Когда мы работаем с редшифтом, у него есть проблема concurrency — сколько одновременных запросов он может обрабатывать. Если у тебя много пользователей и ты им даёшь live-connection, получается, что каждое твое изменение фильтра dimension автоматически отправляет запрос в хранилище данных. Что не круто. Для меня в Tableau всё очень просто: если я могу создать экстракт — я создаю экстракт. Сам по себе экстракт становится кэшем, который позволяет нам работать с Tableau во фронтенде, чтобы не ждать запросы. Я всегда делаю экстракт, и ставлю на расписание.

Экстракт состоит из двух частей: сколько работает запрос, и может ли Tableau сервер его переварить. Если не может, значит надо уменьшать историю, увеличивать агрегаты. Если ничего не помогает, переключаюсь на live. Но live это история о трёх dimension’ах и двух показателях для огромного dataset’а. Потому что, например, у нас есть одна маленькая таблица, в ней миллиарды строк, парень пример показывал про 21 миллиард строк, и у него там несколько метрик в dimesion’ах. Когда он меняет фильтры, то Tableau за несколько секунд всё меняет. Я в книге писал главу big data для tableau, там очень простой подход: если у тебя big data, то Tableau делает рендеринг, отображает результат, а весь heavy lifting идёт в твой data engine, хранилище данных, hadoop, не важно что. Даже спорить не надо «нужно»/«не нужно», потому что мне кажется это best practices: экстракт для всего, только если работаете с огромными данными, то тогда live-connection.

57:49 Блиц

— Озеро или облако?
— Озеро.

— Редшифт или Вертика?
— Редшифт.

— Редшифт или Кликхаус? Ну вдруг, мало ли.
— Редшифт. Ну, если бы я был в России, я бы взял Кликхаус. Хотя я с ним не работал, но как я понял он для продвинутых дата-инженеров, надо брать Кликхаус, Аэрфло и Редаш. Или, если есть деньги, Табло. И всё это на Питоне сделать! Тогда ты такой модный образцовый хипстер.

— Виктория или Бостон?
— Виктория.

— «Сиквел» или «Эскьюэль»?
— «Сиквел».