Variety และ Data Integration

1Schema-on-Write vs. Schema-on-Read

สองคำนี้ไม่ได้หมายถึง “มี Schema” กับ “ไม่มี Schema” เพราะทันทีที่เรา parse JSON, เลือก field หรือคำนวณค่า เรากำลังใช้ schema บางอย่างแล้ว ความต่างอยู่ที่ เมื่อใด ใคร และเข้มงวดเพียงใดที่ schema ถูกนำมาบังคับ

Schema-on-Write ไม่ได้แปลว่า Schema ต้องแข็งตลอดไป

ตารางที่บังคับ schema ยัง evolve ได้ เช่นเพิ่ม nullable column, ขยายชนิดตัวเลข หรือแยก version แต่ต้องกำหนด compatibility และ migration ให้ชัด ความเข้มงวดตอนเขียนช่วยกันข้อมูลผิดเข้าตาราง ไม่ได้ห้ามระบบเปลี่ยนแปลง

Schema-on-Read ไม่ได้แปลว่าโยนไฟล์อะไรก็ได้แล้วค่อยว่ากัน

แม้ raw zone รับข้อมูลหลายรูปแบบ ก็ควรบันทึก metadata ขั้นต่ำ เช่น source, ingestion time, content type, checksum, schema/version ที่ผู้ส่งประกาศ และสิทธิ์การใช้ หากไม่มีข้อมูลเหล่านี้ เราอาจเก็บ byte ไว้ครบแต่ไม่รู้ว่าควรอ่านอย่างไรหรือเชื่อได้แค่ไหน

Raw ไม่ได้แปลว่าไม่มีการเปลี่ยนแปลงเลย

คำว่า Raw ควรนิยามตามขอบเขต อาจหมายถึง payload ที่ได้รับจาก source พร้อม envelope metadata เราอาจ decompress, decrypt หรือย้าย transport framing ออกเพื่อเก็บอย่างปลอดภัย แต่ไม่ควรเปลี่ยน business value โดยไม่เก็บต้นฉบับหรือ lineage คำสำคัญคือ replayable: หาก logic วันนี้ผิด เราควรสร้าง curated data ใหม่จาก source ที่เชื่อถือได้

ETL กับ ELT ต่างกันที่จังหวะ ไม่ใช่ความดีความชั่ว

Medallion Architecture เป็นชื่อเรียกชั้น ไม่ใช่กฎธรรมชาติ

บางระบบเรียก Bronze/Silver/Gold: Bronze ใกล้ raw, Silver ผ่านการทำความสะอาดและเชื่อมความหมาย, Gold พร้อมใช้ตามผลิตภัณฑ์ข้อมูล แนวคิดช่วยสื่อสารระดับความพร้อม แต่ชื่อชั้นไม่ได้รับประกันคุณภาพ ต้องระบุ contract, owner และ acceptance tests ของแต่ละชั้น

Schema Enforcement กับ Schema Evolution ต้องเดินคู่กัน

Enforcement ป้องกันข้อมูลที่ไม่เข้ากติกา ส่วน Evolution เปิดให้กติกาเปลี่ยนอย่างควบคุม หากบังคับเข้มโดยไม่มี evolution pipeline จะพังทุกครั้งที่ source เพิ่ม field หาก evolve อัตโนมัติทุกอย่างโดยไม่ตรวจ เราอาจรับ breaking change เงียบ ๆ ระบบที่ดีต้องรู้ว่า change แบบใด backward/forward compatible

Schema Registry และ Data Contract

Schema Registry เก็บ schema versions และตรวจ compatibility ของ message ส่วน Data Contract กว้างกว่า โดยระบุ owner, semantics, quality, freshness, privacy, deprecation และวิธีแจ้งการเปลี่ยน Contract ไม่ควรเป็นเอกสารที่ไม่มีใครทดสอบ จึงควรแปลงส่วนที่ตรวจได้เป็น automated checks ใน CI และ pipeline

2Logical Architecture ของ Data Engineering Pipeline

สถาปัตยกรรมแบบชั้นช่วยแยกความรับผิดชอบ แต่ไม่ควรถูกอ่านเป็นสายพานทางเดียวเสมอไป ระบบจริงมี batch, streaming, CDC, API และ feedback loop หลายแบบ สิ่งสำคัญคือทุกชั้นมี input/output contract และสามารถตาม lineage ย้อนกลับได้

Control Plane กับ Data Plane

Data Plane คือเส้นทางที่ record ไหลจริง ส่วน Control Plane คือ schema, catalog, access policy, lineage, orchestration และ monitoring ที่บอกว่าข้อมูลควรไปไหนและเชื่อได้แค่ไหน หลายโครงการลงทุนท่อข้อมูลแต่ละเลย Control Plane สุดท้ายมีไฟล์ครบแต่ไม่มีใครหาหรืออธิบายได้

Batch, Streaming และ CDC อยู่ร่วมกันได้

Idempotency: รับซ้ำแล้วไม่สร้างผลซ้ำ

ระบบ ingestion มัก retry เมื่อ timeout แต่ timeout ไม่ได้บอกว่าปลายทางทำงานไม่สำเร็จ หากส่งซ้ำแล้วสร้าง record ใหม่ทุกครั้ง เราได้ยอดซ้ำ วิธีแก้คือมี event ID, source offset หรือ business key และกำหนดขอบ deduplication ให้ชัด อย่างไรก็ตาม deduplicate ด้วย key ผิดอาจเผลอลบเหตุการณ์จริงที่เกิดซ้ำได้

Exactly-once เป็น End-to-End Property

Broker อาจรับประกันการส่งในขอบของตน แต่ถ้า consumer เขียน database แล้ว crash ก่อน commit offset event อาจถูกประมวลผลซ้ำ การได้ผลธุรกิจหนึ่งครั้งต้องประสาน source, processing และ sink หรือทำ operation ให้ idempotent ไม่ควรเห็นคำว่า exactly-once ในผลิตภัณฑ์ชั้นหนึ่งแล้วถือว่าทั้ง pipeline ได้ทันที

Quarantine ดีกว่าทิ้งเงียบ

เมื่อ record ผิด schema เรามีหลายทาง: fail ทั้ง batch, drop, เติม default หรือแยก quarantine การเลือกขึ้นกับ criticality และสัดส่วนความเสียหาย Quarantine ช่วยให้ pipeline หลักเดินต่อพร้อมเก็บหลักฐาน แต่ต้องมี owner, alert และกระบวนการแก้ ไม่เช่นนั้นเป็นสุสานข้อมูลที่โตเงียบ ๆ

Data Lineage: รู้ว่าค่านี้เดินทางมาอย่างไร

Lineage ควรตอบได้ว่า dashboard ช่องนี้มาจาก table ใด transformation version ไหน ใช้ source snapshot เวลาใด และใครเป็น owner เมื่อ logic ผิด เราจึงประเมิน impact และสร้างผลใหม่ได้ การเก็บเพียงชื่อ job ไม่พอ ควรเชื่อม dataset-column-job ตามระดับที่คุ้มกับงาน

Observability ของข้อมูลไม่เหมือน Monitoring Server

CPU 20% และ job status success ไม่ได้บอกว่าคอลัมน์รายได้กลายเป็นศูนย์ทั้งหมด เราต้องดู volume, freshness, schema change, null rate, distribution, uniqueness และ referential integrity พร้อม baseline ตามวัน/ฤดูกาล การเตือนต้องแยก incident จริงจากพฤติกรรมธุรกิจที่เปลี่ยน

3Data Ingestion และ Data Wrangling ในรายละเอียด

Data Wrangling ไม่ใช่ขั้น “ทำข้อมูลให้สวย” แต่เป็นกระบวนการทำให้ข้อมูลตอบคำถามได้โดยไม่ทำลายหลักฐานเดิม ทุกการลบ เติม หรือรวมควรมีเหตุผลและสามารถตรวจย้อนกลับได้

Profiling: ดูข้อมูลก่อนออกกฎ

ก่อนเขียน cleaning rule ควรดูจำนวน record, min/max, quantile, distinct count, top values, pattern และ null rate แยกตาม source/time เพราะ distribution รวมอาจซ่อนปัญหาในแหล่งหนึ่ง ตัวอย่างอายุเฉลี่ยปกติไม่ได้แปลว่าไม่มีอายุ -20 หากดูแค่ mean

