Li Auto x JuiceFS: Evolução e Pensamento do Hadoop para o Cloud Native

Arquitetura técnica do carro ideal na era Hadoop

Primeiro, revise brevemente o desenvolvimento da tecnologia de big data. Com base no meu entendimento pessoal, o desenvolvimento de big data é dividido em quatro períodos:

O primeiro período: 2006 a 2008. Por volta de 2008, o Hadoop se tornou o principal projeto do Apache e lançou oficialmente a versão 1.0.Sua base é definida principalmente com base na troika do Google, GFS, MapReduce e BigTable.

O segundo período: de 2009 a 2013. Empresas como Yahoo, Alibaba e Facebook estão usando cada vez mais big data. No final de 2013, o Hadoop lançou oficialmente a versão 2.0. Tive a sorte de entrar em contato com big data em 2012 e experimentei com Hadoop 1.0 mais Hive. Naquela época, me senti incrível. Big data pode resolver rapidamente problemas que não podem ser resolvidos com SQL Server ou MySQL com algumas máquinas .

A terceira fase: De 2014 a 2019, durante este período de desenvolvimento é muito rápido, durante o qual Spark e Flink se tornaram os principais projetos Apache. Durante esse rápido período de escalada, também tentamos usar o Storm, que mais tarde foi substituído pelo Flink.

A quarta etapa: De 2020 até o presente, depois que Hudi se formou no Apache e se tornou um projeto de alto nível em 2020, eu pessoalmente entendo que o data lake entrou no estágio de maturidade de todo o desenvolvimento e atingiu o estágio do data lake 2.0 de grandes dados. O data lake tem três características principais, em primeiro lugar, armazenamento unificado e aberto, em segundo lugar, um formato aberto e mecanismos de computação avançados.

No processo geral de desenvolvimento, big data tem principalmente várias características, que são os quatro "Vs" que todo mundo costuma dizer: Volume, Velocidade, Variedade e Valor. Agora há um quinto "V" (veracidade), a precisão e confiabilidade dos dados. A qualidade dos dados sempre foi criticada. Espero que haja um conjunto de padrões na indústria para melhorar a qualidade do data lake. Esse pode ser o padrão para o surgimento do Data Lake 2.0, porque projetos como Hudi e Iceberg destina-se a melhorar a qualidade de todo o data lake. O gerenciamento do data lake é bem feito.

Pessoalmente, acho que Hadoop é sinônimo de big data, mas big data não é apenas Hadoop. Big data é um conjunto de soluções para processamento e utilização de uma grande quantidade de dados formados após a integração de vários componentes durante o processo de desenvolvimento . Nos últimos anos, todos basicamente acreditam que o Hadoop está indo ladeira abaixo. Primeiro, a fusão e fechamento das empresas de comercialização de Hadoop Cloudera e Hortonworks, o modelo de negócios original não pode continuar, desafios de usabilidade e a crescente complexidade do próprio ecossistema Hadoop.

Arquitetura atual da Ideal Automobile Big Data Platform

Nesta fase, a plataforma de big data da Li Auto é mostrada na figura acima. Ideal Car usa muitos componentes de código aberto.

Camada de transporte: Kafka e Pulsar. O Kafka foi usado como um todo no estágio inicial de construção da plataforma. Os recursos nativos da nuvem do Kafka são relativamente fracos. O Pulsar foi projetado de acordo com a arquitetura nativa da nuvem no início de seu design e possui alguns recursos muito adequados para IoT cenários, e também condiz com os nossos cenários de negócios, por isso, apresentamos recentemente o Pulsar.
A camada de armazenamento é HDFS + JuiceFS.
Os principais mecanismos de computação atuais da camada de computação são Spark e Flink, e esses mecanismos de computação estão sendo executados no Yarn atual. Os três mecanismos de computação são gerenciados pelo Apache Linkis, que é de código aberto do WeBank, e atualmente usamos muito o Linkis.
À direita estão três bancos de dados. O primeiro, MatrixDB, é uma versão comercial do banco de dados de séries temporais. TiDB é usado principalmente para cenários mistos de OLTP e OLAP. Atualmente, nós o usamos principalmente para cenários TP. A StarRocks é responsável pelo cenário OLAP.
ShardingSphere quer usar seu conceito Database Plus para unificar os bancos de dados subjacentes para gerenciamento em nível de gateway. Ainda está em fase exploratória, e há muitas novidades que nos interessam muito.
Mais à direita, Thanos é uma solução de monitoramento nativa da nuvem. Integramos o monitoramento de componentes, motores e máquinas na solução Thanos.
A camada de aplicativos são nossos quatro principais produtos intermediários atuais, incluindo aplicativos de dados, desenvolvimento de dados, integração de dados e governança de dados.

características

Através do status quo das plataformas de big data, é possível encontrar algumas características:

