Data warehouse что это
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
Стойкая потребность в корпоративных хранилищах данных появилась еще в 90-х годах 20-го столетия. В этот период в бизнес-среде активно стали применяться информационные системы. Они применялись компаниями для контроля многих показателей эффективности работы, обеспечивая возможность мгновенно реагировать на их изменения. Каждое из приложений локально автоматизировало процесс производства или продажи товара, выполнение бухгалтерских расчетов, проведение банковских операций, позволяло составлять аналитику. Основные сложности на этом этапе состояли в разных рабочих схемах различных систем, что приводило к расхождению информации. Не было возможности получать консолидированные данные, позволяющие создать полноценную картину из отдельных прикладных систем.
Решить данную проблему призвано корпоративное хранилище данных – Data Warehouse, или DWH. Это предметно-ориентированная база данных, позволяющая автоматически готовить консолидированные отчеты и выполнять интеграцию бизнес-анализа. Благодаря ей пользователь получает возможность своевременно принимать правильные решения по управлению на основе целостной информационной картины. Так в чем отличие DWH от обычных баз данных? Почему она настолько привлекает внимание бизнес-аналитиков? Нужна ли она вашей компании? Постараемся найти ответы на эти вопросы.
Отличия DWH от других баз данных
Data Warehouse – это хранилище данных, которые нужны вашей компании для принятия решений. От обычных баз они отличаются:
То есть ответ запрос: DWH что это прост – это отдельная от оперативной системы база для хранения архивной информации от разных источников. Она работает совместно с процессами извлечения, загрузки или преобразования корпоративных данных (ETL). В результате получается единая система для хранения корпоративных сведений и работы с ними.
Зачем нужен DWH нужен бизнесу?
DWH хранилище – обязательный спутник любой бизнес-аналитики (BI, Business Intelligence). Оно принимает непосредственное участие в анализе данных и позволяет получать информацию, которая потребуется персоналу или руководителю при принятии соответствующих решений. На примере это выглядит так:
Если не использовать Data Warehouse, причину падения прибыли пришлось бы искать наугад, каждый раз проверяя теорию на практике до тех пор, пока не будет выявлена проблема. А это все заняло бы очень много времени. Ненамного быстрее была бы и работа с классическими базами данных. Маркетологу пришлось бы заходить в разные хранилища, пытаясь отыскать в них нужную информацию, сопоставлять ее.
Но это не единственные преимущества применения DWH. Единое хранилище данных обеспечивает:
На основе Data Warehous создаются и индивидуальные решения под большие объемы данных. Многие разработчики создают персональные коробочные и облачные проекты специально под такие задачи.
Структура DWH
Хранилище данных – это сложная технология с непростой архитектурой, состоящая из нескольких уровней:
Разработкой DWH должны заниматься опытные люди. Те, кто обладает глубокими профессиональными знаниями в данной области. Только так можно будет получить продукт, простой и эффективный в использовании.
Эффективность DWH в бизнес-аналитике
Современная бизнес-аналитика в комплексе с единым хранилищем данных открывает новые возможности для управления бизнесом. Специалисты получили уникальные ресурсы для построения теории и проведения экспериментов, подтверждающих или опровергающие ее, оперируя огромным количеством реальных показателей. В итоге в работу запускается не теоретическая модель, а реально работающий проект, который гарантированно дает высокий результат.
Правильное управление компанией – это не только повышение прибыли. Оно может быть направлено на расширение производственных мощностей, повышение благосостояния сотрудников, лояльности со стороны клиентов, формирования солидного образа и другие мероприятия, которые в перспективе будут способствовать стабильности бизнеса. И все эти показатели позволяет анализировать комплекс из Business Intelligence и Data Warehous. А что было бы без них? Как правило, это попадание пальцем в небо, тория вероятности, которую можно проверить только на практике. А это трата времени и денег, нанесение ущерба бизнесу.
Более подробные консультации из данной области, нюансах создания продукта высокого качества и техническую поддержку можно получить у специалистов компании Xelent.
Что такое 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) и другие компании предлагают различные варианты коробочных и облачных решений под такие задачи.