Missing ไม่ได้มีความหมายเดียว

ถ้าแปลงทุกกรณีเป็น null ตัวเดียว เราสูญความหมายและอาจ impute ผิด การเติมค่าเฉลี่ยช่วยให้โมเดลรับตัวเลขครบ แต่ลด variance และอาจสร้าง bias ควรเลือกจาก mechanism ของ missingness และวัตถุประสงค์

Outlier อาจเป็น Error หรือ Signal

อุณหภูมิร่างกาย 370°C น่าจะเป็น decimal/หน่วยผิด แต่รายการโอนเงินสูงผิดปกติอาจเป็น fraud ที่เราต้องการหา การลบ outlier ทุกตัวทำให้โมเดลดูเรียบร้อยเพราะเราลบกรณีที่ยากออกไปแล้ว ควรแยก:

• Impossible value: ผิดกฎกายภาพหรือ schema
• Rare but valid: หายากแต่เป็นจริง
• Contextual anomaly: ปกติในกลุ่มหนึ่ง ผิดปกติในอีกกลุ่ม
• Data pipeline artifact: เกิดจาก parse, join หรือ duplication ผิด

Duplicate มีหลายชนิด

Exact duplicate ลบง่ายกว่า near duplicate บุคคลเดียวกันอาจสะกดชื่อไม่เหมือนกัน ส่วนธุรกรรมสองรายการมูลค่าเท่ากันเวลาใกล้กันอาจเป็นการซื้อจริงสองครั้ง การ deduplicate ต้องมี business key, time window และ evidence ไม่ใช่ DISTINCT * แล้วถือว่าจบ

Standardization กับ Normalization ต่างกันตามบริบท

ใน Data Integration การ standardize อาจหมายถึงแปลงวันที่ หน่วย และ code ให้เป็นมาตรฐาน ส่วนใน Machine Learning standardization มักหมายถึงปรับค่าให้ค่าเฉลี่ย 0 ส่วนเบี่ยงเบนมาตรฐาน 1 คำเดียวกันจึงต้องระบุบริบท ในบทนี้เน้นการทำ representation ให้เทียบกันได้ก่อนวิเคราะห์

หน่วยควรเป็นข้อมูล ไม่ใช่อยู่ในความทรงจำของทีม

{
  "value": 37.5,
  "unit": "Cel",
  "measured_at": "2026-08-02T10:30:00+07:00",
  "device_id": "T-104",
  "method": "oral"
}

ค่า 37.5 เพียงตัวเดียวไม่พอสำหรับงานแพทย์หรือวิทยาศาสตร์ หน่วย วิธีวัด เวลา และอุปกรณ์เปลี่ยนการตีความ Metadata จึงไม่ใช่ของประดับ แต่เป็นส่วนของข้อมูลที่ทำให้ค่าหลักมีความหมาย

เวลา: Event Time, Processing Time และ Ingestion Time

การใช้ processing time แทน event time ทำให้ยอดเที่ยงคืนย้ายวันเมื่อข้อมูลมาช้า ต้องเก็บ timezone และนิยาม business day ด้วย Timestamp ที่ไม่มี offset อาจตีความไม่ได้เมื่อข้อมูลข้ามประเทศหรือช่วง Daylight Saving Time

Slowly Changing Dimension

ลูกค้าย้ายจังหวัด เราต้องการรายงานยอดเก่าตามจังหวัดปัจจุบันหรือจังหวัดตอนซื้อ? Type 1 เขียนทับค่าปัจจุบัน เหมาะเมื่อแก้ข้อมูลผิดและไม่ต้องรักษาประวัติ Type 2 สร้าง version พร้อมช่วงเวลา ช่วยตอบตามสถานะ ณ วันเกิดเหตุ แต่ join ซับซ้อนขึ้น นี่เป็นตัวอย่างว่า “ข้อมูลที่ถูกต้อง” ขึ้นกับคำถามเรื่องเวลา

Entity Resolution: คนเดียวกันหรือไม่

