Introdução ao MapReduce Video Tutorial

2166 Views

4.1 Introdução ao YARN e MapReduce

Olá, bem-vindo ao curso Big Data e Hadoop Developer oferecido pela Simplilearn. Esta lição apresentará o YARN, que faz parte do Hadoop 2.7 e seus componentes. Também abrange os conceitos do MapReduce e suas operações.

4.2 Objetivos

Depois de completar esta lição, você será capaz de: • Descrever a arquitetura do YARN • Listar os diferentes componentes do YARN • Explicar os conceitos do MapReduce • Listar os passos para instalar o Hadoop na máquina Ubuntu • Explicar os papéis do usuário e do sistema

4.3 Por que o YARN

Antes de 2012, os usuários podiam escrever programas MapReduce usando linguagens de script como Java, Python e Ruby. Eles também poderiam usar Pig, uma linguagem usada para transformar dados. Independentemente da linguagem utilizada, sua implementação dependia do modelo de processamento MapReduce. O Hadoop versão 2.0 foi lançado em maio de 2012 com a introdução de 'Yet Another Resource Navigator', popularmente conhecido como YARN. O YARN é chamado de sistema operacional do Hadoop. Significativamente, não estamos limitados a trabalhar com a estrutura MapReduce frequentemente latente, pois ela suporta vários modelos de processamento além do MapReduce, como o Spark. Outros USPs da YARN são melhorias significativas de desempenho e um mecanismo de execução flexível.

4.4 O que é o YARN?

YARN é um gerenciador de recursos. Ele foi criado separando o mecanismo de processamento e a função de gerenciamento do MapReduce. Ele monitora e gerencia cargas de trabalho, mantém um ambiente de multilocação, gerencia os recursos de alta disponibilidade do Hadoop e implementa controles de segurança. Em suma, o Hadoop YARN é uma tentativa de levar o Apache Hadoop além do MapReduce para processamento de dados.

4,5 YARN — Real Life Connect

O Yahoo foi a primeira empresa a adotar o Hadoop em grande escala e é um criador de tendências no ecossistema Hadoop. No final de 2012, ela se esforçou para lidar com o processamento iterativo e de fluxo de dados na infraestrutura do Hadoop, devido às limitações do MapReduce. Ambos foram importantes para o Yahoo ao facilitar sua migração da computação em lote para a computação contínua. Depois de implementar o YARN no primeiro trimestre de 2013, o Yahoo instalou mais de 30.000 nós de produção no Spark para processamento iterativo, Storm para processamento de fluxo e Hadoop para processamento em lote, que permite manipular mais de 100 bilhões de eventos (cliques, impressões, conteúdo de email e meta-dados e assim por diante) por dia. Tal solução só foi possível depois que o YARN foi introduzido e várias estruturas de processamento foram implementadas.

4.6 Infraestrutura do YARN

A infra-estrutura YARN é responsável por fornecer os recursos computacionais, tais como CPUs ou memória necessária para execuções de aplicativos. A infraestrutura do YARN e a federação do HDFS são completamente desacopladas e independentes: o primeiro fornece recursos para executar um aplicativo, enquanto o segundo fornece armazenamento. O framework MapReduce é apenas um dos muitos frameworks possíveis que rodam sobre o YARN, embora, atualmente, seja o único implementado. A ideia fundamental do MRv2 é dividir as duas principais funcionalidades; gerenciamento de recursos e agendamento e monitoramento de tarefas em daemons separados. Existe um ResourceManager global e ApplicationMaster por aplicativo.

4.7 Infraestrutura do YARN (continuação)

Os três elementos importantes da arquitetura YARN são: • O ResourceManager, ou RM, geralmente numerado um por cluster, é o mestre e sabe onde os escravos estão localizados, conhecido como Reconhecimento de Rack, e quantos recursos eles possuem. O RM executa vários serviços, sendo o mais importante deles o Resource Agendador que decide como atribuir os recursos. • O NodeManager, do qual pode haver muitos em um cluster, é o escravo da infraestrutura. Quando ele inicia, ele se anuncia ao RM e envia periodicamente um heartbeat para o RM. Cada NodeManager oferece recursos para o cluster, sendo a capacidade do recurso a quantidade de memória e o número de vcores. No tempo de execução, o Agendador de Recursos decide como usar essa capacidade. Um contêiner é uma fração da capacidade do NodeManager e é usado pelo cliente para executar um programa. Cada NodeManager recebe instruções do ResourceManager e relata e manipula contêineres em um único nó. • O ApplicationMaster é um processo específico da estrutura que negocia recursos para um único aplicativo, ou seja, um único trabalho ou um gráfico acíclico direcionado de tarefas, que é executado no primeiro contêiner alocado para o propósito. Cada ApplicationMaster solicita recursos do ResourceManager e trabalha com contêineres fornecidos pelo NodeManagers.

