จุดจบของ Big Data (2023)

• จากประสบการณ์ของวิศวกรยุคแรกของ BigQuery คอขวดของหลายองค์กรมักไม่ได้อยู่ที่ ขนาดข้อมูล แต่อยู่ใกล้กับวิธีใช้ข้อมูลและโครงสร้างต้นทุนมากกว่า
• จากลูกค้า BigQuery และฟีดแบ็กในอุตสาหกรรม คลังข้อมูลส่วนใหญ่มีขนาด ต่ำกว่า 1TB และแม้แต่ค่ามัธยฐานของลูกค้าที่ใช้งานหนักก็ยัง เล็กกว่า 100GB มาก
• การ แยก storage กับ compute บนคลาวด์ทำให้ปริมาณข้อมูลที่เก็บเพิ่มขึ้นมาก แต่ความต้องการ compute สำหรับการวิเคราะห์ไม่ได้เพิ่มขึ้นในสัดส่วนเดียวกัน เพราะมักเน้นข้อมูลล่าสุดและข้อมูลที่ aggregate แล้ว
• ใน BigQuery 90% ของ query จากลูกค้าที่ใช้จ่ายมากกว่า 1,000 ดอลลาร์ต่อปี ประมวลผลข้อมูลต่ำกว่า 100MB และแม้แต่ลูกค้าที่มี dataset ขนาดมหาศาลก็ไม่ได้รัน query ขนาดใหญ่บ่อยนัก
• ข้อมูลเก่าอาจกลายเป็น หนี้สิน ได้จากกฎระเบียบ การฟ้องร้อง ความหมายที่เลือนหาย และ logic การประมวลผลเฉพาะกรณี จึงควรตรวจสอบว่าการ aggregate, ลบ หรือสรุปข้อมูลดีกว่าการเก็บ raw data ไว้หรือไม่

---

ความแตกต่างระหว่างความกลัว Big Data กับคอขวดจริง

• ตลอดกว่า 10 ปีที่ผ่านมา มีข้อความที่ย้ำซ้ำ ๆ ว่าสาเหตุที่ยากจะได้ insight ที่นำไปปฏิบัติได้จากข้อมูลนั้นเป็นเพราะ ขนาดข้อมูล
• คำแนะนำที่ตามมาคือซื้อเทคโนโลยีใหม่เพื่อรับมือกับการขยายตัวขนาดใหญ่แล้วปัญหาจะหมดไป แต่หลังจากซื้อเครื่องมือใหม่และย้ายออกจากระบบ legacy แล้ว หลายองค์กรก็ยังคงเข้าใจข้อมูลของตนได้ยากอยู่ดี
• สถานการณ์ในปี 2023 เปลี่ยนไปจากช่วงที่คำเตือนเรื่อง Big Data เริ่มต้นขึ้น
  • มหาภัยข้อมูลถล่ม ที่เคยคาดการณ์ไว้ไม่ได้เกิดขึ้น
  • ขนาดข้อมูลโตขึ้นบ้าง แต่ฮาร์ดแวร์โตเร็วกว่า
  • vendor ยังคงชูเรื่อง scalability แต่คนทำงานจริงเริ่มสงสัยว่าสิ่งนั้นเชื่อมโยงกับปัญหาในโลกจริงอย่างไร

ขนาดข้อมูลลูกค้าที่เห็นจากประสบการณ์ BigQuery

• ผู้เขียนซึ่งเป็นวิศวกรผู้ก่อตั้งของ Google BigQuery เคยสาธิตความสามารถในการประมวลผลข้อมูลขนาดใหญ่ด้วยการรัน query ขนาด 1PB ในงานนำเสนอสาธารณะ
• ต่อมาผู้เขียนได้ debug ปัญหาของลูกค้า BigQuery ร่วมเขียนหนังสือ 2 เล่ม และตั้งแต่ปี 2018 รับหน้าที่เป็น product manager ที่พูดคุยกับลูกค้าและวิเคราะห์ metric ของผลิตภัณฑ์
• สิ่งที่สังเกตเห็นแล้วน่าประหลาดใจที่สุดคือ ผู้ใช้ “BigQuery” ส่วนใหญ่จริง ๆ แล้วไม่ได้มี Big Data
  • แม้แต่ลูกค้าที่มีข้อมูลขนาดใหญ่ ก็มักมี workload ที่ใช้เพียงส่วนน้อยของ dataset ทั้งหมด
  • ตอน BigQuery เปิดตัว ความเร็วในการประมวลผลดูราวกับนิยายวิทยาศาสตร์ แต่ต่อมาวิธีประมวลผลแบบดั้งเดิมมากขึ้นก็ไล่ตามทัน
• กราฟในบทความเป็นภาพวาดจากความทรงจำ ไม่ใช่ตัวเลขที่แม่นยำ และสิ่งสำคัญคือ รูปทรงของการกระจายตัว มากกว่าค่าที่แน่นอน
• หลักฐานมาจาก query log, postmortem ของธุรกรรม, ผล benchmark, ticket สนับสนุนลูกค้า, การพูดคุยกับลูกค้า, service log, บล็อกสาธารณะ และสัญชาตญาณ

องค์กรส่วนใหญ่ไม่ได้มีข้อมูลมากขนาดนั้น

• สไลด์ขายที่บอกว่า “Big Data กำลังมา” สื่อว่าทุกคนกำลังจะถูกข้อมูลท่วมท้น แต่ผ่านไป 10 ปี อนาคตแบบนั้นก็ยังไม่เกิดขึ้น
• เมื่อดูขนาดลูกค้า BigQuery ข้อมูลที่จัดเก็บทั้งหมดของลูกค้าส่วนใหญ่อยู่ที่ ต่ำกว่า 1TB
  • มีลูกค้าที่มีข้อมูลหลายร้อย PB อยู่บ้าง แต่ขนาดเป็นไปตาม power-law distribution ที่ลดลงอย่างรวดเร็ว
  • มีลูกค้าหลายพันรายที่จ่ายค่า storage ต่ำกว่าเดือนละ 10 ดอลลาร์ ซึ่งเทียบได้กับประมาณ 0.5TB
  • แม้ในกลุ่มลูกค้าที่ใช้บริการมาก ค่ามัธยฐานของปริมาณ storage ก็ยังเล็กกว่า 100GB มาก
• จากการสนทนากับ analyst ในอุตสาหกรรมอย่าง Gartner และ Forrester ก็ได้รับฟีดแบ็กว่าคลังข้อมูลขององค์กรส่วนใหญ่ เล็กกว่า 1TB
  • ตามความรู้สึกของอุตสาหกรรม ขนาดที่เหมาะสมของ data warehouse อยู่ราว 100GB
  • ทีม BigQuery ใช้ขนาดนี้เป็นจุดโฟกัสหลักของความพยายามด้าน benchmark
• นักลงทุนรายหนึ่งสำรวจบริษัทใน portfolio พบว่า แม้แต่บริษัทเทคโนโลยีซึ่งมีโอกาสที่ข้อมูลจะค่อนข้างใหญ่ บริษัท B2B ที่ใหญ่ที่สุดมีข้อมูลประมาณ 1TB และบริษัท B2C ที่ใหญ่ที่สุดมีประมาณ 10TB โดยส่วนใหญ่เล็กกว่านั้นมาก
• ตัวอย่างธุรกิจขนาดกลางก็แสดงให้เห็นว่าข้อมูลไม่ได้ใหญ่โตขึ้นง่าย ๆ
  • แม้ลูกค้า 1,000 คนจะสร้างคำสั่งซื้อวันละ 1 รายการและ line item 100 รายการต่อวัน ข้อมูลต่อวันก็ยังต่ำกว่า 1MB และหลัง 3 ปีก็ราว 1GB
  • แม้ marketing DB จะมี lead 1 ล้านรายการและ campaign หลายสิบรายการ ตาราง lead ก็ต่ำกว่า 1GB และการติดตาม campaign ก็น่าจะอยู่ในระดับไม่กี่ GB
  • แม้ตอนที่ SingleStore เป็นยูนิคอร์น Series E ที่เติบโตเร็วในปี 2020–2022 เมื่อรวม financial warehouse, ข้อมูลลูกค้า, การติดตาม marketing campaign และ service log แล้วก็มีขนาดเพียงไม่กี่ GB

