Datastage что это

Основы IBM InfoSphere DataStage V8.7/IBM InfoSphere DataStage Essentials V8.7

В течение данного курса вы изучите основы IBM InfoSphere DataStage V 8.7, как построить и запустить задачи, реализующие язык ETL в DataStage . Вы научитесь разрабатывать параллельные задачи в DataStage , которые читают и записывают информацию в источники данных, такие как последовательные файлы, наборы данных, реляционные таблицы. Также в течение курса вы будете разрабатывать параллельные задачи, которые обрабатывают данные различными способами: преобразование бизнес-данных, фильтрация, объединение данных, генерация данных, сортировка и агрегация.

Для кого предназначен этот курс

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

Необходимая подготовка к курсу

· Знать базовые особенности ОС Windows

· Иметь представления об ODBC и способах доступа к реляционным базам данных

В течение данного курса вы научитесь:

· Объединять данные , используя Lookup Stage, Join Stage, Merge Stage

· Создавать задачи, которые производят как чтение из последовательных файлов, так и запись в них

· Создавать задачи, которые читают и записывают данные в реляционную базу, используя Connector Stage

· Разрабатывать задачи, в которых происходит преобразование данных, объединение, фильтрация, сортировка и агрегация

· Проводить поиск и анализ

· Создавать отчеты по задачам

· Создавать пользователей DataStage

· Администрировать среду DataStage

Основные темы

· Доступ к последовательным данным

· Извлечение данных из реляционных баз данных с помощью Connector Stage

· Complex Flat File stage

· Slowly Changing Dimensions

· Утилита Анализатор производительности и утилита для расчета ресурсов

Подходит? Подать заявку на этот курс

DSXchange

Экспресс-строения здания: прибыль для бизнеса в каждом элементе!
В нынешней эпохе, где часы — финансовые ресурсы, быстровозводимые здания стали решением по сути для бизнеса. Эти современные сооружения обладают повышенную прочность, эффективное расходование средств и ускоренную установку, что позволяет им наилучшим вариантом для коммерческих мероприятий.
Быстровозводимые здания из металлоконструкций под ключ цена
1. Ускоренная установка: Секунды — самое ценное в бизнесе, и экспресс-сооружения способствуют значительному сокращению сроков возведения. Это особенно востребовано в сценариях, когда важно быстро начать вести бизнес и начать прибыльное ведение бизнеса.
2. Финансовая экономия: За счет оптимизации процессов производства элементов и сборки на месте, финансовые издержки на быстровозводимые объекты часто бывает менее, чем у традиционных строительных проектов. Это позволяет сократить затраты и обеспечить более высокий доход с инвестиций.
Подробнее на http://www.scholding.ru/
В заключение, сооружения быстрого монтажа — это оптимальное решение для коммерческих инициатив. Они сочетают в себе быстроту возведения, экономию средств и надежные характеристики, что дает им возможность идеальным выбором для фирм, готовых начать прибыльное дело и обеспечивать доход. Не упустите шанс экономии времени и денег, оптимальные моментальные сооружения для вашего следующего делового мероприятия!

1 post • Page 1 of 1

• Moderators’ Choice
• ↳ Editor’s BLOG Corner
• ↳ Ask the Experts! — Dads and Grads
• ↳ DSXchange Testimonials
• ↳ Cognos (IBM BI)
• FAQs
• ↳ FAQs
• ↳ FAQ Discussion
• DataStage
• ↳ General
• ↳ IBM^® Infosphere DataStage Server Edition
• ↳ IBM^® DataStage Enterprise Edition (Formerly Parallel Extender/PX)
• ↳ Archive of DataStage Users@Oliver.com
• IBM^®Infosphere Products
• ↳ Business Glossary
• Suggestions
• ↳ Site/Forum
• ↳ Enhancement Wish List
• Consulting
• ↳ Talent
• ↳ Looking for Talent
• Support
• ↳ Parameter Manager
• ↳ Compile All Plus
• Usergroup Forums
• ↳ Usergroup Central Forum
• ↳ Heartland Usergroup Forum
• The Written Word
• ↳ Articles, White Papers and Tips and Tricks
• ↳ Product Documentation
• Third Party Applications
• ↳ Third Party Applications
• Product Derivatives
• ↳ Functions
• ↳ Routines
• ↳ Jobs
• ↳ Logs
• Tools
• ↳ Tools Forum
• Category
• ↳ Infosphere Master Data Management
• ↳ Data Quality Best Practices
• ↳ IBM QualityStage
• ↳ Information Analyzer (formerly ProfileStage)
• ↳ IBM^® SOA Editions (Formerly RTI Services)
• ↳ IBM^® DataStage TX
• ↳ BI
• ↳ Data Integration

• Board index
• All times are UTC-06:00
• Delete cookies
• Contact us

Powered by phpBB® Forum Software © phpBB Limited

Решение IBM InfoSphere DataStage прошло сертификацию Huawei на совместимость с большими данными

Huawei объявила о том, что решение IBM InfoSphere DataStage получило статус Huawei Ready после успешной интеграции и тестирования на совместимость с решением Huawei FusionInsight. Результат показал, что заказчики теперь могут реализовывать решения для работы с большими данными с минимальными усилиями путем интеграции решений Huawei FusionInsight и IBM InfoSphere DataStage.

IBM InfoSphere DataStage представляет собой главный модуль платформы интеграции данных InfoSphere Information Server, которая поддерживает универсальный доступ к данным локальной сети, облачной инфраструктуре, мобильной сети, а также к структурированным и неструктурированным данным. Использование решения Huawei FusionInsight, реализованного на базе Hadoop, Oozie, и других решений для работы с большими данными, совместно с IBM InfoSphere DataStage помогает предприятиям максимизировать ценность бизнеса с помощью технологии больших данных.

