Разработчик dwh что это
Что такое Data Warehouse (DWH) и зачем крупному бизнесу корпоративное хранилище данных
Данные — новая нефть. Чем больше их у компании, тем эффективнее она сможет привлекать новых клиентов, разрабатывать стратегии развития и укреплять свою позицию на рынке.
Для хранения данных используются специальные типы хранилищ — Data Warehouse. Разберемся, чем DWH отличается от других способов хранения данных, как используются такие решения и для каких компаний они актуальны.
DWH: чем отличается корпоративное хранилище от обычных БД
Бизнес стал активно интересоваться корпоративными хранилищами еще в конце прошлого века. Их внедряли для увеличения скорости реагирования на изменения, мониторинга показателей эффективности и автоматизации процессов. Разные приложения отвечали за разные процессы: одни использовались для финансовых операций, другие — для координации цепочек поставок, третьи помогали анализировать показатели продаж.
Однако такой подход привел к тому, что ключевые данные бизнеса хранились разрозненно. Компаниям требовалось решение, которое бы позволило анализировать информационную картину целиком, а не данные из разных систем по отдельности.
Для решения этой проблемы был создан особый инструмент — корпоративное хранилище данных, или Data Warehouse. Фактически DWH — это предметно-ориентированная база данных, которая консолидирует важную бизнес-информацию и позволяет в автоматическом режиме подготавливать консолидированные отчеты.
Data Warehouse — это единое корпоративное хранилище архивных данных из разных источников (систем, департаментов и прочее). Цель Data Warehouse — обеспечить пользователя (компанию и ее ключевых лиц) возможностью принимать верные решения в ключе управления бизнесом на основе целостной информационной картины.
DWH — это не просто база данных
Корпоративное хранилище данных отличается от обычных БД, используемых в бизнесе, по нескольким параметрам:
Как бизнес использует DWH
DWH — не только склад важных данных компании, но еще и основа бизнес-аналитики (BI). Именно из корпоративного хранилища компания получает сведения, необходимые для принятия управленческих и стратегических решений.
Давайте на простом примере посмотрим, как это работает.
Корпоративное хранилище позволяет не искать решение вслепую, а выявить источники проблемы. Обычные базы данных просто не позволяют этого сделать, потому что:
Почему DWH — эффективный инструмент аналитики
Корпоративное хранилище играет роль большого склада данных. Давайте посмотрим, в погоне за какими возможностями компании организовывают DWH.
Структура DWH
Data Warehouse состоит из нескольких уровней:
DWH и Business Intelligence
Актуальные инструменты бизнес-аналитики (BI) вкупе с возможностями DWH позволяют принимать управленческие решения с гарантированным результатом. Благодаря эффективному анализу больших массивов данных менеджмент компании также может выдвигать гипотезы, построенные на реальных бизнес-показателях, и тестировать их.
Data Warehouse не только помогает решать конкретные прикладные задачи (например, увеличение прибыли, снижение издержек), но и выстраивать стратегию развития компании на основе data-driven подхода.
DWH как продукт: платформа, инструменты, масштабирование команды
Меня зовут Женя, в Авито я руковожу юнитом DWH. Мы отвечаем за работу с аналитическим хранилищем, которое помогает нашим сотрудникам принимать решения, основанные на данных.
В статье расскажу, как продуктовый взгляд помогает нам развивать DWH и быть полезнее для пользователей. Речь пойдёт про появление платформенных инструментов и рост проникновения аналитики в компании, а также про реорганизацию команды и перераспределение задач. Будет больше о процессах и практиках, чем о хардкорных технологиях. Но и технологии немного затрону.
Зарождение аналитики в Авито
Аналитика в Авито начала активно развиваться в 2013 году. Мы хотели сделать расширяемую BI-платформу, чтобы растить бизнес на основе данных. Ключевым требованием к платформе стала практически неограниченная расширяемость — как по объёмам и скорости сбора, хранения и обработки данных, так и по их сложности.
Начали с сочетания Vertica и Tableau, чтобы осуществить быстрый старт. На тот момент у нас было порядка 50 Tb данных, 6 дата-инженеров и 25 пользователей-аналитиков. Подробнее почитать про задачи и выбор решения можно в кейсе Vertica.
Две типовые задачи, которые решала DWH-команда — это построение витрин и загрузка данных (ETL).
Витрины. Задачи на построение витрин выглядели как описание структуры отчёта, который хотелось получить. Нужно было разобраться с бизнес-логикой, закодить её на SQL и Python, и дальше внедрить это в прод. Такие задачи занимали достаточно много времени: заказчикам приходилось ждать спринтов разработки, а нам — заниматься рутиной.
ETL. Аналогичные тенденции прослеживались и в ETL-задачах, связанных с загрузкой данных. В них тоже описывалась бизнес-логика: что и куда загрузить. Команде DWH приходилось писать типовой код, чтобы реализовать требуемую раскладку данных в хранилище.
Платформизация
На первом этапе перед нами встали два вопроса:
Как справиться с ростом задач, если Авито и его аналитика активно растут?
Как не погрязнуть в рутине?
Ответить на эти вопросы нам помог такой подход как платформизация. Мы решили сфокусироваться на создании инструментов, с помощью которых пользователи смогли бы сами решать свои задачи. Мы при таком раскладе могли сосредоточиться на том, чтобы развивать единую платформу, следить за её стабильностью и помогать пользователям там, где что-то не получается.
Мы хотели сделать так, чтобы с помощью нашей инфраструктуры можно было решать любые аналитические задачи. Тогда пользователям не приходилось бы ждать спринтов разработки, а нам — тратить время на реализацию повторения бизнес-логики.
После внедрения платформенных инструментов, решения типовых задач стали выглядеть иначе.
Витрины. Задачи, связанные с витринами, стали представлять из себя пул-реквесты. Пользователь-аналитик может создать пул-реквест сам, написав код на SQL. Чтобы расчёт новой витрины не нарушил работоспособность всего хранилища, появились автотесты, которые проверяют стандарты кода, оптимальность запросов, потребление технических ресурсов и тому подобное. Если тесты прошли, то мы в команде DWH мёржим реквест, и он встаёт на регулярный расчёт.
Через механизм пул-реквестов удалось создать больше 800 ежедневных расчётов. Также мы создали инструмент оркестрации, который позволяет управлять зависимостями расчётов и считать их в оптимальном порядке.
ETL. Для решения ETL-задач мы сделали механизм, с помощью которого аналитики могут делать раскладку данных самостоятельно. В таске в Jira фиксируется наименование сервиса, бизнес-смысл данных и сценарии их использования. А сама бизнес-логика реализуется в пул-реквесте, он также проходит тесты и мёржится в прод.
В пул-реквесте нужно описать внешний источник, как экстрактить данные и как раскладывать их в хранилище. Все загрузки строятся в SQL, можно прозрачно видеть, что куда раскладывается и управлять версиями в Git.
Подход платформизации сработал и помог решить часть проблем. Чтобы улучшать созданные инструменты и масштабироваться дальше, мы решили применить продуктовый подход к DWH.
Продуктовый подход к DWH
Продукт — это то, у чего есть целевая аудитория и что приносит этой аудитории ценность. Основные пользователи DWH — это аналитики, инженеры и менеджеры продукта. Верхнеуровневая ценность нашей команды для них в том, что мы помогаем принимать решения на данных. Это важная задача, поскольку Авито — data-driven компания. Мы используем данные и метрики для решений в продукте и постановки целей всех команд.
Для взгляда на DWH как продукт мы использовали две практики: user story mapping и customer development.
User story mapping. Эта практика помогла нам визуализировать и лучше представить продукт и задачи, которые мы решаем. Мы составили карту, где отразили всё, что делают наши пользователи. В Miro для этого есть классный плагин.
Сначала мы выписали верхнеуровневые задачи. Например, задача на проверку любой гипотезы. Дальше подумали, на что раскладывается данная задача и записали это в заголовки столбцов. Нужно:
Понять, как ими пользоваться.
Получить ответ на изначальный вопрос.
По каждой части задачи мы накидывали идеи о том, как её сейчас решают пользователи и как можно её реализовать, если готового инструмента ещё нет.
Так мы получили список активностей. Например, чтобы провалидировать данные нужно понять, когда они корректно рассчитывались в последний раз. Если месяц назад, то пользоваться такими данными не очень корректно. Получившийся список активностей и хотелок можно ранжировать и выделять блоки, которые пойдут в MVP, спринт или квартал. Для этого нужно нарезать куски по важности.
Концепцию того, как можно это сделать, я подсмотрел у Джеффа Паттона. При нарезании возникают вопросы с тем, какого объёма должна быть каждая часть предстоящей работы. Мне понравилась аналогия с тем, чтобы вместо свадебного торта делать капкейки. Финальные задачи должны представлять собой ценные части продукта, которые сами по себе полезны, но изготовляются гораздо быстрее, чем весь продукт в целом. Используя такую аналогию, можно декомпозировать истории и структурировать продуктовый бэклог.
Customer development. Практику customer development мы использовали, чтобы понять, как люди пользуются DWH, лучше понять их потребности, проверить свои гипотезы и собрать обратную связь.
Идея состоит в том, что мы задаём пользователям определённые вопросы. Они помогают понять, в чём люди видят ценность продукта. Вот несколько примеров таких вопросов:
В чём для вас главная ценность продукта?
Что изменится, если продукта не будет?
Какой продукт служит альтернативой?
Есть ли факторы, которые мешают вам пользоваться текущим решением?
Несколько советов по проведению интервью с пользователями:
Нужно заранее представлять, что мы хотим получить от встречи. В этом поможет предварительно написанный сценарий или хотя бы канва разговора.
Все вопросы должны быть открытыми, ведь прежде всего мы хотим услышать развёрнутый ответ.
Бывает полезно уточнить, правильно ли мы поняли респондента. Поможет формулировка «правильно ли я понимаю, что?»
Важно задавать вопросы про прошлое, а не про будущее.
Мы интересуемся фактами, а не мнениями и оценками.
Полезная практика — «5 почему», чтобы докопаться до сути проблемы.
Про проведение интервью и корректное формулирование гипотез мы писали в статьях UX-лаборатории. Если вам интересна эта тема, можно почитать разбор тестовых заданий на стажировку 2020 года и похожий разбор 2021 года. На основе интервью с пользователями DWH мы сформулировали гипотезы о том, что можно сделать в следующей итерации.
Решение проблем пользователей
Во время общения с пользователями мы выявили ряд проблем, которые начали постепенно решать. Приведу пару примеров.
Проблема поиска данных. Наше хранилище росло в разы каждый год. Данных становилось всё больше, всё больше разных таблиц и источников. В какой-то момент стало очень сложно ориентироваться в данных и понимать, как тот или иной кусок продукта логируется. Пользователям DWH приходилось искать ответы в чатах в Слаке. Вот что говорили люди:
Данные искать сложно. Чаще всего приходится искать человека, который знает, где что лежит и как работает.
Регулярно приходится обращаться в чаты в Слаке, чтобы понять, есть ли та или иная информация в Вертике. Мне кажется, очень не хватает описания ДДС-таблиц.
Мы хотели упростить работу с хранилищем и упростить процесс валидации данных. Так появилась система поиска dwh-docs.
Искать таблицы и отчёты по поисковому запросу. Dwh-docs ищет по данным из документации, Jira-задачам, коду витрин, названиям таблиц и колонок.
Документировать свои таблицы и отчёты.
Видеть некоторые аномалии в данных. Это помогает пользователям понять, что теми или иными данными сейчас, возможно, не стоит пользоваться, потому что в них есть известная проблема.
Подписываться на объекты. Подписка позволяет получить пуш-уведомление, если что-то произошло с твоими данными.
Проблема DBeaver. Другая проблема, с которой сталкивались наши пользователи, была связана с созданием запросов и вообще порогом входа в хранилище. Мы использовали бесплатный SQL-клиент DBeaver, который стал неудобен с появлением высокоуровневых бизнес-пользователей.
Интерфейс неудобный, сложные настройки, после обновления периодически ломается, например, работа с параметрами. Трудно настраивать клиент самому, аналитик помогал выбрать драйвер и ещё что-то. Не так много документации в интернете.
DBeaver достаточно сложно настраивать. Мы ставили себе вызов демократизировать аналитику и делать её доступной всё более широкому кругу пользователей. Решить этот вызов с использованием готового инструмента было проблематично. Мы решили создать свой SQL-клиент в браузере и поддержать в нём все нужные базы данных: Vertica, ClickHouse, PostgreSQL. За основу взяли sqlpad.io и кастомизировали под себя.
Новый клиент позволяет нам шарить запросы. Приведу пример. Менеджер продукта, у которого возникает вопрос по данным, обычно идёт к аналитику. Аналитик пишет запрос и отправляет ссылку на этот запрос продакту. По ссылке тот может увидеть и сам запрос, и его результаты. В будущем менеджер продукта может поменять какие-то параметры (например, дату) и ответить на вопрос уже самостоятельно. Эта штука действительно сработала, и нам удалось понизить порог входа к данным.
Помимо этого мы добавили ещё несколько фич, которые позволяют удобнее работать с отчётами: строить витрины и интегрироваться с Tableau. Например, по нажатию кнопки можно создать источник данных в Tableau, либо перейти в веб-версию.
Аналогично тестам на витрины, в sqlpad мы добавили проверки планов adhoc-запросов. Таким образом мы страхуемся от того, что пользователь обрушит работу хранилища плохим запросом. Также мы можем делать подсказки, как улучшить производительность запроса.
Внедрив SQL-клиент мы заметили, что доля пользователей DWH среди авитовцев выросла. А новые сотрудники теперь пользуются только sqlpad и забыли про DBeaver.
Проблемы структуры
На этапе, когда мы перешли к созданию единых платформенных инструментов для пользователей аналитики, DWH развивали две команды: dwh-growth и dwh-infra.
Люди в dwh-growth фокусировались на том, чтобы наращивать скорость решения аналитических задач. Они помогали искать данные, строить отчёты, проверять гипотезы, развивали фреймворки и придумывали, что делать, если фреймворка для конкретной задачи ещё нет.
Команда dwh-infra отвечала за развитие инфраструктуры. Для работы высокоуровневых инструментов важно, чтобы платформа корректно функционировала, базы быстро отвечали на запросы, а сами данные были качественными и очищенными от ботов. Другая активность инфраструктурной команды была связана с уходом в realtime.
До какого-то момента всё было неплохо, но затем вскрылись проблемы такой структуры. У первой команды было множество пользовательских контекстов, и ей было очень сложно параллельно развивать ещё и инструменты. При этом у второй команды наоборот было мало взаимодействия, и ей сложно было фокусироваться на потребностях пользователя.
При этом инфраструктура всё усложнялась, а пользователей становилось всё больше: как я говорил, мы вовлекали в работу с данными не только аналитиков, но и инженеров и менеджеров продукта. Юнит DWH рос, и нам нужно было как-то масштабироваться, декомпозировать текущие команды, выбирать верную стратегию и цели. Здесь мы решили применить идею DWH как продукта не только к развитию хранилища, но и юнита.
Разделение команды
За основу для декомпозиции команд мы взяли высокоуровневые задачи пользователей из user story map. В теории получилась такая организация:
Название команды
Главная задача
Решать проблемы пользователей по интеграции с DWH.
Отвечать за создание регулярной отчётности и создание витрин.
Отвечать за проверку гипотез и качество данных.
Для каждой команды мы сформировали пул задач, над которыми она будет работать. Туда вошли и пользовательские задачи и декомпозированные внутренние.
Задачи команды Integration:
Задачи команды Datamart:
Задачи команды Usage:
С разделением команд, основанном на высокоуровневых задачах пользователей, мы пришли к тому, что:
В каждой команде есть и некоторая рутина, и вдохновляющая цель. За счёт того, что есть рутинная часть, есть и стимул к автоматизации и тому, чтобы создавать инструменты, которые позволят упростить решение таких задач.
Команда фокусируется на определённом экспертном поле: загрузке данных, построении регулярных отчётов, быстрой проверке гипотез.
Распределение задач достаточно прозрачное.
Получилось поделить взаимодействие с пользователями, и мы можем масштабироваться.
Дальше нужно было распределить DWH-инженеров в новой структуре. Мы предложили самим ребятам выбирать новую команду. При этом определили некоторые граничные условия: выбрали лидов команд, определили, сколько человек должно быть в какой команде и какие у них цели. Дальше итеративным процессом предлагали сотрудникам выбрать команду и сами ребята оценивали, как это получилось. Когда получилось хорошо, и все были с этим согласны, мы завершили процесс.
Идея здесь в том, что ответственность за работу команды лежит на команде. Отдавая ребятам возможность выбирать самим, мы покрыли много дополнительных факторов, которые могли не учесть, если бы делили людей самостоятельно.
При этом важно подробно объяснить сотрудникам, что происходит. Это необычный процесс, поэтому нужно заложить время на то, чтобы пообщаться и снять сомнения с тех, кто не сможет определиться с выбором. Мы предложили ребятам выставить приоритеты по тому, в какую из трёх команд они хотели пойти чуть больше или чуть меньше. Дальше пришли к финальному решению. Пока кажется, что деление было успешным.
Выводы и планы
Мы пришли к такому взгляду на DWH как на продукт, у которого есть два типа пользователей:
Те, кто производят данные. Это более технические пользователи — аналитики-контрибьюторы и инженеры, которые загружают данные и строят над ними отчёты.
Те, кто используют данные. Менеджеры продукта и аналитики, которые ищут данные, проверяют гипотезы и отвечают на вопросы бизнеса.
Сейчас мы собираем данные в DWH более чем из сотни внутренних и внешних источников. Наше хранилище выросло до 1 Pb, мы по-прежнему используем Vertica, к которой добавился ClickHouse, куда мы вынесли весь ClickStream. Для визуализации используем Tableau, сейчас в нём порядка 3300 отчётов. У нас 300 внутренних пользователей и около 50 сервисов, которые получают и используют данные из хранилища автоматически.
То, куда мы хотим двигаться дальше, можно описать в двух словах: демократизация аналитики. Мы хотим, сделать так, чтобы работа с данными и принятие решений на данных было как можно проще для высокоуровневых пользователей. Для этого мы будем продолжать развивать и продвигать концепцию self-service и доведём ETL и систему пересчётов до того уровня, чтобы все пользователи могли сделать простую задачу самостоятельно.
Другая важная проблема связана с доверием к данным. Мы хотим сделать понятный и прозрачный критерий доверия, который будет иметь численное отражение в системе. Третье направление, куда мы идём, связано с realtime-аналитикой. Мы уже очень хорошо умеем строить аналитику T-1, но этого недостаточно. Мы сняли технические блокеры с этой задачи, внедрив ClickHouse, но дальше предстоит внедрение продуктового применения наших решений.
Мы планируем развивать аналитику под ключ, ведь Авито ещё больше растёт, и у нас появляются всё более крупные бизнес-юниты. У них могут отличаться SLA и они могут требовать своей инфраструктуры. Также хотим развивать внутреннюю IDE для работы с данными, написания запросов и скриптов. А чтобы бороться с проблемами, которые вызывают рост и масштабирование, а также поддерживать отказоустойчивость инфраструктуры, планируем рассмотреть разные облачные решения и работу с холодными данными из других систем.
Что такое DWH и почему без них данные компании почти бесполезны
Тем, кто работает в крупном бизнесе, периодически приходится слышать три магические буквы — DWH. Узнав расшифровку этой аббревиатуры — data warehouse, можно догадаться, что это имеет отношение к данным. А вот чем DWH отличается от простых баз данных, почему вокруг них снуют рои бизнес-аналитиков и зачем вашей компании иметь такую штуку — это всё еще непонятно. Разбираемся в статье.
DWH — что это и в чем отличие от баз данных
Data warehouse — склад всех нужных и важных для принятия решений данных компании.
Но есть же всякие базы данных внутри фирмы, разве они не DWH? Например, СУБД с клиентами, складскими запасами или покупками. Где разница между обычной базой данных и DWH?
Короче говоря, DWH — это система данных, отдельная от оперативной системы обработки данных. В корпоративных хранилищах в удобном для анализа виде хранятся архивные данные из разных, иногда очень разнородных источников. Эти данные предварительно обрабатываются и загружаются в хранилище в ходе процессов извлечения, преобразования и загрузки, называемых ETL. Решения ETL и DWH — это (упрощенно) одна система для работы с корпоративной информацией и ее хранения.
Что дают DWH-решения для BI и принятия решений в компании
Понятное дело, что просто так тратить деньги и время на консервирование кучи разных записей, которые и так можно накопать в других базах данных, никто не станет. Ответ заключается в том, что DWH необходима для того, чтобы делать BI — business intelligence.
Что такое BI с DWH? Бизнес-аналитика (BI) — это процесс анализа данных и получения информации, помогающей компаниям принимать решения.
Если бы такого аналитического отчета не было — управленцам пришлось бы искать проблему наугад.
Логичный вопрос: казалось бы, зачем держать для этого всего DWH? Аналитики вполне могут ходить в базы данных разных систем и просто выдергивать оттуда то, что им надо.
Ответ: так, конечно, тоже можно делать. Но — не нужно. И вот почему:
Для работы с большими данными используют различные решения, обрабатывающие информацию из DWH. SAS, VK Cloud Solutions (бывш. MCS) и другие компании предлагают различные варианты коробочных и облачных решений под такие задачи.
Экспертиза GlobalCareer: подбор DWH-специалистов
Как мы подбираем разработчиков, специализирующихся по DWH.
Корпоративные хранилища данных (КХД, Data Warehouse, DWH) очень востребованы в финтех-компаниях, торговле и телекоме, а в последнее время ими стали пользоваться и производственные холдинги, активно внедряющие IT-технологии. Поэтому запрос на поиск DWH-разработчиков возникает всё чаще. Сегодня делимся опытом подбора кандидатов, специализирующихся по КХД.
В зависимости от особенностей деятельности компании требования к вакансиям, связанным с созданием корпоративных хранилищ данных, могут иметь свою специфику, но есть ряд компетенций, которыми обязательно должны обладать кандидаты на такие позиции.
Достаточно часто встречается несоответствие реального опыта соискателя с опытом, который необходим для работы. Так, в резюме могут быть указаны подходящие технологии, а на интервью становится понятно, что человек только начал их изучение. Поэтому при беседе с претендентом важно проговорить используемые методики работы и узнать уровень владения ими.
Вот на что обращают внимание профессиональные консультанты GlobalCareer, занимаясь рекрутингом на DWH-позиции:
Опыт работы с Oracle. Это главная система работы с базами данных. Она оптимизирована для больших нагрузок, обеспечивает высокую производительность системы (сбор данных и их анализ) и позволяет быстро создавать новые КХД и витрины данных. Поэтому специалист по DWH практически по умолчанию должен уметь работать с Oracle.
Владение OLAP. Эта технология используется при анализе больших объёмов данных, позволяет обрабатывать их очень быстро и считается ключевым компонентом баз данных. А т. к. одно из главных качеств DWH – скорость работы, то без знания технологий, позволяющих эту скорость обеспечить, создание эффективной КХД оказывается под вопросом.
Отличное знание SQL, PL/SQL. SQL стандартный язык баз данных, а PL/SQL в него интегрирован, поэтому без навыков работы с ними кандидат не сможет работать над проектами DWH.
Навыки работы с инструментами ETL (Informatica Power Center, IBM DataStage, Oracle Data Integrator, Oracle WareHouse Builder). Для управления данными в КХД – их обработки, преобразования и перемещения в хранилище – используются ETL-процессы. Поэтому без умения применять различные инструменты для их осуществления сложно представить работу с DWH. Желательно, чтобы кандидат мог подтвердить свои знания по продукту ETL сертификатом вендора. Это станет гарантией того, что он быстро адаптируется и включится в работу.
Опыт в построении Data Mart (витрин данных). Т.к. витрину данных можно назвать хранилищем данных для одного отдела — здесь собрана информация одного типа, её работу поддерживает, как правило, одно приложение и создаётся она для нужд определённого подразделения, то опыт участия в разработке Data Mart станет большим плюсом для кандидата на вакансии, связанные с КХД.
Отличное знание стека Hadoop (Apache Hadoop, Cloudera Manager, MapReduce, HDFS, Spark, Kafka, YARN). Эта основополагающая технология Big Data обеспечивает работу высоконагруженных систем, позволяет хранить, сортировать и быстро преобразовывать огромные объёмы информации. Поэтому специалист, разбирающийся в ней, сможет заниматься реализацией проектов DWH любой сложности.
Разработка корпоративной базы данных с нуля. Это, как правило, даёт кандидату большую фору, т.к. означает, что он отлично понимает принципы создания и поддержки работы КХД. А значит, сможет быстро включиться в решение задач по модернизации существующей базы, самостоятельно разобравшись с её недочётами, или сможет начать создание нового хранилища.
Знание одного из языков программирования. Поскольку для запуска процессов ETL используются языки программирования, то их знание необходимо кандидату для работы с DWH. Если в задачах специалиста будет поддержка и модернизация существующего корпоративного хранилища, на этапе интервью с соискателем следует уточнить его уровень владения тем языком программирования, с помощью которого ранее велась разработка.
Создание КХД – трудоёмкий процесс, сопровождаемый множеством организационных и технических сложностей, поэтому заказчики охотнее работают с соискателями, имеющими успешный опыт внедрения в крупных компаниях. На рынке сейчас достаточно разработчиков хранилищ данных, но кандидатов со знанием Hadoop среди них не так много. Именно они наиболее востребованы, при этом уровень их зарплат высок. Мы регулярно подбираем специалистов на проекты DWH уровня Senior и Architect, для которых опыт работы с Hadoop обязателен.
Высоким спросом пользуются DWH-специалисты с опытом работы в области Big Data: Hadoop, Oracle, Teradata, DB2, SQL. Даже опыт работы, например, от года, обеспечивает большую востребованность этих кандидатов. Поэтому, чтобы закрыть вакансию разработчиков хранилищ данных в Москве, по факту нужно предложить Regular-специалисту — от 150 тысяч рублей, Senior — от 230 тысяч рублей, тимлиду — от 285 тысяч рублей в месяц до вычета налогов.
Востребованность кандидатов на вакансии DWH будет только усиливаться, а требования к ним будут усложняться. Так, если раньше основной задачей разработчиков хранилищ данных был выбор правильных фреймворков и построение системы, то теперь они сталкиваются с другими вызовами: необходимостью использовать данные в real-time режиме, плюс в условиях высоконагруженной системы. Поэтому от рекрутёров требуется пристальное внимание к соискателям с подходящим стеком и максимально точное составление профилей необходимых для КХД-позиций кандидатов.
Если вашей компании нужна зарплатная аналитика IT-специалистов любого профиля или обзор общей ситуации на рынке – напишите нам, и команда GlobalCareer поможет с решением этих задач.