Primeiro, existem muitos componentes em toda a solução, os usuários têm forte dependência desses componentes e a dependência mútua entre os componentes também é relativamente forte. É recomendável que você tente escolher componentes nativos de nuvem mais maduros ao selecionar componentes no futuro .
Em segundo lugar, nossos dados têm picos e vales claros. A cena de viagem é geralmente no pico da manhã e no pico da noite, e haverá mais pessoas aos sábados e domingos.
A terceira característica é que a popularidade de nossos dados é basicamente a mais quente e geralmente acessamos apenas os dados dos últimos dias ou da última semana. No entanto, uma grande quantidade de dados é gerada e, às vezes, uma grande quantidade de retrocesso pode ser necessária; portanto, os dados também precisam ser armazenados por um longo período de tempo, portanto, a taxa de utilização dos dados é muito pior.

Finalmente, todo o sistema de dados atualmente carece de alguns métodos de gerenciamento eficazes no nível do arquivo. Da construção até agora é basicamente baseado em HDFS, e há uma grande quantidade de dados inúteis, o que causa desperdício de recursos, esse é um problema que precisamos resolver com urgência.

Pontos problemáticos das plataformas de Big Data

Primeiro, há muitos componentes, tornando a implantação difícil e ineficiente . Existem mais de 30 componentes de big data no Hadoop e mais de 10 comumente usados. Existem dependências fortes e fracas entre alguns componentes, e a configuração e o gerenciamento unificados tornam-se muito complicados.
Em segundo lugar, o custo da máquina e o custo de manutenção são relativamente altos . Para a operação estável dos negócios, os clusters off-line e em tempo real são implantados separadamente. No entanto, devido às características de negócios mencionadas acima, os picos e vales de nossos negócios são óbvios e a taxa de utilização geral não é alta. Um grande número de componentes de cluster requer pessoal especializado para gerenciá-los e mantê-los.
Terceiro, recursos de compartilhamento de dados entre plataformas . Atualmente, os dados compartilhados entre clusters só podem ser sincronizados com outros clusters Hadoop por meio do DistCp. Não pode ser sincronizado fácil e rapidamente com outras plataformas e servidores.
Quarto, segurança de dados e conformidade com a privacidade . Com base em diferentes requisitos de segurança de dados, os usuários comuns são gerenciados por meio do Ranger, e os requisitos especiais de segurança só podem ser atendidos com a criação de clusters diferentes e a definição de políticas de VPC separadas, resultando em muitas ilhas de dados e custos de manutenção.

A evolução e o pensamento do carro ideal nativo da nuvem

Em primeiro lugar, deixe-me compartilhar brevemente minha compreensão pessoal do nativo da nuvem:

Primeiro, a nuvem nativa é derivada da computação em nuvem. Agora todos usam fornecedores de nuvem como Alibaba Cloud, AWS, Tencent Cloud, Baidu Cloud, etc., inicialmente fornecendo serviços técnicos na camada IaaS para ajudar as empresas a empacotar os itens mais básicos, como armazenamento, computação e redes para gerenciamento unificado. só precisa solicitar um servidor nele. Depois de solicitar servidores, esses servidores ainda são gerenciados por fornecedores de nuvem, que é nossa operação de nuvem tradicional.

O nativo da nuvem é inseparável da computação em nuvem. De um modo geral, o nativo da nuvem pertence ao serviço da camada PaaS da computação em nuvem, que é principalmente um tipo de aplicativo para desenvolvedores. O nativo da nuvem deve ser instalado na nuvem e é um método de desenvolvimento e aplicação de software baseado em nuvem. Cloud + nativo, nuvem é computação em nuvem, nativo é abandonar a estrutura tradicional de desenvolvimento de operação e manutenção, por meio de conteinerização, DevOps e arquitetura de microsserviços para obter dimensionamento elástico e implantação automática de aplicativos, fazendo pleno uso dos recursos de computação em nuvem para alcançar no menor espaço faça a maior coisa. Ele também pode resolver alguns pontos problemáticos do nosso atual sistema de big data, como baixa escalabilidade e manutenção, exigindo muita mão de obra e tempo.

A figura acima lista brevemente vários pontos de tempo de nuvem nativa

No primeiro estágio, a AWS propôs o conceito de nuvem nativa e lançou o EC2 em 2006. Esse estágio é o estágio do servidor, o estágio de computação em nuvem mencionado acima.
O segundo estágio, o estágio de cloudização, ocorre principalmente após o lançamento do Docker de código aberto e do Kubernetes de código aberto do Google. O Kubernetes é uma plataforma de código aberto leve e extensível para gerenciamento de aplicativos e serviços em contêineres. A implantação automática e o dimensionamento de aplicativos podem ser realizados por meio do Kubernetes.
Na terceira etapa, a Fundação CNCF foi criada em 2015 para promover conceitos nativos da nuvem e ajudar no desenvolvimento nativo da nuvem como um todo. O último é o código-fonte aberto do Knative.Um objetivo muito importante do Knative é desenvolver padrões de orquestração sem servidor de plataforma cruzada e nativos da nuvem. Derivado ao presente, já é o estágio do cloud native 2.0, ou seja, o estágio do serverless. Pessoalmente, entendo que o desenvolvimento de big data também deve se desenvolver na direção do Serverless . Por exemplo, todo o serviço online da AWS é basicamente Serverless.