Жэнь Чжипэн (Ren Zhipeng), президент направления облачных ИТ-решений Huawei, заявил: «Мы рады, что решение IBM InfoSphere DataStage прошло сертификацию и получит логотип Huawei Ready как подтверждение успешного взаимодействия с продуктами для больших данных Huawei. Это поможет предприятиям получать ценную информацию из огромных объемов данных, а также сведения о новых возможностях и рисках. Цель Huawei – долгосрочное инвестирование в развитие решений для работы с большими данными для организации самой масштабной экосистемы с международными партнерами».

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

Ритика Гуннар (Ritika Gunnar), топ-менеджер направления информационной интеграции и управления платформой аналитики IBM, отметила: «Платформа IBM InfoSphere совместно с платформой Huawei FusionInsight помогает заказчикам получать больше прибыли от своих вложений в платформу больших данных. Совместное решение объединяет интеллектуальную технологию Huawei Hadoop и проверенные технологии интеграции данных и управления данными IBM, что позволяет создать корпоративную платформу больших данных для высококонкурентных рынков. Все это позволяет заказчикам создавать корпоративные решения интеллектуального управления данными в кратчайшие сроки и с минимальными вложениями в ИТ-инфраструктуру. IBM намерена продолжать сотрудничество с Huawei для создания инновационных решений интеграции данных и управления большими данными».

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

Начало работы с ibm infosphere datastage and qualitystage operations console

База данных DataStage and QualityStage Operations Database (DSODB) разработана в виде реляционной схемы, таблицы которой содержат информацию о выполнении заданий и системных ресурсах, используемых в системе с установленным механизмом DataStage. Эта информация используется для работы Operations Console (консоль операций), но ее также можно запрашивать напрямую для анализа ключевых столбцов таблиц и взаимосвязей между ними.

В статье описываются основные таблицы и представления DSODB, включая все столбцы, используемые в качестве первичных или естественных ключей, и все взаимосвязи, определенные через внешние ключи. Представлены примеры SQL-выражений SELECT, которые можно использовать для получения ответов на некоторые конкретные вопросы, основываясь на информации из DSODB.

В разделе Ресурсы приведена ссылка на справочник по схеме, в котором описывается DSODB 8.7, включая все имеющиеся таблицы и столбцы.

Для иллюстрации взаимосвязей между различными таблицами приведено несколько рисунков. Каждый прямоугольник – это таблица или представление. Показаны имена релевантных столбцов с пиктограммами, иллюстрирующими их использование (см. рисунок 1).

Обратите внимание, что показаны только те столбцы каждой таблицы, которые упоминаются в тексте данной статьи. Полный список столбцов таблиц приведен в справочнике по схеме, ссылка на который имеется в разделе Ресурсы.

Стрелки между таблицами отображают направление взаимосвязей, установленных внешними ключами и SQL-представлениями (см. рисунок 2).

Таблица HOST служит для разделения схемы, чтобы информацию, собранную из нескольких механизмов, можно было при необходимости хранить в одной схеме базы данных (см. рисунок 3).

Каждая строка таблицы HOST представляет систему, в которой полностью или частично установлен механизм сервера InfoSphere Information Server. Столбец HOSTID – это суррогатный первичный ключ; столбец HostName – имя системы, порожденное командой операционной системы hostname или переменной среды HA_ALIAS, если она установлена в среде процесса EngMonApp во время его запуска.

Для систем, работающих как узел-проводник (conductor node) и выполняющих процесс EngMonApp, в столбце InstallationDir указывается имя пути. Это домашний каталог, в который установлен сервер Information Server, например /opt/IBM/InformationServer/Server/DSEngine. Ключ таблицы HOSTS представляет собой комбинацию столбцов HostName и InstallationDir, позволяющую установить на одну и ту же хост-систему несколько механизмов.

Столбец CreatedTimestamp – это UTC-время вставки строки процессом EngMonApp. При каждом запуске экземпляр ResMonApp выясняет, имеется ли в таблице строка с требуемыми значениями HostName и InstallationDir, и если это так, обновляет столбец MonStartTimestamp; в противном случае он создает новую строку. ResMonApp при необходимости создает также новые записи HOST.

Для удаленных узлов в InstallationDir указывается символ «-» (одиночный дефис). Это системы, значение HostNames которых определяется в файле DSODBConfig.cfg при помощи свойства ResourceNode. Данные строки имеют запись в CreatedTimestamp, но не имеют записи в MonStartTimestamp.

Ограничения каскадного удаления (cascading delete) установлены таким образом, чтобы при удалении строки в таблице HOST удалялись все ссылающиеся на нее строки. Таким образом, все задания, выполняющиеся на данной системе, и все записи об использовании ресурсов удаляются одновременно.

В данном разделе описываются таблицы, используемые для записи информации о выполнении заданий в конфигурациях по умолчанию. Обратите внимание, что все эти строки в конечном итоге связаны с записью в таблице HOSTS (рисунок 4). Для полной идентификации выполняющегося SQL-запроса SELECT необходимо выполнить операцию соединения (join) по столбцу HOSTID, если в базе данных имеются записи о заданиях от нескольких механизмов. (Именно такая ситуация предполагается в рассмотренных ниже примерах SQL-запросов.)