ภาพลวงตาที่เกิดจากการแยก storage และ compute

• แพลตฟอร์มข้อมูลคลาวด์สมัยใหม่ทั้งหมดใช้การ แยก storage กับ compute เพื่อไม่ให้ลูกค้าถูกผูกติดกับ form factor เดียว
• การเปลี่ยนแปลงนี้อาจเป็นการเปลี่ยนแปลงที่สำคัญกว่า scale-out ในสถาปัตยกรรมข้อมูลช่วง 20 ปีที่ผ่านมา
  • แทนที่จะใช้โครงสร้าง shared-nothing ที่จัดการยาก โครงสร้าง shared disk ทำให้ขยาย storage และ compute ได้อย่างอิสระ
  • object storage ที่ขยายได้และเร็วพออย่าง S3 และ GCS ช่วยคลายข้อจำกัดในการออกแบบ database
• ในความเป็นจริง ขนาดข้อมูลเพิ่มเร็วกว่า compute มาก
  • ข้อมูลถูกสร้างขึ้นตามเวลา และแม้ในธุรกิจที่นิ่ง ปริมาณ storage ก็เพิ่มแบบเส้นตรงตามเวลา
  • การวิเคราะห์โดยทั่วไปมุ่งไปที่ข้อมูลล่าสุด ดังนั้นความต้องการ compute จึงไม่จำเป็นต้องโตเหมือนปริมาณ storage
  • ข้อมูลเก่าไม่เปลี่ยนแปลงแล้ว การสแกนซ้ำไปเรื่อย ๆ จึงใกล้เคียงกับความสิ้นเปลือง และคำตอบสำคัญสามารถทำได้ด้วย aggregate
• ลูกค้าที่โยกย้ายจาก on-premises ไปยังคลาวด์ที่แยก storage กับ compute มักพบว่าแม้ปริมาณ storage จะเพิ่มขึ้นมาก แต่ความต้องการ compute ไม่ได้เปลี่ยนไปมากนัก
  • ลูกค้า retail รายใหญ่รายหนึ่งของ BigQuery มี data warehouse แบบ on-premises ประมาณ 100TB แต่หลังย้ายขึ้นคลาวด์เพิ่มเป็น 30PB
  • ปริมาณ storage เพิ่มขึ้น 300 เท่า แต่ค่า compute ไม่ได้เพิ่มในสัดส่วนเดียวกัน และไม่ได้ใช้เงินหลายพันล้านดอลลาร์กับการวิเคราะห์
• โครงสร้างนี้แสดงให้เห็นว่าหากใช้ object store ที่ขยายได้ compute ที่ต้องใช้อาจน้อยกว่าที่คาดมาก และอาจไม่จำเป็นต้องใช้ distributed processing ก็ได้

workload ของ query จริงเล็กกว่าข้อมูลทั้งหมดมาก

• ปริมาณข้อมูลที่ workload ด้าน analytics ประมวลผลอาจเล็กกว่าที่คาดด้วยสัญชาตญาณมาก
  • dashboard มักสร้างจากข้อมูลที่ aggregate แล้ว
  • ผู้ใช้มักดูข้อมูลช่วง 1 ชั่วโมง 1 วัน หรือ 1 สัปดาห์ล่าสุด
  • ตารางเล็กถูก query บ่อยกว่า ส่วนตารางมหึมาถูก query อย่างเลือกสรรมากกว่า
• เมื่อวิเคราะห์ query ของลูกค้า BigQuery ที่ใช้จ่ายมากกว่า 1,000 ดอลลาร์ต่อปี พบว่า 90% ของ query ประมวลผลข้อมูลต่ำกว่า 100MB
  • มีการแบ่งวิเคราะห์หลายวิธีเพื่อไม่ให้ปริมาณ query ของลูกค้ารายใดรายหนึ่งบิดเบือนผลลัพธ์
  • query เฉพาะ metadata ที่ไม่ได้อ่านข้อมูลถูกตัดออก
  • query ในระดับ GB จะปรากฏเมื่อขึ้นไปถึง percentile สูง ๆ และ query ในระดับ TB พบได้น้อยมาก
• แม้แต่ลูกค้าที่มีข้อมูลขนาดมหาศาลก็แทบไม่ได้ query ข้อมูลมหาศาล
  • เวลารัน query ขนาดใหญ่ มักมีจุดประสงค์เพื่อสร้างรายงาน และ performance ไม่ใช่ลำดับความสำคัญ
  • บริษัทโซเชียลมีเดียรายใหญ่รายหนึ่งรัน query ขนาดใหญ่มากในช่วงสุดสัปดาห์เพื่อทำรายงานผู้บริหารวันจันทร์ แต่นั่นเป็นเพียงส่วนน้อยมากในบรรดา query หลายแสนรายการระหว่างสัปดาห์
• database สำหรับ analytics สมัยใหม่ใช้หลายเทคนิคเพื่อลดข้อมูลที่อ่านจริง
  • อ่านเฉพาะ field ที่จำเป็นด้วย column projection
  • อ่านเฉพาะช่วงวันที่แคบ ๆ ด้วย partition pruning
  • ใช้ data locality ผ่านการกำจัด segment ด้วย clustering หรือ automatic micro-partitioning
  • การคำนวณบนข้อมูลที่บีบอัด, projection และ predicate pushdown ก็ช่วยลด I/O ตอน query
• การลด I/O ช่วยลดปริมาณการคำนวณที่จำเป็น รวมถึงลดต้นทุนและ latency
  • เอกสารที่เกี่ยวข้อง: ลดต้นทุนคลังข้อมูลบนคลาวด์
  • เอกสารที่เกี่ยวข้อง: วินิจฉัยคอขวดด้านประสิทธิภาพของ data warehouse

ต้นทุนการประมวลผลข้อมูลกดดันให้ query เล็กลง

• ความจริงที่ว่าสามารถประมวลผลได้รวดเร็วด้วย scale-out ไม่ได้หมายความว่าการประมวลผลนั้นจะราคาถูก
• หากใช้ 1,000 node เพื่อให้ได้ผลลัพธ์ ต้นทุนอาจสูงมาก
• query ขนาด 1PB ที่ใช้รันในการสาธิต BigQuery มีราคาขายปลีก 5,000 ดอลลาร์
• ความไร้ประสิทธิภาพแบบนี้เป็นส่วนหนึ่งของ big data tax ที่เป็นภาระต่อทีมที่ไม่ได้ดำเนินงานในระดับ PB
• แรงจูงใจทางการเงินในการลดปริมาณข้อมูลที่ประมวลผลยังมีผลแม้ไม่ได้ใช้โมเดลคิดเงินตาม byte ที่ scan
  • ไม่ว่าจะเป็นค่า scan ของ BigQuery หรือค่า instance ที่ว่างอยู่ของ Snowflake data warehouse คลาวด์รายใหญ่ก็ทำให้บิลพองขึ้นได้
  • การทำให้ query เล็กลงช่วยให้ใช้ instance ที่เล็กลงได้ query เร็วขึ้น และรองรับการรันพร้อมกันได้มากขึ้น

