คลังข้อมูลในอุดมคติสร้างขึ้นบนหลักการใด
มุ่งเน้นไปที่มูลค่าทางธุรกิจและการวิเคราะห์โดยไม่ต้องมีโค้ดสำเร็จรูป การจัดการ DWH เป็นฐานโค้ด: การกำหนดเวอร์ชัน การตรวจสอบ การทดสอบอัตโนมัติ และ CI แบบโมดูลาร์ ขยายได้ โอเพ่นซอร์สและชุมชน เอกสารที่ใช้งานง่ายและการแสดงภาพการพึ่งพา (Data Lineage)
ข้อมูลเพิ่มเติมเกี่ยวกับทั้งหมดนี้และเกี่ยวกับบทบาทของ DBT ในระบบนิเวศ Big Data และ Analytics - ยินดีต้อนรับสู่ cat
สวัสดีทุกคน
ติดต่อ Artemy Kozyr ได้แล้ว เป็นเวลากว่า 5 ปีแล้วที่ฉันทำงานกับคลังข้อมูล การสร้าง ETL/ELT รวมถึงการวิเคราะห์ข้อมูลและการแสดงภาพ ขณะนี้ฉันกำลังทำงานใน , ฉันสอนหลักสูตรที่ OTUS และวันนี้ฉันอยากจะแบ่งปันบทความที่ฉันเขียนด้วยความหวังว่าจะเริ่มต้นกับคุณ การลงทะเบียนใหม่สำหรับหลักสูตร.
รีวิวสั้น ๆ
กรอบงาน DBT เป็นเรื่องเกี่ยวกับตัว T ในตัวย่อ ELT (แยก - แปลง - โหลด)
ด้วยการถือกำเนิดของฐานข้อมูลการวิเคราะห์ที่มีประสิทธิผลและปรับขนาดได้ เช่น BigQuery, Redshift, Snowflake จึงไม่มีประโยชน์ที่จะทำการเปลี่ยนแปลงภายนอกคลังข้อมูล
DBT ไม่ดาวน์โหลดข้อมูลจากแหล่งที่มา แต่ให้โอกาสที่ดีเยี่ยมในการทำงานกับข้อมูลที่โหลดลงในที่จัดเก็บข้อมูลแล้ว (ในที่จัดเก็บข้อมูลภายในหรือภายนอก)
วัตถุประสงค์หลักของ DBT คือการนำโค้ด คอมไพล์ลงใน SQL รันคำสั่งตามลำดับที่ถูกต้องใน Repository
โครงสร้างโครงการ DBT
โครงการประกอบด้วยไดเรกทอรีและไฟล์เพียง 2 ประเภท:
- โมเดล (.sql) - หน่วยของการแปลงที่แสดงโดยแบบสอบถาม SELECT
- ไฟล์การกำหนดค่า (.yml) - พารามิเตอร์ การตั้งค่า การทดสอบ เอกสารประกอบ
ในระดับพื้นฐานมีโครงสร้างงานดังนี้
- ผู้ใช้เตรียมรหัสรุ่นใน IDE ที่สะดวก
- เมื่อใช้ CLI โมเดลจะถูกเปิดตัว DBT จะรวบรวมโค้ดโมเดลลงใน SQL
- รหัส SQL ที่คอมไพล์แล้วจะถูกดำเนินการในที่เก็บข้อมูลตามลำดับที่กำหนด (กราฟ)
นี่คือลักษณะการทำงานจาก CLI:
ทุกอย่างถูกเลือก
นี่เป็นคุณลักษณะเด่นของเฟรมเวิร์กเครื่องมือสร้างข้อมูล กล่าวอีกนัยหนึ่ง DBT จะสรุปโค้ดทั้งหมดที่เกี่ยวข้องกับการทำให้การสืบค้นของคุณเป็นรูปธรรมลงใน Store (รูปแบบจากคำสั่ง 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 (นิพจน์ตารางทั่วไป) - เพื่อจัดระเบียบและทำความเข้าใจโค้ดที่มีการเปลี่ยนแปลงและตรรกะทางธุรกิจมากมาย
ประการที่สอง: รหัสโมเดลเป็นส่วนผสมของ SQL และภาษา (ภาษาเทมเพลต)
ตัวอย่างใช้การวนซ้ำ for เพื่อสร้างจำนวนเงินสำหรับวิธีการชำระเงินแต่ละวิธีที่ระบุในนิพจน์ ชุด. มีการใช้ฟังก์ชันนี้ด้วย อ้าง — ความสามารถในการอ้างอิงรุ่นอื่นภายในโค้ด:
- ระหว่างการรวบรวม อ้าง จะถูกแปลงเป็นตัวชี้เป้าหมายเป็นตารางหรือมุมมองในที่เก็บข้อมูล
- อ้าง ช่วยให้คุณสร้างกราฟการพึ่งพาแบบจำลอง
อย่างแน่นอน เพิ่มความเป็นไปได้เกือบไม่จำกัดให้กับ DBT สิ่งที่ใช้กันมากที่สุดคือ:
- คำสั่ง If / else - คำสั่งสาขา
- สำหรับลูป - รอบ
- ตัวแปร
- มาโคร - การสร้างมาโคร
การทำให้เป็นจริง: ตาราง, มุมมอง, ส่วนเพิ่ม
กลยุทธ์การทำให้เป็นรูปธรรมเป็นแนวทางที่ชุดข้อมูลแบบจำลองที่เป็นผลลัพธ์จะถูกจัดเก็บไว้ในที่เก็บข้อมูล
ในแง่พื้นฐานคือ:
- ตาราง - ตารางฟิสิคัลในที่เก็บข้อมูล
- ดู - ดูตารางเสมือนในที่เก็บข้อมูล
นอกจากนี้ยังมีกลยุทธ์การทำให้เป็นจริงที่ซับซ้อนมากขึ้น:
- ส่วนเพิ่ม - การโหลดส่วนเพิ่ม (ของตารางข้อเท็จจริงขนาดใหญ่) มีการเพิ่มบรรทัดใหม่ บรรทัดที่เปลี่ยนแปลงได้รับการอัปเดต บรรทัดที่ถูกลบจะถูกล้าง
- ชั่วคราว - โมเดลไม่ได้เกิดขึ้นจริงโดยตรง แต่มีส่วนร่วมในฐานะ CTE ในโมเดลอื่น
- กลยุทธ์อื่นๆ ที่คุณสามารถเพิ่มได้ด้วยตัวเอง
นอกเหนือจากกลยุทธ์การทำให้เป็นรูปธรรมแล้ว ยังมีโอกาสในการปรับให้เหมาะสมสำหรับพื้นที่จัดเก็บข้อมูลเฉพาะ เช่น:
- เกล็ดหิมะ: ตารางชั่วคราว, พฤติกรรมการผสาน, การจัดกลุ่มตาราง, การคัดลอกสิทธิ์, มุมมองที่ปลอดภัย
- redshift: Distkey, Sortkey (อินเทอร์ลีฟ, ประสม), Late Binding Views
- BigQuery: การแบ่งพาร์ติชันตารางและการจัดกลุ่ม, พฤติกรรมการผสาน, การเข้ารหัส KMS, ป้ายกำกับและแท็ก
- จุดประกาย: รูปแบบไฟล์ (parquet, csv, json, orc, delta), partition_by, clustered_by, buckets, incendingal_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 (Directed Acyclic Graph)
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 มาพร้อมกับตัวจัดการแพ็คเกจที่ช่วยให้ผู้ใช้สามารถเผยแพร่และนำแต่ละโมดูลและมาโครกลับมาใช้ใหม่ได้
ซึ่งหมายความว่าสามารถโหลดและใช้ไลบรารีเช่น:
- : การทำงานกับวันที่/เวลา, คีย์ตัวแทน, การทดสอบสคีมา, Pivot/Unpivot และอื่นๆ
- เทมเพลตตู้โชว์สำเร็จรูปสำหรับบริการต่างๆ เช่น и
- ไลบรารี่สำหรับพื้นที่เก็บข้อมูลเฉพาะ เช่น
- — โมดูลสำหรับบันทึกการทำงานของ 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%
แมโคร จะดำเนินการคำสั่ง 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) }}
โมเดลการบันทึกทำงาน
คุณสามารถแนบ hooks กับการดำเนินการแต่ละครั้งของโมเดลได้ ซึ่งจะดำเนินการก่อนการเปิดตัวหรือทันทีหลังจากการสร้างแบบจำลองเสร็จสมบูรณ์:
pre-hook: "{{ logging.log_model_start_event() }}"
post-hook: "{{ logging.log_model_end_event() }}"
โมดูลการบันทึกจะช่วยให้คุณสามารถบันทึกข้อมูลเมตาที่จำเป็นทั้งหมดในตารางแยกต่างหาก ซึ่งสามารถนำมาใช้เพื่อตรวจสอบและวิเคราะห์ปัญหาคอขวดในภายหลังได้
นี่คือลักษณะของแดชบอร์ดโดยอิงตามข้อมูลการบันทึกใน Looker:
ระบบอัตโนมัติของการบำรุงรักษาการจัดเก็บ
หากคุณใช้ส่วนขยายบางส่วนของฟังก์ชันการทำงานของ Repository ที่ใช้ เช่น UDF (ฟังก์ชันที่กำหนดโดยผู้ใช้) การกำหนดเวอร์ชันของฟังก์ชันเหล่านี้ การควบคุมการเข้าถึง และการเปิดตัวรีลีสใหม่โดยอัตโนมัติจะสะดวกมากใน DBT
เราใช้ UDF ใน Python เพื่อคำนวณแฮช โดเมนอีเมล และการถอดรหัสบิตมาสก์
ตัวอย่างของมาโครที่สร้าง 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 เป็นบริการได้ (Managed Service) รวมอยู่ด้วย:
- Web IDE สำหรับการพัฒนาโครงการและแบบจำลอง
- การกำหนดค่างานและการกำหนดเวลา
- การเข้าถึงบันทึกที่ง่ายและสะดวก
- เว็บไซต์พร้อมเอกสารประกอบโครงการของคุณ
- การเชื่อมต่อ CI (บูรณาการอย่างต่อเนื่อง)
ข้อสรุป
การเตรียมและการบริโภค DWH จะสนุกสนานและมีประโยชน์พอๆ กับการดื่มสมูทตี้ DBT ประกอบด้วย Jinja, ส่วนขยายผู้ใช้ (โมดูล), คอมไพเลอร์, ผู้ดำเนินการ และตัวจัดการแพ็คเกจ เมื่อรวมองค์ประกอบเหล่านี้เข้าด้วยกัน คุณจะได้รับสภาพแวดล้อมการทำงานที่สมบูรณ์สำหรับคลังข้อมูลของคุณ แทบจะไม่มีวิธีใดที่ดีกว่าในการจัดการการเปลี่ยนแปลงภายใน DWH ในปัจจุบัน
ความเชื่อที่นักพัฒนา DBT ปฏิบัติตามมีดังต่อไปนี้:
- โค้ด ไม่ใช่ GUI เป็นนามธรรมที่ดีที่สุดในการแสดงตรรกะการวิเคราะห์ที่ซับซ้อน
- การทำงานกับข้อมูลควรปรับแนวปฏิบัติที่ดีที่สุดในด้านวิศวกรรมซอฟต์แวร์ (Software Engineering)
- โครงสร้างพื้นฐานข้อมูลที่สำคัญควรได้รับการควบคุมโดยชุมชนผู้ใช้ในฐานะซอฟต์แวร์โอเพ่นซอร์ส
- ไม่เพียงแต่เครื่องมือวิเคราะห์เท่านั้น แต่โค้ดยังจะกลายเป็นสมบัติของชุมชนโอเพ่นซอร์สมากขึ้นอีกด้วย
ความเชื่อหลักเหล่านี้ได้ก่อให้เกิดผลิตภัณฑ์ที่บริษัทกว่า 850 แห่งใช้งานในปัจจุบัน และสร้างพื้นฐานของส่วนขยายที่น่าตื่นเต้นมากมายที่จะถูกสร้างขึ้นในอนาคต
สำหรับผู้ที่สนใจ มีวิดีโอบทเรียนแบบเปิดที่ฉันให้ไปเมื่อไม่กี่เดือนก่อนซึ่งเป็นส่วนหนึ่งของบทเรียนแบบเปิดที่ OTUS - .
นอกเหนือจาก DBT และคลังข้อมูล ซึ่งเป็นส่วนหนึ่งของหลักสูตรวิศวกรข้อมูลบนแพลตฟอร์ม OTUS ฉันและเพื่อนร่วมงานยังสอนชั้นเรียนในหัวข้ออื่นๆ ที่เกี่ยวข้องและทันสมัยอีกมากมาย:
- แนวคิดทางสถาปัตยกรรมสำหรับการใช้งานข้อมูลขนาดใหญ่
- ฝึกฝนด้วย Spark และ Spark Streaming
- สำรวจวิธีการและเครื่องมือสำหรับการโหลดแหล่งข้อมูล
- การสร้างการนำเสนอเชิงวิเคราะห์ใน DWH
- แนวคิด NoSQL: HBase, Cassandra, ElasticSearch
- หลักการเฝ้าติดตามและประสานงาน
- โครงการสุดท้าย: รวบรวมทักษะทั้งหมดไว้ด้วยกันภายใต้การสนับสนุนการให้คำปรึกษา
อ้างอิง:
- — เอกสารอย่างเป็นทางการ
- — ทบทวนบทความโดยหนึ่งในผู้เขียน DBT
- — YouTube บันทึกบทเรียนเปิด OTUS
- — บทเรียนเปิดครั้งต่อไปคือวันที่ 15 พฤษภาคม 2020
- —โอทัส
- — ดูอนาคตของข้อมูลและการวิเคราะห์
- — วิวัฒนาการของการวิเคราะห์และอิทธิพลของโอเพ่นซอร์ส
- — หลักการสร้าง CI โดยใช้ DBT
- — ฝึกฝน คำแนะนำทีละขั้นตอนสำหรับงานอิสระ
- — Github รหัสโครงการการศึกษา
ที่มา: will.com