Как обрабатывают big data гиганты e-commerce

e-CRM, social-CRM

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

Вышеупомянутые технологические компоненты используются во многих частях этого уравнения. Рекламные платформы (включая поисковые сайты, социальные сети и т. д.) обеспечивают источники трафика, вокруг трафика выстроены механизмы маркетинговой аналитики и campaigning с целью оптимизации затрат и получаемого потока лидов. Собственные веб-приложения или приложения, основанные на платформах (таких как Hybris), обеспечивают конверсию трафика в заказы, отдельные сервисы обеспечивают омниканальность — получение заказов из онлайн-приложений, оффлайн-розницы, call-центра, партнерских программ. Продуманное и быстрое веб-приложение обеспечивает отличный пользовательский опыт, тем самым — будучи подкрепленным грамотной работой с ассортиментом и маркетингом — повышая конверсию и трафик (за счет возвращаемости и лучших поведенческих метрик для SEO). OLAP-системы (англ. online analytical processing — интерактивная аналитическая обработка) отвечают за поиск и анализ закономерностей с целью оптимизации бизнес-процессов и маркетинговых коммуникаций, сегментацию трафика (25-летние матери и 40-летние незамужние женщины покупают по-разному). Email-кампании и ретаргетинг напоминают клиентам об интернет-магазине. Персонализация и персонализированные рекомендации помогают увеличить средний чек.

На каждом из этапов очень важна скорость в IT-системах компании.

В уже далеком 2012 году Amazon рассчитал, что замедление веб-приложения всего на одну секунду ежегодно может обходиться для них в $1,6 млрд. упущенной выручки от продаж с учетом их размера на тот момент.

В 2017 г. компания Akamai провела исследование, согласно результатам которого даже 100-миллисекундная задержка при загрузке страницы может уменьшать конверсию на 7%.

Малому бизнесу чаще всего относительно легко добиться высокой производительности IT-систем классическими решениями ввиду небольших объемов данных, среднему — тоже вполне реально. Но трендом сегодняшнего дня в интернет-торговле стала консолидация данных и бизнесов. Вперед выдвинулись большие платформы от Amazon, Rakuten или Alibaba Group, а за ними следуют технически продвинутые конкуренты, жаждущие нарастить свою клиентскую базу и увеличить выручку. Эта же консолидация видна и на российском рынке, где клиент, переходя в онлайн, попадает в агрегаторы наподобие AliExpress, Яндекс.Маркет или к масштабным игрокам, таким как М.Видео.

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

Вынужденный выбор между объемом и скоростью

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

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

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

В некоторых случаях требования к отклику могут быть ниже, но не разительно. Допустим, нам надо персонализировать рекомендации или контент, например, показывать молодой маме детские коляски или спортсмену кроссовки. Хорошо, если у вас узкий ассортимент, который подходит точно под потребности, но чаще всего вы торгуете большим количеством товаров, и очень желательно не показывать клиенту все подряд, начиная с мужских носков, а адаптировать выдачу и показать то, что будет наиболее интересно и даст максимальную конверсию. Общая польза персонализации подтверждается целым рядом исследований — так Salesforce оценивает, что рекомендации могут давать 26% от общей выручки, McKinsey дает более скромную, но все равно очень значительную оценку потенциального прироста выручки в 5–15%.

Персонализацию не всегда обязательно делать в реальном времени, но этот процесс должен быть очень оперативным — вышеупомянутая «мама» в среднем посмотрит всего 3–4 страницы, на каждой проведет всего несколько секунд, чем раньше вы поймете, кто она и что ей предложить, тем выше будет шанс сделать продажу до того, как она отвлечется и займется другими делами или перейдет на вкладку с другим магазином. Это очень небольшой интервал, и большая часть баз данных не способна произвести сложные вычисления под высокой нагрузкой на основе больших массивов данных за столь короткое время. Для этого требуются распределенные (чтобы снизить нагрузку на отдельный узел) системы с «колоцированной» в рамках одного узла обработкой связанных данных (чтобы снизить сетевое взаимодействие, которое может вносить значительные задержки), а также максимально быстрое хранилище (чтобы минимизировать задержки, вносимые системой ввода-вывода).

Чтобы добиться низкого времени отклика, необходима оптимизация во всех направлениях. Можно до определенного момента внедрять более эффективные алгоритмы, можно снизить нагрузку на одну машину путем использования горизонтального масштабирования и распределения данных и запросов по кластеру.

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

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

In-Memory системы и Гибридные решения

В последнее время многие крупные онлайн-ритейлеры внедряют in-memory решения (SAP HANA, Apache Ignite, Polymatica, Druid, Exasol). Это распределенные системы, в которых главным хранилищем является сама оперативная память.

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

К недостаткам In-Memory баз данных относятся высокая стоимость оперативной памяти, а также дефицит квалифицированных специалистов, обладающих достаточным пониманием высокораспределенных систем.

Нужно осознавать, что смотреть в сторону In-Memory решений нужно тогда, когда вы понимаете, что нужен очень высокий уровень производительности для ваших задач, и вы имеете достаточный ROI, чтобы инвестировать в это деньги. Это как спорткар — он нужен вам, если есть, где его применять — но и цена на него выше, чем на обычную машину. Благо, розница, особенно онлайн, предлагает достаточное количество мест, где применение In-Memory может дать свои дивиденды.

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

К таким гибридным системам относятся Druid (используется Alibaba, eBay) и GridGain на базе Apache Ignite (Apple, NewEgg), SAP Hana (Walmart, Staples).

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

Стоимость владения в итоге должна учитывать лицензии, поддержку, стоимость оборудования (она будет стоить дороже, чем стоимость внутренних специалистов или консультантов, которые будут поддерживать разработанное решение), также нужно учитывать плановую стоимость расширения лицензионного и «железного» покрытия при росте бизнеса. В целом стоимость решения может разниться от нескольких сотен тысяч рублей при небольшой инсталляции с использованием продуктов с открытым кодом без поддержки до десятков, сотен миллионов и более, в зависимости от объема хранимых данных, стоимости поддержки у вендора, легкости горизонтального масштабирования конкретного продукта, а также сложностей возлагаемых на него задач.

Сегодняшний рынок In-Memory решений дает пространство для выбора и внедрения наиболее подходящего бизнесу решения для реализации важных проектов с комфортным ценником.

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