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