40.proposta.tex

% !TeX root = ./00.ppgcc-2020.tex

\chapter{Proposta e Metodologia}\label{cha:proposta}

% % Uma Implementação paralela do algoritmo de Detecção de Novidade em Streams MINAS

% A Internet das Coisas (\iot) é composta por vastas quantidades de dispositivos
% conectados à Internet e distribuídos geograficamente.
% Com capacidades diversas providas por elementos como sensores e atuadores, esses
% dispositivos produzem e consomem Fluxos Contínuos de Dados (\streams) com
% diversos objetivos.
% Alguns cenários de \iot envolvem a mineração desses fluxos (\streamMining) em busca de
% padrões para tomada de decisão e, por vezes requerem também baixa latência.
% Para casos de baixa latência ou alta vazão, conexões adequadas para
% processamento em nuvem nem sempre são possíveis ou desejáveis; para esses casos,
% a computação em névoa (\fog) é uma solução.

% O tema de \streamMining envolve a classificação de novos elementos,
% que podem tanto estar relacionados aos dados ou aos metadados das comunicações,
% com base em um modelo.
% \hlke{Porém, como \streams variam temporalmente e são ilimitados,}
% as classes contidas em um \stream não são todas previamente conhecidas.
% A identificação e classificação de novas classes em \streams é denominada
% Detecção de Novidades (\novelty, \nd) em \streams.

% % \hlfa{Além dos aspectos}
% % \notafa{rever o parágrafo. Varios conceitos errados... a identificação de novas
% % classes é denominada detecção de novidade.... data stream variam temporalmente}
% % inerentes a \streamMining, são considerados na construção de um
% % \hlhl{sistema}
% % \notahl{Poderia reescrever a frase, evitando inversões na estrutura
% % sujeito/verbo e complementos. Yoda!}
% % que computa \streams a taxa de eventos
% % % (itens atômicos de um \stream)
% % gerados por cada produtor e o número de produtores nesse sistema, totalizando o
% % volume de eventos 
% % \notahl{qual sistema?}
% % \hlhl{do sistema}.
% % % Além do volume de eventos é necessário
% % Volumes elevados dificilmente são computados em apenas um nó (e muito menos em
% % um único núcleo processador) e por isso, esses sistemas \hlhl{geralmente} são distribuídos.

% Sistemas que utilizam \nd para \streams gerados por dispositivos \iot devem
% utilizar algoritmos que considerem os desafios inerentes a fluxos de dados
% (\evolution e \drift) para adequada detecção de novidades e, para tanto,
% requerem processamento em arquiteturas
% que atendam os requisitos de volume de mensagens e latência de detecção.
% O algoritmo MINAS é adequado para esse caso, pois trata os desafios de
% \streamMining, porém não tem ainda implementação que atenda os requisitos de
% volume e latência, especialmente para aplicações \iot onde um ambiente de \fog é
% atrativo.

% % \notahl{Com relação à proposta, será que é o caso de indicar que a
% % arquitetura apresentada é uma proposta inicial, que será refinada ao longo da
% % pesquisa?}

% Para preencher a lacuna de algoritmo de \nd em ambiente \fog, propõem-se então
% o \mfog, uma implementação distribuída do algoritmo MINAS 
% %sobre a plataforma \flink, que
% considerando  um ambiente de \fog.
% O \mfog descrito neste documento foi refinado com os resultados dos experimentos
% descritos na \refsec{resultados}. 
% % e poderá ser revisado ao longo da pesquisa conforme os resultados de outros experimentos evidenciarem obstáculos ou oportunidades de melhoria.

% % \nota{Reestruturar:
% %   A - remember,
% %   B - cenário (iot, fog, stream),
% %   C - problema (4.1, ND em fog, terminar com minas e cassales),
% %   D - solução (4.2, apresetnação, resumo \mfog, metodologia)
% % }
% % \nota{Falta: fog, processamento distribuído de streams, detecção de novidade}


