რა პრინციპებზეა აგებული იდეალური მონაცემთა საწყობი?

ფოკუსირება ბიზნესის ღირებულებაზე და ანალიტიკაზე ქვაბის კოდის არარსებობის შემთხვევაში. DWH, როგორც კოდის ბაზის მართვა: ვერსიების დათვალიერება, ავტომატური ტესტირება და CI. მოდულური, გაფართოებადი, ღია წყარო და საზოგადოება. მომხმარებლისთვის მოსახერხებელი დოკუმენტაცია და დამოკიდებულების ვიზუალიზაცია (Data Lineage).

მეტი ამ ყველაფრის შესახებ და DBT-ის როლის შესახებ Big Data & Analytics ეკოსისტემაში - Welcome to cat.

გაუმარჯოს

არტემი კოზირი კავშირშია. 5 წელზე მეტია ვმუშაობ მონაცემთა საწყობებთან, ვაშენებ ETL/ELT, ასევე მონაცემთა ანალიტიკასა და ვიზუალიზაციას. ამჟამად ვმუშაობ ბორბლიანი, ვასწავლი OTUS-ში კურსზე მონაცემთა ინჟინერი, და დღეს მინდა გაგიზიაროთ სტატია, რომელიც დაწყების მოლოდინში დავწერე ახალი ჩარიცხვა კურსზე.

მოკლე შინაარსი

DBT ჩარჩო არის T-ის შესახებ ELT (Extract - Transform - Load) შემოკლებით.

ისეთი პროდუქტიული და მასშტაბური ანალიტიკური მონაცემთა ბაზების მოსვლასთან ერთად, როგორიცაა BigQuery, Redshift, Snowflake, აზრი არ ჰქონდა მონაცემთა საწყობის გარეთ ტრანსფორმაციების გაკეთებას. 

DBT არ ჩამოტვირთავს მონაცემებს წყაროებიდან, მაგრამ იძლევა დიდ შესაძლებლობებს იმ მონაცემებთან მუშაობისთვის, რომლებიც უკვე ჩატვირთულია საცავში (შიდა ან გარე საცავში).

DBT-ის მთავარი მიზანია კოდის აღება, მისი SQL-ში შედგენა, ბრძანებების შესრულება საცავში სწორი თანმიმდევრობით.

DBT პროექტის სტრუქტურა

პროექტი შედგება მხოლოდ 2 ტიპის დირექტორიებისა და ფაილებისგან:

• მოდელი (.sql) - ტრანსფორმაციის ერთეული, რომელიც გამოხატულია SELECT მოთხოვნით
• კონფიგურაციის ფაილი (.yml) - პარამეტრები, პარამეტრები, ტესტები, დოკუმენტაცია

საბაზისო დონეზე, სამუშაო სტრუქტურირებულია შემდეგნაირად:

• მომხმარებელი ამზადებს მოდელის კოდს ნებისმიერ მოსახერხებელ IDE-ში
• CLI-ის გამოყენებით, მოდელები გაშვებულია, DBT აგროვებს მოდელის კოდს SQL-ში
• შედგენილი SQL კოდი შესრულებულია Storage-ში მოცემული თანმიმდევრობით (გრაფიკი)

აი, როგორ შეიძლება გამოიყურებოდეს CLI-დან გაშვება:

ყველაფერი არის SELECT

ეს არის Data Build Tool ჩარჩოს მკვლელი ფუნქცია. სხვა სიტყვებით რომ ვთქვათ, DBT აბსტრაქტებს ყველა კოდს, რომელიც დაკავშირებულია თქვენი მოთხოვნების მაღაზიაში მატერიალიზაციასთან (ვარიაციები CREATE, INSERT, UPDATE, DELETE ALTER, GRANT, ...).

ნებისმიერი მოდელი გულისხმობს ერთი SELECT შეკითხვის დაწერას, რომელიც განსაზღვრავს მიღებულ მონაცემებს.

