[SP-pm] Map Reduce

Otávio Fernandes otaviof at gmail.com
Thu Jan 13 00:43:16 PST 2011


2011/1/12 Alexei Znamensky <russoz em gmail.com>:
> Ok, pode me chamar de velho, old-school, o que for. Mas na minha época,
> file-system era algo que tinha alguma coisa a ver com o kernel do sistema
> operacional. Mesmo com o uso cada vez menos incomum de "user space" file
> systems hoje, sempre há um gancho no kernel. Por exemplo, sou um feliz
> usuário de sshfs [1], mas ele precisa que o fuse [2] faça o gancho dentro do
> kernel do Linux.

Na minha época (com certeza uns 20 anos depois da sua :-P) o FS também é coisa
do Kernel, mas em casos específicos, ele pode ser portado para o user-space,
com o foco de lidar com os dados usando um nível mais alto de abstração.

TMTOWTDI. Nós pregamos isso o tempo todo, porque não pode ser válido para um
filesystem ou para outro projeto/linguagem?

> Dei uma lida rápida no começo da documentação do HDFS. Ok, entendi (em
> linahs gerais) o que o cara quis fazer. Eu mudaria o nome de "filesystem"
> para algo como "JVM-based filesystem" ou algo assim, para evitar
> ambiguidades. But hey, that's just me.

Humm, preconceito hein.

> Pessoalmente eu não sei se usaria algo em Java (+ pesado) para lidar com
> algo que pode ter requerimentos de performance como I/O de dados. Algo em
> Java dificilmente irá se aproveitar de coisas como tamanho do bloco no disco
> físico para melhorar o desempenho. Em escala menor, isso não importa, mas se
> falarmos de massas de dados gigantes, esse tipo de detalhe pode fazer
> diferença. O HDFS será tão bom com os arquivos quanto for a implementação de
> Java utilizada para rodá-lo. Espero *muito* que estejam usando java.nio.* -
> não faria sentido se não usassem. Eu pensaria em algo feito em C/C++ para

Vamos esperar para ver o Btrfs, então.

> implementar esse "file system", e que provesse essa funcionalidade
> "genérica" em todas as plataformas onde fosse compilado, mas que pudesse se
> proveitar de coisas como o FUSE no Linux para ser acessado diretamente como
> um "real file system" (mesmo que em user-space), sem que isso tenha um custo
> de performance tão alto.

Este é o trade-of que você vai ter que fazer, não? Existe casos onde
disponibilidade é muito mais importante do que performance, e etc. E pela forma
como o Hadoop forma clusters, eu estou para lhe afirmar que seu "problema" de
performance não vai ser tão grave assim ;-).

> yet another $0.02

Perai. Da forma como você colocou, dá a impressão que todos os seus dados
ficariam neste filesystem. Eu não faria isso e tenho a certeza de que você
também não.

Partindo desta premissa, podemos "chutar" que o HDFS vai ser utilizado para
resolver um problema específico. E se chegamos a este ponto, eu também assumo
que você estudou cuidadosamente o problema e concluiu que o Hadoop é uma boa
solução.

> --
> Alexei Znamensky [russoz_gmail_com] [russoz.wordpress.com]
> [www.flickr.com/photos/alexeiz]
> «Only love / Can bring the rain / That makes you yearn to the sky»

Eu já vi Hadoop rodando em algumas poucas empresas, porem, guardando dados
não-tão-importantes, como logs por exemplo. É questão de tempo para este FS
escalar para posições mais importantes.

um abraço,

--
Otávio Fernandes
otaviof at ( gmail.com, cpan.org )
http://github.com/otaviof


More information about the SaoPaulo-pm mailing list