ข้อมูลส่วนใหญ่แทบไม่ถูก query

• สัดส่วนใหญ่ของข้อมูลที่ถูกประมวลผลคือข้อมูลล่าสุดที่มีอายุ ต่ำกว่า 24 ชั่วโมง
• เมื่อข้อมูลมีอายุราว 1 สัปดาห์ โอกาสที่จะถูก query จะต่ำกว่าข้อมูล 1 วันล่าสุดประมาณ 20 เท่า
• เมื่อผ่านไป 1 เดือน ข้อมูลโดยทั่วไปจะยังคงอยู่เหมือนเดิม และถูก query เฉพาะเวลารันรายงานที่เกิดขึ้นไม่บ่อย
• การกระจายอายุของข้อมูลที่จัดเก็บค่อยเป็นค่อยไปกว่ารูปแบบการเข้าถึงมาก
  • ข้อมูลจำนวนมากอาจถูกทิ้งไปอย่างรวดเร็ว แต่ข้อมูลจำนวนมากก็ยังถูกเติมต่อท้ายตารางไปเรื่อย ๆ
  • แม้ข้อมูล 1 ปีล่าสุดจะมีเพียง 30% ของข้อมูลทั้งหมด ก็อาจคิดเป็น 99% ของการเข้าถึงข้อมูล
  • แม้ข้อมูล 1 เดือนล่าสุดจะมีเพียง 5% ของข้อมูลทั้งหมด ก็อาจคิดเป็น 80% ของการเข้าถึงข้อมูล
• เมื่อข้อมูลเงียบลงตามเวลา working set จริงจะมีขนาดที่จัดการได้กว่าที่คาด
  • แม้จะมีตาราง 1PB ย้อนหลัง 10 ปี สิ่งที่เข้าถึงบ่อยจริง ๆ อาจมีเพียงข้อมูลของวันนั้น
  • ข้อมูลของวันนั้นอาจต่ำกว่า 50GB เมื่อบีบอัดแล้ว

ขอบเขตของเครื่องเดี่ยวถูกผลักออกไปเรื่อย ๆ

• หากนิยาม Big Data ว่า “สิ่งที่ใส่ในเครื่องเดียวไม่ได้” จำนวน workload ที่เข้าข่ายนี้กำลังลดลงทุกปี
• ตอนที่เอกสาร Google MapReduce ปี 2004 ถูกเขียนขึ้น เป็นเรื่องปกติที่ workload ข้อมูลทั่วไปจะไม่พอดีกับเครื่องทั่วไปเพียงเครื่องเดียว
• เมื่อ AWS เปิดตัว EC2 ในปี 2006 instance ที่ให้บริการมีเพียง single core และ RAM 2GB และ workload จำนวนมากไม่พอดีกับเครื่องนี้
• ปัจจุบัน instance มาตรฐานของ AWS ใช้ 64 core และ RAM 256GB ในระดับ physical server
  • RAM เพิ่มขึ้นเป็นหลายสิบเท่าเมื่อเทียบกับ instance ยุคแรกของ EC2 ในปี 2006
  • หากจ่ายเพิ่มสำหรับ memory-optimized instance ก็สามารถเพิ่ม RAM ได้อีกเป็นหลายสิบเท่า
  • ทำให้เกิดคำถามว่า workload ที่ต้องการมากกว่า RAM 24TB หรือ CPU 445 core มีอยู่มากแค่ไหน
• บนคลาวด์ ต้นทุนของ VM ขนาดใหญ่เพิ่มขึ้นเกือบเป็นเส้นตรงตามพลัง compute
  • VM ที่ใช้ทั้ง server แพงกว่า VM ที่ใช้ 1/8 ของ server เพียง 8 เท่า
  • มองได้ว่าวันนี้สามารถได้ performance ใกล้เคียงกับ benchmark 3,000 node แบบขนานใน paper Dremel ดั้งเดิมบน node เดียว

ข้อมูลอาจเป็นหนี้สิน ไม่ใช่สินทรัพย์

• อีกนิยามหนึ่งของ Big Data คือ “สภาวะที่ต้นทุนในการเก็บข้อมูลต่อไปต่ำกว่าต้นทุนในการตัดสินว่าจะทิ้งอะไร”
• data lake ของหลายองค์กรใกล้เคียงกับ บึงขนาดมหึมา ที่ใหญ่ขึ้นเพราะไม่ได้ลบ ไม่ใช่เพราะจำเป็นต้องมี
  • ไม่รู้ว่าข้างในมีอะไร
  • ไม่รู้ว่าจัดระเบียบแล้วจะปลอดภัยหรือไม่
• ต้นทุนการเก็บข้อมูลมากกว่าค่าเก็บ byte ทางกายภาพ
  • ภายใต้กฎระเบียบอย่าง GDPR และ CCPA ต้องติดตามการใช้ข้อมูลบางประเภท
  • ข้อมูลบางส่วนต้องถูกลบภายในช่วงเวลาที่กำหนด
  • หากเบอร์โทรศัพท์ยังคงอยู่ในไฟล์ parquet ของ data lake นานเกินไป ก็อาจละเมิดข้อกำหนดทางกฎหมาย
• ข้อมูลเก่าอาจถูกใช้ในคดีความในทางที่เสียหายต่อองค์กรได้เช่นกัน
  • เช่นเดียวกับที่หลายองค์กรจำกัดระยะเวลาเก็บอีเมลเพื่อลดความรับผิดที่อาจเกิดขึ้น ข้อมูลใน data warehouse ก็อาจกลายเป็นหลักฐานที่เป็นผลเสียได้
  • หาก log เมื่อ 5 ปีก่อนแสดงให้เห็น security bug ใน code หรือการไม่เป็นไปตาม SLA การเก็บไว้นานขึ้นก็อาจทำให้การเปิดรับความเสี่ยงทางกฎหมายยาวนานขึ้น
• ข้อมูลก็อาจสูญเสียความหมายเหมือน bit rot ของ code
  • ผู้คนอาจลืมความหมายที่แม่นยำของ field เฉพาะ
  • bug ของข้อมูลในอดีตอาจเลือนหายไปจากความทรงจำ
  • ตัวอย่างเช่น ในช่วงเวลาสั้น ๆ customer id ทั้งหมดอาจถูกตั้งเป็น null หรือธุรกรรมฉ้อโกงขนาดใหญ่อาจทำให้ผลประกอบการไตรมาส 3 ปี 2017 ดูดีกว่าความจริง
  • business logic ที่ดึงข้อมูลช่วงเวลาเก่าอาจซับซ้อนขึ้นเรื่อย ๆ เช่น “ก่อนปี 2019 ใช้ revenue, ปี 2019–2021 ใช้ revenue_usd, หลังปี 2022 ใช้ revenue_usd_audited”

ตรวจสอบว่าคุณอยู่ในกลุ่ม Big Data 1% หรือไม่

• Big Data มีอยู่จริง แต่คนส่วนใหญ่อาจไม่จำเป็นต้องกังวล
• หากต้องการตัดสินว่าตนเป็น Big Data One-Percenter หรือไม่ สามารถถามคำถามต่อไปนี้ได้
  • คุณสร้างข้อมูลปริมาณมหาศาลจริงหรือไม่
  • ถ้าใช่ คุณต้องใช้ข้อมูลปริมาณมหาศาลในครั้งเดียวจริงหรือไม่
  • ถ้าใช่ มันใหญ่จนไม่สามารถใส่ในเครื่องเดียวได้จริงหรือไม่
  • ถ้าใช่ คุณเป็นเพียงคนที่กองข้อมูลทิ้งไว้หรือเปล่า
  • ถ้าใช่ การสรุปข้อมูลไม่ดีกว่าหรือ
