среда, 9 декабря 2009 г.
Про кризис
Кризис, рецессия. А с чего все взяли, что это кризис? Это тяжкое похмелье после эйфории "легких" денег. Пора уже учиться честным трудом зарабатывать. Хотя некоторым уже поздно...
понедельник, 7 декабря 2009 г.
Старость - не радость
Совершенно не могу работать в проектах, где не я архитектуру/дизайн разрабатывал и/или одобрял. Замечаю такое количество ошибок, что просто отворачивает сразу и надолго. Когда в такой проект попадаешь, как-то не вяжется с тем, что уже вроде как 2009 год. Старость, что-ли?
Вот, например, текущий проект. Множество ETL трансформаций перерабатывает данные от различных торговых систем банка. Трансформация стартуют в тот момент, когда внешняя система публикует очередной снимок своего состояния в виде CSV файла или в Oracle view. Переработанные данные складываются в гигантскую базу на основе Oracle, где хранятся на протяжении нескольких лет.
Соответственно, хаотический подход к проектированию породил зверя, у которого трансформации конфигурируются через базу данных, планировщик, их запускающий, написан на Java, а сами трансформации по большей части на PL/SQL. Типичная трансформация работает так: планировщик обнаруживает новую версию файла и запускает SQL Loader. Loader заливает данные в нелогируемую и неархивируемую таблицу. Далее планировщик запускает хранимую процедуру валидации, которая проверяет, что нет повторений и все важные поля не пусты. После этого он выполняет другую процедуру, которая перемещает данные в основную логируемую и архивируемую таблицу, где данные остаются жить на веки вечные. Следующий и последний шаг, который исполняется планировщиком также путем вызова хранимки, - формирование и рассылка событий с помощью OracleAQ.
Что и почему мне категорически не нравится в имплементации? Попробую раскрыть подробнее:
Планировщик
Что есть:
практически единственный, жестко-фиксированный тип задания, который он может обработать - проверить, есть ли новый снимок и запустить трансформацию из фиксированного набора шагов (см. выше). Конфигурировать можно то, какие хранимки вызываются, но их набор ограничивается структурой таблицы, а порядок вызова - джавовским обработчиком.
Что наблюдаем:
помимо оригинального требования к обработке файлов от внешних систем появились новые - импорт из view, автономный периодический экспорт своего состояния, etc. Всё новое в существующую схему БД вписывается очень криво, многие поля начинают трактоваться по-иному, в зависимости от типа задания.
Должно быть:
гибкий планировщик с персистентностью, безразличный к реализации выполняемых задач. Планировщик должен уметь регулярно или однократно запускать задачу, продвигать задачу из состояния в состояния, сохранять его при необходимости, иметь четко выраженный интерфейс управления и мониторинга. Фактически, persisting workflow manager.
Конфигурацию для задания также как и его состояние вовсе не обязательно размазывать по туче таблиц. Можно хранить в виде XML или JSON.
Трансформации
Что есть:
Куча однотипных PL/SQL процедур, которые варьируются в зависимости от внешней системы, откуда происходит импорт. Используются составные ключи из трех компонент: тип задачи, версия данных и дата обработки.
Что наблюдаем:
Огромное количество copy-paste кода с крайне ограниченным повторным использованием, без намека на юнит-тесты.Не говоря уже о том, что PL/SQL выглядит крайне убого и угрожающе громоздко в тех случаях,когда требуется найти дупликаты или обнаружить пропущенные значения.(PL/SQL вообще недоязык какой-то - длина идентификатора ограничена 30 символами, пространств имен нет, набор функций крайне ограниченный,разбиение пакетов на спецификацию и тело живо напоминает о всех сходных неудобствах с++; в общем - откровенное старьё).
Проблемы управления экземпляром Оракла, где постоянно на больших объёмах данных происходит переполнение архивного лога. Вопрос скорее организационный, но, зная тормознутость местных админов, нужно было это предвидеть и учесть в архитектуре.
Следует использовать однокомпонентные ключи хотя бы для того, чтобы избежать необходимости повторять набор параметров в процедурах. Тем более, что наиболее часто встречающаяся комбинация из нескольких компонент [тип, версия, дата], скорее всего, идентифицирует один объект - Job (тогда описание задания будет именоваться JobTemplate).
Должно быть:
Варант 1 - нафиг Оракл, используем SQL Server и SSIS. Все трансформации конфигурируются в виде SSIS-пакеты и деплоятся как задачи в SQLServer Agent.
Кстати, SQLServer обладает серьезным преимуществом перед Ораклом в том, что возможно выполнять bulk load, используя клиентское API. В Оракле же - только sqlldr.
Вариант 2 - цепочку sql loader >> java scheduler- >> duplicate-and-null check stored proc выбрасываем. Вместо этого читаем CSV на Java, отбрасываем дупликаты, проверяем на null, и результат сохраняем в CSV-файл, который затем загружается Loader-ом в основную таблицу. Получаем важное преимущество - независимый процесс гораздо проще контролировать, чем поведение экземпляра Оракл, нагруженного обработкой больших объёмов данных. Более того, исчерпание дискового пространства также проще контролировать и исправлять проблемы, нежели управлять экземпляром Оракла при помощи местных админов.
С точки зрения производительности проведенный мной несложный тест показал, что скорость такого процессинга сравнима, если не лучше, чем в оргинальной последовательности.
[To be updated]
Вот, например, текущий проект. Множество ETL трансформаций перерабатывает данные от различных торговых систем банка. Трансформация стартуют в тот момент, когда внешняя система публикует очередной снимок своего состояния в виде CSV файла или в Oracle view. Переработанные данные складываются в гигантскую базу на основе Oracle, где хранятся на протяжении нескольких лет.
Соответственно, хаотический подход к проектированию породил зверя, у которого трансформации конфигурируются через базу данных, планировщик, их запускающий, написан на Java, а сами трансформации по большей части на PL/SQL. Типичная трансформация работает так: планировщик обнаруживает новую версию файла и запускает SQL Loader. Loader заливает данные в нелогируемую и неархивируемую таблицу. Далее планировщик запускает хранимую процедуру валидации, которая проверяет, что нет повторений и все важные поля не пусты. После этого он выполняет другую процедуру, которая перемещает данные в основную логируемую и архивируемую таблицу, где данные остаются жить на веки вечные. Следующий и последний шаг, который исполняется планировщиком также путем вызова хранимки, - формирование и рассылка событий с помощью OracleAQ.
Что и почему мне категорически не нравится в имплементации? Попробую раскрыть подробнее:
Планировщик
Что есть:
практически единственный, жестко-фиксированный тип задания, который он может обработать - проверить, есть ли новый снимок и запустить трансформацию из фиксированного набора шагов (см. выше). Конфигурировать можно то, какие хранимки вызываются, но их набор ограничивается структурой таблицы, а порядок вызова - джавовским обработчиком.
Что наблюдаем:
помимо оригинального требования к обработке файлов от внешних систем появились новые - импорт из view, автономный периодический экспорт своего состояния, etc. Всё новое в существующую схему БД вписывается очень криво, многие поля начинают трактоваться по-иному, в зависимости от типа задания.
Должно быть:
гибкий планировщик с персистентностью, безразличный к реализации выполняемых задач. Планировщик должен уметь регулярно или однократно запускать задачу, продвигать задачу из состояния в состояния, сохранять его при необходимости, иметь четко выраженный интерфейс управления и мониторинга. Фактически, persisting workflow manager.
Конфигурацию для задания также как и его состояние вовсе не обязательно размазывать по туче таблиц. Можно хранить в виде XML или JSON.
Трансформации
Что есть:
Куча однотипных PL/SQL процедур, которые варьируются в зависимости от внешней системы, откуда происходит импорт. Используются составные ключи из трех компонент: тип задачи, версия данных и дата обработки.
Что наблюдаем:
Огромное количество copy-paste кода с крайне ограниченным повторным использованием, без намека на юнит-тесты.Не говоря уже о том, что PL/SQL выглядит крайне убого и угрожающе громоздко в тех случаях,когда требуется найти дупликаты или обнаружить пропущенные значения.(PL/SQL вообще недоязык какой-то - длина идентификатора ограничена 30 символами, пространств имен нет, набор функций крайне ограниченный,разбиение пакетов на спецификацию и тело живо напоминает о всех сходных неудобствах с++; в общем - откровенное старьё).
Проблемы управления экземпляром Оракла, где постоянно на больших объёмах данных происходит переполнение архивного лога. Вопрос скорее организационный, но, зная тормознутость местных админов, нужно было это предвидеть и учесть в архитектуре.
Следует использовать однокомпонентные ключи хотя бы для того, чтобы избежать необходимости повторять набор параметров в процедурах. Тем более, что наиболее часто встречающаяся комбинация из нескольких компонент [тип, версия, дата], скорее всего, идентифицирует один объект - Job (тогда описание задания будет именоваться JobTemplate).
Должно быть:
Варант 1 - нафиг Оракл, используем SQL Server и SSIS. Все трансформации конфигурируются в виде SSIS-пакеты и деплоятся как задачи в SQLServer Agent.
Кстати, SQLServer обладает серьезным преимуществом перед Ораклом в том, что возможно выполнять bulk load, используя клиентское API. В Оракле же - только sqlldr.
Вариант 2 - цепочку sql loader >> java scheduler- >> duplicate-and-null check stored proc выбрасываем. Вместо этого читаем CSV на Java, отбрасываем дупликаты, проверяем на null, и результат сохраняем в CSV-файл, который затем загружается Loader-ом в основную таблицу. Получаем важное преимущество - независимый процесс гораздо проще контролировать, чем поведение экземпляра Оракл, нагруженного обработкой больших объёмов данных. Более того, исчерпание дискового пространства также проще контролировать и исправлять проблемы, нежели управлять экземпляром Оракла при помощи местных админов.
С точки зрения производительности проведенный мной несложный тест показал, что скорость такого процессинга сравнима, если не лучше, чем в оргинальной последовательности.
[To be updated]
пятница, 4 декабря 2009 г.
Бизнес-линч - вариант code review?
Забавно, сейчас вдруг подумалось, что Бизнес-линч студии Лебедева - это тоже вариант design/code review.
Почему-то подобная практика всё еще слишком редка в разработке ПО. Существенное отличие нормально организованного программистского код-ревью от Бизнес-линча - гораздо более мягкая форма указания на недостатки. :-)
Почему-то подобная практика всё еще слишком редка в разработке ПО. Существенное отличие нормально организованного программистского код-ревью от Бизнес-линча - гораздо более мягкая форма указания на недостатки. :-)
четверг, 3 декабря 2009 г.
Влад Жигалов: О лирике и физике
Влад Жигалов замечательно отразил ощущения от происходящего в своей новой статье. Чему я несказанно рад, ибо мне такая четкость изложения не подвластна, а мысли-то в голове те же самые крутятся! Присоединяюсь к твоим словам, Влад! Спасибо, дружище! :-)
четверг, 26 ноября 2009 г.
Чуть-чуть о СССР
Кажется я знаю, что было такого в СССР, чего теперь почти не найти - практически не было манипуляций сознанием на бытовом уровне. Идеология КПСС, безусловно, та еще промывка мозгов была. Но зато тебе никто ничего не пытался впарить или выманить денег, используя многочисленные манипулятивные техники. Люди, по-моему, даже не задумывались, что такое возможно. Больше искренности было, что-ли. Незамутненность.
И еще одно наблюдение - мне иногда кажется, что не только россияне, нынешние или бывшие, по СССР скучают как о сказке, которая могла бы сбыться.
P.S. Это я вовсе не о "назад в СССР". Это о том, что ценным бывает не только то, что можно приобрести за золотые. Потерять такое богатство, как оказалось, проще, но найти очень сложно.
И еще одно наблюдение - мне иногда кажется, что не только россияне, нынешние или бывшие, по СССР скучают как о сказке, которая могла бы сбыться.
P.S. Это я вовсе не о "назад в СССР". Это о том, что ценным бывает не только то, что можно приобрести за золотые. Потерять такое богатство, как оказалось, проще, но найти очень сложно.
среда, 25 ноября 2009 г.
Избушку хочу
Пришёл, видимо, к закономерному пониманию того, что работа в офисе, независимо от её сложности и интересности, абсолютно не приносит морального удовлетворения. Хочется работать так, чтобы чувстовать приятную усталость в конце дня. Если честно, уже не помню когда такое было в последний раз.Потому для меня всё более привлекательной выглядит идея, воплощенная Германом Стерлиговым - завести свой дом в сельской местности, хозяйство, растить на свежем воздухе детей, приучая их к труду. Как-то естественно и честно жить такой жизнью для человека. Решаешь сам, как хозяйство развивать и что делать для этого нужно. Да и получаешь ровно столько сколько наработал. Главное, что занят с утра до вечера, без возможности предаваться лени. Чтоб было как учили: "делу время, потехе час".
пятница, 6 ноября 2009 г.
А ну-ка песню нам пропой, веселый ветер!
Который раз замечаю как старые песни "цепляют" своим бесконечным положительным зарядом несоизмеримо сильнее, чем любые проявления современной культуры.Вот, например, только что послушал эту, так сразу чакры открываться стали. :)Богатые душой люди все-таки жили тогда.
Песенка Роберта Гранта из к/ф "Дети капитана Гранта"
Музыка: И.О. Дунаевский Слова: В.И. Лебедев-Кумач.
Песенка Роберта Гранта из к/ф "Дети капитана Гранта"
Музыка: И.О. Дунаевский Слова: В.И. Лебедев-Кумач.
А ну-ка песню нам пропой, веселый ветер!
Веселый ветер, веселый ветер!
Моря и горы ты обшарил все на свете
И все на свете песенки слыхал.
Спой нам, ветер, про дикие горы,
Про глубокие тайны морей,
Про птичьи разговоры,
Про синие просторы,
Про смелых и больших людей.
Кто привык за победу бороться,
С нами вместе пускай запоет:
"Кто весел - тот смеется,
Кто хочет - тот добьется,
Кто ищет - тот всегда найдет!"
А ну-ка песню нам пропой, веселый ветер!
Веселый ветер, веселый ветер!
Моря и горы ты обшарил все на свете
И все на свете песенки слыхал.
Спой нам, ветер, про чащи лесные,
Про звериный запутанный след,
Про шорохи ночные,
Про мускулы стальные,
Про радость боевых побед.
Кто привык за победу бороться,
С нами вместе пускай запоет:
"Кто весел - тот смеется,
Кто хочет - тот добьется,
Кто ищет - тот всегда найдет!"
А ну-ка песню нам пропой, веселый ветер!
Веселый ветер, веселый ветер!
Моря и горы ты обшарил все на свете
И все на свете песенки слыхал.
Спой нам, ветер, про славу и смелость,
Про ученых, героев, бойцов,
Чтоб сердце загорелось,
Чтоб каждому хотелось
Догнать и перегнать отцов.
Кто привык за победу бороться,
С нами вместе пускай запоет:
"Кто весел - тот смеется,
Кто хочет - тот добьется,
Кто ищет - тот всегда найдет!"
А ну-ка песню нам пропой, веселый ветер!
Веселый ветер, веселый ветер!
Моря и горы ты обшарил все на свете
И все на свете песенки слыхал.
Спой нам песню, чтоб в ней прозвучали
Все весенние песни земли,
Чтоб трубы заиграли,
Чтоб губы подпевали,
Чтоб ноги веселей пошли.
Кто привык за победу бороться,
С нами вместе пускай запоет:
"Кто весел - тот смеется,
Кто хочет - тот добьется,
Кто ищет - тот всегда найдет!"
Подписаться на:
Сообщения (Atom)