АНАЛИТИЧЕСКИЙ КОНТУР

Reshape Analytics помогла Estée Lauder выполнить миграцию аналитического контура.

Время на прочтение

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

Мы уже рассказывали о том, как можно реализовать эти ограничения, если вы сами разрабатываете API сервиса, сегодня хотим рассказать о том, как жить с «клиентской» стороны и удобно пользоваться ограниченным по количеству запросов API.

Вводные данные

Меня зовут Юрий Гаврилов, я работаю в команде Data Platfrom в ManyChat. У нас в компании есть маркетинговый отдел, который, среди всего прочего, любит общаться с нашими клиентами через сервис Intercom, позволяющий отправлять удобные In-App сообщения пользователю прямо в нашем веб-приложении. Чтобы эти коммуникации были осмысленными, Intercom должен получать некоторую информацию о наших клиентах (имя, дату регистрации, различные простые метрики их аккаунтов и т.д.). За предоставление этих данных в Intercom отвечает наш довольно-таки монолитный бекенд-компонент, хранящий информацию о наших пользователях. А ещё, совсем недавно, мы построили классный аналитический контур (о котором обязательно расскажем в следующих статьях), также хранящий кучу информации о наших пользователях, и довольно изолированный от упомянутого выше бекенд-компонента. В этом контуре аналитики обсчитывают более сложные пользовательские метрики, гоняют ML-алгоритмы и хранят витрины с результатами всех этих вычислений. Для ещё более крутых коммуникаций с клиентами, часть из этих результатов также хотелось бы иметь в Intercom.

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

Около года назад фирма 1С выпустила свой продукт для построения аналитических систем класса Business Intelligence (BI) 1С:Аналитика. Отличие этого продукта от других BI решений в первую очередь в том, что продукт глубоко интегрирован с платформой 1С:Предприятие, поэтому 1С:Аналитика решает только свою специализированную задачу построения удобного BI интерфейса для подготовки отчетов и работы с ними. Поэтому важным вопросом для понимания продукта и его внедрения становится вопрос общей архитектуры аналитической системы, построенной с помощью 1С:Аналитики. В этой статье мы хотим кратко описать классический подход к построению аналитических систем, и как решение на базе платформы 1С соответствует такому подходу. Мы не претендуем на академическое изложение предмета, поэтому заранее просим прощение за возможную свободу в терминологии или изложении материала.

Какую задачу мы решаем?

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

«Добро пожаловать, у нас фантастически сложные задачи»:

Кто создает новый аналитический контур ВТБ

За объединением Банка Москвы, ВТБ 24 и банка ВТБ в одну структуру последовало слияние их баз данных — очень разных и технологически сложных аналитических систем. Процесс создания единого контура анализа данных продолжается до сих пор.

Заместитель директора департамента технологического развития общебанковских систем ВТБ Дмитрий Алексеев рассказал, как устроено новое хранилище данных банка, как большие данные повышают конверсию в десятки раз и почему в его команде работают лучшие архитекторы страны.

Технологический ландшафт банка ВТБ имеет свою специфику — исторически на него повлияло объединение трех крупных кредитно-финансовых организаций: Банка Москвы, ВТБ 24 и ВТБ. У каждой из структур — собственный аналитический контур, хранилище данных и связанные с ним системы.

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

Построить новый контур, не сломав старый

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

В результате остановились на оптимальном с точки зрения ресурсоемкости и финансовой нагрузки — варианте.

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

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

Дмитрий Алексеев: «В России очень мало банков, перед которыми стоит задача слияния хранилищ данных такого масштаба. Задача суперамбициозная: не сломав текущий контур, создать новый и при этом добиться бесшовной интеграции и синергии. Чем интересно именно наше решение? Во-первых, мы работаем практически со всем технологическим стеком аналитических хранилищ, которые существуют на рынке. Во-вторых, мы реализуем одну из самых технологичных архитектур в отрасли».

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

Дмитрий Алексеев: «Доступность данных на наших хранилищах была где-то t+6. То есть от момента завершения календарного дня до получения данных на аналитических слоях проходило шесть дней. Когда мы начали переработку архитектуры, мы понимали, что доступность данных должна быть намного выше. Так у нас появился дополнительный слой оперативных данных (ОДС), который позволяет получать данные в режиме, близком к реальному времени, что дает качественно новый уровень анализа и новые возможности в скорости принятия решений».

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

