Comments 5
Очень круто все выглядит. Немного непонятно, указанные продукты (GUI, генераторы) - ваши внутренние разработки или есть готовые продукты?
Также не совсем понятно, кто является конечным потребителем кода, какой сервис/система выполняет в итоге работу?
Язык SMTL, GUI, фреймворк на Java и генераторы - внутренняя разработка. Spec-to-graph - внешний продукт, который может быть заменён на что-либо другое. Элементарные операции и тест-кейсы к ним разработаны, так что пересесть при необходимости на какую-либо другую платформу - посильная задача.
Что касается потребителя: сгенерированный граф запускается из контрольного механизма shell-скриптом в кластерном режиме на нодах Hadoop, результаты складываются в HDFS и подхватываются ещё одним процессом (loader), которые опять-таки в кластерном режиме складывает данные в Hive.
Спасибо. Сколько лет вам понадобилось для обкатки технологии и окончательного оформления? Не планируете выставить в виде сервиса?
В данный момент тоже задумываемся об автоматизации задач анализа источников и дальнейшей загрузки. У нас сначала аналитик напишет S2t табличку, потом я делаю stage слой и реализую загрузку из источников с помощью NIFI, дальше подключаются разработчики БД - из stage формируют RDV и витрины. Автоматизируем потихоньку, но общего, чтобы от источника и до витрины, пока не создали.
Писали аналогичное на DataStage в 2011 году, там использовали просто зависимости между таблицами и описание этапов. Все в XML. В каждой сущности описывали этапы: mapping, удаление дубликатов, генерацию суррагатных ключей по функции или по полям, загрузку в DWH. Потом даже навернули Xslt поверх этого.
Но все это прошлый век, в спарке это намного круче делается. Учитывая бедный параллелизм у информатики (но богатый у DataStage).
Автогенерация ETL-кода