Li ser kîjan prensîban Wargehek Daneyê ya îdeal tê çêkirin?
Di nebûna koda boilerplate de li ser nirx û analîtîkên karsaziyê bisekinin. Birêvebirina DWH wekî bingehek kodê: guhertokirin, vekolîn, ceribandina otomatîk û CI. Modular, berfireh, çavkaniya vekirî û civak. Belgekirina bikarhêner-heval û dîtbariya girêdayîbûnê (Data Lineage).
Zêdetir li ser van hemîyan û di derbarê rola DBT-ê de di ekosîstema Big Data & Analytics de - bi xêr hatî pisîkê.
Silav ji her kesê re
Artemy Kozyr di têkiliyê de ye. Zêdetirî 5 sal in ez bi depoyên daneyê re dixebitim, ETL/ELT ava dikim, û her weha analîzên daneyê û dîtbarîkirinê. Ez niha tê de dixebitim , Ez li OTUS li ser kursê ders didim , û îro ez dixwazim gotarek ku min li hêviya destpêkê nivîsî bi we re parve bikim qeydkirina nû ji bo qursê.
Pêşniyarek kurt
Çarçoveya DBT hemî li ser T-ya di kurtenivîsa ELT (Extract - Veguherandin - Barkirin) de ye.
Bi hatina van databasên analîtîk ên hilber û berbelav ên wekî BigQuery, Redshift, Snowflake, ti wateya kirina veguherînan li derveyî Wargeha Daneyê tune bû.
DBT daneyan ji çavkaniyan dakêşîne, lê ji bo xebata bi daneyên ku berê di hilanînê de hatine barkirin (di Parzûngeha Navxweyî an Derveyî de) fersendên mezin peyda dike.
Armanca sereke ya DBT ev e ku kodê bigire, wê di SQL de berhev bike, di Depoyê de fermanan bi rêza rast bicîh bîne.
Struktura Projeya DBT
Proje ji pelrêç û pelên tenê 2 celeb pêk tê:
- Model (.sql) - yekîneyek veguherînê ku ji hêla pirsek SELECT ve hatî diyar kirin
- Pelê veavakirinê (.yml) - Parametre, mîheng, ceribandin, belge
Di asta bingehîn de, xebat bi vî rengî têne saz kirin:
- Bikarhêner koda modelê di her IDE-ya hêsan de amade dike
- Bi karanîna CLI, model têne destpêkirin, DBT koda modelê di SQL de berhev dike
- Koda SQL ya berhevkirî di rêzek diyarkirî de (grafîk) di hilanînê de tê darve kirin.
Li vir e ku meriv ji CLI-ê dibe ku mîna xuya bike:
Her tişt SELECT e
Ev taybetmendiyek kujer a çarçoveya Amûra Avakirina Daneyê ye. Bi gotinek din, DBT hemî kodên ku bi materyalkirina pirsên we ve girêdayî ye di Firotanê de vedihewîne (guhertinên ji emrên CREATE, INSERT, UPDATE, DELETE ALTER, GRANT, ...).
Her modelek bi nivîsandina yek pirsek SELECT ku berhevoka daneya encam diyar dike vedihewîne.
Di vê rewşê de, mantiqa veguherînê dikare pir-ast be û daneyên ji çend modelên din yek bike. Mînakek modelek ku dê pêşangehek fermanê ava bike (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
Çi tiştên balkêş em dikarin li vir bibînin?
Yekem: CTE (Girêdanên Tabloya Hevbeş) bi kar anîn - ji bo organîzekirin û têgihîştina koda ku gelek veguherîn û mantiqa karsaziyê vedihewîne.
Duyemîn: Koda modelê tevliheviyek ji SQL û ziman e (zimanê şablonê).
Nimûne xelekek bikar tîne bo ji bo her awayê dravdanê yê ku di vegotinê de hatî destnîşan kirin mîqdara biafirîne danîn. Fonksiyon jî tê bikaranîn ref - şiyana referanskirina modelên din di hundurê kodê de:
- Di dema berhevkirinê de ref dê di Storage de veguhezîne nîşankerek armancek li ser maseyek an dîmenek
- ref destûrê dide te ku hûn grafiyek pêwendiya modelê ava bikin
Ew bû hema hema îmkanên bêsînor li DBT zêde dike. Yên ku herî zêde têne bikar anîn ev in:
- Daxuyaniyên Heke / din - daxuyaniyên şaxê
- Ji bo loops
- Variables
- Makro - afirandina makroyan
Materyalîzasyon: Tablo, Dîtin, Zêdebûn
Stratejiya materyalîzasyonê nêzîkbûnek e ku li gorî wê berhevoka encamên modelê dê di Storage de were hilanîn.
Di şertên bingehîn de ev e:
- Tablo - tabloya fizîkî ya di hilanînê de
- Dîtin - dîtin, tabloya virtual di Storage
Di heman demê de stratejiyên materyalîzasyona tevlihevtir jî hene:
- Zêdebûn - barkirina zêde (tabloyên rastiyên mezin); xetên nû tên zêdekirin, rêzên guherî tên nûkirin, xetên jêbirin tên paqijkirin
- Ephemeral - model rasterast pêk nayê, lê wekî CTE di modelên din de beşdar dibe
- Stratejiyên din ên ku hûn dikarin xwe lê zêde bikin
Ji bilî stratejiyên materyalîzasyonê, ji bo Depoyên taybetî derfetên xweşbîniyê hene, mînakî:
- snowflake: Tabloyên demkî, Tevhevkirina tevhevkirinê, Komkirina tabloyê, Kopîkirina alîkariyê, Nêrînên ewle
- Redshift: Bişkojka Distkey, Bişkojka Sort (navber, hevedudanî), Dîmenên Binding Dereng
- bigquery: Dabeşkirin û komkirina tabloyê, Tevhevkirina tevhevkirinê, Şîfrekirina KMS, Etîket û Etîket
- spark: Forma pelê (parket, csv, json, orc, delta), partition_by, clustered_by, buckets, incremental_strategy
Depoyên jêrîn niha têne piştgirî kirin:
- postgres
- Redshift
- bigquery
- snowflake
- Presto (bi qismî)
- Spark (bi qismî)
- Microsoft SQL Server (adaptera civakê)
Ka em modela xwe baştir bikin:
- Ka em dagirtina wê zêde bikin (Zêdebûn)
- Ka em ji bo Redshift bişkokên dabeşkirin û birêkûpêk zêde bikin
-- Конфигурация модели:
-- Инкрементальное наполнение, уникальный ключ для обновления записей (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
Grafika girêdayîbûna modelê
Ew jî dara girêdayîbûnê ye. Ew wekî DAG (Grafîka Acyclic Directed) jî tê zanîn.
DBT grafiyek li ser bingeha veavakirina hemî modelên projeyê ava dike, an bêtir, ref() di nav modelan de bi modelên din ve girêdide. Hebûna grafiyek dihêle hûn tiştên jêrîn bikin:
- Modelên di rêza rast de dimeşînin
- Parallelization ji damezrandina storefront
- Bingrafek keyfî dimeşîne
Mînaka dîtbariya grafîkê:
Her girêka grafîkê modelek e; keviyên grafikê bi raveka ref tê diyar kirin.
Quality Data û Belgekirin
Digel hilberîna modelan bixwe, DBT dihêle hûn di derheqê berhevoka daneya encam de çend texmînan biceribînin, wek:
- Ne Null
- Yekane
- Tenduristiya Referansê - yekparebûna referansê (mînak, di tabloya fermanan de id-ya xerîdar bi id-ê di tabloya xerîdaran re têkildar e)
- Lihevhatina navnîşa nirxên pejirandî
Mimkun e ku hûn ceribandinên xwe (ceribandinên daneya xwerû) lê zêde bikin, wek mînak, % guheztina dahatê bi nîşaneyên ji rojek, hefteyek, mehek berê. Her texmînek ku wekî pirsek SQL hatî çêkirin dikare bibe ceribandinek.
Bi vî rengî, hûn dikarin di pencereyên Warehouse de dev û xeletiyên nedilxwaz di daneyan de bigirin.
Di warê belgekirinê de, DBT mekanîzmayên lê zêdekirin, guhertokirin, û belavkirina metadata û şîroveyan di astên model û tewra taybetmendiyê de peyda dike.
Li vir çi ye ku lêzêdekirina ceribandin û belgekirinê di asta pelê vesazkirinê de xuya dike:
- 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']
Û li vir ev e ku ev belge li ser malpera çêkirî çawa xuya dike:
Makro û Modul
Armanca DBT ne ew qas ew e ku bibe komek nivîsarên SQL, lê ew e ku ji bo avakirina veguherînên xwe û belavkirina van modulan navgînek hêzdar û dewlemend a bikarhêneran peyda bike.
Makro komek avahî û biwêjan in ku dikarin wekî fonksiyonên di nav modelan de bêne binav kirin. Makro dihêlin ku hûn SQL di navbera model û projeyan de li gorî prensîba endezyariya DRY (Xwe Dubare Nekin) ji nû ve bikar bînin.
Mînakek makro:
{% 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 %}
Û bikaranîna wê:
{% set column_name = 'product' %}
select
product,
{{ rename_category(column_name) }} -- вызов макроса
from my_table
DBT bi rêveberek pakêtê re tê ku destûrê dide bikarhêner ku modul û makroyên kesane biweşînin û ji nû ve bikar bînin.
Ev tê vê wateyê ku hûn dikarin pirtûkxaneyên wekî barkirin û bikar bînin:
- : bi Dîrok / Dem, Bişkojkên Surrogate, Testên Schema, Pivot / Unpivot û yên din re dixebitin
- Şablonên pêşangeha amade-made ji bo karûbarên wekî и
- Pirtûkxaneyên ji bo Dikanên Daneyên taybetî, wek mînak.
- - Modula ji bo têketina operasyona DBT
Lîsteya bêkêmasî ya pakêtan dikare li vir were dîtin .
Hê bêtir taybetmendiyên
Li vir ez ê çend taybetmendî û pêkanînên balkêş ên din ên ku ez û tîmê bikar tînin ji bo avakirina Wargeha Daneyê li .
Veqetandina hawîrdorên dema xebitandinê DEV - TEST - PROD
Tewra di nav heman koma DWH de (di nav nexşeyên cûda de). Mînakî, peyva jêrîn bikar bînin:
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 -%}
)
Ev kod bi rastî dibêje: ji bo hawîrdoran dev, test, ci daneyên tenê ji bo 3 rojên dawîn û ne bêtir bistînin. Ango, xebitandina di van hawîrdoran de dê pir zûtir be û kêmtir çavkaniyan hewce dike. Dema ku li ser jîngehê dimeşîne çêkerî rewşa Parzûnê dê bê paşguh kirin.
Materyalîzasyon bi şîfrekirina stûna alternatîf
Redshift DBMSek stûnek e ku dihêle hûn ji bo her stûnek kesane algorîtmayên berhevkirina daneyan saz bikin. Hilbijartina algorîtmayên çêtirîn dikare cîhê dîskê 20-50% kêm bike.
Macro dê fermana ANALYZE COMPRESSION bixebite, bi algorîtmayên şîfrekirina stûnê yên pêşniyarkirî, bişkokên dabeşkirinê yên diyarkirî (dist_key) û bişkojên cûrbecûr (sort_key) tabloyek nû biafirîne, daneyan veguhezîne wê, û heke hewce bike, kopiya kevn jê bibe.
Îmzeya makro:
{{ 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) }}
Modela têketinê dimeşe
Hûn dikarin çengan bi her pêkanîna modelê ve girêbidin, ku dê berî destpêkirinê an tavilê piştî ku çêkirina modelê qediya were darve kirin:
pre-hook: "{{ logging.log_model_start_event() }}"
post-hook: "{{ logging.log_model_end_event() }}"
Modula têketinê dê bihêle hûn hemî metadaneyên pêwîst di tabloyek veqetandî de tomar bikin, ku paşê dikare were bikar anîn ji bo kontrolkirin û analîzkirina kêşan.
Tiştê ku dashboard li ser bingeha daneyên têketinê di Looker de xuya dike ev e:
Automation of Storage Maintenance
Ger hûn hin dirêjkirina fonksiyonên Depoya bikar anîn, wek UDF (Fonksiyonên Bikarhêner Diyarkirî) bikar bînin, wê hingê guhertoya van fonksiyonan, kontrolkirina gihîştinê, û derxistina otomatîkî ya weşanên nû pir hêsan e ku meriv di DBT-ê de bike.
Em UDF-ê di Python-ê de bikar tînin da ku haş, domên e-nameyê, û deşîfrekirina bitmask hesab bikin.
Mînaka makroyek ku li ser her hawîrdorek darvekirinê (dev, test, prod) UDF diafirîne:
{% 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 %}
Li Wheely em Amazon Redshift, ku li ser bingeha PostgreSQL-ê ye, bikar tînin. Ji bo Redshift, girîng e ku meriv bi rêkûpêk statîstîkên li ser tabloyan berhev bike û cîhê dîskê azad bike - bi rêzê fermanên ANALYZE û VACUUM.
Ji bo vê yekê, emrên ji makroya redshift_maintenance her şev têne darve kirin:
{% 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 Cloud
Mimkun e ku meriv DBT wekî karûbarek (Xizmeta Birêvebir) bikar bîne. Tê de:
- Web IDE ji bo pêşvebirina proje û modelan
- Veavakirin û plansazkirina kar
- Gihîştina hêsan û hêsan a têketin
- Malpera bi belgekirina projeya we
- Girêdana CI (Integrasyona Berdewam)
encamê
Amadekirin û vexwarina DWH bi qasî vexwarina şilavek xweş û sûdmend dibe. DBT ji Jinja, pêvekên bikarhêner (modul), berhevkar, îcrakar û rêveberek pakêtê pêk tê. Bi berhevkirina van hêmanan hûn ji bo Wargeha Daneyên xwe jîngehek xebatê ya bêkêmasî digirin. Ji bo birêvebirina veguherîna di nav DWH de îro rêyek çêtir tune.
Baweriyên ku ji hêla pêşdebirên DBT ve têne peyda kirin wiha têne formule kirin:
- Kod, ne GUI, ji bo îfadekirina mentiqê analîtîk a tevlihev çêtirîn abstrakasyon e
- Pêdivî ye ku bi daneyan re bixebitin ku di endezyariya nermalavê de pratîkên çêtirîn adapte bikin (Endezyariya Nermalavê)
- Binesaziya daneya krîtîk divê ji hêla civaka bikarhêner ve wekî nermalava çavkaniya vekirî were kontrol kirin
- Ne tenê amûrên analîtîk, lê di heman demê de kod jî dê her ku diçe bibe milkê civaka Çavkaniya Vekirî
Van baweriyên bingehîn hilberek çêkiriye ku îro ji hêla zêdetirî 850 pargîdaniyan ve tê bikar anîn, û ew bingeha gelek dirêjkirinên balkêş ên ku dê di pêşerojê de werin afirandin pêk tînin.
Ji bo kesên eleqedar, vîdyoyek dersek vekirî heye ku min çend meh berê wekî beşek ji dersek vekirî li OTUS da - .
Ji bilî DBT û Warehousing Data, wekî beşek ji qursa Endezyarê Daneyên li ser platforma OTUS, ez û hevkarên xwe li ser çend mijarên din ên têkildar û nûjen dersan didin:
- Têgehên Mîmarî ji bo Serlêdanên Daneyên Mezin
- Bi Spark û Spark Streaming re pratîk bikin
- Vekolîna rêbaz û amûrên ji bo barkirina çavkaniyên daneyê
- Di DWH de pêşangehên analîtîk ava dikin
- Têgehên NoSQL: HBase, Cassandra, ElasticSearch
- Prensîbên çavdêrî û orkestrasyonê
- Projeya Dawî: Hemî jêhatîbûn di bin piştgirîya şêwirmendiyê de bi hev re danîn
References:
- - Belgeyên fermî
- - Gotara yek ji nivîskarên DBT binirxînin
- - YouTube, Tomarkirina dersek vekirî ya OTUS
- - Dersa vekirî ya din 15 Gulan 2020 e
- -OTUS
- - Nêrînek li paşeroja dane û analîtîk
- - Pêşveçûna analîtîk û bandora Çavkaniya Vekirî
- - Prensîbên avakirina CI bi karanîna DBT
- - Pratîk, talîmatên gav-bi-gav ji bo xebata serbixwe
- - Github, koda projeya perwerdehiyê
Source: www.habr.com