Jump to content

Je raconte my life dans la data


Recommended Posts

redshift ils offrent l'accès a un serveur mysql et pas juste à a une base ? quand on a crée un compte RDS on partait confiant vu la kilotonne d'option et là, la douche froide à l'ouverture de l'admin :D mais on a ptet rien compris.
 

Link to comment

Hm. C'est quoi l'ordre de grandeur du CA de la boîte et le nombre d'employés techniques pour avoir une idée de la solution à pousser ?

 

Si je devais le faire moi même, je partirais sur un kubernetes managé chez Ovh avec des postgresql operator. Mais ça demande de l'expérience.

C'est typiquement un boulot taillé pour kube : plein de merdes de partout à factoriser.

Link to comment
il y a 10 minutes, cedric.org a dit :

Hm. C'est quoi l'ordre de grandeur du CA de la boîte et le nombre d'employés techniques pour avoir une idée de la solution à pousser ?

Concept particulier, pour l'instant la boite vit pas sur ce projet, mais je dirai 400K€ année tant que ca explose pas.
Le scaling est compliqué car vu que c'est de la compta, il faut quand même des équipes comptables pour assurer des bilans derrière. Donc l'IT n'est pas le seul goulot d'étranglement.


Donc il y a 200 clients et un seul IT guy, mon frangin, il a fait que du dev jusque la, l'infra arrive maintenant qu'il se dit que c'est pas serieux de compter sur un serveur OVH pour pas planter ses clients. Il backup ses bases avec un script à une heure d'ecart depuis des années car jusque là il n'y avait pas à s'occuper de ça au vu de l'energie a apporter dans le concept avant l'IT.

Malheureusement ils ont embauché des marketteux qui ont rien trouvé d'autre que de vendre la solution comme des petits pains, donc c'est quand même l'heure de s'assurer que l'IT crashe pas. La question c'est de savoir s'ils ont besoin d'expertise, ou si les offres de bases sont encore suffisante pour bien longtemps, après tout ca fait 2 ans que ça traine et ils ont qu'un crash d'une heure OVH ...

Merci pour le nom de la solution, ca a l'air intéressant!

Link to comment

