Сергей Тарасов - Дефрагментация мозга. Софтостроение изнутри
Поскольку в нашу задачу входило предпроектное обследование, начались интересные опыты с технологиями новыми. Начали с прототипа конвертера, извлекающего данные из старых форматов и распределяющего их по таблицам промышленной СУБД, в качестве которой выступал SQL Server. Логично было бы написать такой прототип на C++ или другом языке с возможностями прямого доступа к памяти на уровне битов, но ввиду планируемой общей разработки исключительно на C# необходимо было оценить соответствующую программу в ипостаси распаковщика байтов.
Быстро выяснилось, что побитовые операции с типами данных разной длины не являются сильным местом языка и платформы в целом. Как, например, задать ushort или вообще любую константу в двоичном виде? Никак. А ushort в шестнадцатеричном? Тоже никак, константа определяется как int, все остальные преобразования надо делать в небезопасном контексте unchecked(). В итоге код достаточно простого алгоритма пестрел вот такими вставками, которые, на минуточку, суть рекомендуемые практики. Нас настигла расплата за автоматическое управление памятью.
Convert.ToUInt32("00110000", 2);
unchecked((ushort) 0xC0);
Вторым пунктом была собственно база данных. На логическом уровне структура для тестируемого случая никаких сложностей не представляла: одна узкая длинная таблица, связанная с несколькими короткими справочниками, практически «звезда», но в режиме постоянного добавления пачек новых записей. Трудность представлял собой уровень физический. Втиснуть число-признак, кодируемое тремя битами, в те же три бита на уровне СУБД стандартные средства не позволят. Минимальный размер – байт. Использовать нестандартные битовые поля в принципе можно, но тогда мы лишимся поддержки ссылочной и прочей целостности, возможности использовать SQL для выборок без переупаковки значений в битовые структуры и фактически будем использовать СУБД в качестве продвинутого аналога файлового хранилища с улучшенными функциями администрирования.
Поскольку целью было упрощение работы с пользовательскими запросами, то лишать их доступа к данным посредством прямого и понятного человеку SQL было решительно невозможно. При использовании минимальных по размеру стандартных типов данных прогнозируемый размер базы данных без учёта дополнительных индексов превысил 6 терабайт, то есть минимум удвоился по сравнению с двоичными файлами. Сжатие данных несколько скрасило ситуацию, полученные 4,5 терабайта выглядели уже неплохо. За всё надо платить, в том числе за стандартность доступа и представления данных.
Третьим пунктом была загрузка данных из C#-приложения в базу данных. Поскольку интенсивность вставки из прибывающих от датчиков текстовых файлов составляла почти 400 тысяч записей каждые 10 минут, то, разумеется, приложение должно было справляться с этой задачей за меньшее время. Оптимальной, как и следовало ожидать, оказалась пакетная загрузка, игнорирующая ограничения целостности РСУБД. Такова обычная цена компромисса.
Что имеем по итогам более чем 10-летнего развития технологий? Появилась возможность стандартизировать хранение и доступ к большому массиву данных, используя вполне обычное серверное оборудование корпоративного класса и 64-разрядную промышленную СУБД. Возникла необходимость переделывать программное обеспечение из-за утраты поддержки среды разработки поставщиком и соответствующих компетенций на рынке труда.
Но я совсем не уверен, что ещё через 10 лет новые подрядчики, вынужденные в очередной раз переписывать систему, найдут документацию в том же полном виде, в котором нашли её мы. Если вообще найдут хоть что-то, кроме кода, остатков презентаций и наших отчётов.
«Оптисток», или распределённый анализ данных
Название «Оптисток» придумал уже позже кто-то из маркетинговой команды. Поль, руководитель проекта и ответственный за функционал, был первое время недоволен, так как предыдущая версия продукта называлась «Оскар». Поэтому корневой директорий системы так и живёт до сих пор под названием 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, позволяющая строить приложения, развёртываемые простым копированием исполняемых файлов без необходимости установки системных компонентов. Проблемы локализации и автоматического обновления версий уже решались в рамках этой среды и не вызывали вопросов.
