Егор Матешук, ostrovok.ru: проблемы big data можно решить, закидывая пачки денег в топку

Егор Матешук, ostrovok.ru: проблемы big data можно решить, закидывая пачки денег в топку

Ostrovok.ru — российский интернет-сервис бронирования отелей. Был признан лучшим в своем сегменте в 2013 году по версии National Geographic Traveler Awards. В распоряжении клиентов сервиса свыше 900 тыс. отелей по всему миру. «Проблемы big data можно решить, закидывая пачки денег в топку»

— Big data все начали заниматься не настолько давно — когда примерно это началось у вас в «Островке»?

— Массово — где-то два года назад. Первый разумный агрегат, который начала использовать аналитика, мы выдали, кажется, в июле 2016-го. С тех пор система дорабатывалась, развивалась. Объем данных быстро растет, сама компания растет. Вместе с этим появляются новые источники, новые срезы.

Действительно, объем накапливаемых и обрабатываемых данных растет очень быстро. Мы с этим работаем, используя все более эффективные технологии. Потому что как раз это то место, где технологии идеально работают. Если ты в одном месте что-то улучшил, ты можешь это раскатать на весь процесс обработки данных (если у тебя единая платформа) и получить профит сразу на огромном объеме. То есть можно достаточно просто экономить вычислительные, сетевые ресурсы, используя практики, которые достаточно хорошо показали себя в одном месте. — До развития big data хранили ли вы данные вообще и в каких объемах?

— Данные, с которыми сегодня работает big data стек, даже не собирались, по сути. Там уже был огромный объем, который трудно было выполнить даже в рамках MPP-баз. Даже они не очень хорошо справлялись с этим потоком. Понятное дело, такие проблемы можно решить, закидывая пачки денег в топку, ставя сотни серверов и огромные лицензии. Но здесь open-source-стек оказался определенно выигрышным, по крайней мере, с экономической точки зрения.

MPP, massively parallel processing — массивно-параллельные системы обработки — один из наиболее развитых, проверенных и широко используемых механизмов хранения и анализа больших объемов данных.

При использовании массивно-параллельной архитектуры данные разделяются на фрагменты, обрабатываемые независимыми центральными процессорами (CPU) и хранящиеся на разных носителях. Это похоже на загрузку разных фрагментов данных на несколько объединенных в сеть персональных компьютеров.

— Для чего вам нужна big data?

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

— Что это за данные?

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

— Они запрашиваются в тот момент, когда пользователь начинает искать?

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

— Поставщики — это промежуточные агрегаторы, то есть вы работаете не напрямую с отелями?

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

— Вы используете большие данные для понимания того, что предлагать пользователям?

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

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

— Какие это объемы, если говорить в цифрах?

— У нас есть Kafka как система обмена всеми данными, проходящими через наши системы. У нее нагрузка где-то 500 тыс. сообщений в секунду. «Лучше повозиться, чем хранить токсичную информацию»

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

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

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

— Эти агрегаты вы храните еще и для понимания динамики?

— Да, многое меняется. Вся логика аналитики — в том, что если мы что-то изменили, нам нужно увидеть, как это соотносится с тем, что было. И поскольку не всегда знаешь, что именно ты захочешь изменить или посмотреть, приходится хранить данные с запасом. То есть собирать data lake — не совсем сырые данные — и накапливать какие-то главные сущности, историю по ним. Чтобы в случае изменений можно было проверить, стали мы лучше или хуже перформить.

— Какие данные вы собираете о пользователях и насколько пользователи об этом знают?

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

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

— Могут ли отличаться цены для разных пользователей на основе данных о них?

— В общем-то, могут. Наверное, это связано с маркетинговыми каналами, но тут лучше спросить у маркетинга. Просто мы продаем через много разных площадок и исходя из экономики кажется, что цены должны отличаться. Например, для залогиненного пользователя в приложении ценник будет меньше — просто потому что такова политика компании. Но тут нет каких-то хитрых экспериментов, это не что-то evil-related, как для тех, кто заходит с айфона XS Max, то сразу цены в десять раз выше.

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

— Можно ли сказать, что больше и больше денег уходит на хранение данных?

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

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

— А технологии хранения данных развиваются достаточно быстро?

— Очень быстро. На железном уровне я не могу про это говорить, но на уровне фреймворков для обработки данных и каких-то экосистем, как Hadoop-овская экосистема, все развивается достаточно быстро. Оно стало актуальным.

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

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

А еще интересный момент: если компания активно работает с аналитикой (большой отдел аналитики, много новых людей), как человеку объяснить, что делает вот эта сотня витрин? Это большая проблема. И сейчас нормальных хранилищ метаинформации не так уж и много. Хранение схем данных, описание данных, какая-то прозрачная логика их трансформации, то есть, по сути, все технологии, которые будут отвечать на вопрос «Что это за данные?» для пользователей, — получат большой рывок в ближайшее время. Потому что тут огромная дыра, которую все заполняют как могут. Некоторые просто ничего с этим не делают — и это превратится в страдания уже через год, два, три.

— Что еще планируете делать на основе данных?

— Есть задумки о том, как сделать более крутую персонализацию. Мы делаем A/B-тесты, у нас собирается некая информация о пользователе, о его работе с продуктом, есть отдельно анализ нашего спроса, некие рекомендации, но все это отдельные вещи.

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

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

Подпишитесь на наши новости
Лого www.SiteHere.ru
1970-01-01 03:00 http://news.xtipe.com/ru/news/30146

Смотрите так же

Исследование: ИТ-специалисты в России в среднем получают 90,7 тыс. рублей в месяц 1970-01-01 03:00

Средняя зарплата ИТ-специалистов и инженеров по разработке электронных приборов оказалась самой высокой на российском рынке труда. Об этом говорится в исследовании HeadHunter «Банк данных заработных плат» за третий квартал 2018 года, которое приводит vc.ru.

Конгресс США начнет расследование возможной утечки данных 500 тыс. пользователей Google+ 1970-01-01 03:00

Европейские регуляторы и американский Конгресс направили письмо в компанию Google с требованием предоставить дополнительную информацию о возможной утечке данных 500 тыс. пользователей социальной сети Google+. Кроме того, регуляторы требуют от компании рассказать, почему Google решила умолчать об этой уязвимости.