Comments 75
Интересная статья.
«Появятся первые дистрибутивы CDH уже с частичным отказом от использования HDFS». А можно описать плюсы и минусы такого решения??
«Появятся первые дистрибутивы CDH уже с частичным отказом от использования HDFS». А можно описать плюсы и минусы такого решения??
Спасибо. Из плюсов
1. Убираем лишний слой абстракции над файловой системой, позволяющий выстрелить в ногу. Пример, под Hadoop лежит «еще одна» файловая система, приводящая к фрагментации и рандому при чтении.
2. Если у вас нормальные, структурированные данные — вам не нужен HDFS, это лишние издержки.
Из минусов — лишаемся возможности развести помойку разрозненных данных на HDFS)))
1. Убираем лишний слой абстракции над файловой системой, позволяющий выстрелить в ногу. Пример, под Hadoop лежит «еще одна» файловая система, приводящая к фрагментации и рандому при чтении.
2. Если у вас нормальные, структурированные данные — вам не нужен HDFS, это лишние издержки.
Из минусов — лишаемся возможности развести помойку разрозненных данных на HDFS)))
А какую файловую систему используют в таком случае?
Пример, под Hadoop лежит «еще одна» файловая система, приводящая к фрагментации и рандому при чтении.
WAT?? Поясните, пожалуйста, о какой фрагментации и рандомном чтении идёт речь?
Если у вас нормальные, структурированные данные — вам не нужен HDFS, это лишние издержки.
Расскажите, как, например, Vertica, справляется с real-time аналитикой? Я отвечу за вас: плохо. А вот, например, Druid, хранящий абсолютно структурированные данные на HDFS, делает это вполне эффективно. А всё потому, что HDFS и Hadoop вообще предоставляют более низкоуровневые инструменты и гораздо более широкие возможности, чем любая отдельно взятая SQL СУБД.
Расскажите, как, например, Vertica, справляется с real-time аналитикой? Я отвечу за вас: плохо.
Отлично справляется. У нас пару клиентов за бугром, кто в реалтайме считает клики в банерных сетях прямо на Вертике. У них задержка более 0.3 сек на ответ запросу уже считается ужасом ужасным :)
Справедливаости ради, Druid не хранит горячие данные на hdfs. Горячие данные он хранит под собой, сливая на hdfs (или s3, или ceph...) исторические свертки.
Горячие данные он хранит под собой, сливая на hdfs (или s3, или ceph...) исторические свертки.
Т.е. на распределённую файловую систему, которая в данном случае является необходимостью, а не "лишними издержками" :)
Поставте s3 api на любое абстрактное хранилище, хоть полку c дисками — эффект будет тот же. HDFS тут сугубо потому, что «так тут повелось». Нужно просто много надежного места для хранения истории, распределнность этого хранилища не очень важна. В конечном счете, если мы говорим о realtime — все, что не висит в памяти, напрямую из application или косвенно как object store — не есть realtime, ибо (относительно памяти) медленно.
P.S. Те же примеры, проскакивающие тут в комментриях «у меня на вертике за 0.1» — это не про условную вертику, а про многослойную архитектуру хранения. Терабайты оперативной памяти, ssd cache, infiniband, вот это вот все… Ну или не такие страшные слова — просто горячих данных (относительно) немного. Чудес то не бывает.
P.S. Те же примеры, проскакивающие тут в комментриях «у меня на вертике за 0.1» — это не про условную вертику, а про многослойную архитектуру хранения. Терабайты оперативной памяти, ssd cache, infiniband, вот это вот все… Ну или не такие страшные слова — просто горячих данных (относительно) немного. Чудес то не бывает.
Поставте s3 api на любое абстрактное хранилище, хоть полку c дисками — эффект будет тот же.
Это всё понятно, вопрос был в том, нужен ли HDFS, если все данные — структурированые. Я привёл пример того, где абсолютно структирированные данные пишутся на HDFS, а не в RDBMS, потому что RDBMS не даёт нужного уровня абстракции и контроля.
В конечном счете, если мы говорим о realtime — все, что не висит в памяти, напрямую из application или косвенно как object store — не есть realtime, ибо (относительно памяти) медленно.
Real-time — понятие относительное. Например, Википедия говорит нам, что
"real-time" means a range from milliseconds to a few seconds (5s) after the business event has occurred
На практике же всё определяется ожиданиями клиента: если клиент загружает 3Гб данных и видит по ним аналитику через 15 минут, 13 из которых заливался файл, то для него это всё ещё "real-time".
С замечаниями согласен.
Но хотелось бы отметить, что в дискуссиях по поводу «хранения (слабо) структурирванных данных» стороны очень часто (не сознательно) меняют контекст. Веть действительно, если у вас есть данные, уже разложенные для rdbms, то складывать их на абстракный hdfs для того, чтобы бегать по ним абстрактным drill'ом может быть избыточно…
Но хотелось бы отметить, что в дискуссиях по поводу «хранения (слабо) структурирванных данных» стороны очень часто (не сознательно) меняют контекст. Веть действительно, если у вас есть данные, уже разложенные для rdbms, то складывать их на абстракный hdfs для того, чтобы бегать по ним абстрактным drill'ом может быть избыточно…
Я вот не понимаю, Mongo DB имеющая множество инструментов для MapReduce, хорошо масштабируемая и уже не относится к миру BigData? Почему в статьях когда рассказывают про bigdata редко встретишь упоминание этой бд?
Я не знаток Монги, но могу предложить, что все, что продается там под соусом MapReduce — это не MapReduce.
Это просто распределенные вычисления(извиняюсь за каламбур, но не каждое распределенное вычисление — это MapReduce)
Это просто распределенные вычисления(извиняюсь за каламбур, но не каждое распределенное вычисление — это MapReduce)
Я так понимаю разница в том что монго это bjson — т.е. «полу»-стркуткурированные данные, а в хадупе у вас есть к примеру вся библиотека конгресса США в виде одного файла, по частям на нодах, и потом воркерами и прочими зверьками вы достаете то что вам нужно. Т.к. хадуб на уровень структурированности данных ниже чем монго.
Raw data --> Hadoop --> Semi-Structured Data --> Mongo --> Aggregated Data
Raw data --> Hadoop --> Semi-Structured Data --> Mongo --> Aggregated Data
На официальном сайте есть этому объяснение: https://www.mongodb.com/big-data-explained
Вся эта статья про аналитические системы, а MongoDB — это т.н. «operational» система. Обычно она всплывает в контексте обсуждения Cassandra, HBase и подобных систем этого класса
Вся эта статья про аналитические системы, а MongoDB — это т.н. «operational» система. Обычно она всплывает в контексте обсуждения Cassandra, HBase и подобных систем этого класса
Есть кстати такой зверек как Marklogic, которого многие маркетологи позиционируют как монгу для Биг Даты
В монге в режиме «на запись» работает только один узел системы. Так что более-менее мастабируется она на относительно небольших объемах.
Да и в целом Mongo держится в первую очередь на маркетинге. Для многих задач, которые пытаются решать с Mongo зачастую больше подошел бы PostgreSQL его JSONB.
Да и в целом Mongo держится в первую очередь на маркетинге. Для многих задач, которые пытаются решать с Mongo зачастую больше подошел бы PostgreSQL его JSONB.
Спасибо за взвешенный подход. А то «все кругом говорят о Hadoop» как о единственной панацее, да ещё и бесплатной. И опять мы сталкиваемся с агрессивным маркетингом на реальной и актуальной потребности бизнеса проводить предметную аналитику по конкретным проблемам на основе накопленных данных.
Согласен с автором.
Хадуп очень избыточен, пример:
Нужно перебрасывать данные из 7 таблиц на postgreSQL в одну таблицу на mssql.
Решение в котором ключевую роль играет Хадуп:
Новые данные в онлайн режиме подбираются из postgreSQL неким самописным сервисом, летят в logstash от туда в kafka
из кафки, спарк стримингом грузим данные в hive,
а из hive данные забираются каждый день информатикой и льются в MSsql
итоговая цепочка
postgresql->.net service-> logstash -> kafka ->spark streaming -> hive — > Informatica -> MSSql
И в качестве плана Б был реализован поток на информатике (За 1 день)
postgresql -> IPC -> MSSql
Да хадуп бесплатен, да не нужно платить немалые деньги за лицензию oracle, Informatica ETL
Но стоит ли оно того?
Хадуп очень избыточен, пример:
Нужно перебрасывать данные из 7 таблиц на postgreSQL в одну таблицу на mssql.
Решение в котором ключевую роль играет Хадуп:
Новые данные в онлайн режиме подбираются из postgreSQL неким самописным сервисом, летят в logstash от туда в kafka
из кафки, спарк стримингом грузим данные в hive,
а из hive данные забираются каждый день информатикой и льются в MSsql
итоговая цепочка
postgresql->.net service-> logstash -> kafka ->spark streaming -> hive — > Informatica -> MSSql
И в качестве плана Б был реализован поток на информатике (За 1 день)
postgresql -> IPC -> MSSql
Да хадуп бесплатен, да не нужно платить немалые деньги за лицензию oracle, Informatica ETL
Но стоит ли оно того?
Спасибо, есть и большое количество OpenSource ETL, например Pentaho, Talend. Для семи табличек можно было обойтись без Informatica PowerCenter/
Изи задачка и без «Informatica ETL»
Один селект, один инсерт (что-то кроме — хранимые процедуры) и немного кода на джаве.
Если подшаманить немного с мэпингом полей и конфигами впринципе вот вам и решение более общей задачи. Не знаю как Informatica ETL, а данный подход позволял передавать over 1млн «абстрактных» записей между базами меньше чем за минуту.
Один селект, один инсерт (что-то кроме — хранимые процедуры) и немного кода на джаве.
Если подшаманить немного с мэпингом полей и конфигами впринципе вот вам и решение более общей задачи. Не знаю как Informatica ETL, а данный подход позволял передавать over 1млн «абстрактных» записей между базами меньше чем за минуту.
Надо понимать, что «немного кода на Java», в реальности выливается в сложности:
1. Как обрабатывать исключения, зависания, утечки памяти и т.п.?
2. Логирования ошибок соединенения, загрузки и т.п…
3. Изменение модели данных источника и применика
4. Ковертация типов данных, между различными СУБД, работа с теми же самыми датами.
Тут же уже все давно придумано и, конечно, можно написать свой велосипед, но использовать уже готовые инструменты или фреймворки все же намного проще, благо, существует большое количество OpenSource проектов.
1. Как обрабатывать исключения, зависания, утечки памяти и т.п.?
2. Логирования ошибок соединенения, загрузки и т.п…
3. Изменение модели данных источника и применика
4. Ковертация типов данных, между различными СУБД, работа с теми же самыми датами.
Тут же уже все давно придумано и, конечно, можно написать свой велосипед, но использовать уже готовые инструменты или фреймворки все же намного проще, благо, существует большое количество OpenSource проектов.
вот вспоминается почему то два примера более менее известных когда компании сами описывали архитектуру:
— CCP Games. основной массив данных чуть более терабайта. С ним работает кластер из ~100 машин к которым цепляются клиентский софт (и клиенты будут очень довольны если будут лаги). Непосредственно сервер БД — 2 мощных IBM x86 сервера на которых...Windows и MSSQL(!). а проблему с тем чтобы все летало — решили RAMSAN'ами (аппаратный RAMdisk на сколько надо терабайт)
— Linden Labs. данных в сумме — под половину эксабайта. часть — блобы, часть более менее структурированные данные. Куча раздельных кластеров MySQL (структурированные данные там достаточно просто шардировались) а блобы… сначала на хранилках isilon systems а затем… выгрузили на S3(все равно реальную работу с теми блобами делает обычно клиент, которому надо их скачать и желательно побыстрее а S3 это лучще обеспечивает)
— CCP Games. основной массив данных чуть более терабайта. С ним работает кластер из ~100 машин к которым цепляются клиентский софт (и клиенты будут очень довольны если будут лаги). Непосредственно сервер БД — 2 мощных IBM x86 сервера на которых...Windows и MSSQL(!). а проблему с тем чтобы все летало — решили RAMSAN'ами (аппаратный RAMdisk на сколько надо терабайт)
— Linden Labs. данных в сумме — под половину эксабайта. часть — блобы, часть более менее структурированные данные. Куча раздельных кластеров MySQL (структурированные данные там достаточно просто шардировались) а блобы… сначала на хранилках isilon systems а затем… выгрузили на S3(все равно реальную работу с теми блобами делает обычно клиент, которому надо их скачать и желательно побыстрее а S3 это лучще обеспечивает)
А что можете сказать про storm.apache.org?
Тоже самое, что и для Spark Streaming, все же потоковые вычисления не совсем то, о чем я хотел рассказать.
Думаю, определенную нишу эти продукты найдут.
Но опять же, нужно каждый раз думать, необходимо ли использовать этот инструмент
Как уже писал уважаемый vais в комментарии выше, цепочка из такого зоопарка выглядит как минимум… кхм… странной:
postgresql->.net service-> logstash -> kafka ->spark streaming -> hive — > Informatica -> MSSql
Думаю, определенную нишу эти продукты найдут.
Но опять же, нужно каждый раз думать, необходимо ли использовать этот инструмент
Как уже писал уважаемый vais в комментарии выше, цепочка из такого зоопарка выглядит как минимум… кхм… странной:
postgresql->.net service-> logstash -> kafka ->spark streaming -> hive — > Informatica -> MSSql
Ну давайте по пунткам:
Hadoop вырос из Nutch, который вырос из Lucene. Но к моменту формирования Hadoop как отдельного проекта ASF (а тем более к моменту, когда он стал проектом верхнего уровня), Hadoop уже был вполне самостоятельным продуктом, вышедшим далеко за пределы индексирования текста.
Софт — бесплатно, цена железа остаётся, и я пока не встречал менеджеров, которые это не понимали. Но цена софта тоже имеет значение: у нас, например, одна только лицензия на Vertica стоит больше чем лизинг серверов Hadoop и стоимость фулл-тайм администратора для него. Мы используем и то, и другое, для разных задач, потому что в одних случаях дешевле решать задачу одним способом, в другом — другим.
Ок, задача: классифицировать 10Тб сообщений пользователей на Facebook. Опробовать статистические методы: наивный Байесовский классификатор, логистическая регрессия, машина опорных векторов. Покажите как это сделать на Vertica, Teradata или что вам больше нравится, а потом сравним это с реализацией на Hadoop/Spark.
Да, например бесплатно. С поправкой на железо, конечно, но про это я уже сказал.
Ага, поэтому мы сейчас переписываем уже почти загнувшееся решение на Redshift/Vertica на Spark/SparkSQL.
Полировать — это сильно сказано. Когда мы последний раз пытались написать свой (!) ридер паркетовский файлов из HDFS с помощью Vertica UDF, внезапно оказалось, что Vertica вообще не умеет парсить бинарные данные и пытается перевести из "битой" кодировки в "нормальный UTF-8". Бинарные данные в UTF-8, ага.
В общем, вы явно либо не поняли сути технологического стека Hadoop, либо просто не хотите слазить с SQL-ориентированных задач. Увы, не всё в мире сводится к JOIN-у двух таблиц.
Hadoop как средство для индексирования
Hadoop вырос из Nutch, который вырос из Lucene. Но к моменту формирования Hadoop как отдельного проекта ASF (а тем более к моменту, когда он стал проектом верхнего уровня), Hadoop уже был вполне самостоятельным продуктом, вышедшим далеко за пределы индексирования текста.
Миф 1. Hadoop — это бесплатно
Софт — бесплатно, цена железа остаётся, и я пока не встречал менеджеров, которые это не понимали. Но цена софта тоже имеет значение: у нас, например, одна только лицензия на Vertica стоит больше чем лизинг серверов Hadoop и стоимость фулл-тайм администратора для него. Мы используем и то, и другое, для разных задач, потому что в одних случаях дешевле решать задачу одним способом, в другом — другим.
Миф 2. Hadoop для обработки неструктурированной информации.
Ок, задача: классифицировать 10Тб сообщений пользователей на Facebook. Опробовать статистические методы: наивный Байесовский классификатор, логистическая регрессия, машина опорных векторов. Покажите как это сделать на Vertica, Teradata или что вам больше нравится, а потом сравним это с реализацией на Hadoop/Spark.
По цене CDH выходит немного дешевле Vertica/Greenplum.
Да, например бесплатно. С поправкой на железо, конечно, но про это я уже сказал.
Все это более-менее эффективно работает на простых запросах.
Ага, поэтому мы сейчас переписываем уже почти загнувшееся решение на Redshift/Vertica на Spark/SparkSQL.
Vertica будет полировать свою интеграцию с HDFS
Полировать — это сильно сказано. Когда мы последний раз пытались написать свой (!) ридер паркетовский файлов из HDFS с помощью Vertica UDF, внезапно оказалось, что Vertica вообще не умеет парсить бинарные данные и пытается перевести из "битой" кодировки в "нормальный UTF-8". Бинарные данные в UTF-8, ага.
В общем, вы явно либо не поняли сути технологического стека Hadoop, либо просто не хотите слазить с SQL-ориентированных задач. Увы, не всё в мире сводится к JOIN-у двух таблиц.
Софт — бесплатно
Открою для вас горькую правду — ничего бесплатного в нашем мире нет. Используя CDH или Hortonworks, вы должны купить подписку на поддержку, которая, кстати, не бесплатная.
Если вы собираете свой дистриубутив Hadoop, то да — это бесплатно, но вы уйдете с проекта, кто это все поддерживать будет если оно сломается??
Опробовать статистические методы
Все это есть в любой аналитической МРР системе, в том же Greenplum — библиотека MadLib, умеет делать очень много и на SQL-подобном языке.
просто не хотите слазить с SQL-ориентированных задач. Увы, не всё в мире сводится к JOIN-у двух таблиц.
Согласен, не все так категорично, но перед тем как эти две таблички связать, необходимо провести много работы и не обязательно для этого использовать инструменты из зоопарка Hadoop.
Открою для вас горькую правду — ничего бесплатного в нашем мире нет. Используя CDH или Hortonworks, вы должны купить подписку на поддержку, которая, кстати, не бесплатная.
Нет, не должны. За деньги вы можете получить версию с парой дополнительных фич и да, поддержку, но и абсолютно бесплатной community edition обычно хватает за глаза.
Все это есть в любой аналитической МРР системе, в том же Greenplum — библиотека MadLib, умеет делать очень много и на SQL-подобном языке.
Так покажите мне, как конкретно решить эту задачу на Greenplum. Я не спорю, что вы сможете через трёхэтажный неэффективный запрос вы сможете сделать наивный Байсовский классификатор, может быть даже реализуете безумную логистическую регрессию, SVM — уже маловероятно. А на Spark я это (и много гораздо более сложных вещей) сделаю в пару строк кода. Смысл в том, что в отличие от SQL баз данных, Hadoop позволяет использовать любой кастомный код, строить любые статистические модели, вызывать любые сторонние API, сохранять состояние, отсылать метрики процесса и многое многое другое. Вы же увидели только SQL составляющу Hadoop и пытаетесь доказать, что все компании страдают ерундой, разворачивая себе Hadoop кластер вместо SQL СУБД.
Согласен, не все так категорично, но перед тем как эти две таблички связать, необходимо провести много работы и не обязательно для этого использовать инструменты из зоопарка Hadoop.
Естественно, и никто чисто на Hadoop не завязывается. Просто в инфраструктуре Hadoop много новых полезных инструментов таких как Spark, Storm, Kafka, GraphX, HBase и т.д., которые могут крутиться на одном и том же кластере и хорошо интегрированы друг с другом. Это удобно, но я пока не видел ни одной компании, которая бы замыкалась только на Hadoop и не использовала другие инструменты (в т.ч. классические SQL базы данных).
yusman
Статья у вас конечно очень холивартная, но благодаря ей породилось очень много интересных комментариев.
MADLib почти единственный продукт подобного рода, который позволяте использовать машинное обучение в MPP DBMS (и пока поддерживает только PostgeSQL ориентированные движки баз данных). Если знаете другие примеры подобный библиотек работающих «поверх» MPP RDBMS (ну или MPP с ACID), мы было бы очень интересно на них посмотреть.
ffriend
К вашему комментарию по поводу анализа 10 Тб. У Teradata есть продукт в портфолио под названием «Teradata Aster Database», который собственно и позволяет делать большинство из ктого что привел в пример ffriend, и как раз таки на базе MapReduce парадигмы. Но помимо MR, там есть еще много интересного — анализ логов из коробки, интеграция с много чем (аля HDFS), App Center, что облегчает доступ простым пользователям к результатам анализа и т.д… И да, это этот софт не бесплатный и порой весьма капризный, но тем не менее в качестве примера-альтернативы для озвученных задач весьма подходит. И да, я не имею никакого отношения к компании.
Статья у вас конечно очень холивартная, но благодаря ей породилось очень много интересных комментариев.
MADLib почти единственный продукт подобного рода, который позволяте использовать машинное обучение в MPP DBMS (и пока поддерживает только PostgeSQL ориентированные движки баз данных). Если знаете другие примеры подобный библиотек работающих «поверх» MPP RDBMS (ну или MPP с ACID), мы было бы очень интересно на них посмотреть.
ffriend
К вашему комментарию по поводу анализа 10 Тб. У Teradata есть продукт в портфолио под названием «Teradata Aster Database», который собственно и позволяет делать большинство из ктого что привел в пример ffriend, и как раз таки на базе MapReduce парадигмы. Но помимо MR, там есть еще много интересного — анализ логов из коробки, интеграция с много чем (аля HDFS), App Center, что облегчает доступ простым пользователям к результатам анализа и т.д… И да, это этот софт не бесплатный и порой весьма капризный, но тем не менее в качестве примера-альтернативы для озвученных задач весьма подходит. И да, я не имею никакого отношения к компании.
Продукт интересный, согласен, но я всё-таки задачи для примера привёл, чтобы показать, что SQL базы обычно не умеют. Для Teradata можно найти кучу других примеров (например, меня сразу смутило, что из general purpose языков, судя по всему, поддерживается только R и только через межпроцессорное взаимодействие, весь продукт недоступен шикорому кругу open source разработчиков, что замедляет развитие и т.д.). И точно так же можно назвать кучу недостатков для любого продукта из инфраструктуры Hadoop. Но нельзя говорить, что весь кипеш вокруг Hadoop и big data — это исключительно работа маркетологов: для формирования текущего рынка были вполне обоснованные исторически предпосылки со вполне конкретной выгодой.
Я с вами полностью согласен по поводу того, что термин не полностью придуман маркетологами. Но термин таит очень много опасностей в использовании для «неподготовленных», много раз в этом убеждался.
SQL не умеет из коробки «делать» машинное обучение, но если долго мучатся — можно в итоге что-то да и реализовать, но про переносимость между разными реализациями стандарта SQL (то есть по факту между разными базами данных) и про производительность я умолчу. И в целом использовать специально нацеленные фрейморки (аля MADlib )всегда лучше.
В Teradata Aster можно вроде как реализовывать задачи запускаемые непосредственно в самой базе либо на Java, либо на C/С++, про R как раз-таки не уверен. А если использовать обычный поток stdin/stdout, то тогда возмжно в приципе использовать любой язык, котрый удобно, главное чтобы он запускался на каждой машине в кластере (это я про аналог Hadoop Streaming).
SQL не умеет из коробки «делать» машинное обучение, но если долго мучатся — можно в итоге что-то да и реализовать, но про переносимость между разными реализациями стандарта SQL (то есть по факту между разными базами данных) и про производительность я умолчу. И в целом использовать специально нацеленные фрейморки (аля MADlib )всегда лучше.
В Teradata Aster можно вроде как реализовывать задачи запускаемые непосредственно в самой базе либо на Java, либо на C/С++, про R как раз-таки не уверен. А если использовать обычный поток stdin/stdout, то тогда возмжно в приципе использовать любой язык, котрый удобно, главное чтобы он запускался на каждой машине в кластере (это я про аналог Hadoop Streaming).
В Teradata Aster можно вроде как реализовывать задачи запускаемые непосредственно в самой базе либо на Java, либо на C/С++, про R как раз-таки не уверен.
Про R у них прямо на сайте написано, так что я так понял, что это основной аналитический инструмент у них.
В остальном да, согласен — термин перегретый, часто рождает мифы и слухи. Но и статьи вроде этой не помогают: автор явно пристрастен к SQL базам данных, поэтому я и пытаюсь показать примеры, где SQL сильно проигрывает.
Насколько я знаю, в большинстве коммерческих аналитических МРР-системах имеется в той или иной мере поддержка ML и предиктивной аналитики, в той же Aster или Vertica это имеется. Другое дело насколько эта поддержка удовлетворяет вашим потребностям. Например, в Vertica работа с ML по функционалу и подходу очень напоминает MadLib.
Другое дело насколько эта поддержка удовлетворяет вашим потребностям.
Вот именно поэтому я и попросил привести решение озвученный задач на любой из названных СУБД. Если вы считаете, что большинство или хотя бы какая-то одна БД позволяет сделать озвученные задачи, пожалуйста, приведите пример.
А я потом приведу пример, как это делается в Spark, хоть со встроенным MLlib, хоть с использованием сторонних библиотек и их алгоритмов. И вот тогда уже можно будет предметно обсудить, стоит ли Hadoop своей славы или нет.
Полировать — это сильно сказано. Когда мы последний раз пытались написать свой (!) ридер паркетовский файлов из HDFS с помощью Vertica UDF, внезапно оказалось, что Vertica вообще не умеет парсить бинарные данные и пытается перевести из «битой» кодировки в «нормальный UTF-8». Бинарные данные в UTF-8, ага.
Поправлю Вас. Вертика поддерживает ORC и PARQUET, пример прямо с доки:
=> CREATE EXTERNAL TABLE tableName (columns)
AS COPY FROM path ORC;
=> CREATE EXTERNAL TABLE tableName (columns)
AS COPY FROM path PARQUET;
Полностью согласен, жаль кармы для голосования нет.
Хотя основной посыл — что MapReduce подходит не для всего, и вокруг BigData много маркетинга — верен, автор не смог описать раздел между задачами, или сознательно перегибал в сторону. Статья слишком однобока.
Хотя основной посыл — что MapReduce подходит не для всего, и вокруг BigData много маркетинга — верен, автор не смог описать раздел между задачами, или сознательно перегибал в сторону. Статья слишком однобока.
Хорошая статья, спасибо! Приятно, что есть еще специалисты, способные разделять реальность и маркетинг
В целом направление мысли верное, но есть некоторые фактические ошибки:
Greenpum сделает свой аналог Flex Zone, путем слияния кода с HAWQ, либо сам станет non-HDFS частью HAWQ, в конце концов, кого-то мы потеряем — на самом деле я поднимал этот вопрос перед руководством практически сразу после форка HAWQ от GPDB, но такой цели нет. Сейчас же их ветки ушли чересчур далеко друг от друга и я не вижу возможности их слияния в будущем. Скорее GPDB расширит функционал для нативной поддержки HDFS таблиц, да и только.
В свое время я тоже писал и про Kudu, и про неструктурированные данные, и про перспективы Big Data, и про перспективы Spark. В целом же я рекомендую вам писать статьи на английском — это даст охват аудитории в 10 раз выше и возможность дискуссии с интересными специалистами (как, например, мой спор с одним из создателей Spark в комментариях к этой статье)
В целом направление мысли верное, но есть некоторые фактические ошибки:
- если, например, маперы уже прекратили свою работу, то ресурсы редьюсерам уже не освободятся — на самом деле освободятся. Даже если у вас YARN настроен на возможность выполнения только одного таска единовременно (один маппер или один редюсер), вы сможете выполнить задачу в 1000 мапперов и столько же редюсеров. Конечно, работать они при этом будут последовательно
- Spark не понимает, как данные лежат в HDFS. Это хоть и MPP-система — Spark не MPP, это тот же Batch Processing, что и MapReduce. Задача обработки данных разбивается на таски и они выполняются асинхронно, промежуточные данные сбрасываются на диск
- Spark Streaming и, возможно, это будет действительно таким «долгоиграющим» решением — Как раз у Spark Streaming наиболее сильные конкуренты — Apache Storm, Apache Heron, Apache Flink, да и та же Kafka c Kafka Streams. Конкурировать micro-batch подходу Spark Streaming с «честным» streaming в вышеназванных системах будет очень проблематично
- Impala, Drill и Kudu… это такие же МРР-движки поверх HDFS как Spark и MR — Kudu не имеет зависимости от HDFS, это как раз более быстрая замена HDFS для обработки табличных данных с поддержкой update (в отличии от HDFS). И, конечно, она не имеет отношения к MPP
- Apache HAWQ… они взяли традиционный Greenplum и натянули его на HDFS… какой-то практической целесообразности в этом мало. — по сути это ответ рынку. MPP over Hadoop востребована (посмотрите на те же Hive и Impala), вот Pivotal и выпустил этот продукт. К слову сказать, среди решений его класса он является наиболее быстрым и продвинутым в плане поддержки SQL, но как и любое связанное с Hadoop решение является сложным в сопровождении
- Появятся первые дистрибутивы CDH уже с частичным отказом от использования HDFS — уже появились, ведь Kudu — это не HDFS
Greenpum сделает свой аналог Flex Zone, путем слияния кода с HAWQ, либо сам станет non-HDFS частью HAWQ, в конце концов, кого-то мы потеряем — на самом деле я поднимал этот вопрос перед руководством практически сразу после форка HAWQ от GPDB, но такой цели нет. Сейчас же их ветки ушли чересчур далеко друг от друга и я не вижу возможности их слияния в будущем. Скорее GPDB расширит функционал для нативной поддержки HDFS таблиц, да и только.
В свое время я тоже писал и про Kudu, и про неструктурированные данные, и про перспективы Big Data, и про перспективы Spark. В целом же я рекомендую вам писать статьи на английском — это даст охват аудитории в 10 раз выше и возможность дискуссии с интересными специалистами (как, например, мой спор с одним из создателей Spark в комментариях к этой статье)
Алексей, во-первых, вам большой респект за HAWQ (активно слежу за этим проектом)
Понятие МРР я восринимаю буквально — массивно-параллельный процессинг.
Да, понятие МРР тесно закрепилось за конкретными СУБД(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 или реальными потребностями рынка?
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 или реальными потребностями рынка?
Не согласен с вами касательно MPP. Основная идея MPP как раз в том, что она массивно-параллельная, то есть много процессов параллельно выполняют одну и ту же задачу над разными данными. MapReduce и подобные подходы не являются MPP, т.к. в этих системах нет гарантии параллельного выполнения задач, это системы пакетной обработки данных. По сути это «data parallelism» против «task parallelism» — первый параллельно обрабатывает одни и те же данные набором процессоров, а второй разбивает задачу на независимые «таски» и назначает их свободным процессорам по мере их доступности и глобальных приоритетов
Про Kudu — да, прочитайте их публикацию
Лично я считаю, что популярность Hadoop обусловлена потребностью рынка и маркетингом. А когда начинается использование Hadoop, все «корпоративные» клиенты хотят иметь к нему SQL-интерфейс, при этом быстрый и с транзакциями — вот и потребность
Про Kudu — да, прочитайте их публикацию
Лично я считаю, что популярность Hadoop обусловлена потребностью рынка и маркетингом. А когда начинается использование Hadoop, все «корпоративные» клиенты хотят иметь к нему SQL-интерфейс, при этом быстрый и с транзакциями — вот и потребность
Вопрос на счет HAWQ. Где он может быть полезен если он по факту медленнее Greenplum-a. Да еще и его таблицы не совместимы с hive. Ну и GP уже давно умеет external таблицами юзать hdfs файлы, или HIVE external tables. Что уже позволяет в реальных проектах юзать выгрузку/загрузку данных между hdfs и gp.
HAWQ 2.0 нативно поддерживает чтение таблиц, объявленных в Hive Metastore, без плясок с бубном вроде внешних таблиц. А скоро будет поддерживать и их создание
Да, вы правы, GPDB уже умеет многое. В то же время HAWQ работает поверх Hadoop и интегрируется с YARN, что позволяет ему более удачно вписаться в Hadoop-кластер, а вот GPDB требует для своей работы отдельный кластер и немного другую организацию дисков
Да, вы правы, GPDB уже умеет многое. В то же время HAWQ работает поверх Hadoop и интегрируется с YARN, что позволяет ему более удачно вписаться в Hadoop-кластер, а вот GPDB требует для своей работы отдельный кластер и немного другую организацию дисков
Алексей, есть ли данные о разнице в производительности запросов на native-hawq-таблицах и hive-таблицах?
К сожалению, таких данных у меня нет. Но ожидаемо, что запросы к Hive-таблицам будут медленнее. Нативные таблицы парсятся кодом HAWQ (написанным на C), а для обращения к Hive таблицам нужно поднимать Java-десериализаторы, соответствующие формату хранения, что довольно долго.
Но Apache HAWQ — это open source, и вы свободно можете протестировать его и самостоятельно увидеть разницу в производительности
Но Apache HAWQ — это open source, и вы свободно можете протестировать его и самостоятельно увидеть разницу в производительности
И сразу же второй вопрос, а как они живут вдвоем на одном кластере? хок и хадуп? Не будет ли проблем с ресурсами. В пиковые моменты один другому не мешает? Ибо разделение на разные кластеры это вообще неплохой паттерн. А как раз другая организац\ дисков — это есть оптимизация vs универсализм.
Apache HAWQ интегрирован с YARN, то есть глобальный менеджер ресурсов в кластере будет и HAWQ не сможет забрать себе всё. Но нужно понимать, что YARN управляет только квотами на память и CPU, то есть IO может стать узким местом. Еще стоит учесть, что совмещать на одном кластере аналитические и транзакционные системы — моветон. То есть HAWQ + Sqoop + Flume + Spark будут вместе жить нормально, а вот HAWQ + HBase — уже не очень
Простите, и у вас есть неточность, как минимум,— 1.
Это не совсем так. Писать в диск промежутки на Sparke— дурной тон.
Задача обработки данных разбивается на таски и они выполняются асинхронно, промежуточные данные сбрасываются на диск
Это не совсем так. Писать в диск промежутки на Sparke— дурной тон.
Кусок слайда из курса Беркли по Spark
Советую вам ориентироваться не на презентации, а на код
Вот оригинальный комментарий из кода менеджера shuffle в Spark:
Если по коду, то здесь происходит запись на диск, которая вызывается отсюда, в свою очередь вызывается отсюда, объявляется здесь и вызывается тут. Это наиболее актуальная имплементация, т.н. Tungsten, а вот более старая
Как я и говорил, специалистов, способные разделять реальность и маркетинг, не так уж много.
И да, в презентации говорится про «storage»: они имеют в виду возможность Spark кэшировать данные, а не то, что во время shuffle он не сбрасывает данные на диск
Вот оригинальный комментарий из кода менеджера shuffle в Spark:
/**
* In sort-based shuffle, incoming records are sorted according to their target partition ids, then
* written to a single map output file. Reducers fetch contiguous regions of this file in order to
* read their portion of the map output. In cases where the map output data is too large to fit in
* memory, sorted subsets of the output can are spilled to disk and those on-disk files are merged
* to produce the final output file.
*/
Если по коду, то здесь происходит запись на диск, которая вызывается отсюда, в свою очередь вызывается отсюда, объявляется здесь и вызывается тут. Это наиболее актуальная имплементация, т.н. Tungsten, а вот более старая
Как я и говорил, специалистов, способные разделять реальность и маркетинг, не так уж много.
И да, в презентации говорится про «storage»: они имеют в виду возможность Spark кэшировать данные, а не то, что во время shuffle он не сбрасывает данные на диск
Т.е., вы хотите сказать, что, если:
— вы используете в 1строке кода transformation, в следующей строке action, то Spark запишет результат transormation на HDD, который будет использовать в action?
— нет варианта, при котором любые transformation и action не будут задействовать HDD, кроме случаев, где это явно указано в коде?
— вы используете в 1строке кода transformation, в следующей строке action, то Spark запишет результат transormation на HDD, который будет использовать в action?
— нет варианта, при котором любые transformation и action не будут задействовать HDD, кроме случаев, где это явно указано в коде?
— Нет, я так не говорю. Количество записей на диск не зависит от количества трансормаций, оно зависит от количества shuffle. Каждый раз, когда Spark производит shuffle, все данные приземляются на диск. У вас может быть одна трансформация join, которая будет исполнена в виде reduce-side join, и оба участвующих RDD будут перераспределены (shuffle) по кластеру перед join'ом. А может быть трансформация «filter», которая всегда пайплайнится с другими трансформациями, и соответственно никакого приземления данных на диск не будет
— Нет, такого варианта нет. Данные во время shuffle всегда приземляются на диск. По-другому асинхронное выполнение тасков работать и не может
— Нет, такого варианта нет. Данные во время shuffle всегда приземляются на диск. По-другому асинхронное выполнение тасков работать и не может
Столько неточностей и голословных утверждений в статье это специально чтоб было о чем похоливарить?
Круг задач решаемых с помошью MapReduce довольно широк. Намного шире задачи построения поискового индекса. Например, весь SQL можно реализовать с помошью MapReduce. Уже немало.
Неверно.
Это было про MapReduce. Какое-то голословное утверждение. Во времена, когда появился MapReduce, количество памяти в серверах было сравнительно небольшим, и для аналитики на недорогом железе не было ничего лучше.
Это точно про Spark?
Достаточная. Смотря с чем сравнивать.
Spark понимает, как данные лежат в HDFS.
Это не MPP-система
Текст, например, очень слабо структурирован.
Kudu — хранилище данных, а не МРР-движок
Неверно. Kudu вообще не использует HDFS.
Неверно. В нативном API Kudu нет SQL.
Это про Kudu, Impala и Drill. Нет. Kudu — хранилище данных, Impala и Drill МРР-движки
Еще раз повторюсь. Kudu к MPP-движкам никакого отношения не имеет.
Cloudera Hadoop Distribution
Список хипстеров прилагается — http://www.cloudera.com/customers.html
Google, а потом и Дуг сделали инструмент(и далеко не идеальный, как призналось Google, спустя несколько лет), для решения конкретного класса задач — построение поискового индекса.
Круг задач решаемых с помошью MapReduce довольно широк. Намного шире задачи построения поискового индекса. Например, весь SQL можно реализовать с помошью MapReduce. Уже немало.
Число «маперов» и «редьюсеров» постоянно во время выполнения, ресурсы делятся между этими группами процессов и если, например, маперы уже прекратили свою работу, то ресурсы редьюсерам уже не освободятся.
Неверно.
По факту инструмент для аналитики бесполезен
Это было про MapReduce. Какое-то голословное утверждение. Во времена, когда появился MapReduce, количество памяти в серверах было сравнительно небольшим, и для аналитики на недорогом железе не было ничего лучше.
Хардкод и усердный код на Java превращает простые запросы в месиво, которое невозможно будет читать в будущем.
Это точно про Spark?
Поддержка SQL пока слабая.
Достаточная. Смотря с чем сравнивать.
Spark не понимает, как данные лежат в HDFS.
Spark понимает, как данные лежат в HDFS.
Это хоть и MPP-система
Это не MPP-система
На самом деле, структура есть почти у всех данных, которые нам могут пригодиться
Текст, например, очень слабо структурирован.
Это такие же МРР-движки поверх HDFS как Spark и MR
Kudu — хранилище данных, а не МРР-движок
Kudu понимает, как лежат данные в HDFS
Неверно. Kudu вообще не использует HDFS.
Только SQL и никакого хардкода.
Неверно. В нативном API Kudu нет SQL.
Все эти 3 продукта плюс-минус примерно одинаковые
Это про Kudu, Impala и Drill. Нет. Kudu — хранилище данных, Impala и Drill МРР-движки
Apache HAWQ очень похож на Apache Kudu
Еще раз повторюсь. Kudu к MPP-движкам никакого отношения не имеет.
Cloudera Distributed Hadoop
Cloudera Hadoop Distribution
CDH можно оставить для хипстеров
Список хипстеров прилагается — http://www.cloudera.com/customers.html
Определение Big Data очень простое. Это такие данные, в отношении которых трудно представить, как делается бэкап.
Хорошая статья, спасибо автору! На самом деле так и есть, термин Big Data сильно раздут. На мой взгляд, Hadoop очень хорошо подходит для хранения старых (архивных) данных и работы с ними время от времени, так называемый Data Lake.
Системы MPP (Teradata, Vertica, Greenplum и т.д.) все-таки предназначены для хранения и обработки больших объемов данных и для использования в ежедневных процессах, например для построения отчетности, проведения анализ предметных областей, создания моделей для принятия решений. Для меня все-таки СУБД MPP и Hadoop это немного разные вещи.
Системы MPP (Teradata, Vertica, Greenplum и т.д.) все-таки предназначены для хранения и обработки больших объемов данных и для использования в ежедневных процессах, например для построения отчетности, проведения анализ предметных областей, создания моделей для принятия решений. Для меня все-таки СУБД MPP и Hadoop это немного разные вещи.
Очень жду возможности репликации из хадупа в MPP субд.
А расскажите, пожалуйста, зачем?
сейчас дефакто стандарт в аналитике — MPP аналитическая субд (terradata, greenplum, exadata, vertica etc) на которую смотрят аналитики и bi системы, поверх хадупа для хранения грязного стейджинга.
И приходится гонять террабайты данных из хадупа в субд всякими обходными маневрами. Для реляционных источников всегда рулила и сейчас рулит репликация — как самый удобный и быстрый способ получения данных в нашу MPP систему.
И приходится гонять террабайты данных из хадупа в субд всякими обходными маневрами. Для реляционных источников всегда рулила и сейчас рулит репликация — как самый удобный и быстрый способ получения данных в нашу MPP систему.
Хорошая статья!
Интересная статья «против тренда».
Примечательно, что «родоначальники» всего этого зоопарка (Google) давно уже тихонько отошли от дел и спокойно пилят свои уникальные БД (как транзакционные, так и аналитические) и файловые системы (Фейсбук пошел еще дальше и запилил свою файловую систему только для картинок), а остальные этого просто не замечают.
Примечательно, что в «хороших» университетах (из Ivy League, например) в серьезный академический оборот попал только Spark, при чем без привязки к Hadoop.
Но Big Data рынок это такая себе система с обратной связью: по итогам 2015 года, «Big Data специалисты» получали в США практически больше всех (уступив только DevOps) и это позволяет им зарабатывать, по сути, легкие деньги, и они, не желая терять такую жизнь, подключаются к маркетингу компаний, рассказывая на каждом углу каждому встречному, как они решают «Big Data проблемы» и рубят бабло, создают кучу персональных блогов и книжек и, как итог, привлекают еще больше внимания и ажиотажа.
На фоне всего этого удивляет, что такие вещи как графовые базы данных (которые уже начал использовать Амазон, к примеру), проходят мимо рынка.
P.S. На самом деле весь этот зоопарк выстрелил по 1-й простой причине: возможность запускать любой рандомный код (на Python, Java, Scala) для анализа данных.
Примечательно, что «родоначальники» всего этого зоопарка (Google) давно уже тихонько отошли от дел и спокойно пилят свои уникальные БД (как транзакционные, так и аналитические) и файловые системы (Фейсбук пошел еще дальше и запилил свою файловую систему только для картинок), а остальные этого просто не замечают.
Примечательно, что в «хороших» университетах (из Ivy League, например) в серьезный академический оборот попал только Spark, при чем без привязки к Hadoop.
Но Big Data рынок это такая себе система с обратной связью: по итогам 2015 года, «Big Data специалисты» получали в США практически больше всех (уступив только DevOps) и это позволяет им зарабатывать, по сути, легкие деньги, и они, не желая терять такую жизнь, подключаются к маркетингу компаний, рассказывая на каждом углу каждому встречному, как они решают «Big Data проблемы» и рубят бабло, создают кучу персональных блогов и книжек и, как итог, привлекают еще больше внимания и ажиотажа.
На фоне всего этого удивляет, что такие вещи как графовые базы данных (которые уже начал использовать Амазон, к примеру), проходят мимо рынка.
P.S. На самом деле весь этот зоопарк выстрелил по 1-й простой причине: возможность запускать любой рандомный код (на Python, Java, Scala) для анализа данных.
Статья вполне в тему кстати. Вчера был на OSP форуме по BigData. Не смотря на тучу клевых технологий и очень интересной информации, из выступающих только двое докладчиков назвали объемы своих «BigData» в проде. У СБ Контура в HBase 1 тб, а у классического OLTP на базе Ред БД у приставов крутится ряд БД, соединенных обычным App сервером под 100 тб. Из личного опыта так же — у нас на вполне себе обычной релляционной Vertica крутятся базы по 75 тб и у моих друзей в Штатах и более объемом на Терадате, а мне каждый раз с секретным видом сообщают о том, что на очередном NoSQL или Hadoop у кого то есть база аж 20-30 тб :) Кстати помимо распределенности, аналитических функций и прочих очень полезных мегавещей есть один больной нюанс, о котором забывают любители новых технологий. Это тупо оптимизация и администрирование сверх больших объемов данных. На Вертике, ГП или Терадате выглядит все это вполне себе культурненько, а про HDFS и NoSQL столько чудесных историй слышал при больших объемах, так сказать «нюансы» :)
P.S. Кстати потопчусь по графовым базам, вспоминая опять же вчерашний форум по Бигдате. Есть круг применения у них клевый, но аналитика упаси господь в этот круг не входит. Показали мне вчера на презе по OrientDB как круто в него CDR можно грузить и быстро по абоненту находить его номера, используемые БС и звонки. Запустил я в голове простой запрос за полгода выдать всех абонентов, у которых ежедневно звонков выходило менее, чем на 2 минуты, пробежался по графам БД презы и завис… пробежать все это по графам жесть жестяная, а строить на каждый чих рассчитываемую витрину, это места на дисках не напасешься и скорости записи потеряешь. Как бы в таблицах CDR в сутки у не слишком большого оператора лямов 200 записей прибывает минимум, за полгода для рангового анализа объемы неплохие так получаются.
P.S. Кстати потопчусь по графовым базам, вспоминая опять же вчерашний форум по Бигдате. Есть круг применения у них клевый, но аналитика упаси господь в этот круг не входит. Показали мне вчера на презе по OrientDB как круто в него CDR можно грузить и быстро по абоненту находить его номера, используемые БС и звонки. Запустил я в голове простой запрос за полгода выдать всех абонентов, у которых ежедневно звонков выходило менее, чем на 2 минуты, пробежался по графам БД презы и завис… пробежать все это по графам жесть жестяная, а строить на каждый чих рассчитываемую витрину, это места на дисках не напасешься и скорости записи потеряешь. Как бы в таблицах CDR в сутки у не слишком большого оператора лямов 200 записей прибывает минимум, за полгода для рангового анализа объемы неплохие так получаются.
А что скажете про Apache Ignite?
Есть интеграция со Spark & Hadoop.
Есть SQL поверх NoSql данных.
Есть IGFS — in-memory реализация HDFS, которая может как сама по себе работать, так и проксировать / кешировать HDFS.
Ну и MapReduce тоже есть и всякое еще сверху.
Есть интеграция со Spark & Hadoop.
Есть SQL поверх NoSql данных.
Есть IGFS — in-memory реализация HDFS, которая может как сама по себе работать, так и проксировать / кешировать HDFS.
Ну и MapReduce тоже есть и всякое еще сверху.
2015 год, Дэн, 25 лет: я кошу траву молотком… каждый день. Это немного сложно, но мне, черт возьми, нравится, мне нравится работать руками!
Офигено смешная шутка завтра переведу индюкам из нашего тима — интересно поймут всю глубину иронии… Автор, Вы шутку сами придумали или подсмотрели у кого-то?
Spark— это не только Java и Scala, но и Python и R. Тут даже Java лишняя становится, в последнее время тренд на «продакшн» код на Scala, EDA—Scala, Python, очень экзотично пока на R.
Интересно почему решения типа BigQuery или RedShift отнесены к небольшим компаниям или стартапам? Мы как раз небольшая компания с фокусом на аналитике данных. Используем BigQuery, хотим перейти на RedShift.
Когда и почему мы должны задуматься над уходом в Enterprise решения, типа Teradata?
Когда и почему мы должны задуматься над уходом в Enterprise решения, типа Teradata?
Возможно и никогда. Если вас всё устраивает по цене и производительности, то не надо уходить с облака.
Считайте и исследуйте этот вопрос самостоятельно. Если вы аналитическая компания, то для вас данные — это ваш хлеб. Я просто не могу дать вам совет в стиле «Если вы перевалите за XX ТБ — срочно переходите на Y». Очень много зависит от вашей специфики.
Опять же, крупные банки, фин. организации и т.д. врядли будут доверять свои данные левым компаниям, при том, что выигрыша по цене может даже и не быть, либо он будет минимальным — надо считать.
Считайте и исследуйте этот вопрос самостоятельно. Если вы аналитическая компания, то для вас данные — это ваш хлеб. Я просто не могу дать вам совет в стиле «Если вы перевалите за XX ТБ — срочно переходите на Y». Очень много зависит от вашей специфики.
Опять же, крупные банки, фин. организации и т.д. врядли будут доверять свои данные левым компаниям, при том, что выигрыша по цене может даже и не быть, либо он будет минимальным — надо считать.
Одна из причин, чтобы уйти как минимум от Google BigQuery — это нестабильность платформы. Когда компания продает аналитику, то BigQuery становится mission critical частью ее архитектуры. Инструмент BigQuery еще неизвестно когда выйдет в стабильный режим работы, и получается что вчера отчеты считались быстро и правильно, а сегодня медленно и неправильно. Ребята из BQ вообще любят смелые эксперименты на Production.
В этом плане RedShift вызывает больше доверия, поскольку у пользователя остается больше контроля над средой. С другой стороны и трудоемкость поддержки пропорционально растет.
В этом плане RedShift вызывает больше доверия, поскольку у пользователя остается больше контроля над средой. С другой стороны и трудоемкость поддержки пропорционально растет.
под YAM подразумевается YAML?
Очень интересно узнать мнение автора или другого компетентного человека спустя 6.5 лет после написания этой статьи.
Как я себе вижу ситуацию, вопреки прогнозу автора, хадуп не только не умер, но и вполне себе неплохо живёт.
Sign up to leave a comment.
Big Data головного мозга