Implementação de Flow Registry para armazenar e gerenciar fluxos versionados.

Integração com NiFi para permitir armazenamento, retenção e atualização de fluxos versionados do Flow Registry.

Administração do Registry para definição de usuários, grupos e políticas.

Tamanho pequeno e baixo consumo de recursos.

Gestão centralizada de agentes.

Geração de proveniência de dados com toda a cadeia de custódia da informação.

Integração com NiFi para gerenciamento de fluxo de dados subsequente.

Entrega Garantida: A filosofia principal do NiFi é que, mesmo em altíssima escala, a entrega garantida é a regra. Isto é alcançado pelo uso eficaz do WAL(log de gravação antecipada) e repositorio de conteúdo persistentes. Juntos eles são desenhados para permitir altas taxas de transações, distribuição de carga efetiva, copy-on-write e para "jogar" com as forças dos tradicionais read-writes no disco.

Data Buffering w/ Back Pressure e Pressure Release: NiFi suporta o armazenamento em buffer de todos os dados da fila e tem a capacidade de fornecer back pressure àquelas filas que atingiram os limites ou para "envelhecer" os dados quando atingem uma idade especificada (seu valor pereceu).

Enfileiramento priorizado: NiFi permite configurar um ou mais esquemas de priorização para a recuperação de dados de uma fila. O default é "primeiro o mais antigo" mas há momentos em que dados "mais novos", maiores, ou algum outro esquema personalizado são a regra.

Flow Specific QoS: (latência vs trroughput, baixa tolerância, etc.): Há pontos no Dataflow onde o dado é absolutamente crítico e intolerante a falhas. Há ainda momentos em que devem ser processados e entregues em segundos para gerar algum valor. NiFi habilita o refinamento da configuração de fluxo.

Comando e Controle Visual: Dataflows podem se tornar complexos. Proporcionar uma boa expressão visual pode ajudar a reduzir a complexidade e identificar áreas que precisam ser simplificadas. NiFi habilita o estabelecimento visual de Dataflows em tempo real. Mudanças no dataflow entram em vigor imediatamente. As alterações são refinadas e isoladas nos componentes impactados. Não é necessário interromper um fluxo inteiro ou conjunto de fluxos apenas para realizar uma modificação específica.

Templates: Dataflows tendem a ser altamente orientados a padrões e embora existam muitos caminhos diferentes para solucionar um problema, o compartilhamento de boas práticas por especialistas no assunto beneficia a todos, além de permitir que os próprios especialistas se beneficiem com a colaboração dos demais.

Proveniência de dados: NiFi registra, indexa e disponibiliza automaticamente dados de proveniência à medida que os objetos fluem pelo sistema, mesmo em fan-in, fan out, transformações e outros. Estas informações se tornam extremamente criticas no suporte à conformidade, solução de problemas, otimizações e outros cenários.

Recovery/gravação de buffer contínuo de histórico refinado: O repositório de conteudo NiFi é desenhado para agir como um buffer contínuo do history. Dado é removido do repositório de conteúdo apenas quando "envelhece" ou quando é necessário mais espaço. Isto combinado com capacidade de proveniência cria uma base incrivelmente útil para permitir o "click-to-content", download de conteúdo, reprodução, tudo num ponto específico do ciclo de vida de um objeto o qual pode abranger gerações.

System to System: Um Dataflow só é bom se for seguro. NiFi, em qualquer ponto do Dataflow, oferece troca segura com o uso de protocolos de criptografia como SSL bidirecional. Adicionalmente, permite que o fluxo criptografe e descriptografe o conteúdo e use chaves compartilhadas ou outros mecanismos em ambos os lados da equação remetente/destinatário.

User to System: NiFi permite a autenticação SSL bidirecional e provê autorização "plugável" para controlar o acesso pelo usuário em niveis específicos (somente leitura, gerenciador de fluxo de dados, administrador). Se um usuário inserir uma propriedade confidencial (como uma senha) no fluxo, ela será imediatamente criptografada no lado do servidor e nunca mais exposta no lado do cliente, mesmo em seu formato criptografado.

Autorização multi-locatário: O nivel de autoridade de um Dataflow é aplicado a cada componente, viabilizando que usuário admin tenha um nivel refinado de controle de acesso. Significa que cada cluster NiFi é capaz de lidar com os requisitos de uma ou mais organizações. Comparada a topologias isoladas, a autorização multi-locatário permite um modelo de autoserviço para gestão do dataflow e que cada time ou organização gerencie fluxos com total consciência do restante do fluxo, para os quais não têm acesso.

Extensão: NiFi é construído para extensão, e como tal, é uma plataforma na qual os processos de Dataflow podem ser executados e interagir de maneira repetitiva e previsivel.