При каждом запуске нового экземпляра задания DataStage and QualityStage создается начальное событие, содержащее версию запущенного исполняемого файла задания, время и идентификатор вызова, если задание имеет несколько экземпляров. Таблица JOBEXEC содержит подробные данные о каждом уникальном исполняемом файле задания, выполнение которого было обнаружено. Обратите внимание, что этот список может отличаться от результатов запроса к репозиторию метаданных (Metadata Repository), в котором могут содержаться задания, которые никогда не выполнялись, или уже не существующие задания, удаленные из репозитория после последнего выполнения.

Строки имеют суррогатный ключ JOBID, использующийся для связи всех выполнений и другой информации о данной конкретной версии задания. Имена заданий являются уникальными в рамках проекта DataStage, а имена проектов являются уникальными для данной хост-системы. После каждой компиляции задания его исполняемый файл потенциально может измениться, поэтому имеется возможность различать версии исполняемых файлов задания по времени их компиляции. Следовательно, уникальным первичным ключом таблицы является комбинация столбцов ProjectName, JobName и CompilationTimestamp в сочетании с HOSTID в качестве внешнего ключа к таблице HOST для идентификации системы, где находится проект.

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

Листинг 1. Пример SQL-запроса: запрос к таблице JOBEXEC
— Список имен и местоположений всех последовательностей заданий, — которые когда-либо запускались на хост-системе H. SELECT X.ProjectName, X.FolderPath, X.JobName, X.CompilationTimestamp FROM DSODB.JOBEXEC AS X JOIN DSODB.HOST AS H ON X.HOSTID = H.HOSTID WHERE H.HostName = «H» AND X.JobType = «SEQ» ORDER BY X.ProjectName, X.FolderPath, X.JobName, X.CompilationTimestamp

Ограничения каскадного удаления установлены таким образом, чтобы при удалении строки в JOBEXEC удалялись все записи, связанные со всеми выполнениями данной версии задания.

Листинг 2. Пример SQL-запроса: удаление из таблицы JOBEXEC
— Удалить всю собранную информацию для всех заданий, — выполнявшихся из проекта P на хост-системе H. DELETE FROM DSODB.JOBEXEC WHERE JOBID IN ( SELECT X.JOBID FROM DSODB.JOBEXEC AS X JOIN DSODB.HOST AS H ON X.HOSTID = H.HOSTID WHERE H.HostName = «H» AND X.ProjectName = «P» )

В эту таблицу вставляется одна строка для каждого отслеживаемого выполнения конкретной версии задания. По мере выполнения задания она обновляется. Столбец RUNID – это суррогатный первичный ключ, использующийся для связи с другими таблицами, содержащими подробности выполнения (например, параметры задания и log-сообщения). Столбец JOBID – это внешний ключ к строке таблицы JOBEXEC, содержащей описание соответствующей версии работающего исполняемого файла задания: имя хост-системы, проекта и задания, а также время компиляции. Другими столбцами, формирующими уникальный первичный ключ, являются InvocationId и CreationTimestamp. Все вышесказанное относится только к заданиям, для которых установлено свойство multi-instanceable; оно позволяет запускать одновременно несколько экземпляров задания, поскольку каждый экземпляр имеет свой уникальный идентификатор вызова – произвольную строку, присваиваемую пользователем во время исполнения. Отметим, что если строка идентификатора вызова не указывается, присваивается значение «-» – одиночный дефис. CreationTimestamp – это UTC-время создания события первого выполнения задания системой мониторинга. Отметим, что оно может отличаться от указанного в RunStartTimestamp, в частности, когда запуск осуществляется из очереди. RunStartTimestamp – это UTC-время реального запуска задания сервером, в отличие от времени, когда оно впервые было отмечено для запуска.

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

Во время выполнения генерируются другие события, когда происходят изменения состояния или когда формируются новые значения некоторых из отслеживаемых свойств. Это вызывает обновление строки в JOBRUN, при котором в столбец LastUpdateTimestamp записывается UTC-время последнего такого обновления.

Обратите внимание, что в таблице JobRun есть два столбца, хранящие значения состояния выполнения: RunMajorStatus и RunMinorStatus. При помощи главного состояние (major status) можно быстро отфильтровать завершившиеся задания от запускающихся или выполняющихся. Второстепенное состояние (minor status) указывает специфичное состояние выполняемого задания (все возможные значения перечислены в справочнике по схеме, ссылка на который приведена в разделе Ресурсы).

Листинг 3. Пример SQL-запроса: запрос к таблице JOBRUN – 1
— Вывести время начала и завершения, названия и состояния всех заданий, — выполненных на хост-системе H, начавшихся после YYYY-MM-DD HH:MM:SS — и уже завершившихся. SELECT X.ProjectName, X.JobName, R.RunStartTimestamp, R.RunEndTimestamp, R.RunMinorStatus FROM DSODB.JOBRUN AS R JOIN DSODB.JOBEXEC AS X ON R.JOBID = X.JOBID JOIN DSODB.HOST AS H ON X.HOSTID = H.HOSTID WHERE H.HostName = «H» AND R.RunMajorStatus = «FIN» AND R.RunStartTimestamp >= «YYYY-MM-DD HH:MM:SS» ORDER BY R.RunStartTimestamp

Листинг 4. Пример SQL-запроса: запрос к таблице JOBRUN – 2
— Вывести список имен всех заданий на хост-системе H, выполняющихся во время T, — и отсортировать их по убыванию суммарного использования процессора за все время. SELECT X.ProjectName, X.FolderPath, X.JobName, R.RunStartTimestamp, R.RunEndTimestamp, R.TotalCPU FROM DSODB.JOBRUN AS R JOIN DSODB.JOBEXEC AS X ON R.JOBID = X.JOBID JOIN DSODB.HOST AS H ON X.HOSTID = H.HOSTID WHERE H.HostName = «H» AND R.RunStartTimestamp = «YYYY-MM-DD HH:MM:SS» OR R.RunEndTimestamp IS NULL ) ORDER BY R.TotalCPU DESC