4.8 ResourceManager

O RM arbitra recursos disponíveis no cluster entre aplicativos concorrentes, com o objetivo de utilização máxima do cluster. Ele inclui um agendador conectável chamado YarnScheduler, que permite políticas diferentes para gerenciar restrições como capacidade, justiça e Acordos de Nível de Serviço. O ResourceManager possui dois componentes principais: o Scheduler e o ApplicationsManager. O Scheduler é responsável por alocar recursos para vários aplicativos em execução, dependendo das restrições comuns de capacidades, filas e assim por diante. O Agendador não monitora nem rastreia o status do aplicativo. Além disso, ele não garante a reinicialização de tarefas que falharam devido a falhas no aplicativo ou a falhas de hardware. O Agendador executa sua função com base nos requisitos de recursos dos aplicativos; ele faz isso com base na noção abstrata de um contêiner de recursos que incorpora elementos como memória, CPU, disco, e rede. O Scheduler possui um plug-in de política, que é responsável por particionar os recursos do cluster entre várias filas e aplicativos. Os planejadores MapReduce atuais, como o CapacityScheduler e o FairScheduler, são alguns exemplos do plug-in. O CapacityScheduler suporta filas hierárquicas para permitir o compartilhamento mais previsível de recursos de cluster. No núcleo do ResourceManager, existe uma interface chamada ApplicationsManager, que mantém uma lista de aplicativos que foram submetidos, estão em execução ou concluídos. O ApplicationManager é responsável por aceitar envios de tarefas, negociar o primeiro contêiner para executar o ApplicationMaster específico do aplicativo e reiniciar o contêiner do ApplicationMaster em caso de falha.

4.9 Outros Componentes do ResourceManager

A figura mostrada aqui exibe todos os componentes internos do ResourceManager. O ResourceManager se comunica com os clientes do aplicativo por meio de uma interface chamada ClientService. Um cliente pode enviar ou encerrar um aplicativo e obter informações sobre a fila de agendamento ou estatísticas de cluster por meio do ClientService. As solicitações administrativas são atendidas por uma interface separada chamada AdminService, através da qual os operadores podem obter informações atualizadas sobre a operação do cluster. Em paralelo, o ResourceTrackerService recebe pulsações de nós do NodeManager para rastrear nós novos ou descomissionados. O NMLivelinessMonitor e o NodesListManager mantêm um status atualizado de quais nós são saudáveis ​​para que o planejador e o ResourceTrackerService possam alocar o trabalho apropriadamente. O ApplicationMasterService gerencia ApplicationMasters em todos os nós, mantendo o agendador informado. O AMLivelinessMonitor mantém uma lista de ApplicationMasters e seus últimos tempos de heartbeat, para permitir que o ResourceManager saiba quais aplicativos são saudáveis ​​no cluster. Qualquer ApplicationMaster que não pulsar dentro de um determinado intervalo é marcado como morto e re-programado para ser executado em um novo contêiner.

4.10 ResourceManager no modo HA

Antes do Hadoop 2.4, o ResourceManager era o único ponto de falha em um cluster YARN. O recurso Alta disponibilidade, ou HA, adiciona redundância na forma de um par ResourceManager ativo / em espera para remover esse ponto único de falha. O ResourceManager HA é realizado através da arquitetura Active / Standby: em qualquer ponto do tempo, um dos RMs está ativo e um ou mais RMs estão no modo Standby esperando para assumir caso algo aconteça com o Active. O acionador para transição para ativo é proveniente do administrador, através da CLI, ou onde o failover automático é ativado, por meio do controlador de failover integrado. Vamos dar uma olhada no Failover Automático. Os RMs têm uma opção para incorporar o ActiveStandbyElector baseado em Zookeeper para decidir qual RM deve ser o Ativo. Quando o Ativo é desativado ou não responde, outro RM é automaticamente eleito para ser o Ativo. Observe que, não há necessidade de executar um daemon ZKFC separado, como no HDFS, porque o ActiveStandbyElector incorporado no RMs atua como um detector de falhas e um líder eleitor.

