Так-то калькуляторы «введи сколько и каких инстансов, сколько какого трафика и т.п.» у всяких AWS есть.
Не так-то просто решить, что туда вводить…
но проще чем онпермис лицензии посчитать. попробуй посчитать онпермис лицензии оракла, там то калькулятора нет, а нюансов только по субд больше чем во всех сервисах облака.
я два раза указал, что Impala Daemon Executors mem_limit итак уже поднят до 80Gb и лимит на запрос 64G. этого совершенно достаточно, что бы сделать выводы. нехватало бы памяти на узле, была бы соответствующая ошибка, а так хорошо видно что executor свои 80G получает, но не способен их грамотно распределить между конкурирующими запросами.
если уж так приспичило, на каждом узе по 128G памяти, 20 ядер. совершенно нормальные узлы, на которых и так уже большая часть ресурсов выделена Импале, которая ничего сложного и не делает. все тяжелые ETL / скоринги делает map-reduce и спарк.
вы там периферии дикие. лицензирование оракла в облаке ничем не отличается от своей железке. в облако для того и идут, что бы ораклу не платить миллионы, а юзать SaaS базы и сервисы, ценник на который заметно гуманней.
у нас теперь некая CAB session prioritizton хождение с заказами остановила. стало очень удобно отмазываться — CAB не приоритизировал, не можем взять в спринт.
кантора здоровая, фин услуги в европе, 24 страны, оборот под млрд евро.
особенности договорных отношений материнской компании и Cloudera (извините, без подробностей). Но для кейсов использования Hadoop в нашем случае support и не требуется.
так дело не в супорте, а доступе бинарникам, патчам. ну ясно, на 5.х какие-то договоры есть.
насколько снизилась нагрузка от «бизнеса»? Пока звучит как предпосылки для реализации, которая случилась недавно. Искренне интересен результат (может мы не так своих вовлекаем?).
тут особо рассказать не могу, мы данные процессим, а BI — отдельное царство куда у нас и доступа нет. на их страничке видно что что-то запустили, 150 юзеров лицензировано, подозреваю многие счастливы просто потому что альтернатива ждать когда кто-то наверху приоритизирует запрос на отчетик.
а так хоть что-то сами накликать могут.
если бы Yota была полностью независимой компанией, то конечно смысла нет — Вы правы. Но в материнской компании увидели риски.
не догоняю, в чем может быть преимущество 5.х без супорта над 6.3 без супорта?
круто, если у Вас так (подробнее расскажете?). Нам все равно приходиться делать все сложные визуализации самим.
я относительно далек от BI, но видел внутренние презентации. сложные визуализации делают на qlik, но замахались и в дополнение купили BO. презентовали, как тулзу подходящую продвинутым бизнес пользователям, которым будет быстрее (и дешевле) простые отчеты самим рисовать. показывали иерархическую структуру из нашей основной витрины, от туда можно было брать колонки и накидывать в пивот, BO сам догадывался как там чего заджоинить. простенькие графики / пирожки показывали. с виду выглядело много примитивней, чем у powerbi и соответственно много проще для бизнес пользователя.
со стороны не выглядело как легаси. выглядело как более простенький тул, с которым у бизнес пользователя есть шанс справится без программиста
не понял акробатику с cloudera, какой смысл с 6.3 переезжать на 5.x? закрыли доступ к бинарникам они в на 6.3, если 6.3 успели скачать, зачем переезжать?
161 Тб в вертике, это же наверно миллионы $$$ в год. я угадал?
и еще, у на BO внедряли именно под соусом self BI, только он позволял пользователю самому рисовать отчеты какие надо
если бы я путал, то рестарт запроса не помогал бы. лимит тут не причем, на свободном кластере запрос проходит. когда запрос упирается в лимит демона, на демоне вообще ничего не стартует. при срабатывании лимита демона ошибку кидает координатор, что-то типа такого:
Memory limit exceeded: Query a34a9afbf1a71fb1:85f3fbd100000000 could not start because the backend Impala daemon is over its memory limit
в моем же случае демон запрос пропустил и начал исполнять, в первую очередь потому что запрос проходит по всем лимитам. и по общему на запрос (в моем случае его не было) и по лимиту на демоне. демон начал исполнять, но заранее не зарезервировал достаточно памяти, потому свалился до достижении лимита демона.
можете пояснить, что значит «Memory left in process limit: 9.51 GB» в моем логе?
мне не понятно зачем трогать лимит, если он и близко не превышен? Impala Daemon Executors mem_limit итак уже поднят до 80Gb, причем таких узлов 10. 800G — этого хватает одному такому запросу, если никто крупный параллельно не исполняется. значит в целом на кластере хватает и памяти и лимитов.
хабр дурковатая платформа, одним комментарием в день лимитирует.
Impala Daemon десять штук, Impala Daemon Executors mem_limit 80Gb, не понятно почему вы на этот запрос грешите, вроде очевидно Admission Control толком не работает: лимит 64, выбрано 51.78, в логе он откровенно пишет: Memory left in process limit: 9.51 GB
значит проблема не в лимите запроса, а том что Executor не может выделить запросу 32.00 KB. по мне так очевидно, что параллельные запросы тоже потребляют память на узле и все скопом не уместились, а Admission Control похоже не угадывает сколько запросу на этом узле следовало бы зарезервировать памяти, увеличивает резервацию по ходу выполнения.
ну не знаю, десяток узлов с импалой 3.2, Enable Impala Admission Control галочка стоит, mem_limit стоит и для Impala Daemon Coordinators и для Impala Daemon Executors (30 и 80Gb сотетсвенно), scratch_dirs настроены.
типичная ошибка Memory limit exceeded: Failed to allocate row batch
EXCHANGE_NODE (id=5) could not allocate 32.00 KB without exceeding limit.
Error occurred on backend host010.domain.net:22000
Memory left in process limit: 9.51 GB
Query(3d4641a8c316a52d:f17a2b7100000000): Reservation=51.78 GB ReservationLimit=64.00 GB OtherMemory=22.00 MB Total=51.80 GB Peak=51.80 GB
Fragment 3d4641a8c316a52d:f17a2b7100000006: Reservation=320.00 MB OtherMemory=2.89 MB Total=322.89 MB Peak=322.89 MB
если в запросе ставить явно SET MEM_LIMIT тупо вываливается по достижении лимита. примерно те же проблемы на координаторах — он тянет весь результирующий датасет к себе в память, т.е. памяти на координаторе надо больше, чем клиент попытается утащить.
на сколько я знаю на cвоем железе всего 2 варианта (не считая локал) пускать спарк — хадуп кластер или k8s кластер. k8s как менеджер для spark — совсем новая тема, в проде для совсем смелых и там большой минус — нет «data locality». на хадупе — spark с yarn кажется чаще встречается. без хадупа, поднять лишь yarn думаю не выйдет. yarn наверняка нужен и zookeeper, спарку точно нужен общий сторидж (hdfs). имхо разумней весь хадуп для спарка поднять, тем более что там же у вас и kafka будет.
Hive on Spark именно с HDFS и работает, но думаю медленее Impala на простых запросах, зато стабильно. Impala, да, с тяжелыми запросами и тучей пользователей и у нас плохо дружит.
мне вот интересно как была скорость у Impala/HDFS на фоне Greenplum, обгоняла, если хватало ресурсов выполнить запрос?
интересно, но нифига не понятно.
в связке с greenplum, в чем спарк запускался? из текста складывается впечатление, что спарк на одной единственной ноде запутили в локальном режиме.
когда сравнивали с хадуп, что за енжин был у hive? hive on spark пробовали?
но проще чем онпермис лицензии посчитать. попробуй посчитать онпермис лицензии оракла, там то калькулятора нет, а нюансов только по субд больше чем во всех сервисах облака.
— Петька, прибор!
— 20
— Что 20?
— А что прибор?
если уж так приспичило, на каждом узе по 128G памяти, 20 ядер. совершенно нормальные узлы, на которых и так уже большая часть ресурсов выделена Импале, которая ничего сложного и не делает. все тяжелые ETL / скоринги делает map-reduce и спарк.
feel the difference.
кантора здоровая, фин услуги в европе, 24 страны, оборот под млрд евро.
так дело не в супорте, а доступе бинарникам, патчам. ну ясно, на 5.х какие-то договоры есть.
тут особо рассказать не могу, мы данные процессим, а BI — отдельное царство куда у нас и доступа нет. на их страничке видно что что-то запустили, 150 юзеров лицензировано, подозреваю многие счастливы просто потому что альтернатива ждать когда кто-то наверху приоритизирует запрос на отчетик.
а так хоть что-то сами накликать могут.
не догоняю, в чем может быть преимущество 5.х без супорта над 6.3 без супорта?
я относительно далек от BI, но видел внутренние презентации. сложные визуализации делают на qlik, но замахались и в дополнение купили BO. презентовали, как тулзу подходящую продвинутым бизнес пользователям, которым будет быстрее (и дешевле) простые отчеты самим рисовать. показывали иерархическую структуру из нашей основной витрины, от туда можно было брать колонки и накидывать в пивот, BO сам догадывался как там чего заджоинить. простенькие графики / пирожки показывали. с виду выглядело много примитивней, чем у powerbi и соответственно много проще для бизнес пользователя.
со стороны не выглядело как легаси. выглядело как более простенький тул, с которым у бизнес пользователя есть шанс справится без программиста
161 Тб в вертике, это же наверно миллионы $$$ в год. я угадал?
и еще, у на BO внедряли именно под соусом self BI, только он позволял пользователю самому рисовать отчеты какие надо
Memory limit exceeded: Query a34a9afbf1a71fb1:85f3fbd100000000 could not start because the backend Impala daemon is over its memory limit
в моем же случае демон запрос пропустил и начал исполнять, в первую очередь потому что запрос проходит по всем лимитам. и по общему на запрос (в моем случае его не было) и по лимиту на демоне. демон начал исполнять, но заранее не зарезервировал достаточно памяти, потому свалился до достижении лимита демона.
мне не понятно зачем трогать лимит, если он и близко не превышен? Impala Daemon Executors mem_limit итак уже поднят до 80Gb, причем таких узлов 10. 800G — этого хватает одному такому запросу, если никто крупный параллельно не исполняется. значит в целом на кластере хватает и памяти и лимитов.
Impala Daemon десять штук, Impala Daemon Executors mem_limit 80Gb, не понятно почему вы на этот запрос грешите, вроде очевидно Admission Control толком не работает: лимит 64, выбрано 51.78, в логе он откровенно пишет: Memory left in process limit: 9.51 GB
значит проблема не в лимите запроса, а том что Executor не может выделить запросу 32.00 KB. по мне так очевидно, что параллельные запросы тоже потребляют память на узле и все скопом не уместились, а Admission Control похоже не угадывает сколько запросу на этом узле следовало бы зарезервировать памяти, увеличивает резервацию по ходу выполнения.
типичная ошибка
Memory limit exceeded: Failed to allocate row batchEXCHANGE_NODE (id=5) could not allocate 32.00 KB without exceeding limit.
Error occurred on backend host010.domain.net:22000
Memory left in process limit: 9.51 GB
Query(3d4641a8c316a52d:f17a2b7100000000): Reservation=51.78 GB ReservationLimit=64.00 GB OtherMemory=22.00 MB Total=51.80 GB Peak=51.80 GB
Fragment 3d4641a8c316a52d:f17a2b7100000006: Reservation=320.00 MB OtherMemory=2.89 MB Total=322.89 MB Peak=322.89 MB
если в запросе ставить явно SET MEM_LIMIT тупо вываливается по достижении лимита. примерно те же проблемы на координаторах — он тянет весь результирующий датасет к себе в память, т.е. памяти на координаторе надо больше, чем клиент попытается утащить.
Hive on Spark именно с HDFS и работает, но думаю медленее Impala на простых запросах, зато стабильно. Impala, да, с тяжелыми запросами и тучей пользователей и у нас плохо дружит.
мне вот интересно как была скорость у Impala/HDFS на фоне Greenplum, обгоняла, если хватало ресурсов выполнить запрос?
в связке с greenplum, в чем спарк запускался? из текста складывается впечатление, что спарк на одной единственной ноде запутили в локальном режиме.
когда сравнивали с хадуп, что за енжин был у hive? hive on spark пробовали?