เหตุผลที่ ClickHouse กำลังนำหน้าในสงคราม Observability

 (matduggan.com)
3 คะแนน โดย GN⁺ 6 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ต่างจากประสบการณ์ใช้ grep ในระบบขนาดเล็ก เมื่อบริการและผู้ใช้งานข้อมูลเพิ่มขึ้น log จะกลายเป็นข้อมูลที่จัดการยากที่สุดใน Observability เพราะมี ปริมาณมาก·ไร้โครงสร้าง·query ที่คาดเดาไม่ได้ ซ้อนทับกัน
  • ClickHouse เริ่มต้นเป็น DB สำหรับวิเคราะห์ clickstream แต่เข้ากันได้ดีกับรูปแบบการใช้งานของ log ซึ่งคือ ปริมาณสูง·เน้นการเพิ่มข้อมูล·เรียงตามเวลา·อ่านแบบ aggregate
  • การจัดเก็บแบบ column-oriented ช่วยให้อ่านเฉพาะคอลัมน์ที่จำเป็น และในข้อมูล Observability จริงแสดง อัตราการบีบอัด 10–14x ซึ่งต่างจาก Elasticsearch ที่อยู่ที่ 2–3x
  • ที่ระดับ 1 TB/วัน หลาย stack ยังใช้งานได้ทั้งหมด แต่เมื่อโตเป็น 5 TB/วันและ 10 TB/วัน Elasticsearch·LGTM·Datadog จะเปลี่ยนโครงสร้างหรือต้นทุนอย่างมาก ขณะที่ ClickHouse ขยายได้หลัก ๆ ด้วยการ เพิ่ม shard
  • ClickHouse ต้องการ การออกแบบ schema ในช่วงต้นและมีความซับซ้อนของ query engine แต่แม้ข้อมูลจะเพิ่มขึ้นเป็นหลายเท่า model การดำเนินงานก็ไม่สั่นคลอนมากนัก

เหตุผลที่ log ยากใน Observability

  • นักพัฒนามักคาดหวังสูงกับการค้นหา log เพราะเคยจัดการ log ได้อย่างรวดเร็วในระบบขนาดเล็กด้วย grep, jq, tail -f
  • วิธีนั้นใช้ได้ดีเมื่อระบบยังเล็ก ปริมาณ log น้อย และคนที่ query เป็นคนเขียนบรรทัด log เอง
  • เมื่อ scale ใหญ่ขึ้น schema drift, cardinality explosion, ผู้ใช้งานข้อมูลข้ามทีม และความต้องการ dashboard จะเกิดขึ้นพร้อมกัน
  • คนที่ใช้ log ไม่ได้มีแค่นักพัฒนา
    • ทีม customer support ต้องค้นหาเหตุการณ์อย่างการชำระเงินที่ล้มเหลวของผู้ใช้รายหนึ่ง
    • ทีม data อาจสร้าง business dashboard บนบรรทัด log ที่ backend engineer สามารถเปลี่ยนได้
    • คน on-call คาดหวังให้ช่องค้นหาทำงานได้ทันที โดยไม่ต้องเรียนรู้ภาษา query หรือ index pattern ใหม่
  • ในเชิงเทคนิค ข้อมูลมีปริมาณมาก รูปแบบไม่สม่ำเสมอ และยากจะคาดเดาว่าจะมี query แบบใดเข้ามา
  • นักพัฒนาต้องการความทันที การคำนวณแบบ arbitrary และ schema ที่ผ่อนคลาย ส่วนผู้ใช้ที่ไม่ใช่สายเทคนิคต้องการ dashboard ที่เสถียรและ UI ที่ให้อภัยต่อข้อผิดพลาด

