Совершенно верно, но мы хотели получить независимость от формата файлов в HDFS и стабильность работы (с TEXT и CSV gphdfs уже работает давно и это было нами проверено, а с AVRO и PARQUET относительно недавно). У нас местами используется/использовался ORC. По этому мы осмысленно пошли на выделение отдельного шага и сделали work (или stage) область на стороне HDFS, куда так же можем выгружать с использованием параметров, например, организовать инкремент.
Спасибо, за вопрос. Мы живем в парадигме ELT. DataStage от IBM хороший продукт, но в первую очередь он хороший ETL инструмент, т.е. когда все вычисления выполняются на ETL сервере или на кластере ETL серверов, т.е. нужно иметь дорогую инфраструктуру ETL. У нас же все данные хранятся и обрабатываются на кластере серверов БД (Greenplum), а SAS DI этим всем управляет. Плюс нам SAS DI обладает большими возможностями для собственной разработки, благодаря которой можно разработать вот такие вот трансформации, которые очень упрощают ETL|ELT разработку в целом.
Обсудил с вендером и вот что получилось:
1. Informatica MM позволяет обрабатывать простые PL/SQL код, указывая список используемых таблиц. Для сложных обработок всегда можно расширить функционал написав XConnect и свой парсер или использовав сторонние продукты, позволяющие распарсить код, например MANTA CHECKER, ну в том числе и ODA Oracle Dependencies Analyzer.
2. Lineage показывает зависимость полей и алгоритмы используемые при расчете значений. Этого вполне достаточно, чтобы понять является ли это поле входным Source, выходным Source или используется в Lookup. В любом случае, если есть необходимость сформировать отчет по метаданным, то для этого есть Reporting Service, входящий в поставку MM, который читает данные из репозитория. В рамках текущей задачи важно было получить информацию в графическом виде.
3. ODA Oracle Dependencies Analyzer не плохое решение, но не покрывает большинство систем, которые были интересны в текущем кейсе — Hadoop, Cloudera, Informatica 9.6 BDE. Суть в том, чтобы с одной стороны использовать решение поддерживаемое вендором и по части систем использовать уже готовые модели, настройка которых занимает 15 минут и с другой стороны иметь возможность адаптировать решение под свои нужды, опять таки без особых ресурсных затрат.
Ну смотрите. Например у вас система построена на Oracle. У вас куча таблиц, представлений и хранимой логики. У вас стоит Informatica Metadata Manager и в нем есть metadata exchange for Oracle. То, для того что-бы настроить процесс выгрузки/загрузки метаданных у вас займет 15-20 минут и linage этот прибор сможет построить сам. А вот если у вас более сложная инфраструктура, то тут ручками надо будет поработать. Но поработать рачками здесь не заключается в том, что бы прописывать все зависимости метаданных между собой, а в том что бы описать модель метаданных и написать некий код наполнения этой модели метаданными.
Спасибо за комментарий. Согласен с вами, но эта статья в большей части специализирована на конкретную область — интеграция данных. И в этой области все эти аббревиатуры, как правило, на слуху.
А так, да:
Полной модели чего? У нас сейчас построено четыре модели и они связаны между собой. Больше всего времени было потрачено на разработку модели SAS, т.к. сложная система метаданных. А так в среднем на одну модель уходит 2-3 недели. Это разобраться в метаданных истоника, спроектировать модель, ещё раз разобраться в метаданных источника, запрограммировать обновление метаданных, поставить на регламент. Ну или купить metadata exchange настроить регламент, связку с другими моделями. Одномоментно у нас Metadata Mamager занимался один человек. До текущего состояния внедрения мы дошли где то за 2,5-3 месяца.
Спасибо за комментарий. Аналоги если честно толком не трогали и не тестировали, толки читали. Есть аналоги у IBM и Oracle. По нашему мнению у Oracle ещё сыроватый продукт, а IBM не рассматривали т.к. у нас примерно год назад была закупка Informatica и Informatica Metadata Manager входит в Advanced Edition. Плюс дополнительно можно докупать metadata exchange к различным системам.
по причине низкой стоимости за Гб или были другие причины?
и это тоже. Где как не в Hadoop предлагаете хранить гигантские объемы неструктурированных данных?
А почему выбрали Greenplum, а не Vertica, Netezza?
на тот момент когда выбирали Netezza была морально устаревшей, а Vertica сыроватой. Выбирали бы сейчас, с большой долей вероятности выбрали бы Vertica.
называется AsterData
все эти сборки хадупов от больших вендоров (PivotalHD, IBM Biginsights, AsterData...) развиваются медленней. Нам интересен Spark по этому Cloudera. Хотя вот у PivotalHD есть замечательный HAWQ, который по производительности работы запросов показывает себя очень и очень хорошо…
Да, все верно, можно какие-нибудь агрегаты/витрины поднимать в Greenplum.
Это как бы маленькая Терадата
спорное утверждение, когда GreenPlum кластер из 16 серверов :)
Вопрос стоимости хранения гигабайтов очень важный! skullodrom Oracle и Teradata под одну гребенку не нужно. Здесь скорей всего по стоимости хранения будет следующий порядок, по убыванию:
Oracle
MPP
Hadoop
При этом цены будут различаться примерно в порядок.
Я бы сказал иначе — в мире BigData все течет, все изменяется :) Технологии развиваются, становятся более стабильными, BigData медленно но верно движется в сегмент Enterprise.
на сколько PowerCenter подходит для ваших данных и ETL
PowerCenter не умеет делать PDO на Hadoop.
Hive+Hadoop не тормозной
Hadoop со своей экосистемой развивается и в направлении операционной аналитики, а значит и запросы на Hive и сам Hive становится более производительным. Parquet — это колоночный формат хранения данных в HDFS, с которым также работает Hive. Storm, писал выше, это потоковая обработка данных, нам же нужен был батч процесс. Impala — используем для ad-hoc, PDO на Impala Informatica BDE делать не умеет. Drill не используем.
Да, согласен. Но хочу дополнить, должен быть некий рациональный баланс. Если мы для какой либо задачи, бизнес задачи, поняли, что надо собирать какие то данные, то мы не замарачиваеся на начальном этапе анализом этих данных — начинаем собирать/сохранять все.
Обсудил с вендером и вот что получилось:
1. Informatica MM позволяет обрабатывать простые PL/SQL код, указывая список используемых таблиц. Для сложных обработок всегда можно расширить функционал написав XConnect и свой парсер или использовав сторонние продукты, позволяющие распарсить код, например MANTA CHECKER, ну в том числе и ODA Oracle Dependencies Analyzer.
2. Lineage показывает зависимость полей и алгоритмы используемые при расчете значений. Этого вполне достаточно, чтобы понять является ли это поле входным Source, выходным Source или используется в Lookup. В любом случае, если есть необходимость сформировать отчет по метаданным, то для этого есть Reporting Service, входящий в поставку MM, который читает данные из репозитория. В рамках текущей задачи важно было получить информацию в графическом виде.
3. ODA Oracle Dependencies Analyzer не плохое решение, но не покрывает большинство систем, которые были интересны в текущем кейсе — Hadoop, Cloudera, Informatica 9.6 BDE. Суть в том, чтобы с одной стороны использовать решение поддерживаемое вендором и по части систем использовать уже готовые модели, настройка которых занимает 15 минут и с другой стороны иметь возможность адаптировать решение под свои нужды, опять таки без особых ресурсных затрат.
А так, да:
DWH — Data Warehouse
E
BTL — Extract, Transform, LoadBI — Business intelligence
SAS — SAS
:)
на тот момент когда выбирали Netezza была морально устаревшей, а Vertica сыроватой. Выбирали бы сейчас, с большой долей вероятности выбрали бы Vertica.
все эти сборки хадупов от больших вендоров (PivotalHD, IBM Biginsights, AsterData...) развиваются медленней. Нам интересен Spark по этому Cloudera. Хотя вот у PivotalHD есть замечательный HAWQ, который по производительности работы запросов показывает себя очень и очень хорошо…
спорное утверждение, когда GreenPlum кластер из 16 серверов :)
Вопрос стоимости хранения гигабайтов очень важный! skullodrom Oracle и Teradata под одну гребенку не нужно. Здесь скорей всего по стоимости хранения будет следующий порядок, по убыванию:
При этом цены будут различаться примерно в порядок.
Я бы сказал иначе — в мире BigData все течет, все изменяется :) Технологии развиваются, становятся более стабильными, BigData медленно но верно движется в сегмент Enterprise.
PowerCenter не умеет делать PDO на Hadoop.
Hadoop со своей экосистемой развивается и в направлении операционной аналитики, а значит и запросы на Hive и сам Hive становится более производительным. Parquet — это колоночный формат хранения данных в HDFS, с которым также работает Hive. Storm, писал выше, это потоковая обработка данных, нам же нужен был батч процесс. Impala — используем для ad-hoc, PDO на Impala Informatica BDE делать не умеет. Drill не используем.
Надеюсь ответил на ваши вопросы.
DQ часть Greenplum, в Hadoop пока только проектируем.