Alexander Ryndin1) Там Cloudera Data Hub Edition входит в поставкуНу у хадупа три основных вендора mapr cloudera hortonworks и все они любезно помогут все установить и настроить за денюжку на кластере заказчика.
Alexander Ryndin2) Если брать сравнимое железо от других вендоров (ну т.е. не на горбушке россыпью), то цена будет сравнимаЕсть прямо противоположное мнение, что экономия огромна. Но конкретные цифры вряд ли кто-то в открытый доступ вывалит.
Alexander Ryndin3) Oracle Big Data Appliance обычно берут, когда Hadoop становится достаточно критичным для бизнесаА изолированный хадуп - это просто поиграться? :)
Alexander Ryndin4) У Oracle на данный момент лучший ПАК для Big Data (по оценке Forrester)Что мы имеем по факту
full complement of software components, including Cloudera Enterprise Data Hub Edition, Oracle NoSQL Database CE, Oracle R Distribution, Oracle Linux, Oracle Data Integrator, Oracle Loader for Hadoop, Oracle R Advanced Analytics for Hadoop, and Oracle Spatial and Graph
* Oracle R это, конечно, хорошо. Только пожалуй R во всем хуже python кроме того, что на нем реализован ряд экслюзивных алгоритмов (которые потихоньку портируются).
Динамика достаточно красноречива ( https://stackoverflow.blog/2017/09/06/incredible-growth-python/).
Речь про цивилизованный мир (high-income countries).

* Oracle Data Integrator... вполне понятно, что Оракл пытается это продвигать. Но для загрузки/выгрузки каждый использует то, что знает лучше или вообще пишет свой велосипед.
* Для Spatial and Graph есть opensource аналоги, то есть здесь тоже должен быть очень важный аргумент, чтоб использовать Оракловое - например наличие уже ораклового решения которое частично выносится в хадуп. :)
В сухом остатке Оракл может и засунул в коробку больше чем кто либо, вот только не очень понятно для кого это всё.

DВАOracle Big Data Appliance является превосходным выбором для клиентов, которые хотят работать с полным комплексом передовых Hadoop-технологий ClouderaЭто не отвечает на вопрос зачем вообще хадуп если есть такая железка с Ораклом.
Можно перечислить достаточно экзотические причины чтоб обосновать своё хотение работать с хадуп в таком случае
1.
Задействовать уже реализованные фреймфорки из хадупа для работы, скажем, с графами или анализа данных.
Ну или просто писать свою логику на Spark для параллельной обработки (которая на SQL не реализуема).
2.
Использовать особенности HDFS и хранения данных.
2.1 Воспользоваться тем, что хадуп позволяет анализировать данные в любом формате и даже натягивать таблицы на данные в любом формате (писать свои писать свои Serializer/Deserializer если не хватает имеющихся)
В Оракле тоже можно пытаться натянуть external table на что угодно, но это что угодно надо сначала размазать по узлам, чтоб обработка была распараллелена по аналогии с хадупом.
2.2 Имеюся ну просто огромные объемы и имеет смысл секционировать более чем по 2-м уровням.
При этом каждая под-под-под-секция будет реплицирована по узлам, хоть и представляет собо логически один файл.
В Оракле же секция (или под-секция) это сегмент, который хранится... или в экзадате можно сегмент размазать по разным нодам и читать и обрабатывать его во много потоков?
И главное помнить, что вся эта супер-пупер параллельность в хадупе реализована в ущерб транзакционности.

Это, как уже было замечено, достаточно экзотические случаи, где Оракл собсветнно и не конкурент.

Если же говорить о типичном пусть даже очень большом хранилище, то необходимость хадупа при наличии экзадаты очень сомнительна.
Хотя тут Оракл уступает нескольким конкурентам из-за отсутсвия true columnar формата.
(in-memory columnar 12c только в памяти, а hybrid columnar compression это костыль)

Alexander Ryndin,

Аргументы понятны.
Пользуясь случаем, интересно, есть успешные внедрения скрещивания GoldenGate + Kafka?

