Scroll ลง เพื่อดูบทความ
เบื้องหลังเชิง Technical ของระบบรายงานผลเลือกตั้งร่วมกับ Workpoint News
โดย PanJ
การเลือกตั้งเมื่อวันที่ 24 มีนาคม ที่ผ่านมาหลาย ๆ คนน่าจะเคยได้ดูการรายงานผลแบบ Real-time ของ Workpoint News ที่เว็บ https://vote.workpointnews.com ซึ่งจัดทำโดยทีม Cleverse ของเรา บทความนี้ จะมาเล่าถึ ...
ไขปริศนา ความท้าทายต่าง ๆ ในการก้าวไปสู่ตำแหน่ง CTO
โดย PanJ
ในสายอาชีพ programmer/developer ตำแหน่งที่คนส่วนใหญ่คิดว่าสูงที่สุดแล้วน่าจะหนีไม่พ้น Chief Technology Officer หรือ CTO ซึ่งมีชื่อเรียกภาษาไทยเก๋ ๆ ว่าประธานเจ้าหน้าที่บริหารฝ่ายเทคโนโลยี เอาจริง ๆ แล ...
Solving BigData with BigQuery (3/3) — ใช้จริง
โดย SARIN
บทความนี้จะมีเนื้อหาเกี่ยวกับ Google BigQuery: Serverless Data Warehouse จาก Google ครับ บทความนี้เป็นเนื้อหาพาร์ทสุดท้ายจาก ซีรีส์แนะนำ Google BigQuery ของ Cleverse โดยบทความนี้จะเน้นไปที่แนวทางต่างๆ ...
Solving BigData with BigQuery (2/3) — ลองเล่น
โดย SARIN
คุณมีปัญหากับการวิเคราะห์ข้อมูลขนาดใหญ่ใช่ไหม? — ลองมาใช้ BigQuery ดูสิ 0) เกริ่นนำ หากคุณเป็นคนที่ทำงานในสายงาน Data Science หรือใกล้เคียง คุณอาจจะเคยได้ยินคนพูดถึง BigQuery มาบ้าง สรุปแบบสั้นๆเลยคือ ...
Solving BigData with BigQuery (1/3) — บทนำ
โดย SARIN
หลายๆคนอาจจะมองว่าการจัดการ Big Data เป็นเรื่องลำบาก — ตั้งแต่การวางแผนติดตั้งระบบ การนำข้อมูลเข้า จนถึงการ Query ข้อมูลแต่ละครั้งซึ่งทำได้ยากและใช้เวลานาน แถมพอใช้งานจริงก็ต้องคอยดูแลอีก วันนี้บล็อกน ...
ของโคตรดี! เมื่อแทนที่ GraphQL Backend ด้วย Graphcool!
โดย ชิน
สำหรับท่านที่ไม่เคยใช้ GraphQL มาก่อน น่าจะเคยใช้ชีวิตร่วมกับ REST มาก่อน ซึ่งตัว REST จะมีความต่างที่ชัดเจนจาก GraphQL คือ REST เราต้องกำหนด endpoint เต็มไปหมด ถ้า model เปลี่ยนไปเรื่อยๆต้องมาแก้ทีละ ...
ENGINEERING
DESIGN
CULTURE
Cleverse, a venture builder, with people who have fun building the future. If you also consider building the future a fun and meaningful purpose — let’s find a way we can work together.
121/75 RS TOWER 24th Floor
Ratchadaphisek Road
Dindaeng Bangkok 10400
Thailand
29.Mar.2018
โดย SARIN

Solving BigData with BigQuery (1/3) — บทนำ

Scroll down

หลายๆคนอาจจะมองว่าการจัดการ Big Data เป็นเรื่องลำบาก — ตั้งแต่การวางแผนติดตั้งระบบ การนำข้อมูลเข้า จนถึงการ Query ข้อมูลแต่ละครั้งซึ่งทำได้ยากและใช้เวลานาน แถมพอใช้งานจริงก็ต้องคอยดูแลอีก