Ограничения каскадного удаления установлены таким образом, чтобы при удалении строки в JOBRUN удалялись все записи, имеющие отношение к данному сеансу выполнения задания (параметры, log-файлы, показатели и т.д.). Если при выполнении задания запускались другие выполнения (например, в случае последовательности заданий), все они тоже удаляются вместе с имеющими к ним отношение данными.

Листинг 5. Пример SQL-запроса: удаление записей из таблицы JOBRUN
— Удалить все выполнения заданий из проекта P на хост-системе H, — завершившихся нормально. DELETE FROM DSODB.JOBRUN WHERE RUNID IN ( SELECT R.RUNID FROM DSODB.JOBRUN AS R JOIN DSODB.JOBEXEC AS X ON R.JOBID = X.JOBID JOIN DSODB.HOST AS H ON X.HOSTID = H.HOSTID WHERE H.HostName = «H» AND X.ProjectName = «P» AND R.RunMinorStatus = ‘»FOK» )

В таблице JOBRUNPARAMS имеется одна строка для описания значений параметров задания, установленных для конкретного выполнения. Эти значения можно увидеть в начале log-файла выполнения в Director Client. Столбец RUNID этой таблицы представляет собой внешний ключ к таблице JOBRUN для выполнения, с которым эти параметры связаны.

Столбец ParamList содержит информацию в виде XML-строки; имена и значения параметров можно легко извлечь, выполнив запрос к представлению JOBRUNPARAMSVIEW. Оно разбивает XML на отдельные строки для каждого конкретного значения ParamName и ParamValue с RUNID в качестве общего внешнего ключа.

Листинг 6. Пример SQL-запроса: запрос к представлению JOBRUNPARAMSVIEW
— Вывести имена и время начала всех выполнений задания на хост-системе H, — содержащих параметр P со значением V во время выполнения. SELECT X.ProjectName, X.JobName, R.RunStartTimestamp FROM DSODB.JOBRUN AS R JOIN DSODB.JOBRUNPARAMSVIEW AS P ON P.RUNID = R.RUNID JOIN DSODB.JOBEXEC AS X ON R.JOBID = X.JOBID JOIN DSODB.HOST AS H ON X.HOSTID = H.HOSTID WHERE H.HostName = «H» AND P.ParamName = «P» AND P.ParamValue = «V» ORDER BY X.ProjectName, X.JobName, R.RunStartTimestamp

Ограничения удаления для данного представления определены таким образом, что при удалении строки в JOBRUN удаляются все соответствующие записи из JOBRUNPARAMS.

В ходе выполнения задания некоторые из его log-сообщений собираются и сохраняются в таблице JOBRUNLOG, столбец RUNID которой представляет собой внешний ключ к таблице JOBRUN. Какие именно сообщения собираются, зависит от настройки файла DSODBConfig.cfg, но в общем случае они представляют собой небольшое подмножество всех log-сообщений и содержат только начальное и конечное сообщения и первые N предупреждений.

Столбец EventId – это значение integer, которое можно использовать для получения сообщений в порядке генерирования, поскольку значение в столбце LogTimestamp представляет собой UTC-временя с округлением до ближайшей секунды и может не быть уникальным.

Листинг 7. Пример SQL-запроса: запрос к таблице JOBRUNLOG
— Вывести сообщения и данные о задании для всех выполнений на хост-системе H, — сгенерировавших фатальные сообщения, начиная с YYYY-MM-DD HH:MM:SS. SELECT X.ProjectName, X.JobName, R.RunStartTimestamp, L.LogTimestamp, L.MessageId, L.MessageText FROM DSODB.JOBRUN AS R JOIN DSODB.JOBRUNLOG AS L ON R.RUNID = L.RUNID JOIN DSODB.JOBEXEC AS X ON R.JOBID = X.JOBID JOIN DSODB.HOST AS H ON X.HOSTID = H.HOSTID WHERE H.HostName = «H» AND L.LogType = «FAT» AND R.RunStartTimestamp > «YYYY-MM-DD HH:MM:SS» ORDER BY R.RunStartTimestamp, R.RUNID, L.EventID

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

Параллельные выполнения заданий всегда указывают путь к файлу, содержащему конфигурационную информацию для механизма поддержки параллельной работы (посредством переменной среды APT_CONFIG_FILE). Путь записывается в столбец ConfigFileName таблицы JOBRUN. Однако этот путь может указывать на временный файл или содержимое файла может измениться после запуска задания. Поэтому система мониторинга считывает и анализирует файл и сохраняет информацию о количестве узлов, указанном для выполнения задания в таблице PARALLELCONFIG.

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

Список физических и логических узлов в конфигурации хранится в виде XML-столбца. Используйте представление PARALLELCONFIGNODES для запроса физических имен любых узлов в конфигурации и количества логических узлов, назначенных каждому из них. (Обратите внимание, что столбец NodeListHash используется просто для поиска строки с такой же конфигурацией, поскольку XML-столбец нельзя использовать в операции поиска напрямую.)

