Вторник, 26.09.2017, 17:42
Приветствую Вас Гость | RSS
Главная | Блог | Регистрация | Вход
Форма входа
Логин:
Пароль:
Поиск

Меню сайта

Категории раздела
Техническое [24]
Все о мейнфреймах и не только о них, но все-таки крепко связанное с техникой и инженерными моментами.
Разговорчики [24]
Обо всем остальном, не относящемся к технике.

Календарь
«  Октябрь 2015  »
ПнВтСрЧтПтСбВс
   1234
567891011
12131415161718
19202122232425
262728293031

Архив записей

Наш опрос
О регистрации на сайте с помощью соцсетей.
Всего ответов: 12

Метки
EGL ODM бизнес правила программирование SOA arcati блоги журналы Каталог мейнфреймы журнал z/os Freeware VM bigdata nosql MVS OS zOS SLES zLinux мейнфрейм Хабрахабр 50лет документы хранилище Java EE liberty WebSphere history сообщение Форум DFSORT Hercules VSAM отчётность Linux Analytics Accelerator Netezza IMS IBM IDC продажа CHKPT GSam XRST гипервизор KVM Shutdown #hollywar mainframe Вакансии Санкт-Петербург пример Assembler LHI vs XR instruction to clear GPR z Seies CPU performance семинар впечатление доступность ЦБ цены аутсорсинг BMC CMS ZVM санкции Rockwell история z13 мобильность DB2 Java Coupling Facility Parallel Sysplex WebSphere AS MVT ОС ЕС ссср Tape VTL Вакансия БЛОГ Линукс Новое статьи Люксофт Польша Работа

Статистика

Главная » 2015 » Октябрь » 8 » Статистическая отчётность, позиционирование DB2/Z, или а не набросить ли нам на вентилятор...

Статистическая отчётность, позиционирование DB2/Z, или а не набросить ли нам на вентилятор...
17:21

Введение или исходные посылки.

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

Второй факт.
В связи с этим отчётные системы не только строятся на отдельной инстанции (подсистеме) того же ПО, на котором и оперативные системы, но зачастую на специализированном ПО, и даже на специализированных аппаратных платформах (terradata, netteza).
Это приводит к резкому удорожанию совокупной стоимости системы.

Третий факт.
Ещё за десятилетия до того, как появилось само понятие "аналитические системы", уже строились финансовые и прочие статистические отчёты. На мейнфреймах - больше не на чем было, основная бизнес платформа. Я так думаю...

Выводы из исходных посылок:
1. разделить оперативную и анаитическую системы;
2. минимизировать влияние на текущую нагрузку
3. использовать то, что уже есть, как минимум на начальном этапе и далее, пока будет решаться задача.

Решение по 1-му выводу: из оперативной системы выгружаются факты, данные, которые нужны для анализа. После выгрузки данные могут быть обработаны безо всякого взаимодействия с оперативной системой, даже могут быть перенесены на резервный сервер и обработаны там.

Решение по 2-му выводу: данные выгружаются как можно менее затратным способом, без всяких обработок, без агрегатирования, в бинарном виде, как есть, применяя обходные способы, позволяющие снизить нагрузку на базу, например, для реляционки это может быть замена операций JOIN на перебор записей в циклах в программе.

Решение по 3-му выводу: использование для построения отчётности подсистему DFSORT из состава z/OS, так как она всё равно есть, куплена, и не используется. Собственно, она и использовалась многие годы для создания всевозможной отчётности, в первую очередь финансовой.

Особенности DFSORT,
которые позволяют её использовать и которые мы можем использовать.

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

