อนาคตของ kdb+?

 (timestored.com)
1 คะแนน โดย GN⁺ 2024-08-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

กรณีการใช้งาน

  • การจัดเก็บและวิเคราะห์ข้อมูลตลาดย้อนหลัง

    • ตัวอย่าง: MS Horizon, Citi CloudKDB, UBS Krypton

  • การวิเคราะห์เชิงปริมาณแบบโลคัล

    • ตัวอย่าง: การวิเคราะห์สภาพคล่อง, การวิเคราะห์ PnL, การวิเคราะห์ความสามารถในการทำกำไรแยกตามลูกค้า

  • เอนจินคำนวณสตรีมมิงแบบเรียลไทม์

    • ตัวอย่าง: สตรีมมิง VWAP, สตรีมมิง TCA

  • การประมวลผลแบบกระจาย

    • ตัวอย่าง: การคำนวณมาร์จินหรือการวิเคราะห์ความเสี่ยงของพอร์ตหุ้น

ทางเลือก

ข้อมูลตลาดย้อนหลัง - ทางเลือกของ kdb+

  • เทคโนโลยีฐานข้อมูลใหม่

    • Clickhouse, QuestDB

  • ผู้ให้บริการคลาวด์

    • Bigquery, Redshift

  • บริการข้อมูลตลาด

    • ผู้ใช้ส่วนใหญ่ไม่จำเป็นต้องใช้ "ความเร็ว" ของ kdb+
    • แพลตฟอร์มภายในของธนาคารส่วนใหญ่ยังใช้ประโยชน์จากความเร็วของ kdb+ ได้ไม่เต็มที่
    • คู่แข่งตอนนี้ก็เร็วเพียงพอแล้วเช่นกัน

ผลลัพธ์ที่คาดการณ์

  • kdb+ อาจรักษาฐานลูกค้าเดิมไว้ได้ แต่จะไม่ได้บริษัทระดับรองที่ต้องการความเป็น cloud-native หรือสิ่งอื่นแทน

การวิเคราะห์เชิงปริมาณแบบโลคัล - ทางเลือก

  • Python
    • DuckDB, Polars, PyKX, dataframe/modin เป็นต้น

ผลลัพธ์ที่คาดการณ์

  • DuckDB หรือ Polars จะเป็นผู้ชนะ เพราะใช้ฟรี

สตรีมมิงแบบเรียลไทม์ / การประมวลผลแบบกระจาย

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

ผลลัพธ์ที่คาดการณ์

  • kdb+ จะไม่ชนะ Kafka ได้ครองพื้นที่ในความรับรู้ของตลาดไปแล้ว และ flink/risingwave ก็กำลังเป็นดาวรุ่ง

สรุป

  • kdb+ เป็นเทคโนโลยีที่น่าทึ่ง แต่ยังอยู่ในระดับเดียวกับเมื่อ 15 ปีก่อน

  • บริษัทโอเพนซอร์สชั้นนำได้ขโมยแนวคิดของ kdb+ ไป

    • Parquet/Iceberg คือฟอร์แมตบนดิสก์ของ kdb+
    • Apache Arrow คือฟอร์แมตในหน่วยความจำของ kdb+
    • แนวคิด log/replay/ksql ของ Kafka ก็คล้ายกัน
    • QuestDB, DuckDB, Clickhouse ต่างก็รองรับ asof join

  • คู่แข่งได้ทำให้ส่วนที่ดีที่สุดของ kdb+ กลายเป็นมาตรฐานแล้ว

    • ตัวอย่าง: Snowflake, Dremio, Confluent, Databricks ต่างก็รองรับ Apache Iceberg/parquet
    • QuestDB, DuckDB, Python ต่างก็รองรับ parquet แบบเนทีฟ

  • KX ต้องทำ 4 อย่างต่อไปนี้

    • ต้องมีเวอร์ชันฟรี และมีไลเซนส์ที่ใช้งานได้ในต้นทุนต่ำ
    • ต้องทำให้ผลิตภัณฑ์หลักยอดเยี่ยม
    • ต้องลดความชันของการเรียนรู้
    • ต้องทำให้ได้รับความนิยมมากขึ้น