% Este Capítulo apresenta a proposta deste trabalho e a metodologia estabelecida
% para atingir os objetivos.
Neste trabalho investiga-se uma arquitetura e implementação adequada para
executar \acf{ND} em ambiente de névoa para detecção de intrusão em redes de
dispositivos \acf{IoT}.
% In this work, we investigate an appropriate architecture for performing \nd at
% the edge, as a means of allowing small IoT devices to filter and detect undesirable
% network behavior.
Esta abordagem é baseada na arquitetura \arch \cite{Cassales2019} e no algoritmo
de \nd \minas \cite{Faria2016minas}.
% Our approach is based on the \arch architecture \cite{Cassales2019} and \nd
% techniques provide by the \minas algorithm \cite{Faria2016minas}.
Nomeada ``\mfog'', esta implementação do algoritmo \minas explora computação
distribuída habilitando o uso de computadores e dispositivos com recursos
limitados presentes no ambiente de névoa a realizar, além de tarefas habituais
de um \emph{gateway} \iot, a classificação e detecção de tráfego indesejável.
% Named \mfog, our distributed algorithm explores load balancing to enable low
% profile devices at the edge of the internet to also work on the classification
% and detection of unwanted traffic.

\section{Ambiente Físico, Impactos no Algoritmo e Arquitetura}

Nesta seção apresenta-se o ambiente físico escolhido, a relação deste ambiente
com o problema de detecção de intrusão em rede, as modificações no algoritmo
necessárias para adequação a este problema e ambiente e, por fim, a descrição
da arquitetura geral da presente proposta.

O ambiente físico do \mfog pode ser vista na Figura
\ref{fig:arq-fisica-mfog}, onde um dispositivo \emph{gateway} observa o tráfego
da rede local (sensores IoT) e entre a rede local e a nuvem.
A detecção de intrusão é executada de forma paralela e distribuída numa névoa de
dispositivos SBC (\emph{Single Board Computer}).
Este ambiente físico foi escolhido por aproximar os recursos comuns em redes
deste tipo mas o \mfog não é limitado a ela, podendo utilizar dispositivos de
borda ou névoa com recursos disponíveis para a tarefa de detecção de intrusão ou
novidades.

% \todo[inline]{Não sei se vão existir dispositivos SBC na borda para executar.
% Acho melhor deixar genérico, de que utilizaria quaisquer dispositivos na borda
% ou na névoa que tenha recursos suficientes para a tarefa. Você usou um SBC para
% validar a proposta, por este ter arquitetura semelhante à de vários dispositivos
% que podem estar presentes na borda.}


\begin{figure}[htb]
  \centerline{
    \includegraphics[width=0.6\linewidth,page=1]{figures/arq-mfog.png}
  }
  \caption{Ambiente Físico do \mfog.}
  \label{fig:arq-fisica-mfog}
\end{figure}


Um \acf{NIDS} monitora o tráfego em redes e analisa as características de cada
fluxo de rede com objetivo de identificar intrusos e tráfegos indesejados.
% monitor network traffic, and analyze the characteristics of each flow 
% to identify any intrusion or misbehavior.
No entanto, este problema requer respostas rápidas e acuradas \cite{DaCosta2019a}:
rapidez é necessária para executar uma ação adequada antes que
maior dano seja feito à rede, e para lidar com a velocidade do tráfego sem impor
atraso ou perda de pacotes na rede observada;
% However, this problem requires both fast and accurate response 
% fast response is needed to have a proper reaction before harm can be cast
% to the network and to cope with the traffic without imposing loss or delay
% in the \nids or observed network;
acurácia é necessária para não identificar padrões incorretamente, gerando
alarmes falsos ou ignorando ataques.
% accurate response is required as not to misidentify,
% especially the case of false positive that leads to false alarms.
% To achieve those goals, we leverage fog computing.

% In this work, we propose and assess \mfog, a distributed data stream
% novelty detection system based on the algorithm \minas for securing \iot networks.
% \mfog implements a distributed version of \minas according to the \arch
% architecture proposed in a previous work \cite{Cassales2019}, to execute in the
% edge where small devices and constrained resources may be prevalent.

Em cenários \iot comuns, dados podem ser capturados por sensores e pequenos dispositivos
computacionais e enviados para a nuvem se mais recursos
computacionais ou de armazenamento são necessários. Contudo, para \nids com 
requisito de resposta rápida, tal abordagem pode não ser viável. 
Para atender a essa necessidade a Computação em Névoa é uma alternativa promissora.
% In common \iot scenarios, data is captured by small devices and sent to the
% cloud for any compute or storage tasks, but this is not feasible in a \nids
% scenario.

