Насколько я знаю, в большинстве коммерческих аналитических МРР-системах имеется в той или иной мере поддержка ML и предиктивной аналитики, в той же Aster или Vertica это имеется. Другое дело насколько эта поддержка удовлетворяет вашим потребностям. Например, в Vertica работа с ML по функционалу и подходу очень напоминает MadLib.
Надо понимать, что «немного кода на Java», в реальности выливается в сложности:
1. Как обрабатывать исключения, зависания, утечки памяти и т.п.?
2. Логирования ошибок соединенения, загрузки и т.п…
3. Изменение модели данных источника и применика
4. Ковертация типов данных, между различными СУБД, работа с теми же самыми датами.
Тут же уже все давно придумано и, конечно, можно написать свой велосипед, но использовать уже готовые инструменты или фреймворки все же намного проще, благо, существует большое количество OpenSource проектов.
Алексей, во-первых, вам большой респект за HAWQ (активно слежу за этим проектом)
Spark не MPP, это тот же Batch Processing
Понятие МРР я восринимаю буквально — массивно-параллельный процессинг.
Да, понятие МРР тесно закрепилось за конкретными СУБД(Vertica, GPDB, Teradata и т.д.), но технически MapReduce, Kudu, Spark и т.д. тоже является МРР-системой с распределенной архитектурой.
Kudu не имеет зависимости от HDFS, это как раз более быстрая замена HDFS
Хм… на главной же странице Kudu: A new addition to the open source Apache Hadoop ecosystem, Apache Kudu (incubating) completes Hadoop's storage layer to enable fast analytics on fast data.
Возможно это очередной маркетинговый булшит, покапаюсь глубже в этой теме.
MPP over Hadoop востребована
А чем именно обуслевлена данная востребованность? Популярностью Hadoop или реальными потребностями рынка?
Открою для вас горькую правду — ничего бесплатного в нашем мире нет. Используя CDH или Hortonworks, вы должны купить подписку на поддержку, которая, кстати, не бесплатная.
Если вы собираете свой дистриубутив Hadoop, то да — это бесплатно, но вы уйдете с проекта, кто это все поддерживать будет если оно сломается??
Опробовать статистические методы
Все это есть в любой аналитической МРР системе, в том же Greenplum — библиотека MadLib, умеет делать очень много и на SQL-подобном языке.
просто не хотите слазить с SQL-ориентированных задач. Увы, не всё в мире сводится к JOIN-у двух таблиц.
Согласен, не все так категорично, но перед тем как эти две таблички связать, необходимо провести много работы и не обязательно для этого использовать инструменты из зоопарка Hadoop.
Тоже самое, что и для Spark Streaming, все же потоковые вычисления не совсем то, о чем я хотел рассказать.
Думаю, определенную нишу эти продукты найдут.
Но опять же, нужно каждый раз думать, необходимо ли использовать этот инструмент
Как уже писал уважаемый vais в комментарии выше, цепочка из такого зоопарка выглядит как минимум… кхм… странной:
postgresql->.net service-> logstash -> kafka ->spark streaming -> hive — > Informatica -> MSSql
Я не знаток Монги, но могу предложить, что все, что продается там под соусом MapReduce — это не MapReduce.
Это просто распределенные вычисления(извиняюсь за каламбур, но не каждое распределенное вычисление — это MapReduce)
Спасибо. Из плюсов
1. Убираем лишний слой абстракции над файловой системой, позволяющий выстрелить в ногу. Пример, под Hadoop лежит «еще одна» файловая система, приводящая к фрагментации и рандому при чтении.
2. Если у вас нормальные, структурированные данные — вам не нужен HDFS, это лишние издержки.
Из минусов — лишаемся возможности развести помойку разрозненных данных на HDFS)))
Яндекс, спасибо!
Сколько же аналитических МРР-систем вышло в Open-Source в последнее время!
В начале статьи вы не совсем правильно провели аналитику рынка, разделив его на 5 сегментов и противопоставив себя каждому.
Все перечисленные решения в сравнении плюс/минус тоже самое(кроме платных).
Геораспределенность в аналитической системе? зачем? «Надстройки над Hadoop» это полноценные аналитические МРР-системы и от вашего решения отличаются практически ничем, умеют делать такие же SQL запросы, имеют почти такое же колоночное хранилище, с сжатием. Приближенные вычисления — интересно.
Я не знаю конечно какие цели были у Яндекса, но конкурировать будет с кем.
А вы не думали сделать аналог BigQuery на его основе? Мне кажется было бы интересно, тем более у вас имеются преимущества.
Нет, не считаю.
По факту это просто «грязные» данные, которые автор чистил и сводил в одном месте, с помощью удобного инструмента.
Можно конечно долго размышлять — что есть структура и т.п., но смысла в этом мало — это всего лищь терминология)))
В любом случае статья интересная, спасибо.
Спасибо за статью, но…
GPDB уже сейчас поддерживает AVRO, PARQUET в качестве внешних таблиц в HDFS
Например:
CREATE EXTERNAL TABLE tab (column_spec) LOCATION ( 'gphdfs://location') FORMAT 'AVRO'
Скорее всего в такой виртуалке вы не сможете использовать ресурсы CPU и RAM на полную, а только 20-30% от номинальной(в лучшем случае), если это OpenVZ.
KVM точно не будут стоить таких денег
Спасибо, теперь мой любимый браузер!!!
Но есть вещь, которая просто бесит:
Верхняя рамочка между верхним краем экрана и панелью табов? можно ли ее как то убрать, как в Chrome?
Вот пример: http://snag.gy/IJcag.jpg
1. Как обрабатывать исключения, зависания, утечки памяти и т.п.?
2. Логирования ошибок соединенения, загрузки и т.п…
3. Изменение модели данных источника и применика
4. Ковертация типов данных, между различными СУБД, работа с теми же самыми датами.
Тут же уже все давно придумано и, конечно, можно написать свой велосипед, но использовать уже готовые инструменты или фреймворки все же намного проще, благо, существует большое количество OpenSource проектов.
Понятие МРР я восринимаю буквально — массивно-параллельный процессинг.
Да, понятие МРР тесно закрепилось за конкретными СУБД(Vertica, GPDB, Teradata и т.д.), но технически MapReduce, Kudu, Spark и т.д. тоже является МРР-системой с распределенной архитектурой.
Хм… на главной же странице Kudu: A new addition to the open source Apache Hadoop ecosystem, Apache Kudu (incubating) completes Hadoop's storage layer to enable fast analytics on fast data.
Возможно это очередной маркетинговый булшит, покапаюсь глубже в этой теме.
А чем именно обуслевлена данная востребованность? Популярностью Hadoop или реальными потребностями рынка?
Открою для вас горькую правду — ничего бесплатного в нашем мире нет. Используя CDH или Hortonworks, вы должны купить подписку на поддержку, которая, кстати, не бесплатная.
Если вы собираете свой дистриубутив Hadoop, то да — это бесплатно, но вы уйдете с проекта, кто это все поддерживать будет если оно сломается??
Все это есть в любой аналитической МРР системе, в том же Greenplum — библиотека MadLib, умеет делать очень много и на SQL-подобном языке.
Согласен, не все так категорично, но перед тем как эти две таблички связать, необходимо провести много работы и не обязательно для этого использовать инструменты из зоопарка Hadoop.
Думаю, определенную нишу эти продукты найдут.
Но опять же, нужно каждый раз думать, необходимо ли использовать этот инструмент
Как уже писал уважаемый vais в комментарии выше, цепочка из такого зоопарка выглядит как минимум… кхм… странной:
postgresql->.net service-> logstash -> kafka ->spark streaming -> hive — > Informatica -> MSSql
Это просто распределенные вычисления(извиняюсь за каламбур, но не каждое распределенное вычисление — это MapReduce)
1. Убираем лишний слой абстракции над файловой системой, позволяющий выстрелить в ногу. Пример, под Hadoop лежит «еще одна» файловая система, приводящая к фрагментации и рандому при чтении.
2. Если у вас нормальные, структурированные данные — вам не нужен HDFS, это лишние издержки.
Из минусов — лишаемся возможности развести помойку разрозненных данных на HDFS)))
Кстати, решение очень похоже на Apache NiFi.
Сколько же аналитических МРР-систем вышло в Open-Source в последнее время!
В начале статьи вы не совсем правильно провели аналитику рынка, разделив его на 5 сегментов и противопоставив себя каждому.
Все перечисленные решения в сравнении плюс/минус тоже самое(кроме платных).
Геораспределенность в аналитической системе? зачем? «Надстройки над Hadoop» это полноценные аналитические МРР-системы и от вашего решения отличаются практически ничем, умеют делать такие же SQL запросы, имеют почти такое же колоночное хранилище, с сжатием. Приближенные вычисления — интересно.
Я не знаю конечно какие цели были у Яндекса, но конкурировать будет с кем.
А вы не думали сделать аналог BigQuery на его основе? Мне кажется было бы интересно, тем более у вас имеются преимущества.
По факту это просто «грязные» данные, которые автор чистил и сводил в одном месте, с помощью удобного инструмента.
Можно конечно долго размышлять — что есть структура и т.п., но смысла в этом мало — это всего лищь терминология)))
В любом случае статья интересная, спасибо.
GPDB уже сейчас поддерживает AVRO, PARQUET в качестве внешних таблиц в HDFS
Например:
CREATE EXTERNAL TABLE tab (column_spec) LOCATION ( 'gphdfs://location') FORMAT 'AVRO'
Разве этого не достаточно?
KVM точно не будут стоить таких денег
Но есть вещь, которая просто бесит:
Верхняя рамочка между верхним краем экрана и панелью табов? можно ли ее как то убрать, как в Chrome?
Вот пример: http://snag.gy/IJcag.jpg