4,11 ApplicationMaster

O ApplicationMaster no YARN é uma biblioteca específica do framework, que negocia recursos do RM e trabalha com o NodeManager ou Managers para executar e monitorar contêineres e seu consumo de recursos. Enquanto um aplicativo está em execução, o ApplicationMaster gerencia o ciclo de vida do aplicativo, ajustes dinâmicos ao consumo de recursos, fluxo de execução, falhas e fornece status e métricas. O ApplicationMaster é arquitetado para suportar uma estrutura específica e pode ser escrito em qualquer idioma desde que sua comunicação com o NodeManagers e o ResourceManager é feita usando protocolos de comunicação extensíveis. O ApplicationMaster pode ser personalizado para estender a estrutura ou executar qualquer outro código. Por isso, o ApplicationMaster não é considerado confiável e não é executado como um serviço confiável. Na realidade, todo aplicativo tem sua própria instância de um ApplicationMaster. No entanto, é possível implementar um ApplicationMaster para gerenciar um conjunto de aplicativos, por exemplo, um ApplicationMaster para Pig ou Hive para gerenciar um conjunto de tarefas MapReduce.

4.12 NodeManager

Quando um contêiner é concedido a um aplicativo, o NodeManager configura o ambiente do contêiner, incluindo as restrições de recursos especificadas na concessão e quaisquer dependências, como dados ou arquivos executáveis. O NodeManager monitora a integridade do nó, reportando-se ao ResourceManager quando ocorre um problema de hardware ou software, para que o agendador possa desviar as alocações de recursos para nós saudáveis ​​até que o problema seja resolvido. O NodeManager também oferece vários serviços para contêineres em execução no nó, como um serviço de agregação de logs. O NodeManager é executado em cada nó e gerencia o seguinte: • Gerenciamento do ciclo de vida do contêiner • Dependências de contêineres • Arrendamentos de contêineres • Uso de recurso de nó e contêiner • Integridade do nó • Gerenciamento de log • Status do contêiner e do nó de relatório para o ResourceManager.

4,13 Recipiente

Um contêiner YARN é o resultado de uma alocação bem-sucedida de recursos, o que significa que o ResourceManager concedeu a um aplicativo uma concessão para usar um conjunto específico de recursos em determinados valores em um nó específico. O ApplicationMaster apresenta a concessão ao NodeManager no nó em que o contêiner foi alocado, obtendo acesso aos recursos. Para iniciar o contêiner, o ApplicationMaster deve fornecer um contexto de inicialização do contêiner ou CLC que inclua as seguintes informações: • Variáveis ​​de ambiente • Dependências, ou seja, recursos locais, como arquivos de dados ou objetos compartilhados antes do lançamento • Tokens de segurança • O comando necessário para criar o processo que o aplicativo quer lançar O CLC faz É possível que o ApplicationMaster use contêineres para executar uma variedade de tipos diferentes de trabalho, desde scripts de shell simples até aplicativos para máquinas virtuais.

4.14 Aplicativos em execução no YARN

Devido à abordagem genérica do YARN, um cluster do Hadoop YARN executando muitas cargas de trabalho diferentes é agora uma possibilidade. Isso significa que um único cluster do Hadoop em seu data center pode executar o MapReduce, o Giraph, o Storm, o Spark, o Tez / Impala, o MPI e muito mais. A abordagem de cluster único obviamente oferece várias vantagens, incluindo: • Maior utilização de cluster, em que os recursos não utilizados por uma estrutura podem ser consumidos por outra • Custos operacionais menores, porque somente um cluster "faça-tudo" precisa ser gerenciado e ajustado • Movimento de dados reduzido, pois não há necessidade de mover dados entre o Hadoop YARN e sistemas em execução em diferentes grupos de máquinas

4.15 Inicialização do aplicativo no YARN

