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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ความแตกต่างระหว่าง 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 เป็นรูปแบบที่ friendly ต่อการวิเคราะห์ ทําความสะอาด แล้ว 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 มักถูก implement โดยบริการเชื่อมต่อข้อมูลเฉพาะทาง เช่น 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" ) ซึ่งนําไปสู่ databases ปฏิบัติการที่แยกจากกันหลายร้อยแห่ง ในทางกลับกัน องค์กรมักจะมี data warehouse เดียว เพื่อให้ business analysts สามารถรวมข้อมูลจาก หลาย operational systems ใน query เดียว

ดังนั้น HTAP จึงไม่ได้แทนที่ data warehouses แต่จะมีประโยชน์เมื่อแอปพลิเคชันเดียวกันต้อง ทั้งทํา analytical queries ที่ scan จํานวน rows มาก และอ่าน/update แต่ละ records ด้วย 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 ที่ทํางานเช่น:

• การแปลงข้อมูลให้อยู่ในรูปแบบที่เหมาะสมสําหรับ training 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 ในแง่ที่ว่ามันซ้ำซ้อนกับข้อมูลที่มีอยู่ อย่างไรก็ตาม ข้อมูลนี้มักจําเป็นสําหรับการให้ ประสิทธิภาพที่ดีในการอ่าน query คุณสามารถสร้าง derived datasets หลายชุดจากแหล่งเดียว ทําให้คุณสามารถมองข้อมูลจากมุมมองที่แตกต่างกัน

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

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

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

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

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

สําหรับทุกสิ่งที่องค์กรต้องทํา คําถามแรกๆ คือควรทําภายในองค์กรหรือจ้างบุคคลภายนอก นั่นคือ คุณควรสร้างเองหรือซื้อ?

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

ด้วยซอฟต์แวร์ มีการตัดสินใจสําคัญสองอย่างคือ ใครเป็นคนสร้างซอฟต์แวร์และใครเป็นคน deploy สเปกตรัมของความเป็นไปได้แสดงใน รูป 1-2 ด้านหนึ่งสุดคือ bespoke software ที่คุณเขียนและรันภายในองค์กร อีกด้านหนึ่งคือ cloud services หรือ SaaS products ที่ใช้กันอย่างแพร่หลาย ซึ่ง implement และดําเนินการโดยผู้ขายภายนอก และคุณเข้าถึงผ่านเว็บอินเทอร์เฟซหรือ 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 ของคุณค่อนข้าง predictable (คือ จํานวนเครื่องที่คุณต้องการ ไม่ผันผวนอย่างรุนแรง) การซื้อเครื่องของคุณเองและรันซอฟต์แวร์บนเครื่องเหล่านั้นมักจะถูกกว่า [ 21 , 22 ]

