Главная » 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
вот пример производительности. Задача - агрегатированный отчёт. То, что в 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'у фиолетово, сколько ему на вход подают записей.
IMHO, единственным существенным недостатком DFSORT является невнятные управляющие операторы, правда, ICETOOL частично устраняет этот недостаток. А вот скорость работы DFSORT иногда просто поражает. Кроме того, в ряде случаев без DFSORT очень трудно вообще обойтись, например, при устранении дублирования данных, полученных из разных источников. Сделать то же самое с помощью SQL очень непросто, а DFSORT/ICETOOL - на раз (SPLICE). Так что в реализации E-T-L DFSORT давно занимает достойное место
дык а в чем наброс-то?... в старых, особенно импортных, организациях отчетные системы, построеные на DFSORT, давно используются. я с немцем и американцем общался в конце 90-х, они занимались ТОЛЬКО DFSORT, и ничем больше. у меня в нынешней организации ряд аналитичек собирается тож без СУБД, чисто возможностями DFSORT. в моей прежней организации тоже некую аналитику для нескольких задачек под VM делали на чистом DFSORT+REXX, без всякого DB2))), хехе... так что вот.
ну если меня назвали за такие мысли ретроградом.... то на тебя даже слов не хватает Назвали ретроградом и тут же начали нахваливать in-memory всякие чудеса. У меня только один вопрос - они вот расчётные 90 террабайт информации в какое in-memory чудо засунут, и сколько оно в итоге будет стоить? И сколько будет стоить DFSORT которая с ленты тоже может читать, вернее, не она, но не суть.
Вот если правду говорить, то у DFSORT тоже есть цена, она не бесплатная, и цена эта не копеечная. И еще - DFSORT имеет нестандартный и странноватый язык, он требует освоения. SQL попроще будет. У меня (как и у моих собеседников) процесс обработки выглядел так: программа выгрузки сырых данных - DFSORT - пользовательская программа - DFSORT - DFSORT - пользовательская программа. То есть DFSORT - очень крутая, безумно классная программа, но со своими ограничениями и требующая знания своих возможностей, языка, и дополнительной обработки полученных результатов.
дык я про синтаксис написал... да, есть такое дело.... недостаток, как продолжение достоинства. хотя я вот заметил, что начал читать влёт уже... так что это дело навыка. он непривычен - да, но чертовски логичен.
Так что - надо учить, и надо использовать. Могу сюда тиснуть, например, джобик, по динамическому резервному копированию каталогов. Хотя это бесполезно - куда как полезнее самому написать.
А по поводу требует дополнительной обработки... Вот, к примеру, Excel - безумно крутая по возможностям вещь, что угодно можно сделать. Но вот выгружаем данные эдак гигабайт на 10. Что нам Excel на это скажет? А DFSORT-у на размер фиолетово. А вот уже посе обработки разными способами в DFSORT, фильтраций, вычислений агрегатов, слияний и объединений - результат в Excel, и оформляем до конца. Хотя ничто не мешает включать в промежутки пользовательские программы, как у вас. Мне пока такого не надо было, но лиха беда начало, ещё потребуется.
Просто вот понравился мне DFSORT, а у нас тут про него молчок... Решил, что это несправедливо - достойная компонента z/OS. Таким творением можно гордиться. Не Когнос какой-то
Ну чойта у нас про DFSORT вдруг и молчок? А это - http://s390soft.ru/publ/12-1-0-4 - как раз про нее, вполне практическое применение, с живой установки снято. И вот это - http://s390soft.ru/forum/3-136-1#1471 - тоже. Так что если есть желание поделиться в раздел примеров, так не стесняйся, хорошее дело!
