Комментарии 39
Конечно это все круто, но что вы с этими данными делаете? Какой конечный профит кроме того что все просто работает?
Очень ожидаемый вопрос, спасибо. Основная цель сейчас — на этих данных начать прорабатывать архитектуру и работу нашего озера, накапливать данные, делать Ad-hoc-и на этих данных, строить исследовательские модели в IPython. В дальнейшем будем строить профиль клиента 360, на основе алгоритмов машинного обучения. Также есть в планах построение маркетинговой системы, скорее всего, на технологии Drools.
это все равно не то о чем хотелось бы узнать. Вот вы что, будете рекомендовать что-то пользователям? или будете антифрауд с этим облаком интегрировать? бизнес задача какая стоит?
просто настроить data lake и сказать какие мы молодцы или все таки решить какую то проблему клиентов/бизнеса.
просто настроить data lake и сказать какие мы молодцы или все таки решить какую то проблему клиентов/бизнеса.
А по полученному профилю клиента, читай как сегментацию, нельзя можно будет рекомендовать что-то? Конечно можно. Бизнес задача у нас есть и не одна. Тинькофф Банк это не НИИ, здесь любые начинания в технологиях должны ориентироваться на получение бизнес результата. И да, это не облако, bigdata кластер как и другая инфраструктура банка находится в дата-центре.
Клиент 360 имеется ввиду подход «Customer 360» в традиционном смысле?
Есть ли связка пусть и опосредованная клиент банка (счет) — активность в соц. сети?
Есть ли связка пусть и опосредованная клиент банка (счет) — активность в соц. сети?
Да, речь идет об этом подходе. Конкретно такой связки у нас нет. Есть другие :)
Тогда где Data quality часть? или все на прямом сравнении?
Не понял про «все на прямом сравнении», это про что?
DQ часть Greenplum, в Hadoop пока только проектируем.
DQ часть Greenplum, в Hadoop пока только проектируем.
Для того чтобы понять что вот этот ID с куками и клиент №324 Иванов Иван это одно и то же лицо нужно сравнить реквизиты которые доступны.
А так как качество данных всегда не идеально часть данных отваливается по несовпадению каких то атрибутов.
Или пока главное свести хотя бы 80%? Остальные 20 будем допиливать в процессе?
А так как качество данных всегда не идеально часть данных отваливается по несовпадению каких то атрибутов.
Или пока главное свести хотя бы 80%? Остальные 20 будем допиливать в процессе?
80% — довольно хороший результат, качество данных будем улучшать :)
Так то да.
Для аналитики трендов «третий сорт — не брак», а вот включать в бизнес-процесс и тем более принимать решения на основе 80% довольно смело.
Можно конечно вспомнить про Парето, но проводить аналогию всё более неуместно.
Вы же не будете рады если хирург учтёт только 80% диагноза.
Так и в аналитике. Конечная цель — принятие решения, а конкуренция заставляет сужать дельту недостаточности информации всё больше.
Для аналитики трендов «третий сорт — не брак», а вот включать в бизнес-процесс и тем более принимать решения на основе 80% довольно смело.
Можно конечно вспомнить про Парето, но проводить аналогию всё более неуместно.
Вы же не будете рады если хирург учтёт только 80% диагноза.
Так и в аналитике. Конечная цель — принятие решения, а конкуренция заставляет сужать дельту недостаточности информации всё больше.
Вообще Data Lake — это как раз парадигма «сохраняем все-все данные, авось потом пригодится», так что это скорее задел на будущее
Informatica BDE — это on premises или SaaS/Cloud?
Спасибо за вопрос. Informatica BDE — это on premises. Но у Informatica есть реализация облачной платформы интеграции — Informatica Cloud.
Спасибо, интересно!
Читаю ваши статьи и поражаюсь тому как все быстро и просто у вас все получается
Скажите Informatica platform умеет так же «пушдаунить» трансформации на green plum?
Если да, то зачем вообще Hadoop нужен?
Читаю ваши статьи и поражаюсь тому как все быстро и просто у вас все получается
Скажите Informatica platform умеет так же «пушдаунить» трансформации на green plum?
Если да, то зачем вообще Hadoop нужен?
Спасибо за вопрос. Ну не так уже и быстро и просто, работы много, но мы стараемся :)
Новая Informatica пока пушдаунить на Greenplum не умеет, с этой задачей хорошо справляется Informatica Power Center.
Про зачем нужен Hadoop — ну например вопрос стоимости хранения, в Hadoop хранить данные в 7-9 раз дешевле чем в Greenplum. При этом Greenplum у нас остаётся, мы можем строить в Hadoop витрины с агрегатами или различные сегментации и поднимать их в Greenplum. Ещё важный аргумент в сторону использования Hadoop — это не только среда хранения и но платформа работы с данными, т.е. мы не разрываем эти два понятия и наши аналитики работают, строят модели и исполнят их в Hadoop.
Новая Informatica пока пушдаунить на Greenplum не умеет, с этой задачей хорошо справляется Informatica Power Center.
Про зачем нужен Hadoop — ну например вопрос стоимости хранения, в Hadoop хранить данные в 7-9 раз дешевле чем в Greenplum. При этом Greenplum у нас остаётся, мы можем строить в Hadoop витрины с агрегатами или различные сегментации и поднимать их в Greenplum. Ещё важный аргумент в сторону использования Hadoop — это не только среда хранения и но платформа работы с данными, т.е. мы не разрываем эти два понятия и наши аналитики работают, строят модели и исполнят их в Hadoop.
Вот насчет последнего…
Мне сложно представить как например связывать большие таблицы если мы не понимаем как они хранятся в hadoop, тем более у вас data vault где таблицы по умолчанию как бы «в нормализованном виде». Hadoop не разложит их так, что они будут очень не эффективно вязаться и скорость работы будет еще хуже чем при традиционных СУБД??
А не смотрели в сторону postgre-xl? Бесплатно, работает, можем контролировать то как таблица размазывается по кластеру…
Мне сложно представить как например связывать большие таблицы если мы не понимаем как они хранятся в hadoop, тем более у вас data vault где таблицы по умолчанию как бы «в нормализованном виде». Hadoop не разложит их так, что они будут очень не эффективно вязаться и скорость работы будет еще хуже чем при традиционных СУБД??
А не смотрели в сторону postgre-xl? Бесплатно, работает, можем контролировать то как таблица размазывается по кластеру…
Да, согласен. Но мы то как раз следим за тем как мы загружаем данные в Data Vault. Мы раскладываем все данные по партициям и используем кластаризацию и бакетирование. Это позволяет нам снизить обмен по сети когда мы строим какие либо запросы на таблицах в Data Vault. И конечно же простое использование Data Vault не очень то эффективно, а вот построение прикладных витрин на Data Vault даёт возможность повысить эффективность запросов. Postgre XL не пробовали, у нас GreenPlum есть :)
Платили за какие либо лицензии или подписки, если да, то зачем, почти все опенсорсное, какие преимущества у платных версий? Если так много данных, то почему не Apache Storm?
Да, Informatica это платное удовольствие :) Apache Storme — это потоковая обработка данных, нам же нужен был батч процесс, ETL, т.к. несколько источников данных, а одна из задач это построение консолидированного представления данных по этим источникам. Ничего не имеем против опенсорса, иначе бы не пошли в сторону Hadoop. Преимуществ у Informatica несколько — это продукт, а не фреймворк, это наличие метаданных, это уже реализованный мониторинг и администрирование, это удобная и не сложная среда разработки, это, что не мало важно, среда разработки и реализации разделены со средой исполнения. Пример по последнему пункту очень простой. Представьте что у вас есть уже написанные батч процессы на mr, на java и тут выходит spark и вы начинаете это всё переписывать, и всё что из этого вытекает, на spark… Когда у вас продукт, в нашем случае Informatica, мы не занимаемся переписыванием всего написанного.
DWH, ETL, WTF и т.д сначала бы расшифровали эти аббревиатуры потм писали, в гугле не забанили, но это как то не правильно
>Как и в классическом DWH, мы выделили основные концептуальные слои данных
Ну если уж совсем придерживаться концепции слоев то RAW это STG, ODD это ODS, а DDS в принципе тоже правильно, но я обычно использую DWH.
>Apache Flume.
Что всегда удивляет, так это никогда не повторяющееся сочетания софта и технологий, они всегда новые =) Нет стабильности в мире BigData =)
На счет того что существует Informatica BDE большой респект! не знал это она есть. Но сразу могу вам дать совет вопрос:
> не хватает всего того множества полезных фич, которые есть в старом PowerCenter
А вы можете его использовать тоже, просто target будет сперва РСУБД, а потом уже Hadoop. Но опять же вопрос, на сколько PowerCenter подходит для ваших данных и ETL.
>Hive
Я не знаток NoSQL технологий, но разве стандартный Hive+Hadoop не тормозной? Слышал что все переходят на parquet, storm, Impala, Drill и т.д. Почему именно остановились на Hive+Hadoop?
Ну если уж совсем придерживаться концепции слоев то RAW это STG, ODD это ODS, а DDS в принципе тоже правильно, но я обычно использую DWH.
>Apache Flume.
Что всегда удивляет, так это никогда не повторяющееся сочетания софта и технологий, они всегда новые =) Нет стабильности в мире BigData =)
На счет того что существует Informatica BDE большой респект! не знал это она есть. Но сразу могу вам дать совет вопрос:
> не хватает всего того множества полезных фич, которые есть в старом PowerCenter
А вы можете его использовать тоже, просто target будет сперва РСУБД, а потом уже Hadoop. Но опять же вопрос, на сколько PowerCenter подходит для ваших данных и ETL.
>Hive
Я не знаток NoSQL технологий, но разве стандартный Hive+Hadoop не тормозной? Слышал что все переходят на parquet, storm, Impala, Drill и т.д. Почему именно остановились на Hive+Hadoop?
Спасибо за комментарии.
Я бы сказал иначе — в мире BigData все течет, все изменяется :) Технологии развиваются, становятся более стабильными, BigData медленно но верно движется в сегмент Enterprise.
PowerCenter не умеет делать PDO на Hadoop.
Hadoop со своей экосистемой развивается и в направлении операционной аналитики, а значит и запросы на Hive и сам Hive становится более производительным. Parquet — это колоночный формат хранения данных в HDFS, с которым также работает Hive. Storm, писал выше, это потоковая обработка данных, нам же нужен был батч процесс. Impala — используем для ad-hoc, PDO на Impala Informatica BDE делать не умеет. Drill не используем.
Надеюсь ответил на ваши вопросы.
Нет стабильности в мире BigData
Я бы сказал иначе — в мире 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 не используем.
Надеюсь ответил на ваши вопросы.
Вполне!
Статья хорошая, но требует продолжения.
Например, производительность запросов на вышей системе?
Давайте я буду сторонником традиционных подходов и уверен, что на ваших объемах Оракл и Терадата уделают вас в производительности запросов в 10 раз, а вы будите отстаивать противоположную точку зрения? =)
Иначе я пока сомневаюсь в целесообразности использование не стандартных подходов, точно ли у вас конечный формат данных, характер запросов и объемы данных лучше укладываются в стек технологий Big Data нежели традиционные DWH? Я в этом не уверен и не вижу ответа в статьи!
Статья хорошая, но требует продолжения.
Например, производительность запросов на вышей системе?
Давайте я буду сторонником традиционных подходов и уверен, что на ваших объемах Оракл и Терадата уделают вас в производительности запросов в 10 раз, а вы будите отстаивать противоположную точку зрения? =)
Иначе я пока сомневаюсь в целесообразности использование не стандартных подходов, точно ли у вас конечный формат данных, характер запросов и объемы данных лучше укладываются в стек технологий Big Data нежели традиционные DWH? Я в этом не уверен и не вижу ответа в статьи!
Ну, у них же там есть Greenplum — наверное можно спихивать туда то, что уже проструктурировали. Это как бы маленькая Терадата.
А так, для не очень еще понятной информации хадуп наверное в 100 раз дешевле Терадаты в пересчете на Гигабайт места (особенно при апгрейде).
А так, для не очень еще понятной информации хадуп наверное в 100 раз дешевле Терадаты в пересчете на Гигабайт места (особенно при апгрейде).
Да, все верно, можно какие-нибудь агрегаты/витрины поднимать в Greenplum.
Вопрос стоимости хранения гигабайтов очень важный! skullodrom Oracle и Teradata под одну гребенку не нужно. Здесь скорей всего по стоимости хранения будет следующий порядок, по убыванию:
При этом цены будут различаться примерно в порядок.
Это как бы маленькая Терадатаспорное утверждение, когда GreenPlum кластер из 16 серверов :)
Вопрос стоимости хранения гигабайтов очень важный! skullodrom Oracle и Teradata под одну гребенку не нужно. Здесь скорей всего по стоимости хранения будет следующий порядок, по убыванию:
- Oracle
- MPP
- Hadoop
При этом цены будут различаться примерно в порядок.
>спорное утверждение, когда GreenPlum кластер из 16 серверов :)
смотря какие сервера :)
Стандартная Терадата 2750 года полтора назад имела на борту 432 ядра и 432 винта и 6 Тб оперативки. А сколько у вас?
Я бы сказала даже так, по стоимости хранения будет следующий порядок, по убыванию:
Teradata (+ со всеми фичами типа колоночное хранение)
Exadata
Oracle
Другие MPP
Hadoop
>При этом цены будут различаться примерно в порядок.
Более или менее согласен
Юрия, а вы выбрали Hadoop именно по причине низкой стоимости за Гб или были другие причины?
А почему выбрали Greenplum, а не Vertica, Netezza?
Кстати у Терадаты есть свой Hadoop, называется AsterData, вроде как там стоимость хранения более чем на порядок дешевле, не рассматривали ее?
смотря какие сервера :)
Стандартная Терадата 2750 года полтора назад имела на борту 432 ядра и 432 винта и 6 Тб оперативки. А сколько у вас?
Я бы сказала даже так, по стоимости хранения будет следующий порядок, по убыванию:
Teradata (+ со всеми фичами типа колоночное хранение)
Exadata
Oracle
Другие MPP
Hadoop
>При этом цены будут различаться примерно в порядок.
Более или менее согласен
Юрия, а вы выбрали Hadoop именно по причине низкой стоимости за Гб или были другие причины?
А почему выбрали Greenplum, а не Vertica, Netezza?
Кстати у Терадаты есть свой Hadoop, называется AsterData, вроде как там стоимость хранения более чем на порядок дешевле, не рассматривали ее?
по причине низкой стоимости за Гб или были другие причины?и это тоже. Где как не в Hadoop предлагаете хранить гигантские объемы неструктурированных данных?
А почему выбрали Greenplum, а не Vertica, Netezza?на тот момент когда выбирали Netezza была морально устаревшей, а Vertica сыроватой. Выбирали бы сейчас, с большой долей вероятности выбрали бы Vertica.
называется AsterDataвсе эти сборки хадупов от больших вендоров (PivotalHD, IBM Biginsights, AsterData...) развиваются медленней. Нам интересен Spark по этому Cloudera. Хотя вот у PivotalHD есть замечательный HAWQ, который по производительности работы запросов показывает себя очень и очень хорошо…
А на проде большой кластер для Hadoop получился? Что за машины?
Можно вопрос немного не в тему? Каких размеров у вас кластер (сколько нод, дисков, ядер, памяти)?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Data Lake – от теории к практике. Сказ про то, как мы строим ETL на Hadoop