• หากคำตอบของคำถามข้อใดข้อหนึ่งคือ “ไม่” คุณอาจเป็นผู้เหมาะสมกับเครื่องมือข้อมูลรุ่นใหม่ที่เข้ากับขนาดข้อมูลจริงที่คุณมี
• มีการกล่าวถึง ทางเลือก BigQuery สมัยใหม่เป็นตัวอย่างที่เกี่ยวข้อง
• องค์กรควรเลือกเครื่องมือและนโยบายการเก็บข้อมูลให้สอดคล้องกับขนาดข้อมูลที่มีจริงและรูปแบบ query จริง แทนที่จะหวาดกลัวขนาดข้อมูลที่อาจมีในสักวันหนึ่ง

[GN⁺]

ความเห็นจาก Hacker News

• ที่ทำงานเก่าเคยมีคำถามดักที่ชอบใช้ตอนรับนักวิทยาศาสตร์ข้อมูลว่า “ถ้ามีข้อกำหนดว่ามีข้อมูลขนาดสูงสุด 6TiB คุณจะสร้างสแตก/สถาปัตยกรรมแบบไหน”
  พอได้ยินคำตอบใหญ่โตอย่าง BigQuery, Hadoop แล้วถามต่อถึงต้นทุนฮาร์ดแวร์/ซอฟต์แวร์/ไลเซนส์ ก็มักจะลงเอยด้วยใบประเมินราคาหลายหมื่นดอลลาร์ต่อปี
  สุดท้ายคนที่ผ่านคือคนที่เข้าใจว่า 6TiB เป็นปริมาณที่คน 6 คนในห้องสามารถแบ่งเก็บลงสมาร์ตโฟนได้, ใช้เพียง HDD ระดับองค์กรลูกละ 199 ดอลลาร์ หรือสักสามลูกเพื่อทำ redundancy ก็พอ, และยังประมวลผลได้ด้วยการโหลด CSV เข้าเมมโมรีหลายรอบแล้วใช้สคริปต์ awk
  ผมเองก็เผลอติดกับดักแบบพอมีค้อนแล้วทุกอย่างดูเหมือนตะปูได้ง่าย แต่สำหรับการจ้างงาน การไม่เข้าใจ สเกลที่แท้จริง ของ “บิ๊กดาต้า” ถือเป็นเหตุผลให้ไม่ผ่าน

  • สถานการณ์แบบการสัมภาษณ์งานเองก็อาจมีผลต่อคำตอบได้ ผู้สมัครกำลังพยายามผ่านการสัมภาษณ์สายเทคนิค จึงคาดหวังได้ว่าผู้สัมภาษณ์ต้องการดู ความเข้าใจเรื่องเทคสแตก
    แทนที่จะสรุปจากคำตอบแบบนั้นว่าเขาจะออกแบบทุกอย่างเกินความจำเป็น ก็น่าจะถูกต้องกว่าถ้ามองว่าเขาแค่พลาดเพราะเป็นคำถามดักในสถานการณ์ประดิษฐ์ที่ผู้สัมภาษณ์ได้เปรียบ
    ไม่นานมานี้ผมไปสัมภาษณ์เทคนิคกับผู้สัมภาษณ์ที่มีอายุงานและประสบการณ์ใกล้กัน แล้วตอบได้แย่มาก ผู้สัมภาษณ์ก็มีท่าทีตัดสินกับคำตอบแย่ ๆ ของผม ถ้าสลับบทบาทกัน ผมก็คงทำให้เขาลำบากในหัวข้อที่ผมรู้ดีกว่าได้เหมือนกัน
    ถ้าเป็นผู้สัมภาษณ์ก็ควรระวังเป็นพิเศษ อย่าใช้อำนาจจากตำแหน่งที่เหนือกว่าในทางที่ผิด มันส่งผลเสียทั้งกับบริษัทและกับคนที่นั่งอยู่ตรงหน้า
  • https://x.com/garybernhardt/status/600783770925420546 โพสต์ปี 2015 ของ Gary Bernhardt:
    “บริการที่ปรึกษา: คุณเอาปัญหา big data มาให้ฉัน ฉันจะบอกว่า ‘ชุดข้อมูลของคุณใส่ใน RAM ได้’ แล้วคุณจ่ายฉัน 10,000 ดอลลาร์ จากเงิน 500,000 ดอลลาร์ที่คุณประหยัดได้”
  • บางคนจะไม่พอใจมากถ้าคุณบอกว่าข้อมูลของเขา ไม่ใช่บิ๊กดาต้าจริง ๆ
    หลายปีก่อนมีผู้บริหารคนหนึ่งโชว์ระบบที่ฝ่าย IT สร้างให้ โดยมีทั้ง Hadoop, API gateway, นักพัฒนาหลายคน และค่าใช้จ่ายปีละหลายแสนดอลลาร์ แต่พอผมบอกว่าที่สเกลปัจจุบันและสเกลที่คาดการณ์ได้ในอนาคต แค่ USB drive ที่เสียบกับโน้ตบุ๊กของเขาและสคริปต์ Python ไม่กี่ตัวก็พอรันได้ เขาก็หงุดหงิดมาก และหลังจากนั้นผมก็ไม่ได้เข้าไปยุ่งกับโปรเจกต์นั้นอีกเลย
    ผมมองว่านี่เป็นส่วนหนึ่งของวัฏจักรการโอ้อวดที่แพร่ทั่วบริษัท เป็นโครงสร้างที่ยอมรับไม่ได้ว่า “สิ่งที่เราทำมันเรียบง่าย”
  • ผมเข้าใจแนวทางแก้ปัญหาด้วยการขยายแนวตั้ง แต่พูดตามตรง มันเป็นวิธีที่ผิดสำหรับ use case แทบทั้งหมด ผู้ใช้ข้อมูลไม่ได้อยากได้ awk และถึงอยากได้จริง การสแกน 6TB ด้วย CPU เดียวทุกครั้งที่ query โดยไม่มี partitioning หรือ columnar storage ก็ช้าอยู่ดีเสมอ
    สำหรับงานแบบนี้ปกติแล้ว BigQuery ใช้ได้ดี อินเทอร์เฟซคอนโซลก็พอสำหรับการวิเคราะห์เฉพาะกิจ และยังเชื่อมกับเครื่องมืออย่าง Metabase, Tableau ได้หลายตัว
    ถ้าทำ partitioning ถูกต้อง ค่าใช้จ่ายก็ไม่สูงเกินไป และถ้าเริ่มมีปัญหาก็ค่อยเพิ่ม ตาราง rollup ได้
  • ไฟล์ .parquet ถูกประเมินค่าต่ำเกินไปมาก และยังมีคนจำนวนมากที่ไม่รู้จักฟอร์แมตนี้
    ต่างจาก CSV มันเก็บชนิดข้อมูลไว้ได้, มีขนาดเล็กกว่า CSV 10 เท่า จน 6TB เหลือ 600GB, และอ่านได้เร็วกว่า 50 เท่า อีกทั้งยังเป็นมาตรฐานเปิดของ Apache Foundation
    มันไม่ได้เปิดดูง่ายเท่า CSV แต่ก็เป็นการแลกเปลี่ยนที่คุ้มค่า ผมอยากให้ทุกที่ที่มีไฟล์ CSV ให้ดาวน์โหลด มี .parquet ให้มาด้วย