โครงสร้างของ ClickHouse ที่เหมาะกับ log

  • ClickHouse ถูกสร้างขึ้นที่ Yandex เพื่อประมวลผล analytical query ขนาดใหญ่บนข้อมูล clickstream
  • แม้ไม่ได้ออกแบบมาเฉพาะสำหรับ Observability แต่ข้อมูล clickstream และ Observability มีหลายอย่างคล้ายกัน
    • ข้อมูลปริมาณมาก
    • การเขียนแบบเน้นเพิ่มข้อมูล
    • เน้นลำดับเวลา
    • อ่านแบบ aggregate เป็นหลัก
    • มีรูปแบบการใช้งานที่บางครั้งต้องค้นหา record เฉพาะ
  • วิธีดำเนินงานก็มีหลายตัวเลือก
    • รันเองได้ด้วย Helm chart
    • ใช้ปลั๊กอิน ClickHouse ของ Grafana, web UI ของตัวเอง หรือ frontend ที่สร้างเองได้
    • ใส่ข้อมูล OTLP เข้าโดยตรงผ่าน ClickHouse exporter ของ OpenTelemetry Collector และให้ช่วยจัดการ schema เริ่มต้นได้
  • ออกแบบมาเพื่อ scan หลายพันล้านแถวและ ingest ข้อมูลปริมาณใหญ่มาก
  • ภาษา query ไม่ใช่ภาษาเฉพาะใหม่ แต่เป็น SQL

ความต่างที่เกิดจาก column-oriented storage และการบีบอัด

  • ตามรูปแบบข้อมูลแล้ว log ใกล้เคียงกับ append-only
    • บรรทัด log ไม่ถูก update
    • แทบไม่มีการลบราย record และเมื่อครบระยะ retention จะลบทีละมาก ๆ
    • โดยทั่วไปมาถึงตามลำดับเวลา แต่ไม่ได้เรียงอย่างสมบูรณ์
  • รูปแบบการอ่านจะเปลี่ยนแบบพุ่งสูงในช่วง incident หรือการวิเคราะห์
    • อาจไม่มีใครดูหลายวัน แต่ระหว่าง incident ก็อยากไล่ดูหลายพันล้านรายการภายในไม่กี่วินาที
    • มักดูหลาย field ในช่วงเวลาแคบ ๆ หรือ aggregate ด้วย filter ไม่กี่ตัวในช่วงเวลากว้าง ๆ
    • รูปแบบการหาแถวเดียวจาก ID เฉพาะแบบ transaction DB พบได้น้อย
  • DB แบบ row-oriented อย่าง Elasticsearch, Postgres, MySQL จะเก็บทุก field ของ log line ไว้ด้วยกัน
    • แม้ต้องการแค่ 3 จาก 40 field ก็ต้องอ่านทั้ง 40 field จาก disk
  • ClickHouse เก็บแต่ละคอลัมน์แยกกัน
    • query ที่ใช้แค่ timestamp, service, status_code จะอ่านเฉพาะคอลัมน์เหล่านั้น
    • สำหรับข้อมูล Observability ที่มี attribute หลายสิบรายการ แต่ query หนึ่งใช้แค่ 3–4 คอลัมน์ ความต่างของปริมาณการอ่านจะมาก
  • ข้อมูลแบบ column บีบอัดได้ดี เพราะค่าในคอลัมน์เดียวกันมักคล้ายกัน
    • คอลัมน์ service_name อาจมี string ที่ไม่ซ้ำกันเพียงไม่กี่ร้อยค่า แม้มีข้อมูลหลายพันล้านแถว
    • ในข้อมูล Observability จริง มักเห็น อัตราการบีบอัด 10–14x
    • แตกต่างชัดเจนจาก Elasticsearch ที่ 2–3x