A infraestrutura de Computação em Névoa oferece capacidades de realocar
parte do processamento e armazenamento dos provedores de nuvem, posicionando
dispositivos de capacidade intermediária próximos aos usuários e às fontes de dados.
% Fog computing infrastructure aims to offload processing from the cloud
% providers by placing edge devices closer to end-users and/or data sources.
% Para atingir estes objetivos, a presente proposta utiliza computação distribuída
% em névoa, permitindo processamento escalável e mais próximo da rede \iot.
Dada a natureza distribuída e o típico uso de pequenos computadores em cenários
de \iot e névoa, alguns desafios para implementação \nids são notáveis:
% However, given the distributed nature and the typical use of small computing
% devices in IoT scenarios, new challenges arise:
\begin{enumerate}[label=(\emph{\roman*})]

  \item O tráfego nas bordas da rede é inerentemente distribuído, sem uma
  entidade centralizadora que tenha acesso a todas as transmissões;
  
  \item A tarefa de classificação do algoritmo deve ocorrer em paralelo em
  diferentes nós;
  
  \item A tarefa de detecção de novidade, que provê a atualização do modelo,
  deve ser assíncrona;
    
  \item A complexidade do algoritmo (tempo e espaço) deve permitir sua execução em
  computadores modestos, isto é, pouca memória ($< 1GB$) e processadores de
  pouco desempenho.

\end{enumerate}

Nesta proposta, recursos em névoa são combinados para minimizar a latência entre
o recebimento (ingestão) do descritor de fluxo e a identificação (rotulagem)
daquele descritor de fluxo com uma classe do problema (normal ou ataque).
% \hlpa{Executam-se múltiplas}
Para tal fim, executa-se múltiplos processos da tarefa de classificação do
algoritmo \minas que é responsável pela identificação.
% In our proposal, fog and cloud computing resources are combined to minimize
% the time elapsed between a flow descriptor ingestion and intrusion alarm,
% performing the classification step of \minas running multiple
% classifier instances.

Após identificado o rótulo do descritor de fluxo, o par (rótulo, descritor de fluxo)
% \notaPA{Quem executa?}
pode ser utilizado imediatamente por outros sistemas como os de monitoramento ou
\emph{firewalls} para tomada de decisões.
Caso o rótulo seja ``desconhecido'', o descritor de fluxo é armazenado no
processo coordenador para
% \notaPA{Quem executa?}
posterior execução assíncrona da tarefa
de detecção de novidade, portanto sem interromper o processo de identificação.
% After the initial classification, the resulting label can be used immediately,
% but if the sample is labeled as \emph{unknown}, this sample must be stored and
% the novelty detection step will be triggered.

% \notaPA{Ok, multiprocessamento. Em todas as instâncias? Como?}
% Author: Detalhes de implementação estão na seção 4.4 Implementação com MPI.
Além do multiprocessamento da tarefa de classificação e da execução assíncrona da
tarefa de detecção de novidade na fase \emph{online}, outra mudança em relação
ao \minas original é a remoção do mecanismo de esquecimento de padrões antigos.
Esta remoção tem por finalidade simplificar a atualização e o compartilhamento
do modelo de decisão entre os múltiplas processos e \emph{threads} concorrentes.
% 
O impacto desta alteração não é grande, pois o algoritmo \minas não estabelece a
remoção permanente dos \mclusters com pouco uso.
% \notaPA{Mas não aumenta o tempo para a classificação, caso haja diferentes
% padrões de fluxos de dados?}
% \hlpa{
Essa alteração aumenta marginalmente a complexidade computacional da
classificação, pois inclui na busca os padrões menos utilizados.
% }

Já a fase de treinamento \emph{offline} e a função de detecção de novidades do
algoritmo \minas permanecem as mesmas salvo fato da reimplementação no \mfog.