ამ შემთხვევაში, ტრანსფორმაციის ლოგიკა შეიძლება იყოს მრავალ დონის და გააერთიანოს მონაცემები რამდენიმე სხვა მოდელიდან. მოდელის მაგალითი, რომელიც ააშენებს შეკვეთის ვიტრინას (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

რა საინტერესო რამ შეიძლება ვნახოთ აქ?

პირველი: გამოიყენება CTE (Common Table Expressions) - კოდის ორგანიზებისა და გასაგებად, რომელიც შეიცავს უამრავ ტრანსფორმაციას და ბიზნეს ლოგიკას

მეორე: მოდელის კოდი არის SQL-ისა და ენის ნაზავი Jinja (თარგი ენა).

მაგალითი იყენებს მარყუჟს ამისთვის გამოსახულებაში მითითებული თითოეული გადახდის მეთოდისთვის თანხის გენერირება მითითებული. ფუნქცია ასევე გამოიყენება ref — კოდის ფარგლებში სხვა მოდელების მითითების შესაძლებლობა:

• შედგენის დროს ref გადაიქცევა სამიზნე მაჩვენებლად ცხრილზე ან ხედში Storage-ში
• ref საშუალებას გაძლევთ შექმნათ მოდელის დამოკიდებულების გრაფიკი

სწორედ Jinja თითქმის შეუზღუდავ შესაძლებლობებს ამატებს DBT-ს. ყველაზე ხშირად გამოყენებული არის:

• If / else განცხადებები - ფილიალის განცხადებები
• მარყუჟებისთვის - ციკლები
• ცვლადები
• მაკრო - მაკროების შექმნა

მატერიალიზაცია: ცხრილი, ხედი, ინკრემენტული

მატერიალიზაციის სტრატეგია არის მიდგომა, რომლის მიხედვითაც მოდელის მონაცემების შედეგად მიღებული ნაკრები ინახება Storage-ში.

ძირითადი თვალსაზრისით ეს არის:

• ცხრილი - ფიზიკური ცხრილი საცავში
• View - ხედი, ვირტუალური ცხრილი Storage-ში

ასევე არსებობს უფრო რთული მატერიალიზაციის სტრატეგიები:

• ინკრემენტული - დამატებითი დატვირთვა (დიდი ფაქტის ცხრილების); ემატება ახალი ხაზები, განახლებულია შეცვლილი ხაზები, წაშლილი ხაზები იწმინდება 
• ეფემერული - მოდელი არ ხდება უშუალოდ, მაგრამ მონაწილეობს როგორც CTE სხვა მოდელებში
• ნებისმიერი სხვა სტრატეგია შეგიძლიათ დაამატოთ საკუთარ თავს

მატერიალიზაციის სტრატეგიების გარდა, არსებობს კონკრეტული საცავის ოპტიმიზაციის შესაძლებლობები, მაგალითად:

• ფიფქია: გარდამავალი ცხრილები, შერწყმის ქცევა, ცხრილების დაჯგუფება, გრანტების კოპირება, უსაფრთხო ხედები
• Redshift: Distkey, Sortkey (გადახლართული, რთული), Late Binding Views
• bigquery: ცხრილების დაყოფა და დაჯგუფება, შერწყმის ქცევა, KMS დაშიფვრა, ლეიბლები და ტეგები
• ნაპერწკალი: ფაილის ფორმატი (parquet, csv, json, orc, delta), partition_by, clustered_by, buckets, incremental_strategy

ამჟამად მხარდაჭერილია შემდეგი საცავები:

• პოსტგრესი
• Redshift
• bigquery
• ფიფქია
• პრესტო (ნაწილობრივ)
• ნაპერწკალი (ნაწილობრივ)
• Microsoft SQL Server (საზოგადოების ადაპტერი)

მოდით გავაუმჯობესოთ ჩვენი მოდელი:

• მოდით გავხადოთ მისი შევსება ინკრემენტული (ინკრემენტული)
• მოდით დავამატოთ სეგმენტაციისა და დახარისხების კლავიშები Redshift-ისთვის

-- Конфигурация модели: 
-- Инкрементальное наполнение, уникальный ключ для обновления записей (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

მოდელის დამოკიდებულების გრაფიკი

ეს ასევე დამოკიდებულების ხეა. იგი ასევე ცნობილია როგორც DAG (მიმართული აციკლური გრაფიკი).

DBT აშენებს გრაფიკს ყველა პროექტის მოდელის კონფიგურაციის საფუძველზე, უფრო სწორად, ref() ბმულებს მოდელებში სხვა მოდელებთან. გრაფიკის არსებობა საშუალებას გაძლევთ გააკეთოთ შემდეგი:

• მოდელების გაშვება სწორი თანმიმდევრობით
• ვიტრინის ფორმირების პარალელიზება
• თვითნებური ქვეგრაფის გაშვება 

გრაფიკის ვიზუალიზაციის მაგალითი:

გრაფის თითოეული კვანძი არის მოდელი; გრაფის კიდეები მითითებულია გამოსახულებით ref.

მონაცემთა ხარისხი და დოკუმენტაცია

გარდა თავად მოდელების ფორმირებისა, DBT საშუალებას გაძლევთ შეამოწმოთ მთელი რიგი დაშვებები (განცხადებები) მიღებული მონაცემთა ნაკრების შესახებ, როგორიცაა:

• არა ნული
• უნიკალური
• მითითების მთლიანობა - რეფერენციალური მთლიანობა (მაგალითად, customer_id შეკვეთების ცხრილში შეესაბამება id-ს კლიენტების ცხრილში)
• მისაღები მნიშვნელობების ჩამონათვალის შესაბამისობა

შესაძლებელია საკუთარი ტესტების (მორგებული მონაცემთა ტესტების) დამატება, როგორიცაა, მაგალითად, შემოსავლის % გადახრა ინდიკატორებით ერთი დღის, ერთი კვირის, ერთი თვის წინ. ნებისმიერი დაშვება, რომელიც ჩამოყალიბებულია როგორც SQL შეკითხვა, შეიძლება გახდეს ტესტი.

ამ გზით, თქვენ შეგიძლიათ დაიჭიროთ არასასურველი გადახრები და შეცდომები საწყობის ფანჯრებში.

დოკუმენტაციის თვალსაზრისით, DBT უზრუნველყოფს მექანიზმებს მეტამონაცემების და კომენტარების დამატების, ვერსიების და გავრცელებისთვის მოდელის და თუნდაც ატრიბუტების დონეზე. 

აი, როგორ გამოიყურება ტესტებისა და დოკუმენტაციის დამატება კონფიგურაციის ფაილის დონეზე:

 - 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']

და აი, როგორ გამოიყურება ეს დოკუმენტაცია გენერირებულ ვებსაიტზე:

მაკროები და მოდულები

DBT-ის მიზანია არა იმდენად, რომ გახდეს SQL სკრიპტების ნაკრები, არამედ მიაწოდოს მომხმარებლებს მძლავრი და ფუნქციებით მდიდარი საშუალებები საკუთარი ტრანსფორმაციების შესაქმნელად და ამ მოდულების გავრცელებისთვის.

მაკროები არის კონსტრუქციებისა და გამონათქვამების ნაკრები, რომლებიც შეიძლება ეწოდოს ფუნქციებს მოდელებში. მაკრო საშუალებას გაძლევთ ხელახლა გამოიყენოთ SQL მოდელებსა და პროექტებს შორის DRY (Don't Repeat Yourself) საინჟინრო პრინციპის შესაბამისად.

მაკრო მაგალითი:

{% 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 %}

და მისი გამოყენება:

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

DBT-ს გააჩნია პაკეტის მენეჯერი, რომელიც მომხმარებლებს საშუალებას აძლევს გამოაქვეყნონ და ხელახლა გამოიყენონ ინდივიდუალური მოდულები და მაკროები.

ეს ნიშნავს ბიბლიოთეკების ჩატვირთვას და გამოყენებას, როგორიცაა:

• dbt_utils: მუშაობა თარიღთან/დროსთან, სუროგატ კლავიშებთან, სქემის ტესტებთან, Pivot/Unpivot და სხვა
• მზა ვიტრინის შაბლონები ისეთი სერვისებისთვის, როგორიცაა ფიფქია и ზოლიანი 
• ბიბლიოთეკები მონაცემთა კონკრეტული მაღაზიებისთვის, მაგ. Redshift 
• ხე — DBT ოპერაციების შესვლის მოდული

პაკეტების სრული სია შეგიძლიათ იხილოთ აქ dbt ჰაბი.

კიდევ უფრო მეტი ფუნქციები

აქ მე აღვწერ რამდენიმე სხვა საინტერესო მახასიათებელს და განხორციელებას, რომლებსაც მე და გუნდი ვიყენებთ მონაცემთა საწყობის ასაშენებლად. ბორბლიანი.

სამუშაო დროის გარემოს გამოყოფა DEV - TEST - PROD

თუნდაც ერთი და იგივე DWH კლასტერში (სხვადასხვა სქემებში). მაგალითად, შემდეგი გამონათქვამის გამოყენებით:

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 -%}
 
)

ეს კოდი სიტყვასიტყვით ამბობს: გარემოებისთვის dev, ტესტი, ci მიიღეთ მონაცემები მხოლოდ ბოლო 3 დღის განმავლობაში და არა მეტი. ანუ ამ გარემოში სირბილი გაცილებით სწრაფი იქნება და ნაკლებ რესურსს მოითხოვს. გარემოზე გაშვებისას პროდიდი ფილტრის მდგომარეობა იგნორირებული იქნება.

მატერიალიზაცია ალტერნატიული სვეტის კოდირებით

Redshift არის სვეტოვანი DBMS, რომელიც საშუალებას გაძლევთ დააყენოთ მონაცემთა შეკუმშვის ალგორითმები თითოეული ცალკეული სვეტისთვის. ოპტიმალური ალგორითმების არჩევისას შესაძლებელია დისკის ადგილის შემცირება 20-50%-ით.

მაკრო redshift.compress_table შეასრულებს ANALYZE COMPRESSION ბრძანებას, შექმნის ახალ ცხრილს რეკომენდირებული სვეტის კოდირების ალგორითმებით, მითითებული სეგმენტაციის კლავიშებით (dist_key) და დახარისხების კლავიშებით (sort_key), გადასცემს მას მონაცემებს და საჭიროების შემთხვევაში წაშლის ძველ ასლს.

მაკრო ხელმოწერა:

{{ 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) }}