ที่ 1 TB/วัน stack ส่วนใหญ่ยังเป็นไปได้

  • ที่ระดับ 1 TB/วัน stack Observability สมัยใหม่โดยรวมยังใช้งานได้ และแม้มีความต่าง แต่ยังไม่ถึงขั้นเจ็บปวด

  • Elasticsearch

    • ดำเนินงานได้ด้วย cluster Elasticsearch ค่อนข้างพื้นฐานและ Logstash buffer
    • full-text search เป็นจุดแข็งของ Elasticsearch และทำงานได้ดีในระดับนี้
    • สำหรับข้อมูลแบบผสม มีความเสี่ยง mapping explosion จึงต้องปิด dynamic mapping หรือกำหนด template อย่างระมัดระวัง
    • นโยบาย ILM แบบ hot → warm → delete ยังจำเป็นแม้ในระดับนี้
    • ต้นทุนอยู่ราว $6–9K ต่อเดือน

  • LGTM

    • Alloy รวมการเก็บข้อมูลไว้ใน daemon เดียว
    • Loki จะทำงานได้ดีเมื่อฝึกให้นักพัฒนาติด label ที่มีประโยชน์
    • Mimir และ Tempo โดยรวมทำหน้าที่ตามที่คาดหวัง
    • ต้นทุนอยู่ราว $3.5–5K ต่อเดือน

  • Datadog

    • ที่ 1 TB/วัน ใช้งานง่ายในระดับติดตั้ง agent แล้วดู dashboard ได้เลย
    • เริ่มเห็นประเด็นอย่าง metered pipeline, การแยก indexed-vs-ingested logs และต้นทุน cardinality ของ custom metrics แต่ยังจัดการได้ในระดับนี้
    • ต้นทุนอยู่ราว $45–75K ต่อเดือน และเพราะราคาที่เจรจาได้ต่างกันมาก จึงควรมองตัวเลขแบบกว้าง ๆ
    • เหตุผลด้านราคาของ Datadog คือทำนองว่าช่วยประหยัดวิศวกรประจำ 1 คน

  • ClickHouse

    • ที่ 1 TB/วัน ClickHouse ไม่ได้ซับซ้อนน้อยกว่าทางเลือกอื่น
    • ต้องมี การออกแบบ schema ตั้งแต่ต้น และ key ของ ORDER BY สำคัญมาก
    • ด้วย ZSTD และ codec ที่เหมาะสม สามารถได้ การบีบอัด 10–14x
    • Altinity Operator จัดการ keeper coordination และโดยรวมรันด้วยประมาณ 7 pod
    • ไม่มี PromQL แบบ native และ workflow สำหรับ metrics ต้องผ่านปลั๊กอิน Grafana หรือ chproxy กับ adapter
    • ต้นทุนอยู่ราว $1.5–2.5K ต่อเดือน

ที่ 5 TB/วัน ความต่างด้านโครงสร้างเริ่มชัด

  • ที่ 5 TB/วัน เส้นโค้งการเติบโตของ stack ส่วนใหญ่จะชันขึ้น และเห็นช่องว่างกับ ClickHouse ชัดเจนขึ้น

  • Elasticsearch

    • Kafka แทบจะกลายเป็นสิ่งจำเป็น
    • หากเขียนเข้า Elasticsearch โดยตรง cluster อาจล่มระหว่าง traffic spike เพราะ bulk reject และ backpressure
    • หากตั้ง target shard ที่ 50GB เมื่อรวม replica แล้วจะเกิดประมาณ 200 shard ต่อวัน และขนาดของ cluster state เองจะกลายเป็นปัญหา
    • searchable snapshot และ frozen tier ทำให้แทบต้องใช้ license เชิงพาณิชย์ของ Elastic
    • ต้นทุนก่อน license อยู่ราว $40–55K ต่อเดือน

  • LGTM stack

    • กลายเป็น microservices mode ที่ต้องรันมากกว่า 65 pod และระบบแยกกัน 3 ระบบ
    • แต่ละระบบมี compaction pipeline, hash ring, memcached tier ของตัวเอง
    • gossip/memberlist ring กลายเป็นประเด็นปฏิบัติการจริง
    • การ rollout ingester ต้องปรับ -ingester.autoforget-unhealthy และหากพลาดอาจเกิดข้อมูลสูญหายหรือซ้ำซ้อน
    • ต้นทุนอยู่ราว $22–32K ต่อเดือน

  • Datadog

    • ความซับซ้อนในการดำเนินงานต่ำ เพราะไม่ต้องดูแล server เอง
    • แต่จะต้องมีทีม pipeline โดยเฉพาะเพื่อลดค่าใช้จ่าย Datadog
    • จะมีเครื่องมืออย่าง exclusion filter, sampling rule, cardinality cap, tag allow-list
    • ต้นทุนอยู่ราว $180–350K ต่อเดือน ขึ้นกับความ aggressive ของทีม pipeline
    • กลายเป็นความสัมพันธ์ที่ต้องคอยดูเอกสาร billing ของผู้ให้บริการ SaaS เพื่อหาทางลดค่าใช้จ่าย

  • ClickHouse

    • การเปลี่ยนแปลงใหญ่ที่สุดคือ การเพิ่ม shard
    • operator, query engine, query language และ mental model ยังคงเดิม
    • หลังเพิ่ม shard การ rebalance ต้องทำด้วยตนเอง และทีมส่วนใหญ่มักเลี่ยงด้วยการ provision ล่วงหน้าหรือใช้ weighting ของ Distributed table
    • materialized view สำหรับ dashboard rollup เปลี่ยนจากสิ่งที่มีก็ดีเป็นแทบจำเป็น
    • ต้นทุนอยู่ราว $7–11K ต่อเดือน

