ม้าต้องตรงกับงาน: หยุดใช้คลังข้อมูลสำหรับงานที่ต้องตอบลูกค้า

เมื่อใครสักคนในธนาคารหรือบริษัทประกันพูดถึง “ข้อมูล” คนในห้องมักนึกถึง big data, Snowflake และในอดีตคือสแตกแบบ Hadoop สัญชาตญาณนี้เข้าใจได้ เพราะแพลตฟอร์มเหล่านั้นชนะในทศวรรษที่ผ่านมาเรื่องข้อมูลการจัดการ ความเสี่ยงเชิงวิเคราะห์ และรายงานตามกฎระเบียบ แต่เป็นค่าเริ่มต้นที่ผิดสำหรับงานใด ๆ ที่ต้องตอบผู้ใช้ การอนุมัติ หรือเครื่องยนต์ตรวจจับการฉ้อโกงภายในมิลลิวินาที การสับสนระหว่างจำนวนคนและเครื่องมือเชิงวิเคราะห์กับความต้องการผลิตภัณฑ์เชิงปฏิบัติการ คือสาเหตุที่ next-best-action มาหลังเซสชัน การให้คะแนนการฉ้อโกงเกิดหลังเกิดการสูญเสีย และมุมมองธุรกรรมในแอปยังต้องรอความสดใหม่จากคลังข้อมูล

นิสัยองค์กรนี้เก่ากว่าผู้ขายรายใดรายหนึ่ง “แพลตฟอร์มข้อมูล” เดียวกลายเป็นคำตอบที่ดูมีศักดิ์ศรี คณะกรรมการให้ทุนสร้างคลังข้อมูล lakehouse และทีมที่ดูแลพวกมัน ผู้นำผลิตภัณฑ์จึงขอให้ทีมเดียวกันนั้นสร้าง live upsell, cross-sell ยอดคงเหลือ และประวัติที่ลูกค้าเห็น เพราะสไลด์ยังคงใช้คำว่า “ข้อมูล” Horses for courses ไม่ใช่เพียงคำขวัญที่นี่ มันคือสถาปัตยกรรมเดียวที่ตรงกับวิธีการทำงานจริงของธุรกิจ

ต้นทุนของการใช้ทีมวิเคราะห์ทำภาระงานปฏิบัติการ

คนเชิงวิเคราะห์นำ SLA เชิงวิเคราะห์และเทคโนโลยีเชิงวิเคราะห์มาใช้ พวกเขาถูกฝึกให้กระทบยอด คัดสรร และปกป้องความถูกต้องภายใต้การตรวจสอบ ทักษะเหล่านี้จำเป็นสำหรับสิ้นปี การทดสอบความเครียด และการวิเคราะห์ความเสี่ยงเชิงลึก แต่ไม่เหมาะกับ product backlog ที่วัดความสำเร็จด้วย latency ถึงการตัดสินใจ ผลลัพธ์คือ思維แบบ batch ถูกนำมาใช้กับปัญหา real-time: pipeline แบบ overnight หรือรายชั่วโมงที่แต่งตัวเป็น “near real time” feature store ที่รีเฟรชตามคาเดนซ์ซึ่งหน้าต่างการอนุมัติไม่สามารถรอได้ และ customer journey ที่หยุดชะงักจนกว่าคลังข้อมูลจะบอกว่าข้อมูลพร้อม

