Zein printzipioren arabera eraikitzen da Data Warehouse ideal bat?

Zentratu negozio-balioan eta analisian, boilerplate koderik ezean. DWH kode-base gisa kudeatzea: bertsioa, berrikuspena, proba automatizatuak eta CI. Modularra, hedagarria, kode irekikoa eta komunitatea. Erabiltzaileentzako dokumentazioa eta menpekotasunen bistaratzea (Data Lineage).

Horri guztiari buruz eta DBTk Big Data eta Analytics ekosisteman duen eginkizunari buruz - ongi etorri cat.

Kaixo guztioi

Artemy Kozyr harremanetan dago. 5 urte baino gehiago daramatzat datu biltegiekin lanean, ETL/ELT eraikitzen, baita datuen analisia eta bistaratzea ere. Gaur egun lanean nabil gurpila, OTUSen irakasten dut ikastaro batean Datu Ingeniaria, eta gaur zurekin konpartitu nahi dut hasierari begira idatzi dudan artikulu bat ikastarorako matrikula berria.

Berrikuspen laburra

DBT esparrua ELT (Extract - Transform - Load) akronimoaren T-ri buruzkoa da.

BigQuery, Redshift, Snowflake bezalako datu-base analitiko produktibo eta eskalagarrien etorrerarekin, ez zegoen Data Warehousetik kanpo eraldaketak egiteak.

DBT-k ez ditu iturburuetako datuak deskargatzen, baina aukera bikainak eskaintzen ditu Biltegian dagoeneko kargatuta dauden datuekin lan egiteko (Barneko edo Kanpoko Biltegiratze batean).

DBTren helburu nagusia kodea hartzea da, SQL-n konpilatzea, komandoak Biltegian sekuentzia egokian exekutatu.

DBT Proiektuaren Egitura

Proiektua bi motatako direktorio eta fitxategiek osatzen dute:

Eredua (.sql) - SELECT kontsulta batek adierazten duen eraldaketa-unitatea
Konfigurazio fitxategia (.yml) - parametroak, ezarpenak, probak, dokumentazioa

Oinarrizko mailan, lana honela egituratzen da:

Erabiltzaileak eredu-kodea prestatzen du edozein IDE egokian
CLI erabiliz, ereduak abiarazten dira, DBT-k ereduaren kodea SQLn konpilatzen du
Konpilatutako SQL kodea Biltegian exekutatzen da sekuentzia jakin batean (grafikoa)

Hona hemen CLI-tik exekutatzen nolakoa izan daitekeen:

Dena HAUTATU da

Hau Data Build Tool esparruaren ezaugarri hilgarria da. Beste era batera esanda, DBTk zure kontsultak Dendan materializatzearekin lotutako kode guztia abstraitzen du (SORTU, txertatu, EGUNERATU, EZABATU ALTER, EMAN, ... komandoen aldaerak).

Edozein ereduk sortzen den datu multzoa definitzen duen SELECT kontsulta bat idaztea dakar.

Kasu honetan, eraldaketa logika maila anitzekoa izan daiteke eta beste hainbat eredutako datuak finkatu. Eskaera erakusleiho bat eraikiko duen eredu baten adibidea (f_orders):

{% set payment_methods = ['credit_card', 'coupon', 'bank_transfer', 'gift_card'] %}
 
with orders as (
 
   select * from {{ ref('stg_orders') }}
 
),
 
order_payments as (
 
   select * from {{ ref('order_payments') }}
 
),
 
final as (
 
   select
       orders.order_id,
       orders.customer_id,
       orders.order_date,
       orders.status,
       {% for payment_method in payment_methods -%}
       order_payments.{{payment_method}}_amount,
       {% endfor -%}
       order_payments.total_amount as amount
   from orders
       left join order_payments using (order_id)
 
)
 
select * from final

Zein gauza interesgarri ikus ditzakegu hemen?

Lehena: CTE (Common Table Expressions) erabilia - eraldaketa eta negozio-logika asko dituen kodea antolatzeko eta ulertzeko

Bigarrena: eredu-kodea SQL eta hizkuntzaren nahasketa bat da Jinja (txantiloi hizkuntza).

Adibideak begizta bat erabiltzen du egiteko adierazpenean zehaztutako ordainketa-metodo bakoitzeko zenbatekoa sortzeko ezarri. Funtzioa ere erabiltzen da ref — Kodearen barruan beste eredu batzuk erreferentzia egiteko gaitasuna:

Konpilazioan zehar ref Helburu-erakusle bihurtuko da Biltegiratze-ko taula edo ikuspegi baterako
ref mendekotasun grafiko eredu bat eraikitzeko aukera ematen du

Zehazki Jinja aukera ia mugagabeak gehitzen dizkio DBTri. Gehien erabiltzen direnak hauek dira:

If / else adierazpenak - adar adierazpenak
Begiztak - zikloak
Aldagaiak
Makroa - makroak sortzea

Materializazioa: Taula, Ikuspegia, Inkrementala

Materializazio-estrategia, ondoriozko eredu-datuen multzoa Biltegian gordeko den ikuspegi bat da.

Oinarrizko terminoetan hauxe da:

Taula - Biltegiko taula fisikoa
Ikusi - ikusi, biltegiratze-ko mahai birtuala

Materializazio estrategia konplexuagoak ere badaude:

Karga inkrementala (gertaera handien taulak); lerro berriak gehitzen dira, aldatutako lerroak eguneratzen dira, ezabatutako lerroak garbitzen dira
Efimeroa - eredua ez da zuzenean gauzatzen, CTE gisa parte hartzen du beste eredu batzuetan
Zuk zeuk gehi ditzakezun beste edozein estrategia

Materializazio estrategiez gain, Biltegiratze espezifikoetarako optimizatzeko aukerak daude, adibidez:

Snowflake: Taulen iragankorrak, Bateratzearen portaera, Taulen multzokatzea, Kopiatzeko laguntzak, Ikuspegi seguruak
Redshift: Distkey, Sortkey (tartekatua, konposatua), Late Binding Views
BigQuery: Taulen partizioa eta multzokatzea, Bateratzearen portaera, KMS enkriptatzea, Etiketak eta etiketak
Txinparta: Fitxategiaren formatua (parquet, csv, json, orc, delta), partition_by, clustered_by, buckets, incremental_strategy

Une honetan biltegiratze hauek onartzen dira:

Postgresak
Redshift
BigQuery
Snowflake
Presto (partzialki)
Txinparta (partzialki)
Microsoft SQL Server (komunitate-egokitzailea)

Hobe dezagun gure eredua:

Egin dezagun bere betetzea gehigarria (Inkrementala)
Gehi ditzagun segmentazio eta ordenatzeko gakoak Redshift-erako

-- Конфигурация модели: 
-- Инкрементальное наполнение, уникальный ключ для обновления записей (unique_key)
-- Ключ сегментации (dist), ключ сортировки (sort)
{{
  config(
       materialized='incremental',
       unique_key='order_id',
       dist="customer_id",
       sort="order_date"
   )
}}
 
{% set payment_methods = ['credit_card', 'coupon', 'bank_transfer', 'gift_card'] %}
 
with orders as (
 
   select * from {{ ref('stg_orders') }}
   where 1=1
   {% if is_incremental() -%}
       -- Этот фильтр будет применен только для инкрементального запуска
       and order_date >= (select max(order_date) from {{ this }})
   {%- endif %} 
 
),
 
order_payments as (
 
   select * from {{ ref('order_payments') }}
 
),
 
final as (
 
   select
       orders.order_id,
       orders.customer_id,
       orders.order_date,
       orders.status,
       {% for payment_method in payment_methods -%}
       order_payments.{{payment_method}}_amount,
       {% endfor -%}
       order_payments.total_amount as amount
   from orders
       left join order_payments using (order_id)
 
)
 
select * from final

Ereduaren mendekotasun grafikoa

Mendekotasun zuhaitza ere bada. DAG (Directed Acyclic Graph) izenez ere ezagutzen da.

DBT-k grafiko bat eraikitzen du proiektu-eredu guztien konfigurazioan oinarrituta, edo hobeto esanda, ref() ereduetan beste eredu batzuekin lotzen ditu. Grafiko bat izateak gauza hauek egiteko aukera ematen du:

Exekutatu ereduak sekuentzia egokian
Erakusleihoaren eraketaren paralelismoa
Azpigrafo arbitrario bat exekutatzen

Grafikoen bistaratzeko adibidea:

Grafikoaren nodo bakoitza eredu bat da; grafikoaren ertzak erref adierazpenaren bidez zehazten dira.

Datuen Kalitatea eta Dokumentazioa