Arquitetura nativa da nuvem de big data

Em seguida, deixe-me apresentar as mudanças nos componentes da plataforma de big data do carro ideal após a natividade da nuvem:

Na camada de armazenamento, todo o armazenamento após a natividade da nuvem é basicamente armazenamento de objetos. O diagrama de arquitetura acima leva ao Lustre, que será descrito em detalhes abaixo. Você pode entender que a camada de "armazenamento em nuvem" usa principalmente o JuiceFS para gerenciar o armazenamento de objetos e o sistema de arquivos distribuídos paralelos do Lustre (Nota: devido ao problema de cópia única do Lustre, estamos considerando o uso de sistemas de arquivos paralelos fornecidos pelo produto de provedores de serviços em nuvem).
A camada de contêiner, principalmente em cima de computação, armazenamento e rede, foi toda substituída por Kubernetes mais Docker, e todos os componentes são desenvolvidos nele.
Para a parte do componente, a primeira é a estrutura de computação de big data. Podemos abandonar o Hive, usar diretamente o Spark e o Flink, usar o Hudi como o suporte de capacidade subjacente do Data Lake 2.0 e substituir gradualmente o HDFS.
Na parte de middleware, além do Pulsar, existe o Kafka. No momento, a natividade da nuvem do Kafka não é muito boa. Pessoalmente, prefiro substituir o Kafka pelo Pulsar. Atualmente, o Linkis tem sido usado online para adaptar todos os motores Spark, e o Flink será adaptado e integrado posteriormente. O ShardingSphere acaba de oferecer suporte nativo à nuvem na versão 5.1.2 e realizaremos a verificação do cenário e a exploração de recursos conforme planejado.
A camada de banco de dados ainda é TiDB, StarRocks e MatrixDB. No momento, esses três bancos de dados já possuem recursos nativos da nuvem e todos suportam armazenamento de objetos. Mas esta peça não foi testada separadamente e ainda estamos usando máquinas físicas. Porque para o banco de dados, os recursos de E/S fornecidos pelo armazenamento de objeto atual não podem atender aos requisitos de desempenho do banco de dados, o que reduzirá bastante o desempenho geral do banco de dados.
Em termos de operação e manutenção, um Loki adicional é adicionado à solução Thanos, principalmente para coleta de logs nativos da nuvem. Mas Loki e Thanos são apenas dois deles. No futuro, entendo que eles se alinharão com os recursos SREWorks de código aberto de Ali e selarão toda a qualidade, eficiência de custo e segurança nos recursos abrangentes de operação e manutenção, para que todo o o gerenciamento nativo da nuvem pode ser gerenciado de forma independente.
Observabilidade, um conceito recentemente popular no campo da nuvem nativa. Alguns dos componentes que todo mundo está fazendo agora começam a se desenvolver na nuvem depois de se tornarem populares. Eles não nasceram na nuvem no início, mas apenas esperam crescer na nuvem mais tarde. Nesse caso, ele encontrará alguns problemas.O primeiro problema é que não há monitoramento de visibilidade abrangente. Consideramos como desenvolver um plano para esses componentes como um todo no futuro, para que todos os componentes possam ser efetivamente monitorados após serem nativos da nuvem.

Para resumir, eu pessoalmente acho que a futura nuvem nativa de big data é basicamente:

Uso unificado de armazenamento nativo da nuvem como armazenamento subjacente para todos os componentes (incluindo bancos de dados)
Todos os componentes são executados em contêineres
Use arquitetura sem servidor para atender aplicativos de camada superior

Mas isso também traz desafios para os atuais produtos de plataforma de dados, ou seja, como projetar produtos com recursos sem servidor para uso dos usuários.

Vantagens do Big Data Cloud Native

O primeiro ponto é a separação de armazenamento e cálculo, expansão e contração elástica . Depois de usar máquinas físicas para implantar o Hadoop, se você precisar expandir ou reduzir a capacidade, precisará entrar em contato com o operador e pode haver um longo ciclo. A separação de armazenamento e cálculo resolve bem esse problema. O segundo é pré-pago, sem comprar recursos ociosos. Atualmente, os dados de todo o nosso cenário de negócios têm picos e vales. Nos picos, as máquinas precisam ser preparadas e as máquinas precisam ser retiradas nos vales, mas isso não é possível agora. Agora basicamente empilhamos todas as máquinas até o pico. No pico ele consegue atender a demanda e fica estável sem falhar. Mas fica ocioso por pelo menos 12 horas no vale. Nesse caso, os recursos também são cobrados. Depois do nativo da nuvem, não precisamos mais pagar por isso.

