L'analyse des données est souvent organisée comme ceci: ici nous avons les développeurs du référentiel, et ici nous avons les analystes. Dans DWH (entrepôt de données, stockage), ils peuvent utiliser SQL et nos analystes peuvent travailler avec Excel. Si nous devons analyser quelque chose, allez chez les analystes, et ils vont pour les données à DWH pour les données. Cela semble logique. Et beaucoup perçoivent qu'il s'agit d'une division normale du travail. Dans cet article, je veux transmettre l'idée que cette division du travail est erronée et réduit considérablement l'efficacité et la productivité de l'ensemble du processus d'analyse des données.
Un cycle de travail typique sur un problème analytique ressemble à ceci:
- Une entreprise pose un problème et demande une réponse.
- Les analystes discutent avec les entreprises de ce qui doit être fait.
- Les analystes ont réalisé qu'ils voulaient des affaires d'eux et comprennent ce dont ils ont à peu près besoin dans les données.
- Les analystes écrivent une requête en DWH pour obtenir les données.
- DWH prend une demande, lit, demande, clarifie, récupère des données, donne.
- Les analystes comprennent qu'ils n'ont pas tout pris ou les ont mal compris, ils écrivent à nouveau la demande dans DWH pour obtenir les données.
- DWH prend une demande, lit, demande, clarifie, récupère des données, donne.
- Les analystes comprennent qu'ils n'ont pas tout pris ou les ont mal compris, ils écrivent à nouveau la demande dans DWH pour obtenir les données.
- Répétez les étapes 7 et 8
Une fois, les gars de DWH disent qu'ils ne peuvent pas fournir de données ou ne sont pas prêts à traiter autant de demandes d'analystes. En réponse, les analystes commencent à accumuler leurs données loin de DWH dans une sorte d'excelle. Là, ils commencent à collecter leurs processus ETL, comme ils le peuvent, en fonction de ce qu'ils peuvent obtenir de DWH «sans se battre».
Qu'avons-nous en conséquence:
- DWH ne couvre pas adéquatement les besoins des consommateurs (eh bien, de la part de DWH, il semble que les utilisateurs ne savent pas ce qu'ils veulent).
- Les analystes commencent à écrire de mauvais processus ETL et à créer des pseudo DWH en fonction de leur volume de données, mais sans réserve, contrôle d'accès, faible performance, etc.
- L'interaction de DWH et d'analystes souffre parce que L'un ne se soucie pas des affaires, et le second ne comprend pas comme il faut le «langage des oiseaux».
- Le processus d'obtention d'une réponse à une question commerciale est retardé, car le processus de traitement des données est désormais un travail manuel en dehors de DWH. Et pourquoi avons-nous construit DWH, à l'exception d'un seul référentiel?
- Des changements mineurs dans l'énoncé du problème de l'entreprise commencent le cycle d'analyse des données à partir de presque zéro, car DWH ne fera pas preuve de flexibilité et les analystes n'auront pas de données dans un nouveau contexte.
Quelle pourrait être la solution? Si vous voulez vous débarrasser du problème d'interaction entre DWH et analystes, vous devez rapprocher les compétences de DWH et d'analystes. Une personne qui combine ces compétences peut être appelée analyste de données.
Que devrait faire un tel analyste de données Full Stack?
- Travailler avec des sources de données brutes, comprendre le fonctionnement du stockage de données.
- Pour formuler ce qui doit être changé dans le référentiel en termes de contenu de données, quelles données ajouter et comment les traiter méthodologiquement afin que les développeurs DWH inconditionnels puissent les implémenter.
- Comprendre les besoins de l'entreprise, discuter des exigences et aider votre client, interne ou externe, à formuler un problème et une solution.
- Être capable de concevoir une solution analytique, c'est-à-dire comprendre comment résoudre le problème, quelles données sont nécessaires, ce qui doit être «inventé», quelles hypothèses doivent être faites
- Être capable de visualiser vos résultats et de faire rapport à vos clients (internes ou externes)
- Pour pouvoir faire une étude «reproductible», il s'agit d'une analyse qui peut toujours être répétée sur les mêmes données et obtenir le même résultat. Pour ce faire, vous devez pouvoir travailler avec R / python ou des systèmes qui vous permettent de formaliser le processus d'analyse.
Si vous combinez les compétences techniques et analytiques en une seule analyse, vous obtenez un employé véritablement intégré qui peut résoudre le problème de bout en bout. Et cela est très important pour les tâches analytiques, comme seul cet analyste comprend ce qu'il fait et pourquoi. La division entre ceux qui «analysent» et ceux qui «traitent les données» conduit au fait que chacun de ces employés est handicapé: l'analyste est sans mains, car ne peut pas obtenir et traiter quoi que ce soit à l'échelle, et l'ingénieur des données est "sans cervelle", pour ainsi dire. Il ne pense pas à la façon dont il sera utilisé et aux hypothèses.
La division du travail est très importante, mais elle doit avoir lieu dans un plan légèrement différent. L'analyste doit être en mesure d'obtenir tout ce dont il a besoin pour l'analyse, et la tâche de l'ingénieur des données est de construire des systèmes qui fournissent efficacement des données dans toutes les sections susceptibles d'intéresser l'analyste. Pour Data Engineer, cela signifie que les données doivent être stockées sous une forme plutôt flexible, mais en même temps sous une forme pratique à utiliser: partiellement dénormalisées, partiellement accessibles via des cubes, partiellement pré-agrégées et calculées.
Et si vous ne trouvez pas vous-même l'analyste de la pile complète, incluez au moins Data Engeneer dans l'équipe d'analyse afin que la compétence de travail avec les données ne soit pas transférée de l'analyse à un service externe.
Il n'appartient pas à l'analyste de données de prendre en charge la récupération de données à partir de l'API Google AdWords, mais il n'appartient pas à Data Engeneer de rédiger une sélection pour obtenir des données sur les revenus du mois dernier.