ความเสียหายเชิงพาณิชย์ชัดเจน แม้บัญชีแยกประเภทจะไม่มีรายการชื่อ “ใช้คลังข้อมูลผิด” Next-best-action ที่มองไม่เห็นปฏิสัมพันธ์ล่าสุดสองสามครั้งคือการแสดงละคร การให้คะแนนการฉ้อโกงที่เสร็จหลังการชำระเงินคือการสืบสวน ไม่ใช่การป้องกัน ผู้ปฏิบัติการที่เคยเผยแพร่เกี่ยวกับกระแสบัตรและการชำระเงินทันที มักบรรยายงบประมาณการให้คะแนนของสถาบันอยู่ในช่วงประมาณ 50 ถึง 100 มิลลิวินาทีตั้งแต่การเสริมข้อมูล ผ่านกฎและโมเดล ไปจนถึงการตัดสินใจ หน้าต่างความถูกต้องของการอนุมัติบัตรมักถูกอ้างถึงในหลักร้อยมิลลิวินาทีต่ำ ๆ ถือช่วงเหล่านี้เป็นแนวทางอุตสาหกรรมมากกว่ามาตรฐานที่ถูกกำกับ แต่ไม่ควรแสร้งว่าวงจรความสดใหม่ของคลังข้อมูลที่วัดเป็นนาทีหรือชั่วโมงอยู่ในช่วงนั้นได้ ในขณะเดียวกันทีมวิเคราะห์ยังถูกวัดด้วยความสมบูรณ์ของ pipeline การครอบคลุม mart และต้นทุน query ทุกคนยุ่ง แต่ลูกค้ายังต้องรอ

การจัดสรรคนทำให้ความไม่ตรงกันถาวร กลุ่มที่เน้น Snowflake จะปรับให้เหมาะกับโมเดลที่คัดสรร การกำกับดูแล และ workload ที่เหมาะกับการสแกน ขอให้กลุ่มนั้นรับผิดชอบ customer API คุณจะได้รูปแบบเชิงวิเคราะห์มาประยุกต์กับปัญหาเชิงปฏิบัติการ: ชั้น mediation เพิ่มขึ้น ข้ออ้าง eventual consistency เพิ่มขึ้น และ “เราจะใส่ในคลังข้อมูลก่อน” เพิ่มขึ้น ต้นทุนไม่ใช่เพียง compute แต่คือความเร็วของผลิตภัณฑ์ที่เสียไปกับการอธิบายว่าทำไม hot path ไม่สามารถรอปฏิทินของ cold path

สองงาน สองรูปแบบของข้อมูล

งานข้อมูลเชิงวิเคราะห์คือการคัดสรร กระทบยอด และใช้คณิตศาสตร์หนัก ความถูกต้องสำคัญกว่าความเร็ว ชุดข้อมูลถูกเตรียมเพื่อให้ MI การรายงานตามกฎระเบียบ การวิเคราะห์เชิงลึกเชิงประกันภัย และการวิเคราะห์ความเสี่ยงระยะยาวเชื่อถือได้ Latency วัดเป็นนาที ชั่วโมง หรือรันข้ามคืน วินัยของ schema, lineage และหลักฐานการตรวจสอบสำคัญกว่าการอ่านข้อมูลที่เพิ่งเขียนในคำขอเดียวกัน

งานข้อมูลเชิงปฏิบัติการแตกต่างออกไป Feedback loop สั้น Latency ต่ำ เส้นทางเป็นแบบโต้ตอบกับผู้ใช้ Workload มักเขียนหนักหรือต้องการ read-your-writes ข้าง ๆ แอปพลิเคชัน: ยอดคงเหลือที่เพิ่งอัปเดต ข้อเสนอที่เพิ่งยอมรับ การตัดสินใจฉ้อโกงที่เพิ่งเกิด โมเดล consistency, indexing และพฤติกรรม concurrency ต้องสนับสนุนแอปและบริการตัดสินใจ ไม่ใช่ BI dashboard การเรียกทั้งสองอย่างนี้ว่า “ข้อมูล” ถูกต้องในภาษาอังกฤษ แต่หายนะในสถาปัตยกรรม

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

ทำไมคลังข้อมูลจึงเป็นเครื่องมือที่ผิดสำหรับ hot path