ระบบหนึ่งใช้เลขสมาชิก อีกระบบใช้อีเมล และอีกระบบสะกดชื่อไทย/อังกฤษ การสร้าง Single Customer View ต้องจับ record ที่อาจเป็นคนเดียวกัน วิธี deterministic ใช้ key ที่น่าเชื่อถือ ส่วน probabilistic matching ใช้ชื่อ ที่อยู่ โทรศัพท์ และคะแนน similarity

Join เปลี่ยน Grain และทำให้ยอดพองได้

ตาราง Order หนึ่งแถวต่อคำสั่งซื้อ Join กับ Order Items หลายแถวแล้วนำยอด Order มารวมซ้ำ จะเกิด double counting ก่อน join ต้องระบุ grain ของแต่ละ table เช่นหนึ่งแถวต่อ customer/order/item/day และตรวจ cardinality one-to-one, one-to-many หรือ many-to-many

Transformation ต้อง Version และทดสอบได้

กฎแปลงรหัสจังหวัดหรืออัตราแลกเปลี่ยนเปลี่ยนตามเวลา ควรเก็บ rule version, effective date และ reference snapshot ถ้าใช้ lookup ล่าสุดไปคำนวณอดีต ผลรายงานอาจเปลี่ยนทุกครั้งที่รันโดยไม่รู้สาเหตุ

4Variety ในเชิงข้อมูล: มิติที่มากกว่าแค่ "structured vs unstructured"

กรอบเจ็ดชั้นของความไม่เหมือนกัน

Syntactic Integration: อ่านให้ออกก่อน

ชั้นแรกคือ parse byte ให้เป็น record เช่นจัดการ delimiter, quote, escape, encoding และ nested fields ปัญหา CSV ที่มี comma ในข้อความหรือ newline ใน quoted field ไม่ควรแก้ด้วย split(',') ธรรมดา ต้องใช้ parser ตามมาตรฐานและบันทึก malformed record

Structural Integration: รูปร่างไม่เหมือนกัน

Address ในระบบหนึ่งแยกบ้าน ถนน จังหวัด แต่อีกระบบเป็นข้อความก้อนเดียว การ flatten JSON ช่วย query แต่ชื่อ field อาจชนและ array ทำให้จำนวนแถวเพิ่ม เราต้องกำหนด mapping และ grain หลัง explode ให้ชัด ไม่เช่นนั้นยอดรวมอาจพองเหมือนปัญหา join

Semantic Integration: ชื่อเหมือนกันแต่ความหมายต่าง

คอลัมน์ sales ฝ่ายหนึ่งหมายถึงยอดสั่งซื้อ อีกฝ่ายหมายถึงยอดชำระแล้ว ทั้งคู่เป็น Decimal และใช้บาท จึงผ่าน schema/units check แต่รวมกันไม่ได้ Business Glossary ต้องนิยามสูตร inclusion/exclusion และ owner ไม่ใช่เพียงคำแปลชื่อคอลัมน์

ชื่อแตกต่างแต่ความหมายเดียวกัน

cust_id, member_no และ party_identifier อาจชี้ entity เดียวกัน แต่แต่ละระบบมี namespace และ lifecycle ต่างกัน การ rename ทุกอย่างเป็น customer_id ไม่ได้สร้าง mapping โดยอัตโนมัติ ต้องมี crosswalk/master key และช่วงเวลาที่ mapping มีผล

Granularity: รวมข้อมูลคนละระดับไม่ได้ตรง ๆ

ยอดโฆษณารายวันกับยอดขายรายธุรกรรม join ด้วยวันที่แล้วนำค่าโฆษณาไปซ้ำทุกธุรกรรม ทำให้ cost พอง ต้อง aggregate ยอดขายเป็นรายวันก่อนหรือกระจาย cost ตาม rule ที่ประกาศ Grain เป็นส่วนหนึ่งของ schema ทางความหมายและควรเขียนไว้ในชื่อตาราง/contract

Geospatial Variety

พิกัดอาจใช้ latitude/longitude หรือ projected coordinate reference system ต่างกัน แกน x/y อาจสลับ และ polygon อาจ invalid การเห็นตัวเลขสองช่องไม่พอ ต้องเก็บ CRS, precision และ boundary version เช่นเขตการปกครองเปลี่ยนตามปี

Text และภาษา