Suponha que os usuários enviem aplicativos para o ResourceManager digitando o comando hadoop jar. O ResourceManager mantém a lista de aplicativos em execução no cluster e recursos disponíveis em cada NodeManager ativo. O ResourceManager determina qual aplicativo deve obter uma parte dos recursos do cluster a seguir. A decisão está sujeita a muitas restrições, como capacidade de fila, ACLs e justiça. Quando o ResourceManager aceita um novo envio de aplicativo, uma das primeiras decisões que o Agendador faz é selecionar um contêiner no qual o ApplicationMaster será executado. Depois que o ApplicationMaster é iniciado, ele é responsável por todo o ciclo de vida desse aplicativo. Primeiro, ele envia solicitações de recursos ao ResourceManager para solicitar que os contêineres executem as tarefas do aplicativo. Uma solicitação de recurso é simplesmente uma solicitação para vários contêineres que atendem aos requisitos de recursos, como: • Quantidade de recursos, expressa como megabytes de memória e compartilhamentos de CPU • Local preferencial, especificado por nome do host, nome do rack ou estrela para indicar nenhuma preferência • Prioridade dentro deste aplicativo, e não entre vários aplicativos O ResourceManager concede um contêiner, expresso como ID do contêiner e nome do host, que satisfaz os requisitos do ApplicationMaster. Um contêiner permite que um aplicativo use uma determinada quantidade de recursos em um host específico. Depois que um contêiner é concedido, o ApplicationMaster pergunta ao NodeManager, gerenciando o host no qual o contêiner foi alocado para usar esses recursos, para iniciar uma tarefa específica do aplicativo. Essa tarefa pode ser qualquer processo escrito em qualquer estrutura, como uma tarefa MapReduce ou uma tarefa Giraph. O NodeManager não monitora tarefas; ele monitora apenas o uso de recursos nos contêineres, por exemplo, mata um contêiner se consome mais memória do que inicialmente alocado. Ao longo de sua vida, o ApplicationMaster negocia contêineres para iniciar todas as tarefas necessárias para concluir sua aplicação. Ele também monitora o progresso de um aplicativo e suas tarefas, reinicia tarefas com falha em contêineres recém-solicitados e relata o progresso de volta ao cliente que enviou o aplicativo. Após a conclusão do aplicativo, o ApplicationMaster se desliga e libera seu próprio contêiner. Embora o ResourceManager não execute nenhum monitoramento das tarefas em um aplicativo, ele verifica a integridade dos ApplicationMasters. Se o ApplicationMaster falhar, ele poderá ser reiniciado pelo ResourceManager em um novo contêiner. Em suma, o ResourceManager cuida dos ApplicationMasters, enquanto o ApplicationMasters cuida das tarefas.

4.16 Inicialização do aplicativo em YARN (continuação)

A inicialização do aplicativo pode ser resumida da seguinte forma: • um cliente envia um aplicativo ao Resource Manager • o ResourceManager aloca um contêiner • o ResourceManager contata o NodeManager relacionado • o NodeManager inicia o contêiner • o Container executa o Application Master

4,17 Papel do AppMaster na inicialização do aplicativo

O ApplicationMaster é responsável pela execução de um único aplicativo. Ele solicita o Resource Scheduler para contêineres e executa programas específicos, por exemplo, o principal de uma classe Java, nos contêineres alocados. O ApplicationMaster conhece a lógica do aplicativo e, portanto, é específico do framework. O framework MapReduce fornece sua própria implementação de um ApplicationMaster. O ResourceManager é um ponto único de falha no YARN. Usando ApplicationMasters, o YARN espalha os metadados relacionados à execução de aplicativos no cluster. Isso reduz a carga do ResourceManager e o torna rapidamente recuperável.

4.18 Por que o MapReduce

Antes de 2004, grandes quantidades de dados eram armazenados em servidores únicos. Se algum programa executasse uma consulta de dados armazenados em vários servidores, a integração lógica de resultados de pesquisa e análises de dados seria um pesadelo. Sem mencionar os enormes esforços e despesas envolvidos. A ameaça de perda de dados, o desafio de backup de dados e a reduzida escalabilidade resultaram em um problema de bola de neve. Para combater isso, o Google introduziu o MapReduce em dezembro de 2004. Com isso, a análise dos conjuntos de dados que levariam de 8 a 10 dias foi feita provavelmente em menos de 10 minutos. As consultas podem ser executadas simultaneamente em vários servidores e agora integram logicamente os resultados da pesquisa e analisam os dados em tempo real. O USP do MapReduce é sua tolerância a falhas e escalabilidade.