ლოგის მოდელი გადის

თქვენ შეგიძლიათ მიამაგროთ კაკვები მოდელის თითოეულ შესრულებაზე, რომელიც შესრულდება გაშვებამდე ან მოდელის შექმნის დასრულებისთანავე:

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

ლოგის მოდული საშუალებას მოგცემთ ჩაწეროთ ყველა საჭირო მეტამონაცემები ცალკე ცხრილში, რომელიც შემდგომში შეიძლება გამოყენებულ იქნას შევიწროების აუდიტისა და ანალიზისთვის.

ასე გამოიყურება საინფორმაციო დაფა Looker-ში შესვლის მონაცემების საფუძველზე:

საცავის მოვლის ავტომატიზაცია

თუ იყენებთ გამოყენებული საცავის ფუნქციონალურობის ზოგიერთ გაფართოებას, როგორიცაა UDF (მომხმარებლის განსაზღვრული ფუნქციები), მაშინ ამ ფუნქციების ვერსიირება, წვდომის კონტროლი და ახალი გამოშვებების ავტომატიზირებული გაშვება ძალიან მოსახერხებელია DBT-ში.

ჩვენ ვიყენებთ UDF-ს პითონში ჰეშების, ელ.ფოსტის დომენების და ბიტმასკის დეკოდირების გამოსათვლელად.