% To have a better overview of our proposal and how it integrates with existing
% \iot environments, Figure \ref{fig:mfog-phy-arch-cloud} depicts such scenario
% showing from bottom to top:
% \iot devices directly connected to a (local) gateway network;
% this gateway network could be as simple as a single Internet router 
% or be more complex by connecting to private clouds or 
% containing more devices providing fog computing capabilities;
% lastly, available over the internet, the traditional public cloud provides
% inexpensive computing and storage on demand.
% In this scenario, the further apart resources are, the more network
% resources need to be employed, and, as with any networked system, the
% higher is the latency.

% \begin{figure}[hb]
%   \centering
%   \includegraphics[width=0.5\linewidth]{figures/cassalesimgs-000.png}
%   \caption{\arch \cite{Cassales2019} physical architecture and deployment scenario overview.}
%   \label{fig:mfog-phy-arch-cloud}
% \end{figure}

A arquitetura geral do \mfog é dividida em dois módulos, Classificação e
Detecção de Novidade, que equivalem à fase \emph{online} do algoritmo \minas.
% The overall \mfog architecture has two main modules, Classification and Novelty
% Detection, which implement the \minas main tasks.
O módulo Classificação executa a tarefa de mesmo nome do algoritmo \minas e é
ponto focal dos esforços de paralelismo desta proposta.
% \notaPA{Vai explicando em ciclos, detalhando sempre um pouco mais.
% Sugiro rever, e explicar com detalhes, 1x apenas.}
% \hlpa{
Este módulo é replicado em todos os nós do \emph{cluster} % hospedado (?)
em névoa.
% }
% The Classification Module performs the same task of the \minas Online phase and
% is the focal point for parallelism and distribution in our proposal.
% It is replicated in the fog and runs on each cluster node, using a configurable
% number of threads (limited to the node CPU core count).

% o que quer dizer isso?
O módulo Detecção de Novidade tem uma instância por \emph{cluster}, equivalendo a uma
instância por rede local.
O compartilhamento de modelo entre redes distintas é possível, mas não foi
implementado e testado neste trabalho.
% 
O módulo Detecção de Novidade é responsável pela tarefa homônima do algoritmo
\minas, recebendo exemplos com rótulo ``desconhecido'' e os armazenando no
conjunto de desconhecidos.
Quando o tamanho do conjunto de desconhecidos alcança um valor parametrizado,
este módulo executa a função de detecção de novidade do algoritmo \minas
e distribui os novos \mclusters para as instâncias do módulo de Classificação.
% The Novelty Detection Module can also be replicated,
% the choice being one instance per local network, one global cloud instance,
% or both.
% This module also handles the homonymous task of \minas Online phase, receiving
% all the samples labeled with \emph{unknown}, storing them in an internal
% \emph{unknown-buffer}, and, when this buffer is full, performing the \minas
% Novelty Detection task (clustering followed by validation).

\section{Políticas}\label{sec:polices}

O projeto desta arquitetura de \nd distribuída inclui o particionamento das
funcionalidades do algoritmo \minas e o estabelecimento dos fluxos de dados apropriados
entre os diferentes atores.
 % ??? Hélio
% Mudanças no posicionamento de cada ator e no comportamento \hlpa{têm} impactos
Mudanças no posicionamento de cada ator e no comportamento têm impactos
diferentes no desempenho e na acurácia do modelo e devem ser escolhidas com
cuidado.
% As decisões após essas discussões podem ser organizadas em várias políticas; 
% alguns deles eram recorrentes durante os estudos para a implementação e são:
% 
Alguns dos aspectos com impactos potenciais na implementação incluem:

% The design of our distributed \nd architecture includes partitioning the
% functionalities of \minas and establishing the appropriate data flows
% between different actors.
% Changes to placement and behavior can have different impacts and should be
% chosen with care.
% The decisions following these discussions can be organized in several policies,
% some of them were recurring during our implementation discussions and are:
\begin{enumerate}
  
  \item Com relação à alocação do módulo Detecção de Novidade e a sincronização de
  modelo entre redes distintas para compartilhamento de padrões de novidade local
  com outras redes que não receberam aquele padrão de ataque:
  % Regarding the allocation of the Novelty Detection Module:
  \begin{enumerate}
    
    \item Em névoa (há um módulo em cada \emph{cluster} alocado a uma rede local):
    % \notaPA{qual seria a quantidade e quanto tempo depois esse padrão é detectado?}
    % Author: Essa seria uma boa pergunta de pesquisa para um novo trabalho.
    % Author: Enquanto eu enumero estes desafios, esta exploração não fez parte deste trabalho.
    % \hlpa{
    padrões serão somente detectados se um número suficiente de exemplos deste
    padrão
    % }
    ocorrer na rede observada;
    % considerando o uso do poder computacional da névoa, qualquer sincronização
    % de modelo deve ter a propriedade de aditividade;
    % também é preciso reconhecer padrões duplicados;
    
    % \item At each fog node: patterns will be only detected if sufficient samples
    % of them occur in the local observed network, use of the local node
    % processing power, and a model synchronization mechanism between networks
    % must be added;

    \item Em nuvem: capacidade de detecção de padrões dispersos em cada rede
    local,
    % onde se analisado não formaria um cluster válido,
    neste caso todos exemplos com rótulo ``desconhecido''  são enviados da rede
    local para a nuvem implicando aumento do uso do \emph{link} de internet e
    aumento do atraso entre o surgimento de um padrão, sua detecção e a propagação
    para os classificadores em névoa;
    % \item In the cloud: detect patterns even when scattered on each local
    % network, each sample with \emph{unknown} label must be sent from edge to
    % cloud implying increased internet link usage and increased delay between the
    % appearance of a pattern, its detection and propagation to fog classifiers;

    \item Em ambos (nuvem e névoa): cada conjunto de desconhecidos em cada rede
    local é mantido bem como a detecção de novidade para padrões locais.
    % \notaPA{locais. Quando...
    % A frase muito longa dificulta o entendimento dela...
    % há outros casos assim no texto. Verificar para tornar o texto mais fluído.}
    Quando um exemplo é considerado ruído e removido do conjunto de
    desconhecidos, este é enviado à nuvem para detecção de novidade global.
    Esta opção requer um mecanismo complexo de sincronização de modelo.
    % \item On both: local \emph{unknown} buffer is maintained and novelty
    % detection is local as well, once a sample is considered as noise or outlier
    % it shall be sent to the cloud where the process repeats but with global
    % data.
    % This choice needs an even more complex model synchronization mechanism.
    
  \end{enumerate}
  
  % \notaPA{A propagação dos novos padrões é feita hierarquicamente, subindo da
  % névoa para a nuvem, ou é propagada diretamente entre a porção em névoa?}
  As três opções requerem, no mínimo, um mecanismo global de sincronização de
  modelo alocado em nuvem, onde novidades encontradas em um \emph{cluster} que observa
  uma rede local são enviados para a nuvem e posteriormente distribuídos.
  Para tal fim, o modelo deve ter a propriedade de aditividade e o correto
  tratamento de padrões duplicados.
  Além disso, no caso mais complexo, a instância em nuvem deve tratar exemplos
  com rótulo ``desconhecido'' ou considerados ruído ou \emph{outlier} gerados
  erroneamente por atrasos de comunicação do modelo ou dos próprios exemplos;
    
  \item Com relação ao mecanismo de esquecimento:
  mesmo quando a detecção de novidade global é usada, modelos locais podem
  ser otimizados para classificação rápida usando estatísticas locais para
  ordenar (e remover, usando menos memória) clusters menos utilizados;
  % \item Regarding the model cleanup (forget mechanism): Even when a global
  % novelty detection is used, local models can be optimized for faster
  % classification using the local model statistics by sorting by (or removing)
  % least used clusters;

  \item \label{reclassification}
  Por último, na reclassificação do conjunto de desconhecidos,
  feita pela tarefa de detecção de novidade do algoritmo \minas, o subconjunto de
  desconhecidos que pertencem a um novo \mcluster válido é, efetivamente,
  classificado com o rótulo deste novo \mcluster.
  No Algoritmo \ref{alg:minas-nd}, linha \ref{alg:MINAS-nd:reclassify},
  o novo \mcluster válido inclui o subconjunto de exemplos que o compõem.
  % \notaPA{Eu não consegui enxergar isso...  Como isso ocorre de fato?}
  Portanto, se este conjunto de exemplos fosse classificado com o rótulo atribuído ao
  novo \mcluster e adicionado ao fluxo de saída, esta saída teria exemplos
  atrasados e duplicados em relação ao fluxo de entrada e o resultado obtido
  poderia ser mais acurado.
  % preciso (???) Hélio
  % \notaPA{Novamente, ficou difícil de acompanhar o raciocínio. Talvez uma figura fosse ajudasse aqui.}
  Além disso, esta escolha modificaria o comportamento do operador de fluxo de
  dados de um \emph{map}, onde para cada exemplo do fluxo de entrada existe um
  exemplo no fluxo de saída, para \emph{flatMap}, onde cada exemplo entrada pode
  ter mais de um exemplo no fluxo de saída, como ilustrado nos 
  diagramas de bola de gude\footnote{
  Um Diagrama de bola de gude (\emph{marble diagram}) ilustra o comportamento de
  um operador de fluxos de dados.
  Cada diagrama contém do topo: os fluxos de entrada, o operador e os fluxos de saída.
  Cada fluxo é representado por uma linha do tempo crescente em direção à
  esquerda com um terminador vertical ($|$), possivelmente um marcador de erro
  ($\times$) e diversos eventos.
  Os eventos são representados por polígonos rotulados com valores de exemplo,
  geralmente círculos coloridos (bolas de gude, \emph{marbles}).
  O objetivo deste tipo de diagrama é ilustrar pequenos exemplos de comportamento
  do operador, para cada evento nos fluxos de entrada, qual o comportamento nos
  fluxos de saída.
  }
  na Figura \ref{fig:marble}.
  % \item Lastly, reclassification of \emph{unknowns}: In the novelty detection
  % task in \minas, the \emph{unknown} sample buffer is effectively classified
  % using the new set of clusters.
  % In Algorithm \ref{alg:MINAS-nd}, at the line \ref{alg:MINAS-nd:reclassify}, the
  % new cluster valid (novelty or extension) includes the set of samples composing
  % that cluster, thus, if this new label assignment was put forth to the system
  % output it would introduce delayed outputs, more recent and perhaps more
  % accurate.
  % Also, it would change the system data stream behavior from a \emph{map}
  % (meaning each input has one output) to a \emph{flatMap} (each input can have
  % many outputs).