Направление продвинутой аналитики и больших данных получит новый импульс в развитии: для привлечения клиентов ВТБ сможет пользоваться каналами компаний-партнеров.

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

По словам Алексеева, индивидуальный и адресный подход при работе с клиентскими предложениями позволяет значительно увеличить конверсию от работы с клиентом — в 10-12 раз — и избавить его от неинтересных ему предложений: СМС и письма с неактуальными кредитными опциями и ненужными бонусами уйдут в прошлое.

Более точная и оперативная аналитика упростит и создание отчетов для финансовых регуляторов.

Дмитрий Алексеев: «Аналитический контур — это не только про продажи. Это в том числе и точная до копейки отчетность перед регуляторами. На текущий момент нам удается сдавать все вовремя и без помарок».

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

Дмитрий Алексеев: «В нашей команде работают три лучших архитектора в России и СНГ. Они к нам пришли только за одним — у нашего департамента сейчас фантастически сложные и интересные задачи. Банк в нас верит, руководители поддерживают направление, в котором мы движемся, задача только в реализации. Во многих организациях, я знаю, за запуск новых аналитических проектов борются годами. У нас этот самый сложный этап пройден».

Речь идет не только о банковских специалистах: ВТБ ищет профессионалов и без опыта в финансовой отрасли, приоритет — компетенции. В команду ждут специалистов по данным: аналитиков, специалистов по SQL и автоматизированным банковским системам, ETL-разработчиков, технологов, отвечающих за качество данных, руководителей проектов.

Найти интересное направление и откликнуться на вакансию желающие могут на сайте «ВТБ-Карьера».

Этот материал является частью проекта ВТБ Fintech Talks.

Классический подход и где кроется засада

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

Прогресс технологий и доступность аналитических решений за последние 20 лет заметно выросли, но сказать, что развернуть аналитическую систему в компании «раз плюнуть» – нельзя. И тому есть веские причины.

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

Почему мы решили выпустить 1С

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

Сама платформа 1С:Предприятие является инструментом для быстрой разработки бизнес-приложений, на которой собственно и сделаны такие популярные продукты российского рынка ПО как «1С:Бухгалтерия», «1С:ERP» или «1С:Зарплата и Управление Персоналом». Квалифицированный разработчик 1С легко нарисует любой отчет для представления и анализа информации. Встроенная в платформу Система Компоновки Данных (СКД) позволяет без программирования нарисовать запрос к данным и максимально точно оформить отчет на его основе. Такой готовый отчет можно сохранить внутри программы 1С, чтобы он был доступен как часть приложения. А можно отчет редактировать отдельно от программы и передавать для выполнения в любую программу 1С, где структура данных совпадает.

Учитывая, что отчеты СКД могут управляться из кода программы 1С, многие строили системы отчетности на базе СКД как интегрированный функционал бизнес-приложения 1С. В качестве примера можно привести «Монитор целевых показателей» в «1С:ERP», или «Аналитические панели» в «1С:Управление Холдингом». Что же дополнительно к этим возможностям хотели наши клиенты?

Поэтому и было принято решение разработать специализированное BI решение 1С:Аналитика как часть платформы 1С:Предприятие.

Мир 1С и что мы решили делать по-другому

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

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

1С:Аналитика является BI решением для такой архитектуры системы. С точки зрения внутреннего устройства этот продукт не дублирует функционал платформы, но расширяет его до полноценного аналитического решения. Как устроена и что умеет 1С:Аналитика?

то адрес доступа к 1С:Аналитике будет тут:

Но интеграция сделана и в обратную сторону. Из меню 1С:Аналитики можно открыть страницу с веб-публикацией информационной базы. А если пользователь видит на экране отчет со справочниками или документами, то он может выбрать нужные объекты и открыть их непосредственно в интерфейсе 1С. Здесь есть несколько вариантов в зависимости от того, что хочет пользователь, и что настроено при установке 1С.