ข้อความไทยมีปัญหาการตัดคำ Unicode normalization ตัวอักษรหน้าตาคล้าย และ encoding เก่า การ lowercase ที่ใช้กับอังกฤษไม่ได้แก้ทุกภาษา ชื่อบุคคลมีการถอดเสียงหลายแบบ การ normalize มากเกินไปอาจทำให้ชื่อคนละคนชนกัน จึงควรเก็บทั้ง raw และ normalized form

ภาพ เสียง และ Video

ข้อมูล multimedia ไม่ได้มีเพียงไฟล์ binary แต่มี codec, resolution, frame rate, sampling rate, color space และ metadata อุปกรณ์ ภาพเดียวกันที่ resize/compress ต่างกันอาจมี hash คนละค่า การ deduplicate จึงอาจใช้ perceptual hash หรือ embedding ตามโจทย์ แต่ต้องระวัง false match

Time Series จาก Sensor

Sensor หลายรุ่น sampling rate ต่าง calibration ต่าง และบางช่วงขาด packet การ resample ทุกชุดเป็นหนึ่งนาทีอาจสะดวก แต่ทำให้ peak สั้นหาย ต้องเลือก aggregation ตาม phenomenon และเก็บ quality flag ไม่ควร interpolate ข้ามช่วงยาวโดยไม่บอกผู้ใช้

Label Variety ใน Machine Learning

Annotator หลายคนใช้เกณฑ์ต่างกัน label taxonomy เปลี่ยนตามรุ่น และ class เดียวอาจมีความมั่นใจไม่เท่ากัน การบังคับเป็น label เดียวทิ้ง disagreement ซึ่งอาจเป็นข้อมูลสำคัญ ควรเก็บ annotator, guideline version, confidence และ adjudication process

Provenance: ค่าเดียวกันมาจากใคร

อายุ 35 จากแบบฟอร์มผู้ใช้, OCR เอกสาร และโมเดลคาดการณ์มี reliability ต่างกัน แม้ค่าเท่ากัน ระบบควรเก็บ source และ method เพื่อเลือก priority หรือแสดง confidence หาก merge เหลือเพียงเลข 35 เราสูญเหตุผลว่าทำไมควรเชื่อ

ความหมายไม่ได้อยู่ในข้อมูลเพียงอย่างเดียว

Single Customer View ไม่จำเป็นต้องเป็น Golden Row เดียว

การบีบข้อมูลทุกแหล่งให้เหลือ record เดียวอาจซ่อนความขัดแย้ง ทางเลือกคือเก็บ survivorship rule และ source-specific values เช่นที่อยู่จาก KYC มี priority สูงกว่า social profile แต่ไม่ลบค่าต้นทาง ผู้ใช้จึงตรวจได้ว่า golden value ถูกเลือกจากกฎใด

5เมื่อยุคเปลี่ยน: จาก Data Lake สู่ Data Lakehouse

File Format, Table Format, Catalog และ Compute Engine คนละส่วน

การเรียกทุกอย่างว่า Lakehouse ทำให้วินิจฉัยยาก หาก query ช้า ปัญหาอาจอยู่ file size, partition, catalog latency หรือ engine plan ไม่ใช่คำว่า Lakehouse โดยรวม

Snapshot ทำให้ Reader ไม่เห็น Table ครึ่งเก่า–ครึ่งใหม่

Writer สร้าง data files ใหม่ก่อน แล้ว commit metadata ให้ snapshot ใหม่มองเห็นไฟล์ชุดนั้นอย่าง atomic Reader ที่เริ่มก่อน commit ยังอ่าน snapshot เก่าได้ ส่วน reader ใหม่เห็น snapshot ใหม่ วิธีนี้คล้าย copy-on-write/versioning จากบท Functional Programming

Time Travel ช่วย Reproducibility แต่ไม่ใช่ Backup ตลอดกาล

การ query snapshot เก่าช่วยตรวจผลรายงานและสร้าง ML dataset รุ่นเดิม แต่ระบบมี retention/cleanup ที่ลบ files เก่า Time Travel ยังอยู่ storage/account เดียวกับข้อมูลหลัก จึงไม่แทน backup ที่แยก failure domain และ recovery procedure