• โดยรวมผมเห็นด้วยกับหลายส่วนของบทความ แต่มีข้อแม้อยู่บ้าง อย่างแรก MongoDB ไม่เหมาะจะใช้เป็นจุดอ้างอิง ผมยังไม่เคยเห็นงานอะไรที่ MongoDB ทำแล้ว PostgreSQL ทำได้ไม่ดีกว่า และโซลูชันบิ๊กดาต้าก็มักไม่ใช่ NoSQL/MongoDB แต่เป็นพวกฐานข้อมูลแบบ columnar, map-reduce, หรือ Cassandra
  อย่างที่สอง คุณต้องวางแผนเผื่อความสำเร็จ ธุรกิจ 95% ไม่ได้กลายเป็นยูนิคอร์น แต่ถ้าคุณตั้งเป้าเป็น 5% ที่เหลือ คุณก็ไปไม่ถึงถ้าไม่เตรียมตัวไว้ เหตุผลที่ออกแบบโดยคำนึงถึงการขยายตัวตั้งแต่ตอนมีลูกค้า 5 คน ก็เพื่อคว้าโอกาสไว้เมื่อถึงช่วงการเติบโตแบบเอ็กซ์โปเนนเชียล
  แต่บทเรียนหลักนั้นถูกต้อง ข้อมูลส่วนใหญ่ไม่ได้ใหญ่ และแม้แต่ข้อมูลของคนทั้งโลกก็ยังใส่ใน Chromebook ราคา 100 ดอลลาร์ได้ ข้อมูลส่วนใหญ่ถูกเรียกดูไม่บ่อยและ query ก็เล็ก งาน big data มักมีขั้นตอนแรกคือย่อข้อมูลระดับเทราไบต์ให้เหลือระดับ GB, MB หรือบางครั้งถึง KB ที่ต้องใช้จริง ขณะเดียวกัน ต้นทุนของข้อมูล ก็กำลังสูงขึ้นเพราะกฎระเบียบ

  • คำว่า “วางแผนเผื่อความสำเร็จ” นี่เหมือนกับสิ่งที่พวก สถาปนิกอวกาศด้านสถาปัตยกรรมระบบ พูดกันทุกที่เป๊ะ จากประสบการณ์ผมมันไม่จริงทั้งหมด และบ่อยครั้งกลับลดทั้งผลิตภาพและความคล่องตัวซึ่งสำคัญกับสตาร์ตอัปมากกว่า
    คนส่วนใหญ่ไม่ได้หยุดแค่การวางแผน แต่มักลงมือทำมันด้วย ถ้าคุณวางแผนแค่ 3 เดือนข้างหน้า คุณอาจคล่องตัวและมีประสิทธิภาพกว่ามาก ถ้าส่งมอบจริงไม่ได้ คุณก็ไม่มีทางเป็นยูนิคอร์น
  • ผมเห็นกรณีที่บริษัท ล้มเหลวเพราะเตรียมรับความสำเร็จมากเกินไป บ่อยกว่ากรณีที่อยู่ ๆ ก็สำเร็จจนรับมือไม่ทันเสียอีก
    มันเหมือนการผสมกันของ second-system syndrome กับ survivorship bias คนที่ต้องมาเก็บกวาดความยุ่งเหยิงของ MVP ที่ดีมักบ่นว่า “น่าจะทำแบบนี้ตั้งแต่แรก” แต่บริษัทที่วางแผนและออกแบบทุกอย่างล่วงหน้าไว้จริง ๆ มักไม่รอดจนไม่มีใครเหลือมาบ่นถึงมัน
  • ขอทักเล็กน้อย แต่ 8 บิตมันเก็บแม้แต่เลข ID แบบจำนวนเต็มที่ไม่ซ้ำกันของคนแต่ละคนไม่ได้ด้วยซ้ำ แบบนั้นต้องใช้ 8 ไบต์ต่อคน ซึ่งก็เป็นระดับ 60GB แล้ว
    ผมเห็นด้วยกับเนื้อหาส่วนใหญ่นอกนั้น แต่ตรงนี้ดูผิดจนปล่อยผ่านไม่ได้
  • ผมคิดว่าความเชื่อที่ว่า “ถ้าอยากเปิดโอกาสให้กลายเป็นยูนิคอร์นได้ คุณต้องวางแผนทุกส่วนของธุรกิจทั้งสำหรับวันนี้และอนาคต” ในทางปฏิบัติกลับให้ผลตรงกันข้าม
    รันเวย์ของสตาร์ตอัปมีจำกัด และถ้าวิศวกรกำลังเผาเงินไปกับสิ่งที่จะได้ผลตอบแทนอีกหลายปีข้างหน้า ก็เท่ากับเพิ่มโอกาสที่จะล้มเหลวก่อนถึงวันนั้น
  • ผมสงสัยกับคำกล่าวที่ว่าต้องออกแบบเพื่อการขยายตัวตั้งแต่มีลูกค้า 5 คน เพื่อจะรับมือได้เมื่อการเติบโตแบบเอ็กซ์โปเนนเชียลมาถึง
    ที่ผลิตภัณฑ์จะเกิดแรงดึงดูดระดับนั้นได้ มักเป็นผลรวมจากการมีอยู่ของฐานผู้ใช้และความต้องการของพวกเขา ต่อให้ช่วงโตสะดุดกับการเพิ่มผู้ใช้ใหม่ ผู้ใช้เดิมก็มักไม่ย้อนกลับไปใช้ของเก่าหรือย้ายไปที่อื่นง่าย ๆ
    Twitter ยุคก่อนผู้คนเห็น fail whale กันทุกวันเป็นเรื่องปกติ แต่ส่วนใหญ่ก็ไม่ได้เลิกใช้ และก็ไม่ได้เกิดการย้ายครั้งใหญ่ไปยังทางเลือกอื่นที่ขยายตัวได้ดีกว่า ผลิตภัณฑ์ที่เจอการเติบโตแบบเอ็กซ์โปเนนเชียลจริง ๆ นั้นมีน้อยอยู่แล้ว และระหว่างทางจะเจอปัญหาการขยายตัวจนความพร้อมใช้งานแย่ลงก็เป็นเรื่องปกติ ผมเลยสงสัยว่ามีผลิตภัณฑ์เติบโตแบบเอ็กซ์โปเนนเชียลตัวไหนบ้างที่ล้มเหลวเพราะขยายไม่ทันจริง ๆ