მაკროს მაგალითი, რომელიც ქმნის UDF-ს ნებისმიერ აღსრულების გარემოზე (dev, test, prod):

{% 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-ში ჩვენ ვიყენებთ Amazon Redshift-ს, რომელიც დაფუძნებულია PostgreSQL-ზე. Redshift-ისთვის მნიშვნელოვანია რეგულარულად შეაგროვოთ სტატისტიკა ცხრილებზე და გაათავისუფლოთ დისკზე ადგილი - ANALYZE და VACUUM ბრძანებები, შესაბამისად.

ამისათვის ბრძანებები redshift_maintenance მაკროდან ყოველ ღამე სრულდება:

{% 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 ღრუბელი

შესაძლებელია DBT სერვისად გამოყენება (Managed Service). შედის:

• ვებ IDE პროექტებისა და მოდელების შემუშავებისთვის
• სამუშაოს კონფიგურაცია და დაგეგმვა
• მარტივი და მოსახერხებელი წვდომა ჟურნალებზე
• საიტი თქვენი პროექტის დოკუმენტაციით
• დაკავშირება CI (უწყვეტი ინტეგრაცია)

დასკვნა

DWH-ის მომზადება და მოხმარება ისეთივე სასიამოვნო და სასარგებლო ხდება, როგორც სმუზის დალევა. DBT შედგება Jinja, მომხმარებლის გაფართოებები (მოდულები), შემდგენელი, შემსრულებელი და პაკეტის მენეჯერი. ამ ელემენტების გაერთიანებით თქვენ მიიღებთ სრულ სამუშაო გარემოს თქვენი მონაცემთა საწყობისთვის. დღეს DWH-ში ტრანსფორმაციის მართვის უკეთესი გზა არ არსებობს.

რწმენა, რომელსაც მიჰყვებიან DBT-ის შემქმნელები, ჩამოყალიბებულია შემდეგნაირად:

• კოდი და არა GUI, არის საუკეთესო აბსტრაქცია რთული ანალიტიკური ლოგიკის გამოსახატავად
• მონაცემებთან მუშაობა უნდა მოერგოს საუკეთესო პრაქტიკას პროგრამული უზრუნველყოფის ინჟინერიაში (პროგრამული ინჟინერია)

• კრიტიკული მონაცემთა ინფრასტრუქტურა უნდა კონტროლდებოდეს მომხმარებელთა საზოგადოების მიერ, როგორც ღია კოდის პროგრამული უზრუნველყოფა
• არა მხოლოდ ანალიტიკური ხელსაწყოები, არამედ კოდიც სულ უფრო და უფრო გახდება ღია წყაროს საზოგადოების საკუთრება

ამ ძირითადმა რწმენამ წარმოშვა პროდუქტი, რომელსაც დღეს 850-ზე მეტი კომპანია იყენებს და ისინი ქმნიან ბევრ საინტერესო გაფართოების საფუძველს, რომელიც შეიქმნება მომავალში.

დაინტერესებულთათვის არის ღია გაკვეთილის ვიდეო, რომელიც ჩავატარე რამდენიმე თვის წინ OTUS-ში ღია გაკვეთილის ფარგლებში - მონაცემთა აშენების ინსტრუმენტი Amazon Redshift Storage-ისთვის.

გარდა DBT-ისა და Data Warehousing-ისა, როგორც Data Engineer კურსის ნაწილი OTUS პლატფორმაზე, მე და ჩემი კოლეგები ვასწავლით გაკვეთილებს სხვა რელევანტურ და თანამედროვე თემებზე:

• არქიტექტურული კონცეფციები დიდი მონაცემების აპლიკაციებისთვის
• ივარჯიშეთ Spark და Spark Streaming-ით
• მონაცემთა წყაროების ჩატვირთვის მეთოდებისა და ინსტრუმენტების შესწავლა
• ანალიტიკური ვიტრინების აგება DWH-ში
• NoSQL ცნებები: HBase, Cassandra, ElasticSearch
• მონიტორინგისა და ორკესტრირების პრინციპები 
• საბოლოო პროექტი: ყველა უნარ-ჩვევების გაერთიანება მენტორული მხარდაჭერის ქვეშ

ბმულები:

1. DBT დოკუმენტაცია - შესავალი - ოფიციალური დოკუმენტაცია
2. კონკრეტულად რა არის dbt? — გადახედეთ DBT-ის ერთ-ერთი ავტორის სტატიას 
3. მონაცემთა აშენების ინსტრუმენტი Amazon Redshift Storage-ისთვის — YouTube, OTUS ღია გაკვეთილის ჩაწერა
4. Greenplum-ის გაცნობა — შემდეგი ღია გაკვეთილი არის 15 წლის 2020 მაისი
5. მონაცემთა ინჟინერიის კურსი - OTUS
6. მომწიფებული ანალიტიკის სამუშაო ნაკადის შექმნა — გადახედეთ მონაცემთა და ანალიტიკის მომავალს
7. დროა ღია კოდის ანალიტიკისთვის — ანალიტიკის ევოლუცია და ღია წყაროს გავლენა
8. უწყვეტი ინტეგრაცია და ავტომატური Build ტესტირება dbtCloud-ით — CI-ის აგების პრინციპები DBT-ის გამოყენებით
9. DBT გაკვეთილის დაწყება — პრაქტიკა, ნაბიჯ-ნაბიჯ ინსტრუქციები დამოუკიდებელი მუშაობისთვის
10. Jaffle shop — Github DBT გაკვეთილი — Github, საგანმანათლებლო პროექტის კოდი

შეიტყვეთ მეტი კურსის შესახებ.

წყარო: www.habr.com