Schema Evolution ต้องรู้ Field Identity

Table format บางชนิดใช้ field ID แยกจากชื่อ ทำให้ rename ไม่ถูกตีความเป็น drop column เก่าแล้วเพิ่มใหม่ แต่ consumer, engine และ format ต้องรองรับ การเปลี่ยน type ที่ incompatible ยังต้อง migration ไม่ควรเปิด auto-merge แล้วหวังว่าทุก change ปลอดภัย

Partition Evolution

เมื่อข้อมูลโต จาก partition รายเดือนอาจต้องเปลี่ยนเป็นรายวัน ระบบอย่าง Iceberg สามารถเก็บ partition specs หลายรุ่นและวางแผนอ่านแต่ละชุดตาม metadata โดยไม่ rewrite ประวัติทั้งหมดทันที แนวคิดนี้ช่วยแยก logical query ออกจาก physical layout มากขึ้น

Small Files ยังไม่หาย

Streaming ingestion และ update ถี่อาจสร้างไฟล์เล็กจำนวนมาก ทำให้ planning และ request overhead สูง Table service ต้อง compact/rewrite files และ update metadata การได้ transaction semantics จึงมาพร้อมงานดูแล layout ไม่ใช่เปิด table format แล้วจบ

Data Mesh เป็น Operating Model ไม่ใช่ผลิตภัณฑ์

การให้ domain เป็นเจ้าของ Data Product ช่วยนำความรู้ด้านความหมายมาใกล้ผู้สร้าง แต่ถ้าทุกทีมตั้งมาตรฐานและเครื่องมือเองโดยไม่มี federated governance ความหลากหลายอาจแย่ลง Data Mesh ต้องมี self-service platform, interoperability, discoverability และ accountability ไม่ใช่เพียงแยก bucket ให้แต่ละทีม

Data Product ต้องมีมากกว่า Table

• คำอธิบายและ business semantics
• Owner และช่องทางติดต่อ
• Schema/contract พร้อม change policy
• Freshness, completeness และ quality SLO
• Access policy, classification และ retention
• ตัวอย่าง query และข้อจำกัดการใช้งาน

6Data Quality: ถูกต้องสำหรับคำถามใด

คำว่า “ข้อมูลสะอาด” ฟังเหมือนมีสถานะผ่าน/ไม่ผ่าน แต่คุณภาพขึ้นกับ use case ที่อยู่จัดส่งไม่ครบเลขห้องอาจใช้วิเคราะห์จังหวัดได้ แต่ใช้ส่งพัสดุไม่ได้ เราจึงต้องวัดคุณภาพตาม Fitness for Use

Threshold ต้องผูกกับผลกระทบ

Null 1% ใน optional nickname ไม่เหมือน null 1% ใน transaction amount การตั้ง threshold เดียวทุก column สร้าง alert noise ควรแบ่ง critical fields, warning และ informational พร้อม owner/response time

Distribution Drift ไม่ได้แปลว่าข้อมูลเสียเสมอ

ยอดขายเปลี่ยนเพราะเทศกาลหรือ campaign อาจเป็นธุรกิจจริง ส่วน distribution กระโดดเพราะ source เปลี่ยนหน่วยคือ data incident การตรวจ drift ต้องใช้ context, calendar และ deployment events ไม่ควร auto-reject ทุกการเปลี่ยนแปลง

Quality Debt

ทีมมักแก้ข้อมูลผิดซ้ำในทุก downstream job เพราะต้นทางไม่เปลี่ยน กฎ cleaning จึงกระจัดกระจายและให้ผลต่างกัน Quality Debt เพิ่มเหมือน Technical Debt วิธีลดคือผลัก fix ไปจุดต้นเหตุเมื่อทำได้ และเผยแพร่ reusable standardized dataset/contract แทน copy rule

Data Quality Incident ต้องมีวงจรแก้ไข

1. ตรวจพบและประเมินผลกระทบ
2. หยุดหรือทำเครื่องหมาย output ที่ไม่น่าเชื่อถือ
3. แจ้ง consumers และ owner
4. แก้ source/pipeline แล้ว backfill อย่าง versioned
5. เพิ่ม test/contract ป้องกันเกิดซ้ำ