4.19 O que é o MapReduce?

O MapReduce é um modelo de programação que processa e analisa simultaneamente enormes conjuntos de dados logicamente em clusters separados. Enquanto Map classifica os dados, o Reduce o segrega em clusters lógicos, removendo assim dados "ruins" e retendo as informações necessárias.

4.20 MapReduce - Conexão Vida Real

Nutri é uma facilidade de correio conhecida. Ele transporta documentos em todo o mundo. Quando os funcionários recebem um mensageiro, eles codificam no país a ser transportado. A equipe de expedição, em seguida, separa o correio pelo código de cores marcado. Assim, a recepção funciona como "Mapa" e a equipe de despacho como "Reduzir".

4.21 MapReduce - Analogia

As etapas MapReduce estão listadas aqui e representam a contagem manual de votos após uma eleição como uma analogia. Passo 1: Os boletins de voto de cada urna são contados por um contador. Esta é uma etapa pré-MapReduce chamada divisão de entrada. Passo 2: Contadores de todos os estandes contam os boletins de voto em paralelo. Como vários caixas estão trabalhando em um único trabalho, o tempo de execução do trabalho será mais rápido. Isso é chamado de método Map. Etapa 3: A contagem das urnas de cada estande sob as posições de assembléia e assento do parlamento é encontrada, e a contagem total para os candidatos é gerada. Isso é conhecido como o método Reduzir. Assim, mapeie e reduza a ajuda para executar o trabalho mais rapidamente do que pode ser feito usando a contagem individual.

4.22 MapReduce - Analogia (continuação)

Como vimos na tela anterior, a analogia da contagem de votos ajuda a entender a utilidade do MapReduce. O principal motivo para realizar o mapeamento e a redução é acelerar a execução do trabalho de um processo específico. Isso pode ser feito dividindo-se um processo em várias tarefas, permitindo assim o paralelismo. Se uma pessoa conta todos os boletins de voto ou espera que outro termine a contagem das urnas, pode levar um mês para receber os resultados das eleições. Quando muitas pessoas contam as cédulas simultaneamente, os resultados são obtidos em um ou dois dias. É assim que o MapReduce funciona.

4.23 MapReduce - Exemplo

Nesta tela, a operação MapReduce é explicada usando um problema em tempo real. O trabalho é realizar uma contagem de palavras do parágrafo dado. O parágrafo é: "Esta rápida raposa marrom salta sobre um cão preguiçoso. Um cachorro é o melhor amigo de um homem". O processo MapReduce consiste em entrada, divisão, mapeamento, embaralhamento e reduzindo as fases. A fase de entrada refere-se ao fornecimento de dados para os quais o processo MapReduce deve ser executado. O parágrafo é usado como entrada aqui. A fase de divisão refere-se à conversão de uma tarefa enviada pelo cliente em várias tarefas. Neste exemplo, o trabalho é dividido em duas tarefas. A fase de Mapeamento refere-se à geração de um par de valores-chave para a entrada. Como este exemplo é sobre a contagem de palavras, a frase é dividida em palavras usando o método de substring para gerar palavras de linhas. A fase de Mapeamento garantirá que as palavras geradas sejam convertidas em chaves e um valor padrão de um seja atribuído a cada chave. A fase de embaralhamento se refere à classificação dos dados com base nas chaves. Conforme mostrado na tela, as palavras são classificadas em ordem crescente. A última fase é a fase de redução. Nesta fase, os dados são reduzidos com base nas chaves repetidas, incrementando o valor. A palavra “cachorro” e a letra “a” são repetidas. Portanto, o redutor excluirá a chave e incrementará o valor, dependendo do número de ocorrências da chave. É assim que a operação MapReduce é executada.

4.24 Execução de Mapa

