Upgrade architecture design based on backend storage use cases

[vincentnam]

Datalake enhancement : modular backend and optimization

Block storage: overlay Native object storage Block mode overlay ?

Is it possible to change the storage backend (Openstack Swift) in the case of a deployment on a platform containing pre-existing object storage services (Openstack Swift, Ceph, S3, etc.)? But in this case, the problem of data security management -> the platform administrators may have access rights on the data that they should not have (case of encryption in Swift, if Swift is in the host platform, they can potentially read all the data while if Swift is in the datalake architecture, the encryption keys are only accessible to the datalake administrators)

Is the datalake intended to be deployed only on PaaS? Can it be integrated with SaaS? Is it really modular (easy to juggle between PaaS, SaaS and other forms of Cloud services)?

On PaaS implementing a block storage service (in Openstack, Cinder is used), does this service add an overlay to the use of blocks (does the data do Swift -> Cinder -> Device or directly Swift -> Device with Cinder which is only present to create this link?)

Make it modular at the storage backend level? To be seen! The needs at the storage backend level are at the moment -> passing through API rest and possibility to modify the data processing pipeline to send a web trigger to Airflow

(https://searchstorage.techtarget.com/opinion/Swift-or-Ceph-Which-object-storage-system-is-better)

Maybe put Swift better in the context of large volumes (and distributed architecture or federations of datalake)

Make all other modules modular? To be seen!

---

Amélioration du datalake : backend modulaire et optimisations

Stockage bloc : surcouche Stockage objet natif Surcouches du mode bloc ?

Possible de changer le backend de stockage (Openstack Swift) dans le cas d'un déploiement sur une plateforme contenant des services stockages objet préexistants (Openstack Swift, Ceph, S3, etc...) ? Mais dans ce cas, problèmatique de la gestion de la sécurité des données -> les administrateurs de la plateforme peuvent avoir des droits d'accès sur les données qu'ils ne devraient pas avoir (cas du chiffrement dans swift, si swift est dans sur la plateforme d'accueil, ils peuvent potentiellement lire toutes les données tandis que si Swift est dans l'architecture de datalake, les clés de chiffrement ne sont accessibles qu'aux administrateurs du datalake)

Est-ce que le datalake est destiné à n'être déployé que sur du PaaS ? Peut-ont l'intégrer avec du SaaS ? Est-ce vraiment modulaire (jongler facilement entre le PaaS, le SaaS et les autres formes de service Cloud) ?

Est-ce que sur du PaaS implémentant un service de stockage bloc (dans Openstack, il est utilisé Cinder), ce service rajoute une surcouche au niveau de l'utilisation des blocs ? ( Est-ce que la donnée fait Swift -> Cinder -> Device ou directement Swift -> Device avec Cinder qui est uniquement présent pour créer ce lien ?)

Rendre modulaire au niveau du backend de stockage ? A voir ! Les besoins au niveau du backend de stockage sont à l'heure actuelle -> passage par des API rest et possibilité de modification du pipeline de traitement de la donnée pour envoyer un web trigger vers Airflow

(https://searchstorage.techtarget.com/opinion/Swift-or-Ceph-Which-object-storage-system-is-better)

Peut être que mettre du Swift mieux dans le cadre de gros volumes (et d'architecture distribuée ou fédérations de datalake)

Rendre modulaire tous les autres modules ? A voir !