Листинг 8. Пример SQL-запроса: запрос к представлению PARALLELCONFIGNODES
— Получить названия всех выполнений заданий, запущенных на хост-системе H, — которые использовали узел N и запускались между YYYY-MM-D1 HH:MM:SS — и YYYY-MM-D2 HH:MM:SS. SELECT R.RunStartTimestamp, X.ProjectName, X.JobName FROM DSODB.JOBRUN AS R JOIN DSODB.PARALLELCONFIGNODES AS N ON R.CONFIGID = N.CONFIGID JOIN DSODB.JOBEXEC AS X ON R.JOBID = X.JOBID JOIN DSODB.HOST AS H ON X.HOSTID = H.HOSTID WHERE H.HostName = ‘H’ AND N.PhysicalName = «N» AND R.RunStartTimestamp >= «YYYY-MM-D1 HH:MM:SS» AND R.RunEndTimestamp

Ограничения удаления установлены таким образом, чтобы при удалении строки в HOST удалялись все записи в PARALLELCONFIG, сгенерированные выполнениями на этой хост-системе (и одновременно удаляются все выполнения). Однако удаление записей в JOBRUN не удаляет записи в PARALLELCONFIG; на них могут ссылаться последующие выполнения другого задания на этой же хост-системе.

Листинг 9. Пример SQL-запроса: удаление из таблицы PARALLELCONFIG
— Удалить все строки в PARALLELCONFIG, на которые не ссылается — ни одна строка в JOBRUN. DELETE FROM DSODB.PARALLELCONFIG WHERE NOT EXISTS ( SELECT * FROM DSODB.JOBRUN AS R JOIN DSODB.PARALLELCONFIG AS C ON R.CONFIGID = C.CONFIGID )

Таблица JOBRUNUSAGE заполняется только в случае, если файл DSODBConfig.cfg имеет свойство JobRunUsage=1, которое указано по умолчанию (рисунок 5). Эта таблица используется пользовательским интерфейсом Operations Console для генерирования графика, отображающего ход выполнения задания во времени.

При серверном или параллельном выполнения задания количество строк, прочитанных или записанных его источником или назначением (если есть), накапливается с течением времени. Т.е. обработанные при выполнении задания данные фиксируются через определенные промежутки времени и могут использоваться для построения графика. Каждая строка в JOBRUNUSAGE хранит XML-структуру, содержащую набор снимков состояния, сделанных за постоянно увеличивающиеся интервалы времени с момента запуска задания. Этот набор определяется столбцом StartTimestamp, содержащим UTC-время начала создания набора снимков состояния, и столбцом RUNID, являющимся внешним ключом к таблице JOBRUN, который указывает, к какому выполнению задания это время относится. Данные строки запрашиваются при помощи представления JOBRUNTOTALROWSUSAGE. Оно разбивает наборы на отдельные снимки, содержащие время с момента запуска задания, а также значения TotalRowsConsumed и TotalRowsProduced за это время.

Листинг 10. Пример SQL-запроса: запрос к представлению JOBRUNTOTALROWSUSAGE
— Вывести суммарное число потребленных и сгенерированных строк для каждого — записанного интервала в порядке возрастания времени с момента старта — задания для выполнения задания J в проекте P хост-системы H, — запускавшихся в HH:MM:SS YYYY-MM-DD. SELECT X.ProjectName, X.JobName, U.RunElapsedSecs, U.TotalRowsConsumed, U.TotalRowsProduced FROM DSODB.JOBRUN AS R JOIN DSODB.JOBRUNTOTALROWSUSAGE AS U ON R.RUNID = U.RUNID JOIN DSODB.JOBEXEC AS X ON R.JOBID = X.JOBID JOIN DSODB.HOST AS H ON X.HOSTID = H.HOSTID WHERE H.HostName = «H» AND X.JobName = «J» AND X.ProjectName = ‘»P» AND R.RunStartTimeStamp = «YYYY-MM-DD HH:MM:SS» ORDER BY U.RunElapsedSecs

Эти таблицы заполняются только в случае, если файл DSODBConfig.cfg имеет свойство MonitorLinks=1 (по умолчанию оно установлено в 0). В конце каждого выполнения параллельного или серверного задания система собирает информацию об общем использовании ресурсов процессора на каждом этапе и об общем числе обработанных строк для каждой ссылки, являющейся источником или назначением задания (рисунок 6). Эта информация собирается в таблицу JOBRUN, а число строк периодически добавляется в таблицу JOBRUNUSAGE, которая рассматривалась в предыдущем разделе.

В эту таблицу добавляется одна строка для каждого отслеживаемого этапа выполнения задания. Если таблица не существует, она создается и посредством внешнего ключа JOBID связывается с записью таблицы JOBEXEC для текущего выполнения задания. Запись содержит статическую информацию об этапе, такую как имя, описание и тип. Обратите внимание, что поскольку имена этапов уникальны только на верхнем уровне задания или контейнера, для полной идентификации этапа на более низком уровне используется столбец ContainerPath вместе со столбцом StageName. Каждой строке предоставляется суррогатный ключ, чтобы ее можно было соединить со своими ссылками.

Эта таблица содержит строки для каждой ссылки, определенной как источник или назначение для всего выполняемого задания. Она использует внешний ключ FROMSTAGEID и TOSTAGEID для указания строки в таблице JOBSTAGE, описывающей этап, с которым связана в качестве источника или назначения. Это зависит от настройки столбцов IsSource и IsTarget; в общем случае устанавливается только один из них и соответственно используется только один из внешних ключей.

LinkName является уникальным в комбинации с FROMSTAGEID/TOSTAGEID, поскольку этап не может иметь две ссылки с одинаковыми именами.

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

