Служба интеграции SQL Server Integration Services (SSIS) — это мощный модуль преобразования данных, поставляемый с SQL Server. Иными словами, приобретая лицензию на SQL Server, вы получаете «бесплатную», вернее, прилагаемую лицензию на службу интеграции SQL Server. Это очевидное преимущество для пользователей SQL Server, но известны случаи, когда отдельные организации, которые по большому счету и не пользуются SQL Server, приобретали лицензии лишь для того, чтобы получить доступ к SSIS. Однако, при том что SSIS — невероятно полезный инструмент, его эксплуатация предполагает некоторые скрытые расходы. Кроме того, приобретая этот продукт, вы можете угодить в ловушку, что вам дорого обойдется.
Назначение SSIS — это, прежде всего, извлечение, преобразование и загрузка данных, а также организация их хранения. Основное достоинство службы — гибкость. Средствами SSIS разработчики буксируют различные неоднородные источники данных, а затем эти данные могут быть преобразованы или переправлены в другое место с помощью мощного конвейера, который обеспечивает возможность почти бесконечного набора преобразований. Однако, при том что SSIS обеспечивает выполнение самых разных типов задач (таких, например, как извлечение данных из плоских файлов поставщиков и «загрузка» этих данных в инвентаризационную базу или в базу с данными о продуктах на продажу), в реальных условиях эксплуатации указанная служба в первую очередь предназначена для организации хранения данных. SSIS превосходно справляется с задачей организации операций ETL (extract, transform load operations, или извлечения, преобразования и загрузки), то есть считывания данных из одного источника, их обработки в соответствии с потребностями и загрузки информации в хранилище данных.
Пожалуй, можно утверждать, что большинство людей, использующих SSIS, это, в сущности, ETL-профи, которые только тем и занимаются, что с помощью службы интеграции SQL Server трансформируют данные из источников OLTP в кубы OLAP. И на большинство «подводных камней», которые я здесь упоминаю, такие специалисты просто не обращают внимания. Дело в том, что от проблем, определяемых мною как «скрытые расходы», обычно страдают бюджеты тех организаций, где службой SSIS пользуются от случая к случаю.
Скрытые расходы при нерегулярном использовании SSIS
Служба интеграции SQL Server — инструмент мощный, и его эксплуатация — дело непростое. Поэтому тем, кто не работает со службой постоянно, изо дня в день, приходится сталкиваться с потенциальными проблемами, скрытыми ловушками и дополнительными расходами, с которыми приходится иметь дело всякий раз, когда SSIS используется для решения какого-либо конкретного вопроса. И поскольку каждая из этих проблем сама по себе, пожалуй, «потянет» на отдельную статью, в целях экономии времени я свел наиболее актуальные из них в отдельный список.
SSIS — продукт капризный; такова задумка разработчиков. И это практически не воспринимается как проблема. С особенностями службы пользователь сталкивается сразу же. И это закономерно: решение, обеспечивающее преобразование данных в памяти, не может предполагать «либерального» отношения к типам данных или позволить пользователям строить догадки относительно того, сколько разрядов можно отбросить или какой порядок числовой точности является допустимым. Это означает, что создание пакетов SSIS может вызывать определенные трудности. В ходе преобразований пользователь не может допускать ни малейших ошибок, иначе его пакеты просто рассыплются в прах. Но бывают ситуации, когда здесь возникает проблема. Я имею в виду случаи, когда нерегулярные пользователи SSIS создают пакеты, запускают их на выполнение в течение нескольких месяцев или лет, а потом им приходится возвращаться и вносить в пакеты изменения — возможно, для того, чтобы адаптировать их под более новую версию SQL Server, а может быть, чтобы учесть изменения в схеме либо в потоке работ. В подобных ситуациях работа со службой может доставить много хлопот: вам будет казаться, что быстрее и проще с нуля переделать значительные разделы пакета, чем пытаться заставить его компоненты взаимодействовать с измененной базовой схемой. Проблема, однако, в том, что все это требует больших затрат времени и приводит к увеличению стоимости владения.
Условия и варианты лицензирования могут приводить в замешательство. Да и вообще все положения, касающиеся лицензирования SQL Server, не отличаются особой доходчивостью. Однако, когда речь заходит о SSIS, важно понимать, что эта служба является компонентом или функцией SQL Server. Иными словами, SSIS — это модуль уровня сервера, и, коль скоро вы можете создавать специализированные (или выделенные) экземпляры SQL Server, которые будут в первую очередь выступать в качестве «серверов» SSIS, выполняющих ваши пакеты, для функционирования этих серверов потребуются полновесные лицензии SQL Server. Это не бог весть какая ловушка, если вы, конечно, не думаете, что можете просто так взять и перенести задания SSIS на другой сервер. Поступить таким образом вам ничто не помешает, нужно только, чтобы сервер имел все необходимые лицензии.
Перемещение пакетов SSIS может сопровождаться множеством проблем. Когда разработчики создают решения SSIS, или пакеты (с помощью Visual Studio), они могут разворачивать их на сервере или сохранять локально в файловой системе. Поскольку эти пакеты содержат конфиденциальную информацию (например, строки подключения к базам данных), для сохранения пакетов локально по умолчанию используется следующее правило: конфиденциальная информация шифруется с помощью учетных данных Windows текущего пользователя. С точки зрения обеспечения безопасности это прекрасное решение, но в отношении последующей работы с исходным кодом оно никуда не годится. Дело в том, что, если ваши сотрудники впоследствии уволятся или если в системе Windows произойдут значительные изменения (скажем, если вы войдете в состав рабочей группы и будете готовить для нее свою рабочую станцию), вы не сможете вновь открывать эти старые пакеты, ибо у вас не будет возможности расшифровать конфиденциальную информацию. Если вы воспользуетесь поисковиком Google, то найдете возможные обходные пути для вычленения конфиденциальных данных и перезагрузите пакеты, свободные от этих деталей, но, увы, мне доводилось наблюдать целые проекты, которые не поддавались восстановлению. Их нужно было перестраивать с нуля, когда объект Windows user претерпевал серьезные изменения и всевозможные ухищрения по восстановлению данных не приносили никаких результатов. Поэтому, если вы намереваетесь хранить пакеты в течение длительного времени, шифруйте конфиденциальную информацию с использованием пароля (а пароль храните где-нибудь в другом месте). Иначе в ситуации, когда после нескольких лет работы для обеспечения важных деловых операций потребуется внести изменения в тот или иной пакет, непрерывность бизнеса окажется под угрозой.
У вас могут возникнуть трудности с поиском средств для обеспечения взаимодействия SSIS с SQL Server 2012 и более поздними версиями. Средства для работы с SSIS всегда были слабым звеном, оставаясь в течение длительного времени наспех сработанными дополнениями к Visual Studio. В течение ряда лет постоянно возникали проблемы с поддержкой текущих основных версий Visual Studio и отмечались недоработки в отношении совместимости. В период выпуска версии SQL Server 2012 специалисты Microsoft пытались исправить положение, «разбивая» эти средства на автономные наборы инструментов, «привязанные» к полным релизам Visual Studio. В целом данный подход дал положительные результаты. Но избранный корпорацией несуразный метод достижения поставленных целей по-прежнему только запутывает пользователей.
Однако еще более серьезная проблема состоит в том, что, если вы сегодня установите систему SQL Server 2014, в ее установочных средствах вы не найдете абсолютно никаких инструментов ни для управления пакетами SSIS, ни для создания таких пакетов. С точки зрения SSIS-профи, которые работают с этим продуктом изо дня в день, данное обстоятельство, к сожалению, является вполне логичным. Но для пользователей вроде меня это самый что ни на есть запутанный вариант.
В заключение еще раз подчеркну, что SSIS — это невероятно мощное инструментальное средство. И большинство трудностей, озвученных мною в этой статье, совершенно не касаются SSIS-профи (хотя мне доподлинно известно, что проблемы управления версиями и неразбериха с именованием досаждают им так же, как и всем потребителям). А для обычных пользователей SSIS и вовсе не является символом безмятежного блаженства. Это сложный инструмент, и работа с ним требует подготовки, а также четкого представления о том, где кроются ловушки и «подводные камни». Надеюсь, читателям, которые намереваются использовать SSIS для решения своих профессиональных задач, эта статья будет полезна.