Pentaho Data Integration: первое краткое знакомство
Ссылка: http://www.pentaho.com/product/data-integration
Краткое описание Kettle (дизайнер трансформаций и заданий): http://wiki.pentaho.com/display/EAI/Pentaho+Data+Integration+(Kettle)+Tutorial
Что это такое
Потратил 2 дня на знакомство с этой замечательной системой обработки данных, точнее с той ее частью, которая отвечает за ETL. ETL - это сокращение от Extract Transform Load, то есть загрузка данных, их преобразование и сохранение в новом формате.
Для человека, имеющего опыт работы и разработки под MS Access, Pentaho Data Integration выглядит именно как Access на стероидах. или на анаболиках - система немного монструозна. Объяснение простое - она написана на Java. Что сразу очерчивает некоторые рамки аппетита к ресурсам. В частности, в виртуалке под vSphere с Windows 2008 с квотой в 2 Гб памяти графический дизайнер грузится неторопливо
и работает достаточно размеренно, хотя явного дискомфорта не вызывает. Разве что отдельные нюансы самого гуя напоминают лишний раз, что это GUI на джаве - явно не нативное поведение окон и контролов. Фильтрация шагов по введенному названию вызывает неспешные перерисовки списка после ввода каждого символа, и для "REST client" можно наблюдать полуминутную мультипликацию с морганием палитры инструментов. Впрочем, мелочи.
Решаемая PDI задача, если отбросить технические нюансы, проста и понятна. Есть разные источники данных, в том числе реляционные СУБД, веб-сервисы, простые текстовые файлы в формате CSV и так далее. Там есть ценные данные, которые нужны бизнесу для планирования тактики и стратегии. Чем больше бизнес, тем больше разнородных данных. Аналитика по этим разнородным источникам сводится к повторению одних и тех же шагов: прочитать (точнее, периодически перечитывать) данные из (1C, csv файла, пришедшего из филиала, из Excel документа из департамента стратегического планирования и т.д.), выделить из них подмножество (берем столбцы дата и стоимость акций MSFT, игнорируем остальное), соединяем с выдачей веб-сервиса, который анализирует сентимент IT-новостей в спектре центральных СМИ, джойним, сохраняем в другом месте - пусть это будет какой-нибудь JSON документ в MongoDB. Потом мы эти данные прогоним через регрессионную machine learning модель (см. Weka http://wiki.pentaho.com/display/EAI/Weka+Forecasting), наконец нарисуем красивый репорт (опять там же https://www.profdata.com/reporting/) с рекомендациями - вставать в длинную и как много. Ну или типа того.
Плюсы
(*) Написано на Java, поэтому кроссплатформенно, если повезет с JRE, конечно. У меня со второго захода получилось установить нужную оракловую JRE и стартовать Kettle.
(*) Для софтверной компании, разрабатывающей коробочный продукт для enterprise сегмента, Pentaho DI однозначно суперская вещь с точки зрения маркетинга. На некоторых частях документации концентрация баззводов и наименований модных решений соперничает
с английскими артиклями. К примеру, раздел по Master DataManegement (http://wiki.pentaho.com/display/EAI/Master+Data+Management-Concepts)
перечисляет все основные приемы - Data Quality, Data Cleansing, Validation, Harmonization, Standardization, Data Consolidation (Deduplication, Enrichment).
Загрузить данные из веб-сервиса? Почти без проблем. Правда, я не смог подцепить свой SOAP веб-сервис, пентаха ругнулась на некое несоответствие формата в xml-оформлении конверта. С REST-сервисом все пошло веслее.
(*) Широчайшая поддержка различных РСУБД в качестве источников данных и вариантов сохранения результатов. По-моему, больше чем в MS Access или SSIS. Интеграция с всевозможными NoSQL базами, есть SAP HANA и вся классика типа Oracle и MS SQL. Даже крошка SQLite присутствует. Я сходу сделал сохранение данных в SQLite и оно заработало без каких либо шероховатостей. Потом небольшая пляска со скачиваем Oracle JDBC драйвера и установкой его в нужном каталоге - удалось прочитать данные из оракловой таблицы. Хотя тут был первый неприятный опыт, так как кириллица в varchar2 полях пришла поломанная. То есть настройка локалей где-то на пути требует заботливых рук ветеринара.
(*) Возможность цеплять SOAP и REST-сервисы.
(*) Графический дизайнер для редактирования трансформаций и заданий - это, конечно, плюс для использования PDI не-разработчиками.
(*) Графические программы (трансформации и заданий) сохраняются в XML формате и могут быть, таким образом, созданы и загружены через rest-api сторонними компонентами.
(*) Интеграция с другими компонентами Pentaho, хотя я их не успел попробовать. Отчеты и анализ данных - это хорошо и всегда полезно в реальных бизнес-задачах.
Минусы
(*) Все написано на Java. Поэтому прожорливо и неповоротливо. Когда стартует Carte (сервис, предоставляющий rest-api для создания/запуска/мониторинга трансформаций и заданий), в логе видно, как он инициализирует кучку всяких приблуд - кэши, вспомогательные библиотеки. Выглядит монструозно.
(*) Немного ненативный GUI. Хотя надо сказать, что эта ненативность гораздо нативнее, чем, к примеру, в PyCharm, который меня своими файловыми диалогами иногда ставит в тупик.
(*) Конфигурирование java-style, через xml-конфиги. Лично мне это всегда доставляет боль, так как неимоверное время тратится, чтобы нагуглить и подобрать, какие параметры в каких конфигах надо выставить в волшебные значения, чтобы все завелось. Например, правильный конфиг
для Carte, чтобы сервис увидел репозиторий с готовыми трансформациями, у меня получилось сделать не сразу, а через пару часов гугления и экспериментов.
(*) Это графический язык программирования со всеми вытекающими. Чтобы понять, какой визуальный кирпичик надо подпихнуть и как его настроить для выполнения элементарного действия, приходится гуглить, зырить видюшки на ютубе, в общем чуствовать себя полным буратиной. Возможно, по мере набора компетенции этот фактор станет меньше, но по началу просто часы уходят на то, что в питоне делается за 10 минут. Спустя день мне удалось выстроить трансформацию, в которой данные загружаются из моего rest-сервиса в json-формате, немного модифицируются, затем запихиваются в другой rest-сервис.
(*) Документация (вики) крайне скудна. Местами это просто скриншоты диалоговых окошек с перечислением подписей к контролам, то есть абсолютно бесполезная штука.
(*) В документации говорится, что можно использовать Python для написания специальных трансформаций. У меня не получилось даже понять, как это сделать. Никаких следов переключения с JavaScript на другие ЯП в кирпичике SCRIPT найти не удалось. Нашел некий плагин, который должен добавить поддержку Jython. Скачал его с гитхаба, запустил сборку в java-системе сборки, после 10 минут скачивания зависимостей и сборки эта редиска ругнулась "Fatal error in java compiler" и все. Представив, как этот процесс делать у клиентов удаленно с ограниченным доступом в инет, я решил что это плохой путь.
(*) Редактор js-скриптов в трансформациях мягко говоря убог. Нет, конечно я могу писать без поддержки IDE, и иногда редактирую программы на питоне просто в Notepad++. Но в графическом дизайнере хотелось бы большей поддержки для js.
За рамками исследованного
Остались некотрые вещи, которые я просто увидел в документации, но не смог потрогать вживую.
Во-первых, интеграция с различными системами доставки сообщений. Вроде бы есть встроенная интеграция с Java Message Service, но только в платной enterprise-версии. Есть некие плагины для интеграции с Apache Kafka, но как это все использовать - надо разбираться.
Во-вторых, как обеспечивается гарантированная обработка данных в случае технической аварии на исполняющем хосте. Попросту, можно ли возобновить трансформацию, если произошел фатальный сбой на промежуточном шаге (oom к примеру).
Краткое описание Kettle (дизайнер трансформаций и заданий): http://wiki.pentaho.com/display/EAI/Pentaho+Data+Integration+(Kettle)+Tutorial
Что это такое
Потратил 2 дня на знакомство с этой замечательной системой обработки данных, точнее с той ее частью, которая отвечает за ETL. ETL - это сокращение от Extract Transform Load, то есть загрузка данных, их преобразование и сохранение в новом формате.
Для человека, имеющего опыт работы и разработки под MS Access, Pentaho Data Integration выглядит именно как Access на стероидах. или на анаболиках - система немного монструозна. Объяснение простое - она написана на Java. Что сразу очерчивает некоторые рамки аппетита к ресурсам. В частности, в виртуалке под vSphere с Windows 2008 с квотой в 2 Гб памяти графический дизайнер грузится неторопливо
и работает достаточно размеренно, хотя явного дискомфорта не вызывает. Разве что отдельные нюансы самого гуя напоминают лишний раз, что это GUI на джаве - явно не нативное поведение окон и контролов. Фильтрация шагов по введенному названию вызывает неспешные перерисовки списка после ввода каждого символа, и для "REST client" можно наблюдать полуминутную мультипликацию с морганием палитры инструментов. Впрочем, мелочи.
Решаемая PDI задача, если отбросить технические нюансы, проста и понятна. Есть разные источники данных, в том числе реляционные СУБД, веб-сервисы, простые текстовые файлы в формате CSV и так далее. Там есть ценные данные, которые нужны бизнесу для планирования тактики и стратегии. Чем больше бизнес, тем больше разнородных данных. Аналитика по этим разнородным источникам сводится к повторению одних и тех же шагов: прочитать (точнее, периодически перечитывать) данные из (1C, csv файла, пришедшего из филиала, из Excel документа из департамента стратегического планирования и т.д.), выделить из них подмножество (берем столбцы дата и стоимость акций MSFT, игнорируем остальное), соединяем с выдачей веб-сервиса, который анализирует сентимент IT-новостей в спектре центральных СМИ, джойним, сохраняем в другом месте - пусть это будет какой-нибудь JSON документ в MongoDB. Потом мы эти данные прогоним через регрессионную machine learning модель (см. Weka http://wiki.pentaho.com/display/EAI/Weka+Forecasting), наконец нарисуем красивый репорт (опять там же https://www.profdata.com/reporting/) с рекомендациями - вставать в длинную и как много. Ну или типа того.
Плюсы
(*) Написано на Java, поэтому кроссплатформенно, если повезет с JRE, конечно. У меня со второго захода получилось установить нужную оракловую JRE и стартовать Kettle.
(*) Для софтверной компании, разрабатывающей коробочный продукт для enterprise сегмента, Pentaho DI однозначно суперская вещь с точки зрения маркетинга. На некоторых частях документации концентрация баззводов и наименований модных решений соперничает
с английскими артиклями. К примеру, раздел по Master DataManegement (http://wiki.pentaho.com/display/EAI/Master+Data+Management-Concepts)
перечисляет все основные приемы - Data Quality, Data Cleansing, Validation, Harmonization, Standardization, Data Consolidation (Deduplication, Enrichment).
Загрузить данные из веб-сервиса? Почти без проблем. Правда, я не смог подцепить свой SOAP веб-сервис, пентаха ругнулась на некое несоответствие формата в xml-оформлении конверта. С REST-сервисом все пошло веслее.
(*) Широчайшая поддержка различных РСУБД в качестве источников данных и вариантов сохранения результатов. По-моему, больше чем в MS Access или SSIS. Интеграция с всевозможными NoSQL базами, есть SAP HANA и вся классика типа Oracle и MS SQL. Даже крошка SQLite присутствует. Я сходу сделал сохранение данных в SQLite и оно заработало без каких либо шероховатостей. Потом небольшая пляска со скачиваем Oracle JDBC драйвера и установкой его в нужном каталоге - удалось прочитать данные из оракловой таблицы. Хотя тут был первый неприятный опыт, так как кириллица в varchar2 полях пришла поломанная. То есть настройка локалей где-то на пути требует заботливых рук ветеринара.
(*) Возможность цеплять SOAP и REST-сервисы.
(*) Графический дизайнер для редактирования трансформаций и заданий - это, конечно, плюс для использования PDI не-разработчиками.
(*) Графические программы (трансформации и заданий) сохраняются в XML формате и могут быть, таким образом, созданы и загружены через rest-api сторонними компонентами.
(*) Интеграция с другими компонентами Pentaho, хотя я их не успел попробовать. Отчеты и анализ данных - это хорошо и всегда полезно в реальных бизнес-задачах.
Минусы
(*) Все написано на Java. Поэтому прожорливо и неповоротливо. Когда стартует Carte (сервис, предоставляющий rest-api для создания/запуска/мониторинга трансформаций и заданий), в логе видно, как он инициализирует кучку всяких приблуд - кэши, вспомогательные библиотеки. Выглядит монструозно.
(*) Немного ненативный GUI. Хотя надо сказать, что эта ненативность гораздо нативнее, чем, к примеру, в PyCharm, который меня своими файловыми диалогами иногда ставит в тупик.
(*) Конфигурирование java-style, через xml-конфиги. Лично мне это всегда доставляет боль, так как неимоверное время тратится, чтобы нагуглить и подобрать, какие параметры в каких конфигах надо выставить в волшебные значения, чтобы все завелось. Например, правильный конфиг
для Carte, чтобы сервис увидел репозиторий с готовыми трансформациями, у меня получилось сделать не сразу, а через пару часов гугления и экспериментов.
(*) Это графический язык программирования со всеми вытекающими. Чтобы понять, какой визуальный кирпичик надо подпихнуть и как его настроить для выполнения элементарного действия, приходится гуглить, зырить видюшки на ютубе, в общем чуствовать себя полным буратиной. Возможно, по мере набора компетенции этот фактор станет меньше, но по началу просто часы уходят на то, что в питоне делается за 10 минут. Спустя день мне удалось выстроить трансформацию, в которой данные загружаются из моего rest-сервиса в json-формате, немного модифицируются, затем запихиваются в другой rest-сервис.
(*) Документация (вики) крайне скудна. Местами это просто скриншоты диалоговых окошек с перечислением подписей к контролам, то есть абсолютно бесполезная штука.
(*) В документации говорится, что можно использовать Python для написания специальных трансформаций. У меня не получилось даже понять, как это сделать. Никаких следов переключения с JavaScript на другие ЯП в кирпичике SCRIPT найти не удалось. Нашел некий плагин, который должен добавить поддержку Jython. Скачал его с гитхаба, запустил сборку в java-системе сборки, после 10 минут скачивания зависимостей и сборки эта редиска ругнулась "Fatal error in java compiler" и все. Представив, как этот процесс делать у клиентов удаленно с ограниченным доступом в инет, я решил что это плохой путь.
(*) Редактор js-скриптов в трансформациях мягко говоря убог. Нет, конечно я могу писать без поддержки IDE, и иногда редактирую программы на питоне просто в Notepad++. Но в графическом дизайнере хотелось бы большей поддержки для js.
За рамками исследованного
Остались некотрые вещи, которые я просто увидел в документации, но не смог потрогать вживую.
Во-первых, интеграция с различными системами доставки сообщений. Вроде бы есть встроенная интеграция с Java Message Service, но только в платной enterprise-версии. Есть некие плагины для интеграции с Apache Kafka, но как это все использовать - надо разбираться.
Во-вторых, как обеспечивается гарантированная обработка данных в случае технической аварии на исполняющем хосте. Попросту, можно ли возобновить трансформацию, если произошел фатальный сбой на промежуточном шаге (oom к примеру).