Первый вариант – выбрать объект и получить на него ссылку. При этом в буфер обмена сохранится текстовая ссылка в формате 1С, то есть ссылка, которая может быть открыта непосредственно в интерфейсе приложения 1С. Ссылка содержит метку, что это ссылка в приложении 1С, указывает на тип объекта и передает его идентификатор. Выглядит такая ссылка примерно так:

Если не хочется руками получать и открывать ссылку на объекты из 1С:Аналитики в приложении 1С, то можно воспользоваться командой “Открыть”. Если в приложении активирована Система Взаимодействия (встроенные чаты и видеозвонки), то через неё 1С:Аналитика передаст команду непосредственно на рабочее место пользователя, и в его клиентском приложении 1С выбранный объект откроется на экране. Если Система Взаимодействия в приложении при установке не активирована, то откроется отдельная веб-страница с приложением 1С, где нужный объект будет уже открыт.

Что делать, когда запросов становится настолько много, что очереди разгребаются часами/днями/неделями?

Здесь мы точно не волшебники, и запрограммировать свое взаимодействие с внешним API так, чтобы превышать его rate-limit, мы точно не можем. По задачам загрузки данных наших клиентов мы внедрили у себя систему по учету тех данных, что уже были отправлены во внешний сервис. Когда наступает очередная выгрузка данных о пользователях, отправляются только данные о тех пользователях, которые обновились, и, тем самым, уменьшается необходимое количество запросов.

В остальном, в данной ситуации не остаётся ничего иного, кроме как разговаривать со внешним сервисом на тему увеличения лимита запросов.

О компании

Промышленность:Решение:Бизнес-результаты:Используемые программы и сервисы:

Ситуация до старта

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

Создание аналитического контура с нуля

Привет, Хабр! Меня зовут Татьяна. Я работаю в аналитике более 6 лет. Сегодня хочу на примере своего NFT-кейса рассказать про то, как можно просто и быстро развернуть аналитический контур проекта. Даже, если на данный момент у вас нет НИ-ЧЕ-ГО.

Мы с вами посмотрим:

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

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

Мой стек: Google Tag Manager, Я. Метрика, UA, GA4, немного Javascript. По необходимости работаю совместно с фронтом. Пишу ТЗ, программист клиента выполняет, мы проверяем корректность настройки.

Если есть мобильное приложение, то счетчиками выступают SDK. Работаю с Appsflyer и Appmetrica, консультирую по установке + ТЗ.

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

Настройка длилась около двух недель совместно с разработчиками клиента. Мной было написано ТЗ и произведена настройка отправки событий тегами в GTM. Информацию к передаче и якорные события для GTM настраивали разработчики клиента по нашему ТЗ.

В итоге мы получили поток данных в Яндекс Метрику и Google Analytics о полезных действиях пользователей на сайте.

Далее выбрали аналитическое хранилище данных, настроили все доступы. В моем стеке Google Bigquery, Postgres и ClickHouse. Выбрали для себя Google Bigquery. Он обеспечил нам свободу действий и гибкость в использовании.

За один созвон я помогла клиенту создать проект в Google Cloud Console, мы создали платежный аккаунт и привязали его к проекту. Расшарили доступы к проекту на рабочий e-mail, чтобы можно было производить дальнейшие настройки.

Клиент получил личное аналитическое хранилище данных, в котором в дальнейшем начали аккумулироваться сырые данные и витрины данных для отчетов. Поддержка SQL позволила внутренним аналитикам также обращаться к датасетам и использовать данные для своих собственных отчетов. Затем мы перешли на BI уровень — создание дашбордов на основе витрин данных, выбор и расчет ключевых метрик.

Остановились на Google Data Studio. Все данные у нас собирались в Google Bigquery. Мы складывали туда данные GA4 и к Google Bigquery подключались из Looker Studio.

Требовалась информация об источниках/каналах трафика, количестве сеансов, пользователей и полезных действий. Также клиента интересовало как часто пользователи возвращаются в продукт, поэтому предложил им смотреть DAU, MAU и Retention. Метрики посчитал и визуализировал в отчете.

В результате у нас появились первые быстрые отчеты в Looker на основе данных в GA4 с нужными метриками.