• ในช่วงที่ “Big Data” กำลังเป็นกระแส ฉันเคยเป็นนักวิจัยที่ Large Hadron Collider สำหรับพวกเรา การวิเคราะห์ข้อมูลทั้งหมดคือกรณีใช้งานที่มีความหมาย และในสถิติแบบความถี่นิยมยิ่งมีข้อมูลมากก็ยิ่งดี
  แต่แม้จะใช้เครือข่ายซูเปอร์คอมพิวเตอร์ทั่วโลก ก็ได้เรียนรู้ว่า storage ภายในเครื่องที่เร็วกว่า กลับดีกว่าการรอให้งานขนาดมหึมารันเสร็จ สุดท้ายนักศึกษาปริญญาโท/เอกทุกคนก็ย่อขนาดข้อมูลที่เกี่ยวข้องลงมาเหลือเพียง 1~5TB ได้อย่างแม่นยำ โดยแทบไม่สูญเสียความยืดหยุ่นในการวิเคราะห์
  ดูเหมือนจะมีกฎอะไรสักอย่างคล้าย Amdahl's law of scaling ที่อาจเรียกว่า กฎแห่งความสะดวก

  • ถ้าจะลองตั้งชื่อ ก็คงประมาณว่า “ถ้าคุณวิเคราะห์ทางสถิติด้วย ข้อมูล 1~5TB ไม่ได้ แสดงว่าวิธีวิทยาของคุณผิด”
    เรื่องนี้ดูจะใกล้กับข้อจำกัดของมนุษย์มากกว่าคณิตศาสตร์ ชัดเจนว่าเรามีเพดานของความยืดหยุ่นที่ใช้งานได้จริงอยู่ หากมีวิธีที่ทำให้การรันวิเคราะห์รูปแบบใหม่ ๆ ง่ายขึ้น มันก็คงเปลี่ยนไป แต่ก็น่าจะเพิ่มขึ้นแบบลอการิทึมเมื่อเทียบกับจำนวนสิ่งที่เราอยากทำ
  • ฉันคิดว่ากฎแห่งความสะดวกมีอยู่จริง และยังอธิบายได้ด้วยว่าทำไมเทคโนโลยีจำนวนมากถึงพัฒนาในอัตรา เอ็กซ์โปเนนเชียลคงที่
    ผู้คนเก่งมากในการหาวิธีที่สะดวกเพื่อทำให้สิ่งต่าง ๆ ดีขึ้นทีละนิดทุกปี แต่ไม่ว่าไอเดียไหนก็ยังต้องใช้เวลาขั้นต่ำในการลงมือทำ
  • ในยุค 80~90s NASA สร้าง National Aerodynamic Simulator ขึ้นมา เป็นระบบที่ใช้เครื่องใหญ่แบบ Cray เพื่อรันซิมูเลชันการวิเคราะห์องค์ประกอบจำกัด อิงตามมาตรฐานปัจจุบันมันอาจแรงพอ ๆ กับการ์ดจอราคาถูกก็ได้
    ถ้าจำไม่ผิด คิวรอของเครื่องนั้นยาวพอ ๆ กับหรือยาวกว่าการรันงานบนฮาร์ดแวร์ราคาถูก และระบบ การประมวลผลขนานขนาดใหญ่ อย่าง Beowulf ก็เกิดขึ้นจากความพยายามลักษณะนั้น
  • ฉันคิดว่ากฎแห่งความสะดวกนั้นแม่นมาก พอคุยกับนักพัฒนาระบบเชิงพาณิชย์ จะพบว่าลูกค้ากดดันให้สร้างระบบให้ถูกที่สุดเสมอ
    การลดขนาดฐานข้อมูลที่เก็บและขนาดของการคำนวณ เป็นวิธีชั้นเยี่ยมในการทำให้ยอดบิลรายเดือนของลูกค้าต่ำที่สุด

• จากประสบการณ์ของฉัน ข้อมูลยังคงโตแบบเอ็กซ์โปเนนเชียล แต่ ปริมาณสารสนเทศ ไม่ได้เพิ่มตามนั้น
  ในสายการเงิน ถ้าต้องการ คุณสามารถได้ข้อมูลถึงวันละ 100 ล้าน data points ต่อหนึ่ง time series ได้ไม่ยาก และอาจจัดการกับ time series หลายพันชุดพร้อมกันได้ด้วย แต่ความถี่การเก็บตัวอย่างและจำนวน time series เหล่านั้นมักซ้ำซ้อนกันถึง 99.99% เพราะหลังจากค่าเอกลักษณ์ราวมิติที่ 10 หรือบางครั้งเร็วกว่านั้น ค่าจะตกลงไปใกล้ศูนย์เกือบหมด
  แทบไม่มีเหตุผลที่จะเก็บ tick data ระดับเพตะไบต์ ทั้งที่ไม่มีวันถูกดึงมาใช้อีก ในหลายกรณี การทำ การลดมิติ แบบหนักมือและยอมให้สูญเสียข้อมูลตั้งแต่ตอนเก็บรวบรวม บันทึกเฉพาะองค์ประกอบหลักไม่กี่ตัวแรกกับค่าผิดปกติ และเฝ้าดูเสถียรภาพของค่าเอกลักษณ์เพื่อดูว่าปัจจัยใหม่ที่เคยมองข้ามเริ่มมีความสำคัญหรือไม่ เป็นแนวทางที่สมเหตุสมผลกว่ามาก
  ผลลัพธ์คือชุดข้อมูลเล็กลงมาก จัดการง่ายขึ้น และเพราะใช้งานได้จริง จึงมักให้ insight ได้ดีกว่าเสียอีก

  • น่าสนใจ ฉันสงสัยว่าถ้า eigenvector เปลี่ยนไปตามเวลา คุณจัดการอย่างไร
  • ถ้าพอจะแนะนำแหล่งข้อมูลที่อธิบายเรื่องค่าเอกลักษณ์กับมิติได้ก็คงดี
    ฟังดูน่าสนใจมาก แต่สำหรับฉันมันเป็นเรื่องใหม่ทั้งหมด

• เรื่องขำของ “Big Data” คือมันมีแรงจูงใจบิดเบี้ยวที่ทำให้ผู้คนเลี่ยงแม้แต่ optimization ขั้นพื้นฐานและชัดเจนที่สุดในระดับซอฟต์แวร์ เพราะยิ่งต้องใช้ฮาร์ดแวร์มาก ก็ยิ่งดูเหมือนพิสูจน์ได้ว่าตัวเองเก่งแค่ไหน
  ตัวอย่างเช่น ถ้าคุณบอกว่า “หัวหน้า ถ้าอ่านแค่ sample แทนที่จะคำนวณทั้ง dataset เราจะหาค่าเฉลี่ยในรายงานนี้ได้ด้วยแค่โน้ตบุ๊กครับ” หัวหน้าก็จะรับสารประมาณว่า “sample หมายถึงอะไร? คุณกำลังจะสื่ออะไรด้วยคำพูดเพ้อเจ้อแบบนักคณิตศาสตร์/วิศวกรนั่น? คงไม่ได้หมายความว่าผมเผาเงินไปหลายล้านดอลลาร์เปล่า ๆ ใช่ไหม?”

  • กระแสนั้นยังมีแรงผลักจากคนที่ออกมาจาก Google แล้วนำ stock option มาเปลี่ยนเป็นเงินสดด้วย
    การ โหมขายเกินจริง เรื่อง Big Data รวมถึง noise และการแข่งขันอวดกันว่าใครมีข้อมูลใหญ่พอ เคยรุนแรงมากอยู่ช่วงหนึ่ง
  • นี่เป็นมุมมองของคนนอกที่ค่อนข้างประชด และจริง ๆ แล้วไม่ถูกต้องนัก ช่วงต้นอาชีพฉันทำงานเป็น data engineer โดยพยายาม ลดต้นทุนการประมวลผล
    อยู่มานานมากกว่าจะได้เครื่องที่มีหน่วยความจำเกิน 64GB บนเครื่องเดียว และเมื่อชนเพดานฮาร์ดแวร์ ความซับซ้อนของการ implement จะพุ่งขึ้นอย่างรวดเร็ว
    ถ้าข้อมูลโตขึ้นอีกนิดแล้วทำให้โปรเซสล้มเหลว 1 ครั้งจาก 50 ครั้ง มันสร้างความเสียหายมาก ทีมหนึ่งรันงาน cron แบบนี้เป็นสิบ ๆ ตัว และถ้าแต่ละตัวพังบ่อย คนที่ on-call ก็จะได้แต่คอยตัดแปะชิ้นส่วนแก้ปัญหา
    Hadoop กับ MapReduce ไม่ได้มีประสิทธิภาพสูงสุดก็จริง แต่ถ้าใช้อย่างถูกต้องมันก็ใช้ได้ และการรันได้อย่างเสถียรสำคัญกว่ามาก หมายความว่ามันดีกว่าโค้ด C++ ที่ optimize ระดับบิตแต่ไม่มีใครเชื่อถือหรือดูแลต่อได้ และตายทุกวันพฤหัสด้วย segmentation fault ประหลาด ๆ
    ทุกวันนี้ฉันคงใช้ Snowflake ไปเลย แต่ในตอนนั้นมันเป็นเครื่องมือที่สมเหตุสมผล