O segundo ponto é a implantação e operacionalidade automatizadas . O Kubernetes oferece suporte a soluções de implantação integrada de DevOps. Dessa forma, nossos componentes como um todo podem ser implantados rapidamente (por exemplo, por meio do gráfico Helm) e os recursos de operação e manutenção do componente são reduzidos para a plataforma nativa da nuvem, para que o big data não precise considerar a operação e manutenção do componente cenários.

O terceiro ponto é o armazenamento de objetos . O armazenamento de objetos é o principal e mais importante produto lançado pela computação em nuvem. Os benefícios do armazenamento de objetos são evidentes, fáceis de expandir, espaço de armazenamento ilimitado, preço unitário relativamente baixo e armazenamento de objetos também é dividido em armazenamento de baixa frequência, armazenamento de arquivo e outros tipos de armazenamento, reduzindo ainda mais os custos de armazenamento, os dados podem ser armazenado por mais tempo. Ao mesmo tempo, custo controlável, alta confiabilidade e baixa complexidade operacional também são vantagens do armazenamento de objetos.

O quarto ponto é segurança e conformidade . Após a nuvem nativa, namespace dedicado, isolamento multilocatário e autenticação remota podem ser realizados. Atualmente, o que conseguimos é basicamente o isolamento no nível da rede.A solução amplamente reconhecida para gerenciamento de arquivos HDFS é o Ranger. Usar o Ranger para gerenciar permissões de diretório HDFS também pode gerenciar algumas permissões, como servidor Hive, HBase e Kafka, mas essas permissões são relativamente fracas.

Outra solução é o Kerberos.A segurança de todo o componente de big data será muito melhorada, mas tem muitos custos, e qualquer requisição deve ser verificada. Não usamos essa solução até agora, e tem algo a ver com nosso ambiente de cluster e cenários, estamos basicamente na intranet e não prestamos serviços externos. Se o seu projeto de big data precisar fornecer alguns serviços para a rede externa, você ainda precisará ter uma autenticação forte, caso contrário, os dados vazarão facilmente.

Dificuldades do Cloud Native Big Data

A dificuldade do big data cloud native também existe.

Primeiro, existem muitos componentes relacionados a big data. Ao mesmo tempo, a atualização do Kubernetes é relativamente rápida. Após o cruzamento dos componentes, haverá problemas de compatibilidade, complexidade e escalabilidade.

Segundo, a alocação e realocação de recursos. O Kubernetes é uma ferramenta de agendamento de recursos de contêiner de uso geral e é difícil atender aos cenários de uso de recursos de diferentes componentes de big data. Em um cenário de big data, o uso de recursos será relativamente grande, a frequência de solicitação será alta e o número de pods será relativamente grande a cada vez. Nesse caso, atualmente não há uma boa solução. No momento, estamos analisando a solução do Fluid. O Fluid também implementa o tempo de execução do JuiceFS. Isso é o que investigaremos mais tarde. O Fluid atualmente afirma que pode suportar big data e AI, não apenas cenários de AI, porque big data e AI Os cenários são semelhantes e são todas operações com uso intensivo de dados. A Fluid fez alguns avanços na eficiência da computação e no gerenciamento de abstração de dados.

Em terceiro lugar, o armazenamento de objetos também apresenta algumas desvantagens. As desvantagens do armazenamento de objetos são baixo desempenho de operação de metadados, baixa compatibilidade com componentes de big data e eventual consistência.

O último ponto são os aplicativos com uso intensivo de dados. O modo de separação de computação de armazenamento não pode atender aos requisitos de aplicativos com uso intensivo de dados, como big data e IA, em termos de eficiência de operação de computação e gerenciamento de abstração de dados.

A exploração e implementação do JuiceFS em soluções nativas de nuvem de big data

Antes do código aberto do JuiceFS, prestamos atenção e fizemos alguns testes de aterrissagem. Após o lançamento da versão de código aberto, a usaremos imediatamente. Quando ele ficou online, também encontrei alguns problemas de permissão e alguns pequenos bugs. A comunidade nos apoiou muito e nos ajudou a resolvê-los rapidamente.

O HDFS está ficando offline devido à sua baixa escalabilidade e, ao mesmo tempo, nosso volume de dados é relativamente grande e o custo de armazenamento do HDFS é relativamente alto. Depois de armazenar vários lotes de dados, o espaço na máquina física não é suficiente e muitos cálculos são necessários. Naquela época, nosso desenvolvimento de negócios ainda estava em sua infância e, para obter o máximo de valor possível dos dados, queríamos manter o máximo de dados possível. Além disso, o HDFS requer três cópias. Mais tarde, mudamos para duas cópias, mas duas cópias ainda são arriscadas.