Ouais bon du stateful (database) sur du kubernetes c'est un boulot de spécialiste avec du temps dédié la dessus. C'est faussement facile. Typiquement j'ai fait ça dans ma boîte actuelle quand elle est arrivée à une petite dizaine de mecs techniques : j'ai tout pété et j'ai tout refait avec kubernetes. Du coup j'ai automatisé absolument tout : en un clic un mec a (entre autre) sa base high-availability, backup (dont PiTR) sur plusieurs datacenters, test de backup. On a des centaines des bases qui sont chacunes petites avec un total inférieur au tera (pour le relationnel seulement, le non relationnel c'est autre chose).

 

J'ai entendu beaucoup de bien du postgresql operator développé par Zalando, et c'est en fait mon objectif de dégager mon truc maison vers cette solution.

Link to comment
il y a 3 minutes, cedric.org a dit :

Ouais bon du stateful (database) sur du kubernetes c'est un boulot de spécialiste avec du temps dédié la dessus. C'est faussement facile. Typiquement j'ai fait ça dans ma boîte actuelle quand elle est arrivée à une petite dizaine de mecs techniques : j'ai tout pété et j'ai tout refait avec kubernetes. Du coup j'ai automatisé absolument tout : en un clic un mec a (entre autre) sa base high-availability, backup (dont PiTR) sur plusieurs datacenters, test de backup. On a des centaines des bases qui sont chacunes petites avec un total inférieur au tera (pour le relationnel seulement, le non relationnel c'est autre chose).

 

J'ai entendu beaucoup de bien du postgresql operator développé par Zalando, et c'est en fait mon objectif de dégager mon truc maison vers cette solution.


OK. La il y a que du relationnel, si tant est que les documents additionnels ne sont là qu'en vue d'archivage. (J'imagine qu'actuellement il faut tourner des scripts quand il a besoin de lire des pdfs bancaires par exemple ) . A mon avis vu que c'est architecturé a l'arrache, y aura quand même du travail, mais ca peut être une solution intermédiaire.

Link to comment
  • 1 month later...

J'en ai plein le cul. Il faut que je fouille une table de logs, donc un truc séquentiel par nature, dans laquelle écrit un process SSIS. Chaque appel de module correspond à une ligne de la table, on y trouve le nom du module, et on trouve aussi un intervalle de temps (sous la forme de deux datetime), un Id séquentiel, et plein d'autres colonnes... dont une censée pointer vers le module père mais qui se trouve être foireuse.

 

Comment je peux 1- reconstruire une table hiérarchique (enfant-parent) correspondant à l'arbre d'appel général des modules (il doit y en avoir une soixantaine, donc je préfère éviter de devoir le faire à la main mais ça peut tout de même être envisagé la mort dans l'âme), et 2- pour chaque ligne, trouver l'id de la ligne correspondant au module appelant (histoire d'avoir des infos utiles dans cette table) ?

 

(En temps normal je pense que j'y arriverais, mais compte tenu du niveau de connerie malfaisante de certains collègues sur un autre projet, j'ai plus tout à fait assez de neurones disponibles pour ce genre de problème). CTEs et fonctions de fenêtrage bienvenues.

Link to comment
il y a une heure, Rincevent a dit :

2- pour chaque ligne, trouver l'id de la ligne correspondant au module appelant (histoire d'avoir des infos utiles dans cette table)

Hmmm, serait-ce tout simplement ceci ?

UPDATE	Tablalakon
	Set	ParentId = Max(PP.Id)
FROM	Tablalakon	As Child
Left JOIN	Tablalakon	As PP	--	PutativeParents
		ON	PP.Id < Child.Id	--	Monotononicity
        And	PP.StartDate <= Child.StartDate
        And	PP.EndDate >= Child.EndDate
;

(Cette thêta-jointure me fait frémir... personne n'a de solution avec des fonctions de fenêtrage, vraiment ?)

 

Edit : merdalafin, pourquoi c'est aligné dans l'éditeur et pas dans le post ? Pourquoi les tabs valent 4 espaces dans l'éditeur et 8 dans le post ? @Cthulhu ?

Link to comment
Il y a 6 heures, Rincevent a dit :

Edit : merdalafin, pourquoi c'est aligné dans l'éditeur et pas dans le post ? Pourquoi les tabs valent 4 espaces dans l'éditeur et 8 dans le post ? @Cthulhu ?

 

Les deux ont l'air confés différemment. Je ne vois pas de moyen simple de changer ça, faudra que je me plonge dans les fichiers de conf de ckeditor à l'occasion.

 

(mais bon, mix tabs and spaces is evil ;))

Link to comment
Il y a 23 heures, Rincevent a dit :

(Cette thêta-jointure me fait frémir... personne n'a de solution avec des fonctions de fenêtrage, vraiment ?)

Manifestement, il y a des types incapables de loguer une heure correctement (EndDate est précise à la milliseconde, mais StartDate est à la seconde, WTF), ça fait que certaines lignes empiètent les unes sur les autres de manière débile. Du coup j'ai tenté d'ajouter une clause

And	PP.Name <> Child.Name

mais ça ne suffit pas. J'ai donc reconstitué l'arbre des appels à la main (j'ai fouillé les .dtsx en extrayant les noeuds <ExecutePackageTask><PackageName> comme une brute... et ce n'est pas un arbre, il y a deux modules distincts qui appellent le même fils. L'horreur.

 

Du coup je dois faire une chierie genre

And Exists (SELECT	1	FROM	#PackageHierarchy PH	WHERE PP.Name = PH.Parent And Child.Name = PH.Child)

ce qui est bien cradingue ; et on n'échappera pas à la complexité quadratique de la thêta-jointure (les 10000 premières lignes sortent en peut-être 5 secondes, mais les 100 dernières seules prennent une minute... j'en ai pas loin de 3 millions en tout).

 

Bref, merci à ces très chers prestataires pour leur prestation.

Link to comment
  • 1 month later...

Hé c'est drôle ça:

Il était plus simple de renommer des gènes humains que de mettre à jour Excel.
https://www.numerama.com/sciences/641575-il-etait-plus-simple-de-renommer-des-genes-humains-que-de-mettre-a-jour-excel.html

 

Ils en ont tellement assez des conversions automatiques d'Excel qu'ils revoient la nomenclature !

Link to comment
  • 1 month later...

Bon, je crois que j'ai enfin trouvé un truc simple qui est horriblement compliqué à implémenter en SQL seul : calculer une moyenne mobile exponentielle. 

 

Défi : prove me wrong. ;)

Link to comment
il y a 13 minutes, Prouic a dit :

Oui, il faut une CTE récursive dégueulasse (pléonasme) pour un truc qui se fait par cliquer-glisser sous Excel. Donc un truc horriblement plus compliqué que le besoin de base ; sans même évoquer les performances qui promettent le pire dès que les datasets ne sont pas riduculement petits.

 

il y a 12 minutes, cedric.org a dit :

Des avis sur Druid? L'équipe data eng a commencé à l'utiliser en interne, je suis en train de me faire mon avis, mais je suis preneur d'avis extérieurs.

On m'en a dit le plus grand bien pour ce qui est de gérer des masses de données énormes, mais je n'ai pas eu à l'utiliser personnellement. 

Link to comment
  • 4 weeks later...

C'est pas de la data mais un de mes devops, junior, 1 an d'xp tout juste, est en train de péter un câble en demandant une augmentation à 53k, en start-up qui grossit vite et avec des problématiques intéressantes et long terme. Je sais pas quoi en penser. Ça me paraît délirant mais en même temps le marché est délirant. Et il est bon.

Link to comment
4 hours ago, Mathieu_D said:

Ça fait 15% au dessus du marché si je compte bien 53k pour 1 an d'XP ça non ?

(Sans formation particulièrement prestigieuse)

Le marché ne veut rien dire, il y a devops a.k.a admin système renommé, et devops a.k.a. Automatisation complète de l'infra, archi et accompagnement dans le workflow dev et data. Il est de la seconde catégorie même s'il pêche sur la partie accompagnement humain.

 

Comment obtiens-tu ces chiffres ?

Link to comment

Grosso merdo c'est 45k un junior confirmé en dataops/mlops en environnement Cloud/Spark je suspecte que c'est pareil pour un devops qui va automatiser les workflows GCP ou AWS.

 

Et s'il est junior c'est normal qu'il pêche en accompagnement note.

Link to comment
  • 1 month later...

reprise ici ca ril parait qu'on énerve les gens dans TIL :D

 

Alors voilà ce qu'il s'est passé:

Après avoir été estampillé geek de service suite au switch de Bureau d'étude vers formation data analytics, je m’intéresse à lier les besoins métiers avec le contenu des data lake de la boite. Là ou ça déconne c'est que vu que j'aime bien que ça soit juste, et qu'en plus ma boite est un microcosme de processus et méthodes pour tout et n'importe quoi, et sachant que le data lake a été monté dans l'esprit "on met tout à dispo tel quel", il y a comme un problème de cohérence, car pour construire un objet correct avec lequel on pourrait travailler dans le métier, il faut toujours faire des sortes de rétro engineering à partir des tables brutes. 

Donc évidemment, la boite a fourmillé, et on  suite à ça un bordel de data brutes, et un bordel de data mal liées qui ont été stockées dans d'autres tables pour faire office de simplification. Du coup, maintenant je gravite entre comprendre les objets de la boite, comprendre leur forme brute, et comprendre leur forme transformée ( quand quelqu'un a bien pris le temps d'essayer d'en faire une transfo raisonnable). 

Donc en pratique je gère pas de tables SQL (c'est SQL server BTW) je le lis/lie surtout. Mais je lis surtout le SQL dégueu des autres, et c'est la que ca pèche, car n'ayant pas besoin de les construire, je ne m’entraîne pas assez niveau code, et donc ça reste la plupart du temps un peu obscur. 

 

Sinon pour la théorie des ensembles, je vois pas trop, comme tu dis c'est légèrement vieux, j'ai du en faire 3 mois en prébac il y a 25 ans. Par contre vu que je m'amuse toute la journée à chercher des delta dans les bases, j'imagine qu'en pratique ça correspond a faire des unions de tables tout en ayant conscience de la propagation des populations. (si tant est que ce soit a peu près le même attribut dans les 2 tables, ce qui est jamais gagné.)

 

J'ai jeté un oeil à la théorie des catégories aussi, mais pareil, pas d'application dans l'instant, pouf disparu. J'en ai juste retenu qu'il fallait travailler la fonction, pas la donnée.

 

edit: il m'arrive cependant d'écrire un peu de SQL pour les besoins métier, mais en pratique c'est pas un travail excitant: tu commences par fair e un SQL pour un besoin, ca répond bien, puis quelqu'un te dit qu'il faut l'exposer, ca commence à merder, le périmètre grandit, et un autre type prend le boulot et tu te retrouves à specifier le besoin que t'avais fini.

(faut que je me tire en asie bordel)

 

Link to comment
il y a une heure, Prouic a dit :

Sinon pour la théorie des ensembles, je vois pas trop, comme tu dis c'est légèrement vieux, j'ai du en faire 3 mois en prébac il y a 25 ans.

Les bases de données relationnelles, c'est de la théorie des ensembles appliquée, en fait. Pas forcément besoin de creuser tant que ça, mais l'idée est de toujours garder en tête qu'une requête, c'est un truc qui prend un dataset (ou des dataset), et qui renvoie un autre dataset (pour modifier le premier si c'est un Insert, un Update ou un Delete, ou bien pour le mettre ailleurs si c'est un Select).

 

il y a une heure, Prouic a dit :

J'ai jeté un oeil à la théorie des catégories aussi, mais pareil, pas d'application dans l'instant, pouf disparu. J'en ai juste retenu qu'il fallait travailler la fonction, pas la donnée.

Oui alors on peut faire de la branlette intellectuelle toute la journée aussi, hein. ;)

 

C'est surtout qu'il faut, autant que possible, renoncer à penser en termes de variables et d'algorithmes, mais décrire le plus précisément l'ensemble des données que tu souhaites, libre au moteur de te le calculer comme il l'entend. Une des modules les plus importants dans un moteur de BdD, c'est l'optimiseur, qui prend ta requête, aka la description de ce que tu veux et qui retourne l'algorithme de la manière la plus efficiente (espérons-le) de construire ce que tu veux avec les éléments dont il dispose. Même si l'optimiseur est généralement le fruit de trouzaines de milliers d'heures de sueur d'ingénieur (ou de PhD), il ne peut que mieux se porter si tu décris avec précision ce que tu attends de lui (ta requête, ton DQL / DDL) et qu'il peut se reposer sur des éléments précis et gérables (ton DML).

 

Et il se trouve qu'existent des guidelines, solidement fondées sur de la théorie, qui t'expliquent comment faire les éléments les plus précis et gérables possibles (les "formes normales"). Une manière classique de faire en partant d'un magma informe est de faire 1- des requêtes pour en extraire des données bien propres qui auront vocation à être stockées dans 2- un ODS (i.e. une base de données nettoyées, agrégées, normalisées si possible, stockées dans des tables convenables faisant l'objet de relations clean) ; et cet ODS sera la cible de 3- tes requêtes finales pour te donner tes réponses. Mais bon, c'est du boulot, je ne le nie pas. :lol:

 

Oh, et j'aime SQL Server :)

Link to comment

@Prouic tu as vraiment besoin de comprendre un plan d'exécution pour faire ce que tu veux faire ?

 

 

(Sinon ça n'a rien à voir mais on est en train de migrer de Teradata vers Snowflake au boulot. 

Le gain en performance est assez hallucinant, sachant que Teradata ce n'est pas de la daube, c'est d'autant plus impressionnant )

Link to comment
15 minutes ago, Rincevent said:

Quelques exemples ? Et sur du matériel de puissance équivalente ?

Je viens d'arriver je ne connais pas tous les tenants et aboutissants de l'architecture. (On compare une appliance on-premise à une cloud base sur Azure)

Mais globalement ça va 10 fois plus vite du point de vue utilisateur. (Donc en comptant le réseau, l'I/O, l'outil dans lequel ça tombe, SAS, Microstrategy, Databricks...)

Link to comment
il y a 2 minutes, Mathieu_D a dit :

une cloud base sur Azure

Ouch, c'est d'autant plus impressionnant.

 

Demande quand même au CIO de regarder sa facture Azure de fin de mois, la part variable pourrait être rigolote. ;)

Link to comment
×
×
  • Create New...