• บทความนี้ไม่ได้ถูกต้องทั้งหมด เดิมที Big Data ถูกนิยามด้วยสามมิติ: ปริมาณ, ความเร็ว และความหลากหลาย
  เรื่องปริมาณนั้นแก้ได้ไปมากแล้ว และเรื่องความเร็วก็แก้ได้เช่นกันแต่มีค่าใช้จ่ายสูง ส่วน ความหลากหลาย ยังไม่ถูกแก้ไข
  ทุกวันนี้ Big Data ใกล้เคียงกับปัญหาแบบ “เราไม่มีความสามารถด้านการรับรู้มากพอที่จะบูรณาการและทำความเข้าใจสิ่งนี้” มากกว่าจะเป็น “เรามีพื้นที่เก็บข้อมูลหรือพลังประมวลผลไม่พอ”

  • ผมได้ยินเรื่อง 3V นี้ครั้งแรกจากบรรยายของ Michael Stonebraker เขาเป็นตำนานในวงการ DBMS และเป็นผู้ได้รับรางวัล Turing Award
    ขอแนะนำบรรยายที่เกี่ยวข้องอย่างมาก ส่วนใหญ่มีอยู่บน YouTube
    [1] https://www.youtube.com/watch?v=KRcecxdGxvQ
    [2] https://amturing.acm.org/award_winners/stonebraker_1172121.c...
  • อยากรู้ว่าคำว่า “ความหลากหลาย” ที่นี่หมายถึงอะไร
  • สำหรับผม พื้นที่เก็บข้อมูลและพลังประมวลผลยังคงไม่พอ ผมออกภาคสนามเพื่อเก็บข้อมูลปีละหกครั้ง ครั้งละสองสัปดาห์ โดยในภาคสนามจะเก็บ เรดาร์สังเคราะห์ช่องรับภาพ จากอากาศยานสองลำ ครอบคลุมสี่แถบความถี่และโพลาไรซ์คู่
    อากาศยานแต่ละลำมีระบบเรดาร์หนึ่งชุด และภายในนั้นมีอุปกรณ์เก็บข้อมูล SSD แบบ RAID-0 ขนาด 20TiB จำนวน 8 ชุด โดยแต่ละชุดมีไดรฟ์ 16 ตัว ปกติเราจะไม่ได้เขียนจนเต็ม RAID ดังนั้นจึงได้ข้อมูลราว 176TiB ต่อวัน และถ้าบิน 7 เที่ยวในช่วง 2 สัปดาห์ก็จะได้ประมาณ 1.2PiB ต่อหนึ่งแบตช์ หรือราว 7.2PiB ต่อปี
    เหตุผลที่ต้องเว้นวันระหว่างเที่ยวบินก็เพราะต้องถ่ายข้อมูลผ่านไฟเบอร์ลงไปยังเซิร์ฟเวอร์เก็บข้อมูลที่ถูกยัดไว้แบบลวก ๆ ในมุมหนึ่งของโรงเก็บเครื่องบินข้างลานจอด จากนั้นจึงคัดลอกไปยังเซิร์ฟเวอร์อีกเครื่องเพื่อความปลอดภัย และเมื่อภารกิจจบลงก็ส่งทั้งหมดกลับสำนักงานใหญ่เพื่อจัดเก็บและประมวลผล
    ข้อมูลนี้มีคุณค่า แต่ไม่ถึงระดับ “หลายหมื่นล้านดอลลาร์” มันถูกใช้ในงานสกัดทรัพยากร การทำแผนที่ การวิจัยด้านสิ่งแวดล้อมและภูมิศาสตร์เชิงสำรวจ และเราเก็บทุกไบต์มาตั้งแต่ปี 2008 เพราะเมื่อมีอัลกอริทึมใหม่ออกมา เราสามารถนำข้อมูลเก่ามาประมวลผลใหม่ตามมาตรฐานใหม่ได้
    ไฟล์จะถูกสตรีมไปยังเซิร์ฟเวอร์ประมวลผล GPU เป็นก้อนขนาด 800GiB ถึง 2TiB และบีบอัดไม่ได้ เพราะสิ่งที่เราจับได้เป็นส่วนใหญ่คือพื้นหลังไมโครเวฟของจักรวาลซึ่งค่อนข้างสุ่ม ช่วงหนึ่งผมเคยหลงคิดว่าถ้าเขียนลงเทปเราจะลดโครงสร้างพื้นฐานลงได้ครึ่งหนึ่ง แต่ดูเหมือนว่าความจุเทปจะถูกคำนวณเหมือนตอนเก็บไฟล์ข้อความขนาดกิกะไบต์ที่มีแต่เลข 0
    GPU ก็ช้า CPU ก็ช้า บัส PCIe ก็ช้า RAM ก็ช้า แม้แต่ความเร็วในการพิมพ์ของผมก็ช้า ทุกอย่างต้องเร็วขึ้นตลอดเวลา
    ทุกอย่างช้าเกินไป ยากเกินไป และเล็กเกินไป ฮาร์ดดิสก์เล็กเกินไป และการจูน Linux kernel รวมถึงการตั้งค่าเครือข่ายที่เร็วและเสถียรไปยังคลัสเตอร์ประมวลผลก็ยากเกินไป แม้แต่การอัปเดต kernel/แพ็กเกจที่ควรเป็นแค่การเปลี่ยนแปลงภายในธรรมดา ๆ ก็ยังทำให้ระบบพังในแบบที่มีแต่เราที่เจอ
    ค่าตั้งต้นต่าง ๆ ถูกออกแบบมาภายใต้ภาพลวงตาว่า RAM เป็นทรัพยากรหายาก จึงพยายามประหยัดหน่วยความจำสำหรับงานเครือข่าย แต่เซิร์ฟเวอร์ไฟล์ของเรามี RAM 0.5TB ผมเลยอยากให้มันใช้ทั้งหมดเพื่อทำให้เครือข่ายและไฟล์ซิสเต็มเร็วขึ้น สุดท้ายก็ต้องนั่งอ่านเอกสาร network stack อยู่ 6 ชั่วโมงเพื่อยกระดับ I/O ให้มาอยู่ในระดับสามัญสำนึกของปี 2024
    ผมน่าจะรู้จัก sysctl.conf ดีกว่าแทบทุกคนบนโลก
    ระบบ distributed persistent object store ที่อ้างว่าออกแบบมาสำหรับ Big Data พังไม่เป็นท่ากับ workload ของเราหรือไม่ก็มีราคาหลายร้อยล้านดอลลาร์ พอคุณบอกว่าขนาด object อยู่ราว 1TB เซลส์ฝั่ง distributed filesystem ก็หยุดตอบอีเมล บาง vendor ถึงกับอ่าน requirement แล้วส่งต่อผมไปหาฝ่ายขายที่ดูแลลูกค้าหน่วยข่าวกรอง ผมไม่ใช่ NSA และก็ไม่มีงบแบบ NSA
    บางครั้งจะมีคนจบ MBA หรือ PMP ที่ไปอ่านบทความเรื่องคลาวด์ใน Bloomberg แล้วเห็นค่าใช้จ่ายของดาต้าเซ็นเตอร์แบบ on-premises จากนั้นก็ถามเรื่องย้ายไป AWS หรือ Azure แต่พอผมโชว์ตัวเลขทั้งด้านเงินและเวลาให้ดู พวกเขาจะทำหน้าเหมือนอยากอาเจียนแล้วเปลี่ยนเรื่อง
    ยิ่งไปกว่านั้น vendor ทุกเจ้าก็กำลังเกาะกระแส AI/คลาวด์ จนเลิกสายผลิตภัณฑ์ที่เหมาะกับเรา ตอนนี้เราต้องไปแย่ง GPU กับเฮดจ์ฟันด์และสตาร์ทอัป AI ที่อยากขุดข้อมูลลูกค้าเพื่อยิงโฆษณา
    เราขาดทั้งพื้นที่เก็บข้อมูลและพลังประมวลผล และแม้แต่สิ่งที่มีอยู่ก็ดันช้าเกินไป DPU/IPU น่าสนใจ แต่พอ object ใหญ่กว่าคิวรีฐานข้อมูล SQL หรือชิ้นวิดีโอสตรีมที่บีบอัดแล้ว ก็ชนเพดานทันที