Bobby Z.dbms_photoshopУже есть SQL engines
Spark SQL
Impala
Hive
Tez
... что еще портировать?
Всё перечисленное как-то неудобно называть SQL engines в контексте Oracle, MSSQL, DB2 и даже Postgres. :) Ну, примерно, как называть Запорожец или Москвич "тоже автомобиль" в одном ряду с Тесла и МБ, указывая на наличие четырёх колёс, двигателя, трансмиссии, педалей, руля и способности самостоятельно передвигаться с места на место.Вместо своих субъективных ощущений про удобство и взятых с потолка сравнениях лучше говорить конкретно.
Если ты почитал презенташки и приобрел некоторое впечатление - для тебя оно может и ценно, а для других никакого смысла не несет.
Я за последние пару лет реализовал достаточно много ETL на Hive, Spark, Impala и могу сказать, что базовые возможности SQL весьма неплохо реализованы, а главное разработчик волен дополить трансформацию или даже синтаксическую конструкцию если очень захочется.
Bobby Z.Ну и потом, по факту, Tez - вообще не про SQLTez это фреймворк для выполнения DAG, SQL порождает DAG.
DAG можно рассматривать как аналогию плана для запросов в Оракле.
Тут ( 20997214 ) я расписывал немного для старта, но ты конечно все это знаешь.
Bobby Z.Hive не понимает SQL, а понимает его ограниченное подмножество под названием HiveQL, Spark SQL тоже весьма убогОчередное бла бла.
Приведи конкретную бизнес задачу, где ты столкнулся с убогостью SQL в хадуп.
Bobby Z.сам Spark имеет весьма специфические ограничения по объемам данных.Почитай про driver-memory, executor-memory и прочее. Глядишь изменится картина про "специфические ограничения".
Bobby Z. По факту, из open source SQL on Hadoop на текущий момент есть Hive (и поверх него накрученные всякие примочки), есть Impala у Cloudera (неуправляемая, потому что не интегрирована с YARN) и есть HAWQ/HDB у Hortonworks; и Hive, даже с LLAP, по сравнению с HAWQ - см. выше про "тоже автомобиль", да и Impala ему тоже почти везде проигрывает. Хотя у Hive и Impala/HAWQ разные области применения и они вполне могут сосуществовать.Управляемость и стабильность Импалы можно заметно повысить ( 20818945 ).
Bobby Z.Но главное, на самом деле, то, что SQL, в любой реализации - не родной для Hadoop и никогда не будет столь же эффективен, как в системах, под него специально заточенных. Стоунбрэкер об этом писал уже давно, особо добавить с тех пор так и нечего. Просто очень хочется выкинуть дорогой Оракл|DB2|Netezza|Teradata|[...] и заменить на "дешёвый" Hadoop и чтоб при этом и функционал остался весь и SLA чтоб выполнялись как раньше и расходы на персонал обслуживающий чтоб сократить раз в несколько... Ну и, разумеется, срабатывает эффект молотка в руке.Оракл - RDBMS, Hadoop - платформа для распределенной обработки данных, поддерживающая несколько движков для выполнения SQL и несколько синтаксисов.
О каком родстве речь?
Ты же в курсе что такое "уровень абстракции"?

PS. Вообще про движки уже тоже подробно рассписывал ( 20588925 ).

Bobby Z.dbms_photoshopО каком родстве речь?См. выше реальный бизнес кейс. Уровень абстракции самый высокий: и там и там SQL, значит одно можно прозрачно заменить на другое, возражения не принимаются - деньги уже получены и потрачены. И вообще, ты (я) просто убеждённый ораклоид и консерватор, сопротивляешься всему новому. =)Предлагаю вернуться к тому, с чего продложился диалог.
dbms_photoshopBobby Z.Наваять такой SQL engine в open source с нуля проблематично, но можно попытаться портировать что-то уже работающее и проверенное временемУже есть SQL enginesЯ это понял как портировать SQL движок, а не приложение.
Итак, когда идет речь про обработку на SQL есть синтаксис (диалект) SQL поддерживаемый конкретной реализацией и есть движок , собственно выполняющий запросы.