Snowflake และพวกพ้องเก่งเมื่อชุดข้อมูลถูกคัดสรรและคำถามสามารถรอได้ การเก็บแบบ columnar, micro-partition และ query engine ที่เน้น scan สร้างมาเพื่อการอ่านเชิงวิเคราะห์ขนาดใหญ่และคลังข้อมูลแบบยืดหยุ่นที่แยก workload ของ BI และความเสี่ยงจากกัน นั่นคือจุดแข็งที่แท้จริง Point lookup ด้วย primary key, transaction ขนาดเล็กความถี่สูง และการมองเห็นการเขียนล่าสุดทันที ไม่ใช่สิ่งที่ตารางคลังข้อมูลมาตรฐานถูกออกแบบมาเพื่อทำได้ดี การเปรียบเทียบอิสระระหว่างคลังข้อมูลกับฐานข้อมูลเชิงปฏิบัติการทั่วไปยังคงแสดงการแบ่งที่คุ้นเคย: คลังข้อมูลครองการรวมข้อมูลขนาดใหญ่ ฐานข้อมูลเชิงปฏิบัติการครองการอ่านแถวเดียว การอัปเดต และ traffic เชิงธุรกรรมที่มี concurrency สูง

Snowflake ได้ขยายขอบเขตด้วย Hybrid Tables ภายใต้ agenda Unistore โดยมุ่งสู่การเข้าถึงแบบ row-oriented ที่ latency ต่ำควบคู่กับ query เชิงวิเคราะห์ ซึ่งช่วยปิดช่องว่างจริงสำหรับ workload แบบผสมบางส่วนภายในระบบ Snowflake แต่ไม่ได้ทำให้คลังข้อมูลเป็นบ้านเริ่มต้นสำหรับ customer API ที่ concurrency สูง หรือเส้นทางฉ้อโกงที่ต้องเสร็จภายในงบประมาณการอนุมัติ เอกสารของ Snowflake เองระบุว่า hybrid table เป็นส่วนเสริมของตารางมาตรฐาน ไม่ใช่การแทนที่ทั้งหมดสำหรับฐานข้อมูลเชิงปฏิบัติการที่สร้างมาเพื่อวัตถุประสงค์เฉพาะภายใต้โหลดแบบ OLTP ที่ต่อเนื่อง การอ่านอย่างยุติธรรม: ใช้ Snowflake ในที่ที่การวิเคราะห์ที่คัดสรรสมควร อย่าจัดสรรให้เป็นระบบของ interaction สำหรับ live upsell, cross-sell, มุมมองธุรกรรมในเซสชัน และการให้คะแนนการฉ้อโกงแบบเรียลไทม์

สแตกแบบ Hadoop สอนบทเรียนเดียวกันแต่เร็วกว่า การประมวลผลแบบ batch-oriented และแรงดึงดูดยุค HDFS ดีเยี่ยมสำหรับการเก็บข้อมูลราคาถูกและงานออฟไลน์ แต่เป็นสถานที่ที่ไม่ดีสำหรับสิ่งที่แอปมือถือหรือการอนุมัติการชำระเงินต้องรอ การแทนที่ Hadoop ด้วยคลังข้อมูลบนคลาวด์ช่วยปรับปรุงส่วนวิเคราะห์ แต่ไม่ได้ให้สิทธิ์คลังข้อมูลเป็นเจ้าของ hot path

ทำไมถึงเป็นตอนนี้: paradigm แยกออกไปแล้ว

Streaming เป็นเรื่องปกติ ทีมผลิตภัณฑ์ส่งฟีเจอร์ที่สมมติฐานสถานะสด ลูกค้าคาดหวังว่ายอดคงเหลือ สถานะ และข้อเสนอจะสะท้อนสิ่งที่เพิ่งเกิด ไม่ใช่สิ่งที่ job โหลดเมื่อคืนกระทบยอดได้ การชำระเงินทันที เส้นทางแบบ open banking และช่องทางดิจิทัลที่เปิดตลอดเวลา ทำให้ความสดใหม่แบบคลังข้อมูลกลายเป็นภาระผลิตภัณฑ์เมื่อถูกบังคับใช้กับงานปฏิบัติการ