ที่ 10 TB/วัน model การดำเนินงานแยกทางกัน

  • 10 TB/วันเป็นระดับที่หลายโซลูชันเริ่มรับภาระการดำเนินงานได้ยาก

  • Elasticsearch

    • ต้องรัน cluster Elasticsearch แยก 3 ชุดสำหรับ logs, metrics, APM แล้วเชื่อมด้วย Cross-Cluster Search
    • ค่าใช้จ่ายของ hot-tier NVMe จะครองบิล
    • ที่ระดับนี้ ทีมต่าง ๆ เริ่มประเมินทางเลือกอย่างจริงจัง และการ migrate ไป ClickHouse ช่วงหลังก็เกิดจากระดับนี้เป็นจำนวนมาก
    • ต้นทุนอยู่ราว $95–140K ต่อเดือน นอกเหนือจาก license เชิงพาณิชย์
    • การดำเนินงาน Elasticsearch ในระดับนี้ต้องมีผู้เชี่ยวชาญตัวจริง

  • LGTM

    • ต้องมีประมาณ 180 pod ขึ้นไป, การตั้งค่าแบบ zone-aware, split-and-merge compaction, limit แยกตาม tenant และ shuffle sharding เพื่อป้องกัน noisy neighbor
    • แทบต้องมีทีม Observability platform โดยเฉพาะ 3–5 คน
    • ต้นทุนอยู่ราว $55–85K ต่อเดือน

  • Datadog

    • ในความหมายที่ว่าไม่มี server ต้องดูแลเอง ก็ยังถือว่าง่าย แต่บิลรายเดือนอาจเป็นตัวเลข 6–7 หลัก
    • องค์กรมีแนวโน้มสูงที่จะสร้างทีม preprocessing pipeline เพื่อลดบิล
    • บริษัทจำนวนมากในระดับนี้ใช้ Datadog สำหรับ APM และ metrics ที่มีมูลค่าสูง แล้วนำ logs ไป self-host ในรูปแบบ hybrid
    • เป้าหมายของการ self-host ค่อย ๆ กลายเป็น ClickHouse
    • จึงเป็นโครงสร้างที่ความเรียบง่ายของ Datadog, ความซับซ้อนของ pipeline และ stack self-host ชุดที่สองอยู่ร่วมกัน
    • ต้นทุนแตกต่างกันมาก และอาจสูงกว่า $1M ต่อเดือน

  • ClickHouse

    • ภาพพื้นฐานเหมือนกับการตั้งค่า 1 TB/วัน ต่างกันที่มี shard มากขึ้น
    • materialized view สำหรับ rollup ไม่ใช่ตัวเลือก แต่เป็นสิ่งจำเป็น
    • ความผิดพลาดในการออกแบบ schema เมื่อ 2 ปีก่อนอาจเผยผลเสียอย่างเจ็บปวดในระดับนี้
    • หลังเพิ่ม shard การ rebalance ยังคงต้องทำด้วยตนเอง
    • ทีมส่วนใหญ่จะ provision ล่วงหน้า หรือใช้ clickhouse-copier, dual-write migration
    • สำหรับ ingest ที่ bursty มาก Kafka จะมีประโยชน์ในฐานะ buffer แต่ไม่จำเป็นเสมอไป
    • ต้นทุนอยู่ราว $18–28K ต่อเดือน

