Gözlenebilirlik platformlarının evrimi, silo halindeki veri ambarlarından ve pahalı özel indekslerden, veri göllerinin esnekliğini depo performansı ile birleştiren birleşik lakehouse mimarilerine kaydı. Erken SaaS gözlenebilirlik sağlayıcıları, petabayt ölçeğinde kesirsel maliyet eğrileri ile karşılaşan ve gerçek çok kiracı izolasyonu ile başa çıkamayan Elasticsearch veya Splunk kümelerine dayanıyordu. Apache Iceberg ve Delta Lake gibi açık tablo formatlarının ortaya çıkışı, nesne depolama üzerinde atomik işlemler ve zaman yolculuğu sağladı. Sorgu motorlarının olgunlaşması, Trino gibi bulut depolama üzerinde etkileşimli SQL sağladı. Bu birleşim, tek bir paylaşımlı altyapıdan binlerce kiracının hizmet almasını mümkün kıldı, ancak alt saniye gecikmesini koruma ve katı güvenlik sınırlarını uygulama ve akıllı katmanlama yoluyla depolama maliyetlerini optimize etme konusunda yeni zorluklar ortaya çıkardı.
Kritik zorluk, karşıt gereksinimleri uzlaştırmaktır: çeşitli ajanlardan (Fluentd, Prometheus, OpenTelemetry) saniyede milyarlarca olayı alırken, exabaytlarca tarihsel veriye yönelik etkileşimli sorgu performansı sağlamaktır. Geleneksel paylaşımsız veritabanları, kiracılar arası sorgu gürültüsü altında çöküyor, kiracı bazında silolar ise yönetimsel maliyetleri artırıyor. Katı izolasyon, A kiracısının sorgularının B kiracısının verilerini fiziksel olarak tarayamamasını gerektirse de, satır düzeyinde güvenlik filtreleri genellikle performans kayıplarına neden oluyor. Ayrıca, tüm verilerin sıcak SSD üzerinde depolanması ekonomik olarak mümkün değildir, ancak soğuk verilerin Amazon S3 Glacier'a taşınması, arşivlenmiş veriler aniden sorgulandığında alt saniye SLA'sını ihlal etme riski taşır. Parti ve şema evrimini izleyen katalog hizmeti merkezi olmamalı ve yükselen veri akışı sırasında tekil bir arıza noktası veya üst sınır darboğazı haline gelmemelidir.
Amazon S3, Azure Data Lake Storage veya Google Cloud Storage üzerinde oturan Apache Iceberg tablonun formatı olarak kullanılarak katmanlı bir lakehouse mimarisi tasarlayın. Apache Kafka veya Amazon Kinesis aracılığıyla akışları alın, verileri uygun katmana yerleştirmek için Apache Flink veya Spark Streaming ile işleyin: sıcak (sorgu düğümlerinde yerel NVMe SSD), ılık (S3 Standart) veya soğuk (S3 Glacier Instant Retrieval). Trino veya Presto'yu dağıtık sorgu motoru olarak dağıtın ve A kiracısının sınırlarını tanımlayan satır düzeyinde ve sütun düzeyinde güvenlik politikaları için Apache Ranger veya AWS Lake Formation ile yapılandırın. Merkezi darboğazlardan kaçınmak için Hive Metastore federasyonu veya bölgesel kopyalar ile federasyona dayalı bir katalog uygulayın. Otomatik katmanlama, sorgu günlüklerini izleyen bir ML tabanlı ısı haritası analizörü tarafından yönlendirilir ve sık erişilen soğuk verileri ılımlı depolamaya terfi ettirirken, duraklamış sıcak verileri aşağıya çeker ve katmanlar arasında sorgu şeffaflığını sağlamak için Iceberg üzerinde meta veri işaretçilerini korur.
Detaylı örnek:
12,000 kurumsal müşteriye hizmet veren NebulaObservability, 8PB depolamada aylık 2M$ maliyet gerektiren eski Elasticsearch kümesini değiştirmek zorunda kaldı. Her müşteri günde 2-10TB günlük ve metrik üretiyor, bu da alt saniye gösterge panosu yükleme süreleri ile anlık SQL analiz gerektiriyor. Düzenleyici gereklilikler, Müşteri A'nın Müşteri B'nin veri varlığını zamanlama saldırıları veya sorgu hataları ile anlamamasını gerektiriyor. Veri saklama, 13 ay ile sınırlı, ancak sorguların %95'i yalnızca son 72 saati vuruyor. Önceki mimari, bir müşterinin büyük agregasyon sorgusunun diğerlerinin performansını düşürmesi gibi "gürültülü komşu" sorunlarıyla karşılaştı.
Çözüm 1: Bölümlenmiş ClickHouse Kümeleri
Kiracı bazında parçalanmış büyük ClickHouse kümeleri dağıtmanın düşünüldü. Artıları arasında mükemmel tek sorgu performansı ve olgun SQL desteği ile vektörlü yürütme vardır. Ancak, eksileri oldukça ciddiydi: petabayt ölçeğindeki kümeleri yönetmenin operasyonel karmaşıklığı, performans düşüşü olmadan satır düzeyinde güvenliğin uygulanmasının zorluğu ve depolama ile hesaplamayı bağımsız olarak ölçeklendirmenin imkansızlığı. Ayrıca, kiracı katılımları sırasında ClickHouse kümelerini yeniden parçalara ayırmak, saatlerce kesinti ve manuel müdahale gerektiriyordu.
Çözüm 2: Kiracı Bazında PostgreSQL ile TimescaleDB
Her kiracı için yalıtılmış PostgreSQL örnekleri ve TimescaleDB genişletmeleri sağlamak mükemmel güvenlik izolasyonu ve basit yedekleme stratejileri sundu. Artıları açıktır: yerel satır düzeyinde güvenlik, GDPR için kolay kiracı silme ve kiracılar arası müdahalede bulunmama. Ancak, eksileri bu yaklaşımı imkansız hale getirdi: 12,000 veritabanı örneği yönetmenin operasyonel kabusu, yaman sınıfları ve bağlantı havuzunun tükenmesi. Sütunlu formatlarla karşılaştırıldığında sıkıştırma eksikliği nedeniyle depolama maliyetleri patlayacak ve sağlayıcının kendi kullanım içgörüleri için kiracı bazında analiz yapmak imkansız hale gelecekti.
Çözüm 3: Federated Lakehouse ile Katmanlı Depolama
Trino ve otomatik katmanlama ile Apache Iceberg tabanlı lakehouse uygulamak, optimal dengeyi sağladı. Artılar arasında paylaşımlı altyapı ölçek ekonomileri, kullanıcılardan gelen hataları önleyen Iceberg'in gizli parçalanması ve S3'ün sonsuz ölçeklenebilirliği vardı. Apache Ranger aracılığıyla satır düzeyinde güvenlik, sorguları değiştirmeden ince ayar politikalarına izin verdi. Otomatik katmanlama, soğuk verileri S3 Glacier'a taşıyarak depolama maliyetlerini %70 oranında azaltırken, meta verileri sıcak tutmayı sağladı. Eksiler, önemli bir ayarlama karmaşıklığı içeriyordu: sorgu planlama, dikkatli parça kırpma gerektiriyordu ve katmanlama algoritmasının yanlış tahminlerden kaçınmak için eğitim verisine ihtiyacı vardı.
Seçilen çözüm ve neden:
Çözüm 3, gezegen ölçeği gereğini karşılarken katı izolasyonu sürdürebildiği için seçildi. Iceberg formatının tablo meta verilerini atomik olarak güncelleyebilme yeteneği, kilitlenme olmadan şema evrimini sağladı, bu da sıfır kesinti gerektiren dağıtımlar için kritik öneme sahipti. Trino'nun bağlayıcı mimarisi, yüklenmiş kalıpları S3'e indirmeyi mümkün kıldı ve taranan verileri azalttı. AWS Lambda fonksiyonları ile tetiklenen otomatik indikleme, manuel müdahaleye ihtiyaç duymadan maliyet optimizasyonunu sağladı. Bu yaklaşım, depolamayı hesaplamadan ayırarak trafik zirveleri sırasında bağımsız ölçeklenmeyi sağladı.
Sonuç:
Sistem, 12PB aktif veri üzerinde 650ms p99 sorgu gecikmesi sağladı, zirve saatlerinde 50,000 eşzamanlı sorguyu destekledi. Depolama maliyetleri, önceki Elasticsearch mimarisine kıyasla %68 düştü ve aylık 1.36M$ tasarruf sağlandı. Otomatik indikleme, veri erişim desenlerinin %94'ünü doğru bir şekilde tahmin etti, soğuk depolama için "önbellek kayıpları" sadece %0.3 oranında meydana geldi. İlk 18 aylık operasyon süresince, kiracılar arası veri sızıntısıyla ilgili sıfır güvenlik olayı kaydedildi, üç ayda bir yapılan sızma testleri ile doğrulandı. Yeni bir kiracının katılımı, 30 saniyeden daha kısa sürede sadece meta veri işlemi gerektiriyordu.
Otomatik katmanlama algoritması yanlışlıkla "ılık" verileri düşürdüğünde sorgu gecikmesi patlamalarını nasıl önlersiniz?
Adaylar sıklıkla öngörücü bir katmanlama sistemini, sorgu erişim günlüklerinde üstel düzeltme kullanarak, vélodromdan soğuk veriyi araştırma yerine tekrar ılık katmana kopyalamanız gerektiğini düşünmeden, reaktif önbellekleme öneriyor. Ek olarak, Trino ile S3 arasında dağıtılmış bir önbellek katmanı olarak Alluxio dağıtmak, beklenmeyen erişim zirvelerini karşılar. Kritik ayrıntı, "okuma sırasında terfi" uygulamaktır: soğuk veriler erişildiğinde, sistem asenkron olarak şu anda S3 Glacier Instant Retrieval'dan hizmet vererek ılık katmana kopyalar.
Şemalar arasında binlerce kiracı tablosunda sütun eklerken ACID tutarlılığını nasıl koruyorsunuz?
Çoğu aday, merkezi aksamaların gerekliliğini ihlal eden dağıtılmış kilit öneriyor. Doğru yaklaşım, Apache Iceberg'in iyimser eşzamanlı kontrol ve meta veri katmanlama özelliklerini kullanmaktır. Her kiracı tablosunun bağımsız bir meta veri.json dosya soyu vardır. Şemadaki değişiklikler, artan bir sıra numarasına sahip yeni bir meta veri dosyası ekler; katalog (örneğin, AWS Glue) yalnızca mevcut meta veri dosyasına işaret eden bir göstergenin saklar. Taahhüt sırasında, yazar, işaretçinin değişip değişmediğini kontrol eder (çelişki) ve gerektiğinde yeniden dener. Bu, küresel kilitlerin gereksinimini ortadan kaldırır çünkü kiracı tablosu bağımsız ad alanlarıdır. Nadir kiracılar arası şemalardaki güncellemeler için (örneğin, evrensel bir sütun eklemek) idempotent DDL işlemleri içeren bir saga modeli kullanın.
"Süper kiracı"'nın tüm tablo taraması yapmasını, diğer kiracıların CPU kaynaklarını aç bırakmasını önlemek için satır düzeyindeki güvenlik katmanını nasıl tasarlarsınız?
Adaylar sıkça kaynak yönetim mekanizmalarını gözden kaçırır. Çözüm, kiracı sınıfı başına sert CPU sınırlamaları ve bellek kotası ile Trino'nun kaynak gruplarını kullanarak hiyerarşik kaynak izolasyonu gerektirir. Sorgu maliyetlerini tahmin eden bir kabul kontrolü uygulayın; kiracı özel eşiklerini aşan sorgular, yürütülmek yerine sıraya alınır veya reddedilir. Kubernetes kaynak kotalarını kullanarak sorgu motoru düğümlerini kiracı bazında düğüm havuzlarına ayırın, bu diğer kiracıların gecikmesini önler. Son olarak, tahmin edilen maliyetleri aşan uzun süreli tarama sorguları için öldürme politikaları uygulayın, yaygın maliyetli toplama işlemleri için malzeme görünümlerine ek olarak, böylece kötü niyetli veya kazara yapılan tam taramaların diğer kiracıların gecikmesini etkilemesine izin verilmez.