สรุปโดย GN⁺

  • kdb+ ยังเป็นเทคโนโลยีที่ทรงพลัง แต่คู่แข่งกำลังไล่ตามอย่างรวดเร็ว
  • เครื่องมือฟรีและโอเพนซอร์สกำลังได้รับความนิยม ทำให้มีโอกาสสูงที่ส่วนแบ่งตลาดของ kdb+ จะลดลง
  • หาก kdb+ ต้องการได้รับความนิยมมากขึ้น จำเป็นต้องมีเวอร์ชันฟรี ลดความชันของการเรียนรู้ และเสริมความแข็งแกร่งให้ผลิตภัณฑ์หลัก
  • ผลิตภัณฑ์ที่มีความสามารถคล้ายกัน ได้แก่ DuckDB, Polars, QuestDB เป็นต้น

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-08-04
ความคิดเห็นจาก Hacker News

  • TimeScale เป็นส่วนขยายของ Postgres จึงสามารถใช้ความสามารถของ SQL ได้โดยตรง

    • มีฟังก์ชันบีบอัดแบบคอลัมน์สโตร์ จึงทำงานได้เร็วมาก
    • เคยมีประสบการณ์ใช้งานในแอปพลิเคชันการเงิน และสามารถประมวลผลข้อมูลปริมาณมากได้อย่างรวดเร็ว
    • การซัพพอร์ตใน Slack ดี และโดยส่วนตัวพอใจมาก
    • kdb มีค่าใช้จ่ายสูง และภาษาก็ไม่มีประสิทธิภาพ

  • มีกรณีที่ลาออกภายใน 2 สัปดาห์เพราะประสบการณ์การใช้ kdb+

    • การออกแบบภาษาและการดีบักไม่สะดวก และไม่มีหรือมีมาตรฐานการเขียนโค้ดไม่เพียงพอ
    • วัฒนธรรมองค์กรก็เป็นปัญหา และโค้ดไม่ได้มีการจัดทำเอกสารไว้อย่างดี
    • สแตกทั้งหมดล้าสมัย และใช้วิธีคัดลอกข้อมูลจาก qStudio ไปยัง Excel เพื่อวาดกราฟ
    • การไม่ใช้ Docker และ k8s แต่ดีพลอยลงเซิร์ฟเวอร์โดยตรงถือเป็นข้อดี
    • kdb ถูกใช้งานเหมือนอาวุธมากกว่าเป็นเครื่องมือ

  • ความสามารถด้านการบูรณาการแนวดิ่งของ kdb+ เป็นข้อดี

    • เทคโนโลยีเดียวสามารถทำหน้าที่ได้หลายอย่าง
    • มีภาษา Q, การทำซีเรียลไลซ์ข้อมูล, และความสามารถ IPC จึงสร้างระบบที่ปรับแต่งเองได้
    • อย่างไรก็ตาม kdb+ เป็นซอฟต์แวร์แบบปิดและมีราคาแพง จึงนำไปใช้กับโปรเจกต์ใหม่ได้ยาก

  • kdb+ เป็นที่รู้จักน้อยเพราะไม่มีเวอร์ชันฟรี

    • เคยมีประสบการณ์ใช้ kdb+ ในสายการเงิน และมองว่าการออกแบบกับความเรียบง่ายคล้ายปรัชญา Unix
    • หลังออกจากวงการการเงินก็ยังอยากใช้ kdb+ ต่อ แต่ไม่มีเวอร์ชันฟรีจึงไม่สะดวก

  • มีกรณีที่ไม่ชอบ q/kdb+ จนพัฒนาภาษาของตัวเองขึ้นมา

    • ปัจจุบัน Python ถูกใช้งานมากที่สุด

  • มีประสบการณ์ใช้งาน kdb+ จนดำเนินสตาร์ทอัปได้สำเร็จ

    • แต่เพื่อขยายทีมจึงต้องเขียนใหม่ด้วย FOSS
    • คิดว่า kx ควรเปลี่ยนแพลตฟอร์มเป็นโอเพนซอร์ส

  • kdb+ น่าสนใจ แต่ราคาสูงเกินไป

    • กำลังมองข้ามลูกค้าที่มีศักยภาพจำนวนมาก

  • มีการแก้ไขบางประการเกี่ยวกับ ClickHouse

    • ClickHouse เป็นโอเพนซอร์สมาตั้งแต่ปี 2016 และเริ่มพัฒนามาตั้งแต่ปี 2009
    • ClickHouse รองรับยูสเคสทั้งสามแบบได้ทั้งหมด
    • ClickHouse เป็นฐานข้อมูล SQL แรกที่นำ ASOF JOIN มาใช้ในปี 2019

  • ปัจจุบัน Python เหนือกว่า แต่หนี้ทางเทคนิคทำให้เปลี่ยนไปใช้แพลตฟอร์มใหม่ได้ยาก

    • โปรเจกต์พัฒนาใหม่จะใช้ Python

  • มีคำถามว่านักพัฒนา kdb+ สามารถทำเงินก้อนใหญ่ได้หรือไม่

    • เมื่อไม่กี่ปีก่อน เคยมีตำแหน่งงานที่ให้เงินเดือนปีละ 1 ล้านดอลลาร์