Вот так выглядела воронка полезных действий по устройствам:

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

Также клиенту была интересна оценка воронки с авторизацией через Google по сравнению с обычной воронкой авторизации:

Мы увидели, что хоть и авторизация через Google менее популярный путь пользователей, но в конечном результате процент конверсии из шага регистрации в последний шаг воронки выше.

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

На своем сайте клиент продавал платные размещения. Ему было интересно, сколько кликов было по тем или иным платным размещениям: в шапке сайта, в листингах гильдий, игр и других страницах.

Отчет по динамике посещений разделов сайта показал, что больше всего посещался раздел с играми, но это очевидно — он на самой первой странице.

В итоге, благодаря такому способу, мы с клиентом смогли выявить не только “слабые места” проекта, но и перспективные направления для развития.

Узнали, что пользователи ценят и как мы можем улучшить их опыт использования нашего продукта. Увидели возможности для роста и получили действенные инструменты для достижения наших целей.

На этом все! Теперь вы тоже сможете легко и быстро развернуть аналитический контур проекта 🙂

Реализация «единой точки общения»

Мы уже говорили, что в ManyChat любят Redis — он же нам помог для решения и этой задачи. Для создания такой «единой точки» нужно где-то собирать информацию о том, какие именно методы хотят вызвать во внешнем API наши компоненты. Если внешние компоненты захотят вызвать методов больше, чем позволено ограничениями API, на момент «передышки», пока не обновятся лимиты, эту информацию нужно где-то хранить. А ещё, нам бы очень хотелось ввести систему приоритетов, чтобы «базовые» данные, которые бекенд-компонент хочет отправить в Intercom, не ждали, пока прогрузится много «продвинутых» данных из аналитического контура.

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

На каждый приоритет нам нужно создать по своей очереди, в которую компоненты будут записывать свои намерения вызвать тот или иной метод в API, а один общий consumer будет в порядке приоритетности эти очереди вычитывать и непосредственно вызывать методы API. Если при вызове очереди он сталкивается с достижением rate-limit, он подождет, пока лимиты сбросятся, и продолжит работу.

В нашем случае очереди нужно две — для «базовых» данных из бекенд-компонента (давайте назовем её BackendQueue), и менее приоритетных «продвинутых» данных из аналитического контура (AnalyticsQueue). Прелесть такого подхода заключается также и в том, что совершенно не важно, на каких языках программирования написаны компоненты и consumer, все они смогут выполнять свою работу, нужно только определиться с форматом хранящихся в очереди данных.

Давайте для определенности и простоты примем в этой статье такой формат (JSON):

Здесь мы разбираем очереди в порядке приоритетов, при получении информации о методе пытаемся его выполнить, если сталкиваемся с лимитами — ждем и пытаемся снова ограниченное количество раз.

А наши компоненты на разных языках программирования могут отправлять запрос на вызов интересующего их метода:

Аналитический контур (Python):

Мысли о решении проблемы вслух

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

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

Главный по скорости

Важный момент, который у внимательного читателя сейчас должен вызвать вопросы. Я явно указал, что 1С:Аналитика отвечает только за визуальный BI интерфейс аналитической системы. Сами запросы к данным, как и их хранение, обеспечиваются силами платформы 1С. Насколько быстро будут обрабатываться аналитические запросы в стандартной учетной системе, которая при том еще и работает на стандартной OLTP СУБД? Практика показывает, что до 5-10Гб данных современная СУБД вполне хорошо обрабатывает как в режиме обработки транзакций (OLTP), так и в режиме аналитических отчетов/запросов (OLAP). Если данных становится больше, или аналитические запросы становятся сложнее, то скорость аналитики на обычных СУБД начинает существенно снижаться. Именно поэтому в классической схеме построения аналитических систем и есть выделенный OLAP сервер, который решает задачу скорости на аналитических запросах.

Но платформа 1С:Предприятие тоже готова к решению этой задачи, предлагая для неё две ключевые технологии:

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