- За один проход по входным данным строятся любое нужное количество разных отчётов.
- Фильтрация входных данных - для каждого отчёта могут быть отфильтрованы тольку нужные, удовлетворяющие условиям этого отчёта, данные.
- Наличие арифметических функций, арифметики работы с датами, агрегатирующих функций - min, max, average, count (подсчёт количества)
- Способность вычислять итоги по всему отчёту с использованием агрегатирующих функций.
- Способность разбивать всё множество данных, попадающих под отчёт, на секции по какому либо полю, и выполнять подсчёт подитогов отдельно для каждой секции, делая отчёт с итогами и подитогами. Если секции вложенные, то тут требуется уже усидчивость и умение думать головой, но задача решается.
- возможность объединения файлов с данными по условиям совпадения (или несовпадения) указанных полей, что может быть полезно при построении отчётов типа "в сравнени за период прошлого года, и т.д.". Фактически это операция JOIN, аналогичная таковой в РДБМС, включая inner и outer, left и right.

- возможность работы с VSAM включая KSDS.
- высокая производительность работы, оубсловленная, как мне кажется, не в последнюю очередь тем, что командные предложения DFSORT суть есть макросы ассемблера, которые компилируются во время исполнения.
- логичный текстовый интерфейс и возможност менять отчёты "на лету"
- возможность построения отчётности как в человеко-читаемой форме, так и в виде колонок данных, пригодных для дальнейшего анализа в Excel или для построения диаграмм и графиков посредством gnuplot (делает очень качественные графики в разных форматах)

Недостатки DFSORT
- Текстовый интерфейс, отсутствие мышиного (графического) интерфейса.
 То есть, коллегам, не работающим без чего-то типа TOAD, такой подход не подходит, простите за тавтологию.

- Синтаксис... Тот случай, когда преимущества и недостатки ходят рука об руку... Макросы - производительность, и Макросы - строгий синтаксис... Да и читать код не так уж и просто, нао под рукой иметь файл с нумерацией колонок, увы.




Примерная схема работы.
- Программа выгружает сырые данные с фактами, необходимыми для анализа. Возможно выгрузка всех фактов на регулярной основе, без поступления требования от заказчика. Как показала практика, в случае, когда выгружаемые записи взаимосвязаны - при выгрузке одной требуется посмотреть взаимосвязанную с ней (чаще всего, когда записи представляют собой половинки одного и того же события, являются полу-событиями), то выгружать лучше в KSDS VSAM, потому как быстренько можно обратиться к нужной записи.... А учитывая AIX для VSAM... Ну это же песня! 
- Данные переносятся в среду для построения отчётов. Могут сразу или позже отправляться на ленту.
- Запускаются задания с готовыми командными предложениями DFSORT для построения нужных отчётов. Возможно построение отчётов с итонгами и подитогами за период (месяц, квартал, пол года, год) с группировкой по основным очевидным показателям (по странам, по пунктам пропуска, по целям поездки, и т.д.) без предварительного требования, "на всякий случай", чтобы было под рукой для предъявления, скорее всего, сама информация о том, что такие отчёты есть, приведёт к их затребованию.
- При поступлении заявки на подготовки специализированных отчётов - дорабатываются текстовые команды DFSORT для построения нужной отчётности.
- отчётность сохраняется в наборах данных - по принципу, описанному мною в документе по системе "СХОД", с архивацией на ленту.
- При накоплении отчётов за разные периоды строятся "на всякий случай" отчёты за прошедший период в сравнении с аналогичным периодом прошлого года, например. Для чего отчёт за прошлый период извлекается (автоматически, заданием JCL по вызову DFSORT) с ленточного носителя.
- отчёты с итогами и подитогами могут импортироваться в EXCEL для дальнейшей обработки или придания надлежащего вида.
- отчёты, особенно типа "в сравнении с аналогичным периодом прошлого года" поступают на вход gnuplot для построения всевозможных графиков (изменения каких-то параметров с течением времени, например).


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

 

В связи с чем возникает вопрос о позиционировании DB2/Z в широком смысле этого слова. Как платформа для OLTP она проигрывает на 4 порядка тому же IMS, и не знаю, на сколько порядков - другим базам, тому же ADABAS, IDMS, например. Как платформа для статистической отчётностим - да незачем, дорого! Как платформа для аналитики  настоящей, а не статистической отчётности... А зачем, скажите мне, покупать DB2/Z и к ней IDAA aka Netteza, если одной Netteza вполне можно обойтись? Ну или Teradata, на выбор... Ну или DB2 for zLinux... Как вариант...


