อยากสอบถามว่ามีวิธีหรือขั้นตอน เทคนิคก็ได้ครับ ว่าการ validate ข้อมูลหลังจากที่เรา extract มาแล้วมันตรงกับข้อมูลเดิมใน database ยังไงได้บ้างครับ ก่อนการทำ Transform
#มือใหม่ครับ
1 Like
ขอข้อมูลเพิ่มมากกว่านี้ได้มั้ยเอ่ย
ที่ว่า extract มาแล้วตรงกับข้อมูลใน database นี่คือยังไง มันแปลได้หลายอย่างมาก
ถ้าเอาที่เราเข้าใจตอนนี้ คือ ต้องการเช็คว่า [source data] กับ [extracted data from source] ตรงกัน
แต่เราก็จะงง ว่า มันก็ extract/export ออกมาตรงๆ แล้วมันจะไม่เหมือนกันเพราะอะไร มี issue อะไรถึงต้องการ validate ตรงนี้
ถ้าพูดถึง data validation ส่วนใหญ่เขาจะหมายถึง range, categorical value อะไรพวกนี้ ตรงตามสิ่งที่ expect ไว้ เช่น [travel time ไม่เกิน 2 ชั่วโมง] ถ้าเกินนี้ก็จะถือว่า validation failed
edit: typo
2 Likes
ขอโทษนะครับที่เขียน งงๆ หน่อยนะครับ
ถ้าในกรณี ที่คุณว่ามาแบบ range , categorical value พวกนี้ validate วิธีไหนได้บ้างครับ เคสผมคือ
สมมุติ ว่าดึง data จาก database ข้อมูลวันที่ 01/01/2022
แล้วอยากเทียบว่า script ที่เราเขียนดึง data ของวันที่ 01/01/2022 มาไม่ผิดไปจาก data ที่อยู่ใน database ครับ
ถ้า query จาก database อาจจะได้ nrow = 1000 ,schema = [ date: datetime, name:string, lastname:string]
ประมาณนี้ครับ
อืม ยังไม่ค่อยเข้าใจ ว่า ทำไมถึงต้องการเช็ค ว่า
data ที่ export ออกมา เหมือนกับที่มาจาก database มั้ย มันมีเคสหรือเหตุการณ์อะไร ถึงจำเป็นต้องเช็ค
จะมีคำถามต่อมาอีก ว่า source table ที่ไปเอาข้อมูลมา เป็นแบบ snapshot หรือ transaction, ก็คือ: ข้อมูล append อย่างเดียว หรือมีการ delete/update ด้วย
แล้ว schema นี่ทำไมถึงต้องเช็ค ต้นทางเป็น database อะไร เพราะถ้าเป็น relational มันควรจะล็อก schema มาให้อยู่แล้ว
และ ใช้ tools อะไรในการ extract/transform data, เพราะถ้าใช้ pandas เตรียมตัวเจอกับดัก dtype infer ได้เลย
แล้วจำนวน records อันนี้ต้องถามว่า ปกติตั้ง export schedule ตอนกี่โมง แล้วใน source table มี timestamp column ให้เทียบกันมั้ย ไม่งั้นมันจะบอกยาก ว่า records เท่ากันมั้ย
ที่งงคือ ถ้ามัน export ไม่ผ่าน ตัว extraction tool มันก็น่าจะฟ้องอยู่แล้ว เลยยังงงๆ ว่าทำไมถึงต้องการมา validate นอกรอบ
1 Like
ขออนุญาตถามข้อสุดท้ายครับ
ถ้างั้นขอคำแนะนำควรใช้อะไรในการดึงข้อมูลดีครับเพื่อป้องกันการเกิดปัญหา dtype เพี้ยนน้อยที่สุดครับ
กรณีผมคือใช้ airflow ในการดำเนินการทั้งหมดครับ ที่คิดไว้คือ ดึงข้อมูลมา แล้วก็ transform หลังจากนั้นก็ส่งเข้า Bigquery ครับ
โอเค เริ่มเห็นภาพ
แต่ ใช้ airflow ไม่ได้บอก ว่า ไส้ในมันเอาดาต้าออกมายังไง ตรงนี้อาจจะต้องรบกวนให้คุณอธิบายเพิ่มเติมอีกนิด ว่า ไส้ airflow เขาข้อมูลออกมายังไง และ โยนเข้า big query ยังไง ระหว่างทางใช้อะไร transform
ทีนี้ ทำไม dtype เพี้ยน
มันจะเพี้ยนถ้าเกิดใช้ framework ที่ infer dtype ให้โดย default ซึ่งอันนี้จะเป็นแบบที่ pandas ทำ
แต่ ต่อให้ล็อก dtype ใน pandas ก็ไม่แนะนำอยู่ดี เพราะมันมีโอกาสเละระหว่างทางสูง
และ file format ก็มีผลเช่นกัน เช่น csv/json จะไม่ระบุ dtype เอาไว้
แต่ parquet/avro จะมีการระบุ
1 Like
ใส้ในairflow ก็ประมาณว่า (ทุกอย่างอยู่บน GCP นะครับ)
dag1 : สั่ง python script โดยมีการ query ดึงข้อมูลมาแล้วใช้ pandas เปลี่ยนเป็น csv ใส่เก็บที่ google storage ( เป็นขั้นตอนที่ถามต้นกระทู้ว่าสามารถ validate ได้หรือเปล่าครับ)
dag2 : สั่ง dataflow(apache beam) transform ข้อมูล แล้วส่งเข้า big query as data warehouse
dag3 : สั่ง bq ทำการ partition by date
หลักๆประมาณนี้ครับ ถ้ามีอะไรควรระวังหรือเทคนิคอะไรรบกวนทีนะครับ
งั้นเหมือนว่าจะเป็น concern เรื่อง dtype เพี้ยน
เพราะฉะนั้น แนะนำให้ใช้ pyspark ในการ ingest/write to google blob storage เพราะ spark มันล็อก data type ไว้แน่นมาก
ก็คือ อ่านดาต้ามาจากต้นทาง ระหว่างทางปั่นดาต้าไป ตอนจบให้จับ cast dtype อีกที ตาม schema ที่ระบุไว้ แล้วค่อยเก็บเป็น parquet
เพราะไฟล์ parquet จะมี data type ติดมาให้ด้วย ไม่เหมือน csv/json ที่ต้องไป infer กันเอาเองหน้างาน
2 Likes