\end{enumerate}

\begin{figure}[htb]
  \centerline{
    \includegraphics[width=\linewidth,page=1]{figures/map-vs-flatmap.png}
  }
  \caption{Diagrama de bola de gude da operação de classificação: descarte
  \emph{versus} re-utilização de exemplos formadores de padrões novidade.}
  \label{fig:marble}
\end{figure}

% ------------------------------------------------------------------------------

% \section{Implementação Proposta}\label{sec:descricao}
\input{42.preliminares.tex}
\input{43.mpi.tex}
% \FloatBarrier
\input{44.avaliacao.tex}

% \section{Descrição da Arquitetura Proposta}\label{sec:descricao}

% \newcommand{\source}{módulo auxiliar \emph{source}\xspace}
% \newcommand{\sink}{módulo auxiliar \emph{sink}\xspace}

% \newcommand{\offline}{módulo treinamento\xspace}
% \newcommand{\classify}{módulo classificador\xspace}
% \newcommand{\detector}{módulo detector de novidades\xspace}

% Nesta Seção, apresenta-se o \mfog, objeto proposta deste trabalho.
% O \mfog é composto de três módulos principais e dois auxiliares.
% Os módulos principais implementam o algoritmo MINAS, sendo eles: \offline
% (\emph{Training Module}), \classify (\emph{Classification Module}) e
% \detector (\emph{Novelty Detection Module}).
% Dois módulos auxiliares são utilizados para avaliação do \mfog:
% \source (fonte) e \sink (sorvedouro, consumidor final).
% Os módulos e as interações entre eles são ilustradas na \reffig{arch}.

% \begin{figure}[ht]
% \centering
% \includegraphics[width=\textwidth]{figuras/mfog-arch-v3_pt-br.png}
% \caption{Arquitetura e fluxos de dados do \mfog.}
% \label{fig:arch}
% \end{figure}