การรักษา “แพลตฟอร์มข้อมูล” เดียวสำหรับทั้งสองงานคือความคิดถึงขององค์กร ไม่ใช่สถาปัตยกรรม อุตสาหกรรมใช้ event bus, change-data-capture pipeline และ consumer group หลายกลุ่มเป็นมาตรฐานปฏิบัติแล้ว การแยก paradigm เห็นได้ในทุกองค์กรที่成熟แล้วที่กระจายเหตุการณ์ธุรกิจเดียวกันไปยังระนาบวิเคราะห์และระนาบปฏิบัติการ สิ่งที่ล้าหลังคือภาษาการกำกับดูแล: สไลด์กลยุทธ์ยังพูดถึงแพลตฟอร์มข้อมูลเดียว ขณะที่แผนภาพ traffic แสดงสองงานที่มี SLA ที่เข้ากันไม่ได้ ตั้งชื่อการแยกอย่างชัดเจน แล้วการโต้แย้งเรื่องการจัดสรรคนจะง่ายขึ้น ปฏิเสธที่จะตั้งชื่อ แล้วทุกโครงการจะกลายเป็นอีกหนึ่ง ticket ของคลังข้อมูล

รูปแบบเชิงปฏิบัติ: สตรีมเดียว สองที่เก็บ

รูปแบบที่ใช้การได้นั้นเรียบง่าย Domain event (หรือ CDC จากระบบบันทึก) ลงใน Kafka หรือ event bus ที่เทียบเท่า Consumer group แยกกันกระจายเหตุการณ์เหล่านั้นไปยังที่เก็บเชิงวิเคราะห์และที่เก็บเชิงปฏิบัติการ คลังข้อมูลรับ feed ที่คัดสรร แปลง และกระทบยอดสำหรับ MI การวิเคราะห์ความเสี่ยงเชิงลึก และการรายงานตามกฎระเบียบ ที่เก็บเชิงปฏิบัติการรับ projection ที่แอปพลิเคชันและบริการตัดสินใจต้องการสำหรับการอ่านและเขียน latency ต่ำ ม้าต้องตรงกับงาน: การวิเคราะห์เชิงลึกในที่ที่คลังข้อมูลสมควร MongoDB (หรือฐานข้อมูลเชิงปฏิบัติการที่คล้ายกัน) ในที่ที่แอปและการตัดสินใจอยู่

โมเดล consumer-group ของ Kafka ทำให้ fan-out เป็นคุณสมบัติชั้นแรก ไม่ใช่การผสานรวมแบบ heroic แต่ละระบบปลายทางติดตาม offset ของตัวเองและประมวลผลด้วยจังหวะของตัวเอง Consumer เชิงวิเคราะห์สามารถยอมรับการแปลงมากขึ้นและ materialisation ที่ช้ากว่า Consumer เชิงปฏิบัติการต้องการงบ lag ที่แน่นและ idempotent upsert ที่ key ด้วยตัวระบุธุรกิจ หลีกเลี่ยง dual write แบบ naive จากแอปพลิเคชันไปทั้งสองที่เก็บโดยปราศจากรูปแบบการประสานงาน Confluent และผู้ให้บริการอื่น ๆ ได้บันทึก failure mode ของ dual-write ไว้อย่างละเอียด ควรใช้การเขียน atomic เดียวที่ต้นทาง (transactional outbox หรือ CDC จากระบบบันทึก) และ derive ทั้งสองระนาบจากสตรีม