Дата акселератор – это отдельная СУБД класса ROLAP, в которой может храниться копия данных. R OLAP означает, что для платформы 1С эта база данных выглядит как реляционная СУБД, но сама база данных оптимизирована для быстрого выполнения именно аналитических запросов. Если посмотреть, что “под капотом” у Дата акселератора, то ускорение в десятки раз обработки аналитических данных достигается за счет следующих технологий:

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

В результате вместе механизм копий БД и Дата акселератор решают для 1С:Аналитики следующие две ключевые задачи:

Если посмотреть на общую схему развертывания 1С:Аналитики со всеми нужными компонентами платформы, то мы увидим, что здесь есть аналоги для всех компонентов из классической схемы построения аналитических систем, но важное отличие, что все они работают внутри и являются частью платформы 1С:Предприятие.

Пример использования

Итак, 1С:Аналитика легко может сделать счастливыми пользователей 1С, добавив к их уже работающей программе 1С возможности включения BI интерфейса для работы с данными внутри 1С:Аналитики. За счет того, что данные уже находятся внутри платформы 1С, можно без больших рисков быстро подключить 1С:Аналитику и получить готовую аналитическую систему. А если данные не лежат в одной программе 1С, или даже лежат не в системах 1С, а анализировать их надо? Что делать в таком случае? Возвращаться к классической схеме построения аналитических систем с её рисками и издержками?

Ответ, который мы можем тут дать: и да, и нет. Платформа 1С:Предприятие и 1С:Аналитика позволяют использовать всю гибкость классического подхода, но без его ключевых недостатков. Имея внутри платформы все необходимые технологии, можно рассматривать саму платформу 1С как готовую основу для построения аналитической системы. В этом случае основной доработкой будет построение процесса ETL для сбора данных на базе 1С. Как только все данные будут собраны внутри информационной базы 1С, к ним можно будет настроить доступ через BI интерфейс 1С:Аналитики.

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

Пример такой независимой аналитической системы, построенной на базе 1С, внедрение в ДИТ города Москвы. На платформе 1С была разработана ETL система сборки данных из 1800 информационных систем организаций города. Часть из них тоже работают на базе 1С, но многие – нет. Это не помешало платформе 1С стать ядром и центром консолидации данных для их аналитической обработки внутри 1С:Аналитики. Различные средства разработки предназначены для решения своих специализированных задач, и платформа 1С:Предприятие прекрасно справляется как с разработкой бизнес-приложений, так, теперь вместе с 1С:Аналитикой, и с построением аналитических систем класса BI.

Проблемы метода и их решения

Когда мы попытались перейти на такую систему — всё заработало, данные доходили до Intercom, лимиты не исчерпывались. Но возникла другая проблема — каждое обращение к внешнему сервису занимает какое-то время, и когда все вызовы API «сместились» в один поток, мы совсем перестали доходить до rate-limit, перформанс customer’a был в несколько раз меньше rate-limit’ов, и стало понятно, что нужно всю эту радость как-то распараллеливать. Redis вполне безопасно (в смысле параллельности) позволяет разбирать свои очереди нескольким consumer’ам. В целом, нет никакой проблемы в том, чтобы запустить несколько consumer’ов, описанных выше, на одни и те же очереди и проблемы не будет. Каждый из них будет точно так же с соблюдением приоритетности разбирать очередь и, при превышении лимитов, ждать, пока внешний сервис сбросит лимит, и далее работать снова до исчерпания лимита.

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

Одностороннее взаимодействие с API

Иногда бывает нужно не только вызвать какой-то метод во внешнем API, но и получить и обработать его ответ. Мы же перевели наше взаимодействие компонентов с API в асинхронный формат. Проблема получения ответа от сервера и доведения его до исходного компонента — решаемая. Достаточно дополнить данные о методе, который мы хотим выполнить, данными о callback’e, который consumer’у необходимо выполнить при получении ответа от внешнего сервиса. Мы написали несколько стандартных callback’ов, которые складывают полученные ответы в определенные очереди, из которых компоненты могут их прочитать и обработать самостоятельно.

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

Заключение

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

Надеюсь, что кому-нибудь такой подход окажется полезным и интересным. Буду рад ответить на вопросы в комментариях и узнать, какие подходы для взаимодействия с ограниченными по количеству запросов API используете вы.