oranında yeni bir akışın başlatılması beklentisiyle İlginç materyallerin bir çevirisini hazırladık.
Gözden
Uygulamaların birden fazla veri deposu kullandığı, her mağazanın kendi amaçları için kullanıldığı, örneğin kanonik veri biçimini (MySQL vb.) depolamak, gelişmiş arama yetenekleri sağlamak (ElasticSearch, vb.) .), önbelleğe alma (Memcached vb.) ve diğerleri. Tipik olarak birden fazla veri deposu kullanıldığında bunlardan biri birincil depo, diğerleri ise türev depo görevi görür. Tek sorun bu veri depolarının nasıl senkronize edileceğidir.
Çift yazma, dağıtılmış işlemler vb. gibi birden fazla mağazayı senkronize etme sorununu çözmeye çalışan bir dizi farklı modele baktık. Ancak bu yaklaşımların gerçek hayatta kullanım, güvenilirlik ve bakım açısından önemli sınırlamaları vardır. Veri senkronizasyonunun yanı sıra bazı uygulamaların harici hizmetleri çağırarak verileri zenginleştirmesi de gerekir.
Delta bu sorunları çözmek için geliştirildi. Delta sonuçta veri senkronizasyonu ve zenginleştirme için tutarlı, olay odaklı bir platform sağlar.
Mevcut çözümler
çift giriş
İki veri deposunu senkronize tutmak için, bir depoya yazan ve hemen ardından diğerine yazan ikili yazmayı kullanabilirsiniz. İlk kayıt yeniden denenebilir ve deneme sayısı tükendikten sonra ilki başarısız olursa ikincisi iptal edilebilir. Ancak ikinci depoya yazma işlemi başarısız olursa iki veri deposunun senkronizasyonu bozulabilir. Bu sorun genellikle, verileri periyodik olarak birinci depolama biriminden ikinci depolama birimine yeniden aktarabilen veya yalnızca verilerde farklılıklar tespit edildiğinde bunu gerçekleştirebilen bir kurtarma prosedürü oluşturularak çözülür.
Sorunları:
Kurtarma prosedürünün gerçekleştirilmesi, yeniden kullanılamayan belirli bir iştir. Ayrıca, depolama konumları arasındaki veriler, geri yükleme prosedürü gerçekleşene kadar senkronizasyon dışı kalır. İkiden fazla veri deposunun kullanılması durumunda çözüm daha karmaşık hale gelir. Son olarak, geri yükleme prosedürü orijinal veri kaynağına yük ekleyebilir.
Günlük tablosunu değiştir
Bir tablo kümesinde değişiklik meydana geldiğinde (bir kaydın eklenmesi, güncellenmesi ve silinmesi gibi), değişiklik kayıtları aynı işlemin parçası olarak günlük tablosuna eklenir. Başka bir iş parçacığı veya süreç sürekli olarak günlük tablosundan olay ister ve bunları bir veya daha fazla veri deposuna yazar, gerekirse kayıt tüm depolar tarafından onaylandıktan sonra olayları günlük tablosundan kaldırır.
Sorunları:
Bu model bir kütüphane olarak ve ideal olarak onu kullanan uygulamanın kodunu değiştirmeden uygulanmalıdır. Çok dilli bir ortamda, böyle bir kütüphanenin uygulanmasının gerekli herhangi bir dilde mevcut olması gerekir, ancak diller arasında işlevsellik ve davranış tutarlılığını sağlamak çok zordur.
Diğer bir sorun ise MySQL gibi işlemsel şema değişikliklerini [1] [2] desteklemeyen sistemlerde şema değişikliklerinin elde edilmesinde yatmaktadır. Bu nedenle, değişiklik yapma (örneğin şema değişikliği) ve bunu değişiklik günlüğü tablosuna işlemsel olarak kaydetme modeli her zaman işe yaramayacaktır.
Dağıtılmış İşlemler
Dağıtılmış işlemler, bir işlemi birden fazla heterojen veri deposuna bölmek için kullanılabilir; böylece işlem, kullanılan tüm veri depolarına bağlanır veya bunlardan hiçbirine bağlanmaz.
Sorunları:
Dağıtılmış işlemler, heterojen veri depoları için çok büyük bir sorundur. Doğaları gereği, ilgili sistemlerin yalnızca en düşük ortak paydasına güvenebilirler. Örneğin, XA işlemleri, başvuru sürecinin hazırlık aşamasında başarısız olması durumunda yürütmeyi engeller. Ek olarak XA, kilitlenme tespiti sağlamaz veya iyimser eşzamanlılık kontrol şemalarını desteklemez. Ayrıca ElasticSearch gibi bazı sistemler XA'yı veya başka herhangi bir heterojen işlem modelini desteklemez. Bu nedenle, çeşitli veri depolama teknolojilerinde yazma atomikliğinin sağlanması uygulamalar için oldukça zorlu bir görev olmaya devam etmektedir [3].
Delta
Delta, mevcut veri senkronizasyon çözümlerinin sınırlamalarını gidermek üzere tasarlanmıştır ve aynı zamanda anında veri zenginleştirmesine olanak tanır. Amacımız, uygulama geliştiricilerin tüm bu karmaşıklıkları soyutlayarak iş işlevlerini uygulamaya tamamen odaklanabilmelerini sağlamaktı. Daha sonra Netflix Delta'nın gerçek kullanım durumu olan "Film Arama"yı açıklayacağız.
Netflix yaygın olarak bir mikro hizmet mimarisi kullanır ve her mikro hizmet genellikle bir tür veriye hizmet eder. Filmle ilgili temel bilgiler, Film Hizmeti adı verilen bir mikro hizmette bulunur ve yapımcılar, aktörler, satıcılar vb. hakkındaki bilgiler gibi ilgili veriler diğer bazı mikro hizmetler (yani Fırsat Hizmeti, Yetenek Hizmeti ve Satıcı Hizmeti) tarafından yönetilir.
Netflix Stüdyolarındaki iş kullanıcılarının sıklıkla çeşitli film kriterlerine göre arama yapması gerekir; bu nedenle filmle ilgili tüm verilerde arama yapabilmek onlar için çok önemlidir.
Delta'dan önce, film arama ekibinin, film verilerini dizine eklemeden önce birden fazla mikro hizmetten veri alması gerekiyordu. Ayrıca ekibin, hiçbir değişiklik olmasa bile diğer mikro hizmetlerden değişiklik talep ederek arama dizinini periyodik olarak güncelleyecek bir sistem geliştirmesi gerekiyordu. Bu sistem hızla karmaşık ve bakımı zor hale geldi.
Şekil 1. Delta'ya oylama sistemi
Delta kullanıldıktan sonra sistem, aşağıdaki şekilde gösterildiği gibi olay odaklı bir sisteme basitleştirildi. CDC (Değişim-Veri-Yakalama) olayları Delta-Connector kullanılarak Keystone Kafka konularına gönderilir. Delta Stream Processing Framework (Flink'e dayalı) kullanılarak oluşturulan bir Delta uygulaması, bir konudan CDC olaylarını alır, diğer mikro hizmetleri çağırarak bunları zenginleştirir ve son olarak zenginleştirilmiş verileri Elasticsearch'teki bir arama dizinine aktarır. Tüm süreç neredeyse gerçek zamanlı olarak gerçekleşir; yani, veri ambarına değişiklikler aktarıldığı anda arama dizinleri güncellenir.
Şekil 2. Delta kullanan veri hattı
İlerleyen bölümlerde, CDC olaylarını Kafka konularına yönlendiren gerçek zamanlı veri iletim altyapısı olan, depolamaya bağlanan ve CDC olaylarını taşıma katmanına yayınlayan Delta-Connector'ın çalışmasını anlatacağız. Ve en sonunda uygulama geliştiricilerin veri işleme ve zenginleştirme mantığı için kullanabileceği Delta akış işleme çerçevesinden bahsedeceğiz.
CDC (Değişiklik-Veri-Yakalama)
Veri deposundan yapılan değişiklikleri gerçek zamanlı olarak yakalayabilen ve bunları bir akışa yazabilen Delta-Connector adında bir CDC hizmeti geliştirdik. Gerçek zamanlı değişiklikler işlem günlüğünden ve depolama dökümlerinden alınır. Dökümler kullanılır çünkü işlem günlükleri genellikle değişiklik geçmişinin tamamını saklamaz. Değişiklikler genellikle Delta olayları olarak serileştirilir, böylece alıcının değişikliğin nereden geldiği konusunda endişelenmesine gerek kalmaz.
Delta-Connector aşağıdakiler gibi çeşitli ek özellikleri destekler:
- Kafka'dan sonra özel çıktı verileri yazabilme.
- Tüm tablolar, belirli bir tablo veya belirli birincil anahtarlar için manuel dökümleri istediğiniz zaman etkinleştirme yeteneği.
- Dökümler parçalar halinde alınabilir, dolayısıyla başarısızlık durumunda yeniden başlamaya gerek kalmaz.
- Tablolara kilit yerleştirmeye gerek yoktur; bu, veritabanı yazma trafiğinin hizmetimiz tarafından hiçbir zaman engellenmemesini sağlamak için çok önemlidir.
- AWS Erişilebilirlik Alanlarındaki yedek bulut sunucuları nedeniyle yüksek kullanılabilirlik.
Şu anda AWS RDS ve Aurora'daki dağıtımlar da dahil olmak üzere MySQL ve Postgres'i destekliyoruz. Ayrıca Cassandra'yı (çoklu yönetici) de destekliyoruz. Delta-Connector hakkında daha fazla ayrıntıyı burada bulabilirsiniz .
Kafka ve taşıma katmanı
Delta'nın olay taşıma katmanı, platformun mesajlaşma hizmeti üzerine kurulmuştur .
Geçmişte, Netflix'te içerik yayınlamak uzun ömürlülükten ziyade erişilebilirlik açısından optimize edilmiştir (aşağıya bakınız). ). Takas, çeşitli uç senaryolarda potansiyel komisyoncu veri tutarsızlığıydı. Örneğin, kirli lider seçimi alıcının potansiyel olarak yinelenen veya kaybolan olaylara sahip olmasından sorumludur.
Delta ile CDC etkinliklerinin türev mağazalara teslim edilmesini sağlamak için daha güçlü dayanıklılık garantileri istedik. Bu amaçla birinci sınıf bir nesne olarak özel olarak tasarlanmış bir Kafka kümesi önerdik. Aşağıdaki tabloda bazı komisyoncu ayarlarına bakabilirsiniz:
Keystone Kafka kümelerinde, kirli lider seçimi genellikle yayıncının erişilebilirliğini sağlamak için dahil edilir. Bu, senkronize edilmemiş bir kopyanın lider olarak seçilmesi durumunda ileti kaybına neden olabilir. Yeni bir yüksek kullanılabilirlik Kafka kümesi için seçenek kirli lider seçimi mesaj kaybını önlemek için kapatıldı.
Biz de arttırdık replikasyon faktörü 2'den 3'e ve minimum senkronize olmayan kopyalar 1'den 2'ye. Bu kümeye yazan yayıncılar, diğerlerinin tümünden onay talep eder ve 2 kopyadan 3'sinin, yayıncı tarafından gönderilen en güncel iletilere sahip olmasını sağlar.
Bir aracı örneği sona erdiğinde, yeni bir örnek eskisinin yerini alır. Ancak yeni aracının senkronize edilmemiş kopyalara yetişmesi gerekecek ve bu işlem birkaç saat sürebilir. Bu senaryoda kurtarma süresini azaltmak için yerel aracı diskler yerine blok veri depolamayı (Amazon Elastic Block Store) kullanmaya başladık. Yeni bir örnek, sonlandırılan bir aracı örneğinin yerini aldığında, sonlandırılan örneğin sahip olduğu EBS birimini ekler ve yeni mesajları yakalamaya başlar. Bu işlem, yeni örneğin artık boş bir durumdan çoğaltılmasına gerek kalmadığından biriktirme listesi temizleme süresini saatlerden dakikalara indirir. Genel olarak, ayrı depolama ve aracı yaşam döngüleri, aracı değiştirmenin etkisini önemli ölçüde azaltır.
Veri dağıtım garantisini daha da artırmak için şunları kullandık: aşırı koşullar altında herhangi bir mesaj kaybını tespit etmek için (örneğin, bölüm liderindeki saat senkronizasyonunun bozulması).
Akış İşleme Çerçevesi
Delta'nın işlem katmanı, Apache Flink'in Netflix ekosistemiyle entegrasyonunu sağlayan Netflix SPAaS platformunun üzerine inşa edilmiştir. Platform, Titus konteyner yönetimi platformumuzun üzerinde Flink işlerinin dağıtımını ve Flink kümelerinin orkestrasyonunu yöneten bir kullanıcı arayüzü sağlar. Arayüz ayrıca iş yapılandırmalarını yönetir ve kullanıcıların Flink işlerini yeniden derlemeye gerek kalmadan dinamik olarak yapılandırma değişiklikleri yapmasına olanak tanır.
Delta, Flink ve SPAaS tabanlı bir akış işleme çerçevesi sağlar. ek açıklama tabanlı Soyut teknik ayrıntılar için DSL (Etki Alanına Özel Dil). Örneğin, harici servislerin çağrılmasıyla olayların zenginleştirileceği adımı tanımlamak için kullanıcıların aşağıdaki DSL'yi yazması gerekir ve çerçeve, buna dayalı olarak Flink tarafından yürütülecek bir model oluşturacaktır.
Şekil 3. Delta'da DSL zenginleştirme örneği
İşleme çerçevesi yalnızca öğrenme eğrisini azaltmakla kalmaz, aynı zamanda ortak operasyonel sorunları çözmek için veri tekilleştirme, şemalaştırma ve esneklik ve dayanıklılık gibi ortak akış işleme özellikleri de sağlar.
Delta Stream Processing Framework iki temel modülden oluşur: DSL ve API modülü ve Çalışma Zamanı modülü. DSL ve API modülü, kullanıcıların kendi işleme mantığını (filtreleme veya dönüştürme gibi) yazabilmesi için DSL ve UDF (Kullanıcı Tanımlı İşlev) API'leri sağlar. Çalışma Zamanı modülü, DAG modellerindeki işleme adımlarının dahili temsilini oluşturan bir DSL ayrıştırıcının uygulanmasını sağlar. Yürütme bileşeni, gerçek Flink ifadelerini başlatmak ve sonuçta Flink uygulamasını çalıştırmak için DAG modellerini yorumlar. Çerçevenin mimarisi aşağıdaki şekilde gösterilmektedir.
Şekil 4. Delta Stream Processing Framework mimarisi
Bu yaklaşımın çeşitli avantajları vardır:
- Kullanıcılar, Flink'in veya SPAaS yapısının ayrıntılarına girmeden kendi iş mantıklarına odaklanabilirler.
- Optimizasyon kullanıcılara şeffaf bir şekilde yapılabiliyor ve kullanıcı kodunda (UDF) herhangi bir değişiklik yapılmasına gerek kalmadan hatalar düzeltilebiliyor.
- Delta uygulama deneyimi, kullanıcılar için basitleştirilmiştir çünkü platform, kutudan çıktığı haliyle esneklik ve esneklik sağlar ve uyarılar için kullanılabilecek çeşitli ayrıntılı ölçümleri toplar.
Üretim kullanımı
Delta bir yılı aşkın süredir yapım aşamasında ve birçok Netflix Studio uygulamasında önemli bir rol oynuyor. Ekiplerin arama dizini oluşturma, veri depolama ve olay odaklı iş akışları gibi kullanım senaryolarını uygulamalarına yardımcı oldu. Aşağıda Delta platformunun üst düzey mimarisine genel bir bakış yer almaktadır.
Şekil 5. Delta'nın üst düzey mimarisi.
Teşekkür
Netflix'te Delta'nın oluşturulmasında ve geliştirilmesinde emeği geçen şu kişilere teşekkür ederiz: Allen Wang, Charles Zhao, Jaebin Yoon, Josh Snyder, Kasturi Chatterjee, Mark Cho, Olof Johansson, Piyush Goyal, Prashanth Ramdas, Raghuram Onti Srinivasan, Sandeep Gupta, Steven Wu, Tharanga Gamaethige, Yun Wang ve Zhenzhong Xu.
kaynaklar
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Çevrimiçi etkinlik işleme. İletişim ACM 62(5): 43–49 (2019). DOI:
: “Amazon Redshift Storage için Veri Oluşturma Aracı.”
Kaynak: habr.com