Com base nisso, testamos o JuiceFS em profundidade. Após a conclusão do teste, introduzimos rapidamente o JuiceFS em nosso ambiente online. A migração de algumas tabelas relativamente grandes de HDFS para JuiceFS aliviou nossa necessidade urgente.

Valorizamos três pontos do JuiceFS:

Primeiro, o JuiceFS é compatível com vários protocolos . É totalmente compatível com os protocolos POSIX, HDFS e S3, e é 100% compatível no uso atual sem problemas.
Em segundo lugar, a capacidade de cruzar nuvens . Quando uma empresa tem uma certa escala, para evitar riscos sistêmicos, ela não usará apenas um provedor de serviços em nuvem. Não estará vinculado a uma nuvem, serão todas operações em várias nuvens. Nesse caso, a capacidade do JuiceFS de sincronizar dados entre nuvens desempenha um papel importante.
Em terceiro lugar, cenários nativos da nuvem . JuiceFS suporta CSI. No momento, não usamos CSI neste cenário. Basicamente, usamos POSIX para montar, mas usar CSI será mais simples e mais compatível. Também estamos desenvolvendo para nuvem nativa agora, mas todo o componente ainda não chegou ao Kubernetes ainda.

Aplicação do JuiceFS no Carro Ideal

Dados persistentes do HDFS para armazenamento de objetos

Depois que o JuiceFS foi aberto, começamos a tentar sincronizar os dados do HDFS com o JuiceFS. No início da sincronização, foi usado o DistCp. É muito conveniente sincronizar com o Hadoop SDK do JuiceFS, e a migração geral é relativamente suave. O motivo da migração de dados do HDFS para o JuiceFS é devido a alguns problemas.

A primeira é que o design de acoplamento armazenamento-computação do HDFS tem baixa escalabilidade e não há como resolver esse problema. Meu entendimento pessoal de big data desde o início é que big data deve ser implantado em máquinas físicas, não em hosts de nuvem. Incluindo os vários sistemas EMR lançados por fornecedores de nuvem posteriormente, eles estão realmente encapsulando o Hadoop.Nos últimos um ou dois anos, esses sistemas EMR foram gradualmente des-Hadoopizados.

A segunda é que o HDFS é difícil de se adaptar à nativa da nuvem. O HDFS atual é difícil de se adaptar ao nativo da nuvem, porque é relativamente pesado. Embora a comunidade tenha se concentrado no nativo da nuvem, eu pessoalmente acho que a tendência de desenvolvimento do Hadoop está em declínio e o futuro deve ser baseado no armazenamento de objetos.

Em terceiro lugar, o armazenamento de objetos também tem algumas desvantagens. Não pode ser bem adaptado à API do HDFS. Devido à rede e outros motivos, o desempenho também é muito diferente do dos discos locais. Além disso, as operações de metadados, como listar diretórios, também são muito lento. Usamos o JuiceFS para fazer alguma aceleração, e o desempenho medido é muito impressionante. É basicamente comparável ao disco local no caso do cache. Com base nisso, mudamos rapidamente a cena atual diretamente para o JuiceFS.

Compartilhamento de arquivos no nível da plataforma

O segundo cenário é o compartilhamento de arquivos no nível da plataforma. Todos os dados de arquivos compartilhados de nosso sistema de agendamento atual, sistema em tempo real e plataforma de desenvolvimento são armazenados no HDFS. Se pararmos de usar o HDFS mais tarde, precisaremos migrar esses dados. A solução atual é usar o JuiceFS para se conectar ao armazenamento de objetos.Através do serviço da camada de aplicação, todos eles são montados no modo POSIX, e todos podem solicitar os arquivos no JuiceFS sem sentir.

O JuiceFS atende à maioria dos requisitos de nosso aplicativo neste cenário, mas ainda existem alguns pequenos cenários com problemas. A ideia original era colocar todo o ambiente Python e afins nele. Mais tarde, descobri que a operação real é muito difícil, porque há muitos arquivos pequenos no ambiente Python e ainda há problemas ao carregar. Cenários como o ambiente Python que contém um grande número de arquivos fragmentados ainda precisam ser armazenados no disco local para operação. No futuro, vamos pendurar um bloco de armazenamento especificamente para fazer isso.

Compartilhe alguns problemas que encontramos com HDFS antes:

Primeiro, quando o NameNode está sob forte pressão ou Full GC, haverá falhas de download e atualmente não há solução perfeita. Nossa solução é aumentar a memória o máximo possível, ou adicionar algumas retentativas ao baixar o pacote para evitar seu período de pico, mas é difícil resolver completamente o problema do HDFS neste caso, pois ele é escrito em Java afinal, e o GC Não há como evitar a cena.

