Hologres:Normes de développement Hologres

Couches d'entrepôt de données

L'entrepôt de données est structuré en couches isolées par des schémas dans Hologres. La couche CDM comprend les couches DWD, DWS et DIM.

• Operation data store (ODS) : couche des données opérationnelles.

• Common data model (CDM) : couche du modèle dimensionnel public.

  • Data warehouse detail (DWD) : couche des données détaillées.

  • DWS (Data Warehouse Summary) : récapitulatif de l'entrepôt de données.

  • Dimension (DIM) : couche des données dimensionnelles.

• Application data service (ADS) : couche des données applicatives.

Choisissez la granularité en fonction de la complexité de votre activité. Par exemple, si votre entreprise compte plusieurs unités commerciales (BU), utilisez l'abréviation de l'unité comme préfixe de schéma.

create schema ${bu}_ads;
create schema ${bu}_ads_dev;
create schema ${bu}_dwd;
create schema ${bu}_dwd_dev;
create schema ${bu}_dws;
create schema ${bu}_dws_dev;
create schema ${bu}_dim;
create schema ${bu}_dim_dev;
create schema ${bu}_ods;
create schema ${bu}_ods_dev;

Abréviations des domaines de données

Définissez des codes partagés pour les domaines de données afin d'établir une norme à l'échelle de l'entreprise. Exemples :

Conventions de nommage des jobs

Les règles de nommage diffèrent selon qu'il s'agit de tâches internes ou de tâches de synchronisation :

• Tâches SQL internes (hors tâches de synchronisation) : holo_{target_table_name}. Ce format permet de les distinguer des tâches liées aux tables externes.

• Importation de données vers Hologres : {source}2holo_{target_table_name}.

• Exportation de données depuis Hologres : holo2{target}_{target_table_name}.

Convention de nommage des tables

Convention de nommage des Table Groups

Pour plusieurs Table Groups, utilisez le format suivant : ${bu}_{data_warehouse_layer_name}_{business_definition}_tg.

Convention de nommage des vues

Règles de nommage et exemple pour les vues persistantes :

• Règles

  • DWS : ${bu}_dws.data_domain_data_granularity_abbreviation_business_process_[{custom_root}]_statistical_period_v.

  • ADS : ${bu}_ads.business_domain_dimension_[{custom_root}]_{refresh_period_identifier}_v.

• Exemple

  taobao_dws.trd_byr_itm_ord_cm_v

Conventions de nommage des tables externes

Ajoutez le suffixe ext au nom de la table MaxCompute. Exemple :

taobao_dim.camp_ext

Convention de nommage des tables temporaires

Ajoutez le préfixe tmp et un suffixe numérique au nom de la table. Exemple :

taobao_dim.tmp_camp_01

Abréviations courantes

Normes relatives aux tables internes

Avant de créer une table, définissez les noms conformément aux normes du modèle de données, configurez le cycle de vie et ajoutez des commentaires à la table et à tous les champs.

• Normes strictes (obligatoires pour la publication) :

  • Chaque table et chaque champ doit comporter un commentaire concis. Cette règle s'applique à tous les scénarios de développement de données.

  • L'instruction de création de table doit spécifier le cycle de vie de la table (time_to_live_in_seconds).

  • L'instruction de création de table doit spécifier une clé de distribution (distribute_key). Les principes de sélection d'une clé de distribution sont les suivants.

    Sélectionnez un champ bien réparti fréquemment utilisé dans les clauses JOIN ou GROUP BY. Par exemple, pour une table acheteur-article, vous pouvez définir user_id et item_id comme clé de distribution. Toutefois, si user_id est la clé de jointure la plus courante, définissez uniquement user_id, et non user_id et item_id.

  • Créez les tables jointes dans les requêtes dans le même Table Group.

  • Utilisez le même nom et le même type de données pour les ID d'entité dans toutes les tables de faits et les tables de dimensions. Par exemple, si la table des transactions utilise user_id, la table de dimension doit également utiliser user_id, et non uid. Des types cohérents réduisent les conversions.

  • Par défaut, utilisez ds comme champ de partition pour toutes les tables physiques.

