ханшаар шинэ урсгалыг эхлүүлэхийг хүлээж байна Бид сонирхолтой материалын орчуулгыг бэлдлээ.
тойм
Аппликейшнүүд олон тооны өгөгдлийн дэлгүүрүүдийг ашигладаг, дэлгүүр бүрийг өөрийн зорилгоор ашигладаг, тухайлбал, өгөгдлийн каноник хэлбэрийг (MySQL гэх мэт) хадгалах, хайлтын дэвшилтэт боломжуудыг (ElasticSearch, гэх мэт) .), кэш хийх (Memcached гэх мэт) болон бусад. Ихэвчлэн олон тооны мэдээллийн санг ашиглах үед тэдгээрийн нэг нь үндсэн, бусад нь дериватив дэлгүүрийн үүргийг гүйцэтгэдэг. Ганц асуудал бол эдгээр мэдээллийн санг хэрхэн синхрончлох явдал юм.
Бид давхар бичих, түгээсэн гүйлгээ гэх мэт олон дэлгүүрийг синхрончлох асуудлыг шийдэхийг оролдсон хэд хэдэн өөр хэв маягийг авч үзсэн. Гэсэн хэдий ч эдгээр аргууд нь бодит амьдрал дээр ашиглах, найдвартай байдал, засвар үйлчилгээний хувьд ихээхэн хязгаарлалттай байдаг. Өгөгдлийн синхрончлолоос гадна зарим програмууд нь гадны үйлчилгээ рүү залгах замаар өгөгдлийг баяжуулах шаардлагатай болдог.
Эдгээр асуудлыг шийдэхийн тулд Delta-г бүтээсэн. Delta нь эцсийн дүндээ өгөгдлийг синхрончлох, баяжуулах тууштай, үйл явдалд тулгуурласан платформоор хангадаг.
Одоо байгаа шийдлүүд
Давхар оруулга
Хоёр өгөгдлийн санг синхрончлолтой байлгахын тулд та нэг дэлгүүрт бичиж, дараа нь нөгөөд шууд бичдэг давхар бичих аргыг ашиглаж болно. Оролтын тоо дууссаны дараа эхний бичлэг амжилтгүй болсон тохиолдолд эхний бичлэгийг дахин оролдох, хоёр дахь бичлэгийг цуцлах боломжтой. Гэсэн хэдий ч, хоёр дахь дэлгүүрт бичих амжилтгүй болбол хоёр өгөгдлийн дэлгүүр синхрончлолгүй болж магадгүй юм. Энэ асуудлыг ихэвчлэн эхний хадгалалтаас хоёр дахь руу үе үе дахин шилжүүлэх боломжтой сэргээх процедурыг бий болгосноор шийдэгддэг, эсвэл өгөгдөлд ялгаа илэрсэн тохиолдолд л үүнийг хийдэг.
Асуудлууд:
Сэргээх процедурыг гүйцэтгэх нь дахин ашиглах боломжгүй тодорхой ажил юм. Нэмж дурдахад, сэргээх үйл ажиллагаа явагдах хүртэл хадгалалтын байршил хоорондын өгөгдөл синхрончлолгүй хэвээр байна. Хоёроос дээш мэдээллийн санг ашиглавал шийдэл нь илүү төвөгтэй болно. Эцэст нь сэргээх процедур нь анхны өгөгдлийн эх үүсвэрт ачааллыг нэмж болно.
Бүртгэлийн хүснэгтийг өөрчлөх
Хүснэгтийн багцад өөрчлөлт ороход (бичлэг оруулах, шинэчлэх, устгах гэх мэт) өөрчлөлтийн бүртгэлийг ижил гүйлгээний нэг хэсэг болгон бүртгэлийн хүснэгтэд нэмнэ. Өөр нэг хэлхээ эсвэл процесс нь бүртгэлийн хүснэгтээс үйл явдлуудыг байнга шаардаж, тэдгээрийг нэг буюу хэд хэдэн өгөгдлийн дэлгүүрт бичиж, шаардлагатай бол бүртгэлийг бүх дэлгүүрээр баталгаажуулсны дараа бүртгэлийн хүснэгтээс үйл явдлыг устгадаг.
Асуудлууд:
Энэ загварыг номын сан хэлбэрээр хэрэгжүүлэх нь зүйтэй бөгөөд үүнийг ашигладаг програмын кодыг өөрчлөхгүйгээр хийх нь зүйтэй. Полиглот орчинд ийм номын сангийн хэрэгжилт нь ямар ч шаардлагатай хэл дээр байх ёстой боловч хэл дээрх үйл ажиллагаа, зан үйлийн нийцтэй байдлыг хангах нь маш хэцүү байдаг.
Өөр нэг асуудал бол MySQL гэх мэт гүйлгээний схемийн өөрчлөлтийг [1][2] дэмждэггүй системд схемийн өөрчлөлтийг олж авахад оршдог. Тиймээс өөрчлөлт хийх (жишээлбэл, схемийн өөрчлөлт) болон түүнийг өөрчлөлтийн бүртгэлийн хүснэгтэд гүйлгээгээр бүртгэх загвар нь үргэлж ажиллахгүй.
Тархсан гүйлгээ
Тархсан гүйлгээг олон төрлийн өгөгдлийн сангуудын хооронд гүйлгээг хуваахад ашиглаж болох бөгөөд ингэснээр үйл ажиллагаа нь ашигласан бүх өгөгдлийн хадгалалтад зориулагдсан эсвэл тэдгээрийн аль нэгэнд нь зориулагдаагүй болно.
Асуудлууд:
Тархсан гүйлгээ нь янз бүрийн мэдээллийн сангуудын хувьд маш том асуудал юм. Тэдний мөн чанараар тэд зөвхөн холбогдох системүүдийн хамгийн бага нийтлэг зүйлд найдаж болно. Жишээлбэл, Бэлтгэл үе шатанд програмын процесс амжилтгүй болсон тохиолдолд XA гүйлгээ нь гүйцэтгэлийг блоклодог. Нэмж дурдахад, XA нь түгжрэлийг илрүүлэх боломжийг олгодоггүй эсвэл өөдрөг давхцах хяналтын схемийг дэмждэггүй. Нэмж дурдахад, ElasticSearch гэх мэт зарим системүүд XA болон бусад гетероген гүйлгээний загварыг дэмждэггүй. Тиймээс янз бүрийн өгөгдөл хадгалах технологид бичих атомыг баталгаажуулах нь хэрэглээний хувьд маш хэцүү ажил хэвээр байна [3].
Delta
Delta нь одоо байгаа өгөгдлийн синхрончлолын шийдлүүдийн хязгаарлалтыг шийдвэрлэхэд зориулагдсан бөгөөд өгөгдлийг шууд баяжуулах боломжийг олгодог. Бидний зорилго бол эдгээр бүх нарийн төвөгтэй байдлыг програм хөгжүүлэгчдээс салгаж, бизнесийн үйл ажиллагааг хэрэгжүүлэхэд бүрэн анхаарлаа хандуулах явдал байв. Дараа нь бид Netflix-ийн Delta-ийн бодит хэрэглээ болох "Кино хайлт"-ыг тайлбарлах болно.
Netflix нь микро үйлчилгээний архитектурыг өргөн ашигладаг бөгөөд микро үйлчилгээ бүр нэг төрлийн өгөгдөлд үйлчилдэг. Киноны талаарх үндсэн мэдээлэл нь Movie Service хэмээх бичил үйлчилгээнд агуулагддаг бөгөөд продюсер, жүжигчид, борлуулагчдын талаарх мэдээлэл гэх мэт холбогдох өгөгдлийг өөр хэд хэдэн бичил үйлчилгээ (жишээлбэл, Deal Service, Talent Service, Vendor Service) удирддаг.
Netflix Studios-ийн бизнес хэрэглэгчид киноны янз бүрийн шалгуураар хайлт хийх шаардлагатай байдаг тул кинотой холбоотой бүх мэдээллээс хайх боломжтой байх нь тэдэнд маш чухал байдаг.
Delta-аас өмнө кино хайлтын баг киноны өгөгдлийг индексжүүлэхээс өмнө олон микро үйлчилгээнээс өгөгдөл татах шаардлагатай байв. Нэмж дурдахад, баг нь ямар ч өөрчлөлт ороогүй байсан ч бусад бичил үйлчилгээнүүдээс өөрчлөлт оруулах хүсэлт гаргаж хайлтын индексийг үе үе шинэчилж байх системийг боловсруулах шаардлагатай болсон. Энэ систем хурдан төвөгтэй болж, засвар үйлчилгээ хийхэд хэцүү болсон.
Зураг 1. Дельта руу санал авах систем
Delta-г ашигласны дараа системийг дараах зурагт үзүүлсэн шиг үйл явдалд тулгуурласан систем болгон хялбаршуулсан. CDC (Өгөгдөл өөрчлөх) үйл явдлуудыг Delta-Connector ашиглан Keystone Кафкагийн сэдвүүд рүү илгээдэг. Delta Stream Processing Framework (Flink дээр суурилсан) ашиглан бүтээгдсэн Delta програм нь CDC-ийн үйл явдлуудыг тухайн сэдвээс хүлээн авч, бусад микро үйлчилгээг дуудаж баяжуулж, эцэст нь баяжуулсан өгөгдлийг Elasticsearch дахь хайлтын индекс рүү дамжуулдаг. Бүх үйл явц нь бараг бодит цаг хугацаанд явагддаг, өөрөөр хэлбэл мэдээллийн агуулахад өөрчлөлт оруулмагц хайлтын индексүүд шинэчлэгддэг.
Зураг 2. Delta ашиглан өгөгдөл дамжуулах хоолой
Дараах хэсгүүдэд бид CDC-ийн үйл явдлуудыг Кафкагийн сэдвүүд рүү чиглүүлдэг бодит цагийн өгөгдөл дамжуулах дэд бүтэц болох хадгалалттай холбогдож CDC үйл явдлуудыг тээврийн давхаргад нийтэлдэг Delta-Connector-ийн ажиллагааг тайлбарлах болно. Төгсгөлд нь бид програм хөгжүүлэгчид өгөгдөл боловсруулах, баяжуулах логикт ашиглаж болох Delta урсгал боловсруулах тогтолцооны талаар ярих болно.
CDC (Өгөгдлийг өөрчлөх)
Бид Delta-Connector хэмээх CDC үйлчилгээг хөгжүүлсэн бөгөөд энэ нь мэдээллийн сангаас хийсэн өөрчлөлтийг бодит цаг хугацаанд нь авч, урсгал руу бичих боломжтой. Бодит цагийн өөрчлөлтийг гүйлгээний бүртгэл болон хадгалах сангаас авдаг. Гүйлгээний бүртгэл нь ихэвчлэн өөрчлөлтийн түүхийг бүхэлд нь хадгалдаггүй тул dumps ашигладаг. Өөрчлөлтүүд нь ихэвчлэн Delta үйл явдлуудын цуваа хэлбэрээр хийгддэг тул хүлээн авагч нь өөрчлөлт хаанаас ирсэн талаар санаа зовох шаардлагагүй болно.
Delta-Connector нь хэд хэдэн нэмэлт функцуудыг дэмждэг, тухайлбал:
- Кафкагийн өмнөх гаралтын өгөгдлийг бичих чадвар.
- Бүх хүснэгтүүд, тодорхой хүснэгтүүд эсвэл тодорхой үндсэн түлхүүрүүдийн хувьд гараар дампыг хүссэн үедээ идэвхжүүлэх чадвар.
- Хогийн савыг хэсэг хэсгээр нь гаргаж авах боломжтой тул бүтэлгүйтсэн тохиолдолд дахин эхлүүлэх шаардлагагүй.
- Хүснэгтэнд түгжээ тавих шаардлагагүй бөгөөд энэ нь мэдээллийн сангийн бичих урсгалыг манай үйлчилгээнээс хэзээ ч хаахгүй байх нь маш чухал юм.
- AWS Availability Zones дахь илүүдэл тохиолдлуудын улмаас өндөр хүртээмжтэй байна.
Бид одоогоор AWS RDS болон Aurora дээр байршуулалт зэрэг MySQL болон Postgres-ийг дэмждэг. Бид мөн Кассандра (олон мастер) дэмждэг. Та Delta-Connector-ийн талаарх дэлгэрэнгүй мэдээллийг эндээс авах боломжтой .
Кафка ба тээврийн давхарга
Delta-ийн үйл явдлыг дамжуулах давхарга нь платформын мессежийн үйлчилгээн дээр бүтээгдсэн .
Түүхийн хувьд Netflix дээр нийтлэх нь урт наслахаас илүү хүртээмжтэй байх үүднээс оновчтой болсон (доороос үзнэ үү). ). Худалдаа нь янз бүрийн захын хувилбаруудад брокерын өгөгдөлд нийцэхгүй байх явдал байв. Жишээлбэл, цэвэр бус удирдагчийн сонгууль Давхардсан эсвэл алдагдсан үйл явдлуудыг хүлээн авагч хариуцна.
Delta-ийн тусламжтайгаар бид CDC-ийн үйл явдлуудыг гарал үүсэлтэй дэлгүүрүүдэд хүргэхийн тулд илүү бат бөх баталгаатай байхыг хүссэн. Энэ зорилгоор бид тусгайлан зохион бүтээсэн Кафка кластерыг нэгдүгээр зэрэглэлийн объект болгон санал болгосон. Та доорх хүснэгтээс брокерын зарим тохиргоог харж болно.
Keystone Кафкагийн кластеруудад, цэвэр бус удирдагчийн сонгууль нийтлэгчийн хүртээмжийг хангах үүднээс ихэвчлэн оруулдаг. Энэ нь синхрончлолгүй хуулбарыг удирдагчаар сонгосон тохиолдолд мессеж алдагдаж болзошгүй. Шинэ өндөр хүртээмжтэй Кафка кластерын хувьд сонголт цэвэр бус удирдагчийн сонгууль мессеж алдагдахаас сэргийлж унтраасан.
Бид ч бас нэмэгдсэн хуулбарлах хүчин зүйл 2-оос 3 хүртэл хамгийн бага синхрончлолын хуулбар 1-ээс 2. Энэ кластерт бичдэг нийтлэгчид бусад бүх хүмүүсээс акк шаарддаг бөгөөд 2 хуулбарын 3 нь нийтлэгчийн илгээсэн хамгийн сүүлийн мессежтэй байх ёстой.
Брокерын инстанц дуусгавар болох үед шинэ жишээ хуучин нэгийг орлоно. Гэсэн хэдий ч шинэ брокер нь синхрончлогдоогүй хуулбарыг гүйцэх шаардлагатай бөгөөд энэ нь хэдэн цаг болж магадгүй юм. Энэ хувилбарыг сэргээх хугацааг багасгахын тулд бид дотоод брокер дискний оронд блок өгөгдөл хадгалах санг (Amazon Elastic Block Store) ашиглаж эхэлсэн. Шинэ инстанц нь дуусгавар болсон брокерын инстанцыг солих үед энэ нь дуусгавар болсон инстанцтай байсан EBS хэмжээг хавсаргаж, шинэ мессежүүдийг гүйцэж эхэлдэг. Шинэ инстанц хоосон төлөвөөс дахин хуулбарлах шаардлагагүй тул энэ процесс нь хоцрогдол арилгах хугацааг хэдэн цагаас минут болгон багасгадаг. Ерөнхийдөө тусдаа хадгалалт ба брокерын амьдралын мөчлөг нь брокер солих нөлөөллийг эрс багасгадаг.
Мэдээлэл хүргэх баталгааг цаашид нэмэгдүүлэхийн тулд бид ашигласан эрс тэс нөхцөлд (жишээ нь, хуваалтын удирдагч дахь цагийг синхрончлолгүй болгох) аливаа мессежийн алдагдлыг илрүүлэх.
Stream Processing Framework
Delta-ийн боловсруулалтын давхарга нь Netflix SPaaS платформ дээр баригдсан бөгөөд энэ нь Netflix экосистемтэй Apache Flink интеграцчлалыг хангадаг. Энэхүү платформ нь манай Titus контейнерийн менежментийн платформ дээр Flink ажлуудыг байршуулах, Flink кластеруудыг зохион байгуулах ажлыг удирддаг хэрэглэгчийн интерфейсээр хангадаг. Мөн интерфэйс нь ажлын тохиргоог удирдаж, хэрэглэгчдэд Flink ажлуудыг дахин эмхэтгэх шаардлагагүйгээр динамикаар тохиргооны өөрчлөлт хийх боломжийг олгодог.
Delta нь ашигладаг Flink болон SPaaS дээр суурилсан урсгал боловсруулах тогтолцоог хангадаг тайлбар дээр суурилсан Техникийн мэдээллийг хийсвэрлэхийн тулд DSL (Домэйн тодорхой хэл). Жишээлбэл, гадны үйлчилгээг дуудах замаар үйл явдлуудыг баяжуулах алхмыг тодорхойлохын тулд хэрэглэгчид дараах DSL-г бичих шаардлагатай бөгөөд фрэймворк нь түүн дээр суурилсан загварыг бий болгох бөгөөд үүнийг Флинк гүйцэтгэх болно.
Зураг 3. Delta дахь DSL дээр баяжуулалтын жишээ
Боловсруулалтын хүрээ нь сургалтын муруйг багасгаад зогсохгүй давхардал, схемчлэл, үйл ажиллагааны нийтлэг асуудлуудыг шийдвэрлэх уян хатан байдал, уян хатан байдал зэрэг урсгал боловсруулах нийтлэг боломжуудыг олгодог.
Delta Stream Processing Framework нь DSL & API модуль болон Runtime модуль гэсэн хоёр үндсэн модулиас бүрдэнэ. DSL & API модуль нь DSL болон UDF (Хэрэглэгчийн тодорхойлсон функц) API-уудыг хангадаг бөгөөд ингэснээр хэрэглэгчид өөрсдийн боловсруулалтын логикийг (шүүлтүүр, хувиргалт гэх мэт) бичих боломжтой. Runtime модуль нь DAG загваруудын боловсруулалтын үе шатуудын дотоод дүрслэлийг бий болгодог DSL задлагчийн хэрэгжилтийг хангадаг. Гүйцэтгэлийн бүрэлдэхүүн хэсэг нь бодит Flink мэдэгдлийг эхлүүлэхийн тулд DAG загваруудыг тайлбарлаж, эцэст нь Flink програмыг ажиллуулдаг. Хүрээний архитектурыг дараах зурагт үзүүлэв.
Зураг 4. Delta Stream Processing Framework архитектур
Энэ арга нь хэд хэдэн давуу талтай:
- Хэрэглэгчид Flink эсвэл SPaaS бүтцийн онцлогийг судлах шаардлагагүйгээр бизнесийн логик дээрээ анхаарлаа төвлөрүүлж болно.
- Оновчлолыг хэрэглэгчдэд ил тод байдлаар хийж болох ба алдааг хэрэглэгчийн код (UDF)-д ямар нэгэн өөрчлөлт оруулах шаардлагагүйгээр засч болно.
- Платформ нь уян хатан байдал, уян хатан байдлыг хангаж, сэрэмжлүүлэгт ашиглаж болох олон төрлийн нарийвчилсан хэмжүүрүүдийг цуглуулдаг тул Delta програмын туршлагыг хэрэглэгчдэд хялбаршуулсан.
Үйлдвэрлэлийн хэрэглээ
Delta нь нэг жил гаруйн турш үйлдвэрлэгдсэн бөгөөд Netflix Studio-ийн олон программд гол үүрэг гүйцэтгэдэг. Тэрээр хайлтын индексжүүлэлт, өгөгдөл хадгалах, үйл явдалд тулгуурласан ажлын урсгал зэрэг хэрэглээний тохиолдлуудыг хэрэгжүүлэхэд нь багуудад тусалсан. Дельта платформын өндөр түвшний архитектурын тоймыг доор харуулав.
Зураг 5. Дельтагийн өндөр түвшний архитектур.
Талархал
Netflix-д Delta-г бүтээх, хөгжүүлэхэд оролцсон дараах хүмүүст баярлалаа: Аллен Ван, Чарльз Жао, Жэйбин Юн, Жош Снайдер, Кастури Чаттержи, Марк Чо, Олоф Йоханссон, Пиюш Гоял, Прашант Рамдас, Рагурам Онти Шринивасан, Сандип Гупта, Стивен Ву, Таранга Гамаэтигэ, Юн Ван, Жэнжун Сю.
Эх сурвалжууд
- Martin Kleppmann, Alastair R. Beresford, Boerge Svingen: Онлайн үйл явдал боловсруулах. Коммун. МУЗ 62(5): 43–49 (2019). DOI:
: "Amazon Redshift Storage-д зориулсан өгөгдөл бүтээх хэрэгсэл."
Эх сурвалж: www.habr.com