Ребята, у вас было такое, что хайвзапускает таску в одной очереди, после чего проходят мепры и редьюсеры, а мердж файлов происходит не в той очереди, что меппило и редьюсило , а в дефаулте
А сцилла уже начала работать с диском как и аэроспайк? Блочное устройство на которое переписываем большими страницами и со своим gc чтобы не плодить трим и write amplification
в любом случае прослойка клиентов которым нужно импала и аллуксио одновременно ничтожно мала, думаю никакого серьезного развития сюда в эту сторону не будет
Хехе, я такой изврат видел своими глазами несколько раз. Все инвестбанки (вернее оналитеги внутри них) переползают с оракла на хадуп через импалу. Они ее обожают, клаудера их в этом поддерживает :)) И все хотят инмемори для быстроты, поэтому импала + аллюксио на одном кластере = частое явление
Вопрос по Apache Spark. Количество выходных файлов при вызове метода write у DataFrame можно контролировать методом repartition. Кто-нибудь знает, как задать размер выходных файлов в формате parquet в байтах при записи?
Вопрос по Apache Spark. Количество выходных файлов при вызове метода write у DataFrame можно контролировать методом repartition. Кто-нибудь знает, как задать размер выходных файлов в формате parquet в байтах при записи?
Такого нет, только примерно можно подобрать колво файлов
понятно, я это не так понял (не уловил момент с raw). в любом случае, из личного опыта, работать с чистыми оффсетами на уровне блоков далеко не песня, и при современных дисках разница слишком мизерная чтоб оно того стоило. Учитывая то что Сцилла вложилась в доработку XFS как раз под свои нужды, смысла в уменьшении прослойки тут очень очень мало. Мы очень редко упираемся в боттлнеки когда сервера используют nvme