ISISComputingGroup / ISISComputingGroup/IBEX
Minimal Streaming Application: Running Kafka in container to move/aggregate files
- Dominant language
- No language data
- Stars
- 6
- Forks
- 2
- Avg merge
- 16h 40m
- Merged PRs (30d)
- 2
Description
### Background
This ticket is very much inspired by #8438. It is the **first** step in looking at a current problem with aggregating and moving large numbers of small datafiles from separate PCs and managing the simultaneous transfer of these through an archiving and data analysis path. In this case, one "solution" is to use a Kafaka style data streaming framework to manage this data movement.
For this ticket, it is intended to be the first part of an effort to make use of any technology (but ideally similar or the same to that which is found to work for #8438). In this case using a tool like "rancher" to allow an open source "Red Panda" or other Kafka style data streaming client/server system to be embedded and run on the existing Windows 10/11 based systems (ideally with fairly minimal impact).
The key features of the test system this ticket could lead to are:
**"Ideal" Funtionality**
1. Data file tranches produced from the imaging camera and saved to local disk at any time during a camera/ISIS run are imported seamlessly into a suitably relevant set of "Kafka" stream/topics on the PC. This will include mapping an existing experiment/subfolder/run number structure into the stream as it is produced - possibly just as a file in a "blob".
2. The stream/topic has a destination (feed off?) from the generated stream onto the Instrument Control PC `Data$` area for incoming structured RB data (might initially just be a file copier).
3. A small number of cameras PCs will be able to provide data so the stream will "fan-in" to a joint RB structured folder tree on the Instrument control PC.
**Acceptance Criteria**
note:
Once setup and running, the functionality will _partially_ emulate (in a simple local test environment) and _could_ be compared with the performance and controllability of the _existing camera data transport system_ based on multiple automated "data streams" managed by "robocopy" tasks on the camera PCs and the Instrument Control PC.
The use of "Kafka" is to fully ingest the content and metadata of the camera files and transport as the only data management system (so although files are used as input and as output on the Instrument control PC data area, all transport is through the Kafka stream).
- [ ] a. A test system on a developers PC (for example) is setup which demonstrates that a minimal Kafka system "works" given the existing work using a similar container setup to that in #8438.
- [ ] b. A simple test evaluation is made of how easily/well this system could copy a group of files into and out of a Kafka stream.
**Note**
The final destination of the IMAT data files is jointly and simultaneously to IDAaaS and to a closed archived `.zip` file by run number for long term archiving on different systems. This could be greatly benefitted by using a "continuous" technology to move data onwards from the Instrument control PC as well as to it from the camera PCs. So this solves both an immediate problem along with a potential future "stab" at investigating the benefits of a uniform data streaming technology.
### Time in Planning
08/08/24 - 01:11:48
05/09/24 - 08:30
31/10/24 - 10:00
10/01/25 - 01:26:00
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.