Ну вот как-то так вот.

А ещё у нас задание JCL использует DFSORT для выполнения резервного копирования всех каталогов ICF, которые есть на данный момент в системе, получая их имена динамически. То есть, получаем имена каталогов, парсим, вынимая что надо, строим JCL для верификации, строим JCL для резервного копирования, и так далее. Получается матрёшка - первый запуск DFSORT строит задания, которые запускают DFSORT для построенияй  других заданий, ну и так до тех пор, пока задача не решена. 

А ещё она просто быстрее копирует файлы, чем IDCAMS или IEBGENER... И вообще! Да!
------------------------------------------------------------------------------------------
old programmers never die, we just go out of sequence

Категория: Разговорчики | Просмотров: 762 | Добавил: ggv | Теги: DB2, отчётность, VSAM, DFSORT | Рейтинг: 3.0/1 |


Всего комментариев: 8
8  
вот пример производительности.
Задача - агрегатированный отчёт. То, что в Excel называется Сводная Таблица или Pivot Table.
Строки - названия. 
Колонки - группы дней, до одного дня, 1-3 дня, 4-7, и так далее, до 13-21 день. На пересечениях строк и колонок - суммированные показатели, за строку и за группу дней. Но последняя колонка - Среднее Значение, но не строк в Сводной Таблице, а по формуле
СрЗнач = (4дня*n1+ 5дней*n2+6дней*n3+...+92дня*n89)/(n1+n2+n2+...+n89) где n1,2,3 - собственно агрегатируемый показатель.
Очевидно, что в Сводной Таблице по группам дней исходных данных для формулы нету, и простым щелчком мыши Среднее Значение не посчитать.

Данные в СУБД.
Вынимаются из неё в последовательный набор, 25 тыщ цилиндров, LRECL=971, два поля дата-время, текстовые поля, одно из них используется в Сводной Таблице для обозначения строк, и, падла, может быть незаполненно, но есть числовое поле, код которого обозначает должное быть название в текстовом поле (идентификатор).

Агрегаты дожны считаться по разнице дат полей дата-время каждой строки.
Вынимается по условию из СУБД 13 с лишним миллиона строк.
Первым шагом отфильтровываются около миллиона строк.

Вторым шагом отфильтровываются в разне наборы данных записи содержащие текстовое поле (название строк будущей Сводной Таблицы, 4.5 миллиона записей), не содержащие этого текстового поля (7 с чем-то миллионов записей), и не содержащие числового поля - идентификатора (меньше 800 тыщ записей).

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

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

Пятым шагом добавляется новое поле - разница двух дат полей дата-время.
Если разница меньше минуты между полями дата-время (с учётом перехода через 0 часов), то добавляется поле-метка, помечая таким образом эти записи.
Происходит добавление поля-метки обозначения группы, к которую попадает запись, в зависимости от количества дней разницы между полями дата-время - 0 суток, 1-3 суток, 4-7 и так далее.
На выходе количество записей не меняется, но она становится диннее.

Шестым шагом происходит агрегатирование (DFSORT SECTIONS) по полю-метке, обозначающем группу дней, в которую попала запись.
Входящие 11.5 миллионов записей свернулись в чуть больше, чем 2 тыщи записей, первый отчёт, исходные данные для Сводной Таблицы.

Седьмым шагом происходит агрегатирование по количеству дней разницы между полями дата-время, входящие 11.5 миллиона записей сворачиваются в 43 тыщи записей, второй отчёт, исходные данные для подсчёта Среднего Значения по предоставленной формуле.

Работа в DFSORT закончилась, прошло 15 минут на хиленькой машинке. Да и в геркулесе это отрабатывает на удивление неплохо.

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