Есть стандарт SQL, есть его реализации для конкретных СУБД.
Возьмем Оракл, тут помимо стандарта добавлено connect by, model, pattern matching .
Возьмем MSSQL... а тут ничего нового не добавлено, есть только вольности в реализации описанного.

Возьмем SQL (Impala), тут есть все, что в стандарте включая соединения, подзапросы, агрегатные и аналитические функции, в Hive есть grouping sets (в Impala это вопрос времени), собственно чего нет из стандарта - это recursive CTE, но вряд ли вменяемый архитектор будет это считать принципиальным ограничением - это раз и recursive CTE имеет крайне мало смысла при отсутствии индексов - это два (так что я и не жду его появления в обозримой перспективе).

Если углубляться в тонкости, в Impala сильно ограничены возможности указания windowing_clause в аналитических функциях. Конкретный пример был в Пятничная задачка. Смотрим назад. . Но если воспользоваться вспомогательной структурой - очередью, то не SQL решение опередит аналитику (для Оракла реализация 20559260 , для Спарк было в моей изысканной дискуссии с Yo - 20829512 ).

Но говоря про тонкости использования windowing_clause стоит заметить что в том же MSSQL оно крайне кастрировано по сравнению с Ораклом, а во-вторых в масштабном проекте на Орале где я работал до hadoop были десятки или сотни мест где используеются аналитические функции и только два (!) места где было специфическое windowing_clause. То есть это тоже не та функциональность, которая критична для типичного хранилища.

Я могу продолжать, хотя, вряд ли, кто-то будет в это глубоко вникать, но по факту нельзя сказать что синтаксис SQL диалектов для hadoop как-то уступает в возможностях тому же MSSQL. В сравнении с Ораклом отсутствует выделенное выше курсивом, но это экзотика и для типичного ETL не нужно, а для работы с иерахиями, spreadsheet calculations и pattern matching просто используются не SQL подходы и всё.

Возвращаясь к движкам, сама мысль портировать execution engine работающий на одном экземпляре для работы на кластере абсурдна, у них принципиально разная архитектура.

Теперь перейдем к твоему бизнес кейсу
Bobby Z.вынести очень сложную гибридную систему из Exadata и занести её в Hadoop, сохранив весь функционал и SLA и допилив ещё сверху всякий machine learningВот тут надо желающим выноса донести прежде всего, что
1) в hadoop данные immutable by design. То есть никаких update/delete.
2) система не транзакционна
3) подходит для крупных batch processing, если много мелких транзакций, то все быстро ляжет
* пытливые умы могут быстро нагуглить Hive Transactions и Hive DML - но это все баловство ни о чем.
Так вот, если три описанных фактора не критичны, то можно говорить о возможности и/или целесообразности миграции дальше.
А ограничения SQL - это несерьезно.

Bobby Z.dbms_photoshopВсё пропущено, всё так, а даже если не всё так, то лень спорить.

Возвращаясь к движкам, сама мысль портировать execution engine работающий на одном экземпляре для работы на кластере абсурдна, у них принципиально разная архитектура.Это ты про что? Если про HAWQ, то это Greenplum, который вполне себе MPP. И архитектура вовсе не столь уж принципиально разная: достаточно посмотреть на один экземпляр, как на вырожденный кластер из одного узла с отключенными механизмами, необходимыми для работы невырожденного кластера, и окажется, что архитектура практически ничем не отличается.Я как-то пропустил мысль, что ты говоришь про портирование движка именно MPP.
Impala разрабатывалась изначально с учетом особенностей HDFS, а HAWK может представлять собой порт с учетом этой специфики (то есть изначально Greenplum проектировался с кардинально иным подходом к data distribution).
Поживем увидим, конкуренция между Cloudera Impala или Hortonworks HAWQ - это хорошо, имхо.