ในทางกลับกัน ถ้าคุณต้องการระบบที่คุณยังไม่รู้วิธี deploy และดําเนินการ การใช้ cloud service มักจะง่ายกว่าและเร็วกว่าการเรียนรู้ที่จะจัดการระบบ การจ้างและฝึกอบรมพนักงานเพื่อดูแลและดําเนินการระบบโดยเฉพาะอาจมีราคาแพงมาก คุณยังคงต้องมีทีมปฏิบัติการเมื่อใช้คลาวด์ (ดู "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 ได้ ด้วยบริการที่ hosted โดยผู้ขาย คุณมักจะไม่สามารถเข้าถึงรายละเอียดภายในเหล่านี้ได้

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

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

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

แม้จะมีความเสี่ยงทั้งหมดนี้ การสร้างแอปพลิเคชันใหม่บน cloud services หรือใช้แนวทางแบบ hybrid ที่ใช้ cloud services สําหรับบางส่วนของระบบก็ได้รับความนิยมมากขึ้นเรื่อยๆ อย่างไรก็ตาม cloud services จะไม่เข้ามาแทนที่ data systems ภายในองค์กรทั้งหมด ระบบเก่าจํานวนมากมีมาก่อนคลาวด์ และสําหรับบริการใดๆ ที่มีข้อกําหนดเฉพาะทางที่ cloud services ที่มีอยู่ไม่สามารถตอบสนองได้ ระบบภายในองค์กรก็ยังคงจําเป็น ตัวอย่างเช่น แอปพลิเคชันที่ sensitive ต่อ 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-hosted จํานวนมากมีข้อกําหนดของระบบที่เรียบง่าย พวกมันรันบน operating system ทั่วไป เช่น Linux หรือ Windows จัดเก็บข้อมูลเป็นไฟล์บน filesystem และสื่อสารผ่าน network protocols มาตรฐาน เช่น TCP/IP มีบางระบบที่ depend บน hardware พิเศษ เช่น GPUs (สําหรับ ML) หรือ remote direct memory access (RDMA) network interfaces แต่โดยรวมแล้ว ซอฟต์แวร์ที่ self-hosted มักจะใช้ทรัพยากรคอมพิวเตอร์ทั่วไป: CPUs, RAM, filesystem และ IP network

ในคลาวด์ ซอฟต์แวร์ประเภทนี้สามารถรันใน สภาพแวดล้อม IaaS โดยใช้ VM หนึ่งตัวหรือมากกว่า (หรือ instances ) ด้วยการจัดสรร CPUs, หน่วยความจํา, ดิสก์ และ 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 ยังทําให้แอปพลิเคชัน sensitive ต่อ 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 ขนาดใหญ่ (ที่มี many individual values) ไว้ใน 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 (การปฏิบัติการในยุคคลาวด์)

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

บทบาทของการปฏิบัติการคือการรับประกันว่าบริการต่างๆ ถูกส่งถึงผู้ใช้อย่างน่าเชื่อถือ (รวมถึงการกําหนดค่าโครงสร้างพื้นฐานและการ deploy แอปพลิเคชัน) และเพื่อให้แน่ใจถึง สภาพแวดล้อมการผลิตที่เสถียร (รวมถึงการตรวจสอบและวินิจฉัยปัญหาที่อาจส่งผลต่อความน่าเชื่อถือ) สําหรับระบบที่ self-hosted การปฏิบัติการแบบดั้งเดิมเกี่ยวข้องกับงานจํานวนมากในระดับ ของเครื่องแต่ละเครื่อง เช่น การวางแผนกําลังการผลิต (เช่น การตรวจสอบพื้นที่ดิสก์ที่มีอยู่ และเพิ่มดิสก์ก่อนที่พื้นที่จะหมด), การ 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 ให้ความสําคัญมากขึ้นกับสิ่งต่อไปนี้:

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

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

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

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

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

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

ลูกค้าของ cloud services ยังคงต้องการการปฏิบัติการ แต่พวกเขามุ่งเน้นในด้านที่แตกต่างกัน เช่น การเลือก service ที่เหมาะสมที่สุดสําหรับงานที่กําหนด การบูรณาการ services เข้าด้วยกัน และการย้ายจาก service หนึ่งไปยังอีก service หนึ่ง แม้ว่า metered billing จะขจัดความจําเป็น ในการวางแผนกําลังการผลิตแบบดั้งเดิม แต่ก็ยังคงสําคัญที่จะรู้ว่าคุณใช้ทรัพยากรใดเพื่อจุดประสงค์ใด เพื่อที่คุณจะได้ไม่เสียเงินไปกับ cloud resources ที่ไม่จําเป็น การวางแผนกําลังการผลิตกลายเป็น การวางแผนทางการเงิน และการเพิ่มประสิทธิภาพกลายเป็นการเพิ่มประสิทธิภาพด้านต้นทุน [ 36 ] นอกจากนี้ cloud services ยังมีข้อจํากัดของทรัพยากรหรือ quotas (เช่น จํานวนสูงสุดของ processes ที่คุณสามารถรันพร้อมกัน) ซึ่งคุณต้องรู้และวางแผนก่อนที่จะชนเข้ากับมัน [ 37 ]

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

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

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

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

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

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

คําขอระหว่าง cloud services (Requests between 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)

ถ้าแอปพลิเคชันของคุณ busy ในบางเวลาและ idle ในเวลาอื่น การ deploy บนคลาวด์สามารถ ปรับขนาดขึ้นหรือลงเพื่อตอบสนองความต้องการ เพื่อให้คุณจ่ายเฉพาะทรัพยากรที่คุณใช้งานจริง สิ่งนี้ทําได้ยากกว่าบนเครื่องเดียว ซึ่งต้อง 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 อาจ overloaded หรือ crash และดังนั้น request ใดๆ อาจ timeout โดยไม่ได้รับการตอบกลับ ในกรณีนี้ เราไม่รู้ว่า service ได้รับ request หรือไม่ และการลองใหม่เพียงอย่างเดียวอาจไม่ปลอดภัย เราจะพูดถึงปัญหาเหล่านี้โดยละเอียดใน บท 9 .

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

การแก้ไขปัญหาใน distributed system มักจะยาก—ถ้าระบบตอบสนองช้า คุณจะหาสาเหตุของปัญหาได้อย่างไร? เทคนิคสําหรับการวินิจฉัยปัญหาใน distributed systems ได้รับการพัฒนาภายใต้หัวข้อ observability [ 46 , 47 ] ซึ่งเกี่ยวข้องกับการรวบรวมข้อมูลเกี่ยวกับการ execution ของระบบ และอนุญาตให้ 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 สามารถรันบนโหนดเดียวได้แล้ว เราจะสํารวจหัวข้อนี้เพิ่มเติมใน บท 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 และแต่ละ service มีทีมเดียวที่รับผิดชอบการบํารุงรักษา แอปพลิเคชันที่ซับซ้อนจึงสามารถถูกแยกส่วนออกเป็น 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 โดยปริยาย และโครงสร้างนั้นจะยากต่อการเปลี่ยนแปลง databases ที่ใช้ร่วมกันยังอาจทําให้ queries ของ service หนึ่งส่งผลเสียต่อประสิทธิภาพของ services อื่น

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

นอกจากนี้ microservice APIs อาจท้าทายในการพัฒนา clients ที่เรียก API คาดหวังให้มันมี ฟิลด์บางอย่าง นักพัฒนาอาจต้องการเพิ่มหรือลบฟิลด์ใน API เมื่อความต้องการทางธุรกิจเปลี่ยนไป แต่การทําเช่นนั้นอาจทําให้ clients ล้มเหลว ที่แย่กว่านั้นคือ ความล้มเหลวดังกล่าวมักไม่ถูกค้นพบจนกว่าจะถึงช่วงปลายของ 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 แนวทาง serverless กําลังนํา metered billing มาสู่การ execution ของโค้ด: คุณจ่ายเฉพาะเวลาที่ application code ของคุณกําลังทํางาน แทนที่จะต้อง provision ทรัพยากรล่วงหน้า

เพื่อให้ข้อดีดังกล่าว ผู้ให้บริการโครงสร้างพื้นฐาน serverless จํานวนมากกําหนด time limit สําหรับการ execution ของฟังก์ชันและจํากัดสภาพแวดล้อมรันไทม์ และ services อาจประสบปัญหา slow start times เมื่อฟังก์ชันถูกเรียกครั้งแรก คําว่า "serverless" อาจทําให้เข้าใจผิด; แต่ละการ execution ของ serverless function ยังคงรันบน server แต่การ execution ครั้งถัดไปอาจรันบน 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 การหยุดคลัสเตอร์ทั้งหมดมักไม่เป็นที่ต้องการ เนื่องจาก services ต้องให้บริการผู้ใช้อย่างต่อเนื่องโดยมีการขัดจังหวะน้อยที่สุด

• โหนดของ 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 ] ซึ่งให้ประสิทธิภาพที่ดีกว่าสําหรับ workloads HPC ที่มีรูปแบบการสื่อสาร ที่ทราบ .

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

ระบบ analytical ขนาดใหญ่บางครั้งมีลักษณะร่วมกับ 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 (สรุป)

ธีมของบทนี้คือการทําความเข้าใจข้อแลกเปลี่ยน—นั่นคือ การตระหนักว่าคําถามหลายข้อ ไม่ได้มีคําตอบที่ถูกต้องเพียงข้อเดียว แต่มีหลายความเป็นไปได้ที่แต่ละข้อมีข้อดีและข้อเสีย เราสํารวจตัวเลือกที่สําคัญที่สุดบางอย่างที่ส่งผลต่อสถาปัตยกรรมของ 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 โดยเนื้อแท้ และเราได้ตรวจสอบข้อแลกเปลี่ยนบางประการ ของ distributed systems เมื่อเทียบกับการใช้เครื่องเดียว ในบางสถานการณ์ คุณไม่สามารถหลีกเลี่ยงการกระจายได้ แต่ก็ควรที่จะไม่รีบเร่งทําให้ระบบเป็น distributed ถ้าเป็นไปได้ที่จะเก็บมันไว้บนเครื่องเดียว ใน บท 9 เราจะครอบคลุมความท้าทายของ distributed systems ในรายละเอียดมากขึ้น

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