T+ Conf 2019: Tarantool в Аэрофлоте, или MDM на лету



    Сегодня публикуем расшифровку доклада Николая Шевцова и Рустама Кильдиева с T+ Conf 2019 «Tarantool в Аэрофлоте, или MDM (Master Data Management) на лету». Из доклада вы узнаете:

    • Зачем нужен MDM?
    • Зачем нужен риалтайм?
    • Data Science — это не только Jupyter Notebook.
    • Плюсы Tarantool.
    • Чем Lua хорош в проде.

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

    Именно в платформе по работе с обращениями мы активно используем Tarantool, и о нем чуть подробнее.

    Самая главная ценность Big Data для нас — возможность анализировать данные. Все новые источники информации, связанной с Аэрофлотом, мы стараемся собрать в единое информационное поле для дальнейшей обработки.

    Николай Шевцов, Аэрофлот. Руководитель проектов в Департаменте Информационных Систем.

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

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

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

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

    На старте проекта мы рассматривали несколько инструментов, которые могли бы нам помочь в данном вопросе и в итоге выбрали Tarantool. Жизнь показала, что это был правильный выбор: он позволяет соблюдать требования SLA и при этом неплохо масштабируется при росте нагрузки.

    Реализация


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


    Полученную по обращениям информацию необходимо обработать и систематизировать. Обращения — это текст, который нельзя хранить в «сыром» виде, поэтому весь текст подвергается векторизации. Ведётся поиск по набору обращений, составляется карта уникальных слов и словосочетаний, на основе которой вычисляется начальный вектор для конвертации всех последующих обращений. Изначально наши специалисты по анализу данных использовали классические инструменты — Python и Jupyter Notebook на кластере или локальном ноутбуке. Вектор имеет динамический размер, что создаёт трудности.

    В отличие от множества других инструментов, Tarantool — это полноценный сервер приложений. Мы можем задействовать множество библиотек, таких как SciLua, писать логику на обычном языке программирования и т.д. Сейчас мы векторизуем данные с помощью библиотеки SicLua в режиме реального времени непосредственно в Tarantool. Затем с помощью метода косинусного расстояния система ищет похожий вектор за трёхмесячный период. В результате мы получаем либо дубль, либо похожие обращения для дальнейшей обработки. В процессе поиска выполняется множество математических вычислений: за 3 месяца обрабатывается примерно 100 тыс. обращений из всех доступных источников. Среднее время обработки — 120 мс.

    Рустам Кильдиев, технический директор в компании Иннодата.

    Инфраструктура


    Наша БД Tarantool работает на четырёх шестнадцатиядерных серверах с большим количеством оперативной памяти. Благодаря модулю Vshard удалось реализовать быстрый поиск с перебором. Данные разделены на части — бакеты, благодаря чему обработка запроса распараллеливается. Систему легко масштабировать, достаточно просто добавить сервера. У нас осуществляется репликация мастер-мастер, хотя к этому сейчас приходит большинство СУБД. Также у нас нет необходимости добавлять модули, нет проблем с администрированием.

    Наш объем данных, если считать по оперативной памяти, порядка 1 Тб. На этапе запуска, отладки и исправления ошибок в проекте возникли проблемы. Практически все таблицы содержат по 7-8 индексов, поэтому БД Tarantool на 1 Тб у нас поднималась 20-40 минут, что неприемлемо. Во время запуска система строит индексы и если их убрать, то загрузка пойдёт намного быстрее. В этой ситуации случае нам помогла функция Hot-standby.

    Планы


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

    Tarantool доказал свою полезность в production, и мы будем загружать в него ещё больше данных, добавлять бизнес-логику. В отличие от других БД, его не нужно постоянно настраивать и что-то менять. К слову, пересчёт и загрузка данных в Tarantool из другой системы у нас автоматизированы и выполняются ежедневно.

    В будущем мы планируем перейти на Tarantool Enterprise, что позволит удобно администрировать и настраивать несколько экземпляров Tarantool. Специалистов по этой БД пока мало, а потребность в них постоянно растет. Нашей квалификации иногда бывает недостаточно. В таких случаях помогает внутренний чат разработчиков Tarantool, в котором можно попросить помощи. Этого нет ни в одной другой системе.

    Также мы планируем перейти на Tarantool2 и SQL. Специалистов по SQL на рынке труда много, поэтому переход будет не очень сложным.

    Выводы


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

    Tarantool очень отказоустойчив и работает «из коробки». Мы проводили многочисленные эксперименты: выключали Tarantool, поднимали и т.д. — всё отлично работает, а промежуточные данные пишутся на диск, так что данные мы не теряем.
    Mail.ru Group
    Building the Internet

    Similar posts

    Comments 7

      0
      Очень интересно читать про поступь Tarantool по относительно крупным проектам.

      Практически все таблицы содержат по 7-8 индексов, поэтому БД Tarantool на 1 Тб у нас поднималась 20-40 минут, что неприемлемо. Во время запуска система строит индексы и если их убрать, то загрузка пойдёт намного быстрее. В этой ситуации случае нам помогла функция Hot-standby.


      Не уловил, как тут помогает Hot standby, можно подробности узнать?

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


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

      . Мы можем задействовать множество библиотек, таких как SciLua, писать логику на обычном языке программирования и т.д. Сейчас мы векторизуем данные с помощью библиотеки SicLua в режиме реального времени непосредственно в Tarantool. Затем с помощью метода косинусного расстояния система ищет похожий вектор за трёхмесячный период.


      Интересно как у вас происходит развертывание обновлений той части, которая написана на LUA? Удается ли избежать простоя системы?
        +2

        Как-то чувствуется когнитивный диссонанс, когда читаю о


        Больше всего жалоб, порядка 2,5 тысяч в день, поступает от прилетающих пассажиров

        И при этом упоминается тарантул, 4 сервера в репликации мастер-мастер, и 1ТБ памяти. Я чего-то не уловил и оно того стоит, или реально задача уровня простенькой виртуалки из диджитал оушена с PHP и MySql была решена столь суровым инструментарием просто ради прокачки cv? Как-то привык использовать сервера с терабайтом памяти для других объёмов.

          0
          В обращении используются личные данные, а вы их в виртуалку DO.
          Как я понял, там 2 сервера: мастер-мастер репликация. Объем БД 1 Тб, а не памяти у серверов, у серверов должно быть больше памяти, т.к. тарантул всю базу в памяти хранить.
          Мне кажется, что тут неточность. 2,5 тысячи обращений в день, откуда там 1 Тб
            +1
            В обращении используются личные данные, а вы их в виртуалку DO.

            Если что, метафора была исключительно о производительности.

            2,5 тысячи обращений в день, откуда там 1 Тб

            Может, конечно, где-то терабайт и наскребли данных. Сравнивали текст с неким огромным корпусом текстов, например.

            Но, походу, инженеры тупо развели бизнес на интересную для себя задачу и пофармили чуток cv. Ведь, цифры все есть:
            за 3 месяца обрабатывается примерно 100 тыс. обращений из всех доступных источников. Среднее время обработки — 120 мс.

            Если просто посчитать количество секунд в трех месяцах и количество секунд на отработку 100К запросов, то система была под нагрузкой аж 0.17% всего времени (та и то, вряд ли на все ядра). Учитывая, что не система, где надо давать быстрый летенси, и пассажир вполне может подождать лишние 5 секунд на процессинг своего сообщения, то все выглядит так, что решение на традиционной СУБД дало бы аналогичную ценность. И да, 2.5 тыс обращений в день дают 200К за три месяца, а не 100.
          +1

          Бизнес логика в хранимках БД на lua скриптах? — Здравствуй раздутый бюджет и сроки.

            0
            > Lua очень близок к машинному коду и является одним из самых быстрых языков из семейства C

            wikipedia/lua

            Lua 1.0 was designed in such a way that its object constructors, being then slightly different from the current light and flexible style, incorporated the data-description syntax of SOL (hence the name Lua: Sol is also the Portuguese word for «Sun», Lua being the word for «Moon»). Lua syntax for control structures was mostly borrowed from Modula (if, while, repeat/until), but also had taken influence from CLU (multiple assignments and multiple returns from function calls, as a simpler alternative to reference parameters or explicit pointers), C++ («neat idea of allowing a local variable to be declared only where we need it»[5]), SNOBOL and AWK (associative arrays). In an article published in Dr. Dobb's Journal, Lua's creators also state that LISP and Scheme with their single, ubiquitous data-structure mechanism (the list) were a major influence on their decision to develop the table as the primary data structure of Lua.[7]
              0
              Очень странный выбор платформы под MDM.
              На одном из моих прошлых проектов порядка 5 000 новых записей в день создается, но за счет выявления дубликатов и контроля качества данных общий объем справочника под миллион золотых записей. И все это прекрасно работает на 4 ядрах и нескольких гигабайтах памяти.
              Я правильно понимаю, что цель была не сделать правильно, а сделать на Tarantool?

              Only users with full accounts can post comments. Log in, please.