При изменении хотелок DFSORT натравливается на исходный набор, и готовится основа для следующего отчёта, без обращения к базе.

DFSORT - первый продукт, который должен браться в руки в случаях, когда кто-то произносит "Отчёты" или "Аналитика".
И только если им невозможн выполнить задачу - то тогда уже можно думать, какой аналитический пакет брать.
Excel - сильный продукт, но от 13 миллионов записей ему плохеет... 
А DFSORT'у фиолетово, сколько ему на вход подают записей.

7  
IMHO, единственным существенным недостатком DFSORT является невнятные управляющие операторы, правда, ICETOOL частично устраняет этот недостаток. А вот скорость работы DFSORT иногда просто поражает. Кроме того, в ряде случаев без DFSORT очень трудно вообще обойтись, например, при устранении дублирования данных, полученных из разных источников. Сделать то же самое с помощью SQL очень непросто, а DFSORT/ICETOOL - на раз (SPLICE). Так что в реализации E-T-L DFSORT давно занимает достойное место

0
1  
дык а в чем наброс-то?... в старых, особенно импортных, организациях отчетные системы, построеные на DFSORT, давно используются. я с немцем и американцем общался в конце 90-х, они занимались ТОЛЬКО DFSORT, и ничем больше.
у меня в нынешней организации ряд аналитичек собирается тож без СУБД, чисто возможностями DFSORT.
в моей прежней организации тоже некую аналитику для нескольких задачек под VM делали на чистом DFSORT+REXX, без всякого DB2))), хехе...
так что вот.

2  
ну если меня назвали за такие мысли ретроградом....
то на тебя даже слов не хватает smile
Назвали ретроградом и тут же начали нахваливать in-memory всякие чудеса.
У меня только один вопрос - они вот расчётные 90 террабайт информации в какое in-memory чудо засунут, и сколько оно в итоге будет стоить?
И сколько будет стоить DFSORT  которая с ленты тоже может читать, вернее, не она, но не суть.

0
3  
Вот если правду говорить, то у DFSORT тоже есть цена, она не бесплатная, и цена эта не копеечная. И еще - DFSORT имеет нестандартный и странноватый язык, он требует освоения. SQL попроще будет. У меня (как и у моих собеседников) процесс обработки выглядел так: программа выгрузки сырых данных - DFSORT - пользовательская программа - DFSORT - DFSORT - пользовательская программа.
То есть DFSORT - очень крутая, безумно классная программа, но со своими ограничениями и требующая знания своих возможностей, языка, и дополнительной обработки полученных результатов.

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

Так что - надо учить, и надо использовать.
Могу сюда тиснуть, например, джобик, по динамическому резервному копированию каталогов.
Хотя это бесполезно - куда как полезнее самому написать.

А по поводу требует дополнительной обработки...
Вот, к примеру, Excel - безумно крутая по возможностям вещь, что угодно можно сделать.
Но вот выгружаем данные эдак гигабайт на 10.
Что нам Excel на это скажет?
А DFSORT-у на размер фиолетово.
А вот уже посе обработки разными способами в DFSORT, фильтраций, вычислений агрегатов, слияний и объединений - результат в Excel, и оформляем до конца.
Хотя ничто не мешает включать в промежутки пользовательские программы, как у вас.
Мне пока такого не надо было, но лиха беда начало, ещё потребуется.

Просто вот понравился мне DFSORT, а у нас тут про него молчок... Решил, что это несправедливо - достойная компонента z/OS. Таким творением можно гордиться.
Не Когнос какой-то smile

0
5  
Ну чойта у нас про DFSORT вдруг и молчок? А это - http://s390soft.ru/publ/12-1-0-4 - как раз про нее, вполне практическое применение, с живой установки снято. И вот это - http://s390soft.ru/forum/3-136-1#1471 - тоже. Так что если есть желание поделиться в раздел примеров, так не стесняйся, хорошее дело!

6  
а, ну ок, в понедельник запостим первый примерчик

Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]


Яндекс.Метрика