Em segundo lugar, ao usar HDFS entre sistemas, por exemplo, se tivermos dois clusters, é basicamente irreal usar um cluster para compartilhar arquivos, porque a rede precisa ser aberta para conectar os dois clusters ou acessar o aplicativo, portanto, há não há como garantir a segurança. Atualmente, temos basicamente dois clusters que mantêm seus próprios arquivos compartilhados de forma independente. Agora, a plataforma em tempo real (como a plataforma Flink) mudou para JuiceFS, e ainda é muito suave e não encontrou nenhum problema.

Em terceiro lugar, temos atualmente um grande número de implantações de máquinas físicas, todas em cluster único, sem uma estratégia de recuperação de desastres.Se algum problema catastrófico ocorrer na sala de informática, todo o nosso serviço ficará indisponível. Mas o armazenamento de objetos em si é uma sala entre computadores, na mesma região, deve haver pelo menos três cópias, os fornecedores de nuvem nos ajudam a fazer o backup. No futuro, podemos desenvolver várias nuvens, esperando usar o JuiceFS para compartilhar alguns arquivos de alto nível, bancos de dados principais, incluindo alguns arquivos de backup principais e fazer backups em várias nuvens. Desta forma, multi-nuvem, multi-região e multi-região são realizados, o que pode resolver o problema de recuperação de desastre de ponto único.

Uso multiplataforma de dados massivos

Em outro cenário, todas as plataformas compartilham dados massivos por meio do JuiceFS. O primeiro tipo de dados compartilhados do nosso lado são dados de teste de estrada. Haverá uma grande quantidade de dados de vídeo, áudio e imagem carregados para teste de estrada. Após o upload, esses dados entrarão diretamente no JuiceFS, o que é conveniente para o downstream fazer algumas sincronização e compartilhamento.Incluindo alguma triagem de dados e, em seguida, obter PFS é um sistema de arquivos paralelo, sob o qual é montado SSD. Isso pode aumentar a utilização da GPU, porque a capacidade de armazenamento do objeto é relativamente fraca, caso contrário, a capacidade da GPU será muito desperdiçada.

Os tipos de dados restantes incluem alguns registros relatados por veículos para análise, dados de pontos enterrados e dados de sinais relacionados a veículos exigidos por algumas plataformas nacionais. Esses dados serão inseridos no data warehouse para algumas análises. Também faremos alguma extração de dados de recursos nesses dados, faremos treinamento de modelo para a equipe de algoritmos ou faremos alguma recuperação de NLP e outros cenários.

Cloud Native Storage Acceleration - Luster como um cache de leitura (em teste)

Agora estamos testando outro cenário, que é pendurar um Lustre na camada de armazenamento de objetos para servir como um cache de leitura para o JuiceFS e usar o cache do Lustre para ajudar o JuiceFS a melhorar a velocidade de leitura e a taxa de acertos do cache.

Uma vantagem disso é que agora estamos usando máquinas físicas, que possuem discos físicos, que podem ser usados para armazenar dados em cache. Mas como as tarefas de computação são executadas em vários nós, a taxa de acertos do cache não é muito alta. Isso ocorre porque a versão comunitária do JuiceFS ainda não oferece suporte ao cache distribuído P2P e suporta apenas o cache local de nó único, e cada nó pode ler muitos dados. Nesse caso, alguma pressão de disco também é causada no nó de computação, porque o cache ocupará uma certa quantidade de espaço em disco.

Nossa solução atual é usar o Lustre como o cache de leitura do JuiceFS. Especificamente, de acordo com o tamanho dos dados a serem armazenados em cache, monte um sistema de arquivos Lustre com capacidade de cerca de 20 a 30 TB no nó de computação local e, em seguida, use esse ponto de montagem do Lustre como o diretório de cache do JuiceFS. Nesse caso, depois que o JuiceFS lê os dados, ele pode armazená-los de forma assíncrona no Lustre. Esta solução pode efetivamente resolver o problema de baixa taxa de ocorrência de cache e melhorar muito o desempenho de leitura.

Se gravarmos dados diretamente no armazenamento de objetos no cenário Spark, haverá limitações de largura de banda e QPS. Se a gravação for muito lenta, as tarefas upstream podem tremer. Nesse caso, a função de cache de gravação do JuiceFS pode ser usada Gravando dados para o Lustre primeiro e, em seguida, gravando de forma assíncrona no armazenamento de objetos, esta solução é aplicável em alguns cenários. Mas há um problema que o Lustre não é uma solução nativa da nuvem, é percebido pelo usuário, e o usuário precisa escrever explicitamente um comando para montá-lo ao iniciar o pod. Portanto, também esperamos fazer algumas alterações no JuiceFS no futuro, identificar automaticamente o armazenamento de objetos e o Luster e, em seguida, implementar automaticamente alguns mecanismos de cache, para que os usuários não precisem perceber a existência do Lustre.

No momento, o PoC desta solução foi concluído e passou no teste básico. Em seguida, faremos muitos testes de pressão no ambiente de produção. Espera-se que seja lançado oficialmente no terceiro trimestre deste ano para cobrir alguns serviços de ponta .

