You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Aakash Khochare <aa...@grads.cds.iisc.ac.in> on 2017/01/26 17:16:07 UTC
A few clarifications on MiNiFi
Greetings,
I am a part of a Research Lab in Indian Institute of Science. We are in process of evaluating various frameworks for our IoT deployments. So, MiNiFi's webpage states "Perspectives of the role of MiNiFi should be from the perspective of the agent acting immediately at, or directly adjacent to, source sensors, systems, or servers. " However targets data ingress and from the overview that I had all the processors are targeted towards ingress/egress/transformation of data. Can anyone specifically point out features that facilitate the "agent acting immediately" aspect? Ofcourse I can make custom processors, but what are the specific differences between NiFi and MiNiFi.
Also, the documentation is pretty lean at this point. I hope that changes pretty quickly.
Regards,
Aakash Khochare
MTech (Research)
Indian Institute of Science
Re: A few clarifications on MiNiFi
Posted by Juan Sequeiros <he...@gmail.com>.
I was also pointed to this good document for MINIFI Administration on the
nifi uses alias.
https://github.com/apache/nifi-minifi/blob/master/minifi-docs/src/main/markdown/System_Admin_Guide.md#provenance-reporting-1
On Thu, Jan 26, 2017 at 1:37 PM Uwe@Moosheimer.com <Uw...@moosheimer.com>
wrote:
> Hi Aakash,
>
> think of MiNiFi like NiFI without UI.
>
> The advantages are (as you can see at https://nifi.apache.org/minifi/):
>
> * small and lightweight footprint
> * central management of agents
> * generation of data provenance, and
> * integration with NiFi for follow-on dataflow management and full
> chain of custody of information
>
> So what is the benefit of MiNiFi?
>
> MiNiFi is designed to run on sensors/clients.
> You can define workflows that should run on client side like log
> collection/aggregation (ETL), metrics etc. and send them to NiFi or MQTT
> or Kafka or what ever.
> These tasks should run on the the client side and not on the server
> (load sharing)!
>
> You can configure your sensors/clients on a central side and you are
> able to distribute new configs automatically (push to clients or all
> clients pull the new config periodically).
> The benefit is that you can design a workflow an NiFi and send it to
> thousand of sensors/clients which are running MiNiFi on a very easy way.
> Think of thousand or millions of sensors - how do you like to update
> them and change their behaviour?
>
> How do you get the collected data from your sensors?
> That's what MiNiFi is for.
>
> > but what are the specific differences between NiFi and MiNiFi
> NiFi is the part to define and run workflows within your company. NiFi
> ist also the part to define workflows that should run on MiNiFi.
> MiNiFi is a small NiFi (as described above) to run on sensors/clients
> for things like logfile processing or sending sensor information and so
> on to NiFi or others.
>
> We use MiNiFi to collect metrics and logfile information and send them
> to NiFi via MQTT (failsafe).
> It's pretty straight forward and works like a charm.
> Also you generate data provenance information where it starts (on the
> client side) and if you use Apache Atlas with NiFi you have one place to
> store provenance data for all Enterprise data ;-)
>
> > Also, the documentation is pretty lean at this point. I hope that
> changes pretty quickly.
> You are welcome to help making the documentation better!
>
> Regards,
> Uwe Moosheimer
>
> Am 26.01.2017 um 18:16 schrieb Aakash Khochare:
> > Greetings,
> >
> > I am a part of a Research Lab in Indian Institute of Science. We are in
> process of evaluating various frameworks for our IoT deployments. So,
> MiNiFi's webpage states "Perspectives of the role of MiNiFi should be from
> the perspective of the agent acting immediately at, or directly adjacent
> to, source sensors, systems, or servers. " However targets data ingress and
> from the overview that I had all the processors are targeted towards
> ingress/egress/transformation of data. Can anyone specifically point out
> features that facilitate the "agent acting immediately" aspect? Ofcourse I
> can make custom processors, but what are the specific differences between
> NiFi and MiNiFi.
> >
> >
> > Also, the documentation is pretty lean at this point. I hope that
> changes pretty quickly.
> >
> >
> > Regards,
> >
> > Aakash Khochare
> >
> > MTech (Research)
> >
> > Indian Institute of Science
> >
>
>
Re: A few clarifications on MiNiFi
Posted by "Uwe@Moosheimer.com" <Uw...@Moosheimer.com>.
Hi Aakash,
think of MiNiFi like NiFI without UI.
The advantages are (as you can see at https://nifi.apache.org/minifi/):
* small and lightweight footprint
* central management of agents
* generation of data provenance, and
* integration with NiFi for follow-on dataflow management and full
chain of custody of information
So what is the benefit of MiNiFi?
MiNiFi is designed to run on sensors/clients.
You can define workflows that should run on client side like log
collection/aggregation (ETL), metrics etc. and send them to NiFi or MQTT
or Kafka or what ever.
These tasks should run on the the client side and not on the server
(load sharing)!
You can configure your sensors/clients on a central side and you are
able to distribute new configs automatically (push to clients or all
clients pull the new config periodically).
The benefit is that you can design a workflow an NiFi and send it to
thousand of sensors/clients which are running MiNiFi on a very easy way.
Think of thousand or millions of sensors - how do you like to update
them and change their behaviour?
How do you get the collected data from your sensors?
That's what MiNiFi is for.
> but what are the specific differences between NiFi and MiNiFi
NiFi is the part to define and run workflows within your company. NiFi
ist also the part to define workflows that should run on MiNiFi.
MiNiFi is a small NiFi (as described above) to run on sensors/clients
for things like logfile processing or sending sensor information and so
on to NiFi or others.
We use MiNiFi to collect metrics and logfile information and send them
to NiFi via MQTT (failsafe).
It's pretty straight forward and works like a charm.
Also you generate data provenance information where it starts (on the
client side) and if you use Apache Atlas with NiFi you have one place to
store provenance data for all Enterprise data ;-)
> Also, the documentation is pretty lean at this point. I hope that changes pretty quickly.
You are welcome to help making the documentation better!
Regards,
Uwe Moosheimer
Am 26.01.2017 um 18:16 schrieb Aakash Khochare:
> Greetings,
>
> I am a part of a Research Lab in Indian Institute of Science. We are in process of evaluating various frameworks for our IoT deployments. So, MiNiFi's webpage states "Perspectives of the role of MiNiFi should be from the perspective of the agent acting immediately at, or directly adjacent to, source sensors, systems, or servers. " However targets data ingress and from the overview that I had all the processors are targeted towards ingress/egress/transformation of data. Can anyone specifically point out features that facilitate the "agent acting immediately" aspect? Ofcourse I can make custom processors, but what are the specific differences between NiFi and MiNiFi.
>
>
> Also, the documentation is pretty lean at this point. I hope that changes pretty quickly.
>
>
> Regards,
>
> Aakash Khochare
>
> MTech (Research)
>
> Indian Institute of Science
>