Ereduak beraiek sortzeaz gain, DBTk ondoriozko datu multzoari buruzko hainbat hipotesi probatzeko aukera ematen du, hala nola:

Ez Nulua
Unique
Erreferentziaren osotasuna - osotasun erreferentziala (adibidez, eskaerak taulako customer_id id-ari dagokio bezeroen taulan)
Balio onargarrien zerrenda bat etortzea

Zure probak gehi ditzakezu (datuen proba pertsonalizatuak), adibidez, diru-sarreren % desbideraketa duela egun bateko, aste bateko, hilabete bateko adierazleekin. SQL kontsulta gisa formulatutako edozein hipotesi proba bihur daiteke.

Modu honetan, Biltegiko leihoetan datuetan nahi ez diren desbideraketak eta akatsak atzeman ditzakezu.

Dokumentazioari dagokionez, DBTk metadatuak eta iruzkinak gehitzeko, bertsioratzeko eta banatzeko mekanismoak eskaintzen ditu eredu eta baita atributu mailetan ere.

Hona hemen probak eta dokumentazioa gehitzea konfigurazio fitxategien mailan:

 - name: fct_orders
   description: This table has basic information about orders, as well as some derived facts based on payments
   columns:
     - name: order_id
       tests:
         - unique # проверка на уникальность значений
         - not_null # проверка на наличие null
       description: This is a unique identifier for an order
     - name: customer_id
       description: Foreign key to the customers table
       tests:
         - not_null
         - relationships: # проверка ссылочной целостности
             to: ref('dim_customers')
             field: customer_id
     - name: order_date
       description: Date (UTC) that the order was placed
     - name: status
       description: '{{ doc("orders_status") }}'
       tests:
         - accepted_values: # проверка на допустимые значения
             values: ['placed', 'shipped', 'completed', 'return_pending', 'returned']

Eta hona hemen dokumentazio honek sortutako webgunean nolakoa den:

Makroak eta moduluak

DBTren helburua ez da hainbeste SQL script multzo bat bihurtzea, baizik eta erabiltzaileei beren eraldaketak eraikitzeko eta modulu hauek banatzeko baliabide indartsu eta ezaugarri aberatsak eskaintzea.

Makroak ereduen barruan funtzio gisa dei daitezkeen eraikuntza eta adierazpen multzoak dira. Makroek ereduen eta proiektuen artean SQL berrerabiltzeko aukera ematen dute DRY (Ez errepikatu zeure burua) ingeniaritza printzipioaren arabera.

Makro adibidea:

{% macro rename_category(column_name) %}
case
 when {{ column_name }} ilike  '%osx%' then 'osx'
 when {{ column_name }} ilike  '%android%' then 'android'
 when {{ column_name }} ilike  '%ios%' then 'ios'
 else 'other'
end as renamed_product
{% endmacro %}

Eta bere erabilera:

{% set column_name = 'product' %}
select
 product,
 {{ rename_category(column_name) }} -- вызов макроса
from my_table

DBT pakete-kudeatzaile batekin dator erabiltzaileek modulu eta makro indibidualak argitaratzeko eta berrerabiltzeko.

Horrek esan nahi du liburutegiak kargatu eta erabili ahal izatea, hala nola:

dbt_utils: Data/Ordua, Ordezko gakoak, eskema probak, Pibota/Unpivot eta beste batzuekin lan egitea
Esaterako zerbitzuetarako prest dauden erakusleiho txantiloiak Elurtegia и Stripe
Datu-biltegi zehatzetarako liburutegiak, adibidez. Redshift
Logging — DBT eragiketa erregistratzeko modulua

Paketeen zerrenda osoa helbidean aurki daiteke dbt hub.

Are ezaugarri gehiago

Hemen taldeak eta biok Datu Biltegi bat eraikitzeko erabiltzen ditugun beste ezaugarri eta inplementazio interesgarri batzuk deskribatuko ditut. gurpila.

Exekuzio-inguruneak bereiztea DEV - TEST - PROD

Baita DWH kluster beraren barruan ere (eskema ezberdinen barruan). Adibidez, honako adierazpen hau erabiliz:

with source as (
 
   select * from {{ source('salesforce', 'users') }}
   where 1=1
   {%- if target.name in ['dev', 'test', 'ci'] -%}           
       where timestamp >= dateadd(day, -3, current_date)   
   {%- endif -%}
 
)