• Normes recommandées :

  • L'instruction de création de table doit spécifier au moins l'une des propriétés suivantes : bitmap_columns, segment_key ou cluster_key.

  • Si la cardinalité d'un champ n'est pas claire, laissez dictionary_encoding_columns non défini. Effacez-le avec :

    call set_table_property('table_name', 'dictionary_encoding_columns','')

  • Pour la propriété de table orientation (format de stockage des données), le format column est recommandé. Vous pouvez également définir cette propriété sur row.

    Remarque

    N'utilisez le format row que si toutes les requêtes spécifient toutes les colonnes primary key avec l'opérateur d'égalité ou in. Valeur par défaut : format column.

  • La propriété bitmap_columns active le filtrage basé sur les bitmap au sein des fichiers de stockage.

    • Définissez bitmap_columns sur les champs utilisés dans les conditions de filter. Par défaut, tous les champs TEXT sont inclus.

    • Ne définissez pas les champs à forte cardinalité tels que user_id comme bitmap_columns. Utilisez plutôt des champs à faible cardinalité, tels que l'ID d'activité.

  • La propriété de table event_time_column doit être utilisée pour les champs liés aux écritures en temps réel, tels qu'un horodatage d'événement.

  • La propriété clustering_key trie les données selon l'index spécifié, ce qui accélère les requêtes de range et de filter. Un seul index de cluster est autorisé. Convient au filtrage par plage, tel que le regroupement GMV.

Normes relatives aux tables étrangères MaxCompute

Hologres prend en charge les requêtes accélérées sur MaxCompute via des tables étrangères. Évitez de joindre des tables internes avec des tables étrangères sauf si cela est nécessaire. Suivez ces normes pour gérer efficacement les tables étrangères.

• Norme stricte : respectez la convention de nommage des tables étrangères. Ajoutez le suffixe ext au nom de la table MaxCompute.

• Normes recommandées :

  • Conservez le DDL du schéma de la table et placez-le sous contrôle de version.

  • Ne joignez pas de tables internes avec des tables étrangères. Synchronisez plutôt les données de la table étrangère vers une table interne.

Normes relatives aux vues

• Norme stricte : respectez strictement la convention de nommage des vues.

• Normes recommandées :

  • Activez la planification des tâches pour maintenir les chaînes de dépendance des jobs.

  • Créez des vues distinctes pour différentes granularités afin d'éviter une surcharge de calcul.

    Par exemple, créez des vues distinctes pour cw, cm, nd et 1d. Pour différents clients, créez des vues pour pc, wap et app. Pour différentes méthodes de collecte, séparez ut et non-ut.

Normes relatives au cycle de vie (tables internes uniquement)

Norme recommandée :

Pour les tables partitionnées, écrivez les données en temps réel dans la partition du jour actuel et définissez le TTL en fonction de la couche d'entrepôt de données. N'écrivez pas dans des partitions dont le TTL est dépassé.

Normes relatives aux Table Groups (facultatif)

Normes relatives aux types de champs

Créez des champs en respectant les exigences de type suivantes.

Référence des types de données de base

Les types de données Hologres sont compatibles avec un sous-ensemble des types PostgreSQL. Les types de champs et leurs correspondances MaxCompute sont répertoriés dans Récapitulatif des types de données.

Unité monétaire et précision

L'unité monétaire est l'USD. Sauf indication contraire dans le modèle, n'arrondissez aucune donnée liée aux montants. Cette pratique évite les incohérences dans les calculs récapitulatifs utilisant différentes méthodes statistiques.

Normes strictes :

• N'utilisez pas select * dans la requête la plus externe ou dans les sous-requêtes. Spécifiez toujours explicitement les noms des colonnes.

• Dans les clauses WHERE, gérez les champs null et les chaînes vides avec la fonction Coalesce.

Normes recommandées :

• Utilisez un champ count distinct comme distribution_key. Pour plusieurs opérations count distinct, réécrivez manuellement l'instruction.

  select count(distinct userid)
       , count(distinct case when stat_date = '20201111' then userid end) 
  from t group by cate_id;
  
  --Rewrite as follows
  select count(1), sum(c) from 
  (
    select userid
         , cate_id
         , cast(count(case when stat_date = '20201111' then 1 end) > 0) as c 
    from t 
    group by cate_id, userid
  ) t1 
  group by cate_id;

• Pour les tâches de planification hors ligne, exécutez analyze table sur les tables partitionnées.

• Pour une utilisation à long terme, utilisez ATTACH/DETACH pour les opérations par lot sur les partitions historiques afin d'éviter des fluctuations drastiques des métriques de données.