MongoDB คือตัวอย่างเชิงปฏิบัติการที่ชัดเจนสำหรับบทความนี้ เพราะ document model, secondary index และ change stream จับคู่ได้ดีกับโปรไฟล์ลูกค้า สถานะเซสชัน คุณสมบัติของข้อเสนอ มุมมองประวัติธุรกรรม และการเสริมข้อมูลการฉ้อโกงแบบ event-driven Reference architecture ด้านอาชญากรรมทางการเงินของ MongoDB เองบรรยาย change stream ที่อัปเดตโมเดลความเสี่ยงและเส้นทางคัดกรองแบบ near real time เพื่อให้การตัดสินใจไม่ต้องรอการรีเฟรชแบบ batch รูปแบบนี้ใช้ได้ทั่วไป: ที่เก็บเชิงปฏิบัติการอื่น ๆ สามารถทำหน้าที่เดียวกันเมื่อ latency รูปแบบการเข้าถึง และทักษะของทีมเหมาะสม อย่าทำให้ประเด็นจางลงโดยเปลี่ยนบทความให้เป็นการเปรียบเทียบผู้ขาย ข้อเรียกร้องคือสถาปัตยกรรม dual-path ไม่ใช่การผูกขาดผู้ขาย

ใครเป็นเจ้าของอะไร

กลุ่มเชิงวิเคราะห์เป็นเจ้าของโมเดล, mart และการรายงานตามกฎระเบียบ พวกเขาเป็นเจ้าของมาตรฐานคุณภาพสำหรับชุดข้อมูลที่คัดสรร วินัยการกระทบยอด และร่องรอยหลักฐานที่ผู้ตรวจสอบคาดหวัง ผลิตภัณฑ์และวิศวกรรมเชิงปฏิบัติการเป็นเจ้าของเส้นทาง latency ต่ำ: API, บริการตัดสินใจ, schema เชิงปฏิบัติการ และ SLA ที่อยู่ข้างลูกค้า วิศวกรรมแพลตฟอร์มอาจดูแล event bus ที่ใช้ร่วมกัน แต่การเป็นเจ้าของผลลัพธ์ต้องตามงาน

หยุดจัดสรรทีม Snowflake เพื่อสร้าง customer API หยุดวัดฟีเจอร์เชิงปฏิบัติการด้วยการที่ pipeline “เสร็จสมบูรณ์” เท่านั้น ให้ผู้นำเชิงวิเคราะห์มีขอบเขตที่ชัดเจนและหยุดขอให้พวกเขาทำเป็นเจ้าของ latency ผลิตภัณฑ์ ให้วิศวกรรมผลิตภัณฑ์มีที่เก็บเชิงปฏิบัติการ งบ latency และหยุดบังคับให้การเปลี่ยนแปลงสถานะทุกครั้งผ่านสำนักงานโครงการแบบคลังข้อมูล สัญญา event ที่ใช้ร่วมกันและการกำกับดูแล schema ควรอยู่ตรงกลาง แผนภูมิองค์กรที่ยุบทั้งสองงานไว้ใต้ “Chief Data” โดยไม่แยกความรับผิดชอบจะสร้างโหมดล้มเหลวเดิมด้วยชื่อตำแหน่งที่ดูดีขึ้น

สิ่งที่ “ดี” ควรเป็นสำหรับธนาคารและบริษัทประกัน

การจับคู่ที่เป็นรูปธรรมดีกว่าตัวแบบความ成熟แบบนามธรรม คลังข้อมูลสำหรับข้อมูลการจัดการ ประกันภัย การวิเคราะห์ความเสี่ยงเชิงลึก งาน stress และ scenario และการรายงานตามกฎระเบียบในที่ที่ความถูกต้องและ lineage ครอง ที่เก็บข้อมูลเชิงปฏิบัติการสำหรับ next-best-action การให้คะแนนการฉ้อโกงสด ยอดคงเหลือ ขีดจำกัด สิทธิ์ และประวัติในแอปในที่ที่ผู้ใช้หรือการอนุมัติไม่สามารถรอได้ SLA ที่ชัดเจนสำหรับแต่ละเส้นทาง: เป้าหมายความสดใหม่และความสมบูรณ์ของคลังข้อมูลทางหนึ่ง latency สิ้นสุดถึงการตัดสินใจ p99 read latency และการมองเห็นการเขียนทางอีกด้านหนึ่ง