• ผมเคยทำงานที่บริษัทหนึ่งซึ่งสร้าง ข้อมูลวิเคราะห์ 20GB ต่อวัน ซึ่งนั่นอาจเป็นข้อมูลขนาดใหญ่ที่สุดที่ผมจะได้แตะต้องแล้ว
  เป็นโปรเจ็กต์ระดับจูเนียร์ที่เขียนงานประมวลผลข้อมูลทั้งแบบแบตช์และแบบเรียลไทม์ แล้วเก็บผลลัพธ์ไว้ใน Parquet blob บน Azure
  หัวหน้าของผมฉลาดพอที่จะจัดประชุมผู้มีส่วนได้ส่วนเสียเป็นประจำเพื่อคุยกันว่าจะเก็บอะไรและทิ้งอะไร และด้วยอัลกอริทึมที่ดี เราสามารถบีบข้อมูลลงเหลือประมาณ 200MB ต่อวันได้
  ข้อมูลล่าสุด 2 เดือนจะอยู่บน SQL Server ส่วนข้อมูลล่าสุด 2 ปีจะถูกสรุปรวมมากขึ้นแล้วเก็บไว้อีกเซิร์ฟเวอร์หนึ่ง และทั้งบริษัทก็ใช้ Excel คิวรีมันได้ภายในเวลาที่สมเหตุสมผล ส่วน Big Data ต้นฉบับก็นอนผุอยู่ในระบบเก็บเทป เผื่อว่าสักวันจะต้องใช้
  หัวหน้าของผมเป็นผู้จัดการที่แย่ แต่เขารู้เรื่องข้อมูลดี พอมองย้อนกลับไป เขาทำหลายอย่างถูกต้อง และผมเองก็ได้เรียนรู้อะไรมากมาย

• ตลอดหลายปีที่ผ่านมา ผมเห็นการ ทำเกินความจำเป็นทางวิศวกรรม ของเครื่องมือและไปป์ไลน์สำหรับข้อมูล “ขนาดใหญ่” อยู่เรื่อย ๆ ในหลายกรณี data warehouse และ data lake อยู่แค่ระดับ GB หรือ TB หลักเดียว ซึ่งจริง ๆ ทำให้เรียบง่ายกว่านั้นได้มาก เช่น รัน DuckDB บน EC2 instance ดี ๆ สักตัว
  จากประสบการณ์ของผม วิธีนี้ให้ผลลัพธ์ออกมาก่อนที่ระบบอื่นจะเริ่มรันคิวรีเสียอีก ผมกำลังพูดถึง Athena
  ทุกวันนี้ผมคิดว่าหลายคิวรีรันในเบราว์เซอร์ได้เลย จึงได้สร้าง https://sql-workbench.com/ ขึ้นมาด้วยความช่วยเหลือของ DuckDB WASM(https://github.com/duckdb/duckdb-wasm) และ perspective.js(https://github.com/finos/perspective)

• วงจรกระแสนี้ดูเหมือนจะมาถึง “ที่ราบสูงแห่งความตาย” แล้วในที่สุด ซึ่งก็เป็นจุดจบที่ไม่ถือว่าแปลกสำหรับอุตสาหกรรมที่ไหลไปตามกระแสอย่างรุนแรงแบบนี้

  • มันแค่ถูกเปลี่ยนชื่อเป็น AI เท่านั้น
    AI ก็ใช้ข้อมูลทั้งหมดเหมือนกัน และเอาโครงข่ายประสาทเทียมมหัศจรรย์มาต่อเพื่อหาความหมายของมัน

• โดยส่วนตัวคิดว่าแรงขับหลักของบิ๊กดาต้ามาจาก อีโก้ ของผู้ก่อตั้งบริษัท แนวคิดคือแน่นอนว่าบริษัทของเราจะเติบโตแบบระเบิดและประสบความสำเร็จระดับโลก จึงต้องออกแบบให้รองรับขนาดนั้นตั้งแต่แรก
  ทั้งที่ก่อนที่ผลิตภัณฑ์จะไปถึง Series C แค่ SQLite DB ตัวเดียวก็มักจะเพียงพอแล้ว การทำพลาดแบบนี้จึงน่าเศร้า พลังงานทั้งหมดควรทุ่มไปที่ตัวผลิตภัณฑ์ ไม่ใช่ขนาดในตอนนี้

  • ไม่ใช่เลย บิ๊กดาต้าถูกขับเคลื่อนโดยคนที่มี ปัญหาข้อมูลขนาดใหญ่จริง ๆ
    Hadoop เริ่มต้นจากแรงบันดาลใจจากสิ่งที่มีอยู่ใน Google และได้รับความนิยมจากบริษัททั่วโลกที่ต้องการจัดการข้อมูลด้วยวิธีที่ถูกกว่าและดีกว่า Oracle
    Spark เกิดขึ้นมาเพื่อแก้ความซับซ้อนของ Hive/Pig และเมื่อบริษัทต่าง ๆ สามารถสร้าง data pipeline ที่เชื่อถือได้ ก็สามารถวาง AI ไว้บนสิ่งนั้นได้
  • ขึ้นอยู่กับประเภทของข้อมูลที่จัดการ โมเดลข้อมูลสำคัญอย่างภูมิสารสนเทศ การตรวจจับ และ telemetry อาจไปถึงระดับเพตะไบต์ได้ตั้งแต่ช่วง “Hello, world”
    โมเดลข้อมูลที่เกิดจากพฤติกรรมมนุษย์แบบจงใจ เช่น การคลิกลิงก์ การส่งข้อความ หรือการซื้อสินค้า โดยทั่วไปมีขนาดเล็กกว่า เพราะจำนวนมนุษย์และจำนวนเหตุการณ์แบบจงใจที่มนุษย์สร้างได้ต่อวินาทีนั้นมีขีดจำกัด
    ในทางกลับกัน โมเดลข้อมูลที่สร้างโดยเครื่องจักรอาจมีทั้งความเร็วและปริมาณมากกว่าอีกหลายหลัก และไม่มีเพดานที่ชัดเจนต่อขนาดของโมเดลข้อมูล ข้อมูลแบบนี้มักเป็นข้อมูลที่น่าสนใจที่สุดและถูกใช้งานน้อยเกินไป เพราะมันเปิดเผยข้อเท็จจริงมากมายเกี่ยวกับโลกที่โมเดลข้อมูลจากความตั้งใจของมนุษย์ให้ไม่ได้
  • โดยรวมก็ถูกต้อง แต่ก็มีข้อยกเว้นที่ชุดข้อมูลเกิน 10TB เป็นเรื่องปกติมาก เช่น IoT หรือ GIS