delayed by a give time interval

• https://link.springer.com/article/10.1007/s10994-017-5642-8

label out of order

• https://github.com/mgrzenda/ContinuousReEvaluation
• https://link.springer.com/article/10.1007/s10618-019-00654-y

ho trovato questa bella e chiara lezione su youtube con una repo su github con dentro i suoi notebooks e le slide.

youtube: https://youtu.be/UpsV1y6wMQ8
repo: https://github.com/as595/AllOfYourBases/tree/master/TIARA/GaussianProcessModelling
slides: https://github.com/as595/AllOfYourBases/blob/master/TIARA/GaussianProcessModelling/GaussianProcessModelling.pdf

altre ref:

• sito che consiglia di usare per approfondire http://www.gaussianprocess.org/
• il libro che consiglia http://www.gaussianprocess.org/gpml/chapters/
• la libreria che usa per predirre al C02 https://george.readthedocs.io/en/latest/

• More visual examples
• Explanation of Partial Autocorrelation, also with figures
• Definition of random walk
• Standardize formula notation

• https://www.machinelearningplus.com/time-series/time-series-analysis-python/
• https://otexts.com/fpp2/

in questo momento l'unico caso che è sviluppato across sistema è quello del fire alarm. Sarebbe bello svilupparli anche quello del DB della pizza (che ora è solo per SSS), l'IoT della pizza (che ora è solo per flux) e magari quello del braccio robotico (che ora è solo in EPL).

9:00 - 10:00

• why 20m (TODO: richiami a architettura logica)
• key operations 15m (TODO: richiami a operazione di wrangling base)
• concepts 15m

10:15 - 11:45

• how it works 45m (vedi anche disegni su canale gitter)
• tutorial mw 45 (TODO: illustrare il caso nelle slide, corregere i minuti 187-->117)

11:45 - 13:00

• tutorial etl (attenzione, problema con esecuzione, servito fare nuovamente SET earliest)
• TODO: illustrare il caso nelle slide e disegnare la rete di query (vedi canale gitter)

14:15 - 15:30

• fire alarm (venuto bene, vedi anche chat per migliramenti rispetto a USDE)

16:00 - 17:15

• cp-demo (venuta bene, sarebbe meglio capire anche la parte dei kafka streams)

17:00 - 18:00

• try one more demo yourself (NON ha funzionato, elastic non viene su e grafana non carica il dashborad)

TODO aggiungere esercizi dopo ciascu tutorial. Facile arrivare su 1,5 gg

Caso

Suppose you want to monitor with a stream processing engine a group of robots used for picking and placing goods in an Industry 4.0 storehouse.
Each robotic arm sends events reporting its status: ready to pick the good, good grasped, moving the good, placing the good, moving without any good. Several Force-Sensing Resistors measure the stress levels of the robotic arm. If the stress level is between 0 and 6, the robot is safely operating. If it is between 7 and 8, a controller should raise a warning. If it is above 9, a controller should stop the robot.
In EPL propose:

• E1 How to model the streaming data generated by the robotic arms
• E2 A continuous query that emits the max stress for each arm.
• E3 A continuous query that emits the average stress level between a pick and a place.
• E4 A continuous query that returns the robotic arms that, in less than 10 second,
  • picked a good while safely operating,
  • moved it while the controller was raising a warning, and
  • placed it while safely operating again.
• E5 A continuous query that monitors the results of the previous one and counts how many times each robotic arm is present in the stream over a tumbling window of 1 min.

E1

proposte

Valerio:

create schema Arm1 ( status string, stress_level int ); 
create schema Arm2 ( status string, stress_level int ); 
create schema Arm3 ( status string, stress_level int );

Pietro:

create schema RobotArm ( id int, status string, stess int ); 
create schema StressWarning ( armId int, ); 
create schema StopArmEvent( armId int );

Laura:

create schema RoboticSensorArm( roboticArmId string, status string, stressLevel int );

Andrea: un evento per ogni stato con un riferimento al braccio che lo ha creato mettendo lo stress_level solo negli stati in cui è utile

Ivan:

create schema RoboticArm(id int, status string); 
create schema ForceSensingResistors(idArm string, stressLvl int)

NOTA: ci sono due forze:

• la realtà: se il mondo è fatto come l'ha modellato Ivan (il braccio non sa dei sensori e i sensori sanno solo di essere sul braccio) non possiamo che rappresentarlo in quel modo
• l'uso che devo fare degli eventi: non voglio dover mettere insieme eventi durante le query se chi li emette può emetterne solo uno (vedi soluzione di Laura e Pietro)

per ragioni di efficienza anche il modeling di Valerio è appropriato perchè ha tenuto separati i bracci, mentre nelle altre soluzioni serve separarli usando l'ID

per le stesse ragioni la proposta di Andrea potrebbe essere molto buona se servisse fare analisi across braccio raggruppando per stato

