ну это речь про батч-процессинг, в то время как современная аналитика движется к риалтайм, сейчас модно доставлять в dwh горячие данные через какую-нибудь kafka. сколько будет стоить spark streaming job? подозреваю мого дороже.
по кластерам редшифт не понятно, что значит убивать? а данные куда? если на S3 устроить datalake, а в redshift держать витрины для BI, убивать не получиться и снова возвращаемся к цене.
имхо облачные базы очень дорого и могут окупиться лишь в штатах и совсем западной европе, где персонал стоит по $200к в год. я больше про гугло-клауд знаю, у гугла bigtable. неадекватно дорого. про редшифт почти ничего не знаю, но пошел в их калькулятор, ткнул 3 ноды ds2.8xlarge/16Tb (т.е. hdd и примерно столько же ядер, как у у меня в спарке было). ценник $20,000 в месяц. за деньги какие эти три ноды за три года скушают в наших широтах можно десятки нод хадупа держать и кормить двух админов, которые 24 часа будут вокруг кластера скакать.
у гугла можно просто хадуп арендовать, свалив на него администрирование. но на мой вкус тоже сильно дороже выходит. у accenture есть документ со сравнением vs bare metal www.accenture.com/t00010101T000000__w__/jp-ja/_acnmedia/Accenture/Conversion-Assets/DotCom/Documents/Local/ja-jp/PDF_2/Accenture-Cloud-Based-Hadoop-Deployments-Benefits-and-Considerations.pdf
они подогнали равенство с bare metal за счет расхода на персонал, тогда как расходы на железо в 5 раз дороже, сторидж в двое. у нас к примеру кластер на порядок крупней, а обслуживающий персонал 1.5 человека с далеко не американскими зарплатами. это имеет смысл в штатах, где спец непомерно дорого стоит.
Например, если покупаем 5 серверов с 40 процессорными ядрами и 256 ГБ RAM, то и у облачного провайдера запрашиваем аналогичные ресурсы (40*5=200 vCPU + 256*5=1280 ГБ vRAM)
это как у вас вышло 5*40 полновесных ядер = 200 vCPU !? vCPU у амазона и гугла это hardware thread, а не то что вы подумали.
ну да, клеить лейблы на чужие технологии это путь к успеху. главное, что бы клиент понимал, на кой ему платить за CDH ораклу, а не получить все что там под капотом мимо оракла.
параллелить standard ничего не умеет, но лицензировать требует каждое ядрышко. один сокет и 22 ядра вытянут на $80+ тысяч за лицензии. и за эти деньги будет тошнить в одном потоке в сотни раз уступая импале. в чем смысл?
я не вижу смысла вкладывать в технологии, которые не способны и десятой доли ресурсов односокетного сервера воспользоваться
т.е. абсолютно та же ситуация — банальный хеш джоин будет в один поток 60 гб читать долгими минутами, а лицензировать на EE нет никакого смысла из-за цены.
Vertica мне не интересна. совсем. платить за каждый ТБ в эпоху 16Тб дисков глупо.
Hive-on-Spark в CDH не поддерживает spark 2.х в принципе, с коробкой или без там лишь spark 1.6, со всеми вытекающими, т.е. все ваши фантазии мимо. Thrift клоудера тоже не поддерживает и очень не рекомендует ставить. но это все не важно, как бы ты не запускал, это лишь обвязки вокруг spark-submit. я тоже запускал через свою rest обвязку.
я сравниваю то что стоит сравнивать. в DWH и аналитике хадупы заменяют оракл, конкретно в моем проекте и миллионе соседних.
говоришь несопоставимые мощности. а что бы дали 56 ядер Standard edition? Standard ничерта в параллель делать не умеет, сколько ему не выдели 1,5-2 ядра от силы будет занято. даже если был EE пришлось бы нарезать туеву кучу партиций, что бы загрузить хотя бы треть от тех 56 ядер. но никто на такие объемы не стал бы лицензировать 56 ядер, потому что цена.
и да, spark-submit для sql это не просто серьезно, это в принципе единсвенный для спарка вариант. все остальное лишь обвязка вокруг spark-submit, причем в случае с клоудерой единственный вариант. там ни hive на spark2 не переключить, ни утилиты spark-sql.
хм, надо будет почитать про ORC, думал это концептуально тот же паркет, просто от hortonworks.
по поводу транзакций, на мой вкус в DWH и аналитике снепшоты hdfs даже удобней транзакций. у нас когда приходит батч, на hdfs создается снепшот и перестраивается витрина построенная на parquet файликах. те кто стартанули расчет/запрос работают со старым снепшотом, те кто стартанули позже, работают с новым. а в оракле все равно транзакции на таких задачах бесполезны, ты вынужден коммитить каждые 100500 строк при закачке батча. а раз комитишь, соответсвенно и консистентность идет мимо. плюс если что-то поло не так, у тебя пол батча в базе.
Я тот, кто с грустью наблюдает закат технологии, вызванный одной лишь жадностью. Оракловые кластера по адекватным ценам могли бы безраздельно править хоть в DWH, хоть в OLTP. Oracle rac это индексы, транзакции, консистетность, при этом масштабируемость на десяток узлов, ну где такое еще дают? но цена… что толку от всего этого если 24 ядра экзадаты с железом тысяч на $40 уже тянет на миллион с лицензиями?
Бизнес кейс не суть важно, это хадуп, который читает файлы данных таблиц целиком. т.е. совершенно не важно, что у вас там за структуры и насколько сложные связи. все равно хадуп будет читать все, поэтому была бы это схема зведа с 60 гб фактов и гиганскими измерениями или что-то другое, как у меня, все равно ответ будет примерно в то же время
хм… а у вас почему спарк2 использует hive/мап-редюс? спарк вроде как позиционируют как замену мап-редюса, а sql запросы по мета-таблицам hive спарк и без hive энжина может.
ну и если развернута импала которая дала «ощутимый прирост производительности», почему hive, а не импала?
главная фишка зепелин — он работает с хадупом через spark, суперсет судя по описанию просто еще один визуализатор sql, поддержка hive или спарк даже не заявлена.
а кому нибудь из вас удалось переключить hive на spark2 и как-то подключить внешних клиентов? thirft клоудера похоже не любит.
и есть задачи на импалу? что-то при хорошей нагрузке выглядит что на импалу положиться нельзя.
еще интересно как на spark джобы запускаете? spark-job server, livy?
в чем прикол в 2018 печатать перевод книги 2014 года по технологии, где раз в 1.5 года меняется вообще все? с тех пор в спарке было пара огромных релиза все поменялось. JavaRDD деприкейтед давно.
единственный плюс одна из немногих, где хоть что-то сложнее word count дают
на самом деле оракл еще с глубокой древности имел возможность поднимать несколько процессов пишущих в REDO лог. то была фича когда еще была распространена NUMA архитектура и предлагали на каждой партиции NUMA свой процесс писанинины в лог поднимать. другое дело что особо смысла это не имеет, т.к. нормально настроенный REDO запросто на hdd успевает писать десятки миллионов транзакций однопоточно. в тестах tpc.org и поболее есть тесты, при этом один процесс и hdd справляются.
в навороченных схд несколько уровней кеширования. «горячие» блоки гуляют по ssd и прочим кешам. поэтому скорость чтения датафайла утром и ночью запросто различаются на порядок.
по кластерам редшифт не понятно, что значит убивать? а данные куда? если на S3 устроить datalake, а в redshift держать витрины для BI, убивать не получиться и снова возвращаемся к цене.
у гугла можно просто хадуп арендовать, свалив на него администрирование. но на мой вкус тоже сильно дороже выходит. у accenture есть документ со сравнением vs bare metal
www.accenture.com/t00010101T000000__w__/jp-ja/_acnmedia/Accenture/Conversion-Assets/DotCom/Documents/Local/ja-jp/PDF_2/Accenture-Cloud-Based-Hadoop-Deployments-Benefits-and-Considerations.pdf
они подогнали равенство с bare metal за счет расхода на персонал, тогда как расходы на железо в 5 раз дороже, сторидж в двое. у нас к примеру кластер на порядок крупней, а обслуживающий персонал 1.5 человека с далеко не американскими зарплатами. это имеет смысл в штатах, где спец непомерно дорого стоит.
это как у вас вышло 5*40 полновесных ядер = 200 vCPU !? vCPU у амазона и гугла это hardware thread, а не то что вы подумали.
я не вижу смысла вкладывать в технологии, которые не способны и десятой доли ресурсов односокетного сервера воспользоваться
docs.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2016?view=sql-server-2017
т.е. абсолютно та же ситуация — банальный хеш джоин будет в один поток 60 гб читать долгими минутами, а лицензировать на EE нет никакого смысла из-за цены.
Hive-on-Spark в CDH не поддерживает spark 2.х в принципе, с коробкой или без там лишь spark 1.6, со всеми вытекающими, т.е. все ваши фантазии мимо. Thrift клоудера тоже не поддерживает и очень не рекомендует ставить. но это все не важно, как бы ты не запускал, это лишь обвязки вокруг spark-submit. я тоже запускал через свою rest обвязку.
говоришь несопоставимые мощности. а что бы дали 56 ядер Standard edition? Standard ничерта в параллель делать не умеет, сколько ему не выдели 1,5-2 ядра от силы будет занято. даже если был EE пришлось бы нарезать туеву кучу партиций, что бы загрузить хотя бы треть от тех 56 ядер. но никто на такие объемы не стал бы лицензировать 56 ядер, потому что цена.
и да, spark-submit для sql это не просто серьезно, это в принципе единсвенный для спарка вариант. все остальное лишь обвязка вокруг spark-submit, причем в случае с клоудерой единственный вариант. там ни hive на spark2 не переключить, ни утилиты spark-sql.
по поводу транзакций, на мой вкус в DWH и аналитике снепшоты hdfs даже удобней транзакций. у нас когда приходит батч, на hdfs создается снепшот и перестраивается витрина построенная на parquet файликах. те кто стартанули расчет/запрос работают со старым снепшотом, те кто стартанули позже, работают с новым. а в оракле все равно транзакции на таких задачах бесполезны, ты вынужден коммитить каждые 100500 строк при закачке батча. а раз комитишь, соответсвенно и консистентность идет мимо. плюс если что-то поло не так, у тебя пол батча в базе.
Бизнес кейс не суть важно, это хадуп, который читает файлы данных таблиц целиком. т.е. совершенно не важно, что у вас там за структуры и насколько сложные связи. все равно хадуп будет читать все, поэтому была бы это схема зведа с 60 гб фактов и гиганскими измерениями или что-то другое, как у меня, все равно ответ будет примерно в то же время
ну и если развернута импала которая дала «ощутимый прирост производительности», почему hive, а не импала?
и есть задачи на импалу? что-то при хорошей нагрузке выглядит что на импалу положиться нельзя.
еще интересно как на spark джобы запускаете? spark-job server, livy?
единственный плюс одна из немногих, где хоть что-то сложнее word count дают