Big Data: текущая реальность

    Привет, Хабр!

    С момент публикации серии статей на тему анализа данных и машинного обучения прошло уже достаточно времени и люди начинают просить новых публикаций. За последний год мне удалось поработать с несколькими компаниями, планирующих внедрять у себя инструменты продвинутой аналитики на предмет подбора специалистов, а также обучения их сотрудников и решения проектных задач. Для меня это был довольно необычный и одновременно сложный опыт, поэтому этот пост хотелось бы адресовать руководителям компаний, планирующих внедрять инструменты Big Data и Data Mining.

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

    Важно понимать возможности и ограниченность применения Big Data аналитики


    Очень часто разговор начинается примерно так: «Хотим прогнозировать X по нашим данным Y с точностью не менее Z», где X и Y почти никак не коррелируют, а Z такая, что можно сказать «зуб даю».

    Например, недавно ко мне обратился один из руководителей IT достаточно крупной ритейловой сети. Задача звучала примерно так: "Есть показатели эффективности (порядка нескольких сотен) региональных магазинов (несколько десятков) за 2 года (т.е. 2 таблицы). Нужно предсказать эти же показатели за третий год (т.е. снова таблицу)". Любой специалист знает — что это типичная задача прогнозирования временных рядов и что с такими вводными условиями и таким набором данных она не решается.

    Опять же, люди, которые знакомые с методами обработки естественного языка (Natural Language Processing) скажут, что на сегодняшних день, например задачи классификации текстов решаются в большинстве случаев хорошо (попросту говоря, с малой долей ошибки), в то время как задачи типа «генерирование умозаключений из набора связанных между собой текстов» (пример такой «Decision Support System» мне предлагали разработать для одного из фондов) на сегодняшний момент практически не решаются в том смысле, что существующие решения совершенно не продуктивны.

    Тут хочется отметить, что Big Data — это не волшебная палочка, которая принимает на вход «простыню» (еще один термин, который часто приходится слышать во многих компаниях), что-то делает внутри и выдает на выходе что душе угодно. В прогнозных задачах целевая переменная (target) предсказывается, как правило, на основе набора признаков (features), который должен быть исчерпывающим в плане влияния на целевую переменную. Кстати, отсюда же появляется и второе важное наблюдение:

    В нишевых задачах проще обучить существующих специалистов, чем найти новых с рынка


    В задачах предиктивной аналитики одним из самых важных этапов (фактически закладывающих первое ограничение на качество полученных моделей) является подготовка и отбор признаков (feature engineering, feature selection, etc.). Проще говоря — набора оптимальных параметров, которые влияют на ту или иную целевую переменную. Этот набор признаков определяется именно предметной областью задачи, поэтому ее знание критично для многих задач.

    Например, пусть решается задача прогнозирования оттока клиентов (для любого сервисного бизнеса). Data Scientist, который начнет решать эту задачу, скорее всего, в качестве признаков оттока будет рассматривать показатели вида «кол-во обращений в поддержку». Но любой специалист, который понимает предметную область, скажет Вам, что на отток влияет не кол-во обращений, а «наличие обращений X-го уровня по тематике Y за последние Z дней». Добавление такого признака увеличивает качество моделей «в разы», и не сложно заметить, что придумать такой признак может только человек, глубоко знакомый с предметной областью. Не говоря уже о том, что само понятие «отток» определить правильно может только человек, знающий это понятие не по наслышке.

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

    Это в основном касается таких задач, как обнаружение фрода, оттока или задач, связанных с прогнозированием временных рядов. Думаю, что мноние, кто занимается анализом данных в нишевых задачах, подтвердят данный факт.

    Зачастую не нужен большой CAPEX


    3 месяца назад один не очень большой интернет-сервис решила строить, опять же, модель оттока для своих пользователей. Да, это, наверное, одна из первых задач, которую начинает решать любой сервисный бизнес, услышав название Big Data. Оно и понятно, потому что почти все сервисы работают на retention, потому как cost per acquisition почти всегда высока — проще говоря, легче зарабатывать на тех пользователях, которые уже платят своим хоть и не большим LTV, чем привлекать новых. Так вот, возвращаясь к задаче: пользователей несколько миллионов, вся информация о них в данный момент находится в реляционных хранилищах. Перед руководителем подразделения, отвечающего за данный проект было поручено рассчитать бюджет. Деньги оказались не такие большие для компании, но совершенно фантастические для данного проекта. Предполагалось (почти дословно цитирую) «закупить несколько машин», «организовать на них Hadoop-кластер», «организовать перенос данных в кластер», «поставить коммерческое ПО для больших данных, чтобы оно могло работать с данными на кластере» и (не уточнено как) «построить прогнозную систему».

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

    В этом примере в результате, оказалось, что модель оттока, удовлетворяющую бизнес, можно было успешно построить на уже существующих данных, хранящихся в реляционных базах (практически не делая feature engineering — знающие меня поймут). Из инструментов потребовался Python с его библиотеками, код которого запускается теперь каждый месяц, работает несколько часов, после чего выходные данные «выгружаются в excel» (это тоже важно, потому что данный инструмент участвует в большинстве бизнес-процессов компании) и передаются в службу, планирующие кампании по удержанию клиентов. Решение далеко не лучшее на сегодняшний день, но оно полностью удовлетворяет заказчиков. Кстати, надо рассказать, почему удовлетворяет:

    Компании все еще боятся «искусственного интеллекта»


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

    Нет единого понятийного аппарата


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

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

    Это одни из самых распространенных вещей, с которыми приходится встречаться человеку, который занимается разработкой прогнозных аналитических инструментов (что зачастую также называется модным словом Big Data). Этой статьей я хотел показать, что помимо известного утверждения «90% работы Data Scientist'а состоит из подготовки и очистки данных», на практике чаще оказывается гораздо труднее пройти весь путь от идеи до конечного продуктивного решения, а самый сложный участок начинается и заканчивается далеко не на очистке данных.

    Именно поэтому зачастую важнее находить общий язык с людьми, имея построенное за спиной дерево решений (Decision Tree), нежели градиентный бустинг или RandomForest, который на пальцах не объяснить.

    Всем успехов!

    P. S. К сожалению, т.к. времени на все совершенно не хватает, наверное, я больше не смогу достаточно писать на хабре о том, чем можно поделиться. Оставлю голосовалку
    Чем лучше поделиться?

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Метки:
    MLClass 34,36
    Компания
    Поделиться публикацией
    Похожие публикации
    Комментарии 11
    • +1
      Интересно, как понять, когда компания созрела для внедрения инструментов именно Big Data.
      Когда становится недостаточно реляционных БД+Python/R? Когда обработка начинает занимать слишком долгое время? Или когда решение задач становится в принципе невозможным без Hadoop и пр.?

      И еще вопрос
      Из Вашей практики — кому требуется требуется больше вычислительных ресурсов — аналитикам, которые выбирают, строят и подстраивают модели наилучшим образом или департаменту IT, который реализует уже конкретную модель в рамках всей компании?
      • 0
        >Интересно, как понять, когда компания созрела для внедрения инструментов именно Big Data.
        >Когда становится недостаточно реляционных БД+Python/R? Когда обработка начинает занимать слишком долгое время? Или когда решение задач >становится в принципе невозможным без Hadoop и пр.?

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

        >Из Вашей практики — кому требуется требуется больше вычислительных ресурсов — аналитикам, которые выбирают, строят и подстраивают >модели наилучшим образом или департаменту IT, который реализует уже конкретную модель в рамках всей компании?
        Чаще конечно во втором случае. Аналитики, как правило, «настраивают» свои модели (если мы говорим о машинном обучении) на небольших выборках (просто потому, что трудно найти большую обучающую выборку). Когде же дело касается (пред)обработки больших данных, или разработки продуктивного решения — тут могут потребоваться дополнительные ресурсы, как и серьезное внимание к оптимизации существующих алгоритмов
      • 0
        Биг дата к объёму этих самых данных отношения не имеет вообще. Основа биг даты — не объём данных, а их источники. Если у вас таблица на терабайт — есть определённая техническая проблема её обработать — но это не биг дата. Если у вас есть куча разнорождной информации (логи активности пользователей, показов, продаж, твитов и постов на форуме) — это уже может быть биг датой, даже если умещается на персоналке.

        А вопрос готовности к биг дате у компании — если сокращение издержек/увеличение прибыли на 2-3% — это хорошая сделка, компания готова. если нет — значит не судьба. исключая, разумеется, тех, для кого это профильный бизнес.
        • 0
          Возможно, хотя тут можно спорить и уйти в полемику)

          По мне так — вопросы хранения и обработки больших данных (дословно с английского — Big Data) — тоже имеют право на существование.

          В общем, в этом вопросе — кому как. Но, в целом, да — если хорошего кол-ва признакового описания хватает — это круто. Это и показывает опыт таких площадок, как kaggle.com
          • +1
            Спасибо Александр за ваши посты, и Сергей за ваши интересные комментарии,

            Хотелось бы высказать свое мнение. В целом вы весьма правы — тут можно действительно уйти в глубокую полемику. Но тем не менее хотелось бы выделить отдельно задачи, которые решаются в рамках построения того же Big Data Pipeline, которые обычно решаются отдельными людьми типа Data engineer. Как бы при этом давая большую свободу людям, которые занимаются непосредственно анализом данных и построением конечной модели (предсказание, рекомендации и т.д., суть не в этом), проще говоря Data Scientist. НО, думаю очень часто получается ситуация когда Data Scientist «и швец, и жнец, и на дуде игрец».
            • 0
              Очень согласен, что это так и есть на практике. Более того, скажу, что по большей части ценность из данных можно извлечь просто выполнив какие-то простые действия и аккуратно данные обработав, построив несколько графиков и посмотрев несколько корреляций. Тут требуется только аналитическое мышление, логика и много аккуратности
              • 0
                Полностю согласен. Буквально на днях прочитал интересную статью, где в принципе простая агрегация данных + визуализация увеличила эффективность. Если интересно, вот статья — Utilizing machine data from robots to provide data driven insights and decisions target.github.io/analytics/robotics-analytics
        • +2
          Нет, это не может быть бигдатой. Неспособность проанализировать маленькие данные не делает их большими.
    • +3
      > анализ социальных сетей (много сложной математики)

      А что из литературы можно почитать хорошего на эту тему?
    • +2
      Recognizing What is Not a Big Data Problem as a Service
      yourdatafitsinram.com

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое