ไม่มีคำตอบที่ถูกต้องสมบูรณ์ มีเพียงข้อแลกเปลี่ยนเท่านั้น [...] แต่คุณก็ต้องพยายามหาข้อแลกเปลี่ยนที่ดีที่สุดเท่าที่จะทำได้ และนั่นคือสิ่งที่คุณหวังได้มากที่สุด

Thomas Sowell , ให้สัมภาษณ์กับ Fred Barnes (2005)

ข้อมูล เป็นศูนย์กลางของการพัฒนาแอปพลิเคชันในปัจจุบัน ไม่ว่าจะเป็นเว็บและ mobile apps, software as a service (SaaS) และ cloud services การจัดเก็บข้อมูลของผู้ใช้จำนวนมากในโครงสร้างพื้นฐานข้อมูลบนเซิร์ฟเวอร์ที่ใช้ร่วมกันกลายเป็นเรื่องปกติ ข้อมูลจากกิจกรรมของผู้ใช้ ธุรกรรมทางธุรกิจ อุปกรณ์ และเซนเซอร์ ล้วนต้องถูกจัดเก็บและนำมาวิเคราะห์ เมื่อผู้ใช้โต้ตอบกับแอปพลิเคชัน พวกเขาทั้งอ่านข้อมูลที่ถูกจัดเก็บและสร้างข้อมูลเพิ่มเติมขึ้นไปพร้อมกัน

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

เราเรียกแอปพลิเคชันว่า data-intensive หากการจัดการข้อมูลเป็นหนึ่งในความท้าทายหลักในการพัฒนาแอปพลิเคชัน [ 1 ] ส่วนระบบ compute-intensive ความท้าทายคือการทำให้การคำนวณขนาดใหญ่ทำงานแบบขนานได้ แต่ใน data-intensive applications เรามักจะกังวล เรื่องต่างๆ เช่น การจัดเก็บและประมวลผลข้อมูลปริมาณมาก การจัดการการเปลี่ยนแปลงของข้อมูล การรักษาความสอดคล้อง (consistency) ของข้อมูลเมื่อเกิดความล้มเหลวและมีการทำงานพร้อมกัน และการทำให้แน่ใจว่าบริการต่างๆ พร้อมใช้งานสูง

แอปพลิเคชันประเภทนี้มักถูกสร้างขึ้นจาก building blocks มาตรฐานที่ให้ฟังก์ชันการทำงานที่จำเป็นโดยทั่วไป ตัวอย่างเช่น หลายแอปพลิเคชันจำเป็นต้องทำสิ่งต่อไปนี้:

• จัดเก็บข้อมูลเพื่อให้ตัวเองหรือแอปพลิเคชันอื่นสามารถค้นหาได้ในภายหลัง ( databases )

• จำผลลัพธ์ของงานที่ใช้ทรัพยากรมาก เพื่อเพิ่มความเร็วในการอ่าน ( caches )

• ให้ผู้ใช้ค้นหาข้อมูลด้วยคำสำคัญหรือกรองข้อมูลในรูปแบบต่างๆ ( search indexes )

• จัดการ events และการเปลี่ยนแปลงข้อมูลทันทีที่เกิดขึ้น ( stream processing )

• ประมวลผลข้อมูลสะสมปริมาณมากเป็นระยะ ( batch processing )

ในการสร้างแอปพลิเคชัน เรามักจะนำระบบซอฟต์แวร์หรือบริการหลายๆ ตัว เช่น databases หรือ APIs มาประกอบเข้าด้วยกันด้วย application code ถ้าใช้งานตรงตามที่ data systems ออกแบบมา ก็อาจทำได้ไม่ยากนัก

อย่างไรก็ตาม เมื่อแอปพลิเคชันของคุณมีเป้าหมายใหญ่ขึ้น ความท้าทายก็ตามมา มี database systems มากมายที่มีคุณลักษณะแตกต่างกัน เหมาะกับวัตถุประสงค์ที่แตกต่างกัน— คุณจะเลือกใช้อันไหนดี? มีวิธีการต่างๆ มากมายในการทำ caching, หลายวิธีในการสร้าง search indexes และอื่นๆ—คุณจะประเมิน trade-off (ข้อแลกเปลี่ยน) ของมันอย่างไร? คุณต้องหาว่าเครื่องมือและแนวทางใดเหมาะสมที่สุดสำหรับงานที่ทำอยู่ และการรวมเครื่องมือเข้าด้วยกันอาจเป็นเรื่องยากเมื่อคุณต้องการทำสิ่งที่เครื่องมือเดียวไม่สามารถทำได้

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

เราจะเริ่มจากดูว่าองค์กรยุคปัจจุบันใช้ข้อมูลกันอย่างไรโดยทั่วไป แนวคิดหลายอย่างที่นี่มีต้นกำเนิดมาจาก enterprise software (คือ ความต้องการซอฟต์แวร์และแนวปฏิบัติทางวิศวกรรมขององค์กรขนาดใหญ่ เช่น บริษัทใหญ่ๆ และรัฐบาล) เพราะในอดีต มีเพียงองค์กรขนาดใหญ่เท่านั้นที่มีข้อมูลปริมาณมากที่ต้องใช้โซลูชันทางเทคนิคที่ซับซ้อน หากปริมาณข้อมูลของคุณน้อยพอ คุณก็แค่เก็บไว้ใน spreadsheet! แต่ในช่วงหลังนี้ บริษัทขนาดเล็กและ startup ก็เริ่มจัดการข้อมูลปริมาณมากและสร้าง data-intensive systems กันมากขึ้น

หนึ่งในความท้าทายหลักของ data systems คือคนแต่ละกลุ่มต้องการทำสิ่งที่แตกต่างกันมากกับข้อมูล ถ้าคุณทำงานในบริษัท คุณและทีมของคุณจะมีลำดับความสำคัญชุดหนึ่ง ในขณะที่อีกทีมอาจมีเป้าหมายที่แตกต่างกันโดยสิ้นเชิง แม้ว่าคุณอาจจะทำงานกับชุดข้อมูลเดียวกัน! ยิ่งไปกว่านั้น เป้าหมายเหล่านั้นอาจไม่ถูกกล่าวถึงอย่างชัดเจน ซึ่งอาจนำไปสู่ความเข้าใจผิดและความไม่ลงรอยกัน เกี่ยวกับแนวทางที่ถูกต้อง

เพื่อช่วยให้คุณเข้าใจตัวเลือกต่างๆ บทนี้จะเปรียบเทียบหลายแนวคิดและสำรวจ trade-off ของมัน เราจะพิจารณาหัวข้อต่อไปนี้:

• ความแตกต่างระหว่าง operational และ analytical systems ( "Operational Versus Analytical Systems" )

• ข้อดีและข้อเสียของ cloud services และ self-hosted systems ( "Cloud Versus Self-Hosting" )

• เมื่อใดควรย้ายจาก single-node systems ไปยัง distributed systems ( "Distributed Versus Single-Node Systems" )

• การสร้างสมดุลระหว่างความต้องการของธุรกิจและสิทธิของผู้ใช้ ( "Data Systems, Law, and Society" )

บทนี้ยังนิยามคำศัพท์ที่คุณจะต้องใช้ในส่วนที่เหลือของหนังสืออีกด้วย

Terminology: Frontends and Backends (คำศัพท์: Frontend และ Backend)

สิ่งที่เราจะพูดถึงในหนังสือเล่มนี้ส่วนใหญ่เกี่ยวข้องกับ backend development เพื่ออธิบายคำศัพท์นี้: สำหรับเว็บแอปพลิเคชัน โค้ดฝั่ง client-side (ที่ทำงานในเว็บเบราว์เซอร์) เรียกว่า frontend และโค้ดฝั่ง server-side ที่จัดการคำขอของผู้ใช้เรียกว่า backend Mobile apps มีลักษณะคล้าย frontend ตรงที่ให้ user interfaces ซึ่งมักจะสื่อสารผ่านอินเทอร์เน็ต กับ backend ฝั่ง server บางครั้ง frontend จัดการข้อมูลในเครื่องบนอุปกรณ์ของผู้ใช้ [ 2 ] แต่ความท้าทายด้านโครงสร้างพื้นฐานข้อมูลที่ใหญ่ที่สุดมักอยู่ที่ backend: frontend ต้องจัดการข้อมูลของผู้ใช้เพียงคนเดียว ส่วน backend จัดการข้อมูลในนามของ ผู้ใช้ทุกคน

backend service มักจะเข้าถึงได้ผ่าน HTTP (หรือบางครั้ง WebSocket); โดยทั่วไปประกอบด้วย application code ที่อ่านและเขียนข้อมูลใน databases หนึ่งตัวขึ้นไป และบางครั้งก็เชื่อมต่อกับ data systems เพิ่มเติม เช่น caches หรือ message queues (ซึ่งเราอาจเรียกรวมกันว่า data infrastructure ) application code มักจะเป็น stateless (คือ เมื่อจัดการ HTTP request เสร็จ มันจะลืมทุกอย่างเกี่ยวกับ request นั้น) และข้อมูลใดๆ ที่ต้องคงอยู่จาก request หนึ่งไปยังอีก request หนึ่งต้องถูกจัดเก็บไว้ ที่ฝั่ง client หรือใน server-side data infrastructure

Operational Versus Analytical Systems (ระบบงานปฏิบัติการเทียบกับระบบวิเคราะห์)

ถ้า คุณทำงานเกี่ยวกับ data systems ในองค์กร คุณมักจะพบกับคนหลายประเภทที่ทำงานกับข้อมูล ประเภทแรกคือ backend engineers ที่สร้าง services สำหรับจัดการ requests การอ่านและอัปเดตข้อมูล services เหล่านี้มักให้บริการ ผู้ใช้ภายนอก ไม่ว่าจะโดยตรงหรือโดยอ้อมผ่าน services อื่นๆ (ดู "Microservices and Serverless" ) บางครั้ง services ก็ถูกใช้ภายในโดยส่วนอื่นๆ ขององค์กร

นอกเหนือจากทีมที่จัดการ backend services แล้ว มักจะมีคนอีกสองกลุ่มที่ต้องการเข้าถึงข้อมูลขององค์กร: business analysts ซึ่งสร้างรายงานเกี่ยวกับกิจกรรมขององค์กรเพื่อช่วยผู้บริหารในการตัดสินใจที่ดีขึ้น ( business intelligence หรือ BI) และ data scientists ซึ่งมองหาข้อมูลเชิงลึกใหม่ๆ ในข้อมูลหรือสร้างฟีเจอร์ของผลิตภัณฑ์ที่ต้องใช้ data analysis และ machine learning (ML)/AI (เช่น คำแนะนำ "คนที่ซื้อ X ก็ซื้อ Y ด้วย" บนเว็บไซต์ ecommerce, predictive analytics เช่น การให้คะแนนความเสี่ยงหรือการกรองสแปม และการจัดอันดับผลการค้นหา)

แม้ว่า business analysts และ data scientists มักจะใช้เครื่องมือต่างกันและทำงานในรูปแบบที่ต่างกัน แต่พวกเขามีแนวปฏิบัติร่วมกันบางอย่าง ประการแรก ทั้งคู่ทำ analytics ซึ่งหมายถึงการดูข้อมูลที่ผู้ใช้และ backend services สร้างขึ้น ประการที่สอง โดยทั่วไปแล้ว พวกเขาไม่แก้ไขข้อมูลนี้ (ยกเว้นอาจจะเพื่อแก้ไขข้อผิดพลาด) แม้ว่าพวกเขาอาจสร้าง derived datasets ที่ข้อมูลดั้งเดิมถูกประมวลผลในทางใดทางหนึ่ง

สิ่งนี้นำไปสู่การแบ่งแยกระบบสองประเภท—ซึ่งเป็นความแตกต่างที่เราจะใช้ตลอดทั้งเล่ม:

• Operational systems ประกอบด้วย backend services และ data infrastructure ที่ข้อมูลถูกสร้างขึ้น—เช่น การให้บริการ ผู้ใช้ภายนอก ที่นี่ application code ทั้งอ่านและแก้ไขข้อมูลใน databases ตามการกระทำของผู้ใช้

• Analytical systems ตอบสนองความต้องการของ business analysts และ data scientists ประกอบด้วยสำเนาข้อมูลแบบอ่านอย่างเดียว จาก operational systems และถูกปรับให้เหมาะสมกับประเภทของการประมวลผลข้อมูลที่จำเป็นสำหรับ analytics

ดังที่เราจะเห็นในหัวข้อถัดไป operational และ analytical systems มักถูกแยกออกจากกันด้วยเหตุผลที่ดี เมื่อระบบเหล่านี้เติบโตขึ้น ก็เกิดบทบาทเฉพาะทางใหม่สองบทบาท: data engineers และ analytics engineers Data engineers คือคนที่รู้วิธีบูรณาการ operational และ analytical systems และรับผิดชอบ โครงสร้างพื้นฐานข้อมูลขององค์กรในวงกว้าง [ 3 ] Analytics engineers จำลองและแปลงข้อมูลเพื่อทำให้มีประโยชน์มากขึ้นสำหรับ business analysts และ data scientists ในองค์กร [ 4 ]

วิศวกรจำนวนมากเชี่ยวชาญด้าน operational หรือ analytical ด้านใดด้านหนึ่ง อย่างไรก็ตาม หนังสือเล่มนี้ครอบคลุม ทั้ง operational และ analytical data systems เนื่องจากทั้งคู่มีบทบาทสำคัญในวงจรชีวิตของข้อมูลภายในองค์กร เราจะสำรวจเชิงลึกเกี่ยวกับ data infrastructure ที่ใช้ในการส่งมอบบริการให้กับทั้งผู้ใช้ภายในและภายนอก เพื่อให้คุณสามารถทำงานร่วมกับเพื่อนร่วมงานในอีกฝั่งของเส้นแบ่งนี้ได้ดีขึ้น

Characterizing Transaction Processing and Analytics (ลักษณะของการประมวลผลธุรกรรมและการวิเคราะห์)

ในยุคแรกๆ ของการประมวลผลข้อมูลทางธุรกิจ การเขียนลง database มักสอดคล้องกับ ธุรกรรมทางการค้าที่เกิดขึ้น: การขายสินค้า การสั่งซื้อจากซัพพลายเออร์ การจ่ายเงินเดือนพนักงาน ฯลฯ เมื่อ databases ขยายไปสู่พื้นที่ที่ไม่เกี่ยวข้องกับการโอนเงิน คำว่า transaction ก็ยังคงถูกใช้อยู่ โดยหมายถึงกลุ่มของการอ่านและเขียนที่ประกอบเป็นหน่วยเชิงตรรกะ

หมายเหตุ

บท 8 จะสำรวจอย่างละเอียดว่าคำว่า transaction หมายถึงอะไร บทนี้ใช้คำนี้อย่างกว้างๆ เพื่อหมายถึง การอ่านและเขียนที่ latency ต่ำ

แม้ว่า databases จะเริ่มถูกใช้กับข้อมูลหลายประเภท—โพสต์บนโซเชียลมีเดีย การเดินในเกม รายชื่อในสมุดโทรศัพท์ และอื่นๆ อีกมากมาย—แต่รูปแบบการเข้าถึงพื้นฐานยังคงคล้ายกับการประมวลผล ธุรกรรมทางธุรกิจ operational system โดยทั่วไปจะค้นหาจำนวน records เล็กน้อยด้วย key (เรียกว่า point query ) records จะถูก insert, update หรือ delete ตาม input ของผู้ใช้ เนื่องจากแอปพลิเคชันเหล่านี้เป็น interactive รูปแบบการเข้าถึงนี้จึงเป็นที่รู้จักในชื่อ online transaction processing (OLTP)

อย่างไรก็ตาม databases ก็เริ่มถูกใช้สำหรับ analytics มากขึ้น ซึ่งมีรูปแบบการเข้าถึงที่แตกต่างจาก OLTP มาก โดยทั่วไป analytical query จะ scan records จำนวนมหาศาลและคำนวณ aggregate statistics (เช่น count, sum หรือ average) แทนที่จะส่งคืน records แต่ละรายการให้ผู้ใช้ ตัวอย่างเช่น business analyst ที่ห้างสรรพสินค้าแห่งหนึ่งอาจต้องการตอบคำถามเชิงวิเคราะห์เช่น:

• รายได้รวมของแต่ละสาขาของเราในเดือนมกราคมคือเท่าไร?

• เราขายกล้วยได้มากกว่าปกติเท่าไรในช่วงโปรโมชั่นล่าสุด?

• อาหารเด็กยี่ห้อไหนที่มักถูกซื้อพร้อมกับผ้าอ้อมยี่ห้อ X ?

รายงาน ที่ได้จากคำถามประเภทนี้มีความสำคัญต่อ BI ซึ่งช่วยให้ฝ่ายบริหารตัดสินใจว่าจะทำอะไรต่อไป เพื่อแยกความแตกต่างของรูปแบบการใช้ databases นี้ออกจากการประมวลผลธุรกรรม จึงเรียกมันว่า online analytical processing (OLAP) [ 5 ] ความแตกต่างระหว่าง OLTP และ analytics ไม่ได้ชัดเจนเสมอไป แต่มีลักษณะทั่วไปบางประการ แสดงอยู่ใน ตาราง 1-1 .

ตาราง 1-1. เปรียบเทียบลักษณะของ operational และ analytical systems | คุณสมบัติ | Operational systems (OLTP) | Analytical systems (OLAP) | | --- | --- | --- | | รูปแบบการอ่านหลัก | Point queries (ดึงข้อมูลทีละ record ด้วย key) | Aggregate จาก records จำนวนมาก | | รูปแบบการเขียนหลัก | Create, update, และ delete ทีละ record | Bulk import (ETL) หรือ event stream | | ตัวอย่างผู้ใช้ที่เป็นมนุษย์ | ผู้ใช้ปลายทางของเว็บ/mobile application | นักวิเคราะห์ภายใน สำหรับสนับสนุนการตัดสินใจ | | ตัวอย่างการใช้งานโดยระบบอัตโนมัติ | ตรวจสอบว่าการดำเนินการได้รับอนุญาตหรือไม่ | ตรวจจับรูปแบบการฉ้อโกง/การละเมิด | | ประเภทของ queries | ตายตัว application กำหนดไว้ล่วงหน้า | ad-hoc ตามที่นักวิเคราะห์ต้องการสำรวจ | | ปริมาณ query | queries ขนาดเล็กจำนวนมาก | queries น้อย แต่แต่ละอันซับซ้อน | | ข้อมูลแสดงถึง | สถานะล่าสุดของข้อมูล (ณ เวลาปัจจุบัน) | ประวัติของ events ที่เกิดขึ้นตามเวลา | | ขนาดชุดข้อมูล | Gigabytes ถึง terabytes | Terabytes ถึง petabytes |

หมายเหตุ

ความหมายของคำว่า online ใน OLAP นั้นไม่ชัดเจน อาจหมายถึงว่า queries ไม่ได้มีไว้แค่รายงานที่กำหนดไว้ล่วงหน้า แต่ นักวิเคราะห์ใช้ OLAP system แบบโต้ตอบสำหรับการสำรวจข้อมูล

สำหรับ operational systems โดยทั่วไปผู้ใช้จะไม่ได้รับอนุญาตให้สร้าง custom SQL queries และรันบน database เพราะอาจทำให้พวกเขาสามารถอ่านหรือแก้ไขข้อมูลที่ไม่มีสิทธิ์เข้าถึงได้ และอาจเขียน queries ที่ใช้ทรัพยากรมากจนกระทบประสิทธิภาพของ database สำหรับผู้ใช้คนอื่น ด้วยเหตุนี้ OLTP systems จึงส่วนใหญ่รันชุด queries ที่ตายตัวซึ่งฝังอยู่ใน application code โดยมี custom queries แบบครั้งเดียวที่ใช้เป็นครั้งคราวสำหรับการบำรุงรักษาหรือแก้ไขปัญหาเท่านั้น ในทางกลับกัน analytical databases มักให้อิสระแก่ผู้ใช้ในการเขียน arbitrary SQL queries ด้วยตัวเอง หรือสร้าง queries โดยอัตโนมัติผ่าน data visualization หรือ dashboard tools เช่น Tableau, Looker หรือ Microsoft Power BI

ระบบอีกประเภทหนึ่งถูกออกแบบสำหรับ workloads เชิงวิเคราะห์ (queries ที่รวมข้อมูลจากหลาย records) แต่ถูกฝังอยู่ใน products ที่ผู้ใช้ใช้งานโดยตรง ระบบที่ออกแบบมาสำหรับการใช้งานแบบนี้ เรียกว่า product analytics หรือ real-time analytics เช่น Pinot, Druid และ ClickHouse [ 6 ] ระบบเหล่านี้รับข้อมูลแบบ real time และถูกปรับให้เหมาะสมสำหรับการตอบสนอง query ที่ low latency ในทางตรงกันข้าม OLAP systems แบบดั้งเดิมมักรับข้อมูลเป็น batches และถูกปรับให้เหมาะสมสำหรับ การประมวลผล query แบบ high throughput

Data Warehousing (คลังข้อมูล)

ในตอนแรก databases เดียวกันถูกใช้สำหรับทั้ง transaction processing และ analytical queries SQL มีความยืดหยุ่นค่อนข้างมากในเรื่องนี้ มันทำงานได้ดีสำหรับ queries ทั้งสองประเภท อย่างไรก็ตาม ในช่วงปลายทศวรรษ 1980 ถึงต้นทศวรรษ 1990 บริษัทต่างๆ เริ่มเลิกใช้ OLTP systems ของตนทำ analytics และหันไปรัน analytics บน database อีกระบบหนึ่งที่แยกต่างหากแทน database ที่แยกต่างหากนี้เรียกว่า data warehouse .

องค์กรขนาดใหญ่อาจมี OLTP systems นับสิบหรือแม้กระทั่งหลายร้อยระบบ: ระบบที่ขับเคลื่อนเว็บไซต์ที่ให้บริการลูกค้า ควบคุมระบบ point-of-sale (ชำระเงิน) ในร้านค้าจริง ติดตามสินค้าคงคลังในคลังสินค้า วางแผนเส้นทางสำหรับยานพาหนะ จัดการซัพพลายเออร์ บริหารพนักงาน และทำงานอื่นๆ อีกมากมาย แต่ละระบบมีความซับซ้อนและต้องมีทีมคอยดูแล จึงมักทำงานแยกจากกันเป็นส่วนใหญ่

โดยทั่วไปเราไม่อยากให้ business analysts และ data scientists query OLTP systems เหล่านี้โดยตรง ด้วยเหตุผลหลายประการ:

• ข้อมูลที่สนใจอาจกระจายอยู่ทั่วหลาย operational systems ทำให้ยากที่จะรวมชุดข้อมูลเหล่านั้น ใน query เดียว (ปัญหาที่เรียกว่า data silos )

• ประเภทของ schemas และ data layouts ที่ดีสำหรับ OLTP นั้นไม่เหมาะกับ analytics เท่าไรนัก (ดู "Stars and Snowflakes: Schemas for Analytics" )

• Analytical queries อาจใช้ทรัพยากรมาก ถ้ารันบน OLTP database จะกระทบประสิทธิภาพของผู้ใช้คนอื่น

• OLTP systems อาจอยู่ในเครือข่ายที่แยกต่างหากซึ่งผู้ใช้ไม่ได้รับอนุญาตให้เข้าถึงโดยตรง ด้วยเหตุผลด้านความปลอดภัยหรือ compliance

ในทางตรงกันข้าม data warehouse คือ database ที่แยกต่างหากซึ่งนักวิเคราะห์สามารถ query ได้ตามต้องการ โดยไม่กระทบต่อการทำงานของ OLTP [ 7 ] ดังที่เราจะเห็นใน บท 4 data warehouses มักจัดเก็บข้อมูลแตกต่างจาก OLTP databases อย่างมาก เพื่อปรับให้เหมาะสมกับประเภทของ queries ที่พบบ่อยใน analytics

data warehouse ประกอบด้วยสำเนาข้อมูลแบบอ่านอย่างเดียวจาก OLTP systems ต่างๆ ในบริษัท ข้อมูลถูก extract จาก OLTP databases (โดยใช้ periodic data dump หรือ continuous stream ของ updates) transform เป็นรูปแบบที่เหมาะกับการวิเคราะห์ ทำความสะอาด แล้ว load เข้า data warehouse กระบวนการนำข้อมูลเข้า data warehouse นี้เรียกว่า extract–transform–load (ETL) และแสดงใน รูป 1-1 บางครั้งลำดับของขั้นตอน transform และ load ถูกสลับ (คือ transform ทำใน data warehouse หลังจาก load) เรียกว่า ELT .

รูป 1-1. ภาพรวมแบบง่ายของ ETL เข้าสู่ data warehouse

ในบางกรณี แหล่งข้อมูลของกระบวนการ ETL เป็น SaaS products ภายนอก เช่น customer relationship management (CRM), email marketing หรือระบบประมวลผลบัตรเครดิต ในกรณีนี้ คุณไม่สามารถเข้าถึง database ดั้งเดิมได้โดยตรง เพราะเข้าถึงได้ผ่าน API ของผู้ให้บริการซอฟต์แวร์เท่านั้น การดึงข้อมูลจากระบบภายนอกเหล่านี้เข้า data warehouse ของคุณเอง ทำให้วิเคราะห์ในแบบที่ SaaS API ไม่รองรับได้ ETL สำหรับ SaaS APIs มักทำผ่านบริการเชื่อมต่อข้อมูลเฉพาะทาง เช่น Fivetran, Singer หรือ Airbyte

ระบบ database บางระบบนำเสนอ hybrid transactional/analytical processing (HTAP) ซึ่งมีเป้าหมายเพื่อให้ OLTP และ analytics ทำงานในระบบเดียวโดยไม่ต้องใช้ ETL จากระบบหนึ่งไปยังอีกระบบหนึ่ง [ 8 , 9 ] อย่างไรก็ตาม ระบบ HTAP จำนวนมากภายในประกอบด้วย OLTP system ที่เชื่อมกับ analytical system ที่แยกต่างหาก ซ่อนอยู่เบื้องหลังอินเทอร์เฟซร่วมกัน—ดังนั้นความแตกต่างระหว่างทั้งสองจึงยังคงสำคัญต่อการเข้าใจ วิธีการทำงานของระบบเหล่านี้

ยิ่งไปกว่านั้น แม้จะมี HTAP แล้ว การแยก transactional และ analytical systems ออกจากกันก็ยังเป็นเรื่องปกติ เพราะเป้าหมายและข้อกำหนดต่างกัน โดยเฉพาะอย่างยิ่ง การให้แต่ละ operational system มี database ของตัวเองถือเป็นแนวปฏิบัติที่ดี (ดู "Microservices and Serverless" ) ซึ่งอาจทำให้มี operational databases แยกกันหลายร้อยตัว ในทางกลับกัน องค์กรมักจะมี data warehouse เดียว เพื่อให้ business analysts สามารถรวมข้อมูลจาก หลาย operational systems ใน query เดียว

ดังนั้น HTAP จึงไม่ได้แทนที่ data warehouses แต่จะมีประโยชน์เมื่อแอปพลิเคชันเดียวกันต้อง ทั้งรัน analytical queries ที่ scan rows จำนวนมาก และอ่าน/update แต่ละ record ด้วย low latency การตรวจจับการฉ้อโกงอาจเป็นตัวอย่างหนึ่งของ workload ประเภทนี้ [ 10 ]

การแยกระหว่าง operational และ analytical systems เป็นส่วนหนึ่งของแนวโน้มที่กว้างขึ้น เมื่อ workloads มีความต้องการมากขึ้น ระบบก็มีความเชี่ยวชาญเฉพาะทางและถูกปรับให้เหมาะสมสำหรับ workloads เฉพาะมากขึ้น ระบบอเนกประสงค์จัดการข้อมูลปริมาณน้อยได้สบายๆ แต่ยิ่ง scale ใหญ่ขึ้นเท่าไร ระบบก็มักยิ่งมีความเชี่ยวชาญเฉพาะทางมากขึ้นเท่านั้น [ 11 ]

From data warehouse to data lake (จาก data warehouse สู่ data lake)

data warehouse มักใช้ relational data model ที่ query ผ่าน SQL (ดู บท 3 ) อาจใช้ซอฟต์แวร์ BI เฉพาะทาง โมเดลนี้ทำงานได้ดีสำหรับประเภทของ queries ที่ business analysts ต้องการ แต่ไม่เหมาะกับความต้องการของ data scientists ที่ทำงานเช่น:

• การแปลงข้อมูลให้อยู่ในรูปแบบที่เหมาะกับการ train ML model ซึ่งมักต้องเปลี่ยน rows และ columns ของตาราง database ให้เป็น vector หรือ matrix ของค่าตัวเลขที่เรียกว่า features การแปลงเพื่อให้โมเดลที่เทรนออกมามีประสิทธิภาพดีขึ้นนี้เรียกว่า feature engineering และโดยทั่วไปต้องใช้ custom code ที่ยากต่อการแสดงด้วย SQL

• การใช้เทคนิค natural language processing (NLP) กับข้อมูลข้อความ (เช่น รีวิวสินค้า) เพื่อพยายามดึงข้อมูลที่มีโครงสร้างจากมัน (เช่น ความรู้สึกของผู้เขียน หรือหัวข้อที่พวกเขากล่าวถึง) ในทำนองเดียวกัน data scientists อาจต้องดึงข้อมูลที่มีโครงสร้างจากรูปภาพโดยใช้เทคนิค computer vision

แม้จะมีความพยายามเพิ่ม ML operators เข้าไปใน SQL data model [ 12 ] และสร้าง ML systems ที่ทำงานได้มีประสิทธิภาพบนพื้นฐาน relational [ 13 ] แต่ data scientists จำนวนมากไม่ชอบทำงานใน relational database เช่น data warehouse และมักใช้ Python data analysis libraries เช่น Pandas และ scikit-learn, ภาษาสำหรับการวิเคราะห์ทางสถิติ เช่น R และ distributed analytics frameworks เช่น Spark [ 14 ] เราจะพูดถึงเพิ่มเติมใน "DataFrames, Matrices, and Arrays" .

ด้วยเหตุนี้ องค์กรจึงต้องทำให้ข้อมูลพร้อมใช้งานในรูปแบบที่เหมาะสมสำหรับ data scientists คำตอบคือ data lake : คลังข้อมูลแบบรวมศูนย์ที่เก็บสำเนาของข้อมูลใดๆ ที่อาจมีประโยชน์สำหรับการวิเคราะห์ ซึ่งได้มาจาก operational systems ผ่านกระบวนการ ETL ความแตกต่างจาก data warehouse คือ data lake เป็นเพียงที่เก็บไฟล์ โดยไม่กำหนดรูปแบบไฟล์ data model หรือ schema ที่เฉพาะเจาะจง [ 15 ] ไฟล์ใน data lake อาจเป็น collections ของ database records ที่เข้ารหัสด้วยรูปแบบไฟล์เช่น Avro หรือ Parquet (ดู บท 5 ) แต่ data lake ก็สามารถประกอบด้วยข้อความ รูปภาพ วิดีโอ ค่าจากเซนเซอร์ sparse matrices feature vectors ลำดับจีโนม หรือข้อมูลประเภทอื่นๆ ได้เช่นกัน [ 16 ] นอกเหนือจากความยืดหยุ่นแล้ว data lake ยังมักถูกกว่า relational data storage เนื่องจากสามารถใช้ commoditized file storage เช่น object stores (ดู "Cloud Native System Architecture" )

กระบวนการ ETL ขยายกลายเป็น data pipelines และในบางกรณี data lake ก็กลายเป็นจุดพักระหว่างทางจาก operational systems ไปยัง data warehouse data lake ประกอบด้วยข้อมูลในรูปแบบ "ดิบ" ที่ผลิตโดย operational systems โดยไม่ต้องแปลงเป็น relational data warehouse schema วิธีการนี้มีข้อดีคือ ผู้ใช้ข้อมูลแต่ละรายสามารถแปลงข้อมูลดิบให้เป็นรูปแบบที่เหมาะกับความต้องการของตนเองได้ บางครั้งเรียกว่า sushi principle : "ข้อมูลดิบดีกว่า" [ 17 ]

Beyond the data lake (เหนือกว่า data lake)

เมื่องาน analytics เติบโตขึ้น องค์กรต่างๆ ก็ให้ความสำคัญกับการจัดการและการดำเนินงานของ analytical systems และ data pipelines มากขึ้น เช่นที่ระบุไว้ใน DataOps Manifesto [ 18 ] สาเหตุส่วนหนึ่งมาจากประเด็นด้าน governance ความเป็นส่วนตัว และการปฏิบัติตามกฎระเบียบ เช่น General Data Protection Regulation (GDPR) และ California Consumer Privacy Act (CCPA) ซึ่งเราจะพูดถึงใน "Data Systems, Law, and Society" และใน บท 14 .

ปัจจัยสำคัญอีกอย่างคือ ข้อมูลสำหรับ analytics ไม่ได้มีแค่ในรูปไฟล์และตาราง relational แต่มาในรูป streams ของ events มากขึ้นด้วย (ดู บท 12 ) ถ้าวิเคราะห์ข้อมูลแบบ file-based คุณสามารถรันการวิเคราะห์ซ้ำเป็นระยะ (เช่น รายวัน) เพื่อตอบสนองต่อการเปลี่ยนแปลงของข้อมูลได้ แต่ stream processing ช่วยให้ analytical systems ตอบสนองต่อ events ได้เร็วกว่ามาก ในระดับวินาที ทั้งนี้ขึ้นอยู่กับแอปพลิเคชันและความไวต่อเวลา stream processing อาจมีประโยชน์ เช่น ใช้ระบุและบล็อกกิจกรรมที่อาจเป็นการฉ้อโกงหรือละเมิด

ในบางกรณี ผลลัพธ์ของ analytical systems ถูกทำให้พร้อมใช้งานสำหรับ operational systems (บางครั้งเรียกกระบวนการนี้ว่า reverse ETL [ 19 ]) ตัวอย่างเช่น ML model ที่ถูกเทรนบนข้อมูลใน analytical system อาจถูก deploy ไปยัง production เพื่อสร้างคำแนะนำสำหรับผู้ใช้ปลายทาง เช่น "คนที่ซื้อ X ก็ซื้อ Y ด้วย" Machine learning models สามารถ deploy ไปยัง operational systems โดยใช้เครื่องมือเฉพาะทาง เช่น TFX, Kubeflow หรือ MLflow

Systems of Record and Derived Data (ระบบบันทึกต้นทางและข้อมูลที่ได้มาจากข้อมูลอื่น)

ควบคู่ไปกับความแตกต่างระหว่าง operational และ analytical systems หนังสือเล่มนี้ยังแยกแยะระหว่าง systems of record และ derived data systems คำเหล่านี้มีประโยชน์เพราะช่วยให้เห็นภาพการไหลของข้อมูลผ่านระบบ:

Systems of record (ระบบบันทึกต้นทาง)

system of record หรือที่เรียกว่า source of truth , เก็บข้อมูลเวอร์ชันที่เชื่อถือได้หรือ canonical เมื่อข้อมูลใหม่เข้ามา—เช่น จากผู้ใช้—ข้อมูลจะถูกเขียนที่นี่ก่อน แต่ละ fact เก็บไว้เพียงครั้งเดียว (โดยทั่วไปจะเป็นแบบ normalized ; ดู "Normalization, Denormalization, and Joins" ) หากข้อมูลในระบบอื่นไม่ตรงกับ system of record ให้ถือว่าค่าใน system of record (ตามนิยาม) เป็นค่าที่ถูกต้อง

Derived data systems (ระบบข้อมูลที่ได้มาจากข้อมูลอื่น)

ข้อมูลใน derived system เป็นผลลัพธ์ของการนำข้อมูลที่มีอยู่จากระบบอื่นมาแปลงหรือประมวลผลในทางใดทางหนึ่ง ถ้าคุณสูญเสีย derived data คุณสามารถสร้างมันขึ้นมาใหม่จากแหล่งต้นทางได้ ตัวอย่างคลาสสิกคือ cache: ถ้า cache มีข้อมูลที่ต้องการก็ให้บริการจาก cache ได้เลย แต่ถ้าไม่มี คุณก็ fallback ไปอ่านจาก database หลักได้ Denormalized values, indexes, materialized views, transformed data representations และโมเดลที่เทรนบนชุดข้อมูลก็จัดอยู่ในหมวดนี้

ในทางเทคนิค derived data ถือว่า redundant ในแง่ที่ว่ามันซ้ำซ้อนกับข้อมูลที่มีอยู่ อย่างไรก็ตาม ข้อมูลนี้มักจำเป็นเพื่อให้ read query มีประสิทธิภาพดี คุณสร้าง derived datasets หลายชุดจากแหล่งเดียวได้ ทำให้มองข้อมูลจากมุมมองที่ต่างกันได้

Analytical systems มักเป็น derived data systems เพราะเป็น consumer ของข้อมูลที่สร้างขึ้นที่อื่น Operational services อาจมีทั้ง systems of record และ derived data systems ผสมกัน systems of record คือ databases หลักที่ข้อมูลถูกเขียนครั้งแรก ในขณะที่ derived data systems คือ indexes และ caches ที่เร่งการอ่านทั่วไป โดยเฉพาะสำหรับ queries ที่ system of record ไม่สามารถตอบได้อย่างมีประสิทธิภาพ

Databases, storage engines และ query languages ส่วนใหญ่ไม่ได้เป็น systems of record หรือ derived systems โดยเนื้อแท้ database เป็นเพียงเครื่องมือ วิธีการใช้ขึ้นอยู่กับคุณ ความแตกต่างระหว่าง system of record และ derived data system ไม่ได้ขึ้นอยู่กับเครื่องมือ แต่อยู่ที่วิธีที่คุณใช้มันในแอปพลิเคชันของคุณ การทำให้ชัดเจนว่าข้อมูลชุดไหน derive มาจากชุดไหน ช่วยให้เข้าใจสถาปัตยกรรมระบบที่อาจดูสับสนได้ง่ายขึ้น

เมื่อข้อมูลในระบบหนึ่ง derived จากข้อมูลในอีกระบบหนึ่ง คุณต้องมีกระบวนการอัปเดต derived data เมื่อข้อมูลต้นฉบับใน system of record เปลี่ยนแปลง น่าเสียดายที่ databases จำนวนมากถูกออกแบบบนสมมติฐานที่ว่าแอปพลิเคชันของคุณจะใช้ database นั้นเพียงตัวเดียวเสมอ และไม่ได้ทำให้การเชื่อมหลายระบบเข้าด้วยกันเพื่อส่งต่อการอัปเดตเหล่านั้นเป็นเรื่องง่าย ใน บท 11 เราจะพูดถึง data pipelines ในฐานะแนวทางสำหรับ data integration ซึ่งช่วยให้เราสามารถประกอบหลาย data systems เพื่อทำสิ่งที่ระบบเดียวไม่สามารถทำได้

นั่นคือจุดสิ้นสุดของการเปรียบเทียบ analytics และ transaction processing ของเรา ในหัวข้อถัดไปเราจะดู trade-off อีกเรื่องที่คุณอาจเคยเห็น ถูกถกเถียงกันบ่อยๆ

Cloud Versus Self-Hosting (คลาวด์เทียบกับการโฮสต์ด้วยตนเอง)

ไม่ว่าองค์กรต้องทำอะไร คำถามแรกๆ คือควรทำเองภายในองค์กรหรือจ้างคนนอกทำ กล่าวคือ ควรสร้างเองหรือซื้อ?

ท้ายที่สุดแล้ว นี่คือคำถามเกี่ยวกับลำดับความสำคัญทางธุรกิจ กฎทั่วไปคือ สิ่งที่เป็น core competency หรือ competitive advantage ขององค์กรควรทำภายในองค์กร ส่วนสิ่งที่ไม่ใช่ core เป็นงานประจำ หรือเป็นเรื่องทั่วไป ควรปล่อยให้ผู้ขาย (vendor) ทำ [ 20 ] ยกตัวอย่างสุดโต่ง บริษัทส่วนใหญ่ไม่ผลิต CPU ของตัวเอง เพราะการซื้อจากผู้ผลิตเซมิคอนดักเตอร์ถูกกว่า

สำหรับซอฟต์แวร์ มีการตัดสินใจสำคัญสองเรื่องคือ ใครเป็นคนสร้างและใครเป็นคน deploy ตัวเลือกที่เป็นไปได้เรียงเป็นสเปกตรัมดังที่แสดงใน รูป 1-2 ปลายด้านหนึ่งคือ bespoke software ที่คุณเขียนและรันเองภายในองค์กร อีกด้านหนึ่งคือ cloud services หรือ SaaS products ที่ใช้กันอย่างแพร่หลาย ซึ่งผู้ขายภายนอกเป็นคนพัฒนาและดูแลระบบ ส่วนคุณเข้าถึงได้ผ่านเว็บอินเทอร์เฟซหรือ API เท่านั้น

รูป 1-2. สเปกตรัมของการตัดสินใจเรื่องการจ้างภายนอกทำซอฟต์แวร์และดูแลระบบ

จุดกึ่งกลางคือซอฟต์แวร์สำเร็จรูป (open source หรือ commercial) ที่คุณ self-host หรือ deploy ด้วยตัวเอง—เช่น ถ้าคุณดาวน์โหลด MySQL และติดตั้งบนเซิร์ฟเวอร์ที่คุณควบคุม ซึ่งอาจรันบนฮาร์ดแวร์ของคุณเอง (มักเรียกว่า on premises แม้ว่าเซิร์ฟเวอร์จะอยู่ใน rack datacenter ที่เช่าและไม่ได้อยู่ในสถานที่ของคุณจริงๆ) หรือบน virtual machine (VM) ในคลาวด์ ( infrastructure as a service หรือ IaaS) ยังมีจุดอื่นๆ ตามสเปกตรัมนี้อีก เช่น นำซอฟต์แวร์ open source มาปรับแก้แล้วรันเวอร์ชันของตัวเอง

คำถามที่เกี่ยวข้องคือ อย่างไร ในการ deploy service ไม่ว่าจะในคลาวด์หรือ on premises—เช่น คุณใช้ orchestration framework เช่น Kubernetes หรือไม่ อย่างไรก็ตาม การเลือกเครื่องมือ deployment อยู่นอกเหนือขอบเขตของหนังสือเล่มนี้ เนื่องจากปัจจัยอื่นๆ มีอิทธิพลต่อสถาปัตยกรรมของ data systems มากกว่า

Pros and Cons of Cloud Services (ข้อดีและข้อเสียของ Cloud Services)

การใช้ cloud service แทนการรันซอฟต์แวร์ที่เทียบเคียงได้ด้วยตัวเอง โดยพื้นฐานแล้วก็คือการจ้าง cloud provider ให้ดูแลซอฟต์แวร์นั้นแทน แนวทางนี้มีทั้งข้อโต้แย้งที่สนับสนุนและคัดค้าน cloud providers อ้างว่าการใช้บริการของพวกเขาช่วยประหยัดเวลาและเงิน และช่วยให้คุณทำงานได้เร็วขึ้น เมื่อเทียบกับการตั้งค่าโครงสร้างพื้นฐานของคุณเอง

ไม่ว่าการใช้ cloud service จะถูกกว่าและง่ายกว่า self-hosting หรือไม่นั้น ขึ้นอยู่กับ ทักษะของคุณและ workload บนระบบของคุณเป็นอย่างมาก ถ้าคุณมีประสบการณ์ในการตั้งค่าและดำเนินการ ระบบที่คุณต้องการอยู่แล้ว และถ้า load ของคุณค่อนข้างคาดเดาได้ (คือ จำนวนเครื่องที่คุณต้องการไม่ผันผวนรุนแรง) การซื้อเครื่องของคุณเองและรันซอฟต์แวร์บนเครื่องเหล่านั้นมักจะถูกกว่า [ 21 , 22 ]

ในทางกลับกัน ถ้าคุณต้องการระบบที่คุณยังไม่รู้วิธี deploy และดำเนินการ การใช้ cloud service มักจะง่ายกว่าและเร็วกว่าการเรียนรู้ที่จะจัดการระบบ การจ้างและฝึกพนักงานมาดูแลระบบโดยเฉพาะอาจมีค่าใช้จ่ายสูงมาก คุณยังคงต้องมีทีม operations เมื่อใช้คลาวด์ (ดู "Operations in the Cloud Era" ) แต่การจ้างภายนอกดูแลระบบพื้นฐานช่วยให้ทีมของคุณไปโฟกัสเรื่องในระดับที่สูงขึ้นได้

การให้บริษัทที่เชี่ยวชาญด้านการรันระบบมาดูแลแทนอาจทำให้ได้บริการที่ดีขึ้น เพราะผู้ให้บริการสั่งสมประสบการณ์ด้านการดูแลระบบจากการให้บริการลูกค้าจำนวนมาก ในทางกลับกัน ถ้าคุณรันบริการด้วยตัวเอง คุณสามารถกำหนดค่าและปรับแต่งมันให้ทำงานได้ดี สำหรับ workload เฉพาะของคุณ cloud service น่าจะไม่เต็มใจปรับแต่งแบบนั้นให้คุณ

Cloud services มีค่าเป็นพิเศษเมื่อ load บนระบบของคุณผันผวนอย่างมากตามเวลา ถ้าคุณจัดเตรียมเครื่องให้สามารถรับมือกับ peak load แต่ทรัพยากรคอมพิวเตอร์เหล่านั้นว่างเปล่าส่วนใหญ่ ระบบก็จะมีประสิทธิภาพด้านต้นทุนน้อยลง ในสถานการณ์นี้ cloud services มีข้อได้เปรียบ ที่ทำให้ปรับขนาดทรัพยากรคอมพิวเตอร์ขึ้นหรือลงตามการเปลี่ยนแปลงของ demand ได้ง่ายขึ้น

ตัวอย่างเช่น analytical systems มักมี load ที่ผันผวนอย่างมาก การรัน analytical query ขนาดใหญ่ อย่างรวดเร็วต้องใช้ทรัพยากรคอมพิวเตอร์จำนวนมากแบบขนาน แต่เมื่อ query เสร็จสิ้น ทรัพยากรเหล่านั้นก็จะว่างเปล่าจนกว่าผู้ใช้จะทำ query ถัดไป Predefined queries (เช่น สำหรับรายงานประจำวัน) สามารถ enqueue และจัดตารางเวลาเพื่อปรับ load ให้ราบรื่น แต่สำหรับ interactive queries ยิ่งคุณต้องการให้มันเสร็จเร็วเท่าไร workload ก็ยิ่งผันผวนมากขึ้นเท่านั้น ถ้าชุดข้อมูลของคุณใหญ่จนการ query อย่างรวดเร็วต้องใช้ทรัพยากรคอมพิวเตอร์จำนวนมาก การใช้คลาวด์สามารถประหยัดเงินได้ เนื่องจากคุณสามารถคืนทรัพยากรที่ไม่ได้ใช้ให้ผู้ให้บริการ แทนที่จะปล่อยให้มันว่างเปล่า สำหรับชุดข้อมูลขนาดเล็ก ความแตกต่างนี้มีนัยสำคัญน้อยกว่า

ข้อเสียที่ใหญ่ที่สุดของ cloud service คือคุณไม่สามารถควบคุมมันได้:

• ถ้าขาดฟีเจอร์ที่คุณต้องการ สิ่งที่ทำได้คือขอให้ผู้ขายเพิ่มให้อย่างสุภาพ โดยทั่วไปคุณไม่สามารถ implement เองได้

• ถ้า service ล่ม สิ่งที่คุณทำได้คือรอมันกู้คืน

• ถ้าคุณใช้ service ในแบบที่ trigger บั๊กหรือก่อให้เกิดปัญหาด้านประสิทธิภาพ การวินิจฉัยปัญหาจะทำได้ยาก ถ้าเป็นซอฟต์แวร์ที่คุณรันเอง คุณดึง metrics และข้อมูล debugging จาก operating system มาช่วยทำความเข้าใจพฤติกรรมของมันได้ และดู server logs ได้ แต่ถ้าเป็นบริการที่ผู้ขาย host ให้ คุณมักเข้าถึงรายละเอียดภายในเหล่านี้ไม่ได้

• ถ้า service ปิดตัวลง แพงเกินไป หรือผู้ขายเปลี่ยนผลิตภัณฑ์ไปในแบบที่คุณไม่ชอบ คุณก็ตกเป็นฝ่ายที่ต้องจำยอม การรันซอฟต์แวร์เวอร์ชันเก่าต่อไปมักทำไม่ได้ คุณจึงถูกบังคับให้ย้ายไปใช้บริการอื่น [ 23 ] ความเสี่ยงนี้ลดลงถ้ามีบริการอื่นที่ API เข้ากันได้ แต่ cloud services หลายตัวไม่มี API มาตรฐาน ทำให้ต้นทุนการย้ายสูงขึ้นและ vendor lock-in กลายเป็นปัญหา

• ถ้า cloud provider อยู่ในประเทศอื่นและเกิดความขัดแย้งทางการเมืองระหว่างประเทศนั้น กับประเทศของคุณ คุณเสี่ยงที่จะถูกตัดการเข้าถึง service เนื่องจากการคว่ำบาตร

• cloud provider ต้องได้รับความไว้วางใจให้รักษาข้อมูลให้ปลอดภัย ซึ่งอาจทำให้กระบวนการปฏิบัติตามกฎระเบียบด้านความเป็นส่วนตัวและความปลอดภัยซับซ้อนขึ้น

แม้จะมีความเสี่ยงทั้งหมดนี้ การสร้างแอปพลิเคชันใหม่บน cloud services หรือใช้แนวทางแบบ hybrid ที่ใช้ cloud services สำหรับบางส่วนของระบบก็ได้รับความนิยมมากขึ้นเรื่อยๆ อย่างไรก็ตาม cloud services จะไม่เข้ามาแทนที่ data systems ภายในองค์กรทั้งหมด ระบบเก่าจำนวนมากมีมาก่อนคลาวด์ และสำหรับบริการใดๆ ที่มีข้อกำหนดเฉพาะทางที่ cloud services ที่มีอยู่ไม่สามารถตอบสนองได้ ระบบภายในองค์กรก็ยังคงจำเป็น ตัวอย่างเช่น แอปพลิเคชันที่ไวต่อ latency มาก เช่น high-frequency trading ต้องการการควบคุมฮาร์ดแวร์อย่างเต็มที่

Cloud Native System Architecture (สถาปัตยกรรมระบบ Cloud Native)

นอกจากโมเดลทางเศรษฐกิจที่ต่างออกไป (สมัครใช้บริการแทนการซื้อฮาร์ดแวร์และ ลิขสิทธิ์ซอฟต์แวร์เพื่อรันบนนั้น) การเติบโตของคลาวด์ยังส่งผลอย่างลึกซึ้งต่อวิธีการ implement data systems ในระดับเทคนิค คำว่า cloud native ใช้อธิบายสถาปัตยกรรมที่ถูกออกแบบมาเพื่อใช้ประโยชน์จาก cloud services

โดยหลักการแล้ว ซอฟต์แวร์เกือบทั้งหมดที่คุณสามารถ self-host ก็สามารถให้บริการเป็น cloud service ได้ และแน่นอนว่าขณะนี้มี managed services สำหรับ data systems ยอดนิยมมากมาย อย่างไรก็ตาม ระบบที่ถูกออกแบบตั้งแต่ต้นให้เป็น cloud native ได้แสดงให้เห็นถึงข้อดีหลายประการ: ประสิทธิภาพที่ดีกว่าบนฮาร์ดแวร์เดียวกัน การกู้คืนจากความล้มเหลวที่เร็วกว่า การปรับขนาดทรัพยากรคอมพิวเตอร์ให้ตรงกับ load ได้อย่างรวดเร็ว และการรองรับชุดข้อมูลที่ใหญ่กว่า [ 24 , 25 , 26 ] ตาราง 1-2 แสดงตัวอย่างของระบบทั้งสองประเภท

ตาราง 1-2. ตัวอย่างระบบฐานข้อมูลแบบ self-hosted และ cloud native | หมวดหมู่ | Self-hosted systems | Cloud native systems | | --- | --- | --- | | Operational/OLTP | MySQL, PostgreSQL, MongoDB | AWS Aurora [ 24 ], Azure SQL DB Hyperscale [ 25 ], Google Cloud Spanner | | Analytical/OLAP | Teradata, ClickHouse, Spark | Snowflake [ 26 ], Google BigQuery, Azure Synapse Analytics |

Layering of cloud services (การวางชั้นของ Cloud Services)

data systems ที่ self-host ได้จำนวนมากมีข้อกำหนดด้านระบบที่เรียบง่าย พวกมันรันบน operating system ทั่วไป เช่น Linux หรือ Windows จัดเก็บข้อมูลเป็นไฟล์บน filesystem และสื่อสารผ่าน network protocols มาตรฐาน เช่น TCP/IP บางระบบพึ่งพา hardware พิเศษ เช่น GPUs (สำหรับ ML) หรือ remote direct memory access (RDMA) network interfaces แต่โดยรวมแล้ว ซอฟต์แวร์ที่ self-hosted มักจะใช้ทรัพยากรคอมพิวเตอร์ทั่วไป: CPUs, RAM, filesystem และ IP network

ในคลาวด์ ซอฟต์แวร์ประเภทนี้สามารถรันใน สภาพแวดล้อม IaaS โดยใช้ VM หนึ่งตัวหรือมากกว่า (หรือ instances ) ซึ่งได้รับจัดสรร CPUs, หน่วยความจำ, ดิสก์ และ network bandwidth ในปริมาณที่กำหนดไว้ เมื่อเทียบกับเครื่องทางกายภาพ cloud instances สามารถ provision ได้เร็วกว่าและมีขนาดที่หลากหลายกว่า แต่อย่างอื่นก็คล้ายกับคอมพิวเตอร์แบบดั้งเดิม: คุณสามารถรันซอฟต์แวร์ใดก็ได้ที่คุณต้องการ แต่ต้องดูแลจัดการเอง

ในทางตรงกันข้าม แนวคิดหลักของ cloud native services คือไม่ได้ใช้แค่ทรัพยากรคอมพิวเตอร์ที่ operating system ของคุณจัดการ แต่ยังต่อยอดจาก cloud services ระดับล่างเพื่อสร้าง services ระดับสูงขึ้น ตัวอย่างเช่น:

• Object storage services เช่น Amazon S3, Azure Blob Storage และ Cloudflare R2 จัดเก็บ ไฟล์ขนาดใหญ่ พวกมันให้ APIs ที่จำกัดกว่า filesystem ทั่วไป (อ่านและเขียนไฟล์พื้นฐานเท่านั้น) แต่ก็มีข้อดีคือซ่อนเครื่องทางกายภาพที่อยู่เบื้องหลังไว้ service จะกระจายข้อมูลไปยังหลายเครื่องโดยอัตโนมัติ คุณจึงไม่ต้องกังวลว่าพื้นที่ดิสก์ของเครื่องใดเครื่องหนึ่งจะเต็ม และแม้เครื่องหรือดิสก์บางตัวจะเสียหายทั้งหมด ข้อมูลก็จะไม่สูญหาย

• services อื่นๆ อีกมากมายก็ถูกสร้างบน object storage และ cloud services อื่นๆ เช่นกัน ตัวอย่างเช่น Snowflake เป็น cloud-based analytical database (data warehouse) ที่พึ่งพา S3 สำหรับการจัดเก็บข้อมูล [ 26 ] และ services อื่นๆ ก็สร้างบน Snowflake ต่อไปอีก

เช่นเดียวกับ abstractions อื่นๆ ในวงการคอมพิวเตอร์ ไม่มีคำตอบตายตัวว่าควรใช้อะไร ตามกฎทั่วไป abstractions ระดับสูงมักจะเน้นไปที่ use cases เฉพาะทางมากกว่า ถ้าความต้องการของคุณตรงกับสถานการณ์ที่ระบบระดับสูงถูกออกแบบไว้ การใช้ระบบระดับสูงที่มีอยู่น่าจะตอบสนองความต้องการของคุณได้โดยยุ่งยากน้อยกว่ามากการสร้างเอง จากระบบระดับล่าง ในทางกลับกัน ถ้าไม่มีระบบระดับสูงที่ตรงกับความต้องการของคุณ การสร้างเองจากส่วนประกอบระดับล่างก็เป็นทางเลือกเดียว

Separation of storage and compute (การแยก Storage และ Compute)

ในการคอมพิวติ้งแบบดั้งเดิม disk storage ถือว่าทนทาน (เราสมมติว่าเมื่อมีสิ่งใดถูกเขียนลงดิสก์ มันจะไม่สูญหาย) เพื่อทนต่อความล้มเหลวของฮาร์ดดิสก์แต่ละตัว RAID (redundant array of independent disks) มักถูกใช้เพื่อเก็บสำเนาข้อมูลบนดิสก์หลายตัว ที่ติดอยู่กับเครื่องเดียวกัน RAID สามารถ implement ในฮาร์ดแวร์หรือซอฟต์แวร์โดย operating system และมันโปร่งใสต่อแอปพลิเคชันที่เข้าถึง filesystem

ในคลาวด์ compute instances (VMs) อาจมี local disks ติดอยู่เช่นกัน แต่ cloud native systems มักมองดิสก์เหล่านี้เป็น ephemeral cache มากกว่าที่เก็บข้อมูลระยะยาว เพราะ local disk จะใช้ไม่ได้ถ้า instance ที่เกี่ยวข้องล้มเหลว หรือถ้า instance ถูกแทนที่ด้วยตัวที่ใหญ่หรือเล็กกว่า (บนเครื่องทางกายภาพอื่น) เพื่อรับมือกับ load ที่เปลี่ยนไป

นอกจาก local disks แล้ว cloud services ยังมี virtual disk storage ซึ่งถอดออกจาก instance หนึ่งแล้วไปติดกับอีก instance หนึ่งได้ (เช่น Amazon EBS, Azure managed disks และ persistent disks ใน Google Cloud) virtual disk ดังกล่าวไม่ใช่ดิสก์ทางกายภาพ แต่เป็น cloud service ที่ให้บริการโดยชุดเครื่องแยกต่างหาก ที่เลียนแบบพฤติกรรมของดิสก์ ( block device , โดยแต่ละ block มีขนาดโดยทั่วไป 4 KiB) ด้วยวิธีนี้ เราจึงรันซอฟต์แวร์แบบดั้งเดิมที่ใช้ดิสก์ในคลาวด์ได้ แต่การเลียนแบบ block device ทำให้เกิด overheads ที่สามารถหลีกเลี่ยงได้ในระบบ ที่ถูกออกแบบตั้งแต่ต้นสำหรับคลาวด์ [ 24 ] การใช้ virtual disks ยังทำให้แอปพลิเคชันไวต่อ network glitches มาก เนื่องจากการ I/O ทุกครั้งบน virtual block device คือ network call [ 27 ]

เพื่อแก้ปัญหานี้ cloud native services โดยทั่วไปหลีกเลี่ยงการใช้ virtual disks และสร้างบน dedicated storage services ที่ถูกปรับให้เหมาะสมสำหรับ workloads เฉพาะ Object storage services เช่น S3 ถูกออกแบบสำหรับการจัดเก็บระยะยาวของไฟล์ที่ค่อนข้างใหญ่ ตั้งแต่หลายร้อย kilobytes ถึงหลาย gigabytes ขนาด rows หรือ values แต่ละรายการที่เก็บใน database มักจะเล็กกว่านี้มาก cloud databases จึงมักจัดการ ค่าที่เล็กกว่าใน service ที่แยกต่างหากและจัดเก็บ data blocks ขนาดใหญ่ (ที่บรรจุหลายๆ ค่า) ไว้ใน object store [ 25 , 28 ] เราจะเห็นวิธีการทำเช่นนี้ใน บท 4 .

ในสถาปัตยกรรมระบบแบบดั้งเดิม คอมพิวเตอร์เครื่องเดียวกันรับผิดชอบทั้ง storage (disk) และ computation (CPU และ RAM) แต่ใน cloud native systems ความรับผิดชอบทั้งสองนี้ถูกแยกออกจากกันในระดับหนึ่ง หรือ disaggregated [ 9 , 26 , 29 , 30 ]: ตัวอย่างเช่น S3 จัดเก็บเฉพาะไฟล์ และถ้าคุณต้องการวิเคราะห์ข้อมูลนั้น คุณจะต้องรันโค้ดวิเคราะห์ที่ไหนสักแห่งนอก S3 ซึ่งหมายถึงการโอนย้ายข้อมูลผ่าน network ซึ่งเราจะพูดถึงเพิ่มเติมใน "Distributed Versus Single-Node Systems" .

ยิ่งไปกว่านั้น cloud native systems มักเป็น multitenant ซึ่งหมายความว่าแทนที่จะมีเครื่องแยกสำหรับลูกค้าแต่ละราย ข้อมูลและการคำนวณจาก ลูกค้าหลายรายจะถูกจัดการบนฮาร์ดแวร์ที่ใช้ร่วมกันเดียวกันโดย service เดียว [ 31 ] Multitenancy อาจช่วยให้ใช้ฮาร์ดแวร์ได้คุ้มขึ้น ปรับขนาดได้ง่ายขึ้น และ cloud provider จัดการได้ง่ายขึ้น แต่ก็ต้องอาศัยการออกแบบที่รอบคอบ เพื่อให้แน่ใจว่ากิจกรรมของลูกค้ารายหนึ่งไม่กระทบประสิทธิภาพหรือความปลอดภัยของระบบสำหรับลูกค้ารายอื่น [ 32 ]

Operations in the Cloud Era (งาน operations ในยุคคลาวด์)

ตามธรรมเนียม คนที่จัดการ server-side data infrastructure ขององค์กรเรียกว่า database administrators (DBAs) หรือ system administrators (sysadmins) ในช่วงหลังมานี้ หลายองค์กรพยายามรวมงานพัฒนาซอฟต์แวร์และ operations เข้าเป็นทีมเดียวที่รับผิดชอบร่วมกันทั้ง backend services และ data infrastructure แนวโน้มนี้ได้รับแรงขับเคลื่อนจากปรัชญา DevOps ส่วน Site reliability engineers (SREs) คือการนำแนวคิดนี้ไปใช้ในแบบของ Google [ 33 ]

หน้าที่ของ operations คือทำให้แน่ใจว่าบริการส่งถึงผู้ใช้ได้อย่างน่าเชื่อถือ (รวมถึงการตั้งค่าโครงสร้างพื้นฐานและการ deploy แอปพลิเคชัน) และทำให้ production environment มีเสถียรภาพ (รวมถึงการ monitor และวินิจฉัยปัญหาที่อาจกระทบความน่าเชื่อถือ) สำหรับระบบที่ self-host งาน operations แบบดั้งเดิมมีงานจำนวนมากที่ทำในระดับเครื่องแต่ละเครื่อง เช่น capacity planning (การวางแผนกำลังรองรับ) (เช่น การตรวจสอบพื้นที่ดิสก์ที่มีอยู่ และเพิ่มดิสก์ก่อนที่พื้นที่จะหมด), การ provisioning เครื่องใหม่, การย้ายบริการจากเครื่องหนึ่งไปยังอีกเครื่องหนึ่ง และการติดตั้ง patches ของ operating system

cloud services จำนวนมากนำเสนอ API ที่ซ่อนเครื่องแต่ละเครื่องที่ implement service ตัวอย่างเช่น cloud storage แทนที่ fixed-size disks ด้วย metered billing ซึ่งคุณสามารถจัดเก็บข้อมูลได้โดยไม่ต้องวางแผนความต้องการด้านความจุล่วงหน้า และคุณจะถูกเรียกเก็บตามพื้นที่ที่ใช้ ยิ่งไปกว่านั้น cloud services หลายแห่งยังคง พร้อมใช้งานสูง แม้ว่าเครื่องแต่ละเครื่องจะล้มเหลว (ดู "Reliability and Fault Tolerance" )

การเปลี่ยนแปลงจุดเน้นจากเครื่องแต่ละเครื่องไปยัง services นี้มาพร้อมกับการเปลี่ยนแปลง ในบทบาทของการปฏิบัติการ เป้าหมายระดับสูงของการให้บริการที่เชื่อถือได้ยังคงเหมือนเดิม แต่กระบวนการและเครื่องมือได้พัฒนาไป

ปรัชญา DevOps/SRE ให้ความสำคัญมากขึ้นกับสิ่งต่อไปนี้:

• การใช้ automation โดยเลือกกระบวนการที่ทำซ้ำได้แทนงาน manual ที่ทำครั้งเดียว

• การใช้ ephemeral VMs และ services แทนเซิร์ฟเวอร์ที่รันระยะยาว

• การทำให้อัปเดตแอปพลิเคชันได้บ่อย

• การเรียนรู้จาก incidents

• การรักษาความรู้ขององค์กรเกี่ยวกับระบบไว้ แม้คนจะเข้าๆ ออกๆ [ 34 ]

เมื่อ cloud services เติบโตขึ้น บทบาทก็แยกออกจากกัน ทีม operations ที่บริษัทโครงสร้างพื้นฐานเชี่ยวชาญรายละเอียดของการให้บริการที่เชื่อถือได้แก่ลูกค้าจำนวนมาก ส่วนลูกค้าของบริการใช้เวลาและแรงกับโครงสร้างพื้นฐานให้น้อยที่สุด [ 35 ]

ลูกค้าของ cloud services ก็ยังต้องมี operations เหมือนกัน แต่ไปโฟกัสคนละเรื่อง เช่น การเลือก service ที่เหมาะสมที่สุดสำหรับงานที่กำหนด การบูรณาการ services เข้าด้วยกัน และการย้ายจาก service หนึ่งไปยังอีก service หนึ่ง แม้ metered billing จะทำให้ไม่ต้องทำ capacity planning แบบดั้งเดิมอีกต่อไป แต่ก็ยังต้องรู้ว่าคุณใช้ทรัพยากรอะไรเพื่ออะไร จะได้ไม่เสียเงินไปกับ cloud resources ที่ไม่จำเป็น capacity planning กลายเป็นการวางแผนการเงิน และ performance optimization กลายเป็น cost optimization [ 36 ] นอกจากนี้ cloud services ยังมีข้อจำกัดของทรัพยากรหรือ quotas (เช่น จำนวนสูงสุดของ processes ที่คุณสามารถรันพร้อมกัน) ซึ่งคุณต้องรู้และวางแผนรับมือไว้ก่อนจะไปชนเพดาน [ 37 ]

การใช้ cloud service อาจง่ายและเร็วกว่าการ provision และรันโครงสร้างพื้นฐานเอง แม้คุณจะยังต้องเรียนรู้วิธีใช้ cloud service และอาจต้องหาทางเลี่ยงข้อจำกัดของมันก็ตาม การเชื่อม services เข้าด้วยกันกลายเป็นความท้าทายโดยเฉพาะ เมื่อผู้ขายมากขึ้นเรื่อยๆ เสนอ cloud services ที่หลากหลายขึ้นสำหรับ use cases ที่ต่างกัน [ 38 , 39 ] ETL (ดู "Data Warehousing" ) เป็นเพียงส่วนหนึ่งของเรื่องนี้ operational cloud services ก็ต้องเชื่อมเข้าด้วยกันเช่นกัน ปัจจุบันเรายังไม่มีมาตรฐานที่ช่วยให้การเชื่อมต่อแบบนี้ง่ายขึ้น จึงมักต้องลงแรงทำเองด้วยมืออย่างมาก

งาน operations อื่นๆ ที่จ้าง cloud services ทำแทนไม่ได้ทั้งหมด ได้แก่ การรักษาความปลอดภัยของแอปพลิเคชันและ libraries ที่ใช้ การจัดการปฏิสัมพันธ์ระหว่าง services ของคุณเอง การ monitor load บน services ของคุณ และการหาสาเหตุของปัญหา เช่น performance degradations หรือ outages แม้คลาวด์จะเปลี่ยนบทบาทของ operations แต่ความจำเป็นของ operations ก็ยังสำคัญเหมือนเดิม

Distributed Versus Single-Node Systems (ระบบกระจายเทียบกับระบบโหนดเดียว)

ระบบที่เกี่ยวข้องกับหลายเครื่องที่สื่อสารผ่าน network เรียกว่า distributed system แต่ละ process ที่เข้าร่วมใน distributed system เรียกว่า node คุณอาจต้องการใช้ระบบประเภทนี้ด้วยเหตุผลหลายประการ:

Inherent distribution (การกระจายตัวโดยธรรมชาติ)

ถ้าแอปพลิเคชันเกี่ยวข้องกับผู้ใช้สองคนขึ้นไปที่โต้ตอบกัน โดยแต่ละคนใช้อุปกรณ์ของตนเอง ระบบก็ต้องเป็น distributed อย่างหลีกเลี่ยงไม่ได้: การสื่อสารระหว่างอุปกรณ์ต้องผ่าน network

Requests between cloud services (การเรียกกันระหว่าง cloud services)

ถ้าข้อมูลถูกจัดเก็บใน service หนึ่งแต่ประมวลผลในอีก service หนึ่ง ข้อมูลนั้นต้องถูกโอนย้ายผ่าน network จาก service หนึ่งไปยังอีก service หนึ่ง Cloud native systems และ microservices (ดู "Microservices and Serverless" ) จึงเป็น distributed

Fault tolerance/high availability (ความทนทานต่อความผิดพลาด/ความพร้อมใช้งานสูง)

ถ้า แอปพลิเคชันของคุณต้องทำงานต่อไปได้แม้ว่าเครื่องหนึ่งเครื่อง (หรือหลายเครื่อง หรือ network หรือ datacenter ทั้งหมด) จะล้มเหลว คุณสามารถใช้หลายเครื่องเพื่อให้มีความซ้ำซ้อน เมื่อเครื่องหนึ่งล้มเหลว อีกเครื่องหนึ่งก็สามารถทำงานแทนได้ ดู "Reliability and Fault Tolerance" และ บท 6 .

Scalability (ความสามารถในการปรับขนาด)

ถ้า ปริมาณข้อมูลหรือข้อกำหนดด้านการคำนวณของคุณใหญ่กว่าเครื่องเดียวจะจัดการได้ คุณอาจกระจาย load ไปยังหลายเครื่องได้ ดู "Scalability" .

Latency (ความหน่วง)

ถ้าคุณมีผู้ใช้ทั่วโลก คุณอาจต้องการมีเซิร์ฟเวอร์ในหลายภูมิภาคทั่วโลก เพื่อให้ผู้ใช้แต่ละคนสามารถรับบริการจากเซิร์ฟเวอร์ที่อยู่ใกล้ทางภูมิศาสตร์ ซึ่งหลีกเลี่ยงไม่ให้ผู้ใช้ต้องรอให้ network packets เดินทางข้ามครึ่งโลกเพื่อตอบคำขอของพวกเขา ดู "Describing Performance" .

Elasticity (ความยืดหยุ่น)

ถ้าแอปพลิเคชันของคุณบางช่วงยุ่งมากและบางช่วงว่าง การ deploy บนคลาวด์สามารถ scale ขึ้นหรือลงตามความต้องการ คุณจึงจ่ายเฉพาะทรัพยากรที่ใช้งานจริง ซึ่งทำได้ยากกว่าบนเครื่องเดียว เพราะต้อง provision ให้รองรับ load สูงสุด แม้ในช่วงที่แทบไม่มีใครใช้งาน

Specialized hardware (ฮาร์ดแวร์เฉพาะทาง)

ส่วนต่างๆ ของระบบสามารถใช้ประโยชน์จากฮาร์ดแวร์ประเภทต่างๆ เพื่อให้ตรงกับ workload ของตน ตัวอย่างเช่น object store อาจใช้เครื่องที่มีหลายดิสก์แต่ CPU น้อย ส่วนระบบวิเคราะห์ข้อมูลอาจใช้เครื่องที่มี CPU และหน่วยความจำมากแต่ไม่มีดิสก์ และระบบ machine learning อาจใช้เครื่องที่มี GPUs (ซึ่งมีประสิทธิภาพกว่า CPUs มากสำหรับ training deep neural networks และงาน ML อื่นๆ)

Legal compliance (การปฏิบัติตามกฎหมาย)

บางประเทศมีกฎหมาย data residency ที่กำหนดให้ข้อมูลเกี่ยวกับบุคคลในเขตอำนาจศาลของตน ต้องถูกจัดเก็บและประมวลผลภายในประเทศนั้น [ 40 ] ขอบเขตของกฎเหล่านี้แตกต่างกัน—ตัวอย่างเช่น ในบางกรณีใช้กับข้อมูลทางการแพทย์หรือการเงินเท่านั้น แต่บางกรณีครอบคลุมกว้างกว่านั้น service ที่มีผู้ใช้ในหลายเขตอำนาจดังกล่าวจึงต้องกระจายข้อมูลของผู้ใช้ไปไว้บนเซิร์ฟเวอร์ในหลายสถานที่

Sustainability (ความยั่งยืน)

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

เหตุผลเหล่านี้ใช้ได้กับทั้ง services ที่คุณเขียนเอง (application code) และ services ที่ประกอบด้วย ซอฟต์แวร์สำเร็จรูป (เช่น databases)

Problems with Distributed Systems (ปัญหาของระบบกระจาย)

Distributed systems ก็มีข้อเสียเช่นกัน ทุก request และ API call ที่ผ่าน network ต้องรับมือกับความเป็นไปได้ที่จะล้มเหลว network อาจถูกขัดจังหวะ หรือ service อาจ overload หรือ crash ดังนั้น request ใดๆ ก็อาจ timeout โดยไม่ได้รับ response ในกรณีนี้เราไม่รู้ว่า service ได้รับ request แล้วหรือไม่ และการ retry เฉยๆ อาจไม่ปลอดภัย เราจะพูดถึงปัญหาเหล่านี้โดยละเอียดใน บท 9 .

แม้ว่า datacenter networks จะเร็ว แต่การเรียกไปยัง service อื่นก็ยังช้ากว่า การเรียกฟังก์ชันใน process เดียวกันมาก [ 43 ] เมื่อทำงานกับข้อมูลปริมาณมาก แทนที่จะโอนย้ายข้อมูลจาก storage ไปยังเครื่องแยกที่ประมวลผลมัน การนำการคำนวณไปยังเครื่องที่มีข้อมูลอยู่แล้วอาจจะเร็วกว่า [ 44 ] node มากขึ้นไม่ได้แปลว่าเร็วขึ้นเสมอไป ในบางกรณี โปรแกรม single-threaded ง่ายๆ บนเครื่องเดียวสามารถทำงานได้ดีกว่าอย่างมีนัยสำคัญ เมื่อเทียบกับคลัสเตอร์ที่มี CPU cores มากกว่า 100 ตัว [ 45 ]

การ debug ปัญหาใน distributed system มักจะยาก—ถ้าระบบตอบสนองช้า คุณจะหาสาเหตุได้อย่างไร? เทคนิคสำหรับการวินิจฉัยปัญหาใน distributed systems ถูกพัฒนาขึ้นภายใต้แนวคิด observability [ 46 , 47 ] ซึ่งหมายถึงการเก็บข้อมูลเกี่ยวกับการทำงานของระบบ และเปิดให้ query ข้อมูลนั้นได้ในรูปแบบที่วิเคราะห์ได้ทั้ง metrics ระดับสูงและ events แต่ละรายการ Tracing tools เช่น OpenTelemetry, Zipkin และ Jaeger ช่วยให้คุณติดตามว่า client ใดเรียก server ใดสำหรับ operation ใด และแต่ละ call ใช้เวลานานเท่าไร [ 48 ]

Databases มีกลไกต่างๆ เพื่อรับประกันความสอดคล้องของข้อมูล ดังที่เราจะเห็นในบท 6 และ 8 อย่างไรก็ตาม เมื่อแต่ละ service มี database ของตัวเอง การรักษาความสอดคล้องของข้อมูลข้าม services เหล่านั้นจึงกลายเป็นปัญหาของ application Distributed transactions ซึ่งเราจะสำรวจใน บท 8 เป็นเทคนิคหนึ่งที่ใช้รักษาความสอดคล้องได้ แต่ไม่ค่อยถูกใช้ในบริบท microservices เพราะขัดกับเป้าหมายที่ต้องการให้ services เป็นอิสระจากกัน และ databases จำนวนมากก็ไม่รองรับ [ 49 ]

ด้วยเหตุผลทั้งหมดนี้ การทำงานบนเครื่องเดียวมักง่ายกว่าและถูกกว่าการตั้งค่า distributed system มาก [ 22 , 45 , 50 ] CPUs, หน่วยความจำ และดิสก์มีขนาดใหญ่ขึ้น เร็วขึ้น และน่าเชื่อถือขึ้น เมื่อใช้ร่วมกับ single-node databases เช่น DuckDB, SQLite และ KùzuDB ทำให้ตอนนี้หลาย workloads รันบน node เดียวได้แล้ว เราจะสำรวจหัวข้อนี้เพิ่มเติมใน บท 4 .

Microservices and Serverless (Microservices และ Serverless)

วิธีที่พบมากที่สุดในการกระจายระบบไปยังหลายเครื่องคือแบ่งเป็น clients และ servers แล้วให้ clients ส่ง requests ไปยัง servers ส่วนใหญ่ใช้ HTTP ในการสื่อสารนี้ ดังที่เราจะพูดถึงใน "Dataflow Through Services: REST and RPC" process เดียวกันอาจเป็นได้ทั้ง server (จัดการ requests ขาเข้า) และ client (ส่ง requests ขาออกไปยัง services อื่น)

วิธีสร้างแอปพลิเคชันแบบนี้เดิมเรียกว่า service-oriented architecture (SOA); ต่อมาแนวคิดนี้ถูกพัฒนาต่อเป็น microservices architecture [ 51 , 52 ] ใน microservices architecture แต่ละ service มีหน้าที่ที่กำหนดไว้ชัดเจนหนึ่งอย่าง (เช่น ในกรณีของ S3 คือ file storage); แต่ละ service เปิด API ให้ client เรียกผ่าน network และมีทีมเดียวที่รับผิดชอบดูแล แอปพลิเคชันที่ซับซ้อนจึงแยกออกเป็นหลาย services ที่โต้ตอบกัน โดยแต่ละตัวมีทีมแยกต่างหากดูแล Cloud native systems พึ่งพาการแยกเป็น services อย่างมาก แต่ระบบ on-premises ก็สามารถใช้แนวทางแบบ service-oriented ได้เช่นกัน

การแบ่งซอฟต์แวร์ที่ซับซ้อนออกเป็นหลาย services มีข้อดีหลายประการ: แต่ละ service อัปเดตได้อย่างอิสระ ลดความพยายามในการประสานงานระหว่างทีม; แต่ละ service ได้รับทรัพยากรฮาร์ดแวร์ตามที่ต้องการ; และการซ่อนรายละเอียด implementation ไว้หลัง API ทำให้เจ้าของ service เปลี่ยน implementation ได้อย่างอิสระโดยไม่กระทบ clients ในแง่ของการจัดเก็บข้อมูล เป็นเรื่องปกติที่แต่ละ service จะมี databases ของตัวเอง และไม่แชร์ databases ระหว่าง services การแชร์ database จะทำให้โครงสร้างของ database ทั้งหมดกลายเป็นส่วนหนึ่งของ API ของ service โดยปริยาย ซึ่งทำให้เปลี่ยนแปลงโครงสร้างนั้นได้ยาก นอกจากนี้ database ที่ใช้ร่วมกันยังอาจทำให้ queries ของ service หนึ่งกระทบประสิทธิภาพของ services อื่นด้วย

ในทางกลับกัน การมี services จำนวนมากก็สร้างความซับซ้อนขึ้นมาเอง การทดสอบ service ระหว่างพัฒนาอาจยุ่งยาก เพราะต้องรัน services อื่นๆ ทั้งหมดที่มัน depend อยู่ ยิ่งไปกว่านั้น แต่ละ service ต้องมีโครงสร้างพื้นฐานสำหรับ deploy เวอร์ชันใหม่ ปรับทรัพยากรฮาร์ดแวร์ที่จัดสรรให้ตรงกับ load เก็บ logs ตรวจสอบสุขภาพ (health) ของ service และแจ้งเตือนวิศวกรที่อยู่เวรเมื่อเกิดปัญหา Orchestration frameworks เช่น Kubernetes ได้กลายเป็นวิธียอดนิยมในการ deploy services เพราะให้พื้นฐานสำหรับโครงสร้างพื้นฐานเหล่านี้

นอกจากนี้ microservice APIs ยังพัฒนาได้ยาก เพราะ clients ที่เรียก API คาดหวังว่าจะมี field บางอย่าง นักพัฒนาอาจอยากเพิ่มหรือลบ field ใน API เมื่อความต้องการทางธุรกิจเปลี่ยนไป แต่การทำแบบนั้นอาจทำให้ clients พัง ที่แย่กว่านั้นคือ ความล้มเหลวแบบนี้มักไม่ถูกค้นพบจนกว่าจะถึงช่วงท้ายของ development cycle เมื่อ service API เวอร์ชันที่อัปเดตถูก deploy ไปยัง staging หรือ production มาตรฐานสำหรับอธิบาย API เช่น OpenAPI และ gRPC ช่วยจัดการความสัมพันธ์ระหว่าง client และ server APIs เราจะพูดถึงเรื่องนี้เพิ่มเติมใน บท 5 .

Microservices เป็นวิธีแก้ปัญหาเรื่องคนทางเทคนิคเป็นหลัก คือทำให้แต่ละทีมทำงานคืบหน้าได้อย่างอิสระโดยไม่ต้องประสานงานกัน ซึ่งมีค่าในบริษัทขนาดใหญ่ แต่ในบริษัทขนาดเล็กที่มีทีมน้อยกว่า การใช้ microservices มักเป็น overhead ที่ไม่จำเป็น และควร implement แอปพลิเคชันด้วยวิธีที่ง่ายที่สุดเท่าที่เป็นไปได้ [ 51 ]

Serverless , หรือ function as a service (FaaS) เป็นอีกแนวทางหนึ่งในการ deploy services ซึ่งการดูแลโครงสร้างพื้นฐานถูกจ้างให้ผู้ให้บริการคลาวด์ทำแทน [ 32 ] เมื่อใช้ VMs คุณต้องตัดสินใจเองว่าจะ start หรือ shut down instance เมื่อใด ส่วนในโมเดล serverless cloud provider จะจัดสรรและคืนทรัพยากรฮาร์ดแวร์ให้โดยอัตโนมัติตามความจำเป็น ขึ้นอยู่กับ requests ขาเข้าที่ส่งมายัง service ของคุณ [ 53 ] เช่นเดียวกับที่ cloud storage ใช้ metered billing มาแทน capacity planning (การตัดสินใจล่วงหน้าว่าจะซื้อดิสก์กี่ตัว) แนวทาง serverless ก็นำ metered billing มาสู่การรันโค้ด: คุณจ่ายเฉพาะเวลาที่ application code ของคุณกำลังทำงาน แทนที่จะต้อง provision ทรัพยากรล่วงหน้า

เพื่อให้ได้ข้อดีดังกล่าว ผู้ให้บริการ serverless จำนวนมากจึงกำหนด time limit ให้การรันฟังก์ชันและจำกัดสภาพแวดล้อม runtime และ services อาจเจอปัญหา slow start เมื่อฟังก์ชันถูกเรียกครั้งแรก คำว่า "serverless" อาจทำให้เข้าใจผิด; serverless function แต่ละครั้งที่รันก็ยังรันบน server แต่ครั้งถัดไปอาจรันบน server คนละเครื่อง ยิ่งไปกว่านั้น บริการโครงสร้างพื้นฐาน เช่น BigQuery และบริการ Kafka ต่างๆ ก็หยิบคำว่า "serverless" มาใช้เพื่อสื่อว่า services ของตน autoscale ได้ และคิดค่าใช้จ่ายตามการใช้งานจริงแทนที่จะคิดตาม instances

Cloud Computing Versus Supercomputing (คลาวด์คอมพิวติ้งเทียบกับซูเปอร์คอมพิวติ้ง)

Cloud computing ไม่ใช่วิธีเดียวในการสร้างระบบคอมพิวเตอร์ขนาดใหญ่ อีกทางเลือกหนึ่งคือ high-performance computing (HPC) หรือที่เรียกว่า supercomputing แม้จะมีส่วนที่ทับซ้อนกัน แต่ HPC มักมีลำดับความสำคัญและใช้เทคนิคที่ต่างจาก cloud computing และ enterprise datacenter systems นี่คือความแตกต่างหลักบางประการ:

• Supercomputers มักใช้กับงานคำนวณทางวิทยาศาสตร์ที่ใช้พลังคำนวณสูง เช่น การพยากรณ์อากาศ การสร้างแบบจำลองสภาพภูมิอากาศ molecular dynamics (การจำลองการเคลื่อนที่ของ อะตอมและโมเลกุล) ปัญหาการหาค่าเหมาะที่สุดที่ซับซ้อน และการแก้ partial differential equations ส่วน cloud computing มักใช้กับ online services ระบบข้อมูลทางธุรกิจ และระบบที่คล้ายกันซึ่งต้องให้บริการ requests ของผู้ใช้ด้วยความพร้อมใช้งานสูง

• Supercomputer โดยทั่วไปรัน batch jobs ขนาดใหญ่ที่ checkpoint สถานะของการคำนวณลงดิสก์เป็นระยะ ถ้า node ล้มเหลว วิธีแก้ไขทั่วไปคือหยุด workload ทั้งหมดของคลัสเตอร์ ซ่อม node ที่เสีย แล้วเริ่มการคำนวณใหม่จาก checkpoint ล่าสุด [ 54 , 55 ] แต่กับ cloud services การหยุดทั้ง cluster มักไม่เป็นที่ต้องการ เพราะ services ต้องให้บริการผู้ใช้ต่อเนื่องโดยสะดุดให้น้อยที่สุด

• node ของ supercomputer โดยทั่วไปสื่อสารผ่าน shared memory และ RDMA ซึ่งรองรับ bandwidth สูงและ latency ต่ำ แต่ตั้งสมมติฐานว่าผู้ใช้ระบบไว้ใจกันในระดับสูง [ 56 ] ใน cloud computing network และเครื่องต่างๆ มักถูกใช้ร่วมกัน โดยองค์กรที่ไม่ไว้ใจกัน จึงต้องมีกลไกด้านความปลอดภัยที่เข้มแข็งกว่า เช่น resource isolation (เช่น virtual machines), encryption และ authentication

• Cloud datacenter networks มักใช้ IP และ Ethernet จัดเรียงใน Clos topologies เพื่อให้ bisection bandwidth สูง ซึ่งเป็นตัววัดประสิทธิภาพโดยรวมของ network ที่ใช้กันทั่วไป [ 54 , 57 ] Supercomputers มักใช้ network topologies เฉพาะทาง เช่น multidimensional meshes และ toruses [ 58 ] ซึ่งให้ประสิทธิภาพดีกว่าสำหรับ HPC workloads ที่มีรูปแบบการสื่อสาร ที่ทราบ .

• Cloud computing ให้ nodes กระจายอยู่ในหลายภูมิภาคทางภูมิศาสตร์ได้ ส่วน supercomputers โดยทั่วไปสมมติว่า nodes ทั้งหมดอยู่ใกล้กัน

analytical systems ขนาดใหญ่บางครั้งมีลักษณะร่วมกับ supercomputing การรู้เทคนิคเหล่านี้จึงมีประโยชน์ถ้าคุณทำงานในด้านนี้ อย่างไรก็ตาม หนังสือเล่มนี้ส่วนใหญ่เกี่ยวข้องกับ services ที่ต้องพร้อมใช้งานอย่างต่อเนื่อง ดังที่กล่าวถึงใน "Reliability and Fault Tolerance" .

Data Systems, Law, and Society (ระบบข้อมูล กฎหมาย และสังคม)

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

ข้อกังวลเฉพาะประการหนึ่งคือระบบที่จัดเก็บข้อมูลเกี่ยวกับบุคคลและพฤติกรรมของพวกเขา ตั้งแต่ปี 2018 GDPR ให้ผู้อยู่อาศัยในหลายประเทศในยุโรปมีสิทธิ์ควบคุมข้อมูลส่วนบุคคลของตนและมีสิทธิ์ทางกฎหมายเหนือข้อมูลนั้นมากขึ้น และมีการออกกฎระเบียบความเป็นส่วนตัวที่คล้ายกันในประเทศและรัฐอื่นๆ ทั่วโลก (รวมถึง CCPA เป็นต้น) กฎระเบียบเกี่ยวกับ AI เช่น EU AI Act ก็วางข้อจำกัดเพิ่มเติมเกี่ยวกับวิธีใช้ข้อมูลส่วนบุคคล

ยิ่งไปกว่านั้น แม้ในพื้นที่ที่ไม่มีข้อบังคับโดยตรง ก็ยิ่งมีการยอมรับมากขึ้นถึงผลกระทบที่ระบบคอมพิวเตอร์มีต่อผู้คนและสังคม สื่อสังคมออนไลน์เปลี่ยนวิธีที่ผู้คนรับข่าว ซึ่งมีอิทธิพลต่อความคิดเห็นทางการเมืองและอาจส่งผลต่อผลการเลือกตั้ง ระบบอัตโนมัติก็ตัดสินใจเรื่องที่มีผลกระทบอย่างลึกซึ้งต่อบุคคลมากขึ้นเรื่อยๆ เช่น ใครควรได้รับสินเชื่อหรือความคุ้มครองประกันภัย ใครควรได้รับเชิญให้สัมภาษณ์งาน หรือใครควรถูกสงสัยว่าก่ออาชญากรรม [ 59 ]

ทุกคนที่ทำงานกับระบบเหล่านี้มีส่วนรับผิดชอบในการพิจารณาผลกระทบทางจริยธรรมของการตัดสินใจของตน และทำให้แน่ใจว่าปฏิบัติตามกฎหมายที่เกี่ยวข้อง ไม่จำเป็นที่ทุกคนต้องเป็นผู้เชี่ยวชาญด้านกฎหมายและจริยธรรม แต่ความเข้าใจพื้นฐานเกี่ยวกับหลักการทางกฎหมายและจริยธรรมก็สำคัญพอๆ กับความรู้พื้นฐานเรื่อง distributed systems

ข้อพิจารณาทางกฎหมายกำลังมีอิทธิพลต่อพื้นฐานการออกแบบ data system [ 60 ] ตัวอย่างเช่น GDPR ให้สิทธิ์บุคคลในการขอให้ลบข้อมูลของตน (บางครั้งเรียกว่า right to be forgotten ) อย่างไรก็ตาม ดังที่เราจะเห็นในหนังสือเล่มนี้ หลาย data systems พึ่งพา immutable constructs เช่น append-only logs เป็นส่วนหนึ่งของการออกแบบ เราจะลบข้อมูลบางส่วนที่อยู่ตรงกลางของไฟล์ที่ควรเป็น immutable ได้อย่างไร? เราจะจัดการกับการลบข้อมูลที่ถูกรวมเข้าไปใน derived datasets (ดู "Systems of Record and Derived Data" ) เช่น training data สำหรับ ML models ได้อย่างไร? คำถามเหล่านี้ก่อให้เกิดความท้าทายทางวิศวกรรมใหม่ๆ

ในปัจจุบัน เรายังไม่มีแนวทางที่ชัดเจนว่าเทคโนโลยีหรือสถาปัตยกรรมระบบแบบใดที่ถือว่าเป็นไปตาม GDPR กฎระเบียบจงใจไม่กำหนดเทคโนโลยีเฉพาะ เพราะเทคโนโลยีอาจเปลี่ยนแปลงอย่างรวดเร็วตามการพัฒนา แต่ตัวบทกฎหมายกำหนดหลักการระดับสูงที่ต้องอาศัยการตีความ ดังนั้นการปฏิบัติตามกฎระเบียบความเป็นส่วนตัวจึงไม่มีคำตอบง่ายๆ แต่เราจะดูเทคโนโลยีบางอย่างผ่านมุมมองนี้

โดยทั่วไปแล้ว เราจัดเก็บข้อมูลเพราะเชื่อว่ามูลค่าของมันมากกว่าต้นทุนการจัดเก็บ อย่างไรก็ตาม ควรจำไว้ว่าต้นทุนการจัดเก็บไม่ได้มีแค่ค่าบริการที่คุณจ่ายให้ S3 หรือ service อื่น การคำนวณต้นทุนเทียบกับประโยชน์ควรคำนึงถึงความเสี่ยงด้านความรับผิดและความเสียหายต่อชื่อเสียงหากข้อมูลรั่วไหลหรือถูก adversaries เจาะระบบ รวมถึงความเสี่ยงที่จะเสียค่าใช้จ่ายทางกฎหมายและค่าปรับหากการจัดเก็บและประมวลผลข้อมูลถูกพบว่าไม่เป็นไปตามกฎหมาย [ 50 ]

รัฐบาลหรือตำรวจอาจบังคับให้บริษัทส่งมอบข้อมูลได้เช่นกัน เมื่อข้อมูลอาจเปิดเผยพฤติกรรมที่ถือเป็นอาชญากรรม (เช่น การรักร่วมเพศในหลายประเทศในตะวันออกกลางและแอฟริกา หรือการทำแท้งในหลายรัฐของสหรัฐอเมริกา) การจัดเก็บข้อมูลนั้นก่อให้เกิดความเสี่ยงด้านความปลอดภัยที่แท้จริงต่อผู้ใช้ ตัวอย่างเช่น การเดินทางไปคลินิกทำแท้งอาจถูกเปิดเผยได้ง่ายจากข้อมูลตำแหน่ง หรืออาจแม้แต่จาก log ของที่อยู่ IP ของผู้ใช้ตลอดช่วงเวลาหนึ่ง (ซึ่งบ่งบอกตำแหน่งโดยประมาณ)

เมื่อพิจารณาความเสี่ยงทั้งหมดแล้ว อาจเป็นเรื่องสมเหตุสมผลที่จะตัดสินใจว่าข้อมูลบางอย่าง ไม่คุ้มค่าที่จะจัดเก็บ และควรลบทิ้ง หลักการของ data minimization (บางครั้งเรียกด้วยคำภาษาเยอรมันว่า Datensparsamkeit ) ขัดแย้งกับปรัชญา "big data" ของการจัดเก็บข้อมูลจำนวนมากแบบคาดเดา เผื่อว่าจะมีประโยชน์ในอนาคต [ 61 ] แต่ data minimization สอดคล้องกับ GDPR ซึ่งกำหนดว่าข้อมูลส่วนบุคคลอาจถูกเก็บรวบรวมเพื่อวัตถุประสงค์ที่ระบุและชัดเจนเท่านั้น ไม่สามารถใช้เพื่อวัตถุประสงค์อื่นในภายหลัง และต้องไม่ถูกเก็บไว้นานเกินความจำเป็น สำหรับวัตถุประสงค์ที่มันถูกรวบรวม [ 62 ]

ธุรกิจก็ได้ให้ความสนใจกับข้อกังวลด้านความเป็นส่วนตัวและความปลอดภัยเช่นกัน บริษัทบัตรเครดิตกำหนดให้ธุรกิจที่ประมวลผลการชำระเงินต้องปฏิบัติตามมาตรฐาน Payment Card Industry (PCI) ผู้ประมวลผลได้รับการประเมินจากผู้ตรวจสอบบัญชีอิสระเป็นประจำเพื่อยืนยันการปฏิบัติตามอย่างต่อเนื่อง ผู้ขายซอฟต์แวร์ก็เห็นการตรวจสอบที่เพิ่มขึ้นเช่นกัน ผู้ซื้อจำนวนมากในขณะนี้กำหนดให้ผู้ขายของพวกเขาปฏิบัติตามมาตรฐาน Service Organization Control (SOC) Type 2 เช่นเดียวกับการปฏิบัติตาม PCI ผู้ขายผ่านการตรวจสอบจากบุคคลที่สามเพื่อยืนยันการปฏิบัติตาม

โดยทั่วไปแล้ว การสร้างสมดุลระหว่างความต้องการของธุรกิจของคุณกับความต้องการของบุคคลที่คุณกำลัง รวบรวมและประมวลผลข้อมูลเป็นสิ่งสำคัญ มีอะไรมากกว่านี้ในหัวข้อนี้ ใน บท 14 เราจะลงลึกไปในจริยธรรมและการปฏิบัติตามกฎหมาย รวมถึงปัญหาของ bias และ discrimination

Summary (สรุป)

ธีมของบทนี้คือการทำความเข้าใจ trade-off นั่นคือการตระหนักว่าคำถามหลายข้อไม่ได้มีคำตอบที่ถูกต้องเพียงข้อเดียว แต่มีหลายความเป็นไปได้ที่แต่ละทางมีทั้งข้อดีและข้อเสีย เราสำรวจตัวเลือกสำคัญบางอย่างที่ส่งผลต่อสถาปัตยกรรมของ data systems และแนะนำคำศัพท์ที่จะใช้ตลอดส่วนที่เหลือของหนังสือเล่มนี้

เราเริ่มจากแยกความแตกต่างระหว่าง operational (transaction processing, OLTP) และ analytical (OLAP) systems และดูว่าทั้งสองต่างกันอย่างไร ไม่ได้ต่างแค่ที่จัดการข้อมูลคนละประเภทซึ่งมีรูปแบบการเข้าถึงต่างกัน แต่ยังรองรับผู้ใช้คนละกลุ่มด้วย ระหว่างทางเราได้รู้จักแนวคิดของ data warehouse และ data lake ซึ่งรับข้อมูลจาก operational systems ผ่าน ETL ใน บท 4 เราจะเห็นว่า operational และ analytical systems มักใช้ data layouts ภายในที่แตกต่างกันมาก เพราะ queries ที่ต้องรองรับต่างกัน

จากนั้นเราเปรียบเทียบ cloud services ซึ่งเป็นพัฒนาการที่ค่อนข้างใหม่ กับแนวทางดั้งเดิมแบบซอฟต์แวร์ self-hosted ที่เคยครอบงำสถาปัตยกรรม data systems มาก่อน แนวทางไหนคุ้มค่ากว่าขึ้นอยู่กับสถานการณ์เฉพาะของคุณเป็นอย่างมาก แต่ปฏิเสธไม่ได้ว่าแนวทาง cloud native กำลังนำการเปลี่ยนแปลงครั้งใหญ่มาสู่วิธีออกแบบ data systems เช่น การแยก storage และ compute ออกจากกัน

Cloud systems เป็น distributed โดยเนื้อแท้ และเราได้พิจารณาอย่างคร่าวๆ ถึง trade-off บางอย่างของ distributed systems เมื่อเทียบกับการใช้เครื่องเดียว ในบางสถานการณ์คุณเลี่ยงการกระจายระบบไม่ได้ แต่ก็ไม่ควรรีบทำให้ระบบเป็น distributed ถ้ายังเก็บไว้บนเครื่องเดียวได้ ใน บท 9 เราจะครอบคลุมความท้าทายของ distributed systems ในรายละเอียดมากขึ้น

สุดท้าย เราเห็นว่าสถาปัตยกรรมของ data system ไม่ได้ถูกกำหนดโดยความต้องการของธุรกิจที่ deploy ระบบเท่านั้น แต่ยังรวมถึงกฎระเบียบความเป็นส่วนตัวที่ปกป้องสิทธิ์ของบุคคลที่ข้อมูลกำลังถูกประมวลผล ซึ่งเป็นแง่มุมที่วิศวกรจำนวนมากมักมองข้าม ยังไม่มีแนวทางที่เป็นระบบแน่ชัดว่าจะแปลข้อกำหนดทางกฎหมายเป็นการ implement ทางเทคนิคอย่างไร แต่การคำนึงถึงคำถามนี้ไปตลอดส่วนที่เหลือของหนังสือเล่มนี้เป็นสิ่งสำคัญ