для чего нужен репозиторий метаданных etl сервера
2) Informatica Architecture
Инструмент Informatica ETL состоит из следующих сервисов и компонентов
В этом уроке вы узнаете
Домен Informatica
Общая архитектура Informatica — это сервис-ориентированная архитектура (SOA).
Например, на приведенном ниже снимке экрана вы можете увидеть под окном домена папку «Domain_Rajesh», в которой мы создали имя узла «node01_rajesh» и сервисы как «сервисы интеграции guru99».
Узел является логическим представлением машины внутри домена. Узел требуется для запуска служб и процессов для Informatica.
Вы можете иметь несколько узлов в домене. В домене вы также найдете узел шлюза.
Узел шлюза отвечает за получение запросов от различных клиентских инструментов и маршрутизацию этих запросов к различным узлам и службам.
В Домене есть два типа услуг
PowerCenter Repository
Хранилище PowerCenter является реляционной базой данных, такой как Oracle, Sybase, SQL- сервер, и управляется службой хранилища. Он состоит из таблиц базы данных, в которых хранятся метаданные.
В Informatica Powercenter доступны три клиентских инструмента Informatica. Они информатики
Эти клиенты могут получить доступ к хранилищу только через службу хранилища.
Для управления репозиторием существует служба Informatica, которая называется Repository Service. Один сервис репозитория обрабатывает только один репозиторий. Кроме того, служба репозитория может выполняться на нескольких узлах для повышения производительности.
Службы репозитория используют блокировки для объектов, поэтому несколько пользователей не могут изменять один и тот же объект одновременно.
Вы можете включить контроль версий в репозитории. С помощью функции контроля версий вы можете поддерживать разные версии одного и того же объекта.
Объекты, созданные в хранилище, могут иметь следующие три состояния
Конфигурация домена
Как упоминалось ранее, домен является основным административным контролем в Informatica. Это родительский объект, который состоит из других сервисов, таких как сервис интеграции, сервис репозитория и различные узлы.
Конфигурирование домена может быть выполнено с помощью консоли администратора Informatica. Консоль можно запустить с помощью веб-браузера.
После открытия в веб-браузере он запрашивает учетную запись администратора. Пароль устанавливается во время установки Informatica.
После входа в домен Informatica домашняя страница выглядит примерно так.
На левой панели отображаются существующие узлы, службы репозитория, службы интеграции в домене.
В главном окне отображается состояние этих служб, независимо от того, включены они или нет.
Свойства домена
Нажмите на меню свойств на странице администратора, чтобы просмотреть свойства домена.
Ключевые свойства домена
Тайм-аут устойчивости — Если какой-либо из сервисов интеграции или сервисов репозитория выходит из строя, то тайм-аут устойчивости — это количество секунд, в течение которого сервис приложений пытается подключиться к этим сервисам.
Период перезапуска — это максимальное количество секунд, которое домен тратит на перезапуск службы.
Режим отправки — это политика, используемая балансировщиком нагрузки для отправки задач различным узлам.
Тип базы данных — тип базы данных, на которой настроен домен.
Хост базы данных — имя хоста компьютера, на котором настроен домен.
Порт и имя базы данных — это порт базы данных и имя экземпляра базы данных для домена.
Эти свойства могут быть изменены в зависимости от требований.
Клиент Powercenter и подключение к серверу
Инструменты клиента PowerCenter — это инструменты разработки, которые устанавливаются на клиентские машины. Дизайнер Powercenter, менеджер рабочего процесса, менеджер хранилища и монитор рабочего процесса являются основными инструментами клиента.
Отображения и объекты, которые мы создаем в этих клиентских инструментах, сохраняются в репозитории Informatica, который находится на сервере Informatica. Поэтому клиентские инструменты должны иметь сетевое подключение к серверу.
С другой стороны, клиент PowerCenter подключается к источникам и целям для импорта метаданных и определений структуры источника / цели. Таким образом, он также должен иметь подключение к исходным / целевым системам.
Репозиторий Сервис
Служба хранилища поддерживает подключения клиентов Powercenter к хранилищу PowerCenter. Это отдельный многопоточный процесс, который извлекает, вставляет и обновляет метаданные внутри хранилища. Он также отвечает за поддержание согласованности внутри метаданных репозитория.
Служба интеграции
Служба интеграции — это движок для Informatica, другими словами, это объект, который выполняет задачи, которые мы создаем в Informatica. Вот как это работает
Например, он может объединять данные из таблицы оракула и источника плоских файлов.
Итак, в общем, сервис интеграции Informatica — это процесс, находящийся на сервере Informatica, ожидающий назначения задач для выполнения. Когда мы выполняем рабочий процесс, сервис интеграции получает уведомление о выполнении рабочего процесса. Затем сервис интеграции считывает рабочий процесс, чтобы узнать детали, например, какие задачи он должен выполнять, как сопоставления, и в какие моменты времени. Затем служба считывает детали задачи из хранилища и приступает к выполнению.
Источники и цели
Informatica, являясь инструментом интеграции ETL и данных, вы всегда будете обрабатывать и преобразовывать некоторые формы данных. Вклад в наши отображения в Informatica называется исходной системой. Мы импортируем определения источника из источника и затем подключаемся к нему для извлечения данных источника в наших отображениях. Там могут быть разные типы источников и могут быть расположены в нескольких местах. В зависимости от ваших требований целевой системой может быть реляционная или плоская файловая система. Целевые плоские файлы создаются на компьютере-сервере Informatica, который может быть передан позже с помощью ftp.
Реляционные — эти типы источников являются системными таблицами базы данных. Эти системы баз данных обычно принадлежат другим приложениям, которые создают и поддерживают эти данные. Это может быть база данных управления взаимоотношениями с клиентами, база данных человеческих ресурсов и т. Д. Для использования таких источников в Informatica мы либо получим копию этих наборов данных, либо получим привилегии выбора в этих системах.
Плоские файлы. Плоские файлы являются наиболее распространенными источниками данных после реляционных баз данных в Informatica. Плоский файл может быть файлом, разделенным запятыми, файлом с разделителями табуляции или файлом фиксированной ширины. Informatica поддерживает любые кодовые страницы, такие как ascii или Unicode. Чтобы использовать плоский файл в Informatica, его определения должны быть импортированы аналогично тому, как мы это делаем для реляционных таблиц.
Администрирование Informatica PowerCenter в деталях, часть первая
Посвящается моему коллеге и наставнику по Informatica Максиму Генцелю, который умер от COVID-19 21.01.2021
Привет! Меня зовут Баранов Владимир, и я уже несколько лет администрирую Informatica в «Альфа-Банк». В статье я поделюсь опытом работы с Informatica PowerCenter. IPC это платформа, которая занимается ETL (Extract, Transformation, Loading). Я сосредоточусь на описании конкретных кейсов и решений, расскажу о некоторых тонкостях и постараюсь дать пищу для ума.
В работе приходится часто сталкиваться с проблемами производительности и стабильности платформы, при этом глубоко во всё вникая, поэтому лично я при работе с Informatica получаю огромное удовольствие. Во-первых, потому, что даже IPC сам по себе не такой уж маленький, а у Informatica целое семейство продуктов. Во-вторых, ETL находится на стыке разных систем, надо знать всего понемногу – базы данных, коннекторы, линукс, скриптовые языки и системы визуализации и мониторинга. В-третьих, это общение с большим количеством разных людей и много интересных задач.
Запуск клиента информатики
Забавно, но даже тут можно наступить на некоторые грабли. Да, прямо на старте и с размахом.
У информатики есть следующие клиенты: Workflow Manager, Workflow Monitor, Repository Manager, Designer и Developer Client. Параметры подключения к репозиториям хранятся в файле domains.infa, который обычно задаётся переменной окружения:
Но если версий информатики несколько, то файл рано или поздно будет «побит», а клиент информатики будет ругаться при попытке сохранения добавленного репозитория.
Что делать? Создать батники для каждой версии клиента вида:
SET INFA_DOMAINS_FILE=C:\Informatica\9.5.1\clients\PowerCenterClient\domains.infa
cd C:\Informatica\9.5.1\clients\PowerCenterClient\client\bin\
start pmdesign.exe
Последние две строчки попортили мне очень много крови, так как изначально я запускал клиента так:
И батник прекрасно работал ровно до того момента, пока я не обновился с 9.5.1 до 10.1.1 и не начал пытаться подключаться через клиент информатики к SAP.
Disigner должен был показывать коннекты из файла sapnwrfc.ini, но показывалась пустота, хотя файл лежал в нужном каталоге клиента IPC. Я даже успел немного посидеть с отладчиком над клиентом, но в итоге мне помогла индианка из службы поддержки.
Что ещё можно сказать о файле domains.infa и создании подключений? Вы не сможете единовременно добавить два репозитория с одинаковым именем, даже если они находятся на разных серверах.
Файл domains.infa также используется при использовании консольных команд для подключения к репозиторию* (pmrep), имейте это в виду. Но об этом чуть позже.
*На самом деле не обязательно, смотрите на описание ключей команды.
Настраиваем окружение
stack size 10240
open files (-n) 500000
Сколько ставить open files? Поддержка Informatica как-то утверждала, что у нас одна из самых высоконагруженных и сложных инсталляций в России – при этом нам хватает 500к open files, с запасом примерно в 150-250к.
На многих серверах стоит по 120-180к, и этого хватает. Со временем (и в случае нашего банка это происходит очень быстро) приходится увеличивать.
Однажды видел, как ведёт себя Oracle, если ему не хватает максимально открытых файлов. Он периодически начинает ощутимо тормозить, клиенты от него отваливаются. Но при этом он оставался работать и не падал.
Если вы не знаете, какое текущее значение у уже запущенного процесса:
cat /proc/pid/limits
max user processes (-u) 4134885
Важный параметр, но ничего особенно интересного про него рассказать не могу.
Имеет смысл следить за этим каталогом и аккуратно его чистить.
Теперь не такое очевидное:
/etc/systemd/system.conf, /etc/systemd/user.conf
DefaultTasksMax=40000
DefaultLimitNOFILE=500000
To control the default TasksMax= setting for services and scopes running on the system, use the system.conf setting DefaultTasksMax=. This setting defaults to 512, which means services that are not explicitly configured otherwise will only be able to create 512 processes or threads at maximum.
For thread- or process-heavy services, you may need to set a higher TasksMax value. In such cases, set TasksMax directly in the specific unit files. Either choose a numeric value or even infinity.
Similarly, you can limit the total number of processes or tasks each user can own concurrently. To do so, use the logind.conf setting UserTasksMax (the default is 12288).
Как можно посмотреть текущее значение:
Если интересно, что это такое — гуглить «linux cgroup slices»:
Что будет в системных логах, если TaskMax недостаточен:
2020-01-01T03:23:30.674392+03:00 serv kernel: [5145583.466931] cgroup: fork rejected by pids controller in /user.slice/user-*.slice/session-2247619.scope
/etc/sysctl.conf
fs.file-max = 6815744
Тут тоже особо не заостряю внимания.
Сеть, sysctl, net.core, net.iipv4
Кейсы по архитектурным ошибкам
Всё, что я напишу ниже, следует читать осторожно, сознавая что обычный разработчик, который работает с Informatica каждый день, может обладать куда большей экспертизой, чем я.
1. GRID
Информатика может иметь все сервисы на одной машине, а может существовать в виде кластера и балансировать нагрузку между нодами. Даже если вы в ближайшем будущем не планируете использовать кластер, всё же крайне желательно, чтобы разработка велась так, как будто это может произойти в будущем. Вертикальная масштабируемость конечна, сидеть на ней без возможности в любой момент переключиться на горизонтальную — это как сидеть на пороховой бочке.
Я не имел личного опыта работы с гридом, но много людей отзывались о нём негативно. Грид определённо не только решает проблемы, но и добавляет новые. Тем не менее, я знаю организации, у которых всё работает именно на гриде. Надеюсь, у меня будет возможность познакомиться с ним поближе и набить уже своих шишек.
Очень наглядный гайд по созданию грида видел у nutanix.
2. Pushdown
К разработке может быть несколько подходов:
Ведь как правило незачем тягать данные на сервер информатики и нагружать его, если source & target находятся в пределах одной БД — лучше сделать процедуру.
На Хабре выходила отличная статья от DIS, где они рассказывали про pushdown на русском, рекомендую к прочтению.
3. Информатика как шедулер
Большинство компаний используют информатику в качестве эдакого шедулера для запуска потоков и не перекладывают на неё вычисления, если это можно сделать на стороне БД. И во всех организациях присутствует дополнительная сущность в виде базы данных, которая используется в качестве управляющего механизма. Это очень удобно для выстраивания логики работы потоков и параметров их запуска (нам же нужно знать, например, какие даты мы уже успешно загрузили, успешно ли отработали потоки и т.д).
В итоге в информатике выстраивается сложная схема, когда один поток запускает десятки других потоков, в это время второй поток дожидается выполнения третьего и пятого потока, а многие-многие сессии запускают sh-файлы, которые взаимодействуют с управляющим механизмом. В некоторых потоках может быть и 1500+ запусков sh-файлов (и до 200-300 запусков одновременно).
Как минимум поэтому сервер БД метаданных информатики и сервер БД управляющего механизма не должны быть в опасной близости друг от друга. И конечно, бест практик не размещать сервер БД, хранящий метаданные информатики, на одной площадке*.
*На самом деле, не так уж это и критично. Но по возможности лучше этого избегать. Я видел примеры с высоконагруженными серверами информатики, где сервера БД были на этом же хосте.
4. «Оптимизация» как угроза
Если какой-нибудь поток выйдет за рамки SLA то у разработчиков и саппорта после доработки хинтами может быть большой соблазн увеличить количество параллелей, т.к это путь наименьшего сопротивления. Пересмотром запросов или архитектуры займутся в последнюю очередь, как наиболее трудозатратное. Возможно стоит мониторить как меняются параллели у потоков.
5. Параметризация
При разработке желательно подумать о том, что вот прямо завтра сервер может переехать на другой хост или в другой каталог. У потока также может сменится репозиторий или интеграционный сервис (с дева на тест, с теста на прод, например). Смену каталога тоже принято делать при обновлении IPC.
Может так сложиться, что вы решите перенести сервис на хост, где будет несколько инстансов информатики.
Посмотрим, нет ли у нас абсолютных путей до информатики в метаданных репозитория:
Предостережение: Даже селекты из метаданных информатики могут быть опасны и у поддержки IPC есть кейсы когда это реально вредило стабильности IPC. Разрешено использовать только view, список которых есть в Repository Guide.
В некоторых запущенных случаях можно обнаружить комбо:
В данном случае поток запускали под пользовательской учёткой, с указанием пароля и инт.сервис+домен не был параметризирован.
С sh-файлами необходимо придерживаться тех же самых правил. Конфиги должны быть отдельно от скриптов, абсолютных путей быть не должно, только относительные. Недопустимо указание инт.сервиса, хостов и других явно зашитых параметров в sh-скрипте.
6. Репозитории, интеграционные сервисы, файловая система и лукапы
Репозитории достаточно просто переносятся с сервера на сервер, я расскажу подробнее в главе «Работа в консоли, девопс». На самом деле сущность репозитория вообще не имеет отражения на уровне файловой системы — репозиторий находится в БД-слое.
А вот интеграционные сервисы, которые привязываются к репозиторию, требуют инфраструктуры каталогов:
По возможности лучше разделять проекты в разные репозитории, чтобы было проще их переносить, масштабировать, актуализировать и понимать, сколько ресурсов они потребляют.
Я бы с самого начала посоветовал сделать как минимум два подкаталога с лукап кэшами. В первом каталоге можно хранить кэши временные, во втором – постоянные (persistent) кэши (не путать с именованными). И ещё, информатика обладает неприятным поведением при падениях – она не чистит за собой старые лукапы.
В «Альфа-Банке», например, раньше часть больших кэшей лежала на медленных дисках, а остальные на быстрых. Кэши в разных каталогах это довольно удобно — в любой момент можно перекинуть часть кэшей на другой массив, оставив симлинк. Это проще, чем когда все кэши находятся в одном месте.
Также хочу обратить внимание, что в случае, когда у персистент-лукапов добавляются или меняются поля – эти лукапы будут полностью перестраиваться, создавая в каталоге свою полную копию (*.bak). Это может сыграть злую шутку, если лукап весит 300-500 гб. В целом, грамотное использование лукапа значительно увеличивает производительность.
Обратите внимание на именование лукапов, которые создаёт информатика на уровне ФС:
ls PMLKUP629*
PMLKUP629_21_0_247034L64.dat0
PMLKUP629_21_0_247034L64.dat1
PMLKUP629_21_0_247034L64.idx0
PMLKUP629_21_0_247034L64.idx1
В начале названия файлов идёт префикс (PMLKUP), который означает, что это лукап-кэш. Помимо лукапов в CacheDir создаются джойнеры, сортировка, агрегатор и rank transformation.
Насколько я помню, после префикса идёт session_id — и это даёт возможность получить сессию, которая с ним работает в данный момент.
Определяем, кто работает с файлом кэша (возьму любой из занятых).
Отформатирую и порежу вывод, чтобы остановить ваше внимание на самых важных вещах, которые мы можем увидеть, посмотрев pmdtm-процесс.
Смотрим, какие файлы занял процесс:
И раз уж я начал рассказывать про pmdtm — не могу не поделится крутым параметром для отладки, которые задаётся в Custom-параметрах интеграционного сервера.
Чтобы ещё больше не увеличивать эту статью, просто дам ссылку.
7. Система версионности в информатике
По кейсам в базе знаний сложилось стойкое впечатление, что с ней лучше дел не иметь.
8. Логи сессий и потоков
Подробнее о логах мы говорим позже, но хочется обозначить следующее. Будьте готовы, что в большой инсталляции логи будут занимать десятки гигабайт, и количество логов сессий свободно может перевалить за 1-2 млн в зависимости от выбранной вами стратегии log-rotate.
Я не могу с уверенностью сказать, что большое количество файлов на xfs в одном каталоге влияет на производительность их загрузки, копирования или удаления в случае прямого обращения к ним, без масок. Подозреваю, что на удаление должно уходить больше времени.
При большом количестве файлов с ls могут быть проблемы (Argument list too long), но всегда есть find и exec rm, который работает значительно надёжнее, чем ls.
Хотя и к find есть вопросы по использованию памяти — не могу не порекомендовать замечательную и глубокую статью seriyPS.
Поэтому, если вы хотите обеспечить более удобный доступ к логам, лучше хранить их в разных каталогах. Как вариант — создать каталоги по имени папок в репозитории.
Логи сессий и потоков необходимо периодически чистить.
Внимание вопрос: какая опция наиболее опасна?
В следующей части поговорим о запуске сервера, развернем репозиторий с интеграционным сервисом, изучим немного полезных консольных команд, обсудим бэкапы и узнаем, где лежат логи и как искать ошибки.
Что такое ETL: как справиться с анализом big data
Крупные предприятия собирают, хранят и обрабатывают разные типы данных из множества источников, таких как системы начисления заработной платы, записи о продажах, системы инвентаризации и других. Эта информация извлекается, преобразуется и переносится в хранилища данных с помощью ETL-систем. Расскажем, что такое ETL, а также какие платные и общедоступные решения для работы с данными есть на рынке.
ETL — что это такое и зачем?
В переводе ETL (Extract, Transform, Load) — извлечение, преобразование и загрузка. То есть процесс, с помощью которого данные из нескольких систем объединяют в единое хранилище данных.
Представьте ритейлера с розничными и интернет-магазинами. Ему нужно анализировать тенденции продаж и онлайн, и офлайн. Но бэкэнд-системы для них, скорее всего, будут отдельными. Они могут иметь разные поля или форматы полей для сбора данных, использовать системы, которые не могут «общаться» друг с другом.
И вот тогда наступает момент для ETL.
ETL-система извлекает данные из обеих систем, преобразует их в соответствии с требованиями к формату хранилища данных, а затем загружает в это хранилище.
ETL — что это на практике, а не на примере?
Современные инструменты ETL собирают, преобразуют и хранят данные из миллионов транзакций в самых разных источниках данных и потоках. Эта возможность предоставляет множество новых возможностей: анализ исторических записей для оптимизации процесса продаж, корректировка цен и запасов в реальном времени, использование машинного обучения и искусственного интеллекта для создания прогнозных моделей, разработка новых потоков доходов, переход в облако и многое другое.
Облачная миграция. Процесс переноса данных и приложений в облако называют облачной миграцией. Она помогает сэкономить деньги, сделать приложения более масштабируемыми и защитить данные. ETL в таком случае используют для перемещения данных в облако.
Хранилище данных. Хранилище данных — база данных, куда передают данные из различных источников, чтобы их можно было совместно анализировать в коммерческих целях. Здесь ETL используют для перемещения данных в хранилище данных.
Машинное обучение. Машинное обучение — метод анализа данных, который автоматизирует построение аналитических моделей. ETL может использоваться для перемещения данных в одно хранилище для машинного обучения.
Интеграция маркетинговых данных. Маркетинговая интеграция включает в себя перемещение всех маркетинговых данных — о клиентах, продажах, из социальных сетей и веб-аналитики — в одно место, чтобы вы могли проанализировать их. ETL используют для объединения маркетинговых данных.
Интеграция данных IoT. То есть данных, собранных различными датчиками, в том числе встроенными в оборудование. ETL помогает перенести данные от разных IoT в одно место, чтобы вы могли сделать их подробный анализ.
Репликация базы данных — данные из исходных баз данных копируют в облачное хранилище. Это может быть одноразовая операция или постоянный процесс, когда ваши данные обновляются в облаке сразу же после обновления в исходной базе. ETL можно использовать для осуществления процесса репликации данных.
Бизнес-аналитика. Бизнес-аналитика — процесс анализа данных, позволяющий руководителям, менеджерам и другим заинтересованным сторонам принимать обоснованные бизнес-решения. ETL можно использовать для переноса нужных данных в одно место, чтобы их можно было использовать.
Популярные ETL-системы: обзор, но коротко
Cloud Big Data — PaaS-сервис для анализа больших данных (big data) на базе Apache Hadoop, Apache Spark, ClickHouse. Легко масштабируется, позволяет заменить дорогую и неэффективную локальную инфраструктуру обработки данных на мощную облачную инфраструктуру. Помогает обрабатывать структурированные и неструктурированные данные из разных источников, в том числе в режиме реального времени. Развернуть кластер интеграции и обработки данных в облаках можно за несколько минут, управление осуществляется через веб-интерфейс, командную строку или API.
IBM InfoSphere — инструмент ETL, часть пакета решений IBM Information Platforms и IBM InfoSphere. Доступен в различных версиях (Server Edition, Enterprise Edition и MVS Edition). Помогает в очистке, мониторинге, преобразовании и доставке данных, среди преимуществ: масштабируемость, возможность интеграции почти всех типов данных в режиме реального времени.
PowerCenter — набор продуктов ETL, включающий клиентские инструменты PowerCenter, сервер и репозиторий. Данные хранятся в хранилище, где к ним получают доступ клиентские инструменты и сервер. Инструмент обеспечивает поддержку всего жизненного цикла интеграции данных: от запуска первого проекта до успешного развертывания критически важных корпоративных приложений.
iWay Software предоставляет возможность интеграции приложений и данных для удобного использования в режиме реального времени. Клиенты используют их для управления структурированной и неструктурированной информацией. В комплект входят: iWay DataMigrator, iWay Service Manager и iWay Universal Adapter Framework.
Microsoft SQL Server — платформа управления реляционными базами данных и создания высокопроизводительных решений интеграции данных, включающая пакеты ETL для хранилищ данных.
OpenText — платформа интеграции, позволяющая извлекать, улучшать, преобразовывать, интегрировать и переносить данные и контент из одного или нескольких хранилищ в любое новое место назначения. Позволяет работать со структурированными и неструктурированными данными, локальными и облачными хранилищами.
Oracle GoldenGate — комплексный программный пакет для интеграции и репликации данных в режиме реального времени в разнородных IT-средах. Обладает упрощенной настройкой и управлением, поддерживает облачные среды.
Pervasive Data Integrator — программное решение для интеграции между корпоративными данными, сторонними приложениями и пользовательским программным обеспечением. Data Integrator поддерживает сценарии интеграции в реальном времени.
Pitney Bowes предлагает большой набор инструментов и решений, нацеленных на интеграцию данных. Например, Sagent Data Flow — гибкий механизм интеграции, который собирает данные из разнородных источников и предоставляет полный набор инструментов преобразования данных для повышения их коммерческой ценности.
SAP Business Objects — централизованная платформа для интеграции данных, качества данных, профилирования данных, обработки данных и отчетности. Предлагает бизнес-аналитику в реальном времени, приложения для визуализации и аналитики, интеграцию с офисными приложениями.
Sybase включает Sybase ETL Development и Sybase ETL Server. Sybase ETL Development — инструмент с графическим интерфейсом для создания и проектирования проектов и заданий по преобразованию данных. Sybase ETL Server — масштабируемый механизм, который подключается к источникам данных, извлекает и загружает данные в хранилища.
Open source ETL-средства
Большинство инструментов ETL с открытым исходным кодом помогают в управлении пакетной обработкой данных и автоматизации потоковой передачи информации из одной системы данных в другую. Эти рабочие процессы важны при создании хранилища данных для машинного обучения.
Некоторые из бесплатных и открытых инструментов ETL принадлежат поставщикам, которые в итоге хотят продать корпоративный продукт, другие обслуживаются и управляются сообществом разработчиков, стремящихся демократизировать процесс.
Open source ETL-инструменты интеграции данных:
Apache Airflow — платформа с удобным веб-интерфейсом, где можно создавать, планировать и отслеживать рабочие процессы. Позволяет пользователям объединять задачи, которые нужно выполнить в строго определенной последовательности по заданному расписанию. Пользовательский интерфейс поддерживает визуализацию рабочих процессов, что помогает отслеживать прогресс и видеть возникающие проблемы.
Apache Kafka — распределенная потоковая платформа, которая позволяет пользователям публиковать и подписываться на потоки записей, хранить потоки записей и обрабатывать их по мере появления. Kafka используют для создания конвейеров данных в реальном времени. Он работает как кластер на одном или нескольких серверах, отказоустойчив и масштабируем.
Apache NiFi — распределенная система для быстрой параллельной загрузки и обработки данных с большим числом плагинов для источников и преобразований, широкими возможностями работы с данными. Пользовательский веб-интерфейс NiFi позволяет переключаться между дизайном, управлением, обратной связью и мониторингом.
CloverETL (теперь CloverDX) был одним из первых инструментов ETL с открытым исходным кодом. Инфраструктура интеграции данных, основанная на Java, разработана для преобразования, отображения и манипулирования данными в различных форматах. CloverETL может использоваться автономно или встраиваться и подключаться к другим инструментам: RDBMS, JMS, SOAP, LDAP, S3, HTTP, FTP, ZIP и TAR. Хотя продукт больше не предлагается поставщиком, его можно безопасно загрузить с помощью SourceForge. CloverDX по-прежнему поддерживает CloverETL в соответствии со стандартным соглашением о поддержке.
Jaspersoft ETL — один из продуктов с открытым исходным кодом TIBCO Community Edition, позволяет пользователям извлекать данные из различных источников, преобразовывать их на основе определенных бизнес-правил и загружать в централизованное хранилище данных для отчетности и аналитики. Механизм интеграции данных инструмента основан на Talend. Community Edition прост в развертывании, позволяет создавать витрины данных для отчетности и аналитики.
Apatar — кроссплатформенный инструмент интеграции данных с открытым исходным кодом, который обеспечивает подключение к различным базам данных, приложениям, протоколам, файлам. Позволяет разработчикам, администраторам баз данных и бизнес-пользователям интегрировать информацию разного формата из различных источников данных. У инструмента интуитивно понятный пользовательский интерфейс, который не требует кодирования для настройки заданий интеграции данных. Инструмент поставляется с предварительно созданным набором инструментов интеграции и позволяет пользователям повторно использовать ранее созданные схемы сопоставления.
Итак, почему стоит отказаться от локальных ETL-решений?
Традиционные локальные ETL чаще всего поставляются в комплекте с головной болью. Например, создаются собственными силами, поэтому могут быстро устареть или не иметь сложных функций и возможностей. Они дороги и требуют времени на обслуживание, а также поддерживают только пакетную обработку данных и плохо масштабируются.
Локальные платформы ETL были важнейшим компонентом инфраструктуры предприятий на протяжении десятилетий. С появлением облачных технологий, SaaS и больших данных выросло число источников информации, что вызвало рост спроса на более мощную и сложную интеграцию данных.