direi di continuare usando:

create schema RoboticArm( id string, status string, stressLevel int );

I dati:

RoboticArm={id="1", status="ready", stressLevel=0} 
t=t.plus(1 seconds) 
RoboticArm={id="1", status="goodGrasped", stressLevel=1} 
t=t.plus(1 seconds) 
RoboticArm={id="1", status="movingGood", stressLevel=5} 
RoboticArm={id="2", status="ready", stressLevel=0} 
t=t.plus(1 seconds) 
RoboticArm={id="2", status="goodGrasped", stressLevel=5} 
t=t.plus(1 seconds) 
RoboticArm={id="2", status="movingGood", stressLevel=9} 
t=t.plus(5 seconds) 
RoboticArm={id="2", status="placingGood", stressLevel=3} 
RoboticArm={id="1", status="placingGood", stressLevel=3} 
t=t.plus(4 seconds) 
RoboticArm={id="1", status="moving", stressLevel=2} 
RoboticArm={id="2", status="moving", stressLevel=1} 
t=t.plus(3 seconds) 
RoboticArm={id="1", status="ready", stressLevel=0} 
RoboticArm={id="2", status="ready", stressLevel=0} 
t=t.plus(1 seconds)

le query E2, E3, E4, e E5

@Name("E2") 
SELECT id, max(stressLevel) 
FROM RoboticArm 
GROUP BY id
@Name("E3") 
SELECT a.id, (a.stressLevel + b.stressLevel + c.stressLevel) / 3
FROM pattern [ 
every a=RoboticArm(status="goodGrasped") -> 
b=RoboticArm(id = a.id, status="movingGood") -> c=RoboticArm(id = a.id, status="placingGood")  ];

@Name("E4") 
select a.id
from pattern [
(every (a=RoboticArm(status="goodGrasped")) -> 
every (b=RoboticArm(id=a.id, status="movingGood")) -> 
every (c=RoboticArm(id=a.id, status="placingGood"))) where timer:within(10 sec)
]
where  a.stressLevel <= 6 and  b.stressLevel > 6 and b.stressLevel <9 and c.stressLevel <= 6;

https://online.stat.psu.edu/stat510/

per periodo per server

....

realizzare una tabella di comparazione con cosa si può fare e cosa no in ciascun linguaggio

• cookbook with many reciepts
• basic dockerized version of FlinkSQL
• connectors, e.g., the kafka one or the JDBC one

http://esper.espertech.com/release-5.5.0/esper-reference/html/nwtable.html#nwtable-table

nel percorso di demo nel tutorial su ksql_materialized-view verso la fine si cheide di

INSERT INTO calls (name, reason, duration_seconds) VALUES ("derek", "help", 2727);

aspettandosi che

+---------+-------------------+------------+
|NAME     |DISTINCT_REASONS   |LAST_REASON |
+---------+-------------------+------------+
|derek    |4                  |help        |

ma non può succedere che DISTINCT_REASONS diventi 4 perchè ci sono solo tre ragioni distinte e aggiugendo help il 3 resta 3. Giustamente, invece cambia l'ultima ragione da refund a help

immagina che il tutto venga eseguito da una macchiana con anaconda per l'accesso al terminale via web è molto comodo.

Nel caso:

• MUST
  • togliere jupyter dai docker-compose
  • sistemare i notebook in modo che si colleghino a kafka da localhost:29092
• NTH
  • capacità di vedere le interfacce dei vari servizi da dentro jupyter lab (per non dover aprire all'esterno tutte le porte)

nel fare il tutorial ksql_etl_tutorial ho scoperto che al ritmo della lezione non arrivano i dati nell'elastic (mentre vi arrivano se uno esegue il tutorial una query dopo l'altra senza pause di spiegazione).

Bisognerebbe capire perché. Una prima ipotesi è che i timestamp delle collezioni orders e shipments sono nel passato e se si lascia abbastanza tempo i dati vengono cancellati da kafka perché vecchi.

Di sicuro si può cambiare il percorso di demo in modo da registrare connettori e query prima di mettere gli i dati in postgres e mongo.

in line protocol:

org [measurement/tag]

• building [tag]
  • floor [tag]
    • asset [tag]
      • meter [field]
        • not decreasing value

in a table

tariff

• building
  • time-interval

compute consumption

|> aggWindow(1m, agg:last)
|> difference()

compute the cost

join stream with table tariff

https://blog.jovian.ai/time-series-analysis-data-exploration-and-visualization-9dbede5cbb8d

https://uc-r.github.io/ts_exploration

https://www.kaggle.com/code/kentata/time-series-data-exploration/notebook

mi è capitato già due volte che mi chiedessero come interpolare ad una certa ora e non usare la finestra per sincronizzare, sarebbe bello mostrare come fare nei vari linguaggi