SQL Server 2005: пакеты вместо самописных выгрузок и отчёты прямо в браузере
Обновились с SQL Server 2000: SSIS заменил хрупкие скрипты интеграции, а Reporting Services дал финансистам самостоятельные отчёты в браузере без участия программиста.
Microsoft выпускает финальный RC SQL Server 2005 с Integration Services и Reporting Services
SQL Server 2005 вышел в финальный RC, и мы поставили его на аналитический стенд одного из клиентов практически сразу. Не потому что гонимся за новинками, а потому что два компонента из этого релиза - Integration Services и Reporting Services - закрывают конкретные дыры, которые у нас уже болели.
Что было до
Схема, с которой работаем у нескольких клиентов, примерно одинаковая: боевая 1С на SQL Server, рядом - аналитическая база, куда ночью переливаются данные. Про то, как строили первый OLAP-куб поверх такой схемы, писали раньше.
Проблема была в слое между боевой базой и аналитической. ETL - то, что вытаскивает, чистит и грузит данные - писался как набор хранимых процедур и bat-скриптов с sqlcmd. Работало. Но любое изменение в структуре источника (переименовали реквизит в 1С, добавили новый вид операции) - и скрипт тихо ломается или, что хуже, начинает грузить мусор без каких-либо ошибок. Поймать это можно только когда финансист заметит расхождение в отчёте, а это может случиться через неделю.
Второй больной вопрос - отчёты. Терминальный сервер для бухгалтерии помог с доступом к 1С, но аналитические отчёты по-прежнему были либо в Excel-кубах, куда надо уметь подключаться, либо в виде выгрузок, которые программист готовит руками. Ни тот, ни другой вариант не давал финансистам самостоятельности.
Что появилось в SQL Server 2005
SSIS (SQL Server Integration Services) - это уже не DTS из 2000-й версии, который был, честно говоря, игрушкой. Здесь полноценный визуальный редактор пакетов: источники, преобразования, назначения соединяются стрелками, каждый шаг журналируется, при ошибке пакет может отправить письмо, повторить попытку или упасть с внятным сообщением. Важнее всего - валидация контрактов: если изменился тип или имя столбца в источнике, пакет не запустится молча, он сообщит об ошибке до начала загрузки.
Это принципиально другой уровень надёжности по сравнению со скриптами. Не потому что стало проще писать - пакет SSIS в визуальном редакторе поначалу непривычен. Просто теперь у нас есть структура, которая умеет жаловаться на проблемы сама, а не ждёт, пока кто-то обнаружит кривые данные в отчёте.
Reporting Services - сервер отчётов с веб-интерфейсом. Отчёт разрабатывается в Visual Studio в специальном дизайнере, публикуется на сервер, и дальше любой сотрудник с браузером и правами открывает его по ссылке. Никакого Excel, никакого клиентского ПО, никакого «позвони программисту». Параметры - период, регион, подразделение - выбираются прямо на странице, отчёт перестраивается. Экспорт в Excel или PDF - кнопкой.
Что поменялось на практике
Первое, что сделали - переписали все ETL-процедуры в SSIS-пакеты. Заняло примерно две недели на одного инженера. Зрелищным результатом это не стало - данные льются так же, как раньше. Но теперь при любом сбое в источнике мы узнаём об этом утром по письму от агента, а не через неделю по звонку от клиента.
Второе - запустили несколько базовых отчётов в Reporting Services. Здесь результат куда нагляднее. Финансисты открывают браузер, выбирают период, смотрят P&L или сверку с контрагентами. Никого не ждут. Первые несколько дней нам звонили с вопросами «это точные данные или приблизительные» - непривычно, что отчёт готовится сам и сразу. Пришлось объяснить, что данные те же, что были в Excel-выгрузках, просто без промежуточного звена в виде программиста.
Один момент оказался неочевидным: как только у финансистов появился самостоятельный доступ к отчётам, запросы к нам не уменьшились, а поменяли характер. Раньше: «сделайте отчёт по продажам за август». Теперь: «в отчёте сумма не сходится с тем, что в 1С, разберитесь». То есть разбираться приходится, но уже с реальными расхождениями, а не с задачей сформировать выгрузку.
Что ещё не закрыто
SSIS-пакеты хранятся в файловой системе или в msdb, нормального version control из коробки нет. Пакет можно случайно перетереть, и никто не узнает что именно изменилось. Решаем пока через ручное копирование версий в папку с датой - дёшево и сердито, но не масштабируется.
Reporting Services требует отдельного сервера или минимум отдельного IIS-сайта. На одном хосте с боевым SQL это можно поднять, но нагрузка на отчётный сервер в часы пик неприятно сказывается на боевой базе. На следующей итерации будем выносить аналитику на отдельное железо.
Если стоит задача собрать аналитику из нескольких систем и дать бизнесу нормальные отчёты без участия программиста - это как раз то, чем мы занимаемся в рамках построения хранилищ и BI-платформ.
- Первый куб: OLAP-отчёт вместо дня в Excel · 20 июня 2005
- 1С 8.0 + SQL Server: как мы переводили сорок пользователей с файловой базы · 7 марта 2005