Листинг 11. Пример SQL-запроса: запрос к таблице JOBRUNSTAGE
— Вывести список выполнений заданий на хост-системе H в порядке — уменьшения использования процессора. SELECT X.ProjectName, X.JobName, R.RunStartTimestamp, JS.ContainerPath, JS.StageName, RS.TotalCPU FROM DSODB.JOBRUN AS R JOIN DSODB.JOBEXEC AS X ON R.JOBID = X.JOBID JOIN DSODB.HOST AS H ON X.HOSTID = H.HOSTID JOIN DSODB.JOBSTAGE AS JS ON X.JOBID = JS.JOBID JOIN DSODB.JOBRUNSTAGE AS RS ON JS.STAGEID = RS.STAGEID WHERE H.HostName = «H» ORDER BY RS.TotalCPU DESC

Каждое выполнение задания, имеющее ссылки на источник или назначение, генерирует также по одной строке на каждую такую ссылку. В ней содержится число строк, переданных ссылке (эти строки участвуют в подсчете значений «consumed» (потреблено) или «produced» (сгенерировано), если ссылка отмечена как источник или назначение соответственно). Что касается этапов, то распараллеливание в соответствующих случаях записывается в виде списка разделенных запятыми значений числа строк на сегмент, а столбец TotalRows – это сумма по всем сегментам.

Листинг 12. Пример SQL-запроса: запрос к таблице JOBRUNLINK
— Вывести список ссылок (и этапы, к которым они присоединены) — выполнения заданий на хост-системе H — в порядке убывания количества сгенерированных строк. SELECT X.ProjectName, X.JobName, R.RunStartTimestamp, JS.ContainerPath, JS.StageName, JL.LinkName, RL.TotalRows FROM DSODB.JOBRUN AS R JOIN DSODB.JOBEXEC AS X ON R.JOBID = X.JOBID JOIN DSODB.HOST AS H ON X.HOSTID = H.HOSTID JOIN DSODB.JOBSTAGE AS JS ON X.JOBID = JS.JOBID JOIN DSODB.JOBRUNSTAGE AS RS ON JS.STAGEID = RS.STAGEID JOIN DSODB.JOBLINK AS JL ON (JS.STAGEID = JL.FROMSTAGEID OR JS.STAGEID = JL.TOSTAGEID) JOIN DSODB.JOBRUNLINK AS RL ON R.RUNID = RL.RUNID WHERE H.HostName = «H» AND JL.IsTarget = 1 ORDER BY RL.TotalRows DESC

Ссылка может также записать информацию для определения местоположения. Это восемь строк, определяющих местоположение внешнего ресурса данных. Т.е. для файла с последовательным доступом эти строки должны определять путь в файловой системе, для таблицы базы данных – тип, имя, схему базы данных, а также имя таблицы. Точные данные зависят от этапа. Для каждого уникального набора идентификаторов существует отдельная строка в таблице DATALOCATOR с суррогатным ключом в столбце LOCATORID. Каждая ссылка, имеющая такую информацию, определяет, была ли создана строка с такими же идентификаторами, и если нет, создает ее. Столбец LOCATORID в таблице JOBRUNLINK является внешним ключом к этой строке.

Таблица 1. Столбцы DATALOCATOR
Имя столбцаИспользованиеComputerNameИмя хост-системы, на которой размещен ресурсSoftwareProductNameИмя продукта, управляющего ресурсомDataStoreSubClassОбщий тип хранилища данныхDataStoreNameОбщее имя базы данных или путь к верхнему уровню ресурсаDataSchemaSubClassТип следующего уровня ресурса, если используетсяDataSchemaNameИмя следующего уровня ресурса, если используетсяDataCollectionSubClassТип самого нижнего уровня ресурсаDataCollectionNameИмя самого нижнего уровня ресурса, например таблица или файл

Листинг 13. Пример SQL-запроса: запрос к таблице DATALOCATOR
— Вывести список всех выполнений, пишущих в базу данных D, — имена таблиц и количество записанных строк. SELECT X.ProjectName, X.JobName, R.RunStartTimestamp, JS.ContainerPath, JS.StageName, JL.LinkName, DL.DataCollectionName AS TableName, RL.TotalRows FROM DSODB.JOBRUN AS R JOIN DSODB.JOBEXEC AS X ON R.JOBID = X.JOBID JOIN DSODB.HOST AS H ON X.HOSTID = H.HOSTID JOIN DSODB.JOBSTAGE AS JS ON X.JOBID = JS.JOBID JOIN DSODB.JOBRUNSTAGE AS RS ON JS.STAGEID = RS.STAGEID JOIN DSODB.JOBLINK AS JL ON (JS.STAGEID = JL.FROMSTAGEID OR JS.STAGEID = JL.TOSTAGEID) JOIN DSODB.JOBRUNLINK AS RL ON R.RUNID = RL.RUNID JOIN DSODB.DATALOCATOR AS DL ON RL.LOCATORID = DL.LOCATORID WHERE H.HostName = «H» AND JL.IsTarget = 1 AND DL.DataStoreName = «D» ORDER BY TableName, RL.TotalRows DESC, R.RunStartTimestamp

Отметим, что строки записываются в таблицу HOSTDETAIL (рисунок 7) только если механизм настроен на выполнение мониторинга ресурсов, т.е. ResourceMonitor в файле DSODBConfig.cfg не установлен в 0.

Каждая строка в таблице HOST должна иметь как минимум одну связанную с ней строку из таблицы HOSTDETAIL. Эти строки содержат информацию о свойствах операционной системы, которые действовали некоторое время при запуске экземпляра процесса ResMonApp. Столбец CreatedTimestamp содержит UTC-время первой вставки конкретного набора свойств. LastCheckedTimestamp – это UTC-время последнего определения экземпляром ResMonApp того, что свойства этой конкретной системы после предыдущей проверки не менялись (т.е. ни одно значение во всех других столбцах менять не нужно). Если какому-либо столбцу требуется другое значение, вместо обновления существующей строки вставляется новая. В новой строке столбцы CreatedTimestamp и LastCheckedTimestamp устанавливаются в значение «сейчас». Строки формируют временную ось, которую можно использовать для отслеживания изменений свойств операционной системы конкретного узла.