การกำกับดูแลควรสะท้อนการแยก การควบคุมการเข้าถึง การเก็บข้อมูล และการพำนักยังใช้กับทั้งสองระนาบ แต่ change window แตกต่างกัน Mart เชิงวิเคราะห์สามารถตาม release train ที่คัดสรร Projection เชิงปฏิบัติการต้องการการอัปเดตต่อเนื่อง idempotent พร้อม rollback และ shadow-scoring path สำหรับการเปลี่ยนโมเดล ทีม fraud และ NBA ควรสามารถส่งอัปเดต rule หรือโมเดลโดยไม่ต้องรอปฏิทิน release ของคลังข้อมูล ในขณะที่ทีมความเสี่ยงเชิงวิเคราะห์ยังคงเก็บประวัติที่คัดสรรซึ่งโมเดลเหล่านั้นจะถูกตัดสินในภายหลัง สิ่งที่ดีคือสองเส้นทางที่มีความรับผิดชอบที่ได้รับอาหารจาก event spine เดียว ไม่ใช่แพลตฟอร์มที่โอเวอร์โหลดด้วย KPI ที่ขัดแย้งกัน

ขั้นตอนถัดไปทันที

ตั้งชื่อทุกโครงการ “ข้อมูล” ว่าเป็น operational หรือ analytical ก่อนรับงบ ถ้ามันต้องตอบลูกค้าหรือเครื่องยนต์ความเสี่ยงภายในเซสชันหรือหน้าต่างการอนุมัติ มันคือ operational ถ้ามันต้องถูกคัดสรร กระทบยอด และปกป้องได้ภายใต้การวิเคราะห์เชิงลึกหรือการรายงานตามกฎระเบียบ มันคือ analytical โครงการที่คลุมเครือซึ่งอ้างทั้งสองอย่างโดยไม่มีสถาปัตยกรรมคู่คู่ควรถูกท้าทายก่อน

หยุดฟีเจอร์ hot-path ใหม่บนคลังข้อมูล ข้อยกเว้นที่มีอยู่สามารถยกเลิกตามแผน ข้อใหม่ควรต้องมีข้อยกเว้นชัดเจนพร้อม latency SLA ที่ระบุชื่อซึ่งเส้นทางคลังข้อมูลพิสูจน์ได้ว่าตรงตาม สร้าง dual fan-out จาก event bus: consumer path หนึ่งไปยังระบบวิเคราะห์ อีก path หนึ่งไปยัง MongoDB หรือที่เก็บเชิงปฏิบัติการที่เลือก โดยติดตาม lag และ idempotency เป็นการควบคุมชั้นแรก วัด latency ถึงการตัดสินใจสำหรับ NBA และ fraud ไม่ใช่เพียงความสมบูรณ์ของ pipeline และการครอบคลุม mart จัดสรรคนให้ตรง: ทีมวิเคราะห์กับงานที่คัดสรร ผลิตภัณฑ์และวิศวกรรมเชิงปฏิบัติการกับ hot path

การยึดติดกับคำตอบแบบคลังข้อมูลเดียวสำหรับทุกปัญหาที่ติดป้าย “ข้อมูล” ไม่ใช่ทางเลือกที่ปลอดภัยอีกต่อไป Streaming ได้แยก paradigm แล้ว ธนาคารและบริษัทประกันที่วาง Snowflake ในที่ที่ curation และความลึกสมควร และ MongoDB (หรือเทียบเท่า) ในที่ที่ลูกค้าและการตัดสินใจอยู่ จะหยุดจ่ายเงินเดือนทีมวิเคราะห์เพื่อล้มเหลวกับ SLA เชิงปฏิบัติการ ผู้ที่ยังคงใช้ทีมเดียวและที่เก็บเดียวสำหรับทั้งสองงานจะยังคงค้นพบ หลังการสูญเสียและหลังเซสชันที่ถูกทิ้ง ว่าคลังข้อมูลตอบคำถามที่ลูกค้าไม่ได้ถาม