Kode honek literalki dio: inguruneetarako dev, proba, ci hartu azken 3 egunetako datuak eta ez gehiago. Hau da, ingurune hauetan exekutatzen aritzea askoz azkarragoa izango da eta baliabide gutxiago beharko ditu. Ingurunean exekutatzen denean prod iragazkien baldintza ez ikusi egingo da.

Materializazioa ordezko zutabeen kodeketarekin

Redshift zutabe bakoitzerako datu-konpresioaren algoritmoak ezartzeko aukera ematen duen DBMS zutabe bat da. Algoritmo optimoak hautatzeak diskoko espazioa % 20-50 murriztu dezake.

Makroa redshift.konprimitu_taula ANALYZE COMPRESSION komandoa exekutatuko du, taula berri bat sortuko du gomendatutako zutabeen kodeketa algoritmoekin, zehaztutako segmentazio-gakoekin (dist_key) eta ordenatzeko gakoekin (sort_key), datuak bertara transferituko ditu eta, behar izanez gero, kopia zaharra ezabatuko du.

Makro sinadura:

{{ compress_table(schema, table,
                 drop_backup=False,
                 comprows=none|Integer,
                 sort_style=none|compound|interleaved,
                 sort_keys=none|List<String>,
                 dist_style=none|all|even,
                 dist_key=none|String) }}

Erregistro-eredua exekutatzen da

Ereduaren exekuzio bakoitzari kakoak erantsi diezazkiokezu, abiarazi baino lehen edo eredua sortzea amaitu eta berehala:

   pre-hook: "{{ logging.log_model_start_event() }}"
   post-hook: "{{ logging.log_model_end_event() }}"

Erregistro-moduluari esker, beharrezkoak diren metadatu guztiak bereizitako taula batean grabatzeko aukera emango dizu, eta, ondoren, botila-lepoak ikuskatu eta aztertzeko erabil daiteke.

Hau da arbelaren itxura Looker-en erregistroko datuetan oinarrituta:

Biltegiratze Mantentzearen Automatizazioa

Erabilitako Biltegiaren funtzionalitatearen luzapen batzuk erabiltzen badituzu, hala nola UDF (Erabiltzaileak Definitutako Funtzioak), orduan funtzio horien bertsioa, sarbide-kontrola eta bertsio berrien zabaltze automatizatua oso erosoa da DBTn egiteko.

UDF erabiltzen dugu Python-en hashak, posta elektronikoko domeinuak eta bitmasken deskodeketa kalkulatzeko.

Edozein exekuzio-ingurunetan UDF bat sortzen duen makro baten adibidea (garapena, proba, produkzioa):

{% macro create_udf() -%}
 
 {% set sql %}
       CREATE OR REPLACE FUNCTION {{ target.schema }}.f_sha256(mes "varchar")
           RETURNS varchar
           LANGUAGE plpythonu
           STABLE
       AS $$  
           import hashlib
           return hashlib.sha256(mes).hexdigest()
       $$
       ;
 {% endset %}
  
 {% set table = run_query(sql) %}
 
{%- endmacro %}

Wheely-n Amazon Redshift erabiltzen dugu, hau da, PostgreSQL-n oinarrituta. Redshift-erako, garrantzitsua da aldian-aldian taulen estatistikak biltzea eta diskoko lekua askatzea - ANALYZE eta VACUUM komandoak, hurrenez hurren.

Horretarako, redshift_maintenance makroaren aginduak exekutatzen dira gauero:

{% macro redshift_maintenance() %}
 
   {% set vacuumable_tables=run_query(vacuumable_tables_sql) %}
 
   {% for row in vacuumable_tables %}
       {% set message_prefix=loop.index ~ " of " ~ loop.length %}
 
       {%- set relation_to_vacuum = adapter.get_relation(
                                               database=row['table_database'],
                                               schema=row['table_schema'],
                                               identifier=row['table_name']
                                   ) -%}
       {% do run_query("commit") %}
 
       {% if relation_to_vacuum %}
           {% set start=modules.datetime.datetime.now() %}
           {{ dbt_utils.log_info(message_prefix ~ " Vacuuming " ~ relation_to_vacuum) }}
           {% do run_query("VACUUM " ~ relation_to_vacuum ~ " BOOST") %}
           {{ dbt_utils.log_info(message_prefix ~ " Analyzing " ~ relation_to_vacuum) }}
           {% do run_query("ANALYZE " ~ relation_to_vacuum) %}
           {% set end=modules.datetime.datetime.now() %}
           {% set total_seconds = (end - start).total_seconds() | round(2)  %}
           {{ dbt_utils.log_info(message_prefix ~ " Finished " ~ relation_to_vacuum ~ " in " ~ total_seconds ~ "s") }}
       {% else %}
           {{ dbt_utils.log_info(message_prefix ~ ' Skipping relation "' ~ row.values() | join ('"."') ~ '" as it does not exist') }}
       {% endif %}
 
   {% endfor %}
 
