İdeal bir Veri Ambarı hangi ilkeler üzerine kuruludur?
Standart kodun olmadığı durumlarda iş değerine ve analitiklere odaklanın. DWH'yi kod tabanı olarak yönetmek: sürüm oluşturma, inceleme, otomatik test ve CI. Modüler, genişletilebilir, açık kaynak ve topluluk. Kullanıcı dostu dokümantasyon ve bağımlılık görselleştirmesi (Data Lineage).
Tüm bunlar ve DBT'nin Büyük Veri ve Analitik ekosistemindeki rolü hakkında daha fazla bilgi için cat'e hoş geldiniz.
Merhaba
Artemy Kozyr temas halinde. 5 yıldan fazla bir süredir veri ambarları, ETL/ELT oluşturmanın yanı sıra veri analitiği ve görselleştirme ile çalışıyorum. şu anda çalışıyorum OTUS'ta bir kursta ders veriyorum ve bugün sizlerle, başlangıcın beklentisiyle yazdığım bir makaleyi paylaşmak istiyorum. kursa yeni kayıt.
Özet
DBT çerçevesi tamamen ELT (Extract - Transform - Load) kısaltmasındaki T ile ilgilidir.
BigQuery, Redshift, Snowflake gibi üretken ve ölçeklenebilir analitik veritabanlarının ortaya çıkışıyla Veri Ambarı dışında dönüşüm yapmanın bir anlamı kalmadı.
DBT, kaynaklardan veri indirmez ancak Depolamaya (Dahili veya Harici Depolamaya) önceden yüklenmiş olan verilerle çalışmak için harika fırsatlar sunar.
DBT'nin temel amacı kodu almak, SQL'de derlemek, komutları Depoda doğru sırayla yürütmektir.
DBT Proje Yapısı
Proje yalnızca 2 türde dizin ve dosyadan oluşur:
- Model (.sql) - SELECT sorgusu tarafından ifade edilen bir dönüşüm birimi
- Yapılandırma dosyası (.yml) - parametreler, ayarlar, testler, belgeler
Temel düzeyde çalışma şu şekilde yapılandırılmıştır:
- Kullanıcı herhangi bir uygun IDE'de model kodunu hazırlar
- CLI'yi kullanarak modeller başlatılır, DBT model kodunu SQL'de derler
- Derlenen SQL kodu, Depolama alanında belirli bir sırayla (grafik) yürütülür.
CLI'den çalıştırmak şöyle görünebilir:
Her şey SEÇ
Bu, Veri Oluşturma Aracı çerçevesinin mükemmel bir özelliğidir. Başka bir deyişle, DBT, sorgularınızın Mağazada gerçekleştirilmesiyle ilişkili tüm kodu (CREATE, INSERT, UPDATE, DELETE ALTER, GRANT, ... komutlarının varyasyonları) soyutlar.
Herhangi bir model, elde edilen veri kümesini tanımlayan bir SELECT sorgusunun yazılmasını içerir.
Bu durumda, dönüşüm mantığı çok seviyeli olabilir ve diğer birçok modelden gelen verileri birleştirebilir. Sipariş vitrini (f_orders) oluşturacak bir model örneği:
{% 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
Burada ne gibi ilginç şeyler görebiliriz?
Birincisi: Çok sayıda dönüşüm ve iş mantığı içeren kodu düzenlemek ve anlamak için CTE (Ortak Tablo İfadeleri) kullanıldı
İkincisi: Model kodu SQL ve dilin bir karışımıdır (şablon dili).
Örnek bir döngü kullanıyor için ifadede belirtilen her ödeme yöntemine ilişkin tutarı oluşturmak için set. Fonksiyon aynı zamanda kullanılır ref — kod içindeki diğer modellere referans verme yeteneği:
- Derleme sırasında ref Depolama alanında bir tabloya veya görünüme yönelik bir hedef işaretçiye dönüştürülecek
- ref bir model bağımlılığı grafiği oluşturmanıza olanak tanır
Tam DBT'ye neredeyse sınırsız olanaklar ekler. En sık kullanılanlar şunlardır:
- If / else ifadeleri - dal ifadeleri
- Döngüler için
- Değişkenler
- Makro - makrolar oluşturma
Gerçekleştirme: Tablo, Görünüm, Artımlı
Gerçekleştirme stratejisi, ortaya çıkan model veri setinin Depolamada saklanacağı bir yaklaşımdır.
Temel anlamda şöyledir:
- Tablo - Depolamadaki fiziksel tablo
- Görünüm - görünüm, Depolamadaki sanal tablo
Daha karmaşık gerçekleştirme stratejileri de vardır:
- Artımlı - artımlı yükleme (büyük olgu tablolarının); yeni satırlar eklenir, değişen satırlar güncellenir, silinen satırlar temizlenir
- Geçici - model doğrudan gerçekleşmez ancak diğer modellere CTE olarak katılır
- Kendiniz ekleyebileceğiniz diğer stratejiler
Gerçekleştirme stratejilerine ek olarak belirli Depolamalar için optimizasyon fırsatları da vardır, örneğin:
- Kar taneciği: Geçici tablolar, Birleştirme davranışı, Tablo kümeleme, İzinlerin kopyalanması, Güvenli görünümler
- Redshift: Distkey, Sortkey (serpiştirilmiş, bileşik), Geç Ciltleme Görünümleri
- BigQuery: Tablo bölümleme ve kümeleme, Birleştirme davranışı, KMS Şifreleme, Etiketler ve Etiketler
- Kıvılcım: Dosya formatı (parke, csv, json, orc, delta), partition_by,clused_by, buckets, artımlı_strateji
Şu anda aşağıdaki Depolamalar desteklenmektedir:
- postgres
- Redshift
- BigQuery
- Kar taneciği
- Presto (kısmen)
- Kıvılcım (kısmen)
- Microsoft SQL Server (topluluk bağdaştırıcısı)
Modelimizi geliştirelim:
- Doldurmasını artımlı yapalım (Artımlı)
- Redshift için segmentasyon ve sıralama anahtarları ekleyelim
-- Конфигурация модели:
-- Инкрементальное наполнение, уникальный ключ для обновления записей (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
Model bağımlılığı grafiği
Aynı zamanda bir bağımlılık ağacıdır. DAG (Yönlendirilmiş Asiklik Grafik) olarak da bilinir.
DBT, tüm proje modellerinin konfigürasyonuna dayalı bir grafik oluşturur veya daha doğrusu, modeller içindeki diğer modellere olan ref() bağlantılarını kullanır. Bir grafiğe sahip olmak aşağıdakileri yapmanıza olanak tanır:
- Modelleri doğru sırayla çalıştırma
- Vitrin oluşumunun paralelleştirilmesi
- Rastgele bir alt grafiğin çalıştırılması
Grafik görselleştirme örneği:
Grafiğin her düğümü bir modeldir; grafiğin kenarları ref ifadesiyle belirtilir.
Veri Kalitesi ve Dokümantasyon
Modellerin kendilerini oluşturmanın yanı sıra, DBT, ortaya çıkan veri seti hakkında aşağıdakiler gibi bir dizi varsayımı test etmenize olanak tanır:
- Geçersiz değil
- Benzersiz
- Referans Bütünlüğü - referans bütünlüğü (örneğin, siparişler tablosundaki müşteri_kimliği, müşteriler tablosundaki kimliğe karşılık gelir)
- Kabul edilebilir değerler listesini eşleştirme
Örneğin, bir gün, bir hafta, bir ay önceki göstergelerle gelirdeki sapma yüzdesi gibi kendi testlerinizi (özel veri testleri) eklemek mümkündür. SQL sorgusu olarak formüle edilen herhangi bir varsayım bir test haline gelebilir.
Bu sayede Depo pencerelerindeki verilerde istenmeyen sapmaları ve hataları yakalayabilirsiniz.
Dokümantasyon açısından DBT, meta verileri ve yorumları model ve hatta öznitelik düzeylerinde ekleme, sürüm oluşturma ve dağıtmaya yönelik mekanizmalar sağlar.
Yapılandırma dosyası düzeyinde testler ve belgeler eklemenin nasıl göründüğü aşağıda açıklanmıştır:
- 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']
Ve işte bu dokümantasyonun oluşturulan web sitesinde nasıl göründüğü:
Makrolar ve Modüller
DBT'nin amacı bir dizi SQL betiği olmak değil, kullanıcılara kendi dönüşümlerini oluşturmaları ve bu modülleri dağıtmaları için güçlü ve zengin özelliklere sahip bir araç sağlamaktır.
Makrolar, modeller içindeki işlevler olarak adlandırılabilecek yapı ve ifade kümeleridir. Makrolar, DRY (Kendini Tekrarlama) mühendislik ilkesine uygun olarak SQL'i modeller ve projeler arasında yeniden kullanmanıza olanak tanır.
Makro örneği:
{% 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 %}
Ve kullanımı:
{% set column_name = 'product' %}
select
product,
{{ rename_category(column_name) }} -- вызов макроса
from my_table
DBT, kullanıcıların bireysel modülleri ve makroları yayınlamasına ve yeniden kullanmasına olanak tanıyan bir paket yöneticisiyle birlikte gelir.
Bu, aşağıdaki gibi kütüphaneleri yükleyebilmek ve kullanabilmek anlamına gelir:
- : Tarih/Saat, Yedek Anahtarlar, Şema testleri, Pivot/Unpivot ve diğerleriyle çalışma
- Gibi hizmetler için hazır vitrin şablonları и
- Belirli Veri Depolarına yönelik kütüphaneler, ör.
- — DBT işleminin günlüğe kaydedilmesi için modül
Paketlerin tam listesini şu adreste bulabilirsiniz: .
Daha da fazla olasılık
Burada ekibin ve benim Veri Ambarı oluşturmak için kullandığımız diğer birkaç ilginç özelliği ve uygulamayı anlatacağım. .
Çalışma zamanı ortamlarının ayrılması DEV - TEST - PROD
Aynı DWH kümesinde bile (farklı planlar dahilinde). Örneğin aşağıdaki ifadeyi kullanarak:
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 -%}
)
Bu kod tam anlamıyla şunu söylüyor: ortamlar için geliştirme, test, ci yalnızca son 3 güne ait verileri alın, daha fazlasını almayın. Yani bu ortamlarda çalışmak çok daha hızlı olacak ve daha az kaynak gerektirecektir. Ortamda çalışırken dürtme filtre koşulu göz ardı edilecektir.
Alternatif sütun kodlamasıyla materyalleştirme
Redshift, her bir sütun için veri sıkıştırma algoritmaları ayarlamanıza olanak tanıyan sütunlu bir DBMS'dir. Optimum algoritmaların seçilmesi disk alanını %20-50 oranında azaltabilir.
Makro ANALYZE COMPRESSION komutunu yürütecek, önerilen sütun kodlama algoritmaları, belirtilen segmentasyon anahtarları (dist_key) ve sıralama anahtarları (sort_key) ile yeni bir tablo oluşturacak, verileri ona aktaracak ve gerekirse eski kopyayı silecektir.
Makro imza:
{{ 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) }}
Günlüğe kaydetme modeli çalışır
Modelin her uygulamasına, lansmandan önce veya modelin oluşturulması tamamlandıktan hemen sonra yürütülecek kancalar takabilirsiniz:
pre-hook: "{{ logging.log_model_start_event() }}"
post-hook: "{{ logging.log_model_end_event() }}"
Günlük modülü, gerekli tüm meta verileri daha sonra darboğazları denetlemek ve analiz etmek için kullanılabilecek ayrı bir tabloya kaydetmenize olanak tanır.
Looker'daki günlüğe kaydetme verilerine göre kontrol paneli şu şekilde görünür:
Depolama Bakım Otomasyonu
Kullanılan Havuzun UDF (Kullanıcı Tanımlı İşlevler) gibi bazı işlevsellik uzantılarını kullanıyorsanız, bu işlevlerin sürümlendirilmesi, erişim kontrolü ve yeni sürümlerin otomatik olarak kullanıma sunulması DBT'de gerçekleştirilmesi çok kolaydır.
Karma değerleri, e-posta etki alanlarını ve bit maskesi kod çözümünü hesaplamak için Python'da UDF'yi kullanırız.
Herhangi bir yürütme ortamında (dev, test, prod) UDF oluşturan bir makro örneği:
{% 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'de PostgreSQL'i temel alan Amazon Redshift'i kullanıyoruz. Redshift için, tablolarla ilgili istatistikleri düzenli olarak toplamak ve disk alanını boşaltmak (sırasıyla ANALYZE ve VACUUM komutları) önemlidir.
Bunu yapmak için redshift_maintenance makrosundaki komutlar her gece yürütülür:
{% 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 Bulutu
DBT'yi bir hizmet (Yönetilen Hizmet) olarak kullanmak mümkündür. Dahil:
- Proje ve model geliştirmek için Web IDE
- İş yapılandırması ve zamanlaması
- Günlüklere basit ve rahat erişim
- Projenizin dokümantasyonunu içeren web sitesi
- CI'yı Bağlama (Sürekli Entegrasyon)
Sonuç
DWH hazırlamak ve tüketmek, smoothie içmek kadar keyifli ve faydalı hale geliyor. DBT, Jinja, kullanıcı uzantıları (modüller), bir derleyici, bir yürütücü ve bir paket yöneticisinden oluşur. Bu unsurları bir araya getirerek Veri Ambarınız için eksiksiz bir çalışma ortamı elde edersiniz. Bugün DWH'de dönüşümü yönetmenin daha iyi bir yolu yok.
DDT'yi geliştirenlerin takip ettiği inançlar şu şekilde formüle edilmiştir:
- Karmaşık analitik mantığı ifade etmek için GUI değil kod en iyi soyutlamadır
- Verilerle çalışmak, yazılım mühendisliğindeki en iyi uygulamaları uyarlamalıdır (Yazılım Mühendisliği)
- Kritik veri altyapısı açık kaynaklı yazılım olarak kullanıcı topluluğu tarafından kontrol edilmelidir.
- Yalnızca analiz araçları değil, kod da giderek Açık Kaynak topluluğunun malı haline gelecek
Bu temel inançlar bugün 850'den fazla şirket tarafından kullanılan bir ürünün ortaya çıkmasını sağladı ve gelecekte oluşturulacak birçok heyecan verici eklentinin temelini oluşturuyor.
İlgilenenler için birkaç ay önce OTUS'ta açık ders kapsamında verdiğim açık dersin videosu var - .
OTUS platformundaki Veri Mühendisliği kursunun bir parçası olarak DBT ve Veri Ambarı'na ek olarak meslektaşlarım ve ben bir dizi başka ilgili ve modern konu hakkında dersler veriyoruz:
- Büyük Veri Uygulamalarına Yönelik Mimari Konseptler
- Spark ve Spark Streaming ile pratik yapın
- Veri kaynaklarını yüklemeye yönelik yöntemleri ve araçları keşfetme
- DWH'de analitik vitrinler oluşturma
- NoSQL kavramları: HBase, Cassandra, ElasticSearch
- İzleme ve düzenleme ilkeleri
- Final Projesi: tüm becerilerin mentorluk desteği altında bir araya getirilmesi
Bağlantılar:
- — Resmi belgeler
- — DBT yazarlarından birinin makalesini inceleyin
- — YouTube, OTUS açık dersinin kaydedilmesi
- — Bir sonraki açık ders 15 Mayıs 2020
- —OTUS
- — Veri ve analitiğin geleceğine bir bakış
- — Analitiklerin evrimi ve Açık Kaynağın etkisi
- — DBT kullanarak CI oluşturmanın ilkeleri
- — Uygulama, Bağımsız çalışma için adım adım talimatlar
- — Github, eğitim projesi kodu
Kaynak: habr.com