7กรณีศึกษา: รวมข้อมูลการขายจากสามระบบ

สมมุติ ERP เก็บรายการขายเป็นบาทตามเวลาประเทศไทย, Payment Gateway ส่งจำนวนเป็นสตางค์และเวลา UTC, CRM มี customer ID คนละ namespace เป้าหมายคือสร้างยอดชำระสำเร็จต่อจังหวัดและ Customer 360

ขั้นที่ 1: เก็บ Source แยกและระบุ Grain

ERP หนึ่งแถวต่อ order item, Payment หนึ่งแถวต่อ payment attempt และ CRM หนึ่งแถวต่อ customer version หาก join ตรง ๆ Order หนึ่งรายการที่ลองจ่ายสามครั้งจะถูกคูณ ต้องเลือก successful attempt หรือ aggregate payment ก่อน join

ขั้นที่ 2: ทำเวลาและหน่วยเป็น Canonical

เก็บ event timestamp แบบมี timezone/UTC พร้อม local business date แยก และแปลงสตางค์เป็น Decimal บาทด้วย rule version หลีกเลี่ยง floating point สำหรับเงิน

ขั้นที่ 3: Resolve Identity

สร้าง mapping ระหว่าง ERP customer ID กับ CRM party ID โดยใช้ verified email/phone และเก็บ confidence ไม่ควร merge จากชื่อเหมือนอย่างเดียว Record ที่ไม่แน่ใจอยู่ unresolved queue แทนบังคับเลือก

ขั้นที่ 4: ตรวจ Reconciliation

ยอด Payment ที่ successful ควร reconcile กับยอดที่ ERP บันทึกภายใน tolerance และช่วงเวลา แต่ refund, fee และ partial payment ทำให้ไม่เท่ากันตรง ๆ ต้องนิยาม accounting semantics ก่อนเขียน test

ขั้นที่ 5: Publish Data Product

ตาราง curated ระบุ grain หนึ่งแถวต่อ paid order, schema, freshness, owner, quality metrics และ lineage Dashboard อ่าน Gold view ส่วน ML อาจอ่าน feature view ที่ลด leakage และตรึง snapshot ตามเวลาทำนาย

8สรุปและขั้นตอนถัดไป

Variety เริ่มจากรูปแบบไฟล์ แต่ไม่จบที่รูปแบบไฟล์ ข้อมูลอาจต่างกันที่โครงสร้าง หน่วย เวลา Identity Grain ความหมาย ที่มา และสิทธิ์การใช้ การรวมข้อมูลจึงเป็นทั้งงานวิศวกรรมและงานทำความเข้าใจโลกจริง

สิ่งที่ควรจำมีดังนี้:

• Schema-on-Read ไม่ได้แปลว่าไม่มี Schema แต่เลื่อนจังหวะและผู้รับผิดชอบในการตีความ
• Raw Zone ต้องมี metadata, provenance และ replayability ไม่เช่นนั้นกลายเป็น Data Swamp
• อย่าลบ Outlier หรือเติม Missing โดยไม่เข้าใจเหตุที่เกิด
• ประกาศ Grain ก่อน Join เพื่อป้องกัน Double Counting
• การทำหน่วย เวลา และ Identity ให้ตรงกันสำคัญกว่าการ rename column
• Lineage และ Data Contract ทำให้การเปลี่ยนแปลงตรวจพบและย้อนอธิบายได้
• Table Format เพิ่ม Snapshot, Evolution และ Transactional Metadata แต่ยังต้องดูแลไฟล์และ Compaction
• Data Quality ต้องวัดตาม Fitness for Use และมี Owner รับผิดชอบ
• ข้อมูลที่เชื่อมได้ไม่จำเป็นต้องเป็นข้อมูลที่มีสิทธิ์นำมาเชื่อม

บทถัดไปจะเข้าสู่ Spark SQL และ ML Pipeline ซึ่งเป็นจุดที่แนวคิดจากบทนี้กลายเป็นการลงมือจริง: Schema, DataFrame, Relational Algebra, Feature Transformation และ Pipeline จะช่วยเปลี่ยนข้อมูลที่หลากหลายให้เป็นการคำนวณที่ทำซ้ำและขยายขนาดได้