sujets techniques à instruire DSI

# sujets techniques à instruire DSI * **1 : observabilité** * TODO : Loïc prépare un papier court sur ce sujet (définition, enjeux, possibilités techniques) * **2 : BDD orientée colonne** * pour les traitements analytiques les BDD orientées colonnes sont plus performantes que les BDD orientées lignes. * TODO : trouver un cas d'usage pertinent pour un SI dans un SD puis organiser un POC équipe projet/DIIT * **3 : orchestration de batchs** * pour le moment les dev utilisent rundeck * ne serait il pas préférable d'utiliser un outil plus moderne? * la DIIT pousse argo * sujet veille techno * airflow 2 semble plus kubernetes friendly * Metaflow is an open source project out of Netflix that aims to improve data science orchestration. Peut être que cela pourrait avoir un intérêt dans le cadre des travaux sur la PCS 2020? * nouveaux entrants : several nascent open source projects aim to mimic the best elements of Airflow’s core design while improving on it in key areas. Some of the most interesting examples are Prefect and Dagster, which aim to improve the portability and testability of DAGs to allow engineers to move from local development to production more easily * **4 : R vs python => tester python pour data wrangling** * contexte : * pour le self on est parti pour convertir presque tout le SAS en R * dans les SD on ne fait pas de python * pourtant dans le monde les data engineer font beaucoup de SQL et de python * le champ du débat R vs python c'est * pour le data wrangling/les pipelines de traitement de données * pour la partie traitement stats purs/ML il y a moins de débats (ex: économétrie et analyse des données mieux en R, traitement du langage naturel/ML/réseaux de neurones mieux en python) * il faudrait qu'on progresse sur python à l'Insee sur le data wrangling/les pipelines de traitement de données * développer une 1re chaine batch en python dans un SD avec formation et aide DIIT * TODO : Loïc écrit un papier de base sur ce problème (à faire circuler auprès des sachants comme DIIT et ssp lab) * **5 : échange de données entre SI** * contexte : actuellement un SI A produit un CSV des données puis le CSV est déplacé sur applishare puis le SI B intègre ce CSV. * défauts * couplage fort. * points de montage NAS * plein de gestion de batchs par les ops * In 2002, Bezos wrote an email to Amazon employees that became known as the Bezos API Mandate: * 1. All teams will henceforth expose their data and functionality through service interfaces. * 2. Teams must communicate with each other through these interfaces. * 3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. * 4. It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols—doesn’t matter. * 5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. * voir quelles meilleures solutions on peut proposer * ex : garder échange de fichiers mais que l'échange soit piloté par API * est ce que des outils EL pourraient apporter un gain? ex Singer https://www.singer.io/ (c'est plus un outil EL que ETL) * data virtualisation? * une analyse intéressante ici https://enterprisearchitecture.harvard.edu/sites/hwpi.harvard.edu/files/enterprise/files/data_exchange_advisory_v1_final.pdf?m=1581437469 * **6: veille techno sur R et python nouveaux outils apportant de la performance** [moins important que les points précédents] * monde python * **Polars** is not an alternative to PyArrow. Polars merely uses arrow as its in-memory representation of data. Similar to how pandas uses numpy. Arrow provides the efficient data structures and some compute kernels, like a SUM, a FILTER, a MAX etc. Arrow is not a query engine. Polars is a DataFrame library on top of arrow that has implemented efficient algorithms for JOINS, GROUPBY, PIVOTs, MELTs, QUERY OPTIMIZATION, etc. (the things you expect from a DF lib). Polars could be best described as an in-memory DataFrame library with a query optimizer. Because it uses Rust Arrow, it can easily swap pointers around to pyarrow and get zero-copy data interop. * **DataFusion** is another query engine on top of arrow. * on voit tout **l'éco système autour de DataFusion** dans cette vidéo https://www.youtube.com/watch?v=Rii1VTn3seQ&ab_channel=Databricks * **7 : quels travaux sur le MLops?**