สวัสดีครับ สัปดาห์นี้จะมาเล่าต่อกันเรื่องการใช้ Google Cloud Platform ที่บริษัท Credit OK สำหรับสัปดาห์ที่แล้วได้เล่าถึงประวัติศาสตร์การ Deploy Application ต่างๆ ตั้งแต่ Bare Metal ไปจนถึง Cloud Functions ท่านใดสนใจจะกลับไปอ่านบทความก่อนหน้าก็ตามลิงค์ไปได้เลย Server & Application Deployment History ส่วนสัปดาห์นี้ ผมจะขอแนะนำบริการต่าง ที่น่าสนใจบน Google Cloud Platform ทั้งทางฝั่ง Compute, Storage, Database และ Data Analytics
สำหรับ Slide ในงาน Barcamp สามารถดูได้จากที่นี่ครับ
Serverless Big Data Architecture on Google Cloud Platform at Credit OK
บทความชุดนี้ประกอบด้วย 3 episodes ดังนี้
- Server & Application Deployment History
- Introducing to Google Cloud Platform Services
- How Credit OK Utilize Google Cloud Platform as a Serverless Big Data Service
EP 2 : Introducing to Google Cloud Platform Services
ก่อนจะเริ่มผมขอบอกก่อนว่าผมไม่ได้เป็นตัวแทนจำหน่าย Google Cloud Platform แต่อย่างใด แล้วก็ไม่ได้เป็นผู้เชี่ยวชาญด้วย เป็นเพียงผู้ใช้ทั่วไปที่ได้มีโอกาสได้เข้าไปใช้งานเครื่องมือต่างๆ แล้วรู้สึกว่าถูกใจ ก็เลยอยากจะมาแบ่งปันประสบการณ์ให้ฟังกันว่า มันมีอะไรน่าสนใจบ้าง
GCP ถึงแม้จะมาหลังจากชาวบ้าน แต่ผมรู้สึกว่ามาท่าแปลกกว่าชาวบ้าน คือพยายามทำให้ Service ต่างๆ มันเป็นเครื่องมือจริงๆ ไม่ใช่แค่การตั้ง Server แล้วมีบริการครอบข้างบนให้อีกที (Managed Service) ด้วยเหตุผลนี้ทำให้การใช้งานแทบไม่ต้องเป็นกังวลเรื่องการต้องมาตั้งเครื่องเผื่อ Scale ใดๆ เลย ถ้าเลือกบริการที่เป็นแบบ Serviceless ใช้เท่าไหร่ก็จ่ายกันไปเท่านั้น
เครื่องมือหลายๆ ตัวอาจจะยังไม่เยอะอย่างคู่แข่ง แต่ว่าก็เพียงพอแล้วสำหรับการใช้งานในส่วนใหญ่ แล้วก็มีฟีเจอร์ มีบริการเพิ่มเติมขึ้นมาเรื่อยๆ สามารถเข้าไปดูบริการทั้งหมดของ GCP ได้จากหน้า Products and Services
จากนี้ผมจะขอแนะนำบริการบางส่วนที่ผมเข้าใจและพอเล่าให้ฟังได้บ้างว่ามันคืออะไร เพื่อมาทำความรู้จักกัน ซึ่งก็จะขอแบ่งออกมา 3 กลุ่ม ได้แก่ Computing, Storages & Databases, Data Analytics
GCP Computing
มาเริ่มกันที่ฝั่ง Computing ก่อน มันคือกลุ่มเครื่องมือที่เอาไว้ประมวลผลใช้งานกับ Application ต่างๆ ของเรานั่นเอง
Compute Engine ก็คือเครื่อง VM หรือบริการแบบ IaaS นั่นเอง เราสามารถเข้าไปเลือกได้ว่าอยากจะใช้เครื่อง spec เท่าไหร่ ใช้ Image อะไร (นอกจาก Linux แล้วยังมี Windows ให้เลือกด้วย) ตั้งเครื่องเสร็จก็ Remote SSH เข้าไปใช้ได้เลย ความเด็ดของ Compute Engine บน GCP คือ มันมี Web Terminal ให้ใช้ด้วย คือสามารถ Remote SSH เข้าไปใช้งานได้ผ่านทาง Web Browser เลย (เจ้าอื่นก็มีแหละ 555)
ถ้าใครอยากเห็นหน้าตานิดๆ หน่อยๆ ผมมี Blog เคยเขียนไว้เรื่อง ติดตั้ง Open VPN Server บน Google Cloud Platform ใช้งานแบบฟรีๆ สามารถตามเข้าไปดูตัวอย่างหน้าตากันได้
App Engine (GAE) ต่อมาเป็นบริการแบบ PaaS ถ้าผมเข้าใจไม่ผิดมันเป็นบริการแรกที่ Google เปิดให้ใช้ เปิดมาก่อนที่จะมี GCP เสียอีก สำหรับใครที่เคยใช้ Heroku น่าจะคุ้นเคยกับบริการแบบนี้ ก็คือ Google จะมี Image สำหรับ Platform ต่างๆ มาให้เราเลือกว่าพัฒนาด้วยภาษาอะไร ในเว็บตอนนี้เห็นมี Java, Python, PHP, Go, Node.js สำหรับ Standard Envionment ทีนี้เราก็พัฒนา Application ของเราไป แล้วก็จับไปวางบน env ที่ Google ให้มา แล้วก็ Deploy เลย แล้วก็มีบริการอีกแบบก็คือ Flexible Environment สำหรับอันนี้เราสามารถสร้าง Docker Image ที่ Compat กับ App Engine ขึ้นมาใช้เองได้ ทำให้ภาษาที่ใช้งานไม่จำกัดแบบ Standard Env อีกต่อไป
ข้อดีของ App Engine ก็คือ เราสามารถพัฒนาแอปขึ้นมาใช้งานได้เลย โดยไม่ต้องเป็นห่วงเรื่องการต้องไปลง Dependency เองแบบ Compute Engine นอกจากนั้นมันยังจัดการเรื่อง Auto Scale ต่างๆ ให้ด้วย ถ้า Node ไม่พอ GCP ก็จะทำการ Spawn เครื่องขึ้นมาเพิ่มให้พร้อมใช้บริการโดยอัตโนมัติ
Kubernetes Engine (GKE) อันนี้คือว่าที่พระเอกในอนาคตอันใกล้ สำหรับใครที่ใช้งาน Kubernetes เป็น แล้วลองได้เคย Deploy Kubernetes ขึ้นมาใช้งาน น่าจะเข้าใจถึงความยากลำบากที่ได้พบเจอจนไม่ต้องบรรยายให้มากความ GKE คือบริการสร้าง Cluster Kubernetes ให้เพียงคลิกแค่ไม่กี่ครั้ง มันเป็น Managed Service ที่จะ Spawn เครื่อง GCE ขึ้นมา หน้าที่ของเราก็แค่ใช้ kubectl ต่อเข้าไปใช้งาน ทรัพยากรต่างๆ ไม่ว่าจะเป็น Persistent Volumn, Configuration, Network, Public IP ต่างๆ ก็สามารถสั่งให้มัน Auto Deploy ให้โดยอัตโนมัติ ผมลองไปใช้งานแล้ว โอโห ซาร่ามาก นอกจากนั้นยังเพิ่มลด Node ของ Cluster ได้ง่ายๆ ผ่านทาง GUI เช่นกัน (เข้าใจว่าน่าจะทำ Automation ได้ด้วย) การดู Resource ต่างๆ ก็สามารถเปิดดูภาพรวมได้เช่นกัน
แต่ก่อนจะผ่านตัวนี้ไป ผมอยากบอกว่า Kubernetes ไม่ได้เหมาะกับทุกคน ถ้าโปรเจกต์คุณเล็กๆ ไม่ซับซ้อนอะไร แนะนำว่าให้ศึกษาเอาไว้ แต่อย่าเพิ่งมาใช้ เพราะทั้งเรื่อง Learning Curve และการต้องลงทุนลงแรงในการคอยดูแลความเรียบร้อย กว่าจะ config ขึ้นมาได้ต้องมีความรู้ความเข้าใจพอสมควร แต่ถ้างานช้าง ทีมใหญ่ คนพร้อม ก็เป็นตัวเรื่องที่ดีที่จะทำ Automation กันทางนี้ เนื่องจากมันจะช่วยให้จัดการเรื่อง infra ได้สะดวกขึ้นมาก
Cloud Functions (GCF) หากจะให้พูดถึงความสะดวก ใช้งานง่าย ก็คงต้องยกให้เจ้าตัวนี้เลย (มันจะคล้ายๆ กับ AWS Lambda นั่นเอง) แค่เอา Code ไปวางแล้วก็ใช้งานได้เลย ไม่มีการมาตั้ง Node อะไรใดๆ ทั้งสิ้น บริการนี้เป็นแบบ Stateless นะครับ คือไม่มีการเก็บสถานะของผู้ที่ Request เข้ามา รันแล้วก็จบไป เอาไว้ทำงาน Computing ที่ทำแล้วจบไปได้ดีมากๆ
หลักการทำงานของ GCF คือ หลังจาก Deploy ไปแล้ว GCP เอา Code เราไปแปะกับ Image ของ GCF แล้วเก็บเอาไว้รัน แล้วก็ Deploy ให้เราลงบน Instance ที่เราไม่ต้องรู้อยู่ว่ามันมี ถ้ามีการเรียกใช้งานเข้ามา มันก็จะวิ่งเข้า Instance นั้นนั่นเอง ความเด็ดและความซับซ้อนมันอยู่ที่ว่า เวลาเราไม่ได้เรียกใช้งานถึงระยะหนึ่ง Instance นั้นจะถูกทำลายออกไป แต่ Image ที่เราสร้างไว้ยังอยู่ พอมีผู้ใช้เรียกใช้งาน มันก็จะ Hold Request เอาไว้ก่อน แล้วก็ทำการ Deploy Instance ขึ้นมารับโหลด กระบวนการนี้เรียกว่า Cold Start ซึ่งจะใช้เวลานานกว่าปรกติ (ถ้าเขียนดีๆ มันจะไม่เกิน 2-5 วินาที) นอกจากนั้นเวลามี Request เข้ามาพร้อมๆ กัน มันจะให้ one request per one instance เท่านั้น ถ้ามีคนเข้ามารันพร้อมกัน 10 คน มันก็จะ spawn ขึ้นมา 10 instances แยกกัน ส่วน Instance ที่ทำงานเสร็จแล้วว่างอยู่ ก็จะรอรับ Request สำหรับ user ต่อไป เพื่อที่ว่าจะไม่ต้องกลับไปสู่การ cold start ให้เสียเวลา ก่อนที่ถ้าไม่มีการใช้งานนานถึงเวลาหนึ่งมันก็จะปิดตัวเองไป
ส่วนตัวผมคิดว่านี่เป็นบริการในดวงใจเลย เพราะว่ามันเป็นการเรียกใช้ทรัพยากรที่มีประสิทธิภาพสูงมาก คือปรกติเวลาเราตั้งเครื่อง ไม่ว่าจะใช้หรือไม่ใช้ เราก็ต้องจ่ายเงินค่าจอง แล้วเวลาเครื่องไม่ได้ใช้ ผู้ใช้คนอื่นๆ ก็เข้ามาใช้งานทรัพยากรที่เราจองไว้ก็ไม่ได้อีก แต่ถ้าบริการจัดการแบบนี้ มันจะเป็นภาพเหมือนเรามี Resource Pool ก้อนใหญ่ๆ 1 ก้อน แล้วทุกคนไปแบ่งชิ้นเล็กๆ ขึ้นมาใช้งาน ใครจะใช้ก็ใช้ ใครไม่ใช้ก็คืนกลับลงไป แล้วการคิดเงินก็คิดตามการใช้งานจริงๆ เป็นครั้ง และเวลา ที่เรียกใช้งาน ทำให้เหมาะมากสำหรับคนที่ไม่มีเวลามาดูแล Infrastrucure
CAP Theorem
บทแทรก ต่อมาก็จะเป็นเรื่องของบริการเก็บข้อมูลบน GCP ซึ่งก่อนจะไปต่อ ผมจะเล่าถึงทฤษฎีที่ใช้ในการเลือก DB ให้ถูกประเภทสักหน่อย เพราะมันเป็นความรู้ที่สำคัญมาก เรียกว่า DB Engineer ทุกคนจำเป็นจะต้องรู้จัก (ความจริงต้องเล่าเรื่องประเภทของ DB อีก โดยเฉพาะตระกูล NoSQL เอาไว้จะเขียนแยกออกมาให้ละกันครับ)
CAP Theorem กล่าวไว้ว่า DB ใดๆ บนโลกใบนี้ จะต้องเลือกว่าตนเองจะเป็นเลิศในด้านใดได้ 2 ด้าน แล้วจะยอมเสียสละด้านใด 1 ด้าน ซึ่งจะมี 3 ด้านนั้น มีดังนี้
C (Consistency) คุณสมบัติของการเป็นชิ้นเดียวกัน (พูดแล้วงง) ลองจินตนาการถึงการทำ Transaction โอนเงิน เราจะต้อง Block ไม่ให้คนมากกว่า 1 คน ทำธุรกรรมกับบัญชีๆ ใดๆ พร้อมกัน ไม่เช่นนั้นจะเกิดปัญหาเรื่อง Race Condition ส่งผลให้การคำนวณออกมาผิดพลาดไปจากสิ่งที่ควรจะเป็น DB ที่มีคุณสมบัตินี้ จะสามารถทำการเขียนอ่านข้อมูลแบบ Transaction ได้อย่างปลอดภัย
A (Availability) คุณสมบัติของการใช้งาน ไม่มีใครมาขัดขาตอนฉันจะใช้งาน เรียกข้อมูลไป ต้องได้ออกมาทันที ไม่มีใครมาบอกว่า เฮ้ย รอก่อน เดี๋ยวค่อยกลับมาเอาใหม่
P (Partition Tolerance) คุณสมบัติของการแบ่งข้อมูลกระจายไปเก็บบนหลายๆ เครื่อง ช่วยลดโหลดในแต่ละเครื่อง ช่วยกันเก็บ ช่วยกันทำงาน
เลือก CA เสีย P ถ้าต้องการรักษา C ไว้ จะทำได้ง่ายถ้า DB อยู่บนเครื่องเดียว มีทางเข้าทางออกทางเดียว แต่มันแทบจะเป็นไปไม่ได้เลยถ้า DB ของเรากระจายข้อมูลไปบนหลายเครื่อง แล้วจะรักษา C เอาไว้ได้ เพราะทุกครั้งที่มีการเขียนอะไร จะต้องแจ้งให้ทุกเครื่องที่อยู่ในวงหยุดทำการอ่านหรือเขียนเสียก่อน เมื่อเขียนเสร็จแล้วจึงให้คนอื่นทำงานต่อได้ แล้วถ้ามี DB ช่วยกันทำงานเป็นร้อยเป็นพันเครื่อง การจะเขียนข้อมูลทีต้องยิ่งไปบอกเครื่องทั้ง Cluster แบบนี้จึงเป็นไม่ได้แน่นอน
เลือก CP เสีย A จากข้อข้างบนที่ว่า ถ้าต้องการจะเก็บข้อมูลบนหลายๆ เครื่อง แล้วอยากจะรักษา C เอาไว้ให้ได้ คุณก็จำเป็นจะต้องยอม Block ทุกเครื่องใน Cluster ให้คนที่จะทำ Transaction ทำให้เรียบร้อยซะก่อน ทีละรายๆ ในเมื่อมีคนถูก Block ไม่สามารถเข้าใช้งานได้ทันที จึงทำให้เสีย A ไปนั่นเอง
เลือก AP เสีย C เมื่อ DB ของคุณเลือกที่จะให้หลายเครื่องเข้ามาช่วยกระจายโหลดได้อย่างเต็มประสิทธิภาพ นอกจากนั้นยังบอกด้วยว่าข้อมูลต้องพร้อมใช้งานตลอด ดังนั้นการอ่านการเขียนจะต้องไม่เกิด Blocking ระหว่าง Node จึงเป็นไปไม่ได้เลยที่จะทำ Transaction บน DB ประเภทนี้ เพราะการรักษา C คือการที่จะต้อง Blocking
GCP STORAGES & DATABASES
เรากลับมาที่ Google Cloud Platform กันต่อ ผมขอแบ่ง DB Services เป็น 2 กลุ่ม คือ Manged Services (ต้องตั้ง Node เอง ที่เหลือ GCP ดูแล) กับ Serverless (GCP ดูแลให้ทุกอย่าง เข้าไปใช้งานได้เลย)
Managed Services
Cloud Bigtable เป็น DB ชื่อดัง ที่คนในวงการน่าจะเคยได้ยินกันมานาน (เจ้านี่คือ HBase ใน Hadoop Stack) มันคือ DB ที่ Google ใช้ในบริการ Search Engine นั่นเอง เป็น Columnar Database เป็นประเภท AP มีความเป็นเลิศเรื่องการกระจายโหลดไปบนหลายๆ เครื่อง พร้อมให้บริการทันใจตลอดเวลา เพราะว่าบริการอย่าง Google Search ไม่จำเป็นจะต้องมีการทำงานเป็น Transaction ดังนั้นแล้ว DB ตัวนี้จึงเหมาะสมอย่างยิ่งกับโจทย์ที่กล่าวมา
การจะใช้ Cloud Bigtable นั้นเราจะต้องตั้งเครื่องอย่างน้อย 3 เครื่อง แล้วก็จะได้ Cluster ของ Cloud Bigtable ขึ้นมา ซึ่งสามารถเข้าใช้งานได้ผ่านทาง HBase API เลย
Cloud SQL อยากจะใช้ MySQL/PgSQL แต่ไม่อยาก Config Cluster ขึ้นมา ก็มาใช้ Cloud SQL เลย มันคือ Cluster ของ MySQL ที่ตั้งขึ้นมาพร้อมให้ใช้งาน มีการอัพเดท มีการทำ Replica อะไรให้โดยอัตโนมัติ หน้าที่ของเราก็แค่ไปกดสร้าง บอกประเภทงานที่จะใช้ (dev,test,prod) แล้วก็เอาไปใช้งานได้เลย
Cloud Spanners เป็น RDBMS กลายร่าง เพิ่มคุณสมบัติเรื่อง Scalability ทำให้สามารถขยายทางแนวกว้างได้เหมือน DB แบบ P แต่ยังรักษาความเป็น CA เอาไว้ได้ ซึ่งความจริงมันเป็น DB แบบ CA นะครับ ผมเองก็ยังไม่เคยได้ใช้ Cloud Spanner แต่รู้สึกว่ามันเป็น DB ที่น่าสนใจมากก็เลยขอเอามาใส่ไว้ เผื่อใครจะมีโจทย์ต้องใช้ก็ไปลองดู
Cloud Memorystore สิ่งที่ขาดไม่ได้เลยสำหรับ Application ที่ดีก็คือระบบการทำ Caching เจ้านี่เป็น Manage Service ของ Redis นั่นเอง เพียงแค่กดตั้งเครื่องที่ต้องการแล้วก็มี Redis ขึ้นมาพร้อมใช้งานได้ทันที
Serverless
Persistent Disk ความจริงเจ้านี่ไม่ควรจะเอามาใส่ แต่ก็ต้องเอามาใส่เพราะถือเป็นบริการเก็บข้อมูลเช่นกัน มันคือ Disk ที่เราเอาไว้ใช้เวลาตั้งเครื่อง VM ขึ้นมา ความเจ๋งก็คือเราสามารถทำ Snapshot สามารถ Clone กดย้าย Disk ไปเสียบ GCE เครื่องโน่นเครื่องนี้ได้ การจะย้ายเครื่องจากซีกโลกหนึ่งไปสู่อีกซีกโลกหนึ่งจำทำได้ง่ายดายเพียงแค่ย้าย Persistent Disk ข้ามมาเสียบ VM ของเครื่องใหม่ ก็จะพร้อมใช้งานทันที
Cloud Storage (GCS) ตัวนี้คือ Object Storage แบบเดียวกับ AWS S3 สมัยก่อนผมสงสัยมากจะมีมาทำไมให้วุ่นวาย เก็บใน Disk ก็ได้นิ พอโตขึ้นเห็นว่าไฟล์หนึ่งๆ มันถูกใช้งานโดย Services หลายตัว นอกจากนั้นมันอาจมีการอ่านเขียนแบบกระจายศูนย์ จึงได้เข้าใจ สำหรับคนที่มาจาก Hadoop อันนี้ก็จะคล้ายๆ กับ HDFS นั่นเอง สร้าง Bucket ขึ้นมา จะเก็บอะไรก็เก็บ สั่งเขียน สั่งอ่าน ผ่านทาง API นอกจากนั้น เวลาที่มีไฟล์ใส่เข้ามา ยังสามารถสั่งให้มันไป trigger cloud function ให้มัน process ไฟล์ที่เพิ่งใส่เข้ามาได้โดยอัตโนมัติอีกด้วย ที่ บ. เอามาใช้เก็บไฟล์ Raw CSV ก่อนจะส่งเข้าไปใน Big Query
Cloud Datastore หากอยากจะหา High Performance Database สักตัวที่เป็น AP แล้วไม่อยากตั้ง Node เองแบบ Big Table ก็ต้องตัวนี้เนี่ยแหละ ผมลองใช้งานแล้วมีความรู้สึกว่าเจ้านี่เหมือน Bigtable กลายร่างมาเป็น Serverless พร้อมให้ใช้งาน แต่มี API Interface ของตัวเอง เก็บข้อมูลลงไปได้มหาศาล จ่ายเงินค่าเก็บข้อมูลและเวลาเขียนกับเรียกใช้ข้อมูลเท่านั้นเลย (ซึ่งถ้าใช้งานหนักๆ ก็ราคาไม่ได้ถูก)
ตัวนี้อาจจะไม่ค่อยเหมาะกับงาน Big Data สักเท่าไหร่ เพราะว่าราคาการเรียกใช้ข้อมูลค่อนข้างสูง แล้วทำงาน Analytics แทบจะไม่ได้เลย แต่ถ้าเอามาใช้กับ Application แค่เรื่องเก็บข้อมูล ต้องการ Concurrentcy สูงๆ ผมว่ามันเหมาะมากเลยแหละ
GCP Data Analytics Tools
สุดท้ายคือบริการฝั่ง Data Analytics โดยเครื่องมีทางฝั่งนี้ก็จะแบ่งเป็น 2 ส่วน ก็คือการทำ Data Pipeline (ย้ายจากแหล่งหนึ่งไปอีกแหล่งหนึ่ง ETL) กับการทำ Analytics สำหรับวิเคราะห์ข้อมูล
Pipeline
Cloud Pub/Sub เป็นบริการเอาไว้ Ingest Data ประมาณว่าเอาไว้รับข้อมูล โดยอิงตาม Event คือให้มันไป Subscribe Event เอาไว้ ทีนี้เวลามีคนส่งเข้ามาที่ Event ดังกล่าว มันก็จะไปปลุกขึ้นมาทำงาน ตัวนี้ผมไม่ได้ใช้งานตรงๆ แต่ใช้ผ่าน Tools ตัวอื่นๆ ถ้าผมเข้าใจไม่ผิดมันจะคล้ายๆ กับ Apache Kafka ที่กำลังดังเป็นกระแสอยู่ในทุกวันนี้ แต่เจ้านี่จะดูเฉพาะส่วนของ Pub/Sub เท่านั้น ไม่ได้มีตัว Process อะไรในตัว ค่อนข้างสำคัญมากสำหรับการทำ Data Streaming
Dataflow เป็นบริการเอาไว้ทำ Dataflow ตามชื่อ คือมันจะใช้งานเป็นตัว Process ต่อกับ Pub/Sub ซะส่วนใหญ่ เพียงสร้าง Job ขึ้นมา สมมุติว่าเป็นงาน Data Cleansing แล้วก็จับมันไป subscribe ไว้กับ Service อื่น อย่างเช่น Pub/Sub หรือ GCS เมื่อเกิด Event ขึ้น มันก็จะรันคำสั่งตามที่เราเขียนเอาไว้ (ตัวนี้เขียนเป็น Code นะครับ ไม่ใช่ GUI ลากๆ ทีแรกผมนึกว่าจะง่าย 555)
Dataprep ถ้าหากรู้สึกว่าการทำ Automated Data Pipeline เป็นเรื่องยาก ขอแนะนำทุกท่านให้รู้จักกับ Dataprep เมื่อการทำ Data Pipeline การทำ Data Cleansing ขึ้นมาอยู่บน GUI สามารถเขียนสิ่งที่ต้องการให้มันทำผ่านทาง GUI ชีวิตก็ง่ายไปหมด ซึ่งความจริงแล้ว สิ่งที่มันทำก็คือมันไปสร้าง Job ให้กับ Pub/Sub และ Dataflow นั่นเอง
Analytics
Big Query ต่อมาเป็นพระเอกของเราในการทำ Data Analytics ก็คือ Big Query นั่นเอง สิ่งที่ Big Query ทำก็คือ ความสามารถในการประมวลผลข้อมูลขนาดใหญ่มากๆๆ ผ่านทางภาษา SQL อารมณ์เหมือนเราใช้ MySQL เนี่ยแหละ ก็คือจะต้องมีการสร้าง Table เขียน SQL แล้วก็สั่งให้มันรัน แต่การรันบน Big Query นั้นมันแตกงานไปรันบนเครื่องหลายๆ เครื่องพร้อมๆ กัน โดยเครื่องเล่านั้นเราไม่ต้องไปจัดการ ทางฝั่ง GCP จะเป็นคนสร้างขึ้นมารันให้เอง (ถ้าใครเคยใช้ Stack Hadoop มาก่อน มันจะคล้ายๆ Hive นั่นเอง ต่างกันตรงที่ Node ที่ใช้รันตรงนี้เราไม่ต้องสร้างเผื่อเอาไว้ก่อน) สุดท้ายคือเราสามารถ Process ข้อมูลระดับ TB ได้ในการรันเพียงไม่กี่วินาทีเท่านั้น และไม่ต้องจับเครื่องแม้แต่เครื่องเดียว
แต่ว่า Big Query ไม่ใช่ Database ที่เอาไว้ทำ Real-time analysis คือมันคิดเงินตามปริมาณข้อมูลที่เราใช้ Query แล้วมันก็ไม่ได้มีการทำ Index เพื่อเพิ่ม Performance อย่าง DB ทั่วไป ทุกครั้งที่รันจะต้องโหลดข้อมูลเข้าไปประมวลผล แล้วก็รันแบบ Map Reduce ดังนั้นความเร็วนั้นมันจะสู้ Online DB ทั่วไปไม่ได้ แต่ถ้าเราจะต้องสร้าง DB มาเก็บข้อมูลระดับ TB แล้วมา Query วันละครั้งสองครั้ง แบบนั้นก็จะเปลืองโดยใช่เหตุ นี่คือโจทย์ที่ Big Query ออกแบบมาแก้นั่นเอง ข้อมูลใหญ่ ประมวลผลได้ ไม่ต้องตั้ง Server เหมาะกับงานแบบ Batch แล้วก็เก็บ Result เอาไว้ใช้งานในภายหลัง จะให้ดีกว่านั้นคือ เก็บ Result ไว้บน Online Database หลังจากประมวลผลเสร็จ แล้วจะได้ไม่ต้องเสียเงินค่า Big Query รัวๆ
Visualization
ส่วนสุดท้ายคือการแสดงข้อมูลให้อยู่ในรูปแบบที่อ่านเข้าใจได้ง่าย
Data Studio เป็นเครื่องมือเอาไว้ทำ Dashboard แสดงข้อมูลออกมาสวยๆ อารมณ์คล้ายๆ Tableau แต่ว่าความสามารถยังห่างไกลนัก อย่างไรก็ดี มันมีดีที่ใช้งานฟรี แล้วสามารถดึงข้อมูลออกมาได้จากบริการของ Google ไม่ว่าจะเป็น Spreadsheet, Google Ads, Google Analytics และที่สำคัญก็คือจาก Big Query นั่นเอง
Stackdriver บริการตัวสุดท้ายที่ไม่เข้ากับใคร Logo ก็ไม่เหมือนชาวบ้าน แต่ผมขอแนะนำภูมิใจนำเสนอ คือบริการสำหรับการเก็บ Log และมีความสำคัญมากสำหรับการทำ Serverless เพราะว่า Serverless Application นั้นไม่มี Server ประจำของตัวเอง เวลามีปัญหาขึ้นจึงไม่สามารถ Remote เข้าไปดูได้โดยตรง (ต่อให้มี Server ก็ควรใช้ Logging Service อยุ่ดีเพื่อความสะดวกในการ Monitor) การทำ Logging ไว้เช็คเวลาโปรแกรมมีปัญหาจึงสำคัญมากกก และ Stackdriver ก็ทำหน้าที่นี้ดีมาก แล้วยังสามารถทำออกมาเป็นกราฟเพื่อใช้ดูสถานะได้ด้วยนะ
ขอโชว์หน่อย อันนี้เป็นโปรเจกต์เล็กๆ ผมเอาไว้ Monitor เน็ตที่บ้านว่าล่มกี่โมงบ้าง พอดีมีช่วงนึงเน็ตล่มบ่อยก็เลยสั่งให้ Raspberry Pi ที่บ้าน และเร้าเตอร์ Ping ชื่อตัวเองไปหา Stack Driver ทุกนาที แล้วทำ Metrics ให้สามารถพล็อตออกมาเป็นกราฟสวยๆ ได้ ดังนั้นจะไฟดับ เน็ตหลุด กลับมาใช้ได้เมื่อไหร่ ก็มองเห็นหมด
เอาล่ะครับ สำหรับตอนนี้ผมขอหยุดไว้เท่านี้ก่อน สำหรับท่านใดที่มีคำถามหรือข้อเสนอแนะ สามารถ Comment พูดคุยกันได้ข้างล่างเลย แล้วตอนหน้าจะมาเล่าให้ฟังกันต่อว่า ที่ Credit OK เราทำ Big Data Pipelines & Analytics ด้วย Google Cloud Platform แบบ Serviceless กันอย่างไร ไปต่อกันได้เลย How Credit OK Utilize Google Cloud Platform as a Serverless Big Data Service
