Книга: Дефрагментация мозга. Софтостроение изнутри

«Оптисток», или распределённый анализ данных

«Оптисток», или распределённый анализ данных

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

Организация процесса получилась близкой к подходу MSF, но с учётом относительно небольшого масштаба. Из рабочих групп оставалось, с одной стороны, только управление продуктом, совмещённое с управлением проектом, где кроме Поля были задействованы ключевые пользователи и представитель директората. С другой – была объединённая группа архитектуры и разработки за моей ответственностью и основным участием вкупе с координацией привлекаемых к проекту специалистов по SAP, корпоративному хранилищу данных и графике. Спираль процессов потребовала всего полторы фазы с одним прототипом.

С оговорками, я работаю в такой организации со студенческих времён и считаю её наиболее эффективной и комфортной для разработки продукта или заказного проекта. Опыт Microsoft показывает хорошие возможности масштабирования процесса. Но мы ещё вернёмся к этому вопросу.

Если применить к «Оптистоку» действующие классификации, то это система класса SFA (Sales Forces Automation – автоматизация продаж на выезде), предназначенная для выстраивания каналов сбыта, ориентированных на конкретного клиента. Рынок – автомобильные компоненты, запчасти и тому подобное. С другой стороны, система занимается аналитической обработкой данных и относится к BI. Типовое использование проходит по следующему сценарию.

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

• продаж компании в выбранной географии. Например, данные отгрузки по стране клиента;

• парка автомобилей выбранного сегмента рынка, также с учётом географии. Например, вся Голландия или только 75-й департамент Франции.

После чего клиенту предлагается пополнить склад некоторым количеством товаров на базе этих расчётов.

Архитектура подобных систем, можно сказать, типовая. Проектируем специализированное хранилище, ищем в корпоративной среде источники нужной информации, организуем регулярное обновление данных, предоставляем пользователям интерфейс для доступа к данным: непосредственно к хранилищу или к так называемым витринам (datamart) и кубам. Наибольшую трудность, кстати, вызывает не сам импорт данных, а поиск в компании людей, которые могут знать, где эти данные взять. Всё-таки 20 тысяч таблиц SAP R3 и примерно столько же в корпоративном хранилище – не шутка, поэтому без хороших проводников раскопки источников информации обернутся поиском иголки в стоге сена.

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

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

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

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

Работа в крупной компании имеет свои особенности. Например, директор информационных систем уровня филиала может и не знать, чем принципиально отличается MS Access от SQL Server. Но показать лицензионную чистоту использования движка Access ему необходимо.

Если с серверной СУБД выбор без особенных затруднений пал на SQL Server, то рабочие места обладали неприятной особенностью: пользователи были лишены прав локального администратора, соответственно, возможности по установке компонентов системного уровня у них отсутствовали. Встраиваемая в приложение редакция SQL Server Compact 2005 в тот момент не могла быть развёрнута простым копированием. Общего с полноценным SQL Server, даже в его минимальной экспресс-версии, у неё было немного, за исключением названия. По сути, тот же Access, даже местами менее функциональный за счёт отсутствия поддержки временных таблиц, но с проблемами использования вне. NET. На рассмотрение и обход раскиданных граблей в других встраиваемых СУБД времени не было.

С автономным приложением выбор был более очевидным. Стандартной версией. NET на рабочих местах была 1.1, что для 2007 года выглядело устаревшим. Собственно, NET был нужен для приложения SAP и, в своё время, накатывая на корпоративные компьютеры обновление фреймворка на уровне пакета (service pack 1), предприятие столкнулось с проблемами функционирования основного приложения. Поэтому предлагать службе эксплуатации устанавливать. NET 2 было невежливо, мягко говоря. А при анонсированном. NET 3 ещё и неразумно. Так в проекте возникла последняя версия Delphi для Win32, позволяющая строить приложения, развёртываемые простым копированием исполняемых файлов без необходимости установки системных компонентов. Проблемы локализации и автоматического обновления версий уже решались в рамках этой среды и не вызывали вопросов.

Если изобразить получившуюся архитектуру, то получится картинка, представленная на рис. 11.

Построив распределённую архитектуру, мы сталкиваемся с двумя основными проблемами:

• поддержка данных в актуальном состоянии;

• обработка данных относительно слабым, по сравнению с сервером, компьютером пользователя.

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

Рис. 11. Архитектура «Оптисток»

Однако передача таких объёмов данных по узким каналам, равно как и вставка в таблицы локального движка миллионов записей, потребовали дополнительной оптимизации. Веб-служба синхронизации была дополнительно нагружена сжатием данных, добавлены функции пакетной передачи, например, по 500 тысяч записей. Вставка в транзакции даже на ADO-технологии позволила довести скорость до 10–20 тысяч записей в секунду, что было достаточным.

Вторая проблема вызывала тревогу у работавших по соседству консультантов, поскольку имевшееся у них в эксплуатации приложение с БД Access размером всего 1 гигабайт проводило за расчётами долгие ночные часы. Но я был априори уверен, что из этого движка вполне можно выжать необходимую скорость, если не впадать в деструктивный снобизм якобы «ненастоящей СУБД», а подходить к вопросу так же серьёзно, как к обработке на порядок-два больших объёмов на полноценном SQL Server.

Для отладки SQL пришлось в короткий срок соорудить инструмент, подобный Query Analyser, но работавший через ADO с БД Access. В получившем название ADO SQL Tools (MS Access Query Analyzer) и происходила основная разработка расчётов. Время исполнения наиболее тяжёлых пакетов запросов удалось довести до 20–30 секунд на обычном пользовательском ПК или ноутбуке с одноядерным процессором и 1 гигабайтом ОЗУ.

Немало времени было уделено интерфейсу пользователя. Зная, что основная работа по обучению ляжет на его плечи, Поль постарался упростить видимый функционал, внеся немало предложений и уточнений в спецификацию. Кроме того, внешний вид приложения, «шкурка»[116], должен был соответствовать корпоративной цветовой гамме, для чего в проект был привлечён профессиональный график. По одёжке встречают.

Рис. 12. Внешний вид клиентского приложения «Оптисток»

Для обеспечения процесса на площадке заказчика пришлось организовывать минимальный набор из трех изолированных сред: разработки, тестирования-приёмки и эксплуатации. С точки зрения 2012 года мощность сервера вызывает улыбку, лишь недавно ему добавили памяти, доведя объём ОЗУ до 4 гигабайт. Но распределённая обработка данных вкупе с использованием множественной обработки на SQL позволила обойтись столь скромными ресурсами.

Добавлю, что корпорация дважды представляла систему на международной автомобильной выставке EquipAuto в 2007 и 2009 годах. Ролик с соответствующим видео и сейчас можно найти на веб-сайте. Неплохой бонус к успешно внедрённому продукту, сделанному при удачной организации процесса и мотивации основных участников.

Оглавление книги