Məzənnə ilə yeni axının başlanması ərəfəsində Maraqlı materialın tərcüməsini hazırlamışıq.
Review
Tətbiqlərin hər bir mağazanın öz məqsədləri üçün istifadə edildiyi, məsələn, məlumatların kanonik formasını (MySQL və s.) saxlamaq, təkmil axtarış imkanlarını təmin etmək (ElasticSearch, s.) .), keşləmə (Memcached və s.) və s. Tipik olaraq, bir neçə məlumat anbarından istifadə edərkən onlardan biri əsas, digərləri isə törəmə anbar kimi çıxış edir. Yeganə problem bu məlumat anbarlarını necə sinxronlaşdırmaqdır.
İkiqat yazılar, paylanmış əməliyyatlar və s. kimi birdən çox mağazanın sinxronlaşdırılması problemini həll etməyə çalışan bir sıra fərqli nümunələrə baxdıq. Bununla belə, bu yanaşmalar real həyatda istifadə, etibarlılıq və texniki xidmət baxımından əhəmiyyətli məhdudiyyətlərə malikdir. Məlumatların sinxronizasiyası ilə yanaşı, bəzi proqramlar da xarici xidmətlərə zəng etməklə məlumatları zənginləşdirməli olur.
Delta bu problemləri həll etmək üçün hazırlanmışdır. Delta son nəticədə məlumatların sinxronizasiyası və zənginləşdirilməsi üçün ardıcıl, hadisələrə əsaslanan platforma təmin edir.
Mövcud həllər
İkiqat giriş
İki məlumat anbarını sinxronlaşdırmaq üçün siz bir mağazaya yazılan və dərhal sonra digərinə yazan ikili yazmadan istifadə edə bilərsiniz. Cəhdlərin sayı tükəndikdən sonra birincisi uğursuz olarsa, birinci qeyd təkrar sınana bilər, ikincisi isə dayandırıla bilər. Bununla belə, ikinci mağazaya yazmaq uğursuz olarsa, iki məlumat anbarı sinxronizasiya oluna bilər. Bu problem adətən məlumatları ilk yaddaşdan ikinciyə vaxtaşırı yenidən ötürə bilən bərpa proseduru yaratmaqla həll edilir və ya bunu yalnız məlumatlarda fərqlər aşkar edildikdə həyata keçirir.
Problemlər bunlardır:
Bərpa prosedurunun yerinə yetirilməsi təkrar istifadə edilə bilməyən xüsusi bir işdir. Bundan əlavə, bərpa proseduru baş verənə qədər saxlama yerləri arasında məlumatlar sinxronizasiya olunmur. İkidən çox məlumat anbarı istifadə edilərsə, həll daha mürəkkəb olur. Nəhayət, bərpa proseduru orijinal məlumat mənbəyinə yük əlavə edə bilər.
Giriş cədvəlini dəyişdirin
Cədvəllər dəstində dəyişikliklər baş verdikdə (məsələn, qeydin daxil edilməsi, yenilənməsi və silinməsi) dəyişiklik qeydləri eyni əməliyyatın bir hissəsi kimi jurnal cədvəlinə əlavə edilir. Başqa bir başlıq və ya proses, qeyd bütün mağazalar tərəfindən təsdiqləndikdən sonra, log cədvəlindən hadisələri davamlı olaraq tələb edir və onları bir və ya bir neçə məlumat anbarına yazır, lazım gələrsə, qeyd cədvəlindən hadisələri silir.
Problemlər bunlardır:
Bu nümunə kitabxana kimi və ideal olaraq ondan istifadə edən tətbiqin kodunu dəyişdirmədən həyata keçirilməlidir. Poliqlot mühitində belə bir kitabxananın tətbiqi istənilən zəruri dildə mövcud olmalıdır, lakin dillər arasında funksionallıq və davranışın ardıcıllığını təmin etmək çox çətindir.
Başqa bir problem, MySQL kimi tranzaksiya sxem dəyişikliklərini [1][2] dəstəkləməyən sistemlərdə sxem dəyişikliklərinin əldə edilməsindədir. Buna görə də, dəyişiklik etmək (məsələn, sxem dəyişikliyi) və onu dəyişiklik jurnalı cədvəlində əməliyyat olaraq qeyd etmək nümunəsi həmişə işləməyəcəkdir.
Paylanmış Əməliyyatlar
Paylanmış əməliyyatlar əməliyyatı çoxlu heterojen məlumat anbarları arasında bölmək üçün istifadə edilə bilər ki, əməliyyat ya istifadə olunan bütün məlumat anbarlarına uyğun olsun, ya da heç birinə bağlı olmasın.
Problemlər bunlardır:
Paylanmış əməliyyatlar heterojen məlumat anbarları üçün çox böyük problemdir. Təbiətlərinə görə, onlar yalnız iştirak edən sistemlərin ən aşağı ortaq məxrəcinə etibar edə bilərlər. Məsələn, hazırlıq mərhələsində ərizə prosesi uğursuz olarsa, XA əməliyyatları icranı bloklayır. Bundan əlavə, XA çıxılmaz vəziyyətin aşkarlanmasını təmin etmir və ya optimist paralellik nəzarəti sxemlərini dəstəkləmir. Bundan əlavə, ElasticSearch kimi bəzi sistemlər XA və ya hər hansı digər heterojen əməliyyat modelini dəstəkləmir. Beləliklə, müxtəlif məlumat saxlama texnologiyalarında yazma atomluğunun təmin edilməsi tətbiqlər üçün çox çətin bir vəzifə olaraq qalır [3].
Delta
Delta mövcud verilənlərin sinxronizasiya həllərinin məhdudiyyətlərini aradan qaldırmaq üçün nəzərdə tutulmuşdur və həmçinin məlumatların anında zənginləşdirilməsinə imkan verir. Məqsədimiz bütün bu mürəkkəblikləri proqram tərtibatçılarından uzaqlaşdırmaqdan ibarət idi ki, onlar bütün diqqətlərini biznes funksionallığının həyata keçirilməsinə yönəldə bilsinlər. Sonra Netflix-in Deltası üçün faktiki istifadə halı olan "Film Axtarışı"nı təsvir edəcəyik.
Netflix geniş şəkildə mikroservis arxitekturasından istifadə edir və hər bir mikroservis adətən bir növ verilənlərə xidmət edir. Film haqqında əsas məlumat Movie Service adlı mikroservisdə yer alır və prodüserlər, aktyorlar, satıcılar və s. haqqında məlumat kimi əlaqəli məlumatlar bir neçə digər mikroservislər (məs, Deal Service, Talent Service və Vendor Service) tərəfindən idarə olunur.
Netflix Studios-da biznes istifadəçiləri tez-tez müxtəlif film meyarları üzrə axtarış aparmalıdırlar, buna görə də filmlə bağlı bütün məlumatlar arasında axtarış edə bilmələri çox vacibdir.
Delta-dan əvvəl film məlumatlarını indeksləşdirməzdən əvvəl film axtarış komandası çoxlu mikroservislərdən məlumat götürməli idi. Bundan əlavə, komanda heç bir dəyişiklik olmasa belə, digər mikroservislərdən dəyişikliklər tələb edərək, axtarış indeksini vaxtaşırı yeniləyəcək bir sistem hazırlamalı idi. Bu sistem tez bir zamanda mürəkkəbləşdi və onu saxlamaq çətin oldu.
Şəkil 1. Deltaya səsvermə sistemi
Delta istifadə etdikdən sonra sistem aşağıdakı şəkildə göstərildiyi kimi hadisəyə əsaslanan sistemə sadələşdirildi. CDC (Change-Data-Capture) hadisələri Delta-Connector istifadə edərək Keystone Kafka mövzularına göndərilir. Delta Stream Processing Framework (Flink əsasında) istifadə edərək qurulan Delta proqramı mövzudan CDC hadisələrini alır, digər mikroservislərə zəng etməklə onları zənginləşdirir və nəhayət zənginləşdirilmiş məlumatları Elasticsearch-də axtarış indeksinə ötürür. Bütün proses demək olar ki, real vaxt rejimində baş verir, yəni məlumat anbarında dəyişikliklər edilən kimi axtarış indeksləri yenilənir.
Şəkil 2. Delta istifadə edərək məlumat kəməri
Növbəti bölmələrdə biz yaddaşa qoşulan və CDC hadisələrini Kafka mövzularına yönləndirən real vaxt məlumat ötürmə infrastrukturu olan nəqliyyat qatına CDC hadisələrini dərc edən Delta-Connector-un işini təsvir edəcəyik. Və ən sonunda, proqram tərtibatçılarının məlumatların emalı və zənginləşdirilməsi məntiqi üçün istifadə edə biləcəyi Delta axın emal çərçivəsi haqqında danışacağıq.
CDC (Məlumatları Dəyişdirmə)
Biz Delta-Connector adlı CDC xidmətini inkişaf etdirmişik ki, o, real vaxt rejimində məlumat anbarından edilən dəyişiklikləri ələ keçirə və onları axına yaza bilər. Real vaxt dəyişiklikləri əməliyyat jurnalından və saxlama zibillərindən götürülür. Dumplar istifadə olunur, çünki əməliyyat qeydləri adətən dəyişikliklərin bütün tarixini saxlamır. Dəyişikliklər adətən Delta hadisələri kimi seriallaşdırılır, ona görə də alıcı dəyişikliyin haradan gəldiyi barədə narahat olmayacaq.
Delta-Connector bir neçə əlavə funksiyanı dəstəkləyir, məsələn:
- Kafkadan keçmiş fərdi çıxış məlumatlarını yazmaq imkanı.
- İstənilən vaxt bütün cədvəllər, xüsusi cədvəl və ya xüsusi əsas açarlar üçün əl ilə zibilləri aktivləşdirmək imkanı.
- Zibillər hissə-hissə götürülə bilər, buna görə də uğursuzluq halında hər şeyi yenidən başlamağa ehtiyac yoxdur.
- Cədvəllərə kilidlər qoymağa ehtiyac yoxdur, bu, verilənlər bazası yazma trafikinin heç vaxt xidmətimiz tərəfindən bloklanmamasını təmin etmək üçün çox vacibdir.
- AWS Əlçatımlılıq Zonalarında lazımsız nümunələrə görə yüksək əlçatanlıq.
Hazırda AWS RDS və Aurora-da yerləşdirmələr də daxil olmaqla, MySQL və Postgres-i dəstəkləyirik. Biz həmçinin Cassandra (multi-master) dəstəkləyirik. Delta-Connector haqqında ətraflı məlumatı burada tapa bilərsiniz .
Kafka və nəqliyyat təbəqəsi
Delta-nın hadisə daşıma təbəqəsi platformanın mesajlaşma xidmətində qurulub .
Tarixən Netflix-də yerləşdirmə uzunömürlülük üçün deyil, əlçatanlıq üçün optimallaşdırılıb (aşağıya bax). ). Mübadilə müxtəlif kənar ssenarilərdə potensial broker məlumatlarının uyğunsuzluğu idi. Misal üçün, murdar lider seçkisi alıcının dublikat və ya itirilmiş hadisələrə görə məsuliyyət daşıyır.
Delta ilə biz CDC hadisələrinin törəmə mağazalara çatdırılmasını təmin etmək üçün daha güclü dayanıqlılıq zəmanətləri istədik. Bu məqsədlə biz birinci dərəcəli obyekt kimi xüsusi hazırlanmış Kafka klasterini təklif etdik. Aşağıdakı cədvəldə bəzi broker parametrlərinə baxa bilərsiniz:
Keystone Kafka qruplarında, murdar lider seçkisi adətən naşirin əlçatanlığını təmin etmək üçün daxil edilir. Sinxronlaşdırılmamış replika lider seçilərsə, bu, mesajın itirilməsi ilə nəticələnə bilər. Yeni yüksək əlçatanlıq Kafka klasteri üçün seçim murdar lider seçkisi mesaj itkisinin qarşısını almaq üçün söndürüldü.
Biz də artdıq replikasiya faktoru 2-dən 3-ə qədər və minimum insync replikaları 1-dən 2-ə qədər. Bu klasterə yazan naşirlər bütün digərlərindən aks tələb edir ki, 2 replikadan 3-də naşir tərəfindən göndərilən ən cari mesajlar olsun.
Broker nümunəsi dayandırıldıqda, yeni bir nümunə köhnəsini əvəz edir. Bununla belə, yeni broker bir neçə saat çəkə bilən sinxronlaşdırılmamış replikaları tutmalı olacaq. Bu ssenari üçün bərpa müddətini azaltmaq üçün yerli broker diskləri əvəzinə blok məlumat yaddaşından (Amazon Elastik Blok Mağazası) istifadə etməyə başladıq. Yeni bir nümunə dayandırılmış broker instansiyasını əvəz etdikdə, o, dayandırılmış nümunənin malik olduğu EBS həcmini əlavə edir və yeni mesajları tutmağa başlayır. Bu proses geriləmə müddətini saatlardan dəqiqələrə azaldır, çünki yeni nümunənin artıq boş vəziyyətdən təkrarlanmasına ehtiyac yoxdur. Ümumilikdə, ayrı saxlama və broker həyat dövrləri broker keçidinin təsirini əhəmiyyətli dərəcədə azaldır.
Məlumatların çatdırılması zəmanətini daha da artırmaq üçün istifadə etdik ekstremal şəraitdə hər hansı mesaj itkisini aşkar etmək üçün (məsələn, bölmə liderində saat desinxronizasiyası).
Stream Processing Framework
Delta-nın emal təbəqəsi Apache Flink-in Netflix ekosistemi ilə inteqrasiyasını təmin edən Netflix SPaaS platformasının üstündə qurulub. Platforma Titus konteyner idarəetmə platformamızın üstündə Flink işlərinin yerləşdirilməsini və Flink klasterlərinin təşkilini idarə edən istifadəçi interfeysi təqdim edir. İnterfeys həmçinin iş konfiqurasiyalarını idarə edir və istifadəçilərə Flink işlərini yenidən tərtib etmədən dinamik şəkildə konfiqurasiya dəyişiklikləri etməyə imkan verir.
Delta istifadə edən Flink və SPaaS-a əsaslanan axın emalı çərçivəsini təmin edir annotasiya əsasında Texniki təfərrüatları mücərrəd etmək üçün DSL (Domain Specific Language). Məsələn, xarici xidmətlərə zəng etməklə hadisələrin zənginləşdiriləcəyi addımı müəyyən etmək üçün istifadəçilər aşağıdakı DSL-i yazmalıdırlar və çərçivə onun əsasında Flink tərəfindən yerinə yetiriləcək bir model yaradacaq.
Şəkil 3. Delta-da DSL-də zənginləşdirmə nümunəsi
Emal çərçivəsi təkcə öyrənmə əyrisini azaldır, həm də ümumi əməliyyat problemlərini həll etmək üçün təkmilləşdirmə, sxemləşdirmə, çeviklik və elastiklik kimi ümumi axın emal xüsusiyyətlərini təmin edir.
Delta Stream Processing Framework iki əsas moduldan, DSL & API modulundan və Runtime modulundan ibarətdir. DSL və API modulu DSL və UDF (İstifadəçi tərəfindən müəyyən edilmiş funksiya) API təmin edir ki, istifadəçilər öz emal məntiqlərini (məsələn, filtrləmə və ya çevrilmələr kimi) yaza bilsinlər. Runtime modulu DAG modellərində emal addımlarının daxili təsvirini quran DSL analizatorunun tətbiqini təmin edir. İcra komponenti faktiki Flink ifadələrini işə salmaq və nəticədə Flink tətbiqini işə salmaq üçün DAG modellərini şərh edir. Çərçivənin arxitekturası aşağıdakı şəkildə təsvir edilmişdir.
Şəkil 4. Delta Stream Processing Framework arxitekturası
Bu yanaşmanın bir sıra üstünlükləri var:
- İstifadəçilər Flink və ya SPaaS strukturunun xüsusiyyətlərini araşdırmadan öz biznes məntiqinə diqqət yetirə bilərlər.
- Optimallaşdırma istifadəçilər üçün şəffaf şəkildə həyata keçirilə bilər və səhvlər istifadəçi kodunda (UDF) heç bir dəyişiklik tələb edilmədən düzəldilə bilər.
- Delta tətbiqi təcrübəsi istifadəçilər üçün sadələşdirilmişdir, çünki platforma qutudan kənarda çeviklik və dayanıqlıq təmin edir və xəbərdarlıqlar üçün istifadə edilə bilən müxtəlif detallı ölçüləri toplayır.
İstehsal istifadəsi
Delta bir ildən çoxdur istehsaldadır və bir çox Netflix Studio proqramlarında əsas rol oynayır. O, komandalara axtarışın indeksləşdirilməsi, məlumatların saxlanması və hadisəyə əsaslanan iş axınları kimi istifadə hallarını həyata keçirməyə kömək etdi. Aşağıda Delta platformasının yüksək səviyyəli arxitekturasına ümumi baxış verilmişdir.
Şəkil 5. Deltanın yüksək səviyyəli arxitekturası.
Təşəkkürlər
Netflix-də Delta-nın yaradılması və inkişafında iştirak edən aşağıdakı insanlara təşəkkür etmək istərdik: 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 və Zhenzhong Xu.
İnformasiya qaynaqları
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Hadisələrin onlayn işlənməsi. Kommun. ACM 62(5): 43–49 (2019). DOI:
: "Amazon Redshift Storage üçün Məlumat Quraşdırma Aləti."
Mənbə: www.habr.com