วันนี้บล็อกนี้จะขอแนะนำ Tool ตัวหนึ่งจาก Google: BigQuery ซึ่งเป็น Tool หลักที่บริษัทใช้ทำการวิเคราะห์ Big Data ครับ

*ที่รูปประกอบมีโลโก้ amazon.co.jp ติดอยู่นั้นไม่มีนัยยะแอบแฝงแต่อย่างใด ผู้เขียนแค่ลืมลบออก


Cleverse, สตาร์ทอัพเล็กๆ
กับโจทย์คือการวิเคราะห์ข้อมูลขนาดมหาศาล ;
คำถามคือไปต่อทางไหนดี

เรื่องเริ่มจากวันหนึ่งที่ทีมของเราคิด product แนว data ขึ้นมาได้ และได้หาวิธีให้ได้สิทธิเข้าถึงข้อมูล Big Data ก้อนนึง ซึ่งเราต้องทำการหา Insights อะไรบางอย่างจากข้อมูลกลุ่มนี้

เราเริ่มงานนี้โดยมี Developer ในทีมประมาณ 3 คนเศษๆ (?) ซึ่งเกือบทุกคนไม่มีประสบการณ์ในงานสาย data มาก่อน เราจึงได้ลองประยุกต์ใช้ Tools หลายๆ ตัวกับฐานข้อมูลชุดนี้ดู


1) เล่าปัญหา; Dealing with a big dataset

เริ่มแรกมาเลยเราก็ลองใช้ ElasticSearch มาเพื่อเก็บข้อมูล เนื่องจาก ES สามารถเก็บข้อมูลได้ทั้งแบบ Structured และ Unstructured Data สนับสนุน Query ค่อนข้างหลากหลายซึ่งตรงกับที่เราอยากได้ และเอาไป Visualize ต่อได้ง่ายๆบน Kibana แต่สุดท้ายก็ต้องล้มเลิกไปเพราะค่าใช้จ่ายที่สูงขึ้นและ Performance ที่ไม่เร็วพอตามที่หวังไว้

หลังจากนั้นผมเลยถอยกลับมาลองเอา Database (SQL, NoSQL) ตัวอื่นๆมาใช้แทน ซึ่งต้องติดตั้งและ Host เอง (บนคลาวด์) มาลองใช้งาน (MySQL, MongoDB, Cloud Datastore, Redis และอื่นๆ) พอลองใช้มาก็จะเจอปัญหาประมาณนี้ครับ

  1. Performance ไม่เพียงพอสำหรับไปใช้งานจริง — Scale ลำบากเมื่องานใหญ่ขึ้น
    Database แต่ละตัวจะความเร็ว+กินทรัพยากรในการประมวลผล Query แต่ละชนิดไม่เท่ากันซึ่งเป็นผลมาจากข้อจำกัดของระบบ ถ้าไม่ได้ประมาณทรัพยากรหรือตั้งระบบให้ดี สั่ง Query ใหญ่ๆ รัวๆหลายๆ ทีก็ทำ Server ระเบิดได้ แถมพอข้อมูลขนาดโตขึ้นก็จะเริ่มทำงานช้าลงจนเกินค่าที่เราต้องการ จะทำให้เร็วขึ้นโดยอัพสเป็คเครื่องก็ทำได้ (เช่น เพิ่ม RAM, ใช้ SSD, ลด Latency) แต่ก็ไม่คุ้มกับค่าใช้จ่ายที่เพิ่มขึ้น
  2. ลำบากในการ Set Up, Maintain, และ Monitor
    มันไม่ใช่เรื่องตลกเลยเมื่อหัวหน้าโทรมาบอกว่า Server ระเบิดไปตอนกำลังจิบกาแฟอยู่ในสตาร์บัค หรือตอนที่ต้องตื่นมาตอนหกโมงมาดูกราฟการใช้งานเครื่องแล้วภาวนาว่ามันจะไม่พัง (เพราะมีคนใช้พรีเซนต์ลูกค้าอยู่) ตอนจะลอง Database ใหม่ๆก็ต้องไปศึกษาการติดตั้งและการทำงานเพื่อนำไปตั้งค่าให้เหมาะสมอีก ซึ่ง Spec ของเครื่องที่ใช้ก็ประมาณได้ยาก ถ้าเลือกเอางบมาถมซื้อเครื่องแพงๆไปเลยก็อาจจะไม่คุ้มถ้าไม่ได้ใช้เครื่องให้เต็มที่ เพราะเราต้องทำ Product ที่ขายได้ในราคาที่เหมาะสม เราจึงต้องคุมต้นทุน ซึ่งสำหรับสตาร์ทอัพเล็กๆ ที่มีคนไม่มาก งานส่วนนี้กลายเป็นงานที่สาหัสมากจนไม่มีเวลาไปทำงานส่วนอื่นเลย
  3. นำเข้า(Ingestion) ข้อมูลไม่ทัน
    ข้อมูลที่เราได้รับจะถูก Stream เข้ามาเรื่อยๆ ครั้งละเยอะๆ ตลอดทั้งวัน บางครั้งมีข้อมูลซ้ำด้วย ในตอนแรกก็พยายามปรับตั้งค่าระบบให้รับข้อมูลให้ได้มากขึ้นและเร็วขึ้นโดยทำ Sharding แยกฐานข้อมูล หรืออัพสเป็คเครื่อง VM บนคลาวด์ (เช่น เพิ่ม RAM หรือเปลี่ยนเป็น SSD) เพื่อให้เขียนเร็วขึ้น แต่หลังที่จากข้อมูลขนาดใหญ่ขึ้นเกินค่าค่าหนึ่งก็เริ่มปรับไม่ไหวแล้ว
  4. ลำบากในการประมาณค่าใช้จ่ายล่วงหน้า
    ก่อนจะปล่อย Feature หนึ่งอันทางบริษัทต้องมีการประมาณค่าใช้จ่ายทางด้าน Infrastucture มาเป็นปัจจัยด้วย ซึ่งการประเมินค่าใช้จ่ายส่วนนี้ล่วงหน้านั้นทำได้ลำบากมาก เพราะตอนที่ได้ Implement เราจะรู้แค่ลักษณะ Query กับปริมาณข้อมูลที่เกี่ยวข้อง แต่ตอนประมาณราคาเราต้องนำข้อมูลพวกนั้นมาคำนวณต่อว่าจะต้องเปิดเครื่อง VM กี่เครื่อง แต่ละเครื่องต้องใช้สเป็คขนาดไหน ซึ่งประมาณได้ยากจากแค่ข้อมูลที่ทราบตอนแรก

 

หลังจากลองศึกษา Database อยู่หลายเดือน ผมก็ลองเปลี่ยนระบบบางส่วนมาใช้ Tools ตัวนึงของ Google ที่ไม่ค่อยเห็นคนไทยพูดถึงกัน —  BigQuery


2) Introducing Google BigQuery — ชีวิตดีเมื่อมี Google มาดูแลให้

A fast, highly scalable, cost-effective and fully-managed enterprise data warehouse for analytics at any scale

Google BigQuery เป็น Data Warehouse ที่ตั้งอยู่บนโครงสร้างของ Google Cloud Platform (เป็น Serverless) สามารถทำงานกับข้อมูลขนาดใดๆ ตั้งแต่จาก Excel เล็กๆ จนถึง Big Data ขนาดหลาย Petabyte ได้ในเวลาอันสั้น

การใช้งาน BigQuery

BigQuery รองรับการ Query แบบ SQL ทำให้สามารถ Implement ระบบได้อย่างง่ายดาย โดยสามารถเรียกใช้งาน (เอาข้อมูลเข้าและ Query) ผ่าน web UIcommand-line toolclient library (ปัจจุบันซัพพอร์ทภาษา C#, Go, Java, Node.js, PHP, Python และ Ruby) หรือจะยิงเป็น JSON Request เข้ามาทาง BigQuery REST API ก็ได้

Serverless — ให้กูเกิ้ลดูแลคุณ

ด้วยความที่เป็น Serverless คือระบบอยู่บนระบบของ Google เลย ทำให้ไม่ต้องเสียเวลามาติดตั้งหรือ Monitor เท่าไรนัก จึงเป็นตัวเลือกที่ดีสำหรับขนาดเล็กที่ไม่ต้องการจ้างคนมาดูแลแยก สามารถใช้งานบน Production จริงได้เลย ตัวระบบจะ Scale และปรับตามการใช้งานให้โดยอัตโนมัติไม่มีค่าใช้จ่ายเพิ่มเติมในส่วนนี้

การเชื่อมต่อกับ Tools อื่นๆ

นอกจากนี้ BigQuery ยังซัพพอร์ตการเชื่อมต่อกับ Tools อื่นๆ เพื่อเชื่อมต่อข้อมูลเข้าหรือออกไปใช้งานต่อได้ด้วย เช่น นำข้อมูลไปใช้บน Hadoop/Spark, นำเข้าข้อมูลสถิติโดยอัตโนมัติจากบริการต่างๆของ Google (DoubleClick, AdWords, YouTube Analytics) หรือจะนำข้อมูลออกไปแสดงผลบน tableau ก็ได้

BigQuery เหมาะกับงานประเภทไหน?

ข้อจำกัดเพียงไม่กี่อย่างของ BigQuery คือด้วยโครงสร้างของระบบ ทำให้ BigQuery เน้นสนับสนุนข้อมูลที่การเขียนเข้าเป็นหลัก ไม่เอื้อแก่การแก้ไขหรือลบข้อมูล (append-only tables) เท่าไหร่นักจึงเหมาะจะใช้เป็น Data Warehouse (LDAP) สำหรับเก็บข้อมูลที่ไม่ต้องถูกแก้ไขบ่อยนัก เช่น Event Logs, Analytical Data, หรือ Time Series Events Data แทนที่จะใช้เป็น Operational Database (OLTP) สำหรับเก็บข้อมูลแบบทั่วไปครับ // อ่านเพิ่มเติม

 


จากที่ใช้งานมา พบว่ามันโหดมาก..
อัดข้อมูลเทเข้าได้รัวๆแทบไม่มีข้อจำกัด
ทำ Query ที่เมื่อก่อนใช้เวลาหลายสิบนาทีได้ในไม่กี่วินาที
จะสั่งทำงานพร้อมกันหลายร้อยรีเควสก็ทำได้เลยไม่ต้องรอคิว
แทบไม่มีรีเควสที่ล้มเหลว ระบบไม่เคยล่ม
คือมันสุดยอดมากอ่ะ 555

 

เออแต่เหมือนจะลืมดูเรื่องราคา.. อ๊ะ..


3) BigQuery — ถูกและดี ?

ราคาค่าใช้งานจาก https://cloud.google.com/bigquery/pricing

อีกปัจจัยหนึ่งที่ทำให้ BigQuery น่าใช้คือประเด็นเรื่องค่าใช้จ่าย โมเดลการคิดเงินของ BigQuery มีแบบ Pay-as-you-go คือค่าใช้จ่ายจะยืดหยุ่นตามการใช้งาน ซึ่งไม่มีขั้นต่ำ โดยจะคำนวณดูจากปัจจัยหลักๆ คือ

  1. ปริมาณข้อมูลทั้งหมดที่มีอยู่ โดยคิด $0.02/GB ต่อเดือน
  2. ปริมาณของข้อมูลที่ถูกนำเข้า โดยคิด $0.05/GB
  3. ปริมาณของข้อมูลทั้งหมดที่ถูกค้นหา โดยคิด $5/TB
    (จากที่เคยใช้งานมา ค่าใช้จ่ายส่วนใหญ่จะไปขึ้นกับส่วนนี้มากที่สุดเกือบ 90%+)

ข้อดีของการคิดราคาแบบนี้คือ การประมาณค่าใช้จ่ายสามารถทำได้ง่ายมาก เนื่องจากไม่มีปัจจัยที่ควบคุมได้ยาก อย่างเช่นการประมาณค่าเครื่องเซิฟเวอร์ ค่าสเกลเครื่องเซิฟเวอร์ หรือค่าซอฟท์แวร์อื่นๆ ทำให้พอต้องการทำ Feature ใหม่ๆ เราสามารถประมาณค่าใช้จ่ายของ Feature นั้น โดยประเมินจาก SQL ที่ใช้ได้เลย ว่าจะใช้ข้อมูลไปเท่าไหร่ในแต่ละครั้ง

จากการคิดราคาแบบนี้ทำให้ BigQuery เป็นตัวเลือกที่ดูคุ้มค่ามากหากข้อมูลที่เรามีมีขนาดใหญ่ แต่ไม่ได้ถูกค้นหาบ่อยนัก หรือต้องการระบบที่ใช้งานง่ายและทำงานเร็ว รวมถึงยังลดค่าใช้จ่ายในการจ้างคนมาดูแลหรือติดตั้งระบบด้วย

ราคานี้อาจจะดูไม่แพงและคุ้มค่า แต่อย่าพึ่งชะล่าใจไป..

หากสั่งวิเคราะห์ข้อมูลขนาด 500GB x 1280 ครั้ง คุณจะโดนเก็บตังเป็นเงินประมาณ 100,000 บาทเศษๆ เท่านั้นเอง..

แต่ถ้าคุณเข้าใจข้อจำกัดและวิธีคิดราคาของ BigQuery — มันก็มีวิธีทำให้เหลือไม่กี่พันบาท

(ซึ่งจะขอพูดถึงในพาร์ทถัดๆไปครับ เพราะยังเขียนไม่เสร็จ ._.)

… to be continued in

 — Part 2/3 : BigQuery – Usage +Constraints + Use Cases

 — Part 3/3 : BigQuery – Costs Optimization


TL;DR

สรุปสั้นๆคือ BigQuery เป็น Data Warehouse ตัวหนึ่งที่สามารถจัดการปัญหาด้าน Hardware, Performance, Maintenance, Monitoring ให้เราได้พอสมควร สิ่งที่เราต้องทำมีแค่เอาข้อมูลเข้า เขียน SQL ไปเรียกใช้ และจ่ายเงิน ทุกปัญหาก็จะหมดไป — จะได้เอาเวลาไปทำสิ่งที่อยากทำ (นอน)

แต่เนื่องจาก BigQuery มีค่าใช้จ่ายค่อนข้างสูงหากไม่ระวังให้ดี แต่ถ้าค่าใช้จ่ายจะสูงขนาดนี้คงเอาไปใช้จริงไม่ได้แน่ๆ ซึ่งในส่วนนี้เราสามารถลดค่าใช้จ่ายลงได้โดยการใช้ Tools อื่นๆ เข้ามาช่วย หรือใช้งานตาม Best Practice ที่ Google ได้ระบุไว้ครับ


ในส่วนของบทความพาร์ทถัดไปเราจะมาเล่าถึงข้อจำกัด การใช้งาน และตัวอย่างการเอาไปประยุกต์ใช้ และแนวทางการลดค่าใช้จ่าย เพื่อให้ BigQuery พร้อมไปใช้จริงบน Production ครับ รอติดตามชมได้ในไม่ช้า (คาดว่า)

ขอบคุณครับ -w-/

SARIN
Software Engineer.
“anything-except-frontend” software/data engineer
@ Cleverse, Thailand.

Also, machine learning enthusiasts and photographer.
Next Article
Solving BigData with BigQuery (2/3) — ลองเล่น
สมัครงาน