Записи в HOSTDETAIL связаны с таблицей HOST по двум внешним ключам. HOSTID – это первичный ключ строки HOST, идентифицирующий имя хост-системы, которую данный набор записей подробно описывает. HEAD_HOSTID – это первичный ключ строки HOST, идентифицирующий хост-систему, на которой выполняется экземпляр ResMonApp, вставивший запись. Для узла-проводника HOSTID и HEAD_HOSTID одинаковы, а для удаленного узла они различаются. В последнем случае в строку записываются свойства удаленного узла, видимые со стороны одного конкретного узла-проводника. Отметим, что уникальным первичным ключом этой таблицы является комбинация HOSTID, HEAD_HOSTID и CreatedTimestamp, поскольку любое изменений в столбцах, отличных от LastCheckedTimestamp, приводит к вставке новой строки вместо обновления строки.

Листинг 14. Пример SQL-запроса: запрос к таблице HOSTDETAIL 1
— Вывести имя и версию операционной системы для хост-системы H — на момент YYYY-MM-DD HH:MM:SS (это означает поиск строки, — значение CreatedTimestamp которой находится ближе всего к этому времени). SELECT Max(HD.CreatedTimestamp) AS «Last Changed», HD.PlatformName, HD.PlatformVersion FROM DSODB.HOSTDETAIL AS HD JOIN DSODB.HOST AS H ON HD.HEAD_HOSTID = H.HOSTID WHERE H.HostName = «H» AND HD.CreatedTimestamp

Листинг 15. Пример SQL-запроса: запрос к таблице HOSTDETAIL 2
— Вывести самую свежую информацию об операционной системе — для каждого узла механизма, отслеживаемого с хост-системы H. SELECT H2.HostName AS «Node», Max(HD.CreatedTimestamp) AS «Last Changed», HD.PlatformName, HD.PlatformVersion FROM DSODB.HOSTDETAIL AS HD JOIN DSODB.HOST AS H ON HD.HEAD_HOSTID = H.HOSTID JOIN DSODB.HOST AS H2 ON HD.HOSTID = H2.HOSTID WHERE H.HostName = «H» GROUP BY H2.HostName, HD.PlatformName, HD.PlatformVersion

Эти таблицы содержат информацию по использованию процессора, оперативной памяти и других системных ресурсов в конкретное время (см. рисунок 8). Отметим, что строки записываются в таблицы RESOURCESNAP и RESOURCEUSAGE, только если механизм настроен на выполнение мониторинга ресурсов (т.е. параметр ResourceMonitor в файле DSODBConfig.cfg не установлен в 0).

Эта таблица содержит одну строку на каждую хост-систему, мониторинг которой осуществляется данным механизмом. Ее столбец HOSTID представляет собой внешний ключ к таблице HOST для идентификации описываемых системных ресурсов. Столбец HEAD_HOSTID в RESOURCESNAP также определяется как внешний ключ, идентифицирующий механизм, вставивший строку. Для узла-проводника HOSTID и HEAD_HOSTID одинаковы, а для удаленного узла они различаются.

На каждом механизме (в соответствии со значением HEAD_HOSTID) для каждой отслеживаемой им системы, включая самого себя (значения HOSTID), строка периодически обновляется значениями, содержащими информацию об использовании всех системных ресурсов, собираемых для данной системы. Столбец LastUpdateTimestamp содержит время последнего обновления.

Содержимое RESOURCESNAP всегда следует запрашивать посредством представлений RESOURCESNAPSYSTEM или RESOURCESNAPDISKS.

Полный набор доступных посредством этих представлений столбцов описан в справочнике по схеме, ссылка на который приведена в разделе Ресурсы.

Это представление содержит несколько столбцов, хранящих информацию об использовании процессора, свободной оперативной памяти, количестве процессов и организации страничной памяти. Названия столбцов используются для группирования счетчиков. Таким образом, CPUPctxxxx соответствует использованию процессора в процентах, MemFreeKBxxxx соответствует свободной памяти в килобайтах, ProcNumxxxx соответствует количеству процессов, а PageNumxxxx соответствует числу событий организации страничной памяти.

Например, CPUPctUser – это процент использования процессора пользовательскими процессами в интервале до LastUpdateTimestamp; MemFreeKBPhysical – это объем свободной оперативной памяти в килобайтах в этот период.

Это представление разворачивает повторяющееся поле в RESOURCESNAP, которое управляется количеством дисковых путей (при наличии таковых), указанных в конфигурационном файле DSODBConfig.cfg (свойства ResourceLocalFS и ResourceRemoteFS, которые могут повторяться). Столбец DiskPathMonitored идентифицирует каждый путь файловой системы, а столбцы DiskTotalKB и DiskFreeKB предоставляют общее число килобайтов и число свободных килобайтов для диска, смонтированного по данному пути.

Эта таблица содержит счетчики, порожденные из счетчиков таблицы RESOURCESNAP, объединенных по интервалам и упорядоченных по оси времени. Значения обновленной записи в RESOURCESNAP используются для вычисления максимальных, минимальных и средних значений за последний период, а затем через определенные промежутки времени вставляется строка для описания поведения за этот период. При использовании настроек по умолчанию таблица RESOURCESNAP обновляется каждые 10 секунд, и каждые 60 секунд в RESOURCEUSAGE вставляется новая строка, содержащая максимальное, минимальное и среднее значения последних шести обновлений для комбинации HOSTID и HEAD_HOSTID. Столбец StartTimestamp данной таблицы может использоваться для сортировки записей по времени.

