การพัฒนาสถานที่จัดเก็บเป็นการดำเนินการที่ยาวนานและจริงจัง
ส่วนใหญ่ในชีวิตของโครงการขึ้นอยู่กับว่าโมเดลวัตถุและโครงสร้างพื้นฐานได้รับการพิจารณาตั้งแต่เริ่มต้นได้ดีเพียงใด
แนวทางที่เป็นที่ยอมรับโดยทั่วไปมีและยังคงมีหลากหลายรูปแบบในการรวมโครงร่างดาวเข้ากับรูปแบบปกติที่สาม ตามกฎแล้วตามหลักการ: ข้อมูลเริ่มต้น - 3NF, โชว์ผลงาน - ดาว แนวทางนี้ซึ่งผ่านการทดสอบตามเวลาและได้รับการสนับสนุนจากการวิจัยจำนวนมาก ถือเป็นสิ่งแรก (และบางครั้งก็เป็นเพียงสิ่งเดียว) ที่อยู่ในใจของผู้เชี่ยวชาญ DWH ที่มีประสบการณ์ เมื่อพิจารณาว่าพื้นที่เก็บข้อมูลเชิงวิเคราะห์ควรมีลักษณะอย่างไร
ในทางกลับกัน ความต้องการของธุรกิจโดยทั่วไปและลูกค้าโดยเฉพาะมีแนวโน้มที่จะเปลี่ยนแปลงอย่างรวดเร็ว และข้อมูลมีแนวโน้มที่จะเติบโตทั้ง "ในเชิงลึก" และ "ในเชิงกว้าง" และนี่คือจุดที่ข้อเสียเปรียบหลักของดาวปรากฏขึ้น - มีจำกัด มีความยืดหยุ่น.
และหากในชีวิตที่เงียบสงบและอบอุ่นของคุณในฐานะนักพัฒนา DWH จู่ๆ:
- งานเกิดขึ้น "อย่างน้อยก็ทำบางอย่างอย่างรวดเร็วแล้วเราจะได้เห็น";
- โครงการที่กำลังพัฒนาอย่างรวดเร็วปรากฏขึ้นพร้อมการเชื่อมโยงแหล่งข้อมูลใหม่และการปรับปรุงรูปแบบธุรกิจอย่างน้อยสัปดาห์ละครั้ง
- ลูกค้าปรากฏตัวโดยไม่รู้ว่าระบบควรมีลักษณะอย่างไรและควรใช้งานฟังก์ชันใดในท้ายที่สุด แต่พร้อมที่จะทดลองและปรับปรุงผลลัพธ์ที่ต้องการอย่างต่อเนื่องในขณะที่เข้าใกล้มันมากขึ้นเรื่อยๆ
- ผู้จัดการโครงการแวะมาพร้อมกับข่าวดี: “และตอนนี้เราก็มีความคล่องตัวแล้ว!”
หรือหากคุณเพียงสนใจที่จะค้นหาวิธีอื่นที่คุณสามารถสร้างพื้นที่เก็บของได้ ก็ยินดีเลย!
“ความยืดหยุ่น” หมายถึงอะไร?
ขั้นแรก เรามากำหนดคุณสมบัติที่ระบบต้องมีเพื่อที่จะเรียกว่า "ยืดหยุ่น"
แยกเป็นมูลค่าการกล่าวขวัญว่าคุณสมบัติที่อธิบายไว้ควรเกี่ยวข้องโดยเฉพาะ ระบบไม่ให้ กระบวนการ การพัฒนาของมัน ดังนั้น หากคุณต้องการอ่านเกี่ยวกับ Agile เพื่อเป็นแนวทางในการพัฒนา ควรอ่านบทความอื่นจะดีกว่า ตัวอย่างเช่น ตรงนั้น ที่Habré มีเนื้อหาที่น่าสนใจมากมาย (เช่น и และ ).
นี่ไม่ได้หมายความว่ากระบวนการพัฒนาและโครงสร้างของคลังข้อมูลจะไม่เกี่ยวข้องกันโดยสิ้นเชิง โดยรวมแล้ว การพัฒนาพื้นที่เก็บข้อมูลแบบ Agile สำหรับสถาปัตยกรรมแบบ Agile ควรจะง่ายกว่ามาก อย่างไรก็ตามในทางปฏิบัติมักมีตัวเลือกในการพัฒนา Agile ของ DWH แบบคลาสสิกตาม Kimbal และ DataVault - ตาม Waterfall มากกว่าความบังเอิญที่มีความสุขของความยืดหยุ่นในสองรูปแบบในหนึ่งโครงการ
ดังนั้นพื้นที่จัดเก็บข้อมูลแบบยืดหยุ่นควรมีความสามารถอะไรบ้าง? มีสามจุดที่นี่:
- การจัดส่งก่อนเวลาและการตอบสนองที่รวดเร็ว - นี่หมายความว่าตามหลักการแล้วควรได้รับผลลัพธ์ทางธุรกิจแรก (เช่น รายงานการทำงานฉบับแรก) โดยเร็วที่สุด นั่นคือ ก่อนที่ระบบทั้งหมดจะได้รับการออกแบบและใช้งานอย่างสมบูรณ์ด้วยซ้ำ นอกจากนี้ การแก้ไขครั้งต่อไปแต่ละครั้งควรใช้เวลาน้อยที่สุดเท่าที่จะทำได้
- การปรับแต่งซ้ำ - ซึ่งหมายความว่าการปรับปรุงครั้งต่อไปแต่ละครั้งไม่ควรส่งผลกระทบต่อฟังก์ชันการทำงานที่กำลังทำงานอยู่ ในขณะนี้เองที่มักจะกลายเป็นฝันร้ายที่ใหญ่ที่สุดในโครงการขนาดใหญ่ ไม่ช้าก็เร็ว แต่ละอ็อบเจ็กต์เริ่มได้รับการเชื่อมต่อมากมายจนเป็นการง่ายกว่าที่จะทำซ้ำลอจิกในสำเนาที่อยู่ใกล้ๆ แทนที่จะเพิ่มฟิลด์ลงในตารางที่มีอยู่ และหากคุณแปลกใจที่การวิเคราะห์ผลกระทบของการปรับปรุงต่อออบเจ็กต์ที่มีอยู่อาจใช้เวลานานกว่าการปรับปรุงเอง เป็นไปได้ว่าคุณยังไม่ได้ทำงานกับคลังข้อมูลขนาดใหญ่ในธนาคารหรือโทรคมนาคม
- ปรับตัวให้เข้ากับความต้องการทางธุรกิจที่เปลี่ยนแปลงตลอดเวลา - โครงสร้างวัตถุโดยรวมควรได้รับการออกแบบไม่เพียงแต่คำนึงถึงการขยายตัวที่เป็นไปได้ แต่ด้วยความคาดหวังว่าทิศทางของการขยายครั้งต่อไปนี้ไม่สามารถแม้แต่จะฝันถึงในขั้นตอนการออกแบบ
ใช่แล้ว การปฏิบัติตามข้อกำหนดทั้งหมดเหล่านี้ในระบบเดียวก็เป็นไปได้ (แน่นอน ในบางกรณีและอาจมีข้อจำกัดบางประการ)
ด้านล่างนี้ฉันจะพิจารณาวิธีการออกแบบ Agile ที่ได้รับความนิยมมากที่สุดสองวิธีสำหรับคลังข้อมูล - โมเดลสมอเรือ и คลังข้อมูล. เทคนิคที่ยอดเยี่ยมที่เหลืออยู่ในวงเล็บเช่น EAV, 6NF (ในรูปแบบบริสุทธิ์) และทุกสิ่งที่เกี่ยวข้องกับโซลูชัน NoSQL - ไม่ใช่เพราะมันแย่กว่านั้นและไม่ใช่เพราะในกรณีนี้บทความอาจขู่ว่าจะได้รับ ปริมาณของ dissers เฉลี่ย เพียงแต่ว่าทั้งหมดนี้เกี่ยวข้องกับโซลูชันของคลาสที่แตกต่างกันเล็กน้อย ไม่ว่าจะเป็นเทคนิคที่คุณสามารถใช้ได้ในบางกรณี โดยไม่คำนึงถึงสถาปัตยกรรมโดยรวมของโครงการของคุณ (เช่น EAV) หรือกับกระบวนทัศน์การจัดเก็บข้อมูลอื่น ๆ ทั่วโลก (เช่น ฐานข้อมูลกราฟ และตัวเลือกอื่นๆ NoSQL)
ปัญหาของแนวทาง "คลาสสิก" และแนวทางแก้ไขในวิธีการที่ยืดหยุ่น
ด้วยแนวทาง "คลาสสิก" ฉันหมายถึงดาราเก่าที่ดี (โดยไม่คำนึงถึงการใช้งานเฉพาะของเลเยอร์พื้นฐาน ผู้ติดตามของ Kimball, Inmon และ CDM ยกโทษให้ฉันด้วย)
1. จำนวนสมาชิกที่เข้มงวดของการเชื่อมต่อ
โมเดลนี้มีพื้นฐานจากการแบ่งข้อมูลที่ชัดเจน มิติ и ข้อเท็จจริง. และนี่เป็นสิ่งที่สมเหตุสมผล - ท้ายที่สุดแล้วการวิเคราะห์ข้อมูลในกรณีส่วนใหญ่อย่างล้นหลามนั้นขึ้นอยู่กับการวิเคราะห์ตัวบ่งชี้ตัวเลข (ข้อเท็จจริง) บางอย่างในบางส่วน (มิติข้อมูล)
ในกรณีนี้ การเชื่อมต่อระหว่างออบเจ็กต์จะถูกสร้างขึ้นในรูปแบบของความสัมพันธ์ระหว่างตารางโดยใช้คีย์นอก สิ่งนี้ดูค่อนข้างเป็นธรรมชาติ แต่นำไปสู่ข้อจำกัดประการแรกของความยืดหยุ่นในทันที - คำจำกัดความที่เข้มงวดของจำนวนสมาชิกของการเชื่อมต่อ.
ซึ่งหมายความว่าในขั้นตอนการออกแบบตาราง คุณต้องกำหนดอย่างแม่นยำสำหรับคู่ของออบเจ็กต์ที่เกี่ยวข้องกันแต่ละคู่ว่าสามารถเชื่อมโยงกันแบบกลุ่มต่อกลุ่ม หรือเพียง 1 ต่อกลุ่มเท่านั้น และ "ไปในทิศทางใด" นี่เป็นการกำหนดโดยตรงว่าตารางใดจะมีคีย์หลักและตารางใดจะมีคีย์ต่างประเทศ การเปลี่ยนทัศนคตินี้เมื่อได้รับข้อกำหนดใหม่มักจะนำไปสู่การปรับปรุงฐาน
ตัวอย่างเช่น เมื่อออกแบบวัตถุ "ใบเสร็จรับเงิน" คุณวางความเป็นไปได้ในการดำเนินการโดยอาศัยคำสาบานของฝ่ายขาย โปรโมชั่นเดียวเช็คได้หลายตำแหน่ง (แต่ไม่ใช่ในทางกลับกัน):
และหลังจากนั้นไม่นาน เพื่อนร่วมงานก็ได้แนะนำกลยุทธ์ทางการตลาดใหม่ซึ่งพวกเขาสามารถดำเนินการในตำแหน่งเดียวกันได้ โปรโมชั่นหลายรายการในเวลาเดียวกัน. และตอนนี้คุณจำเป็นต้องแก้ไขตารางโดยแยกความสัมพันธ์ออกเป็นออบเจ็กต์ที่แยกจากกัน
(ออบเจ็กต์ที่ได้รับทั้งหมดซึ่งรวมการตรวจสอบการส่งเสริมการขายจะต้องได้รับการปรับปรุงด้วย)
ความสัมพันธ์ใน Data Vault และ Anchor Model
การหลีกเลี่ยงสถานการณ์นี้กลายเป็นเรื่องง่าย: คุณไม่จำเป็นต้องไว้วางใจฝ่ายขายในการดำเนินการนี้ การเชื่อมต่อทั้งหมดจะถูกจัดเก็บไว้ในตารางแยกกันตั้งแต่แรก และประมวลผลแบบกลุ่มต่อกลุ่ม
ได้มีการเสนอแนวทางนี้ แดน ลินสเตดท์ ซึ่งเป็นส่วนหนึ่งของกระบวนทัศน์ คลังข้อมูล และได้รับการสนับสนุนอย่างเต็มที่ ลาร์ส เรินน์เบค в โมเดลสมอเรือ.
ด้วยเหตุนี้ เราจึงได้รับคุณลักษณะที่โดดเด่นประการแรกของวิธีการที่ยืดหยุ่น:
ความสัมพันธ์ระหว่างออบเจ็กต์ไม่ได้จัดเก็บไว้ในแอตทริบิวต์ของเอนทิตีหลัก แต่เป็นออบเจ็กต์ประเภทที่แยกจากกัน
В คลังข้อมูล ตารางการเชื่อมโยงดังกล่าวเรียกว่า ลิงค์และใน โมเดลสมอเรือ - เน็คไท. เมื่อมองแวบแรกพวกมันจะคล้ายกันมากแม้ว่าความแตกต่างจะไม่ได้ลงท้ายด้วยชื่อ (ซึ่งจะกล่าวถึงด้านล่าง) ในสถาปัตยกรรมทั้งสอง ตารางลิงก์สามารถลิงก์ได้ จำนวนเอนทิตีเท่าใดก็ได้ (ไม่จำเป็นต้อง 2)
ความซ้ำซ้อนนี้ให้ความยืดหยุ่นอย่างมากในการปรับเปลี่ยนเมื่อมองแวบแรก โครงสร้างดังกล่าวจะทนทานไม่เพียง แต่ต่อการเปลี่ยนแปลงจำนวนสมาชิกของลิงค์ที่มีอยู่เท่านั้น แต่ยังรวมไปถึงการเพิ่มลิงค์ใหม่ด้วย - หากตอนนี้ตำแหน่งเช็คมีลิงค์ไปยังแคชเชียร์ที่เจาะเข้าไปด้วยการปรากฏตัวของลิงค์ดังกล่าวก็จะง่ายขึ้น กลายเป็นส่วนเสริมเหนือตารางที่มีอยู่โดยไม่กระทบต่อออบเจ็กต์และกระบวนการที่มีอยู่
2. การทำสำเนาข้อมูล
ปัญหาที่สองที่แก้ไขได้ด้วยสถาปัตยกรรมที่ยืดหยุ่นนั้นไม่ค่อยชัดเจนและมีอยู่ตั้งแต่แรก การวัดประเภท SCD2 (ขนาดประเภทที่สองเปลี่ยนแปลงอย่างช้าๆ) แม้ว่าจะไม่เพียงเท่านั้นก็ตาม
ในคลังสินค้าแบบคลาสสิก โดยทั่วไปมิติจะเป็นตารางที่มีคีย์ตัวแทน (เป็น PK) และชุดของคีย์ธุรกิจและคุณลักษณะในคอลัมน์ที่แยกจากกัน
หากมิติสนับสนุนการกำหนดเวอร์ชัน ขอบเขตความถูกต้องของเวอร์ชันจะถูกเพิ่มให้กับชุดฟิลด์มาตรฐาน และหลายเวอร์ชันจะปรากฏในที่เก็บสำหรับหนึ่งแถวในแหล่งที่มา (หนึ่งเวอร์ชันสำหรับการเปลี่ยนแปลงแต่ละรายการในแอตทริบิวต์เวอร์ชัน)
หากมิติข้อมูลมีแอตทริบิวต์เวอร์ชันที่เปลี่ยนแปลงบ่อยอย่างน้อยหนึ่งรายการ จำนวนเวอร์ชันของมิติดังกล่าวจะน่าประทับใจ (แม้ว่าแอตทริบิวต์ที่เหลือจะไม่ได้กำหนดเวอร์ชันหรือไม่เคยเปลี่ยนแปลงก็ตาม) และหากมีแอตทริบิวต์ดังกล่าวหลายรายการ จำนวนเวอร์ชันสามารถ เติบโตแบบทวีคูณจากจำนวนของพวกเขา มิติข้อมูลนี้อาจใช้พื้นที่ดิสก์จำนวนมาก แม้ว่าข้อมูลส่วนใหญ่ที่เก็บไว้จะซ้ำกับค่าแอตทริบิวต์ที่ไม่เปลี่ยนรูปจากแถวอื่นก็ตาม
ในขณะเดียวกันก็มีการใช้บ่อยมากเช่นกัน การทำให้เป็นปกติ — คุณลักษณะบางอย่างถูกจัดเก็บไว้เป็นค่าโดยเจตนา และไม่ใช่ลิงก์ไปยังหนังสืออ้างอิงหรือมิติอื่น วิธีการนี้ช่วยเพิ่มความเร็วในการเข้าถึงข้อมูล โดยลดจำนวนการรวมเมื่อเข้าถึงมิติข้อมูล
โดยปกติแล้วสิ่งนี้จะนำไปสู่ ข้อมูลเดียวกันจะถูกจัดเก็บพร้อมกันในหลายแห่ง. ตัวอย่างเช่น ข้อมูลเกี่ยวกับภูมิภาคที่พำนักและหมวดหมู่ของลูกค้าสามารถจัดเก็บพร้อมกันในมิติข้อมูล "ลูกค้า" และข้อเท็จจริง "การซื้อ" "การจัดส่ง" และ "การโทรผ่านศูนย์บริการทางโทรศัพท์" รวมถึงในข้อเท็จจริง "ลูกค้า - ผู้จัดการลูกค้า ” ตารางลิงค์
โดยทั่วไป สิ่งที่อธิบายไว้ข้างต้นใช้กับมิติข้อมูลปกติ (ไม่มีเวอร์ชัน) แต่ในเวอร์ชันที่มีเวอร์ชันอาจมีขนาดที่แตกต่างกัน: การปรากฏของเวอร์ชันใหม่ของออบเจ็กต์ (โดยเฉพาะในการหวนกลับ) ไม่เพียงแต่นำไปสู่การอัปเดตที่เกี่ยวข้องทั้งหมด ตาราง แต่สำหรับลักษณะที่ปรากฏแบบเรียงซ้อนของวัตถุที่เกี่ยวข้องเวอร์ชันใหม่ - เมื่อใช้ตารางที่ 1 เพื่อสร้างตารางที่ 2 และใช้ตารางที่ 2 เพื่อสร้างตารางที่ 3 เป็นต้น แม้ว่าจะไม่มีคุณลักษณะใดของตารางที่ 1 ที่เกี่ยวข้องกับการสร้างตารางที่ 3 (และคุณลักษณะอื่นๆ ของตารางที่ 2 ที่ได้รับจากแหล่งอื่นที่เกี่ยวข้อง) การกำหนดเวอร์ชันการก่อสร้างนี้อย่างน้อยที่สุดจะนำไปสู่ค่าใช้จ่ายเพิ่มเติม และที่สูงสุดถึงพิเศษ เวอร์ชันต่างๆ ในตารางที่ 3 ซึ่งไม่มีส่วนเกี่ยวข้องใดๆ เลย และยิ่งไปกว่านั้นในห่วงโซ่
3. ความซับซ้อนแบบไม่เชิงเส้นของการทำงานซ้ำ
ในขณะเดียวกัน หน้าร้านใหม่แต่ละร้านที่สร้างขึ้นบนพื้นฐานของอีกร้านหนึ่งจะเพิ่มจำนวนสถานที่ที่ข้อมูลสามารถ "แยกออก" เมื่อมีการเปลี่ยนแปลงกับ ETL สิ่งนี้จะนำไปสู่ความซับซ้อน (และระยะเวลา) ที่เพิ่มขึ้นของการแก้ไขครั้งต่อไปแต่ละครั้ง
หากข้างต้นอธิบายระบบที่มีกระบวนการ ETL ที่ไม่ค่อยมีการแก้ไข คุณสามารถดำเนินชีวิตตามกระบวนทัศน์ดังกล่าวได้ คุณเพียงแค่ต้องแน่ใจว่ามีการแก้ไขใหม่กับวัตถุที่เกี่ยวข้องทั้งหมดอย่างถูกต้อง หากการแก้ไขเกิดขึ้นบ่อยครั้ง โอกาสที่การเชื่อมต่อหลายรายการจะ "หายไป" โดยไม่ตั้งใจจะเพิ่มขึ้นอย่างมาก
นอกจากนี้ หากเราคำนึงว่า ETL แบบ "มีเวอร์ชัน" นั้นซับซ้อนกว่า ETL แบบ "ไม่มีเวอร์ชัน" อย่างมาก จะค่อนข้างยากที่จะหลีกเลี่ยงข้อผิดพลาดเมื่ออัปเดตสิ่งอำนวยความสะดวกทั้งหมดนี้บ่อยครั้ง
การจัดเก็บออบเจ็กต์และคุณลักษณะใน Data Vault และ Anchor Model
แนวทางที่เสนอโดยผู้เขียนสถาปัตยกรรมแบบยืดหยุ่นสามารถกำหนดได้ดังนี้:
จำเป็นต้องแยกสิ่งที่เปลี่ยนแปลงออกจากสิ่งที่ยังคงเหมือนเดิม นั่นคือจัดเก็บคีย์แยกจากคุณลักษณะ
อย่างไรก็ตามก็ไม่ควรสับสน ไม่มีเวอร์ชัน คุณลักษณะด้วย ไม่เปลี่ยนแปลง: อันแรกจะไม่เก็บประวัติการเปลี่ยนแปลง แต่สามารถเปลี่ยนแปลงได้ (เช่น เมื่อแก้ไขข้อผิดพลาดอินพุตหรือรับข้อมูลใหม่) อันที่สองไม่เคยเปลี่ยนแปลง
มุมมองจะแตกต่างกันไปตามสิ่งที่ถือได้ว่าไม่เปลี่ยนรูปใน Data Vault และ Anchor Model
จากมุมมองทางสถาปัตยกรรม คลังข้อมูลถือว่าไม่มีการเปลี่ยนแปลง กุญแจทั้งชุด - ธรรมชาติ (TIN ขององค์กร รหัสผลิตภัณฑ์ในระบบต้นทาง ฯลฯ) และตัวแทน ในกรณีนี้ คุณลักษณะที่เหลือสามารถแบ่งออกเป็นกลุ่มตามแหล่งที่มาและ/หรือความถี่ของการเปลี่ยนแปลงและ จัดโต๊ะแยกกันแต่ละกลุ่ม ด้วยชุดเวอร์ชันที่เป็นอิสระ
ในกระบวนทัศน์ โมเดลสมอเรือ ถือว่าไม่เปลี่ยนแปลง กุญแจตัวแทนเท่านั้น แก่นแท้. อย่างอื่นทั้งหมด (รวมถึงคีย์ธรรมชาติ) เป็นเพียงกรณีพิเศษของคุณลักษณะของมัน โดยที่ คุณลักษณะทั้งหมดเป็นอิสระจากกันตามค่าเริ่มต้นดังนั้นสำหรับแต่ละแอตทริบิวต์ a โต๊ะแยก.
В คลังข้อมูล ตารางที่มีคีย์เอนทิตีจะถูกเรียก ฮูบามิ. ฮับจะมีชุดฟิลด์คงที่เสมอ:
- คีย์เอนทิตีธรรมชาติ
- กุญแจตัวแทน
- เชื่อมโยงไปยังแหล่งที่มา
- บันทึกการเพิ่มเวลา
โพสต์ในฮับ ไม่เคยเปลี่ยนแปลงและไม่มีเวอร์ชัน. ภายนอก ฮับจะคล้ายกับตารางประเภทแผนที่ ID ที่ใช้ในบางระบบเพื่อสร้างตัวแทน อย่างไรก็ตาม ขอแนะนำให้ใช้แฮชจากชุดคีย์ธุรกิจเป็นตัวแทนใน Data Vault วิธีการนี้ช่วยลดความยุ่งยากในการโหลดความสัมพันธ์และคุณลักษณะจากแหล่งที่มา (ไม่จำเป็นต้องเข้าร่วมฮับเพื่อรับตัวแทน เพียงคำนวณแฮชของคีย์ธรรมชาติ) แต่อาจทำให้เกิดปัญหาอื่นๆ (ที่เกี่ยวข้อง เช่น การชนกัน ตัวพิมพ์เล็กและพิมพ์ไม่ได้ อักขระในคีย์สตริง ฯลฯ .p.) จึงไม่เป็นที่ยอมรับโดยทั่วไป
คุณลักษณะเอนทิตีอื่น ๆ ทั้งหมดจะถูกเก็บไว้ในตารางพิเศษที่เรียกว่า ดาวเทียม. ฮับเดียวสามารถมีดาวเทียมหลายดวงที่จัดเก็บชุดคุณลักษณะที่แตกต่างกัน
การกระจายคุณลักษณะระหว่างดาวเทียมเกิดขึ้นตามหลักการ การเปลี่ยนแปลงร่วมกัน — ในแอตทริบิวต์ที่ไม่ใช่เวอร์ชันดาวเทียมหนึ่งสามารถจัดเก็บได้ (เช่นวันเกิดและ SNILS สำหรับแต่ละบุคคล) ในอีกอันหนึ่ง - ไม่ค่อยเปลี่ยนเวอร์ชัน (เช่นนามสกุลและหมายเลขหนังสือเดินทาง) ในอันที่สาม - การเปลี่ยนแปลงบ่อย (เช่น ที่อยู่สำหรับจัดส่ง หมวดหมู่ วันที่สั่งซื้อครั้งล่าสุด เป็นต้น) ในกรณีนี้ การกำหนดเวอร์ชันจะดำเนินการที่ระดับของดาวเทียมแต่ละดวง ไม่ใช่เอนทิตีโดยรวม ดังนั้นจึงแนะนำให้กระจายคุณลักษณะเพื่อให้จุดตัดของเวอร์ชันภายในดาวเทียมดวงเดียวน้อยที่สุด (ซึ่งจะลดจำนวนเวอร์ชันที่เก็บไว้ทั้งหมด ).
นอกจากนี้ เพื่อเพิ่มประสิทธิภาพกระบวนการโหลดข้อมูล คุณลักษณะที่ได้รับจากแหล่งต่างๆ มักจะรวมอยู่ในดาวเทียมแต่ละดวง
ดาวเทียมสื่อสารกับฮับผ่าน คีย์ต่างประเทศ (ซึ่งสอดคล้องกับจำนวนสมาชิก 1 ต่อกลุ่ม) ซึ่งหมายความว่าค่าแอตทริบิวต์หลายค่า (เช่น หมายเลขโทรศัพท์ติดต่อหลายหมายเลขสำหรับลูกค้ารายเดียว) ได้รับการสนับสนุนโดยสถาปัตยกรรม "ค่าเริ่มต้น" นี้
В โมเดลสมอเรือ ตารางที่เก็บคีย์เรียกว่า จุดยึด. และพวกเขาเก็บ:
- กุญแจตัวแทนเท่านั้น
- เชื่อมโยงไปยังแหล่งที่มา
- บันทึกการเพิ่มเวลา
พิจารณาคีย์ธรรมชาติจากมุมมองของ Anchor Model คุณสมบัติสามัญ. ตัวเลือกนี้อาจดูเหมือนเข้าใจยากกว่า แต่ให้ขอบเขตในการระบุวัตถุมากกว่ามาก
ตัวอย่างเช่น หากข้อมูลเกี่ยวกับเอนทิตีเดียวกันอาจมาจากระบบที่แตกต่างกัน ซึ่งแต่ละระบบใช้คีย์ธรรมชาติของตัวเอง ใน Data Vault สิ่งนี้สามารถนำไปสู่โครงสร้างที่ค่อนข้างยุ่งยากของฮับหลาย ๆ ตัว (หนึ่งตัวต่อแหล่งที่มา + เวอร์ชันหลักที่รวมเข้าด้วยกัน) ในขณะที่ในรุ่น Anchor คีย์ธรรมชาติของแต่ละแหล่งที่มาจะตกอยู่ในคุณลักษณะของตัวเอง และสามารถใช้เมื่อโหลดโดยแยกจากกัน คนอื่นๆ ทั้งหมด
แต่ก็มีจุดร้ายกาจประการหนึ่งที่นี่: หากคุณลักษณะจากระบบที่แตกต่างกันถูกรวมไว้ในเอนทิตีเดียว ก็มีแนวโน้มว่าจะมีบางส่วน กฎของการ "ติดกาว"โดยที่ระบบจะต้องเข้าใจว่าบันทึกจากแหล่งที่แตกต่างกันสอดคล้องกับอินสแตนซ์หนึ่งของเอนทิตี
В คลังข้อมูล กฎเหล่านี้มักจะเป็นตัวกำหนดรูปแบบ “ศูนย์กลางตัวแทน” ของเอนทิตีหลัก และไม่มีอิทธิพลต่อฮับที่เก็บคีย์แหล่งที่มาตามธรรมชาติและคุณลักษณะดั้งเดิมในทางใดทางหนึ่ง หาก ณ จุดใดจุดหนึ่งมีการเปลี่ยนแปลงกฎการรวม (หรือแอตทริบิวต์ที่ใช้ดำเนินการได้รับการอัปเดต) ก็จะเพียงพอที่จะฟอร์แมตฮับตัวแทนใหม่
В โมเดลสมอเรือ เอนทิตีดังกล่าวมักจะถูกจัดเก็บไว้ สมอเรือเท่านั้น. ซึ่งหมายความว่าคุณลักษณะทั้งหมดไม่ว่าจะมาจากแหล่งใดก็ตาม จะถูกผูกไว้กับตัวแทนคนเดียวกัน การแยกบันทึกที่ผสานอย่างผิดพลาด และโดยทั่วไป การตรวจสอบความเกี่ยวข้องของการรวมในระบบดังกล่าวอาจทำได้ยากขึ้นมาก โดยเฉพาะอย่างยิ่งหากกฎค่อนข้างซับซ้อนและเปลี่ยนแปลงบ่อยครั้ง และคุณลักษณะเดียวกันสามารถได้รับจากแหล่งที่ต่างกัน (แม้ว่าจะแน่นอนก็ตาม เป็นไปได้ เนื่องจากแต่ละเวอร์ชันของแอ็ตทริบิวต์ยังคงมีลิงก์ไปยังแหล่งที่มา)
ไม่ว่าในกรณีใด หากระบบของคุณควรจะใช้งานฟังก์ชันดังกล่าว การขจัดข้อมูลซ้ำซ้อน การรวมบันทึก และองค์ประกอบ MDM อื่นๆควรให้ความสนใจเป็นพิเศษกับแง่มุมต่างๆ ของการจัดเก็บคีย์ธรรมชาติด้วยวิธีการที่คล่องตัว มีแนวโน้มว่าการออกแบบ Data Vault ที่เทอะทะจะปลอดภัยกว่าในแง่ของข้อผิดพลาดในการผสาน
โมเดลสมอเรือ ยังมีประเภทวัตถุเพิ่มเติมที่เรียกว่า ปม โดยพื้นฐานแล้วมันเป็นเรื่องพิเศษ สมอประเภทเสื่อมซึ่งสามารถมีได้เพียงแอตทริบิวต์เดียวเท่านั้น โหนดควรจะใช้เพื่อจัดเก็บไดเร็กทอรีแบบแฟลต (เช่น เพศ สถานภาพการสมรส หมวดหมู่การบริการลูกค้า ฯลฯ) ต่างจาก Anchor, Knot ไม่มีตารางแอตทริบิวต์ที่เกี่ยวข้องและแอตทริบิวต์ (ชื่อ) เท่านั้นจะถูกเก็บไว้ในตารางเดียวกันกับคีย์เสมอ โหนดเชื่อมต่อกับ Anchors โดยผูกตาราง (Tie) ในลักษณะเดียวกับ Anchors ที่เชื่อมต่อถึงกัน
ไม่มีความคิดเห็นที่ชัดเจนเกี่ยวกับการใช้โหนด ตัวอย่างเช่น, ซึ่งส่งเสริมการใช้ Anchor Model ในรัสเซียอย่างแข็งขัน เชื่อ (โดยไม่มีเหตุผล) ว่าไม่ใช่หนังสืออ้างอิงเล่มเดียวที่สามารถระบุได้อย่างมั่นใจว่า เสมอ จะเป็นแบบคงที่และเป็นระดับเดียว ดังนั้นจึงเป็นการดีกว่าถ้าใช้ Anchor เต็มรูปแบบสำหรับวัตถุทั้งหมดทันที
ข้อแตกต่างที่สำคัญอีกประการระหว่าง Data Vault และโมเดล Anchor ก็คือความพร้อมใช้งาน คุณสมบัติของการเชื่อมต่อ:
В คลังข้อมูล ลิงก์เป็นวัตถุที่มีคุณสมบัติครบถ้วนเหมือนกับฮับและสามารถมีได้ คุณลักษณะของตัวเอง. ใน โมเดลสมอเรือ ลิงค์ใช้เพื่อเชื่อมต่อจุดยึดและ ไม่สามารถมีคุณสมบัติเป็นของตัวเองได้. ความแตกต่างนี้ส่งผลให้แนวทางการสร้างแบบจำลองแตกต่างกันอย่างมาก ข้อเท็จจริงซึ่งจะกล่าวถึงต่อไป
การจัดเก็บข้อเท็จจริง
ก่อนหน้านี้ เราได้พูดคุยเกี่ยวกับการสร้างแบบจำลองการวัดเป็นหลัก ข้อเท็จจริงมีความชัดเจนน้อยลงเล็กน้อย
В คลังข้อมูล วัตถุทั่วไปสำหรับการจัดเก็บข้อเท็จจริงคือ ลิงค์ซึ่งมีการเพิ่มตัวบ่งชี้ที่แท้จริงของดาวเทียม
แนวทางนี้ดูเป็นธรรมชาติ ช่วยให้เข้าถึงตัวบ่งชี้ที่วิเคราะห์ได้ง่าย และโดยทั่วไปจะคล้ายกับตารางข้อเท็จจริงแบบดั้งเดิม (เฉพาะตัวบ่งชี้เท่านั้นที่ไม่ถูกจัดเก็บไว้ในตาราง แต่อยู่ในตาราง "ใกล้เคียง") แต่ก็มีข้อผิดพลาดเช่นกัน: หนึ่งในการปรับเปลี่ยนทั่วไปของแบบจำลอง - การขยายคีย์ข้อเท็จจริง - จำเป็น เพิ่มคีย์ต่างประเทศใหม่ให้กับลิงก์. และในทางกลับกัน สิ่งนี้จะ "ทำลาย" ความเป็นโมดูลาร์ และอาจเป็นสาเหตุให้เกิดความจำเป็นในการปรับเปลี่ยนวัตถุอื่น ๆ
В โมเดลสมอเรือ การเชื่อมต่อไม่สามารถมีแอตทริบิวต์ของตัวเองได้ ดังนั้นวิธีการนี้จึงใช้ไม่ได้ - คุณลักษณะและตัวบ่งชี้ทั้งหมดจะต้องเชื่อมโยงกับจุดยึดเฉพาะจุดเดียว ข้อสรุปจากสิ่งนี้ง่าย ๆ - ข้อเท็จจริงแต่ละข้อยังต้องมีจุดยึดของตัวเองด้วย. สำหรับสิ่งที่เราคุ้นเคยกับการรับรู้ว่าเป็นข้อเท็จจริง สิ่งนี้อาจดูเป็นธรรมชาติ - ตัวอย่างเช่น ข้อเท็จจริงของการซื้อสามารถลดลงเหลือแค่ "คำสั่งซื้อ" หรือ "ใบเสร็จรับเงิน" ได้อย่างสมบูรณ์แบบ การเยี่ยมชมไซต์เพื่อเซสชัน ฯลฯ แต่ก็มีข้อเท็จจริงที่ไม่ง่ายนักที่จะค้นหา "วัตถุขนส่ง" ตามธรรมชาติเช่นสินค้าที่เหลืออยู่ในโกดังตอนต้นของแต่ละวัน
ดังนั้นปัญหาเกี่ยวกับความเป็นโมดูลเมื่อขยายคีย์ข้อเท็จจริงในโมเดล Anchor จะไม่เกิดขึ้น (เพียงเพิ่มความสัมพันธ์ใหม่ให้กับ Anchor ที่เกี่ยวข้องก็เพียงพอแล้ว) แต่การออกแบบแบบจำลองเพื่อแสดงข้อเท็จจริงนั้นไม่คลุมเครือน้อยกว่า จุดยึด "เทียม" อาจปรากฏขึ้น ที่แสดงโมเดลออบเจ็กต์ทางธุรกิจในลักษณะที่ไม่ชัดเจน
ความยืดหยุ่นเกิดขึ้นได้อย่างไร
ผลการก่อสร้างทั้งสองกรณีประกอบด้วย ตารางมากขึ้นอย่างเห็นได้ชัดกว่าการวัดแบบเดิมๆ แต่อาจจะต้องใช้เวลา พื้นที่ดิสก์น้อยลงอย่างมาก ด้วยชุดแอตทริบิวต์ที่มีเวอร์ชันเดียวกันกับมิติข้อมูลดั้งเดิม โดยธรรมชาติแล้วไม่มีเวทย์มนตร์ที่นี่ - มันเป็นเรื่องของการทำให้เป็นมาตรฐาน ด้วยการกระจายคุณลักษณะไปยังดาวเทียม (ใน Data Vault) หรือแต่ละตาราง (โมเดล Anchor) เราจะลด (หรือกำจัดทั้งหมด) การทำซ้ำค่าของคุณลักษณะบางอย่างเมื่อเปลี่ยนแปลงคุณสมบัติอื่น.
สำหรับ คลังข้อมูล การชนะจะขึ้นอยู่กับการกระจายคุณลักษณะระหว่างดาวเทียมและสำหรับ โมเดลสมอเรือ — เกือบจะเป็นสัดส่วนโดยตรงกับจำนวนเวอร์ชันเฉลี่ยต่อวัตถุการวัด
อย่างไรก็ตาม การประหยัดพื้นที่ถือเป็นข้อได้เปรียบที่สำคัญ แต่ไม่ใช่ข้อดีหลักในการจัดเก็บแอตทริบิวต์แยกกัน เมื่อรวมกับการจัดเก็บความสัมพันธ์ที่แยกจากกัน แนวทางนี้จะทำให้ร้านค้า การออกแบบโมดูลาร์. ซึ่งหมายความว่าการเพิ่มทั้งคุณลักษณะเฉพาะบุคคลและหัวเรื่องใหม่ทั้งหมดในโมเดลดังกล่าวมีลักษณะเช่นนี้ คอนเทนเนอร์ เหนือชุดวัตถุที่มีอยู่โดยไม่ต้องเปลี่ยนแปลง และนี่คือสิ่งที่ทำให้วิธีการที่อธิบายไว้มีความยืดหยุ่น
สิ่งนี้ยังคล้ายกับการเปลี่ยนจากการผลิตเป็นชิ้นเป็นการผลิตจำนวนมาก - หากในแนวทางดั้งเดิม แต่ละตารางของแบบจำลองมีเอกลักษณ์เฉพาะตัวและต้องการการดูแลเป็นพิเศษ ดังนั้นในวิธีการที่ยืดหยุ่น ตารางของแบบจำลองแต่ละอันก็จะกลายเป็นชุดของ "ชิ้นส่วน" มาตรฐานอยู่แล้ว ในด้านหนึ่งมีตารางมากขึ้นและกระบวนการโหลดและดึงข้อมูลควรดูซับซ้อนมากขึ้น ในทางกลับกันพวกเขาก็กลายเป็น ทั่วไป. ซึ่งหมายความว่าอาจจะมี ขับเคลื่อนอัตโนมัติและข้อมูลเมตา. คำถาม“ เราจะวางมันอย่างไร” คำตอบที่อาจต้องใช้เวลาส่วนสำคัญของงานในการออกแบบการปรับปรุงตอนนี้ก็ไม่คุ้มค่า (รวมถึงคำถามเกี่ยวกับผลกระทบของการเปลี่ยนแปลงแบบจำลองต่อกระบวนการทำงาน ).
นี่ไม่ได้หมายความว่านักวิเคราะห์ไม่จำเป็นในระบบดังกล่าวเลย - บางคนยังต้องทำงานผ่านชุดของออบเจ็กต์ที่มีคุณลักษณะและค้นหาว่าจะโหลดทั้งหมดที่ไหนและอย่างไร แต่ปริมาณงาน รวมถึงโอกาสและต้นทุนของข้อผิดพลาดจะลดลงอย่างมาก ทั้งในขั้นตอนการวิเคราะห์และระหว่างการพัฒนา ETL ซึ่งในส่วนสำคัญสามารถลดเหลือเพียงการแก้ไขข้อมูลเมตาได้
ด้านมืด
ทั้งหมดที่กล่าวมาข้างต้นทำให้ทั้งสองแนวทางมีความยืดหยุ่น มีความก้าวหน้าทางเทคโนโลยีอย่างแท้จริง และเหมาะสำหรับการปรับปรุงซ้ำๆ แน่นอนว่ายังมี "ถังในครีม" ซึ่งฉันคิดว่าคุณคงเดาได้แล้ว
การสลายตัวของข้อมูลซึ่งรองรับโมดูลาร์ของสถาปัตยกรรมที่ยืดหยุ่น นำไปสู่การเพิ่มจำนวนตาราง และด้วยเหตุนี้ ค่าใช้จ่าย เพื่อเข้าร่วมเมื่อสุ่มตัวอย่าง เพื่อให้ได้แอตทริบิวต์ทั้งหมดของมิติข้อมูล ในร้านค้าแบบคลาสสิก การเลือกรายการเดียวก็เพียงพอแล้ว แต่สถาปัตยกรรมที่ยืดหยุ่นจะต้องมีการรวมทั้งชุด ยิ่งไปกว่านั้น หากสามารถเขียนการรวมรายงานเหล่านี้ล่วงหน้าได้ นักวิเคราะห์ที่คุ้นเคยกับการเขียน SQL ด้วยมือจะได้รับผลกระทบเป็นสองเท่า
มีข้อเท็จจริงหลายประการที่ทำให้สถานการณ์นี้ง่ายขึ้น:
เมื่อทำงานกับขนาดใหญ่ คุณลักษณะทั้งหมดแทบไม่เคยถูกใช้พร้อมกันเลย ซึ่งหมายความว่าอาจมีการรวมน้อยกว่าที่เห็นเมื่อดูแบบจำลองครั้งแรก Data Vault ยังสามารถคำนึงถึงความถี่ในการแบ่งปันที่คาดหวังเมื่อจัดสรรคุณลักษณะให้กับดาวเทียม ในขณะเดียวกัน ตัวฮับหรือจุดยึดเองก็จำเป็นสำหรับการสร้างและการทำแผนที่ตัวแทนในขั้นตอนการโหลดเป็นหลัก และไม่ค่อยมีการใช้ในการสืบค้น (โดยเฉพาะอย่างยิ่งสำหรับจุดยึด)
การรวมทั้งหมดใช้คีย์ นอกจากนี้ วิธีการจัดเก็บข้อมูลแบบ "บีบอัด" มากขึ้นจะช่วยลดค่าใช้จ่ายในการสแกนตารางเมื่อจำเป็น (เช่น เมื่อกรองตามค่าแอตทริบิวต์) ซึ่งอาจนำไปสู่ความจริงที่ว่าการสุ่มตัวอย่างจากฐานข้อมูลมาตรฐานที่มีการรวมจำนวนมากจะเร็วกว่าการสแกนมิติข้อมูลหนักๆ หนึ่งมิติที่มีหลายเวอร์ชันต่อแถวด้วยซ้ำ
ตัวอย่างเช่นที่นี่ใน บทความนี้มีการทดสอบเปรียบเทียบประสิทธิภาพของโมเดล Anchor โดยละเอียดพร้อมตัวอย่างจากตารางเดียว
มากขึ้นอยู่กับเครื่องยนต์ แพลตฟอร์มสมัยใหม่จำนวนมากมีกลไกการปรับให้เหมาะสมการรวมภายใน ตัวอย่างเช่น MS SQL และ Oracle สามารถ "ข้าม" การรวมเข้ากับตารางได้หากไม่มีการใช้ข้อมูลของพวกเขาที่ใดก็ได้ยกเว้นการรวมอื่น ๆ และไม่ส่งผลกระทบต่อการเลือกขั้นสุดท้าย (การกำจัดตาราง/การรวม) และ MPP Vertica ได้รับการพิสูจน์แล้วว่าเป็นเครื่องมือที่ยอดเยี่ยมสำหรับ Anchor Model เนื่องจากมีการปรับแผนการสืบค้นด้วยตนเอง ในทางกลับกัน การจัดเก็บ Anchor Model เช่น บน Click House ซึ่งมีการสนับสนุนการเข้าร่วมที่จำกัด ก็ดูไม่ใช่ความคิดที่ดีนัก
นอกจากนี้สำหรับสถาปัตยกรรมทั้งสองนั้นยังมี การเคลื่อนไหวพิเศษทำให้การเข้าถึงข้อมูลง่ายขึ้น (ทั้งจากจุดยืนด้านประสิทธิภาพการสืบค้นและสำหรับผู้ใช้ปลายทาง) ตัวอย่างเช่น, ตารางจุดในเวลา ใน Data Vault หรือ ฟังก์ชั่นตารางพิเศษ ในโมเดล Anchor
เบ็ดเสร็จ
สาระสำคัญของสถาปัตยกรรมที่มีความยืดหยุ่นที่ได้รับการพิจารณาคือความเป็นโมดูลาร์ของ "การออกแบบ"
เป็นคุณสมบัตินี้ที่ช่วยให้:
- หลังจากการเตรียมการเบื้องต้นเกี่ยวกับการปรับใช้ข้อมูลเมตาและการเขียนอัลกอริธึม ETL พื้นฐานแล้ว ให้ผลลัพธ์แรกแก่ลูกค้าอย่างรวดเร็ว ในรูปแบบของรายงานสองสามฉบับที่มีข้อมูลจากออบเจ็กต์แหล่งที่มาเพียงไม่กี่รายการ ไม่จำเป็นต้องคิดอย่างถี่ถ้วน (แม้แต่ในระดับบนสุด) เกี่ยวกับโมเดลออบเจ็กต์ทั้งหมด
- โมเดลข้อมูลสามารถเริ่มทำงาน (และมีประโยชน์) ด้วยออบเจ็กต์เพียง 2-3 ชิ้นเท่านั้น จากนั้น ค่อยๆ เติบโต (เกี่ยวกับโมเดล Anchor Nikolai เปรียบเทียบได้ดีกับไมซีเลียม)
- การปรับปรุงส่วนใหญ่รวมถึงการขยายสาขาวิชาและเพิ่มแหล่งข้อมูลใหม่ ไม่ส่งผลกระทบต่อฟังก์ชันการทำงานที่มีอยู่ และไม่ก่อให้เกิดความเสี่ยงที่จะทำลายสิ่งที่กำลังทำงานอยู่.
- ต้องขอบคุณการแยกย่อยเป็นองค์ประกอบมาตรฐาน กระบวนการ ETL ในระบบดังกล่าวจึงดูเหมือนกัน การเขียนของพวกมันยืมตัวเองไปสู่อัลกอริทึม และท้ายที่สุด ระบบอัตโนมัติ.
ราคาของความยืดหยุ่นนี้คือ ประสิทธิภาพ. นี่ไม่ได้หมายความว่าเป็นไปไม่ได้ที่จะบรรลุประสิทธิภาพที่ยอมรับได้ในรุ่นดังกล่าว บ่อยครั้ง คุณอาจต้องการความพยายามและความใส่ใจในรายละเอียดมากขึ้นเพื่อให้บรรลุเกณฑ์ชี้วัดที่คุณต้องการ
ปพลิเคชัน
ประเภทเอนทิตี คลังข้อมูล
ข้อมูลเพิ่มเติมเกี่ยวกับ Data Vault:
ประเภทเอนทิตี โมเดลสมอเรือ
รายละเอียดเพิ่มเติมเกี่ยวกับ Anchor Model:
ตารางสรุปพร้อมคุณสมบัติทั่วไปและข้อแตกต่างของแนวทางที่พิจารณา:
ที่มา: will.com