{% endmacro %}

DBT hodeia

DBT zerbitzu gisa erabil daiteke (Zerbitzu Kudeatua). Barne:

Web IDE proiektuak eta ereduak garatzeko
Lanpostuaren konfigurazioa eta programazioa
Erregistroetarako sarbide erraza eta erosoa
Webgunea zure proiektuaren dokumentazioarekin
CI konektatzen (Etengabeko Integrazioa)

Ondorioa

DWH prestatzea eta kontsumitzea smoothie bat edatea bezain atsegina eta onuragarria bihurtzen da. DBT Jinja, erabiltzaileen luzapenak (moduluak), konpiladore bat, exekutatzaile bat eta pakete kudeatzaile batek osatzen dute. Elementu hauek elkartuz zure datu biltegirako lan-ingurune osoa lortuko duzu. Gaur egun ez dago DWHren eraldaketa kudeatzeko modu hoberik.

DBTren garatzaileek jarraitzen dituzten usteak honela formulatzen dira:

Kodea, ez GUI, logika analitiko konplexua adierazteko abstrakzio onena da
Datuekin lan egiteak software ingeniaritzako praktika onenak egokitu beharko lituzke (Software Ingeniaritza)

Datuen azpiegitura kritikoak erabiltzaileen komunitateak kontrolatu behar ditu kode irekiko software gisa
Analitika tresnak ez ezik, kodea ere gero eta gehiago izango da Kode Irekiko komunitatearen jabetza

Oinarrizko sinesmen hauek gaur egun 850 enpresa baino gehiagok erabiltzen duten produktua sortu dute, eta etorkizunean sortuko diren luzapen zirraragarri askoren oinarria dira.

Interesa dutenentzat, duela hilabete batzuk OTUSeko ikasgai ireki baten barruan eman nuen ikasgai ireki baten bideoa dago - Datuak eraikitzeko tresna Amazon Redshift biltegirako.

DBT eta Data Warehousing-az gain, OTUS plataformako Data Engineer ikastaroaren barruan, nire lankideek eta biok beste gai garrantzitsu eta moderno batzuei buruzko klaseak ematen ditugu:

Big Data aplikazioetarako kontzeptu arkitektonikoak
Praktikatu Spark eta Spark Streaming-ekin
Datu-iturriak kargatzeko metodoak eta tresnak aztertzea
Erakusleiho analitikoak eraikitzea DWHn
NoSQL kontzeptuak: HBase, Cassandra, ElasticSearch
Jarraipenaren eta orkestrazioaren printzipioak
Amaierako Proiektua: trebetasun guztiak mentoring laguntzapean jartzea

erreferentziak:

DBT dokumentazioa - Sarrera — Dokumentazio ofiziala
Zer da, zehazki, dbt? — DBTren egileetako baten berrikuspena artikulua
Datuak eraikitzeko tresna Amazon Redshift biltegirako — YouTube, OTUS ikasgai ireki baten grabaketa
Greenplum ezagutzea - Hurrengo ikasgai irekia 15ko maiatzaren 2020a da
Datuen Ingeniaritza Ikastaroa —OTUS
Analitikako lan-fluxu heldu bat eraikitzea — Datuen eta analitikaren etorkizunari begirada bat
Kode irekiko analisien garaia da — Analitikaren bilakaera eta Kode Irekiaren eragina
Etengabeko integrazioa eta eraikitze-proba automatizatuak dbtCloud-ekin — DBT erabiliz CI eraikitzeko printzipioak
DBT tutorialarekin hasteko — Praktika, Lan independenterako urratsez urratseko argibideak
Jaffle denda — Github DBT Tutoriala — Github, hezkuntza proiektuaren kodea

Ikastaroari buruzko informazio gehiago.

Iturria: www.habr.com

Data Build Tool edo Data Warehouse eta Smoothie-ren artean ohikoa dena