% A implementação do \mfog segue a arquitetura \arch formalizada por
% \citeonline{Cassales2019}, discutida na \refsec{cassales}.
% A arquitetura \arch
% % (e outras arquiteturas de NIDS)
% estabelece que um serviço de
% captura e tratamento de dados é instalado na borda de uma rede local com
% dispositivos \iot.
% Na presente implementação, esse serviço de captura e tratamento é representado
% pelo \source.

% O \source é dependente da fonte de dados, executando a transformação dos
% formatos dos \datasets para um fluxo de exemplos (representado por $x$ na \reffig{arch})
% compatível com o restante da implementação.
% Além de fornecer exemplos tratados para o \classify, o \source também fornece
% exemplos com a classe original (representado por $x,c$ na \reffig{arch})
% \notafa{somente na fase de treinamento o source fornece exemplos rotulados par ao sink, certo?}
% \hlfa{para o \sink e para o \offline}.

% O \sink é responsável por agregar todos resultados do \mfog e,
% juntamente com os valores do \dataset fornecidos pelo \source, por computar
% as métricas de qualidade de classificação.
% Além disso, esse módulo também coleta e agrega métricas base para as avaliação de
% escalabilidade e métricas de uso de recursos computacionais.

% Os dados resultantes do serviço de captura e tratamento (representado no \mfog
% pelo \source) são ingeridos pela aplicação no \classify. A ingestão é feita por
% meio de um operador fonte, fornecida pela plataforma \flink.
% % \notake{TCP e apache flink}
% % conexão TCP (\emph{Transmission Control Protocol}).
% Na plataforma, com o modelo de classificação disponível, os exemplos são
% classificados seguindo o algoritmo MINAS original discutido na \refsec{minas-og}.
% A rótulo atribuída pela classificação, ou meta-rótulo de desconhecido,
% juntamente com o exemplo original (representado por $x,l$ na \reffig{arch})
% são enviados para o \sink.
% Além disso, se o exemplo não for classificado, o exemplo e a meta-rótulo de
% desconhecido (representado por $x,u$ na \reffig{arch}) são enviados para o
% \detector.
% \notahl{processaa ND em paralelo?}
% Outra comunicação é o envio das modificações ao sumário estatístico do modelo de
% classificação (representado por $Summary$ na \reffig{arch}) do \classify para o
% \detector.

% O \detector é responsável por executar o processo de detecção de novidade,
% atualizando o modelo de classificação, e entregar o novo modelo às instâncias do
% \classify, através do serviço de armazenamento de modelo (\emph{Model Store} na
% \reffig{arch}).
% O \detector também envia meta-informações sobre o processo de detecção de
% novidade (representado por $Log$ na \reffig{arch}) para o \sink.

% \nota{
% nao seria legal fazer um diagrama pq ai vc pode usar ate nos slides de como eh
% essa implementacao. Faz no draw io pra que de pra usar na monografia e de para
% enxergar na apresentacao
% }

% flink ainda... revisar...

% O \mfog utiliza em seus módulos a distribuição oferecida pela plataforma \flink
% como paralelização, ou seja, utiliza uma instância de trabalho (\emph{job}) por
% dispositivo de classificação, sendo que cada instância de trabalho aloca um
% gerenciador de tarefas por processador.
% Dessa forma, busca-se a escalabilidade no ambiente de \fog para o \classify.
% O \offline, por ser utilizado somente uma vez para gerar o modelo
% de classificação inicial, não tem impacto na escalabilidade geral do sistema.
% O \detector também é implementado na plataforma \flink e, por ser hospedado em
% ambiente de \cloud, herda as qualidades desse ambiente incluindo escalabilidade.
% \notake{destaque sentença}
% O restante do sistema (\source, \sink, armazenamento de modelo) não é foco deste
% estudo e sua escalabilidade, desde que não afete a escalabilidade do \classify e
% \detector.
% \notahl{Questões que precisam ser tratadas:\\
% - Paralelização da classificação: como agrupar os dados e dividir o processamento?\\
% - ND: como saber o que agrupar (dos nós) e como dividir?
% Padrões podem ser locais? Ou sempre se aplicam a todos os nós?}
% \notafa{frase incompleta}