Для каждого столбца RESOURCESNAP, содержащего системные счетчики, имеется три столбца с суффиксами Avg, Max и Min. Т.е. CPUPctUserAvg – это среднее значение, основанное на столбце CPUPctUser, а MemFreeKBPhysicalMin – это минимальное значение столбца MemFreeKBPhysical за период между StartTimestamp и EndTimestamp.

Листинг 16. Пример SQL-запроса: запрос к представлению RESOURCEUSAGESYSTEM
— Вывести средние значения использования процессора для хост-системы H — между YYYY-MM-D1 HH:MM:SS и YYYY-MM-D2 HH:MM:SS. SELECT RS.StartTimestamp, RS.CPUPctUserAvg FROM DSODB.RESOURCEUSAGESYSTEM AS RS JOIN DSODB.HOST AS H ON RS.HEAD_HOSTID = H.HOSTID WHERE H.HostName= «H» AND RS.StartTimeStamp >= «YYYY-MM-D1 HH:MM:SS» AND RS.EndTimeStamp

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

Листинг 17. Пример SQL-запроса: запрос к представлению RESOURCEUSAGEDISKS
— Вывести все периоды, за которые свободное пространство — для любых путей на хост-системе N, — за которой ведется мониторинг с хост-системы H, было меньше 1 MБ. SELECT RD.DiskPathMonitored, RD.StartTimestamp, RD.EndTimestamp, RD.DiskFreeKBMin FROM DSODB.RESOURCEUSAGEDISKS AS RD JOIN DSODB.HOST AS H ON RD.HEAD_HOSTID = H.HOSTID JOIN DSODB.HOST AS H2 ON RD.HOSTID = H2.HOSTID WHERE H.HostName = «H» AND H2.HostName = «N» AND RD.DiskFreeKBMin < 1024

Есть несколько таблиц, в столбцах которых хранятся нумерованные значения кода, имеющие вид слабо мнемонических трехсимвольных ASCII-строк в верхнем регистре (см. рисунок 9). При необходимости их можно представить в более удобном для чтения виде, используя таблицу MASTERREF и основанные на ней представления.

Эта таблица содержит строку для каждого уникального значения каждого нумерованного типа. Комбинация столбцов Enumeration и Code формирует первичный ключ, который может быть использован следующими представлениями для поиска конкретного значения кода. Столбцы Name и Description предоставляют более содержательные строки, которые можно использовать в отчетах вместо самого значения кода.

Каждое представление соответствует таблице и столбцу, содержащему код, как показано в таблице 2.

DB2 Express-C, бесплатную версию DB2 Express Edition для сообщества, которая предлагает те же основные функции, что и DB2 Express Edtion, и предоставляет надежную основу для создания и развертывания приложений.

Лен Гринвуд (Len Greenwood) был членом небольшой группы, разработавшей в 1996 году первую версию DataStage, которую IBM приобрела у Ascential Software в 2005 году. Сейчас эта версия является основой пакета программ IBM InfoSphere Information Server. Последние 15 лет Лен работал в смежных областях интеграции данных и метаданных, а в настоящее время является главным архитектором основных компонентов средств разработки и эксплуатации DataStage и QualityStage. Недавно он разработал схему базы данных, лежащую в основе продукта Information Server Operations Console, применяемого для мониторинга работы на уровне внутреннего механизма DataStage.

Аррон Харден (Arron Harden) работает старшим инженером-программистом по продуктам IBM InfoSphere DataStage и QualityStage. Оставаясь разработчиком продукта DataStage, несмотря на несколько слияний и приобретений, он уже более 12 лет занимается DataStage в IBM, куда пришел в результате приобретения IBM компании Ascential Software Inc в 2005 году. После нескольких лет работы в Бостоне он переехал в Великобританию и работает в офисе IBM им. Милтона Кейнса. В последнее время он является ведущим разработчиком Web-компонента DataStage and QualityStage Operations Console, создаваемого при помощи Dojo Toolkit.

Джефф Маклин (Geoff McClean) был членом группы разработки DataStage с самого начала, а в настоящее время является ведущим разработчиком основных компонентов средств разработки и эксплуатации IBM InfoSphere DataStage и QualityStage, являющихся частью пакета программ IBM InfoSphere Information Server. Он контролирует реализацию сервисов управления базой данных, обработки событий и отслеживания ресурсов в IBM InfoSphere DataStage and QualityStage Operations Console.

Сумит Кумар (Sumit Kumar) имеет 13-летний опыт работы в разных отраслях, включая финансы, банковские услуги, телекоммуникации, управление цепочками поставок, страхование и здравоохранение. Он занимается продуктом IBM InfoSphere Information Server с начала 2010 года, том числе функциональностью Operations Console сервера Information Server в качестве ключевого сотрудника с самого начала ее проектирования и разработки. Участвовал в реализации большинства общедоступных интерфейсов прикладного программирования и сервисных уровней Operations Console.

Спасибо. Эта запись была помечена для модератора.

Сообщение о нарушении не было отправлено. Попробуйте, пожалуйста, позже.

developerWorks: вход

При первом входе в developerWorks для Вас будет создан профиль. Выберите информацию отображаемую в Вашем профиле — скрыть или отобразить поля можно в любой момент.

Вся введенная информация защищена.

Выберите ваше отображаемое имя

При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Вся введенная информация защищена.

ArticleTitle=Начало работы с IBM InfoSphere DataStage and QualityStage Operations Console Database: Часть 1. Введение