A execução do mapa consiste em cinco fases: fase do mapa, fase da partição, fase aleatória, fase de classificação e fase de redução. • Fase do mapa: na fase do mapa, a divisão da entrada atribuída é lida do HDFS, onde uma divisão pode ser um bloco de arquivos por padrão. Além disso, a entrada é analisada em registros como pares de valores-chave. A função de mapa é aplicada a cada registro para retornar zero ou mais novos registros. Essas saídas intermediárias são armazenadas no sistema de arquivos local como um arquivo. Eles são classificados primeiro pelo número do depósito e, em seguida, pela chave. No final da fase do mapa, as informações são enviadas para o nó principal de sua conclusão. • Fase de partição: Na fase de partição, cada mapeador deve determinar qual redutor receberá cada uma das saídas. Para qualquer chave, independentemente de qual instância do mapeador gerou, a partição de destino é a mesmo. Note que o número de partições será igual ao número de redutores. • Fase de embaralhamento: na fase de embaralhamento, os dados de entrada são buscados em todas as tarefas do mapa para a parte correspondente ao bucket da tarefa de redução. • Fase de classificação: na fase de classificação, uma espécie de mesclagem de todas as saídas do mapa ocorre em uma única execução. • Reduzir Fase: Na fase de redução, uma função de redução definida pelo usuário é aplicada à execução mesclada. Os argumentos são uma chave e uma lista correspondente de valores. A saída é gravada em um arquivo no HDFS.

4.25 Execução de Mapa - Ambiente Distribuído de Dois Nós

Os mapeadores em cada um dos nós recebem uma divisão de entrada de blocos. Com base no formato de entrada, o Leitor de Registros lê a divisão como um par de valores-chave. A função de mapa é aplicada a cada registro para retornar zero ou mais novos registros. Essas saídas intermediárias são armazenadas no sistema de arquivos local como um arquivo. Posteriormente, um particionador atribui os registros a um redutor. Na fase de embaralhamento, os pares intermediários de valor-chave são trocados por todos os nós. Os pares de valor-chave são então classificados aplicando a chave e reduzindo a função. A saída é armazenada no HDFS com base no formato de saída especificado.

4.26 MapReduce Essentials

O essencial de cada fase do MapReduce é mostrado na tela. A entrada do trabalho é especificada em pares de valores-chave. Cada trabalho consiste em dois estágios. Primeiro, uma função de mapa definida pelo usuário é aplicada a cada registro de entrada para produzir uma lista de pares de valores-chave intermediários. Em segundo lugar, uma função de redução definida pelo usuário é chamada uma vez para cada chave distinta na saída do mapa. Em seguida, a lista de valores intermediários associados a essa chave é passada. O número de tarefas reduzidas pode ser definido pelos usuários. Cada tarefa de redução é atribuída a um conjunto de grupos de registros, que são registros intermediários que correspondem a um grupo de chaves. Para cada grupo, uma função de redução definida pelo usuário é aplicada aos valores de registro nesse grupo. As tarefas de redução lidas em todos os mapas


{{detail.h1_tag}}

{{detail.display_name}}
{{author.author_name}} {{author.author_name}}

{{author.author_name}}

{{detail.full_name}}

Published on {{detail.created_at| date}} {{detail.duration}}

  • {{detail.date}}
  • Views {{detail.downloads}}
  • {{detail.time}} {{detail.time_zone_code}}

Registrants:{{detail.downloads}}

Downloaded:{{detail.downloads}}

About the {{detail.about_title && detail.about_title != null ? detail.about_title : 'On-Demand Webinar'}}

About the {{detail.about_title && detail.about_title != null ? detail.about_title : 'Webinar'}}

Hosted By

Profile

{{author.author_name}}

{{author.author_name}}

{{author.about_author}}

About the {{detail.about_title && detail.about_title != null ? detail.about_title : 'Ebook' }}

About the {{detail.about_title && detail.about_title != null ? detail.about_title : 'Ebook' }}

View {{detail.about_title && detail.about_title != null ? detail.about_title : 'On-Demand Webinar'}}

Webcast

Register Now!

Download the {{detail.about_title && detail.about_title != null ? detail.about_title : 'Ebook'}}!

First Name*
Last Name*
Email*
Company*
Phone Number*

View {{detail.about_title && detail.about_title != null ? detail.about_title : 'On-Demand Webinar'}}

Webcast

Register Now!

{{detail.about_title && detail.about_title != null ? detail.about_title : 'Webinar'}} Expired

Download the {{detail.about_title && detail.about_title != null ? detail.about_title : 'Ebook'}}

Email
{{ queryPhoneCode }}
Phone Number

Show full article video

Name Date Place
{{classRoomData.Date}} {{classRoomData.Place}} View Details

About the Author

{{detail.author_biography}}

About the Author

{{author.about_author}}

Recommended articles for you

{{ article.title }}

Article