เกณฑ์ในการเลือก

  • ที่ 1 TB/วัน stack ใด ๆ โดยรวมก็ทำงานได้ จึงควรเลือกสิ่งที่ทีมรู้อยู่แล้ว
  • คำถามสำคัญไม่ใช่ว่าวันนี้มันทำงานได้หรือไม่ แต่คืออีก 2 ปีเมื่อข้อมูลเพิ่ม 5 เท่า ทีมเพิ่ม 2 เท่า และผู้ออกแบบช่วงต้นจากไปแล้ว มันยังคงรูปแบบเดิมได้หรือไม่
  • Elasticsearch และ LGTM จะเปลี่ยนโครงสร้างเมื่อ scale ใหญ่ขึ้น
  • Datadog เรียบง่ายในเชิงปฏิบัติการ แต่ในด้านต้นทุนจะเปลี่ยนไปเป็นรูปแบบที่ต้องมีทีมบัญชี·pipeline แยกต่างหาก
  • ClickHouse ขยายออกด้วย วิธีเพิ่ม shard
  • สิ่งที่ต้องแลกคือการยอมรับการออกแบบ schema ตั้งแต่ต้นและความซับซ้อนของ query engine
  • หากยอมจ่ายราคานี้ แม้ข้อมูลจะโตขึ้นมากกว่าหนึ่งหลัก ประสบการณ์ของนักพัฒนาและผู้ปฏิบัติการโดยรวมก็ยังคงเดิม

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

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

 
GN⁺ 6 시간 전
ความคิดเห็นจาก Lobste.rs

  • สตาร์ตอัปที่เคยทำงานอยู่ช่วงสั้น ๆ ในปี 2019 สร้างของที่น่าประทับใจไว้เยอะมาก และตอนนั้นก็ได้เห็น ClickHouse นิดหน่อย ซึ่งทำให้ประทับใจมาก
    ก่อนหน้านั้นผมคิดว่าแทบไม่มีเหตุผลที่จะต้องใช้อะไรนอกจาก PostgreSQL แต่ ClickHouse ทำให้รู้สึกอยากลองใช้ขึ้นมาจริง ๆ
    เคยใช้ทั้ง ElasticSearch, InfluxDB และตัวอื่น ๆ ด้วย แต่ไม่ค่อยประทับใจเสมอไป น่าจะเพราะแต่ละตัวสร้างภาษาคิวรีของตัวเองขึ้นมาใหม่ตั้งแต่ต้น ขณะที่ ClickHouse เลือกใช้ SQL ที่คุ้นเคยและขยายเฉพาะส่วนที่จำเป็นอย่างเหมาะสม
    เหมือนผลิตภัณฑ์ที่ประสบความสำเร็จหลายตัว ClickHouse ให้ความรู้สึกว่าคุณภาพการพัฒนาดีและใส่ใจผู้ใช้ รายละเอียดเล็ก ๆ น้อย ๆ ก็ถูกตั้งค่าเริ่มต้นมาอย่างลงตัว
    ตอนนี้ที่บริษัทใช้ HyperDX อยู่ กราฟ metrics อาจจะใช้งานยุ่งยากนิดหน่อย แต่ tracing ทำงานได้ดีพอสมควร ตอนแรกคิดว่า tracing จะกลายเป็นเครื่องมือจำเป็นอย่างรวดเร็วและเพิ่ม productivity ได้มาก แต่พอเห็นว่ายังไม่ได้รับการยอมรับเท่าที่คาด ก็เลยรู้สึกว่ามันอาจไม่ใช่ฟีเจอร์ที่เปลี่ยนเกมได้ขนาดนั้น ถึงอย่างนั้นการที่ ClickHouse กลายเป็นผู้เล่นหลักในพื้นที่นี้และทำให้ไม่ต้องไปยุ่งกับของอื่นมากนักก็เป็นเรื่องน่ายินดี

    • จากประสบการณ์ของผม การนำ tracing เข้าไปในองค์กรที่เดิมอยู่ได้ด้วยแค่ metrics กับ logs นั้นชันพอสมควร
      ต้องอาศัยการ evangelize เยอะมาก ต้องรวบรวม use case และต้องทำงานหนักเพื่อแสดงให้เห็นโดยตรงว่าตอนนี้เราทำสิ่งที่เมื่อก่อนทำไม่ได้แล้วได้ และสิ่งที่เคยยากนั้นง่ายขึ้นแค่ไหน
      ในทางเทคนิค การนำไปใช้ก็ต้องลื่นไหลให้มากที่สุดด้วย ซึ่งขึ้นกับสแตกและบริบทแล้วมันอาจเป็นงานใหญ่ในตัวเอง และปกติภาระนั้นก็มักจะตกไปอยู่กับคนที่เป็นคนผลักดันการใช้งาน
      มันแทบไม่ต่างจาก initiative ระดับองค์กรที่กินวงกว้าง ดังนั้นถ้ามี ผู้ศรัทธาตัวจริง สักหนึ่งหรือสองคนที่มีความน่าเชื่อถือส่วนบุคคลและช่วยเผยแพร่สิ่งนี้ในบริษัทได้ ก็จะมีประโยชน์มาก
    • สงสัยว่ากำลังหมายถึงภาษา query แบบ JSON ของ ElasticSearch หรือเปล่า ElasticSearch รองรับ multiple query languages รวมถึง SQL dialect ด้วย
      ไม่รู้ว่าคุณภาพของการรองรับนั้นเป็นอย่างไร แต่ที่เคยใช้เองมีแค่ภาษา query แบบ JSON และเพิ่งรู้เดี๋ยวนี้เองว่ามีแบบอื่นด้วย
      ในฐานะภาษาคิวรี SQL ก็ไม่ได้สมบูรณ์แบบ จะให้หงุดหงิดตรงที่ clause ซ้ำกันไม่ได้และเรียงลำดับตามใจไม่ได้ แต่ถึงอย่างนั้น SQL ก็ยังเป็นภาษาที่ดีมาก

  • ประสบการณ์ของผมก็คล้ายกับผู้เขียน ความสามารถในการขยายระบบของ ClickHouse ดีจนน่าทึ่ง และต่อให้รันเองก็มักจะเป็นเรื่องของการเพิ่ม core เข้าไปมากกว่า
    ค่าใช้จ่ายในการตั้งค่าเริ่มต้นอาจสูงกว่าเล็กน้อย แต่ schema นั้นแทบจะถูกกำหนดมาให้โดย OTel export อยู่แล้ว จึงเริ่มจากตรงนั้นได้ และเมื่ออยากได้ประสิทธิภาพคิวรีเพิ่มก็ค่อยดึง columns กับ materialized views ออกมา
    สิ่งที่ได้ตอบแทนคือกังวลเรื่องการสเกลน้อยลง สามารถนำข้อมูลทั้งหมดไปใช้วิเคราะห์ได้โดยตรง และยังสามารถ derive metrics จาก traces ได้ด้วย
    แต่ visualization ซึ่งเป็นอีกชิ้นส่วนหนึ่งของปริศนายังต้องปรับปรุงอีกมาก Grafana ไม่ได้เหมาะที่สุดเมื่อเทียบกับเครื่องมืออย่าง Honeycomb สำหรับการแสดงและวิเคราะห์ traces หวังว่าจะมีผู้เล่นเดิมสักรายแก้ปัญหานี้ได้ในไม่ช้า อาจจะเป็น HyperDX ก็ได้

  • ตอนแรกบทความนี้ให้ความรู้สึกว่าเปิดมาได้แรงด้วยเกริ่นนำที่น่าเชื่อถือ แต่พอไปถึงส่วนที่วิเคราะห์หลายบริษัท มันกลับพังลงเป็นบทความแบบลิสต์ที่มีกลิ่น สำนวน LLM แบบใช้แรงน้อย ชัดเจน
    พอกลับไปอ่านเกริ่นนำแบบวิจารณ์มากขึ้นก็ยิ่งเริ่มเห็นร่องรอยนั้นมากขึ้นเรื่อย ๆ
    มันเป็นรูปแบบที่เห็นบ่อยขึ้นเรื่อย ๆ ในโพสต์บน Lobsters ช่วงหลัง เลยอยากทิ้งความเห็นสั้น ๆ ในฐานะข้อสังเกตทั่วไปมากกว่าจะโจมตีบทความนี้เป็นการเฉพาะ
    ส่วนตัวผมไม่ได้มีประสบการณ์กับเครื่องมือ observability มากนัก ดังนั้นบางส่วนของบทความก็น่าสนใจโดยไม่เกี่ยวกับวิธีการเขียน แต่ผมก็ไม่อยากตกอยู่ในความผิดพลาดแบบเชื่อ LLM ในหัวข้อที่ไม่คุ้นเคย แล้วพอเป็นหัวข้อที่คุ้นเคยกลับบอกว่าบทความจาก LLM นั้น flawed
    เพราะแบบนั้นผมเลยไม่ค่อยแน่ใจว่าควรเชื่อถือข้อเท็จจริงของบทความนี้หรือบทความคล้าย ๆ กันส่วนใหญ่ได้แค่ไหน ดูชัดว่าผู้เขียนโยนงานคิดส่วนใหญ่ให้เครื่องทำ แต่ความคิดตั้งต้นเองก็ดูค่อนข้างชัดเจนอยู่
    เวลาเขียนโปรแกรม ความคิดที่ชัดเจนในหัวของผมเองก็มักจะทำให้ยอมรับได้ว่ามีบางอย่างขาดหายไปโดยพื้นฐาน ก็ต่อเมื่อได้ลงมือเขียนโปรแกรมจริงแล้วเจอกรณีขอบที่ทดสอบไม่ผ่านหรือไม่ผ่าน type checks
    งานเขียนก็เหมือนกัน ถ้าไม่ได้สร้างข้อโต้แย้งขึ้นมาเอง ประกอบทั้งชิ้นงานขึ้นมาเอง แล้วพิจารณาข้อโต้แย้งกลับอย่างรอบคอบ ผมก็ไม่คิดว่ามันส่งมอบคุณค่าได้มากไปกว่าความคิดชัดเจนตั้งต้นเท่าไร
    ผมเดาว่านี่ก็คือจุดที่คนซึ่งบอกว่าควรเขียนโค้ดด้วยการเก็บแค่ prompt ไว้ให้ LLM ในอนาคตกำลังพยายามจะสื่อ
    แต่ถ้าการเขียนโปรแกรมหรือการเขียนทั้งหมดกลายเป็นแบบนั้น ก็เท่ากับเราทิ้งไม่ใช่แค่การคิด แต่รวมถึง ความเข้มงวด ความซื่อสัตย์ และความเคารพ ไปด้วย
    ผมไม่แน่ใจว่า Lobsters ควรทำอะไรกับเรื่องนี้ดี แท็ก vibecoding ดูเหมือนเป็นวิธีแก้ที่ใช้งานเกินพิกัดอยู่แล้ว แต่การมีแท็ก กลิ่น LLM เพื่อเตือนให้ระวังความไม่เข้มงวดอาจช่วยได้

    • ผมเองก็ไม่อยากโพสต์เรื่องนี้เป็นคอมเมนต์บนสุดเหมือนกัน แต่พอกดเข้าไปอ่านเนื้อหาจริงแล้วมันเป็นแค่ คำพูดสำเร็จรูปแบบ LLM เลยรู้สึกเสียดายเวลาที่ใช้ไปกับการอ่านช่วงต้นนิดหน่อย
    • จากมุมคนที่เคยใช้เครื่องมือ observability มาบ้าง มันดูเป็นบทความที่ชัดเจนและสมเหตุสมผลพอสมควร
      ใจความหลักคือแต่ละผลิตภัณฑ์มีวิธีสเกลต่างกัน และบทความก็แสดงให้เห็นผ่านแผนภาพกับคำอธิบายที่เป็นรูปธรรมว่าในแต่ละขนาดจะเกิดอะไรขึ้น
      ถ้ามีส่วนไหนที่ทำให้รู้สึกว่าผู้เขียนละทิ้งการคิดอย่างชัดเจน ผมก็อยากรู้ตัวอย่างเหมือนกัน
    • อย่างน้อย Matthew ก็เป็นคนที่เชี่ยวชาญด้าน observability พอสมควร เขาเคยเป็น tech lead ที่ Braintree และตอนนี้เป็น Principal ที่ SYBO ซึ่งเป็นที่รู้จักจาก Subway Surfers
      ส่วนที่มีคำหยาบปนอยู่ก็ดูเหมือนสะท้อนน้ำเสียงของเจ้าตัวเองอยู่บ้าง
      ถ้าเอาไปใส่ GPTZero จะได้ผลว่าเป็นไปได้ 71% ว่าเป็น LLM และ 28% ว่าเป็นแบบผสม แต่เกริ่นนำซึ่งอ่านดูเป็นมนุษย์ที่สุดถูกตัดออกไปเพราะข้อจำกัดจำนวนตัวอักษร
      ผมเข้าใจความรู้สึกต่อต้านนะ แต่ดูเหมือนมันเป็นงานเขียนที่ผ่านการทบทวนและแก้ไขซ้ำจริง ๆ และใกล้เคียงกับกรณีที่ไม่ได้พยายามกรองสำนวนแบบ LLM หรือปรับโทนให้เหมาะที่สุดมากกว่า ทุกวันนี้แค่ไม่ใช้ em dash อย่างเดียวก็ไม่พอจะหลบกลิ่นแล้ว

  • สำหรับคนที่มีประสบการณ์กับ Honeycomb อยากรู้ว่ามันเข้ากับบริบทนี้อย่างไร
    เท่าที่ผมรู้ Honeycomb ก็ใช้รูปแบบการเก็บข้อมูลแบบคอลัมน์ และพึ่งพาการบีบอัดกับ bucketing อย่างมากเพื่อข้ามข้อมูลจำนวนมากตอนอ่าน มันไม่น่าใช่แนวใช้ inverted index แบบ Elastic หรือ Datadog และเท่าที่รู้ Datadog เองก็รัน Elastic ภายในด้วย

    • จำได้ว่าหลายปีก่อน Charity Majors ผู้ร่วมก่อตั้ง Honeycomb เคยพูดบน Twitter ว่า ถ้าตอนเริ่มบริษัทมี ClickHouse อยู่แล้ว ก็คงใช้มันไปเลย
      แต่ก็ยังไม่แน่ใจว่าสองระบบนี้ทับซ้อนกันในเชิงแนวคิดมากน้อยแค่ไหน คงน่าสนใจถ้ารู้ว่าปัญหาในโดเมนนี้พาไปสู่วิธีการที่คล้ายกันโดยธรรมชาติหรือไม่ ซึ่งส่วนตัวผมเดาว่าน่าจะใช่

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