A solução geral do JuiceFS em nuvem de big data nativa

Como pode ser visto no diagrama de arquitetura da solução geral, atualmente usamos todos os três métodos fornecidos pelo cliente JuiceFS.

Conforme mostrado na metade esquerda da figura acima, teremos clusters Spark e Flink independentes e montaremos o JuiceFS diretamente em todo o cluster por meio do driver CSI, para que, quando os usuários iniciarem o Spark e o Flink, eles não saibam O JuiceFS existe, e a leitura e gravação de tarefas de computação são todas feitas por meio do armazenamento de objetos.

Esta seção atualmente tem uma pergunta sobre shuffle. Como a tarefa Spark requer uma grande quantidade de dados a serem gravados no disco durante a fase de embaralhamento do processo de cálculo, um grande número de solicitações de leitura e gravação de arquivo geradas durante esse período têm requisitos de desempenho mais altos para o armazenamento subjacente. O Flink é relativamente melhor porque é streaming e não requer um grande número de discos. No futuro, esperamos que o JuiceFS possa gravar diretamente no Lustre, mas isso requer algumas modificações no JuiceFS. Por meio da integração do cliente, o JuiceFS pode ler e gravar diretamente no Lustre. Isso não será percebido pelos usuários e também pode melhorar a leitura do Shuffle Stage e escrever o desempenho.

O aplicativo na metade direita da figura acima tem dois cenários. Uma delas é simplesmente consultar os dados do JuiceFS, como visualização de dados por meio do HiveJDBC. Nesse cenário, o JuiceFS pode ser acessado por meio do gateway S3.

O segundo é o cenário em que a plataforma de big data e a plataforma de IA estão vinculadas. Por exemplo, colegas na plataforma AI geralmente precisam ler dados de amostra, dados de recursos etc. em seu trabalho diário, e esses dados geralmente são gerados por tarefas Spark ou Flink na plataforma de big data e foram armazenados no JuiceFS . Para compartilhar dados entre diferentes plataformas, quando o pod da plataforma AI for iniciado, o JuiceFS será montado diretamente no pod através do FUSE, para que os colegas da plataforma AI possam acessar diretamente os dados no JuiceFS através do Jupyter para fazer alguns modelos O treinamento, em vez de copiar dados repetidamente entre diferentes plataformas como a arquitetura tradicional, melhora a eficiência da colaboração entre equipes.

Porque o JuiceFS usa usuários e grupos de usuários padrão POSIX para controle de permissão, e o contêiner inicia como usuário root por padrão, o que dificulta o controle de permissões. Portanto, fizemos uma modificação no JuiceFS para montar o sistema de arquivos por meio de um token de autenticação, que contém as informações de conexão do mecanismo de metadados e outras informações de controle de permissão. Em alguns cenários em que vários sistemas de arquivos JuiceFS precisam ser acessados ao mesmo tempo, usamos o gateway JuiceFS S3 combinado com políticas IAM para gerenciamento unificado de permissões.

Algumas dificuldades encontradas no uso do JuiceFS no momento

O primeiro ponto é que a função de gerenciamento de permissões com base em usuários e grupos de usuários é relativamente simples. Em alguns cenários, o contêiner inicia como usuário root por padrão e as permissões não são fáceis de controlar.

O segundo ponto é sobre a otimização da configuração do JuiceFS Hadoop SDK. No momento, temos principalmente três configurações para otimizar o JuiceFS Hadoop SDK: juicefs.prefetch, juicefs.max-uploadse juicefs.memory-size. Alguns problemas foram encontrados no processo de ajuste juicefs.memory-sizeda configuração . O valor padrão desta configuração é 300 MB. A sugestão oficial é definir uma memória off-heap que tenha 4 vezes o tamanho do valor padrão, que é 1,2 GB. No momento, a maioria de nossas tarefas está configurada para 2 GB de memória off-heap, mas algumas tarefas ocasionalmente falham ao gravar mesmo se mais de 2 GB de memória estiverem configurados (o HDFS pode gravar de forma estável). No entanto, isso não é necessariamente um problema com o JuiceFS, também pode ser causado pelo Spark ou pelo armazenamento de objetos. Portanto, no momento, também estamos planejando adaptar profundamente o Spark e o JuiceFS e descobrir os motivos passo a passo, tentando superar todas essas armadilhas e reduzir a memória, garantindo a estabilidade da tarefa.

O terceiro ponto é que, à medida que a arquitetura geral (JuiceFS + armazenamento de objetos + Lustre) se torna mais complexa, há mais pontos de falha possíveis e a estabilidade das tarefas pode diminuir, o que requer outros mecanismos tolerantes a falhas para garantir. Por exemplo, durante a fase de gravação aleatória da tarefa Spark, um erro semelhante a "tarefa perdida" pode ser relatado e a causa específica do erro ainda não foi localizada.

