?я по бабло другое не тяну

а больше нод взять?

а зачем такие большие тачки тогда

у тя будут ресурсы и все в простое

вы упираетесь в цпу юниты

зачем те оператива и диски если спу нет

а больше нод взять?

а ноды дешёвые по твоему?

а ноды дешёвые по твоему?

взять три ноды в два раза послабее

по той же цене

да глянь книжку

на нее ссылаться можно

на нее ссылаться можно

мне заявили похрен на практики и тд, у нас бюджет

мне заявили похрен на практики и тд, у нас бюджет

вы этот же бюджет потратите

мне заявили галвное обеспечить чтобы работало и хранило, а скорость вопрос тертий

оно когда отвалится

потому что у вас кластер из двух нод

но БОГАТЫРСКИХ

потому что у вас кластер из двух нод

у меня разраб - архитектор вообще предлагал брать блейды с 1230v5 и 64 рамы, и туда 10 тб диск

да я образно

книжку для себя прочитать можно

зачем вообще хадуп если кластер из двух нод? просто файл сервер, а если данные структурированные изначально - базу данных

спарк можно гонять против нфс шары или даже локальной файловой системы

зачем вообще хадуп если кластер из двух нод? просто файл сервер, а если данные структурированные изначально - базу данных

две ноды я придумал(

я еле отговорил от этого

ну прост чуваки, может вам рил купить лицензии на по которое решает вашу пробелму на малом количестве нод, оно и хранит и считает

ну прост чуваки, может вам рил купить лицензии на по которое решает вашу пробелму на малом количестве нод, оно и хранит и считает

тебе сказали 1,5 пб чистого и репликация в требованиях, ну расскажи какое по будет дешевле?

linux + rsync

да рил короч есть сетапы

жирные тачки всегда дороже

жирные тачки всегда лучше

есть узкий набор кейсов когда удобнее иметь худые тачки, но в общем жирные лучше

жирные тачки всегда дороже

увы нет, например память по 32 тб за обьём выходит дешевле чем по 4-8-16

да и на процах не сэкономишь

есть узкий набор кейсов когда удобнее иметь худые тачки, но в общем жирные лучше

жирные тачки лучше кода у тебя их много

проц время дорогое в жирных тачилах прсот

увы нет, например память по 32 тб за обьём выходит дешевле чем по 4-8-16

ну делайте тачки по 128гигов 256

у тебя все равно должно быть определенное количество цпу юнитов на гиг

жирные тачки лучше кода у тебя их много

тут же канал про хадуп, их должно быть много

спарки взлетать не будут

тут же канал про хадуп, их должно быть много

хадуп может и на мертвых трупах с дисками работать

существовать

но кому он такой нужен? :)

ну хдфс если то вполне

хдфс так задизайнен

про какой объем данных мы говорим?

ему не нужны дорогие процы и дорогие диски

да хоть тбы

много тбов

просто ФС будет намного лучше

медленные диски быстрая сеть нужна и тачки рядом

ext4, xfs

просто ФС будет намного лучше

…

на самом деле согласен

просто ФС будет намного лучше

но нет репликации

эта ваша бигдата

просто рибята

ext4

и все рсинком

вместо спарка много апликух на голанге

профит

одна жирная тачка файл сервер, реплика на другую, компьют на бездисковых тачках спарком против nfs

летает просто

пока иопсов хватает

да, но мы говорим же про десятки терабайт

актинвые рид райты кластера спарка

ну и что

я не из головы придумал, было несколько маленьких проектов где мы просто на толстом файлере данные держали - все отлично работает

я тоже не из головы придумал

делал все на рсинках и голанге - лучшией сетап

какие ужасы

на hetzner тачки SX - самая большая дает 75 ТБ в RAID1, стоит 300 евро в месяц

мне кажется он не может хетснер юзать

да, но мы говорим же про десятки терабайт

но потом вам нужно переделоывать решение , внося ошибки в бизнесслогику

если данных больше 30 ТБ никогда не будет - отличный вариант, все летает просто

но потом вам нужно переделоывать решение , внося ошибки в бизнесслогику

смотря как написать, для spark путь есть путь, просто file:// вместо hdfs:// впереди

если данных больше 30 ТБ никогда не будет - отличный вариант, все летает просто

а ты под спарки отдельные тачки без дисков предлагаешь? но со много спу

смотря как написать, для spark путь есть путь, просто file:// вместо hdfs:// впереди

мы говорим о решении комплексном, когда нам нужно и обрабатывать данные и реплицировать и использовать несколько инструментов сразу

смотря как написать, для spark путь есть путь, просто file:// вместо hdfs:// впереди

нам нужен цитатник

а ты под спарки отдельные тачки без дисков предлагаешь? но со много спу

если прям жирные джобы - да

если прям жирные джобы - да

ну это можно, согласен, хороший вариант в принципе

главное не упираться в боттленк на чтении

и записи

мы говорим о решении комплексном, когда нам нужно и обрабатывать данные и реплицировать и использовать несколько инструментов сразу

ну вот если речь не про нищебродские решения, то можно построить и масштабируемое решение на такой архитектуре, только вместо NFS брать толстый NAS

смотря как написать, для spark путь есть путь, просто file:// вместо hdfs:// впереди

хм, а если на ноде где выполняется task спарка этого файла не будет, то что тогда?

если прям жирные джобы - да

?у меня джоба может 3 суток делаться без претензий

которая в спарке

у меня есть клиент с EMC Isilon под сторадж, он умеет S3, HDFS и кучу апишек показывать, сеть там инфинибенд от меланокса, посадили на это кучу компьют нод - промышленное решение, даже Ranger прикрутили

хм, а если на ноде где выполняется task спарка этого файла не будет, то что тогда?

почему не будет? хранилище замаунчено на всех нодах

ну вот если речь не про нищебродские решения, то можно построить и масштабируемое решение на такой архитектуре, только вместо NFS брать толстый NAS

и потерять локальность данных

и потерять локальность данных

локальность преувеличена для батча

(она не нужна)

локальность преувеличена для батча

нет не так

у тебя сеть на узле шире чем диск, только low latency операции будут тормозить, а потоковое чтение не будет

вы говорите о вендор лок решениях, которые могут работать быстрее

нет

ну isilon это вендор лок

ну как нет