- Son 3 yılda Notion'ın verisi, kullanıcı ve içerik artışı nedeniyle 10 kat büyüdü ve her 6-12 ayda bir 2 katına çıktı
- Notion AI özellikleri başta olmak üzere önemli ürünler ve analitik kullanım senaryolarının veri gereksinimlerini karşılarken, bu hızlı büyümeyi yönetmek için Notion veri gölü kuruldu ve ölçeklendirildi
Notion'ın veri modeli ve büyümesi
- Notion'da görülen her şey, Postgres veritabanında tutarlı bir yapı, şema ve ilişkili meta verilerle saklanan bir "block" varlığı olarak modellenir
- Bu block verisi her 6-12 ayda bir 2 katına çıktı; 2021 başında 20 milyardan fazla block satırı varken bugün 200 milyardan fazla block bulunuyor
2021'de Notion'ın veri ambarı mimarisi
- Özel veri altyapısına, Postgres WAL'den Snowflake'e veri alan Fivetran tabanlı basit bir ELT pipeline'ı ile başlandı
- 480 ham Snowflake tablosuna yazmak için 480 shard üzerinde saatlik çalışan 480 connector kuruldu ve bu tablolar analiz, raporlama ve makine öğrenimi kullanım senaryoları için tek büyük tabloda birleştirildi
Ölçekleme sırasındaki zorluklar
- Postgres verisi büyüdükçe çeşitli sorunlarla karşılaşıldı
- Operasyonel yönetilebilirlik: 480 Fivetran connector'ünü izleme ve yönetme yükü çok yükseldi
- Hız, veri tazeliği ve maliyet: Notion'ın kendine özgü güncelleme ağırlıklı iş yükü, verinin Snowflake'e alınmasını yavaşlattı ve maliyeti artırdı
- Kullanım senaryosu desteği: Veri dönüşüm mantığı daha karmaşık ve ağır hale gelerek, standart veri ambarlarının sunduğu standart SQL arayüzünün sınırlarını aştı
Notion'ın kurum içi veri gölünü kurmak ve ölçeklendirmek
- İç veri gölünün hedefleri
- Ham ve işlenmiş veriyi büyük ölçekte depolayabilecek bir veri deposu oluşturmak
- Özellikle Notion'ın güncelleme ağırlıklı block verisi için, tüm iş yüklerinde hızlı, ölçeklenebilir, yönetilebilir ve maliyet etkin veri alımı ile hesaplama sağlamak
- Yapay zeka, arama ve denormalize veri gerektiren diğer ürünler için kullanım senaryolarını desteklemek
- Amaç, Snowflake ve Fivetran'ın tamamen yerini almak ya da çok sıkı gecikme gerektiren çevrim içi kullanım senaryolarını desteklemek değildi
Veri gölünün üst düzey tasarımı
- Postgres'ten Kafka'ya artımlı güncellenmiş veri almak için Debezium CDC connector'leri kullanıldı, ardından Apache Hudi ile bu güncellemeler Kafka'dan S3'e yazıldı
- Bu ham veri kullanılarak dönüşüm, denormalizasyon ve zenginleştirme yapıldı; ardından işlenmiş veri, analiz ve raporlama gereksinimleri ile yapay zeka, arama ve diğer ürün ihtiyaçlarını karşılamak üzere yeniden S3'e veya aşağı akış sistemlerine kaydedildi
Tasarım kararları
- Veri deposu ve göl seçimi: Tüm ham ve işlenmiş veriyi saklamak için veri deposu ve veri gölü olarak S3 seçildi; veri ambarı ve diğer ürün odaklı veri depoları ise aşağı akışta konumlandırıldı
- İşleme motoru seçimi: Ana veri işleme motoru olarak açık kaynaklı framework Spark seçildi
- Snapshot dump yerine artımlı alımı tercih etme: Normal çalışma sırasında değişen Postgres verisi artımlı olarak alınarak sürekli S3'e uygulandı; nadir durumlarda ise tabloları S3'te bootstrap etmek için Postgres'in tam snapshot'ı bir kez oluşturuldu
- Artımlı alımı basitleştirme: Artımlı değişen Postgres verisini Kafka'ya yayımlamak için Kafka Debezium CDC connector'leri kullanıldı, Kafka'dan S3'e artımlı veri almak için ise Hudi kullanıldı
- İşlemeden önce ham veri alımı: Tek bir doğruluk kaynağı oluşturmak ve tüm veri pipeline'ında debugging'i basitleştirmek için, anlık işleme yapılmadan ham Postgres verisi S3'e alındı
Veri gölünü ölçeklendirme ve işletme
- CDC connector ve Kafka kurulumu: Postgres host başına bir Debezium CDC connector'ü yapılandırıldı ve AWS EKS cluster'ına dağıtıldı
- Hudi kurulumu: Apache Hudi Deltastreamer kullanılarak Kafka mesajları tüketildi ve S3 üzerinde Postgres tablolarının durumu kopyalandı
- Spark veri işleme kurulumu: Veri işleme görevlerinin çoğunda PySpark kullanıldı; ağaç dolaşımı ve denormalizasyon gibi daha karmaşık işler için Spark'ın güçlü performansından yararlanıldı
- Bootstrap kurulumu: Debezium Connector, Postgres değişikliklerini Kafka'ya almak üzere yapılandırıldı; AWS RDS'nin S3'e export işlevi kullanılarak Postgres tablolarının en güncel snapshot'ı S3'e kaydedildi; ardından S3'ten bu veriyi okuyup Hudi tablo formatında yazan Spark işleri oluşturuldu
Sonuçlar
- Veri gölü altyapısının geliştirilmesine 2022 ilkbaharında başlandı ve aynı yılın sonbaharında tamamlandı
- 2022'de 1 milyon doların üzerinde net tasarruf sağlandı; 2023 ve 2024'te ise orantılı olarak daha yüksek tasarruf elde edildi
- Postgres'ten S3 ve Snowflake'e uçtan uca alım süresi, bir günden fazla süreden küçük tablolar için birkaç dakikaya, büyük tablolar içinse en fazla birkaç saate indirildi
- Veri gölü sayesinde 2023 ve 2024'te Notion AI özellikleri başarıyla kullanıma sunuldu
2 yorum
Acaba yukarıdaki içerikle ilgili dokümanları ya da başvurulan kaynakları paylaşmanız mümkün mü?
Ben yanlış yazmışım hahaha
Buldum~~~