A combinação de arquitetura de JuiceFS + armazenamento de objeto + Luster mencionada acima melhora o desempenho de leitura e gravação até certo ponto, mas também torna a arquitetura mais complexa e, correspondentemente, aumenta alguns possíveis pontos de falha. Por exemplo, o Lustre não tem uma capacidade forte de cópia de recuperação de desastres. Se o Lustre travar um nó repentinamente, as tarefas em execução podem continuar a ler e gravar dados no Lustre de forma estável ou os dados no Lustre foram perdidos acidentalmente? Ele ainda pode ser estável Atualmente, é incerto se devemos ir ao JuiceFS e recuperá-lo por meio do armazenamento de objetos, e atualmente estamos fazendo esse tipo de teste catastrófico.

futuro e perspectivas

Solução de data lake em tempo real baseada em Flink + Hudi + JuiceFS

Uma das coisas que faremos em um futuro próximo é a solução de data lake em tempo real de Flink + Hudi + JuiceFS. O lado esquerdo da figura acima é a fonte de dados. Através do Flink, Kafka/Pulsar, os dados são gravados no Hudi em tempo real. Ao mesmo tempo, os dados do Hudi cairão no JuiceFS para substituir nossos dados atuais em tempo real armazém.

Planejamento de longo prazo de big data nativo em nuvem

Por fim, gostaria de apresentar o plano de longo prazo do carro ideal nativo da nuvem de big data, que também é uma perspectiva.

O primeiro ponto é um sistema unificado de gerenciamento e governança de dados. Acreditamos que na era do data lake 2.0, o maior problema que precisa ser resolvido é resolver o problema do pântano de dados no cenário do data lake 1.0. Mas agora parece que não há melhor produto de código aberto para gerenciamento unificado de metadados, gerenciamento de diretório de dados e controle de segurança de dados, semelhante ao AWS Glue e AWS Lake Formation. Atualmente, estamos trabalhando em um projeto de "sistema de origem". A primeira etapa desse sistema é gerenciar todos os metadados no banco de dados acima e armazenamento de objetos em um gerenciamento de diretório unificado, controle de segurança unificado e gerenciamento de dados unificado. Estamos tateando nossos caminho a seguir.

O segundo ponto são os recursos de armazenamento subjacente mais rápidos, mais estáveis e de menor custo. No momento, a maior dificuldade em todos os cenários é o armazenamento de objetos. As vantagens do armazenamento de objetos são estabilidade e baixo custo. Ao mesmo tempo, o armazenamento de objetos está em constante iteração. Por enquanto, acho que, se o big data nativo da nuvem se desenvolver, o armazenamento de objetos deve fornecer melhor desempenho sob a premissa de garantir a estabilidade.

Ao mesmo tempo, o S3 pode alegar oferecer suporte a consistência forte, mas no momento entendo que o design de arquitetura baseado em armazenamento de objetos pode ser difícil de alcançar consistência forte ou, para alcançar consistência forte, é necessário sacrificar algumas coisas. Isso pode ser uma necessidade. Uma questão de equilíbrio. O JuiceFS suporta nativamente consistência forte, o que é muito amigável para plataformas de big data.

O terceiro ponto é um mecanismo de consulta mais inteligente, eficiente e fácil de usar. Para estender o pensamento sobre a integração de lagos e armazéns mencionados acima, a integração de lagos e armazéns ainda está em estágios iniciais de desenvolvimento e pode levar de 5 a 10 anos de desenvolvimento. A Databricks e a Microsoft estão tentando construir um mecanismo MPP vetorizado no data lake, na esperança de promover a arquitetura integrada do lake e do warehouse. Esta pode ser uma direção de desenvolvimento futuro, mas parece que não há como usar um mecanismo para atender às necessidades de todos os cenários em um curto espaço de tempo.

Nossa arquitetura atual é basicamente equipada com todos os mecanismos de consulta, como Spark, Flink, banco de dados relacional (para cenários OLTP), banco de dados de séries temporais e banco de dados OLAP. Em princípio, é melhor usar quem é melhor, e nossa camada superior irá gerenciá-lo por meio de um middleware unificado. Outro exemplo é o Snowflake, que embora já suporte a consulta de dados estruturados e semiestruturados ao mesmo tempo, ainda não está claro como suportar dados não estruturados (como fotos, voz e vídeo) envolvidos em inteligência artificial no futuro. claro. No entanto, acho que esta é definitivamente uma direção de desenvolvimento futuro. Li Auto também tem um cenário de inteligência artificial semelhante, então vamos explorar e construir junto com várias partes de negócios.

Por fim, o objetivo final de todo o desenvolvimento de big data é concluir a análise de dados com o menor custo e o mais alto desempenho, de modo a obter valor comercial real .

Se você for útil, preste atenção ao nosso projeto Juicedata/JuiceFS ! (0ᴗ0✿)