Isolamento do Carregador de classe (classloader): Para qualquer sistema baseado em componentes, problemas de dependência podem ocorrer. NiFi endereça isto provendo um modelo de carga de classe personalizado, garantindo que cada pacote de extensão seja exposto a um conjunto muito limitado de dependências. Como resultado, extensões podem ser construídas sem se preocupar se podem entrar em conflito com outra extensão. O conceito destes pacotes de extensão é chamado "arquivos NiFi".

Protocolo de comunicação Site-to-Site: O protocolo de comunicação preferencial entre instâncias NiFi é o Protocolo NiFi Site-to-Site (s2s). S2S facilita a transferência de dados de uma instância NiFi para outra de forma eficiente e segura. As bibliotecas do cliente NiFi podem ser facilmente construídas e agrupadas em outros aplicativos ou dispositivos para se comunicar com o NiFi via S2S. Tanto o protocolo baseado em socket quanto o HTTP(s) são suportados no S2S como o protocolo de transporte subjacente, tornando possível incorporar um servidor proxy na comunicação S2S.

Scale-out: (Expansão / Clustering)* NiFi é desenhado para escalabilidade horizontal por meio do uso de clustering de vários nós. Se um único nó for provisionado e configurado para lidar com centenas de MB por segundo, um Cluster modesto pode ser configurado para lidar com GB por segundo. Isto traz desafios de balanceamento de carga e failover entre NiFi e os sistemas dos quais obtem dados. O uso de protocolos baseados em filas assíncronas, como serviços de mensagem, kafka, etc. pode ajudar. O recurso site-to-site também é muito eficaz, pois é um protocolo que permite que o NiFi e um cliente (incluindo outro Cluster) conversem entre si, compartilhem informações sobre carregamento e troquem dados portas autorizadas específicas.

Scale-up e down: NiFi é também desenhado para scale-up e scale-down de uma maneira muito flexível. Em termos de "throughput", do ponto de vista da estrutura NiFi, é possível aumentar o número de tarefas simultâneas, no processador, na guia agendamento, durante a configuração. Isso permite que mais processos sejam executados simultaneamente, provendo grande throughput. Do outro lado do espectro, o NiFi pode ser dimensionado para execução em dispositivos de ponta, onde os recursos de hardware são limitados.

A documentação sempre deve ser fornecida para que todos possam utilizar o componente com facilidade.

Consistência (convenções de nomenclatura), simplicidade e clareza são princípios fundamentais para tornar esta experiência adequada.

pode tornar o processador muito complexo.

Se o processador não conseguir se comunicar com um serviço remoto, encaminhará os dados para um relacionamento failure e ficará responsável por realizar a tradução dos dados novamente, e novamente…​

Se tivermos 5 diferentes processadores traduzindo dados de entrada em novo formato antes de enviá-los, teremos uma grande quantidade de codigo duplicado. Se o esquema mudar, muitos processadores devem ser atualizados.

Estes dados intermediários são descartados quando o processador termina de enviar para o serviço remoto. O formato intermediário pode ser útil para outros processadores.

Processadores que extraem dados de um sistema remoto são denominados:

Processadores que enviam dados para um sistema remoto são denominados:

Nomes de relacionamentos são caixa baixa e usam espaço para delinear palavras.

Nomes de propriedade devem usar palavras significativas, como o título de um livro.

subpacote documentation : Fornecem documentação ao usuário.

Subpacote lifecycle: Instruem a estrutura sobre quais métodos devem ser chamados no processador para responder aos eventos de ciclo de vida apropriados.

Subpacote behavior: Ajudam a estrutura a entender como interagir com o processador em termos de agendamento e comportamento geral.

EventDriven: instrui a estrutura de que o processador pode ser agendado usando a estrategia de agendamento orientada a eventos.

SideEffectFree: indica que o processador não tem nenhum efeito colateral externo ao NiFi.

SupportsBatching: indica que não há problema em a estrutura agrupar várias confirmações de ProcessSession em uma única confirmação.

TriggerSerially: impede que o usuário agende mais de uma thread concorrente para executar o método onTrigger de uma vez.

PrimaryNodeOnly: restringe a execução do processador apenas no Primary Node.

TriggerWhenAnyDestinationAvailable: Indica que o processador deve ser executado se algum relacionamento estiver "disponível" mesmo se uma das filas estiver cheia.

TriggerWhenEmpty: ignora o tamanho das filas de entrada e aciona o processador, independentemente de haver ou não dados em uma fila de entrada.

InputRequirement: ao fornecer um valor por meio desta anotação (INPUT_REQUIRED, INPUT_ALLOWED ou INPUT_FORBIDDEN), a estrutura saberá quando deve ser invalidada ou se o usuário deve ou não ser capaz de estabelecer uma conexão com o processador.