Да покажеш, че наистина те е грижа. Разговор с д-р Десислава Иванова

Post Syndicated from Надежда Цекулова original https://www.toest.bg/da-pokazhesh-che-naistina-te-e-grizha/

Да покажеш, че наистина те е грижа. Разговор с д-р Десислава Иванова

Срещаме се с д-р Десислава Иванова в дните между Международния ден на анестезиолога – 16 октомври, и Деня на българския лекар – 19 октомври, пред УМБАЛ „Св. Анна“ в София. В момента д-р Иванова е част от анестезиологичния екип на болницата, известна на столичани като „Окръжна“. Всеки ден тя идва на работа от кв. „Надежда“ на колело. В свободното си време обича да „рестартира“ мозъка си с планинско колоездене и скално катерене. Смята, че хората, които искат да променят здравеопазването, трябва да са компетентни и да работят за общото благо.

Представете се.

Вече съм на почти 42. Работя в поредната държавна болница. Не мога да се откъсна от държавите болници.

Защо сменяте болниците?

Според мен е правилно човек да смени, когато отношенията се изчерпят, независимо дали става дума за лични, или професионални отношения. И в двата случая става въпрос за взаимодействие между хората. Даваш, вземаш, когато тези отношения се изчерпят, трябва да освободиш място за някой друг, а ти да намериш ново място, за да продължиш да се развиваш.

Публичният имидж на здравеопазването създава впечатление, че хората си плащат, за да отидат в частна болница и да получат по-любезно отношение, уважение на правата и желанията им. Любопитно е защо през очите Ви на анестезиолог изглежда обратното…

Не знам, може би в държавните болници са се съхранили медицината и отношението към пациента. Работила съм в „Александровска болница“ 6–7 години, в „Пирогов“ още толкова и една година в частна болница. Мисля, че там видях дъното. Дъното на човека в отношението му към човек. В момента работя в УМБАЛ „Св. Анна“, бившата Окръжна болница.

Това, че някъде пациентът получава любезно отношение, не означава, че получава най-добрата медицина. Аз го видях по този начин, не твърдя, че винаги и навсякъде е така. Всички се стараем да бъдем съпричастни към пациентите. На някои колеги им се удава повече, на други по-малко, но това не изчерпва грижата за пациента.

Съпричастността обаче е важна за пациентите. Според Вас дали лекарите биха я изразявали по-добре, ако получават подкрепа за това?

Подкрепа от кого?

Вие от кого бихте искали да получите подкрепа?

Според мен всичко е въпрос на възпитание в семейството. Ако там сте изразявали емоциите си и сте се научили да ги уважавате, това остава за цял живот.

А според Вас няма ли място за отношенията лекар–пациент в медицинското образование? Българското медицинско образование обръща по-малко внимание на този въпрос в сравнение с други системи. Дали трябва да разчитаме само на семейното възпитание, или общуването е инструмент, който един бъдещ лекар трябва да изучи?

Да, и аз съм чувала от колеги, че в други държави се държи много повече на това. При нас общуването е умение, което се добива по-скоро неформално. Аз имах късмета да случа на прекрасни учители. Те ме научиха, че това не го пише в книгите ни, но то е не по-малко важно за пациента и определящо за работата, която можем да свършим. Покрай тях свикнах как да общувам с пациентите, как да стигам до информацията, която ми е нужна, по начин, който да създаде доверие и спокойствие у пациента. Пациентът трябва да усеща твоята подкрепа, да бъде сигурен, че наистина желаеш той да се подобри. И както вербалната, така и невербалната комуникация са пътят да му покажеш това – че наистина те е грижа.

Вие как решихте да станете лекар?

Съседите ни бяха семейство лекари. Може би от тях съм се запалила, но не съм убедена, продължавам понякога да се чудя защо. Майка ми и баща ми са учители – по математика и по руски. Наглед нищо общо! Но всъщност анестезиологията и реанимацията си е чиста физика – ние работим с флуиди, налягане, с електричество, ако щете. А на мен това е голямата ми страст.

Когато едно дете мечтае да се развие в някаква професия, очакванията му понякога катастрофират в реалността. Какво беше за едно момиче от малък град, дете на учители, да стане български лекар?

Преди да стана български лекар, бях български студент по медицина от бедно семейство. В ония години имаше повече кандидати и всеобщото мнение беше, че за да влезеш в Медицинския университет в София, трябва да изкараш едни курсове, които струват хиляди левове. Родителите ми нямаше откъде да ги вземат. Съответно мен ме приеха на третата година без курсове и помня как на първите упражнения ни разпитваха: „Вие при кого ходихте на курсове?“ Като кажех, че идвам от Математическата гимназия в Казанлък, реагираха с огромно учудване: „Е как така влязохте?!“ Все ми се искаше да им кажа: не знам, пуснахте ме, явно ви е писнало да ми гледате почерка.

После трябваше да работя, за да се издържам. Една сутрин след нощна смяна закъснях за упражнения и асистентът ме посрещна с репликата: „Колежке, вие не знаете ли, че медицината не е за бедни хора.“

Така че първите шест години бяха тежка тренировка.

Но попаднах и на много добри учители, които много ме подкрепяха. Помня как д-р Станчев казваше: „Детенце, някой ден пациентът няма да те пита на коя година си приета и с каква диплома си завършила. Ще иска да му помогнеш.“ И то е така.

Как изглежда развитието Ви сега, през прозореца на Окръжна болница? Успявате ли да сте в крак със съвременната анестезиология и интензивно лечение, да настигате амбицията си?

Да. Тук, ако човек иска да работи, му се дава възможност, като се гледа на първо място интересът на пациента. За да си добър в нашата работа – то във всяка професия е така, – трябва да се чете непрекъснато. Нещо, което много ме вдъхновява, са младите колеги в екипа – има млади колеги, специалисти и специализанти, които много четат. Непрекъснато си говорим, обсъждаме статии, случаи. Това е уау!

Та, да се върна на въпроса как изглежда – четеш, прилагаш това, за което ти дава възможност държавата, и хубавото е, че тук ти се отваря поле да работиш.

Това какво означава? Може ли да обясните, защото на мен ми е малко трудно да си представя при недостиг на анестезиолози какво означава да не им се дава да работят.

Стигало се е до такива ситуации, затова и аз съм си тръгвала… Явно има все пак достатъчно колеги, които приемат някой друг да им казва как да си вършат работата. Когато изискванията към теб нарушават принципите ти, просто си тръгваш, това е. И продължаваш да даваш всичко, на което смяташ, че си способен, на друго място.

Мислите ли, че Ви ограничава това, че сте имено български лекар, а не френски или германски, примерно?

Самият факт, че все още съм български лекар, а не френски или германски, означава, че се чувствам удовлетворена. Към момента е така. Не ме мъчи въпросът щастлива ли съм от това, че живея и работя тук – напълно наясно съм.

Вълнувате ли се от здравеопазването като система, от политиките в здравеопазването, от политиката в здравеопазването?

Не. Нямам сили, за съжаление може би. Мисля, че не ми е в компетенциите да се ангажирам.

А аз понякога си мисля, че ако повече редови лекари се вълнуват от политиките в здравеопазването, тези политики може да станат по-качествени и за лекарите, и за пациентите им. Вие явно не мислите така, чудя се защо се разминаваме. Вие как си го обяснявате?

Да се вълнуваш и да имаш идеи не е достатъчно, трябва да можеш и да ги осъществяваш. Според мен хората, които искат да променят средата, завършват „Здравен мениджмънт“, отиват и се борят за общото благо. Аз мисля за себе си, че мога да допринеса за лечебния процес на пациента в болницата. Не мисля, че притежавам качества да променям точно тази система.

Това значи ли, че в други системи се чувствате по-уверена да променяте и да бъдете активист?

Да. Защитата на животните е това, в което съм по-активна – работя с институции, общини, доброволци. Това, което правя всъщност, е да сигнализирам на институциите – най-често общините – да си изпълнят задълженията по Закона за защита на животните. Има програма, която се нарича „Кастрирай и върни“ и нейната цел е по хуманен начин да се намали популацията на бездомни животни – кучета основно, но и котки. Тя обаче не се изпълнява достатъчно добре навсякъде, немалко общини се освобождават от животните по нехуманен начин. Това е нетрайно решение, но на някои общини явно не им пречи. Фактът, че причиняват страдания на гръбначно животно, явно също не им пречи… В случая моята работа е да подавам сигнали, да питам защо така се случва, какво става с парите, които по бюджет са предвидени за кастриране – и така бавно-бавно колелото се завърта.

Явно правите всичко това, без да сте завършили „Мениджмънт на защитата на животни“, примерно.

Добра аналогия, хванахте ме!

Целта не беше да Ви „хващам“. По-скоро да си представим заедно каква е ролята на хилядите редови лекари в това здравеопазването да стане по-хуманно и да причинява по-малко страдание – както на пациентите, така и на всички медици, които се грижат за тях. Защото не можем да разчитаме само на политиците.

Не мога да кажа за всички лекари. Но за себе си мисля, че може би не съм се сблъсквала с толкова остро усещане за несправедливост в работата си, колкото виждам в отношението към животните. Разбира се, че в здравеопазването също има несправедливости. Но като че ли се опитваме да ги компенсираме. Някак въпреки тях да успеем да си свършим работата. Или може би защото все още не съм усетила даден закон, примерно, да ми пречи да си върша работата, или да имам нужда от някакъв закон, за да си я свърша. В нашата професия, ако си чел достатъчно, ако си разбираш от работата и имаш достатъчно опит – професионален и житейски – може да се справиш със ситуацията, така че да се направи нужното за благополучието на пациента.

Казахте „ако имаш достатъчно опит“. Това значи ли, че смятате медицината за изкуство?

Изкуство? Не, това твърдение никога не съм го разбирала. Тази фраза идва много отдалеч във времето, вече сме отишли напред в развитието си. Изкуство ли е?

Министърът на здравеопазването така смята.

Не знаех. Според мен е много повече логика, математика, физика… Наука, отговорност и рационални решения. Протоколи.

Вие по протоколи ли работите?

Да. Имахме такива и в „Пирогов“, имаме и в „Св. Анна“, в клиниките, в които работя. Те са разписани на база международни протоколи и консенсуси, не е нещо, което сме измислили. Просто се адаптира за съответното отделение. В някои държави има национални, но при нас са на ниво болница.

Говорим много за анестезиологията. Някои Ваши колеги казват, че това е най-тежката специалност. На Вас тежка ли ви се струва?

Знаете ли, днес давах една анестезия в Очна клиника. И се замислих как още от университета съществува тоя предразсъдък, че очните болести и дерматологията са елементарни специалности. Но не е така. Ако човек загуби зрението си вследствие на твое неправилно решение, е сериозна отговорност – кое е елементарното? Или например в дерматологията има много заболявания, които са хронични – в момента няма лечение за тях, най-много временно облекчение. Това може да доведе след време до поведенчески и психични промени. И пациентът се надява на теб, а ти трябва да му обясниш, че такова е положението, такова е нивото на науката в момента – това да не би да е лесно? Във всяка специалност има специфики и трудности.

Може би убеждението за леките и тежките специалности идва оттам, че един анестезиолог трудно може да реши, че вече не му се работи в болница, и да стане амбулаторен лекар.

Всичко е въпрос на мотивация! Познавам лекари, които са били анестезиолози и после са станали фармацевтични представители.

Но е много важно да можеш да слагаш граници между професията и личния живот. За да си адекватен лекар, мозъкът ти трябва да е отпочинал. Това важи за всяка професия.

Вие успявате ли да имате личен живот?

Успявам донякъде. Родителството се оказа доста трудна работа. Може би когато синът ми стане на около 30 години, може да го питам как съм се справила, успяла ли съм, или не.

Изглежда като да сменяте една трудна работа с друга трудна работа. Нали казахте, че мозъкът трябва да е отпочинал, как става това?

С хобита. Много ми е любимо скалното катерене, защото само мислиш как да продължиш, без да паднеш. На мен най-големият ми страх не е да не умра, а да не се инвалидизирам. И когато се катеря, умът ми е съсредоточен в това и в нищо друго. Така на другия ден нямам търпение да отида на работа.

Нямате търпение?

Да. Много е хубаво човек да си обича професията! И затова според мен е голям проблем, че хората избират професия по задължение или поне по някакви външни причини, а не защото им е страст. За мен лично лекарската професия е най-важна, защото съм я избрала. Но всъщност всички професии са важни посвоему. Най-важно е да се чувстваш добре с това, което правиш, и да ти е чиста съвестта в края на деня.


В рубриката „Разговори за здравеопазването" Надежда Цекулова кани своите събеседници да поговорят без клишета и празнодумие за проблемите и решенията, болката и оздравяването, медицината и политиката.

На второ четене: „Идва събота“

Post Syndicated from Стефан Иванов original https://www.toest.bg/na-vtoro-chetene-idva-sabota/

„Идва събота“ от Лусия Бърлин

На второ четене: „Идва събота“

Превод от английски Василена Мирчева, изд. „Кръг“, 2021

Симон Вейл пише писмо на Жое Буске на 13 април 1942 г., година преди смъртта си, в което му казва, че „вниманието е най-рядката и чиста форма на щедрост“. Вниманието като разбиране на себе си и на другия. Жое Буске е поет, тежко ранен в края на Първата световна война, парализиран е и прекарва голяма част от остатъка от живота си на легло и в постоянна болка, за която взима опиум.

Разказите на Лусия Бърлин са едни от най-добрите, които някога съм чел.

Заслуга за това до голяма степен има и образцовият превод на Василена Мирчева. Сравненията с Чехов, Реймънд Карвър, Кларис Лиспектор или Буковски са колкото уместни, толкова и не са. В писането ѝ има искрен и щедър поглед и още по-щедро разбиране на парализирани от страх, любов или болест хора, а не просто персонажи или герои, които са чисто нейни. Не са плод на интелектуално или литературно влияние, а идват от живота и опита ѝ. Тя ги преувеличава и трансформира. Превръща ги в проза, която е като среща и откровен разговор с приятел, когото познаваш в цялост. Познаваш го в истината и сложността му.

Като си мисля за тези разкази, най-лесно ми е да опиша прочита ми с цитат от един от тях:

… когато после мислеше за това, не беше по начина, по който си спомняш човек или сексуален акт, а като природно явление, лек земетръс, повей на вятъра в летен ден.

Бърлин е като отделен сезон в читателската ми година. Израснала е в Чили и е живяла в Мексико, Ню Йорк и на дузина места в Америка. Има множество любовници и съпрузи, майка е на четири деца. Красива е като Елизабет Тейлър, но е била с тежка форма на сколиоза и ѝ е отнело дълго време да се пребори с алкохолизма. Разказите ѝ са за семейството ѝ, за превод на стихотворение, за престои в изтрезвително, арест и реанимация, за индианците, които среща в обществените перални, за миньори, гмуркачи, музиканти и жокеи, за дядо ѝ – зъболекар и насилник, за работата ѝ – като секретарка в болница, учителка и чистачка, за затворници, които посещават курса ѝ по творческо писане.

Разказите ѝ са за полудялото време на влюбването, секса и скръбта, покоя на помирението и стоицизма на остаряването.

Писането на Бърлин е белязано от сурова откровеност, хумор, безпощадна и топла прецизност, изчерпателен реализъм и детайли, чието събиране и концентрация карат няколко фрази, един параграф или разказ да се усещат като поема, новела или роман. Няма празни приказки в писането ѝ.

На второ четене: „Идва събота“

Трудно ми е да избера какво да цитирам. Отбелязах си дузини параграфи. Но се връщах към един и същ. Нейно е едно от най-интензивните описания на еуфорията и екстаза от първия стадий на влюбване:

Хранеха животните по едно и също време всеки ден, но останалото от дните и нощите се обърка. Оставаха в леглото целия ден, закусваха, когато се стъмваше, разхождаха се из горите на лунна светлина. Гледаха „Мистър Лъки“ с Кари Грант в три посред нощ. Лениви от жаркото слънце, гребяха с дървена лодка в езерото, ловяха риба, четяха Джон Дън, Уилям Блейк. Лежаха на влажната трева, гледайки пиленцата, говореха си за детството си, за децата си. Гледаха как Нолан Райън отбелязва точки, спяха часове наред в спални чували край езерото. Любеха се във ваната на лъвски крака, в лодката, в гората, но най-вече сред искрящата зеленина на верандата, докато валеше. Какво е любовта? Мария се питаше, гледайки чистите линии на лицето му, докато той спеше.

Това описание вече е редом в паметта ми до едно на Анита Брукнър от „Хотелът край езерото“.

Не мога да разбера как толкова добра писателка не е получила приживе безспорното признание, което е заслужавала? В момента на Бърлин не ѝ липсват читатели, награди и включвания във всевъзможни списъци за най-добри книги. Това е следствие от настоящия сборник, съставен от Стивън Емерсън, Бари Гифърд и Майкъл Улф, нейни приятели и ценители. Той е първият, публикуван от голямо американско издателство. Може би и безкомпромисната ѝ независимост, страненето от литературни и академични кръгове също са сред причините за пренебрегването ѝ, за не особената ѝ видимост. 

А Лусия Бърлин винаги е била толкова добра писателка. Може би чувствителността и културата на публиката се променят. Може би е и въпрос на вкусове, тенденции или мода. На подходящ момент. Няма да спра да се удивявам как има хора, които са по-талантливи, по-интересни и по-умни от преподаватели и писатели, а не преподават и не пишат. Да, нужно е и его, амбиция и последователност, но понякога на притежаващите тези качества им липсват други.

За успелите се случва да има един свят и той е приветлив, боядисан, ремонтиран и уреден. Но под него има и друг. И за него пише Бърлин. Прозаичният ѝ свят е за това, което е прикрито. За раните, болката и травмата. Може да ги направиш приемливи. Върху тях може да сложиш грим, дрехи, аксесоари, автомобил, но това отдолу остава и даже и да се заглушава, то постоянно избива на повърхността. Прекомерната близост с реалността предизвиква изтласкване и недоверие. Човешката и артистична смелост може да предизвика завист, несправедливост или унижение.

В България има преизобилие от болка и за нея се говори недостатъчно. Маркира се, очертава се, загатва се, но за нея главно се мълчи.

Колкото е по-болен пациентът, толкова по-малко шум вдига,

пише американската писателка. За болката често се казва, че е битова, че е излишно драматизиране да се говори за нея, че не е достоен обект на изкуството. Защо пък да се пише за това; да не създаваме излишни грижи на читателя; той си има достатъчно. Да го утешим с плацебо. И без това няма какво да се направи, проблемите са нерешими, няма смисъл да пишем за тях.

Четейки разказите на Бърлин, бих искал да чета разкази за българските касиерки, за медицинските сестри, за лекарките, сервитьорките и готвачките, за учителките, за чистачките, за жените в офисите, но и за т.нар. лелички в държавната администрация. За жените, които са гръбнакът и на тази държава.

Бих искал да чета за тях, но не калкулирани, полирани или сантиментални измишльотини, а истината. Тяхната истина. Те, както и героините на Бърлин, както и самата тя, не са жертви на средата или обстоятелствата. Тяхната истина не е за шокиране или умиление, а е свидетелство за една забележителна страна на живота и на достойнството в него. Просто, колкото и да не е за вярване, все още има и истина, и реалност. И в нея има красота, за която често сме склонни да си затваряме очите. Има и смелост.

Тя е нужна във времена на реклама и борба за внимание и харесване в социалните мрежи. Във времена на лесни суперлативи и копнеж по вписване, по приемливост и загладеност без остри ръбове или риск.

Във времена на обидчивост и лицемерие това са жестоки разкази. Необходими са.

Както за Бърлин е нямало начин да не ги напише, така и читателите имат нужда да ги прочетат. Възможни са и днес, стига писателят, който ги пише, да знае, че може и да не излезе начело в класациите с тях. Може да си позволи написването им автор, който не иска да е на първо място. Който е поне малко лишен от пресметливост, който не слага филтри на снимките и на писането си, не е зает непрекъснато с проекти, грантове, резиденции, телевизионни или радиоучастия. Има ли място такова писане днес? Желано ли е? Пазарът и медиите предпоставят ли го? Не съм съвсем сигурен.

Отговорът е сложен. Писане като това на Бърлин поставя под въпрос контекст и установени клишета. С лекота може да бъде пренебрегнато, зачеркнато и отречено като грубо, грозно или безсрамно. И в Америка, а не само в България има еснафски, угоднически, консервативни и конформистки ценности. Творчеството на всеки писател, без значение колко е добър, може да бъде заметено под килима, а писателят – овъртолен в килима, нарамен и изхвърлен.

Но от всеки писател зависи дали ще бъде свидетел, или лъжесвидетел на времето си. Въпрос на внимание и избор е.

Дали ще иска да е успешен, готин и куул, или ще избере свой собствен път, който неизбежно е и трънлив. По този път успех и провал може да са синоними. Може рождената дата да е и ден на смърт, каквато е 12 ноември за Лусия Бърлин.


Активните дарители на „Тоест“ получават постоянна отстъпка в размер на 20% от коричната цена на всички заглавия от каталога на издателство „Кръг“, както и на няколко други български издателства в рамките на партньорската програма Читателски клуб „Тоест“. За повече информация прочетете на toest.bg/club.

Никой от нас не чете единствено най-новите книги. Тогава защо само за тях се пише? „На второ четене“ е рубрика, в която отваряме списъците с книги, публикувани преди поне година, четем ги и препоръчваме любимите си от тях. Рубриката е част от партньорската програма Читателски клуб „Тоест“. Изборът на заглавия обаче е единствено на авторите – Стефан Иванов и Севда Семер, които биха ви препоръчали тези книги и ако имаше как веднъж на две седмици да се разходите с тях в книжарницата.

Намерени в превода

Post Syndicated from original https://www.toest.bg/namereni-v-prevoda/

Намерени в превода

Последния път завършихме със свети Йероним, сега ще започнем с него. Познат и като Йероним Блажени, светецът е най-известен с превода си на Библията от гръцки и еврейски на латински език, наречен Вулгата (Vulgata), с придружаващите го преводачески коментари, както и с множеството си други писания по преводачески теми. Заради тези свои дейности свети Йероним се смята за патрон и покровител на преводачите, а на 30 септември (деня на смъртта му през 420 г.) се чества Международният ден на превода.

И въпреки че септември вече е зад нас,

за превода – и преводачите! – си заслужава да се говори по-често, а не само по официални поводи.

В този текст, поне първоначално, ще подходим към превода съвсем буквално в опит да проследим етимологията на думата в различни езици. А сякаш като олицетворение на дейността, която обозначава, самото проследяване се оказва доста сложно и главозамайващо оплетено.

Освен чисто езиково, вглеждането в разнопосочните етимологии на думата „превод“ е любопитно и защото разкрива широкия спектър от разбирания за това в какво всъщност се състои дейността на преводачите. С други думи,

самите понятия, които обозначават превода, може да се разглеждат като метафори – преводът като пре-веждане, пре-местване, пре-насяне, пре-обръщане, а дори и като бродиране и чеверме.

По някаква причина иначе доста обширният Български етимологичен речник на БАН не включва думата „превод“, а другите речници, с които се консултирах, не съдържат етимологичните ѝ тълкувания. Затова не ни остава друго, освен да предположим, че българската дума споделя сходна етимология с руския си еквивалент. Той („перевод“) е образуван от глагола „переводѝть“, чийто корен произлиза от праславянската *voditi, а тя на свой ред – от праиндоевропейската *wodʰéyeti, с корен *wedʰ- (‘водя’)¹.

Макар и с различен корен, идеята за превода като „водене през“ съществува и в еквивалентните думи на романските езици – френската traduction, испанската traducción, италианската traduzione произлизат от латинската transducere: от trans (‘през’) + ducere (‘водя’).

Отделна теория, която освен леко съмнителна е и доста изкушаваща – особено за преводачи, които смятат заниманията си за ювелирно изкуство, – обяснява етимологията на думата „превод“ в сърбохърватския като свързана с „превести“, чийто праславянски корен *vęzti означава „везам, бродирам, шия“.

На други славянски езици, например украински и чешки, думата за „превод“ – съответно „переклад“ и překlad – е съставена от корен, произлизащ от праславянската дума *ložiti, която пък идва от праиндоевропейската *logʰ-éye-ti, тоест „слагам, полагам, поставям“.

Идеята за формирането на немската Übersetzung и скандинавските översättning, oversættelse, oversettelse (съответно на шведки, датски и норвежки) е подобна, макар че всички те произлизат от прагерманския корен *satjaną, който също означава „поставям“.

На унгарски преводът е известен като fordítás, което се смята, че произлиза от прауралския корен *pürke- (*pᴕrγɜ-), тоест „въртя, обръщам”. Идеята за въртене се открива и в турския, където – както научих от едно интервю с преводача Азиз Шакир-Таш – думата за „превод“ (çeviri) споделя общ корен с „чеверме“.

В различните начини на формиране на думата на различните езици, разбира се, няма нищо необичайно. Тези различия обаче създават сериозни предизвикателства за същинския процес на превод, особено когато е важно смисловият заряд на корена от оригинала да се съхрани.

Преди време например, докато работех по текст на преводачката Василена Мирчева, посветен на баща ѝ Красимир Мирчев и озаглавен „Баща ми преводачът“, ми се наложи да преведа следните две изречения: „Баща ми е преводач, така пише на визитката му. Баща ми е от хората, които ще те преведат през пяната на дните, без да те лъжат, че ще излезеш оттам окъпан, но ще те научи да се гмуркаш за съкровища по дъното.“

В моя превод на английски, за съжаление, връзката между „преводач“ и „ще те преведат“ – които аз съм превела като translator и will carry you through – става почти изцяло незабележима. Загубата е налице, въпреки че английският превод също отразява етимологията на думата, формирана чрез представката trans (‘през’) и корен, произлизащ от латинското latus (минало причастие на ferre, тоест „нося, понасям”).

Заниманието с художествен превод постоянно води до такъв тип загуби, поради което преводачите често биват обвинявани в предателство.

Понякога обаче боговете на превода (или може би самият свети Йероним) са благосклонни и се случва така, че определен израз или фраза съвсем гладко и без усилия преминават от един език в друг – дори и когато тези езици не са близки.

Крилатата фраза „traduttore, traditore“ е идеален пример за това: първоначално появила се като определение от гневни италианци за (според тях нескопосаните) френски преводачи на Данте, тя – благодарение на споделения префикс между двете думи – в голяма степен запазва благозвучието си и на други, дори и далечни на италианския езици.

Английската „translator, traitor“ например е почти толкова алитеративна колкото италианската, а даже и българската „преводач, предател“ притежава известна доза мелодичност. На унгарски, в опит да се запази алитерацията, фразата понякога се предава по-свободно като „fordítás: ferdítés“, тоест „превод: изкривяване“.

Нещата стават още по-оплетени, когато вземем предвид и различните видове превод, които на български обикновено се обозначават доста прозаично като „писмен“ и „устен“, но в много други езици за тези дейности – както и за преводачите, които ги извършват – съществуват съвсем отделни думи.

Два примера ни разкриват любопитни етимологии: на немски писменият преводач се нарича Übersetzer, а устният – Dolmetscher, докато на шведски тези думи са съответно översättare и tolk. Както вече споменах, и в двата случая думите за писмен превод имат общ корен, означаващ „поставям“. Думите за устния обаче се различават. За немската Dolmetscher се смята, че е заимствана от праславянската *tъlmačь (оцеляла и на български като остарялата „тълмач“), която на свой ред произлиза от пратюркската *til, означаващ „език“ и в двата смисъла на думата. (Полската дума за преводач – tłumacz, споделя същия произход.)

Скандинавската дума за устен преводач – tolk, също – доста изненадващо! – има праславянски произход: думата *tъlkъ (това е коренът и на съвременния глагол „тълкувам“), а тя от своя страна произлиза от праиндоевропейската *telkʷ- и е сродна със санскритската तर्क (tarka, ‘предположение’), латинскaта loquor (‘говоря’) и староирландскиите do·tluchethar (‘питам’) и ad·tluchedar (‘благодаря’).

На английски и френски, докато писменият преводач се нарича translator/traducteur, устният е познат като interpreter/interprète. Втората двойка думи произлиза от латинската interpres ‘агент, брокер, обяснител, посредник’, която от своя страна е формирана от inter (‘между’) и pres, смята се, за корен на pretium (‘цена’) и се предполага, че е свързана със старогръцката φράζειν (phrázein ‘посочвам, показвам, обяснявам, декларирам, говоря’), от която произлизат и φραδή (phradḗ ‘разбиране, знание’) и φράσις (phrásis ‘фраза, израз, говор’).

Думата φράσις (phrásis) служи и като корен на гръцката дума за „(писмен) превод“: μετάφραση (metáfrasi). Както е известно, този термин е навлязъл и в други езици с леко изменено значение².

Сега се замислям, че ако гръцката дума за „превод“ беше формирана по модела на английската – на базата на корена „нося, понасям“ – тя щеше да звучи като μεταφορά (metaforá).

Освен като познатото ни стилистично средство в реториката, μεταφορά на гръцки също така означава чисто и просто „транспорт“. A етимологично погледнато, думата „транспорт“ – от латински, trans (‘през’) + portare (‘нося’) – се оказва нещо като калка, тоест буквален превод на „превод“.

Ето как в края на краищата се оказва, че преводът неизбежно е и пренос(ен). И въпреки първоначалните ми намерения да пиша по темата съвсем буквално, все пак достигнахме метафоричното – и то буквално.

Като голям застъпник на духа пред буквата свети Йероним със сигурност би одобрил.

1 Смята се, че праиндоевропейската *wedʰ-, освен на думата „водя“ и нейните сродни думи на другите славянски езици, е първоизточникът и на английските wed (‘венчавам’) и wage (‘водя, провеждам’, обикновено в комбинация с „война“).

2 Терминът „метафраза“ е навлязъл и в други езици, в които се използва като обозначение на буквален превод, тоест пренасяне на текста дума по дума и ред по ред, а също така и на превода на поезия в проза. Tова, с други думи, е вид превод, който свети Йероним не би одобрил. С право той се запитва: „Каква е ползата да се гони буквата, да се спори за грешките на пишещия или за хронологията, когато много ясно е казано, че буквата убива, а духът животвори.“


В рубриката „От дума на дума“ Екатерина Петрова търси актуални, интересни или новопоявили се думи от нашето ежедневие и проследява често изненадващия им произход, развитието на значенията им във времето и взаимовръзките им с близки и далечни езици.

Машаллах и „Банкси не се е появил в арабския свят“: Непознатите графити

Post Syndicated from Атанас Шиников original https://www.toest.bg/mashallah-i-banksi-ne-se-e-poiavil-v-arabskiya-svyat/

Наско, имам нужда от твоята помощ,

Машаллах и „Банкси не се е появил в арабския свят“: Непознатите графити

получавам преди време съобщение в служебната си поща. Поглеждам кой ми пише, и изтръпвам. Регионалният мениджър по сигурността за Източна Европа и Близкия изток. Никой не обича да си има вземане-даване със сигурността, дори и в ИТ сектора. Имат си репутация, подобна на отдел „Човешки ресурси“. Не е добре да те търсят просто ей така. 

Моля те, виж приложените снимки и ми кажи какво пише на тях. На арабски е и е от служебния паркинг. Ако може днес, че пътувам в командировка и ми е важно да знам. 

Аха, добре. Отварям снимката в приложението. Определено е на арабски. Графит с много несръчен, тромав и грозен почерк, ъгловати, удебелени букви, издраскан с нещо твърдо върху бетонната стена на паркинга. Много лоша снимка, с ниска осветеност. Увеличавам я и веднага прочитам. Не пише „Хамас“, особено актуално с оглед на последните събития около Израел, или „Освободете Палестина“, нито пише „Джихад“. Не е „Аллах“, нито пък нещо романтично, например „Али обича Фатима“. 

[Една определена анатомична част] на майка ти. 

Това пише. Толкоз. Ако трябва да перифразирам любим разказ за мухата в писоара, тук няма да видите снимките и да разберете какво точно казва надписът, защото на гнусливите читатели ще им прилошее. Напълно професионално отговарям на колегата. Натраквам „Привет“, следва буквален превод на надписа.

Пише това и това. Бъди здрав и пътувай спокойно! 

Но историята зад надписа ще остане загадка. Дали е бил някой като мен? Може да е носител на езика от ИТ тълпата, примерно агент от колцентъра, обслужващ Близкия изток. За кого е адресиран графитът? За чия майка става въпрос? Може пък да е просто спонтанен израз на порив към вандалство. Като българските надписи по Колизея. 

С графитите винаги е така – имат нужда от много контекст. И той обикновено липсва.

Ревниво крият историята си отвъд непосредственото впечатление. Нещо като фотографията, която паметува твърде малко отвъд непосредственото улавяне на образа. 

Та какво ви говори например този графит от Женския пазар в София? 

Машаллах и „Банкси не се е появил в арабския свят“: Непознатите графити
„Жена. Живот. Свобода.“ Надпис на арабски в района на Женския пазар © Личен архив

От кофите за боклук около Централните хали и синагогата е. Сигурно забелязвате червенобразни знаци с маркер, които говорят за екзотичността на района. Аз пък чета уверен, акуратен, окръглен, жив почерк с широк филцов маркер, около 10 мм. Пише три думи. 

Зан. Зендеги. Азади. Жена. Живот. Свобода. 

Лозунг от иранските протести през 2022 г. в знак за солидарност с жените там. Един от моментите, когато се усещаш въвлечен в много по-голяма картина от пазаруването на сок от нар, агнешко или дюнер от тази част на града.

Но отвъд това какво? Почти нищо. Като че ли идеята какво точно са графитите и какво ти казват, се изплъзва. Навсякъде са, предизвикват непосредствена реакция („Много грозно!“, „Вандализъм!“, „Виж колко интересно!“, „Леле, виж колко красиво!“, „Адски готин, суперсмарт“), но какво точно представляват? Малко като нещата, за които всички говорят, все едно се подразбират, но не успяват да определят същността им. Според общата ми култура „графити“ идвало от гръцкия корен на всичко, свързано с „писане“. Графити. Графеми. Графит. Графика. Калиграфия. Графология. Графомания. Сграфито. Нещо написано. 

Та не е ли същото и с арабския корен на всичко около писането – к-т-б?

Оттам идва и познатото ни арабско китаб, преминало в турския като китап. Книга, писание, документ, написано. И то като графитите е колкото устойчиво, толкова и изплъзващо се.

Конрад Хиршлер, един от любимите ми изследователи на арабската ръкописна традиция, сравнява понятието за книга при арабите с метафора, използвана от самия Мартин Лутер. Бащата на протестантската Реформация, твърди той, сравнявал Еразъм със „змиорка, която само Бог може да улови“. Е, такова, твърди Хиршлер, било и разбирането за книга при арабите. Дали е текстът, който върви под определено заглавие, или подвързаният между две корици кодекс от страници, остава напълно неясно.

Като гледаме графитите, оставаме със сходно впечатление за флуидност и преходност. Графити културата се движи от сенчестите пространства, в които се пръква, към помилваните от властта пространства на художествена себеизява. Присъщата маргиналност на графитите първоначално изглежда аксиоматична. Важи както за драсканиците на бандите в Ню Йорк през 70-те години на миналия век, така и за парижките графити, снимани от Брасай, този близък приятел на Пикасо. Издраскани лица, сърца, надписи, кръстове по улиците на Париж, променящи се с времето изображения – всичко това няма как да намери място в Лувъра, нито пък да бъде финансирано от някоя община. Не принадлежи към този пласт от художествената реалност. 

Но графитите лека-полека изпълзяват на светло. Катерят стълбицата от ниския, маргинален пласт на градското пространство до по-високите му етажи. Този преход бива капитализиран от градските управи, които усвояват досега пренебрегвани пространства и правят живота там малко по-поносим визуално. Но в момента, в който биват насила придърпани под прожекторите, губят част от характера си. „Благословията“ на публичната санкция лесно може да се превърне в „проклятие“. 

В природата на графитите е заложено тяхното спотайване в кьошетата на града. 

Приличат на маргиналните илюстрации в средновековните ръкописи на Запад или спираловидно завихрените бележки в арабските ръкописи, по Бринкли Месик и неговата „Калиграфска държава“. В момента, в който занаятът се официализира, той загубва същностен аспект. Престава да бъде част от културата на протеста, която го осмисля. Защото обезсилва оттласкването му от статуквото, чрез което той се определя. Уличната рисунка, обект на туризъм, може да привлича посетители, но именно заради комфорта, който предлага, тя престава да бъде „графит“.

Отделно съществуват и противоречията във връзката между художествено и политическо. „Смятам, че графитите се политизират твърде много, за мен е важно изкуството“, споделя с мен един от известните софийски артисти по време на уъркшоп в ателието си в София сред тълпа дечурлига. Но много негови колеги не мислят така. Всъщност мислят точно обратното. И политическите размирици около Арабската пролет, и протестите в Иран го показват. Както и случаят на местна почва с един Симон Варсано през 1989 г.

В рамките на тези спорни отношения гуруто на модерните графитъри, популярният (направо популистки) Банкси, някак арогантно е наседнал прехода между маргиналното и показно комерсиалното, между чисто художественото и политическото. Ако гледате Exit Through the Gift Shop, много лесно може да съзрете проблематичността в творци, за които протестът е част от внимателно граден и поддържан имидж. Банкси е колкото шампион на добре режисирани политически изяви, толкова и на комерсиални начинания като „Зазидания хотел“ в Газа, срещу стената, която отделя Израел от гетото. 

Възникват също въпроси около формата и жанра. Добре, наред с разнообразните тагове, бомбене, throw-ups, които се въртят около буквите, имаме и свързаните с тях, но отделни форми на улично изкуство. Лепене на плакати, стикери с изображения, шаблони. Големи пана със спрейове. Накрая идват и най-монументалните, обикновено създавани по поръчка градски стенописи върху фабрики, фасади на сгради. „Графити“ може да е всичко, стига да е върху стена.

Наложете върху тези противоречивости около графитите и контекста на непривично за нас общество, например Турция, Израел, Египет, Мароко. Добавете върху него и близкоизточен език, който не говорим. Резултатът е възел, пред чието теоретично разплитане човек лесно избира по-непосредствени удоволствия. Затова и вместо мъчителното бъхтене по потискащи интелектуални питания около дефинициите,

тук предлагам два напълно различни, но допълващи се погледа към арабските улични надписи. 

Първото е сблъсък със стар арабски текст. С изненада ще откриете, че в Близкия изток темата за графитите се проблематизира отпреди Банкси. Писането по стените вълнува литературното въображение на древните араби. Поне така личи по съчинения като „Книга за странниците“ от IX в. Приписвали я на големия Ал-Исфахани, повече известен чрез поетичния сборник „Книга на песните“. Пък дали е негова, знае само онзи, който можел да улови плъзгавия Еразъм. Обаче ето, казва авторът на книгата, събрал съм неща, чути или видени, поезия от хора, които пътуват, пришълци, които изповядват мъката по родните места или по възлюбените, като пишат за страданията си по стените на местата, през които минават. Звучи едновременно загадъчно и вандалско, екзотично някак, хем напудрено, хем извън общоприетата норма, почти като приказка от „Хиляда и една нощ“. 

И какво представляват драсканиците по стените от арабския IX век?

Представете си ги на вид почти като драсканиците на арабица по колоните на църквата „Св. Четиридесет мъченици“ във Велико Търново (да, такива има), но поетични. Защото човекът от онова време не се задоволява с простото изписване на пословичното трибуквие или вечното „Аз бях тук“. Няма надписи срещу властта. Не следват стилистиката и съдържанието на тоалетния надпис от „Дома на киното“ в София, където анонимен активист е оставил следа, подканваща към социален дебат.

Машаллах и „Банкси не се е появил в арабския свят“: Непознатите графити
© Личен архив

Като че ли вечната тема на този архив от надписи по манастири, кръчми, джамии, пазари е самотата и загубеното щастие. Пътуването по време на Абасидския халифат може да е нещо обичайно – хората пътуват „в търсене на религиозното знание“ (талаб ал-‘илм), по търговски дела, в дирене на препитание, на религиозни поклонения из светите места – Мека, Медина, Йерусалим. Но усещането за отчуждение не изчезва.

Времето, за което арабският език използва различни думи – най-разпространеното заман, но също и „дните“ (ал-аййам), „нощите“ (ал-лайали), „съдбата“ (дахр, ал-кадар), – неумолимо изтича и завлича със себе си и пътешественика. То е и главният виновник за носталгията човешка. Eто, разказвал Ал-Асмаи, известен филолог и поет, минах покрай една скала, докато пътешествах, и на нея беше надраскано следното:

Всяка страна е страна на човека, но той не е на никоя ближен,

та възкликнал: авторът на тоя стих със сигурност ще си умре пришълец! 

Около надписите се разгръщат цели истории, понякога на ръба на общоприетия морал, че направо и отвъд него. В манастирите девойки оставят надписи по стените, прелюдия към съблазняване на мюсюлманските пътешественици. Араби драскат меланхолични стихове по портите на християнски олтари. Благочестиви поклонници пишат имената си и набожни стихове не къде да е, а по минаретата. Халифът Ал-Мутауаккил пиянства с черковно вино в компанията на красавица. А пък самият Ал-Исфахани изповядва хомосексуална афера, в която поетични графити, надраскани по врати и стени, играят ролята на сантиментално обяснение в любов. 

Не мога да пропусна и историята за някой си Абу ал-Хинди, който влязъл при винопродавец в място, наречено Куи Заян, което пък значело „Улица на покварата“. Уж бил в компания, разказва старият арабски текст, ама подранил и от сабахлем наченал да винопийства. Както казваше баща ми, „направил главата“ без време и заспал. Приятелите му разбрали какво е сторил, и решили да го последват. Пили, пили, докато и те не заспали. Абу ал-Хинди се събудил, видял ги и на свой ред попитал какво става. Разбрал и си рекъл: дай и аз да направя същото. И така минали десет дни. Дошло време Абу ал-Хинди да си тръгне и поканил приятелите си най-после да пият заедно. „Желаем го повече и от теб!“, та пили заедно един последен ден. Накрая, като си тръгнал, надраскал върху стената на мястото, където били отседнали, поема в чест на паметното преживяване. 

Машаллах и „Банкси не се е появил в арабския свят“: Непознатите графити
Илюстрация от „Макамите“ на Ал-Харири (поч. 1122)

Без съмнение, от подобни разкази лъха на известен литературен произвол. Скептикът в мен, който винаги изхожда от позицията „Да бе, верно ли!“, може да си каже: „Добре де, отгде да знам, че Ал-Исфахани не си го е измислил?“. Та не е ли вярно, че арабските историци постоянно си измислят истории? Измислят си всичко, дори и доказателства за казаното от Пророка Мохамед. И все пак винаги стои възможността поне част от историите в „Странниците“ да бъдат основани на реални събития, разкази, наблюдения. Периодът е запазил подобни надписи и откъм техника, и откъм жанр, ако вярваме на изследователската литература. Както обичат да обобщават мюфтиите след всяко отсъждане, „Аллах знае най-добре“. Но със сигурност можем да твърдим, че преходната природа на написаното по стените влиза в полезрението на арабите поне от десетото столетие насам. 

(Следва продължение.)


В рубриката „Ориент кафе“ Атанас Шиников поднася любопитни теми, свързани не толкова с горещата политика, колкото с историята и културата на Близкия изток. А той, древен и днешен, е по-близко до нас и съвремието ни, отколкото си представяме.

What does AI mean for computing education?

Post Syndicated from Philip Colligan original https://www.raspberrypi.org/blog/what-does-ai-mean-for-computing-education/

It’s been less than a year since ChatGPT catapulted generative artificial intelligence (AI) into mainstream public consciousness, reigniting the debate about the role that these powerful new technologies will play in all of our futures.

A person in front of a cloudy sky, seen through a refractive glass grid. Parts of the image are overlaid with a diagram of a neural network.
Image: Alan Warburton / © BBC / Better Images of AI / Quantified Human / CC-BY 4.0

‘Will AI save or destroy humanity?’ might seem like an extreme title for a podcast, particularly if you’ve played with these products and enjoyed some of their obvious limitations. The reality is that we are still at the foothills of what AI technology can achieve (think World Wide Web in the 1990s), and lots of credible people are predicting an astonishing pace of progress over the next few years, promising the radical transformation of almost every aspect of our lives. Comparisons with the Industrial Revolution abound.

At the same time, there are those saying it’s all moving too fast; that regulation isn’t keeping pace with innovation. One of the UK’s leading AI entrepreneurs, Mustafa Suleyman, said recently: “If you don’t start from a position of fear, you probably aren’t paying attention.”

In a computing classroom, a girl looks at a computer screen.
What is AI literacy for young people?

What does all this mean for education, and particularly for computing education? Is there any point trying to teach children about AI when it is all changing so fast? Does anyone need to learn to code anymore? Will teachers be replaced by chatbots? Is assessment as we know it broken?

If we’re going to seriously engage with these questions, we need to understand that we’re talking about three different things:

  1. AI literacy: What it is and how we teach it
  2. Rethinking computer science (and possibly some other subjects)
  3. Enhancing teaching and learning through AI-powered technologies

AI literacy: What it is and how we teach it

For young people to thrive in a world that is being transformed by AI systems, they need to understand these technologies and the role they could play in their lives.

In a computing classroom, a smiling girl raises her hand.
Our SEAME model articulates the concepts, knowledge, and skills that are essential ingredients of any AI literacy curriculum.

The first problem is defining what AI literacy actually means. What are the concepts, knowledge, and skills that it would be useful for a young person to learn?

The reality is that — with a few notable exceptions — the vast majority of AI literacy resources available today are probably doing more harm than good.

In the past couple of years there has been a huge explosion in resources that claim to help young people develop AI literacy. Our research team mapped and categorised over 500 resources, and undertaken a systematic literature review to understand what research has been done on K–12 AI classroom interventions (spoiler: not much). 

The reality is that — with a few notable exceptions — the vast majority of AI literacy resources available today are probably doing more harm than good. For example, in an attempt to be accessible and fun, many materials anthropomorphise AI systems, using human terms to describe them and their functions and thereby perpetuating misconceptions about what AI systems are and how they work.

A real banana and an image of a banana shown on the screen of a laptop are both labelled "Banana".
Image: Max Gruber / Better Images of AI / Ceci n’est pas une banane / CC-BY 4.0

What emerged from this work at the Raspberry Pi Foundation is the SEAME model, which articulates the concepts, knowledge, and skills that are essential ingredients of any AI literacy curriculum. It separates out the social and ethical, application, model, and engine levels of AI systems — all of which are important — and gets specific about age-appropriate learning outcomes for each. 

This research has formed the basis of Experience AI (experience-ai.org), a suite of resources, lessons plans, videos, and interactive learning experiences created by the Raspberry Pi Foundation in partnership with Google DeepMind, which is already being used in thousands of classrooms.

If we’re serious about AI literacy for young people, we have to get serious about AI literacy for teachers.

Defining AI literacy and developing resources is part of the challenge, but that doesn’t solve the problem of how we get them into the hands and minds of every young person. This will require policy change. We need governments and education system leaders to grasp that a foundational understanding of AI technologies is essential for creating economic opportunity, ensuring that young people have the mindsets to engage positively with technological change, and avoiding a widening of the digital divide. We’ve messed this up before with digital skills. Let’s not do it again.

Two smiling adults learn about computing at desktop computers.
Teacher professional development is key to AI literacy for young people.

More than anything, we need to invest in teachers and their professional development. While there are some fantastic computing teachers with computer science qualifications, the reality is that most of the computing lessons taught anywhere on the planet are taught by a non-specialist teacher. That is even more so the case for anything related to AI. If we’re serious about AI literacy for young people, we have to get serious about AI literacy for teachers. 

Rethinking computer science 

Alongside introducing AI literacy, we also need to take a hard look at computer science. At the very least, we need to make sure that computer science curricula include machine learning models, explaining how they constitute a new paradigm for computing, and give more emphasis to the role that data will play in the future of computing. Adding anything new to an already packed computer science curriculum means tough choices about what to deprioritise to make space.

Elephants in the Serengeti.
One of our Experience AI Lessons revolves around the us of AI technology to study the Serengeti ecosystem.

And, while we’re reviewing curricula, what about biology, geography, or any of the other subjects that are just as likely to be revolutionised by big data and AI? As part of Experience AI, we are launching some of the first lessons focusing on ecosystems and AI, which we think should be at the heart of any modern biology curriculum. 

Some are saying young people don’t need to learn how to code. It’s an easy political soundbite, but it just doesn’t stand up to serious scrutiny.

There is already a lively debate about the extent to which the new generation of AI technologies will make programming as we know it obsolete. In January, the prestigious ACM journal ran an opinion piece from Matt Welsh, founder of an AI-powered programming start-up, in which he said: “I believe the conventional idea of ‘writing a program’ is headed for extinction, and indeed, for all but very specialised applications, most software, as we know it, will be replaced by AI systems that are trained rather than programmed.”

Computer science students at a desktop computer in a classroom.
Writing computer programs is an essential part of learning how to analyse problems in computational terms.

With GitHub (now part of Microsoft) claiming that their pair programming technology, Copilot, is now writing 46 percent of developers’ code, it’s perhaps not surprising that some are saying young people don’t need to learn how to code. It’s an easy political soundbite, but it just doesn’t stand up to serious scrutiny. 

Even if AI systems can improve to the point where they generate consistently reliable code, it seems to me that it is just as likely that this will increase the demand for more complex software, leading to greater demand for more programmers. There is historical precedent for this: the invention of abstract programming languages such as Python dramatically simplified the act of humans providing instructions to computers, leading to more complex software and a much greater demand for developers. 

A child codes a Spiderman project at a laptop during a Code Club session.
Learning to program will help young people understand how the world around them is being transformed by AI systems.

However these AI-powered tools develop, it will still be essential for young people to learn the fundamentals of programming and to get hands-on experience of writing code as part of any credible computer science course. Practical experience of writing computer programs is an essential part of learning how to analyse problems in computational terms; it brings the subject to life; it will help young people understand how the world around them is being transformed by AI systems; and it will ensure that they are able to shape that future, rather than it being something that is done to them.

Enhancing teaching and learning through AI-powered technologies

Technology has already transformed learning. YouTube is probably the most important educational innovation of the past 20 years, democratising both the creation and consumption of learning resources. Khan Academy, meanwhile, integrated video instruction into a learning experience that gamified formative assessment. Our own edtech platform, Ada Computer Science, combines comprehensive instructional materials, a huge bank of questions designed to help learning, and automated marking and feedback to make computer science easier to teach and learn. Brilliant though these are, none of them have even begun to harness the potential of AI systems like large language models (LLMs).

The challenge for all of us working in education is how we ensure that ethics and privacy are at the centre of the development of [AI-powered edtech].

One area where I think we’ll see huge progress is feedback. It’s well-established that good-quality feedback makes a huge difference to learning, but a teacher’s ability to provide feedback is limited by their time. No one is seriously claiming that chatbots will replace teachers, but — if we can get the quality right — LLM applications could provide every child with unlimited, on-demand feedback. AI-powered feedback — not giving students the answers, but coaching, suggesting, and encouraging in the way that great teachers already do — could be transformational.

Two adults learn about computing at desktop computers.
The challenge for all of us working in education is how we ensure that ethics and privacy are at the centre of the development of AI-powered edtech.

We are already seeing edtech companies racing to bring new products and features to market that leverage LLMs, and my prediction is that the pace of that innovation is going to increase exponentially over the coming years. The challenge for all of us working in education is how we ensure that ethics and privacy are at the centre of the development of these technologies. That’s important for all applications of AI, but especially so in education, where these systems will be unleashed directly on young people. How much data from students will an AI system need to access? Can that data — aggregated from millions of students — be used to train new models? How can we communicate transparently the limitations of the information provided back to students?

Ultimately, we need to think about how parents, teachers, and education systems (the purchasers of edtech products) will be able to make informed choices about what to put in front of students. Standards will have an important role to play here, and I think we should be exploring ideas such as an AI kitemark for edtech products that communicate whether they meet a set of standards around bias, transparency, and privacy. 

Realising potential in a brave new world

We may very well be entering an era in which AI systems dramatically enhance the creativity and productivity of humanity as a species. Whether the reality lives up to the hype or not, AI systems are undoubtedly going to be a big part of all of our futures, and we urgently need to figure out what that means for education, and what skills, knowledge, and mindsets young people need to develop in order to realise their full potential in that brave new world. 

That’s the work we’re engaged in at the Raspberry Pi Foundation, working in partnership with individuals and organisations from across industry, government, education, and civil society.

If you have ideas and want to get involved in shaping the future of computing education, we’d love to hear from you.


This article will also appear in issue 22 of Hello World magazine, which focuses on teaching and AI. We are publishing this new issue on Monday 23 October. Sign up for a free digital subscription to get the PDF straight to your inbox on the day.

The post What does AI mean for computing education? appeared first on Raspberry Pi Foundation.

Откъси от Украйна: Тогава тихичко се появи страхът…

Post Syndicated from original https://www.toest.bg/otkusi-ot-ukrayna-togava-tihichko-se-poyavi-strahut/

<< Към втора част

Откъси от Украйна: Тогава тихичко се появи страхът...

Дулото на танка сочи точно срещу изхода на метрото. Залива го пелена от проливен дъжд. Майданът и булевардът до него са притихнали под тежестта на сиви облаци и военна техника. Подготовката за парада на пленени руски бойни машини от сегашната война на Русия срещу Украйна започва ден преди 24 август, Деня на независимостта на Украйна. Дъждът в Киев полека-лека спира и мога да разгледам всичко по-отблизо.

Много от военните машини са обгорели, някои са без покриви, на трети има надписи: „Азов“, „Зарубежна“ (Чуждестранен), „ За Харкiв“ – с нарисувано до надписа сърце, „Никополь не бьi забуди“ (Никога не забравяйте Никопол), „Слава Україні“, „Дніпро“, „Руский иди на хуй“. Някои надписи са върху бетонни плочи, закрепени на танка. Вероятно са част от сграда или от нещо друго, взето от мястото, където танкът е рушил и убивал. Буквите са изкривени, набързо надраскани, задъхани и разтреперени.

Опитвам се да си представя ръцете, писали по тези танкове. Трескавия поглед. Страха, примесен с радостта от малката победа. Как изглеждат мъжете, пленили танка и изписали думи върху грозното му тяло.

Какъв мирис само има на фронта, направо воня! Но как да е другояче? Можехме да перем дрехите си само в някоя река. Нямахме вода за къпане, а беше лято. Къде ти сапун – търкаш си дрехите с камъни. Обличаш ги мокри, а наоколо всичко гори – каучук от гуми, човешки тела, поляните, горите. Навсякъде има пожари от стрелбата. Всичко гори. Миризмата е ужасна и прониква в дрехите ти, в тялото ти. Смърдиш целият на риба и огън.

Саша е ранен на фронта през лятото тази година. Очите му се движат бързо наляво-надясно. Прилича на тик. Пристъпва от крак на крак и ясно личи, че единият е по-къс от другия. Костта му е раздробена от куршум по време на бой. Сега на мястото на липсващата кост има метална пластина.

Представата ми за ветеран винаги е била за възрастен мъж със спомени от далечни времена, които никога няма да се върнат. Саша е висок, едър, с рехава черна брада.

Ветеран от настоящата война в Украйна, само на двайсет и четири години.

Володимир е на трийсет и пет. Запознахме се във Виница. И той е ветеран.

Въпросът за войната е много сложен. Как се чувства човек? Първо е страх и неразбиране. Когато тръгнахме, на една улица тлъст полицай ни отдаваше чест, докато колоната ни, километри дълга, преминаваше покрай него. В същото време ни махаха и жени с леко поведение. Горди бяхме, че щом и полицаят, и проститутките разбират къде отиваме, значи, ето ни! Но колкото повече се приближаваш към фронтовата линия и виждаш разрушенията, започваш да разбираш, че тук не е, както си си го представял, докато ти махат и отдават чест. Тогава тихичко, лично в мен, се появи страхът – какво ще бъде, как ще бъде…

Саша се сражава в Купянска, Миколаевска и Харкивска област. Губи най-близките си приятели на фронта. Те също са били момчета като него. Най-младият – на двайсет и една, най-възрастният – на двайсет и осем. Всички са убити по време на сраженията.

Единият загина от куршум и излезе късметлия, защото другия го разкъса мина и половин месец правиха ДНК експертиза, за да се разбере той ли е, или не е той. Просто нямаше достатъчно от тялото му, за да се направи експертизата, събирахме го на парчета. Друг мой приятел пък изгоря и също едва установиха кой е, защото беше сирак и нямаше от кого да се вземе ДНК. Едва намериха някакъв роднина, за да сравнят пробите и да разберат…

Според Саша двамата му приятели, разкъсани на фронта, са едва ли не щастливци, защото са успели да ги идентифицират. Тези, които не могат да бъдат разпознати, се водят безследно изчезнали в боя и семействата им не получават компенсация.

Пазим остатъците от вещите им и само си спомняме за тях. Толкоз.

Столът лекичко изскърцва, Володимир се намества в него и издишва дима от цигарата си. Изучава ме внимателно, сякаш се опитва да прозре колко от разказа му мога наистина да разбера. Започва бавно:

Пристигнахме на местоназначението. Момчетата, които сменихме, бързо-бързо си събраха нещата и си тръгнаха. И ние: „А..? Какво става..?“ Тези, които останаха, ни разказаха, че преди дни е имало няколко силни обстрела точно на нашите позиции. Бяха ни инструктирали, че веднага щом започнат взривове, трябва да се скрием, и затова ние постоянно тичахме. Щом чуехме непознат звук, падахме по очи. Пристигна втората група момчета. Имаше тревога „въздух“. След отбоя усетихме силна миризма на фекалии. Не разбрахме откъде идва. Излязохме от окопа и видяхме как едно момче седи до кръста във фекалии. Питаме го: какво правиш, какво е това? Той отговаря: аз току-що пристигнах и ми казаха, че при команда „нападение от въздуха“ трябва незабавно да скоча в някоя дълбока дупка, но никой не ми каза, че тази дупка е тоалетна. Смяхме се много, но това беше защитна реакция, защото след малко пак започна обстрел и усетихме какво е в действителност към теб да летят мини. Мой приятел го събрахме на части, в торба, защото върху него падна мина. В този момент разбираш, че истинската война не е като във филмите с Рамбо. В съзнанието ти изплува, че във всеки един момент би могло да…

Саша лекичко докосва крака си с ръка. Убеден е, че най-голямата трагедия е за тези момчета, които остават осакатени за цял живот, с откъснати от мините крака и ръце.

Да, живи са, но какъв живот е за човек на двайсет години това да е осакатен по този начин. Без крака, без ръце. Как ще си намери момиче, как ще живее, кой би се грижил за него?

На фронта постоянно те връхлитат черни мисли,

казва ми Володимир, докато поглежда телефона си. Изключва го и продължава:

Нашата част беше обкръжена. Тогава, за да преодолеем страха, започваме да правим различни полезни неща. Копаем окопи, почистваме оръжията, пишем писма, разговаряме с неправителствени организации. И през цялото време не спираме да се поддържаме един друг с думи, за да не зациклим върху това, което ни заобикаля, и максимално да потиснем емоциите.

Гледам този висок, хубав мъж и си представям, че съм негова майка, сестра, любима – какво ли бих почувствала, докато чета редовете, в които ми пише, че върху него падат бомби, приятелят му е разкъсан от мина, частта му е обкръжена и не е ясно дали ще оцелее, или ще го пленят. Какво ли бих му отговорила? Как бих го окуражила? Той ще ми повярва ли, знаейки, че докато преживява всичко това, аз съм в някой град, където животът все пак продължава.

Предадоха ни, че са нападнали наш пост. Чувахме картечници. Ние бяхме назад в кръгова отбрана. Имахме далекобойни оръдия, но за да стигнем до тях, трябваше да минем през минно поле. Това е преломен момент за психиката – да превъзмогнеш страха, защото си наясно, че ако настъпиш мината – край. В същото време обаче трябва да тичаш към оръжието. Каквото и да ти се случва, каквото и да ти се наложи да направиш, знаеш, че трябва да си свършиш работата. Стигнахме до оръжията, заехме позиция. В това време пристигна и нашият БТР, който ни помогна. Всичко приключи много бързо. Седнахме, запалихме по цигара и един от по-възрастните войници ни каза: „Браво, мъже! Рискът за живота е този повратен момент, който ви прави не просто войници, а военни, които могат да воюват.“

Виждам, че Саша е притеснен. Сякаш иска да сподели нещо, което смята, че няма да ми хареса. Казвам му да говори спокойно, защото, ако някой е държал в ръцете си разкъсания труп на свой приятел, има право да каже всичко, дори и да не ми хареса. Той се усмихва по детски и започва да говори бързо.

За мен е много важно да кажа, че това, дето се твърди, че руснаците не могат да воюват, не е вярно. Те могат да воюват добре, колкото и да ми е неприятно да го призная. Освен това ни превъзхождат числено. Ако при една битка от техните загинат двайсет души, веднага на тяхно място идват нови двайсет, и нови, и нови… При нас не е така. За тях загубата на двайсет души не е нищо. За нас е много. Затова и се грижим за хората си повече, но пак не е достатъчно.

Притихва. Гледа ме изпитателно и малко виновно. Търси в мен упрека. Не го намира. Добива кураж и продължава:

Освен това тяхната военна индустрия работи, и то явно добре, защото гилзите, които падаха при нас, бяха с дата от тази година, значи са направени сега. Страната им е много голяма и очевидно всички работят сега за фронта. Нашите заводи не могат да смогнат да произведат такова количество оръжия и ако нямаме помощ от НАТО и ЕС, не знам какво би станало.

Откъси от Украйна: Тогава тихичко се появи страхът...
© Николета Атанасова

Мълчим и се гледаме около минута, без да знам какво да му кажа. Той пристъпва и се поклаща. Кракът го боли. Предлагам му да седнем. Отказва. Тогава споделя с мен още една своя тревога. Викат го отново на военна комисия, за да го върнат на фронта. Саша се притеснява, че кракът му няма да издържи, защото пластината в него е от метал, който не е медицински, а и не е поставена както трябва. Оперирали са го при полеви условия. Някои от лекарите му казали, че само да скочи или да се затича, пластината, която свързва костта му, може да се счупи. Други обаче го посъветвали, ако се счупи, да си върже крака с колана. Докато ми разказва това, тялото му сякаш се смалява и прегърбва. Преживява всяка своя дума. Тревожи се за две неща. Едното е, че някой може да го помисли за страхливец. Другото – че металната пластина може да не издържи в боя, когато се върне там.

Саша се надява, ако отново отиде да се сражава, да е пак в артилерията, откъдето се връща. Защото в пехотата боевете се водят много отблизо, а окопите на двете страни са на десет метра разстояние един от друг.

Виждат се очи в очи и си мятат един на друг гранати. Това е някакъв кошмар.

За университета, в който е учил до началото на войната, вече не мечтае, защото не знае дали ще оцелее. Въпреки всичко Саша не се съмнява, че Украйна ще победи. Почти въпросително ми казва:

Но кога ще се случи това и колко още човешки животи ще коства…

Тревожи се, че доброволците за фронта намаляват и ще се наложи задължителна мобилизация.

Даваме много жертви и това ще обърне нещата към лошо, защото каква ще е тази армия с войници, които са изпратени на фронта насила? Войната трябва да приключи, преди да са свършили тези, които отиват да воюват като доброволци.

Володимир е убеден, че ще се върне на фронта, където е и по-големият му брат.

Знам и съм готов. Мъжете в Украйна днес разбират, че рано или късно всички ще трябва да воюват. Защото факторите войната да спре са твърде много и не вярвам да сработят. Този конфликт не го създава само един човек. И тях никой не ги кара насила да ни убиват, нали? Руснаците могат и да се предадат, ако не искат да ни убиват. Тоест и в главите на войниците трябва нещо да се случи, както и в тяхното правителство и командване.

С Володимир говорим дълго за преживяванията на момчетата, когато се върнат от фронта. Според него това е много тежък период, защото войната променя хората страшно много.

Ценности като „не убивай“, „хуманност“, „добрина“ се заличават. Войната ги изтрива. Каквото и да си чувствал преди, спираш да го чувстваш, защото чувства по време на война не може да има, не съществуват. Всичко се заличава.

Володимир разказва, че след като се завърнат от фронта, много негови приятели искат да се самоубият, а някои дори са се самоубили, защото съпругите им не разбират промяната в тях и ги напускат заедно с децата им. Или пък всеки ден пристигат вести за загинали на фронта техни приятели.

Те губят смисъл и доверие в цивилния свят. Чувстваш се сам и се питаш: а какво следва оттук нататък? Какво? Но искам да ви кажа, че войната е най-ужасното нещо, което може да ти се случи, и в същото време е най-прекрасното, защото ти се иска да се върнеш там. Тя е като наркотик. Да, там е тежко, но когато се прибереш в цивилния живот, си мислиш, че на фронта ти е по-добре, защото там разбираш всичко, там всичко ти е ясно и много просто. Има враг. Ти го убиваш – или той теб. Това е.

Мълча и за пореден път не знам какво да кажа. Толкова много болка има в тези момчета, толкова много тъга и в същото време такава решителност. Питам Володимир как му изглеждат Европа и останалият свят, докато е на бойното поле, под обстрела на ракетите.

Преди се ядосвах много, защото, за съжаление, Европа не разбира, че те няма да спрат до нас и ако превземат Украйна, ще продължат нататък. Кой и какво ще им попречи? Никой. Дори и аз не си помислях, че ще стигнат дотук, преди да започнат пълномащабната война. Но не, те се оказаха такива идиоти, че от тях явно може да се очаква всичко. Илюзия е, че страни от ЕС или НАТО са защитени, защото от руснаците може да се очаква абсолютно всичко. Най-ужасно е, че има хора в Европа, които не разбират как това не е само наша битка. Ние пазим безопасността на всички близки европейски страни.

Според Володимир най-страшното би било, ако Русия превземе Украйна.

Ще започнат да промиват мозъците и на украинците, които живеят тук, и ще стане така, че в един момент украинци ще воюват против Европа. Защото ако ни превземат, те ще ни заставят да воюваме за тях. А Европа си седи спокойно и си мисли: „Е, това се случва някъде там. Не е у дома. Защо трябва да им давам каквото и да било, ако са толкова далеч?“ На нас ни трябват още много оръжия, включително далекобойни, трябва ни ПВО, за да освободим територията си. А после ще построим такава граница, че те никога повече да не припарят тук. Трябва да се разбере и в Европа, и тук, че има враг и трябва да го спрем по всякакъв начин. Защото ако Украйна не ги спре, те ще продължат нататък и ще се опитат да провалят живота на всички. Знам, че във вашата страна има купени политици, които лъжат хората – не в името на благополучието на вашия народ, а по други причини. Откъде извират всички тези глупости за плоската земя, антиваксърските теории или за всемирния заговор и колективния Запад? От Русия идват и това не води до нищо добро. Трябва да го знаете.

Откъси от Украйна: Тогава тихичко се появи страхът...
Володимир Скосогоренко © Николета Атанасова

В Киев вече е тъмно. Върху платформата на огромен камион лежи танк. Голям кран бавно го стоварва на площада до другите.

Момченце на около пет години пита баща си: „Татко, татко, какво е това?“ Баща му отговаря: „Това е танковоз.“

Била съм в подножието на танк само в музей. Зловещо е. Знаеш обаче, че това е било в предишни, далечни времена и когато си тръгнеш от музея, нищо не те грози. Тези танкове на Майдана в Киев са воювали току-що срещу Украйна. Разрушавали са градове, училища, убивали са невинни хора и деца насред Европа през ХХI век. Мисля си защо му е на малкото дете да научава дума като „танковоз“. Колко още ще му се налага да я чува и използва? Докато стане достатъчно голямо, за да воюва?

Време е да тръгваме, наближава комендантският час. Звъня на Юлия, доброволка, която носи помощи до фронтовата линия. Искам да се срещнем на другия ден във Виница. Разбира се, телефонният оператор се включва с вече познатото:

Моля, изчакайте. Абонатът говори за победата.

Вървим бавно към хотела. Сирени. Вибриращ телефон. Стрелки по тротоара сочат към „убежище“. Някак ми е все едно. Няма да се крием. Просто продължаваме по чистите, блестящи улици на Киев.

Multiple Load Balance Support in AWS CodeDeploy

Post Syndicated from Brian Beach original https://aws.amazon.com/blogs/devops/multiple-load-balance-support-in-codedeploy/

AWS CodeDeploy is a fully managed deployment service that automates software deployments to various compute services, such as Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (ECS), AWS Lambda, and on-premises servers. AWS CodeDeploy recently announced support for deploying to applications that use multiple AWS Elastic Load Balancers (ELB). CodeDeploy now supports multiple Classic Load Balancers (CLB), and multiple target groups associated with Application Load Balancers (ALB) or Network Load Balancer (NLB) when using CodeDeploy with Amazon EC2. In this blog post, I will show you how to deploy an application served by multiple load balancers.

Background

AWS CodeDeploy simplifies deploying application updates across Amazon EC2 instances registered with Elastic Load Balancers. The integration provides an automated, scalable way to deploy updates without affecting application availability.

To use CodeDeploy with load balancers, you install the CodeDeploy agent on Amazon EC2 instances that have been registered as targets of a Classic, Application, or Network Load Balancer. When creating a CodeDeploy deployment group, you specify the load balancer and target groups you want to deploy updates to.

During deployment, CodeDeploy safely shifts traffic by deregistering instances from the load balancer, deploying the new application revision, and then re-registering the instances to route traffic back. This approach ensures application capacity and availability are maintained throughout the deployment process. CodeDeploy coordinates the traffic shift across groups of instances, so that the deployment rolls out in a controlled fashion.

CodeDeploy offers two deployment approaches to choose from based on your needs: in-place deployments and blue/green deployments. With in-place deployments, traffic is shifted to the new application revision on the same set of instances. This allows performing rapid, incremental updates. Blue/green deployments involve shifting traffic to a separate fleet of instances running the new revision. This approach enables easy rollback if needed. CodeDeploy makes it easy to automate either deployment strategy across your infrastructure.

Architectures with Multiple Load Balancers

CodeDeploy’s expanded integration with Elastic Load Balancing unlocks new deployment flexibility. Users can now register multiple Classic Load Balancers and multiple target groups associated with Application or Network Load Balancers. This allows you to deploy updates across complex applications that leverage multiple target groups. For example, many customers run applications that serve both an internal audience and external audience. Often, these two audiences require different authentication and security requirements. It is common to provide access to the internal and external audiences through different load balancers, as shown in the following image.

Architecture showing two load balancers, one external facing and one internal facing

In the past, CodeDeploy only supported one load balancer per application. Customers running internal and external application tiers would have to duplicate environments, using separate EC2 instances and Amazon EC2 Auto Scaling groups for each audience. This resulted in overprovisioning and added overhead to manage duplicate resources.

With multiple load balancer support, CodeDeploy removes the need to duplicate environments. Users can now deploy updates to a single environment, and CodeDeploy will manage the deployment across both the internal and external load balancers. You simply select all the target groups used by your application, as shown in the following image.

CodeDeploy configuration showing two load balancers selected

This consolidated approach reduces infrastructure costs and operational complexity when automating deployments. CodeDeploy orchestrates the in-place or blue/green deployment across multiple load balanced target groups.

Migrating from a Classic Load Balancer

Many customers are migrating from Classic Load Balancers (CLB) to Application Load Balancers (ALB) or Network Load Balancers (NLB). ALB and NLB offer a more modern and advanced feature set than CLB, including integrated path-based and host-based routing, and native IPv6 support. They also deliver improved load balancing performance with higher throughput and lower latency. Other benefits include native integrations with AWS WAF, Shield, and Global Accelerator along with potential cost savings from requiring fewer load balancers. Overall, migrating to ALB or NLB provides an opportunity to gain advanced capabilities, better performance, tighter service integration, and reduced costs.

CodeDeploy’s new multi-target group capabilities streamline migrating from Classic Load Balancers (CLB) to Application or Network Load Balancers (ALB or NLB). Users can now deploy applications utilizing both legacy CLB and modern ALB or NLB in parallel during the transition. This enables gracefully testing integration with the new load balancers before fully cutting over. Once you verify that users have stopped using the CLB endpoint, you can delete the CLB.

During the transition period, CodeDeploy orchestrates deployments across the CLB and target groups tied to the ALB or NLB within a single automation. Users simply select the CLB and target groups of the new load balancer in the deployment group as shown in the following image.

CodeDeploy configuration showing a both a classic load balancer and target group selected

This consolidated approach lets CodeDeploy coordinate a staged rollout across CLB and ALB/NLB. With simplified management of multiple load balancers, CodeDeploy eases the critical process of modernizing infrastructure while maintaining application availability.

Conclusion

CodeDeploy’s expanded integration with Elastic Load Balancing allows more flexible application deployments. Support for multiple Classic Load Balancers and multiple target groups associated with Application or Network Load Balancers enables you to seamlessly update complex architectures on AWS. Whether you are consolidating disparate environments or migrating from Classic Load Balancers, CodeDeploy simplifies managing deployments across multiple load balanced tiers. To learn more, see Integrating CodeDeploy with Elastic Load Balancing in the AWS CodeDeploy Developer Guide or visit the CodeDeploy product page.

Enhance your security posture by storing Amazon Redshift admin credentials without human intervention using AWS Secrets Manager integration

Post Syndicated from Tahir Aziz original https://aws.amazon.com/blogs/big-data/enhance-your-security-posture-by-storing-amazon-redshift-admin-credentials-without-human-intervention-using-aws-secrets-manager-integration/

Amazon Redshift is a fully managed, petabyte-scale data warehouse service in the cloud. You can start with just a few hundred gigabytes of data and scale to a petabyte or more. Today, tens of thousands of AWS customers—from Fortune 500 companies, startups, and everything in between—use Amazon Redshift to run mission-critical business intelligence (BI) dashboards, analyze real-time streaming data, and run predictive analytics. With the constant increase in generated data, Amazon Redshift customers continue to achieve success in delivering better service to their end-users, improving their products, and running an efficient and effective business.

AWS Secrets Manager helps you manage, retrieve, and rotate database credentials, and natively supports storing database secrets for Amazon Relational Database Service (Amazon RDS), Amazon Aurora, Amazon Redshift, and Amazon DocumentDB (with MongoDB compatibility). We recommend you use Secrets Manager for storing Amazon Redshift user credentials because it allows you to configure safer secret rotation, customize fine-grained access control, and audit and monitor secrets centrally. You can natively use existing Secrets Manager secrets to access Amazon Redshift using the Amazon Redshift API and query editor.

Until now, you would have needed to configure your Amazon Redshift admin credentials in plaintext, or let Amazon Redshift generate credential for you. To store these credentials in Secrets Manager, you either needed to manually create a secret, or configure scripts with the credentials hardcoded or generated. Both options required a human to retrieve them. Amazon Redshift now allows you to create and store admin credentials automatically without a human needing to see the credentials. As part of this workflow, the admin credentials are configured to rotate every 30 days automatically. By reducing the need for humans to see the secret during configuration, you can increase the security posture of your Amazon Redshift data warehouse and improve the accuracy of your audit trails.

In this post, we show how to integrate Amazon Redshift admin credentials with Secrets Manager for both new and previously provisioned Redshift clusters and Amazon Redshift Serverless namespaces.

Prerequisites

Complete the following prerequisites before starting:

  1. Have admin privileges to create and manage Redshift Serverless namespaces or Redshift clusters.
  2. Have admin privileges to create and manage secrets in Secrets Manager.
  3. Optionally, have a Redshift Serverless namespace or a Redshift cluster to enable Secrets Manager integration.
  4. Optionally, have different AWS Key Management Service (AWS KMS) keys for credentials encryption with Secrets Manager.
  5. Have access to Amazon Redshift Query Editor v2.

Set up a new cluster using Secrets Manager

In this section, we provide steps to configure either a Redshift provisioned cluster or a Redshift Serverless workgroup with Secrets Manager.

Create a Redshift provisioned cluster

To get started using Secrets Manager with a new Redshift provisioned cluster, complete the following steps:

  1. On the Amazon Redshift console, choose Create cluster.
  2. Define the Cluster configuration and Sample data sections as needed.
  3. In the Database configurations section, specify your desired admin user name.
  4. To use Secrets Manager to automatically create and store your password, select Manage admin credentials in AWS Secrets Manager.
  5. You can also customize the encryption settings with your own AWS customer managed KMS key by creating a key or choosing an existing one. This is the key that is used to encrypt the secret in Secrets Manager. If you don’t select Customize encryption settings, an AWS managed key will be used as default.
  6. Provide the information in Cluster permissions and Additional configurations as appropriate and choose Create cluster.
  7. When the cluster is available, you can check the ARN of the secret containing the admin password on the Properties tab of the cluster in the Database configurations section.

Create a Redshift Serverless workgroup

To get started using Secrets Manager with Redshift Serverless, create a Redshift Serverless workgroup with the following steps:

  1. On the Amazon Redshift Serverless dashboard, choose Create workgroup.
  2. Define the Workgroup name, Capacity, and Network and security sections as appropriate and choose Next.
  3. Select Create a new namespace and provide a suitable name
  4. In the Database name and password section, select Customize admin user and credentials.
  5. Provide an admin user name.
  6. In the Admin password section, select Manage admin credentials in AWS Secrets Manager.
  7. You can also customize the encryption settings with your own AWS customer managed KMS key by creating a key or choosing an existing one. This is the key that is used to encrypt the secret in Secrets Manager. If you don’t select Customize encryption settings, an AWS managed key will be used as default.
  8. Provide the information in the Permissions and Encryption and security sections as appropriate and choose Next.
  9. Review the selected options and choose Create.
  10. When the status of the newly created workgroup and namespace is Available, choose the namespace.
  11. You can find the Secrets Manager ARN with admin credentials under General information.

Enable Secrets Manager for an existing Redshift cluster

In this section, we provide steps to enable Secrets Manager for an existing Redshift provisioned cluster or a Redshift Serverless namespace.

Configure an existing Redshift provisioned cluster

To enable Secrets Manager for an existing Redshift cluster, follow these steps:

  1. On the Amazon Redshift console, choose the cluster that you want to modify.
  2. On the Properties tab, choose Edit admin credentials.
  3. Select Manage admin credentials in AWS Secrets Manager.
  4. To use AWS KMS to encrypt the data, select Customize encryption options and either choose an existing KMS key or choose Create an AWS KMS key.
  5. Choose Save changes.
  6. When the cluster is available, you can check the ARN of the secret containing the admin password on the Properties tab of the cluster in the Database configurations section.

Configure an existing Redshift Serverless namespace

To enable Secrets Manager on an existing Amazon Redshift Serverless namespace, follow these steps:

  1. On the Amazon Redshift Serverless Dashboard, choose the namespace that you want to modify.
  2. On the Actions menu, choose Edit admin credentials.
  3. Select Customize admin user credentials.
  4. Select Manage admin credentials in AWS Secrets Manager.
  5. To use AWS KMS to encrypt the data, select Customize encryption settings and either choose an existing AWS KMS key or choose Create an AWS KMS key.
  6. Choose Save changes.
  7. When the namespace status is Available, you can see the Secrets Manager ARN under Admin password ARN in the General information section.

Manage secrets in Secrets Manager

To manage the admin credentials in Secrets Manager, follow these steps:

  1. On the Secrets Manager console, choose the secret that you want to modify.

Amazon Redshift creates the secret with rotation enabled by default and a rotation schedule of every 30 days.

  1. To view the admin credentials, choose Retrieve secret value.
  2. To change the secret rotation, choose Edit rotation.
  3. Define the new rotation frequency and choose Save.
  4. To rotate the secret immediately, choose Rotate secret immediately and choose Rotate.

Secrets Manager can be integrated with your application via the AWS SDK, which is available in Java, JavaScript, C#, Python3, Ruby, and Go. The supported language code snippet is available in the Sample code section.

  1. Choose the tab for your preferred language and use the code snippet provided in your application.

Restore a snapshot

New warehouses can be launched from both serverless and provisioned snapshots. You have the choice to configure the restored cluster to use Secrets Manager credentials, even if the source cluster didn’t use Secrets Manager, by following these steps:

  1. Navigate to either the Redshift snapshot dashboard for snapshots of provisioned clusters or the Redshift data backup dashboard for snapshots of serverless workgroups and choose the snapshot you’d like to restore from.
    On the provisioned snapshot dashboard, on the Restore snapshot menu, choose Restore to provisioned cluster or Restore to serverless namespace.

    On the serverless snapshot dashboard, on the Actions menu, under Restore serverless snapshot, choose Restore to provisioned cluster or Restore to serverless namespace.

    If you’re restoring to a serverless endpoint from either option, you will need to have the target serverless namespace configured in advance.
  1. If you’re restoring to a warehouse using a snapshot that doesn’t have Secrets Manager credentials configured, you can enable it in the Database configuration section of the snapshot restoration page by selecting Manage admin credentials in AWS Secrets Manager.
  2. You can also customize the encryption settings with your own AWS customer managed KMS key by creating a key or choosing an existing one. If you don’t select Customize encryption settings, an AWS managed key will be used as default.
  3. If the snapshot was taken from a cluster that was using Secrets Manager to manage its admin credentials and you’re restoring to a provisioned cluster, you can optionally choose to update the key used to encrypt credentials in Secrets Manager. Otherwise, if you’d like to use the same configuration as the source snapshot, you can choose the same key as before.
  4. After you configure all the necessary details, choose Restore cluster from snapshot/Save changes to launch your provisioned cluster, or choose Restore to write the snapshot data to the namespace.

Connect to Amazon Redshift via Query Editor v2 using Secrets Manager

To connect to Amazon Redshift using Query Editor v2, complete the following steps:

  1. On the Amazon Redshift console, choose the cluster that you want to connect to.
  2. On the Properties tab, locate the admin user and admin password ARN.
  3. Make a note of the ARN to be used in the later steps.
  4. At the top of the cluster details page, on the Query data menu, choose Query in query editor v2.
  5. Locate the Redshift cluster or Redshift Serverless workgroup you want to connect to and choose the options menu (three dots) next to its name, then choose Create connection.
  6. In the connection window, select AWS Secrets Manager.
  7. For Secret, choose the appropriate secret for your cluster.
  8. Choose Create connection.

Note that access to the secrets can be controlled by AWS Identity and Access Management (IAM) permissions.

The connection should be established to your cluster now and you will be able to see the database objects in your cluster as well as run queries against your cluster

Conclusion

In this post, we demonstrated how the Secrets Manager integration with Amazon Redshift has simplified storing admin credentials. It’s a simple-to-use feature that is available immediately and automates the important task of maintaining admin credentials and rotating them for your Redshift data warehouse. Try it out today and leave a comment if you have any questions or suggestions.


About the Authors

Tahir Aziz is an Analytics Solution Architect at AWS. He has worked with building data warehouses and big data solutions for over 15 years. He loves to help customers design end-to-end analytics solutions on AWS. Outside of work, he enjoys traveling and cooking.

Julia Beck is an Analytics Specialist Solutions Architect at AWS. She supports customers in validating analytics solutions by architecting proof of concept workloads designed to meet their specific needs.

Ekta Ahuja is a Senior Analytics Specialist Solutions Architect at AWS. She is passionate about helping customers build scalable and robust data and analytics solutions. Before AWS, she worked in several different data engineering and analytics roles. Outside of work, she enjoys baking, traveling, and board games.

Enabling highly available connectivity from on premises to AWS Local Zones

Post Syndicated from Macey Neff original https://aws.amazon.com/blogs/compute/enabling-highly-available-connectivity-from-on-premises-to-aws-local-zones/

This post is written by Leonardo Solano, Senior Hybrid Cloud SA and Robert Belson SA Developer Advocate.

Planning your network topology is a foundational requirement of the reliability pillar of the AWS Well-Architected Framework. REL02-BP02 defines how to provide redundant connectivity between private networks in the cloud and on-premises environments using AWS Direct Connect for resilient, redundant connections using AWS Site-to-Site VPN, or AWS Direct Connect failing over to AWS Site-to-Site VPN. As more customers use a combination of on-premises environments, Local Zones, and AWS Regions, they have asked for guidance on how to extend this pillar of the AWS Well-Architected Framework to include Local Zones. As an example, if you are on an application modernization journey, you may have existing Amazon EKS clusters that have dependencies on persistent on-premises data.

AWS Local Zones enables single-digit millisecond latency to power applications such as real-time gaming, live streaming, augmented and virtual reality (AR/VR), virtual workstations, and more. Local Zones can also help you meet data sovereignty requirements in regulated industries  such as healthcare, financial services, and the public sector. Additionally, enterprises can leverage a hybrid architecture and seamlessly extend their on-premises environment to the cloud using Local Zones. In the example above, you could extend Amazon EKS clusters to include node groups in a Local Zone (or multiple Local Zones) or on premises using AWS Outpost rack.

To provide connectivity between private networks in Local Zones and on-premises environments, customers typically consider Direct Connect or software VPNs available in the AWS Marketplace. This post provides a reference implementation to eliminate single points of failure in connectivity while offering automatic network impairment detection and intelligent failover using both Direct Connect and software VPNs in AWS Market place. Moreover, this solution minimizes latency by ensuring traffic does not hairpin through the parent AWS Region to the Local Zone.

Solution overview

In Local Zones, all architectural patterns based on AWS Direct Connect follow the same architecture as in AWS Regions and can be deployed using the AWS Direct Connect Resiliency Toolkit. As of the date of publication, Local Zones do not support AWS managed Site-to-Site VPN (view latest Local Zones features). Thus, for customers that have access to only a single Direct Connect location or require resiliency beyond a single connection, this post will demonstrate a solution using an AWS Direct Connect failover strategy with a software VPN appliance. You can find a range of third-party software VPN appliances as well as the throughput per VPN tunnel that each offering provides in the AWS Marketplace.

Prerequisites:

To get started, make sure that your account is opt-in for Local Zones and configure the following:

  1. Extend a Virtual Private Cloud (VPC) from the Region to the Local Zone, with at least 3 subnets. Use Getting Started with AWS Local Zones as a reference.
    1. Public subnet in Local Zone (public-subnet-1)
    2. Private subnets in Local Zone (private-subnet-1 and private-subnet-2)
    3. Private subnet in the Region (private-subnet-3)
    4. Modify DNS attributes in your VPC, including both “enableDnsSupport” and “enableDnsHostnames”;
  2. Attach an Internet Gateway (IGW) to the VPC;
  3. Attach a Virtual Private Gateway (VGW) to the VPC;
  4. Create an ec2 vpc-endpoint attached to the private-subnet-3;
  5. Define the following routing tables (RTB):
    1. Private-subnet-1 RTB: enabling propagation for VGW;
    2. Private-subnet-2 RTB: enabling propagation for VGW;
    3. Public-subnet-1 RTB: with a default route with IGW-ID as the next hop;
  6. Configure a Direct Connect Private Virtual Interface (VIF) from your on-premises environment to Local Zones Virtual Gateway’s VPC. For more details see this post: AWS Direct Connect and AWS Local Zones interoperability patterns;
  7. Launch any software VPN appliance from AWS Marketplace on Public-subnet-1. In this blog post on simulating Site-to-Site VPN customer gateways using strongSwan, you can find an example that provides the steps to deploy a third-party software VPN in AWS Region;
  8. Capture the following parameters from your environment:
    1. Software VPN Elastic Network Interface (ENI) ID
    2. Private-subnet-1 RTB ID
    3. Probe IP, which must be an on-premises resource that can respond to Internet Control Message Protocol (ICMP) requests.

High level architecture

This architecture requires a utility Amazon Elastic Compute Cloud (Amazon EC2) instance in a private subnet (private-subnet-2), sending ICMP probes over the Direct Connect connection. Once the utility instance detects lost packets to on-premises network from the Local Zone it initiates a failover by adding a static route with the on-premises CIDR range as the destination and the VPN Appliance ENI-ID as the next hop in the production private subnet (private-subnet-1), taking priority over the Direct Connect propagated route. Once healthy, this utility will revert back to the default route to the original Direct Connect connection.

On-premises considerations

To add redundancy in the on-premises environment, you can use two routers using any First Hop Redundancy Protocol (FHRP) as Hot Standby Router Protocol (HSRP) or Virtual Router Redundancy Protocol (VRRP). The router connected to the Direct Connect link has the highest priority, taking the Primary role in the FHRP process while the VPN router remain the Secondary router. The failover mechanism in the FHRP relies on interface or protocol state as BGP, which triggers the failover mechanism.

High level HA architecture for Software VPN

Figure 1. High level HA architecture for Software VPN

Failover by modifying the production subnet RTB

Figure 2. Failover by modifying the production subnet RTB

Step-by-step deployment

Create IAM role with permissions to create and delete routes in your private-subnet-1 route table:

  1. Create ec2-role-trust-policy.json file on your local machine:
cat > ec2-role-trust-policy.json <<EOF
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
EOF
  1. Create your EC2 IAM role, such as my_ec2_role:
aws iam create-role --role-name my_ec2_role --assume-role-policy-document file://ec2-role-trust-policy.json
  1. Create a file with the necessary permissions to attach to the EC2 IAM role. Name it ec2-role-iam-policy.json.
aws iam create-policy --policy-name my-ec2-policy --policy-document file://ec2-role-iam-policy.json
  1. Create the IAM policy and attach the policy to the IAM role my_ec2_role that you previously created:
aws iam create-policy --policy-name my-ec2-policy --policy-document file://ec2-role-iam-policy.json

aws iam attach-role-policy --policy-arn arn:aws:iam::<account_id>:policy/my-ec2-policy --role-name my_ec2_role
  1. Create an instance profile and attach the IAM role to it:
aws iam create-instance-profile –instance-profile-name my_ec2_instance_profile
aws iam add-role-to-instance-profile –instance-profile-name my_ec2_instance_profile –role-name my_ec2_role   

Launch and configure your utility instance

  1. Capture the Amazon Linux 2 AMI ID through CLI:
aws ec2 describe-images --filters "Name=name,Values=amzn2-ami-kernel-5.10-hvm-2.0.20230404.1-x86_64-gp2" | grep ImageId 

Sample output:

            "ImageId": "ami-069aabeee6f53e7bf",

  1. Create an EC2 key for the utility instance:
aws ec2 create-key-pair --key-name MyKeyPair --query 'KeyMaterial' --output text > MyKeyPair.pem
  1. Launch the utility instance in the Local Zone (replace the variables with your account and environment parameters):
aws ec2 run-instances --image-id ami-069aabeee6f53e7bf --key-name MyKeyPair --count 1 --instance-type t3.medium  --subnet-id <private-subnet-2-id> --iam-instance-profile Name=my_ec2_instance_profile_linux

Deploy failover automation shell script on the utility instance

  1. Create the following shell script in your utility instance (replace the health check variables with your environment values):
cat > vpn_monitoring.sh <<EOF
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: MIT-0
# Health Check variables
Wait_Between_Pings=2
RTB_ID=<private-subnet-1-rtb-id>
PROBE_IP=<probe-ip>
remote_cidr=<remote-cidr>
GW_ENI_ID=<software-vpn-eni_id>
Active_path=DX

echo `date` "-- Starting VPN monitor"

while [ . ]; do
  # Check health of main VPN Appliance path to remote probe ip
  pingresult=`ping -c 3 -W 1 $PROBE_IP | grep time= | wc -l`
  # Check to see if any of the health checks succeeded
  if ["$pingresult" == "0"]; then
    if ["$Active_path" == "DX"]; then
      echo `date` "-- Direct Connect failed. Failing over vpn"
      aws ec2 create-route --route-table-id $RTB_ID --destination-cidr-block $remote_cidr --network-interface-id $GW_ENI_ID --region us-east-1
      Active_path=VPN
      DX_tries=10
      echo "probe_ip: unreachable – active_path: vpn"
    else
      echo "probe_ip: unreachable – active_path: vpn"
    fi
  else     
    if ["$Active_path" == "VPN"]; then
      let DX_tries=DX_tries-1
      if ["$DX_tries" == "0"]; then
        echo `date` "-- failing back to Direct Connect"
        aws ec2 delete-route --route-table-id $RTB_ID --destination-cidr-block $remote_cidr --region us-east-1
        Active_path=DX
        echo "probe_ip: reachable – active_path: Direct Connect"
      else
        echo "probe_ip: reachable – active_path: vpn"
      fi
    else
      echo "probe:ip: reachable – active_path: Direct Connect"	    
    fi
  fi    
done EOF
  1. Modify permissions to your shell script file:
chmod +x vpn_monitoring.sh
  1. Start the shell script:
./vpn_monitoring.sh

Test the environment

Failover process between Direct Connect and software VPN

Figure 3. Failover process between Direct Connect and software VPN

Simulate failure of the Direct Connect link, breaking the available path from the Local Zone to the on-premises environment. You can simulate the failure using the failure test feature in Direct Connect console.

Bringing BGP session down

Figure 4. Bringing BGP session down

Setting the failure time

Figure 5. Setting the failure time

In the utility instance you will see the following logs:

Thu Sep 21 14:39:34 UTC 2023 -- Direct Connect failed. Failing over vpn

The shell script in action will detect packet loss by ICMP probes against a probe IP destination on premises, triggering the failover process. As a result, it will make an API call (aws ec2 create-route) to AWS using the EC2 interface endpoint.

The script will create a static route in the private-subnet-1-RTB toward on-premises CIDR with the VPN Elastic-Network ID as the next hop.

private-subnet-1-RTB during the test

Figure 6. private-subnet-1-RTB during the test

The FHRP mechanisms detect the failure in the Direct Connect Link and then reduce the FHRP priority on this path, which triggers the failover to the secondary link through the VPN path.

Once you cancel the test or the test finishes, the failback procedure will revert the private-subnet-1 route table to its initial state, resulting in the following logs to be emitted by the utility instance:

Thu Sep 21 14:42:34 UTC 2023 -- failing back to Direct Connect

private-subnet-1 route table initial state

Figure 7. private-subnet-1 route table initial state

Cleaning up

To clean up your AWS based resources, run following AWS CLI commands:

aws ec2 terminate-instances --instance-ids <your-utility-instance-id>
aws iam delete-instance-profile --instance-profile-name my_ec2_instance_profile
aws iam delete-role my_ec2_role

Conclusion

This post demonstrates how to create a failover strategy for Local Zones using the same resilience mechanisms already established in the AWS Regions. By leveraging Direct Connect and software VPNs, you can achieve high availability in scenarios where you are constrained to a single Direct Connect location due to geographical limitations. In the architectural pattern illustrated in this post, the failover strategy relies on a utility instance with least-privileged permissions. The utility instance identifies network impairment and dynamically modify your production route tables to keep the connectivity established from a Local Zone to your on-premises location. This same mechanism provides capabilities to automatically failback from the software VPN to Direct Connect once the utility instance validates that the Direct Connect Path is sufficiently reliable to avoid network flapping. To learn more about Local Zones, you can visit the AWS Local Zones user guide.

Introducing Amazon MSK Replicator – Fully Managed Replication across MSK Clusters in Same or Different AWS Regions

Post Syndicated from Danilo Poccia original https://aws.amazon.com/blogs/aws/introducing-amazon-msk-replicator-fully-managed-replication-across-msk-clusters-in-same-or-different-aws-regions/

Amazon Managed Streaming for Apache Kafka (Amazon MSK) provides a fully managed and highly available Apache Kafka service simplifying the way you process streaming data. When using Apache Kafka, a common architectural pattern is to replicate data from one cluster to another.

Cross-cluster replication is often used to implement business continuity and disaster recovery plans and increase application resilience across AWS Regions. Another use case, when building multi-Region applications, is to have copies of streaming data in multiple geographies stored closer to end consumers for lower latency access. You might also need to aggregate data from multiple clusters into one centralized cluster for analytics.

To address these needs, you would have to write custom code or install and manage open-source tools like MirrorMaker 2.0, available as part of Apache Kafka starting with version 2.4. However, these tools can be complex and time-consuming to set up for reliable replication, and require continuous monitoring and scaling.

Today, we’re introducing MSK Replicator, a new capability of Amazon MSK that makes it easier to reliably set up cross-Region and same-Region replication between MSK clusters, scaling automatically to handle your workload. You can use MSK Replicator with both provisioned and serverless MSK cluster types, including those using tiered storage.

With MSK Replicator, you can setup both active-passive and active-active cluster topologies to increase the resiliency of your Kafka application across Regions:

  • In an active-active setup, both MSK clusters are actively serving reads and writes.
  • In an active-passive setup, only one MSK cluster at a time is actively serving streaming data while the other cluster is on standby.

Let’s see how that works in practice.

Creating an MSK Replicator across AWS Regions
I have two MSK clusters deployed in different Regions. MSK Replicator requires that the clusters have IAM authentication enabled. I can continue to use other authentication methods such as mTLS or SASL for my other clients. The source cluster also needs to enable multi-VPC private connectivity.

MSK Replicator cross-Region architecture diagram.

From a network perspective, the security groups of the clusters allow traffic between the cluster and the security group used by the Replicator. For example, I can add self-referencing inbound and outbound rules that allow traffic from and to the same security group. For simplicity, I use the default VPC and its default security group for both clusters.

Before creating a replicator, I update the cluster policy of the source cluster to allow the MSK service (including replicators) to find and reach the cluster. In the Amazon MSK console, I select the source Region. I choose Clusters from the navigation pane and then the source cluster. First, I copy the source cluster ARN at the top. Then, in the Properties tab, I choose Edit cluster policy in the Security settings. There, I use the following JSON policy (replacing the source cluster ARN) and save the changes:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "kafka.amazonaws.com"
            },
            "Action": [
                "kafka:CreateVpcConnection",
                "kafka:GetBootstrapBrokers",
                "kafka:DescribeClusterV2"
            ],
            "Resource": "<SOURCE_CLUSTER_ARN>"
        }
    ]
}

I select the target Region in the console. I choose Replicators from the navigation pane and then Create replicator. Here, I enter a name and a description for the replicator.

Console screenshot.

In the Source cluster section, I select the Region of the source MSK cluster. Then, I choose Browse to select the source MSK cluster from the list. Note that Replicators can be created only for clusters that have a cluster policy set.

Console screenshot.

I leave Subnets and Security groups as their default values to use my default VPC and its default security group. This network configuration may be used to place elastic network interfaces (EINs) to facilitate communication with your cluster.

The Access control method for the source cluster is set to IAM role-based authentication. Optionally, I can turn on multiple authentication methods at the same time to continue to use clients that need other authentication methods like mTLS or SASL while the Replicator uses IAM. For cross-Region replication, the source cluster cannot have unauthenticated access enabled, because we use multi-VPC to access their source cluster.

Console screenshot.

In the Target cluster section, the Cluster region is set to the Region where I’m using the console. I choose Browse to select the target MSK cluster from the list.

Console screenshot.

Similar to what I did for the source cluster, I leave Subnets and Security groups as their default values. This network configuration is used to place the ENIs required to communicate with the target cluster. The Access control method for the target cluster is also set to IAM role-based authentication.

Console screenshot.

In the Replicator settings section, I use the default Topic replication configuration, so that all topics are replicated. Optionally, I can specify a comma-separated list of regular expressions that indicate the names of the topics to replicate or to exclude from replication. In the Additional settings, I can choose to copy topics configurations, access control lists (ACLs), and to detect and copy new topics.

Console screenshot.

Consumer group replication allows me to specify if consumer group offsets should be replicated so that, after a switchover, consuming applications can resume processing near where they left off in the primary cluster. I can specify a comma-separated list of regular expressions that indicate the names of the consumer groups to replicate or to exclude from replication. I can also choose to detect and copy new consumer groups. I use the default settings that replicate all consumer groups.

Console screenshot.

In Compression, I select None from the list of available compression types for the data that is being replicated.

Console screenshot.

The Amazon MSK console can automatically create a service execution role with the necessary permissions required for the Replicator to work. The role is used by the MSK service to connect to the source and target clusters, to read from the source cluster, and to write to the target cluster. However, I can choose to create and provide my own role as well. In Access permissions, I choose Create or update IAM role.

Console screenshot.

Finally, I add tags to the replicator. I can use tags to search and filter my resources or to track my costs. In the Replicator tags section, I enter Environment as the key and AWS News Blog as the value. Then, I choose Create.

Console screenshot.

After a few minutes, the replicator is running. Let’s put it into use!

Testing an MSK Replicator across AWS Regions
To connect to the source and target clusters, I already set up two Amazon Elastic Compute Cloud (Amazon EC2) instances in the two Regions. I followed the instructions in the MSK documentation to install the Apache Kafka client tools. Because I am using IAM authentication, the two instances have an IAM role attached that allows them to connect, send, and receive data from the clusters. To simplify networking, I used the default security group for the EC2 instances and the MSK clusters.

First, I create a new topic in the source cluster and send a few messages. I use Amazon EC2 Instance Connect to log into the EC2 instance in the source Region. I change the directory to the path where the Kafka client executables have been installed (the path depends on the version you use):

cd /home/ec2-user/kafka_2.12-2.8.1/bin

To connect to the source cluster, I need to know its bootstrap servers. Using the MSK console in the source Region, I choose Clusters from the navigation page and then the source cluster from the list. In the Cluster summary section, I choose View client information. There, I copy the list of Bootstrap servers. Because the EC2 instance is in the same VPC as the cluster, I copy the list in the Private endpoint (single-VPC) column.

Console screenshot.

Back to the EC2 instance, I put the list of bootstrap servers in the SOURCE_BOOTSTRAP_SERVERS environment variable.

export SOURCE_BOOTSTRAP_SERVERS=b-2.uscluster.esijym.c9.kafka.us-east-1.amazonaws.com:9098,b-3.uscluster.esijym.c9.kafka.us-east-1.amazonaws.com:9098,b-1.uscluster.esijym.c9.kafka.us-east-1.amazonaws.com:9098

Now, I create a topic on the source cluster.

./kafka-topics.sh --bootstrap-server $SOURCE_BOOTSTRAP_SERVERS --command-config client.properties --create --topic my-topic --partitions 6

Using the new topic, I send a few messages to the source cluster.

./kafka-console-producer.sh --broker-list $SOURCE_BOOTSTRAP_SERVERS --producer.config client.properties --topic my-topic
>Hello from the US
>These are my messages

Let’s see what happens in the target cluster. I connect to the EC2 instance in the target Region. Similar to what I did for the other instance, I get the list of bootstrap servers for the target cluster and put it into the TARGET_BOOTSTRAP_SERVERS environment variable.

On the target cluster, the source cluster alias is added as a prefix to the replicated topic names. To find the source cluster alias, I choose Replicators in the MSK console navigation pane. There, I choose the replicator I just created. In the Properties tab, I look up the Cluster alias in the Source cluster section.

Console screenshot.

I confirm the name of the replicated topic by looking at the list of topics in the target cluster (it’s the last one in the output list):

./kafka-topics.sh --list --bootstrap-server $TARGET_BOOTSTRAP_SERVERS --command-config client.properties
. . .
us-cluster-c78ec6d63588.my-topic

Now that I know the name of the replicated topic on the target cluster, I start a consumer to receive the messages originally sent to the source cluster:

./kafka-console-consumer.sh --bootstrap-server $TARGET_BOOTSTRAP_SERVERS --consumer.config client.properties --topic us-cluster-c78ec6d63588.my-topic --from-beginning
Hello from the US
These are my messages

Note that I can use a wildcard in the topic subscription (for example, .*my-topic) to automatically handle the prefix and have the same configuration in the source and target clusters.

As expected, all the messages I sent to the source cluster have been replicated and received by the consumer connected to the target cluster.

I can monitor the MSK Replicator latency, throughput, errors, and lag metrics using the Monitoring tab. Because this works through Amazon CloudWatch, I can easily create my own alarms and include these metrics in my dashboards.

To update the configuration to an active-active setup, I follow similar steps to create a replicator in the other Region and replicate streaming data between the clusters in the other direction. For details on how to manage failover and failback, see the MSK Replicator documentation.

Availability and Pricing
MSK Replicator is available today in: US East (Ohio), US East (N. Virginia), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Sydney), Europe (Frankfurt), and Europe (Ireland).

With MSK Replicator, you pay per GB of data replicated and an hourly rate for each Replicator. You also pay Amazon MSK’s usual charges for your source and target MSK clusters and standard AWS charges for cross-Region data transfer. For more information, see MSK pricing.

Using MSK replicators, you can quickly implement cross-Region and same-Region replication to improve the resiliency of your architecture and store data close to your partners and end users. You can also use this new capability to get better insights by replicating streaming data to a single, centralized cluster where it is easier to run your analytics.

Simplify your data streaming architectures using Amazon MSK Replicator.

Danilo

Migrate Microsoft Azure Synapse Analytics to Amazon Redshift using AWS SCT

Post Syndicated from Ahmed Shehata original https://aws.amazon.com/blogs/big-data/migrate-microsoft-azure-synapse-analytics-to-amazon-redshift-using-aws-sct/

Amazon Redshift is a fast, fully managed, petabyte-scale data warehouse that provides the flexibility to use provisioned or serverless compute for your analytical workloads. With Amazon Redshift Serverless and Query Editor v2, you can load and query large datasets in just a few clicks and pay only for what you use. The decoupled compute and storage architecture of Amazon Redshift enables you to build highly scalable, resilient, and cost-effective workloads. Many customers migrate their data warehousing workloads to Amazon Redshift and benefit from the rich capabilities it offers, such as the following:

  • Amazon Redshift seamlessly integrates with broader data, analytics, and AI or machine learning (ML) services on AWS, enabling you to choose the right tool for the right job. Modern analytics is much wider than SQL-based data warehousing. With Amazon Redshift, you can build lake house architectures and perform any kind of analytics, such as interactive analytics, operational analytics, big data processing, visual data preparation, predictive analytics, machine learning, and more.
  • You don’t need to worry about workloads such as ETL (extract, transform, and load), dashboards, ad-hoc queries, and so on interfering with each other. You can isolate workloads using data sharing, while using the same underlying datasets.
  • When users run many queries at peak times, compute seamlessly scales within seconds to provide consistent performance at high concurrency. You get 1 hour of free concurrency scaling capacity for 24 hours of usage. This free credit meets the concurrency demand of 97% of the Amazon Redshift customer base.
  • Amazon Redshift is straightforward to use with self-tuning and self-optimizing capabilities. You can get faster insights without spending valuable time managing your data warehouse.
  • Fault tolerance is built in. All data written to Amazon Redshift is automatically and continuously replicated to Amazon Simple Storage Service (Amazon S3). Any hardware failures are automatically replaced.
  • Amazon Redshift is simple to interact with. You can access data with traditional, cloud-native, containerized, serverless web services or event-driven applications. You can also use your favorite business intelligence (BI) and SQL tools to access, analyze, and visualize data in Amazon Redshift.
  • Amazon Redshift ML makes it straightforward for data scientists to create, train, and deploy ML models using familiar SQL. You can also run predictions using SQL.
  • Amazon Redshift provides comprehensive data security at no extra cost. You can set up end-to-end data encryption, configure firewall rules, define granular row-level and column-level security controls on sensitive data, and more.

In this post, we show how to migrate a data warehouse from Microsoft Azure Synapse to Redshift Serverless using AWS Schema Conversion Tool (AWS SCT) and AWS SCT data extraction agents. AWS SCT makes heterogeneous database migrations predictable by automatically converting the source database code and storage objects to a format compatible with the target database. Any objects that can’t be automatically converted are clearly marked so that they can be manually converted to complete the migration. AWS SCT can also scan your application code for embedded SQL statements and convert them.

Solution overview

AWS SCT uses a service account to connect to your Azure Synapse Analytics. First, we create a Redshift database into which Azure Synapse data will be migrated. Next, we create an S3 bucket. Then, we use AWS SCT to convert Azure Synapse schemas and apply them to Amazon Redshift. Finally, to migrate data, we use AWS SCT data extraction agents, which extract data from Azure Synapse, upload it into an S3 bucket, and copy it to Amazon Redshift.

The following diagram illustrates our solution architecture.

This walkthrough covers the following steps:

  1. Create a Redshift Serverless data warehouse.
  2. Create the S3 bucket and folder.
  3. Convert and apply the Azure Synapse schema to Amazon Redshift using AWS SCT:
    1. Connect to the Azure Synapse source.
    2. Connect to the Amazon Redshift target.
    3. Convert the Azure Synapse schema to a Redshift database.
    4. Analyze the assessment report and address the action items.
    5. Apply the converted schema to the target Redshift database.
  4. Migrate data from Azure Synapse to Amazon Redshift using AWS SCT data extraction agents:
    1. Generate trust and key stores (this step is optional).
    2. Install and configure the data extraction agent.
    3. Start the data extraction agent.
    4. Register the data extraction agent.
    5. Add virtual partitions for large tables (this step is optional).
    6. Create a local data migration task.
    7. Start the local data migration task.
  5. View data in Amazon Redshift.

Prerequisites

Before starting this walkthrough, you must have the following prerequisites:

Create a Redshift Serverless data warehouse

In this step, we create a Redshift Serverless data warehouse with a workgroup and namespace. A workgroup is a collection of compute resources and a namespace is a collection of database objects and users. To isolate workloads and manage different resources in Redshift Serverless, you can create namespaces and workgroups and manage storage and compute resources separately.

Follow these steps to create a Redshift Serverless data warehouse with a workgroup and namespace:

  1. On the Amazon Redshift console, choose the AWS Region that you want to use.
  2. In the navigation pane, choose Redshift Serverless.
  3. Choose Create workgroup.

  1. For Workgroup name, enter a name that describes the compute resources.

  1. Verify that the VPC is the same as the VPC as the EC2 instance with AWS SCT.
  2. Choose Next.
  3. For Namespace, enter a name that describes your dataset.
  4. In the Database name and password section, select Customize admin user credentials.
  5. For Admin user name, enter a user name of your choice (for example, awsuser).
  6. For Admin user password, enter a password of your choice (for example, MyRedShiftPW2022).

  1. Choose Next.

Note that data in the Redshift Serverless namespace is encrypted by default.

  1. In the Review and Create section, choose Create.

Now you create an AWS Identity and Access Management (IAM) role and set it as the default on your namespace. Note that there can only be one default IAM role.

  1. On the Redshift Serverless Dashboard, in the Namespaces / Workgroups section, choose the namespace you just created.
  2. On the Security and encryption tab, in the Permissions section, choose Manage IAM roles.
  3. Choose Manage IAM roles and choose Create IAM role.
  4. In the Specify an Amazon S3 bucket for the IAM role to access section, choose one of the following methods:
    1. Choose No additional Amazon S3 bucket to allow the created IAM role to access only the S3 buckets with names containing the word redshift.
    2. Choose Any Amazon S3 bucket to allow the created IAM role to access all S3 buckets.
    3. Choose Specific Amazon S3 buckets to specify one or more S3 buckets for the created IAM role to access. Then choose one or more S3 buckets from the table.
  5. Choose Create IAM role as default.
  6. Capture the endpoint for the Redshift Serverless workgroup you just created.
  7. On the Redshift Serverless Dashboard, in the Namespaces / Workgroups section, choose the workgroup you just created.
  8. In the General information section, copy the endpoint.

Create the S3 bucket and folder

During the data migration process, AWS SCT uses Amazon S3 as a staging area for the extracted data. Follow these steps to create an S3 bucket:

  1. On the Amazon S3 console, choose Buckets in the navigation pane.
  2. Choose Create bucket.
  3. For Bucket name, enter a unique DNS-compliant name for your bucket (for example, uniquename-as-rs).

For more information about bucket names, refer to Bucket naming rules.

  1. For AWS Region, choose the Region in which you created the Redshift Serverless workgroup.
  2. Choose Create bucket.

  1. Choose Buckets in the navigation pane and navigate to the S3 bucket you just created (uniquename-as-rs).
  2. Choose Create folder.
  3. For Folder name, enter incoming.
  4. Choose Create folder.

Convert and apply the Azure Synapse schema to Amazon Redshift using AWS SCT

To convert the Azure Synapse schema to Amazon Redshift format, we use AWS SCT. Start by logging in to the EC2 instance that you created previously and launch AWS SCT.

Connect to the Azure Synapse source

Complete the following steps to connect to the Azure Synapse source:

  1. On the File menu, choose Create New Project.
  2. Choose a location to store your project files and data.
  3. Provide a meaningful but memorable name for your project (for example, Azure Synapse to Amazon Redshift).
  4. To connect to the Azure Synapse source data warehouse, choose Add source.
  5. Choose Azure Synapse and choose Next.
  6. For Connection name, enter a name (for example, olap-azure-synapse).

AWS SCT displays this name in the object tree in left pane.

  1. For Server name, enter your Azure Synapse server name.
  2. For SQL pool, enter your Azure Synapse pool name.
  3. Enter a user name and password.
  4. Choose Test connection to verify that AWS SCT can connect to your source Azure Synapse project.
  5. When the connection is successfully validated, choose Ok and Connect.

Connect to the Amazon Redshift target

Follow these steps to connect to Amazon Redshift:

  1. In AWS SCT, choose Add target.
  2. Choose Amazon Redshift, then choose Next.
  3. For Connection name, enter a name to describe the Amazon Redshift connection.

AWS SCT displays this name in the object tree in the right pane.

  1. For Server name, enter the Redshift Serverless workgroup endpoint you captured earlier.
  2. For Server port, enter 5439.
  3. For Database, enter dev.
  4. For User name, enter the user name you chose when creating the Redshift Serverless workgroup.
  5. For Password, enter the password you chose when creating the Redshift Serverless workgroup.
  6. Deselect Use AWS Glue.
  7. Choose Test connection to verify that AWS SCT can connect to your target Redshift workgroup.
  8. When the test is successful, choose OK.
  9. Choose Connect to connect to the Amazon Redshift target.

Alternatively, you can use connection values that are stored in AWS Secrets Manager.

Convert the Azure Synapse schema to a Redshift data warehouse

After you create the source and target connections, you will see the source Azure Synapse object tree in the left pane and the target Amazon Redshift object tree in the right pane. We then create mapping rules to describe the source target pair for the Azure Synapse to Amazon Redshift migration.

Follow these steps to convert the Azure Synapse dataset to Amazon Redshift format:

  1. In the left pane, choose (right-click) the schema you want to convert.
  2. Choose Convert schema.
  3. In the dialog box, choose Yes.

When the conversion is complete, you will see a new schema created in the Amazon Redshift pane (right pane) with the same name as your Azure Synapse schema.

The sample schema we used has three tables; you can see these objects in Amazon Redshift format in the right pane. AWS SCT converts all the Azure Synapse code and data objects to Amazon Redshift format. You can also use AWS SCT to convert external SQL scripts, application code, or additional files with embedded SQL.

Analyze the assessment report and address the action items

AWS SCT creates an assessment report to assess the migration complexity. AWS SCT can convert the majority of code and database objects, but some objects may require manual conversion. AWS SCT highlights these objects in blue in the conversion statistics diagram and creates action items with a complexity attached to them.

To view the assessment report, switch from Main view to Assessment Report view as shown in the following screenshot.

The Summary tab shows objects that were converted automatically and objects that were not converted automatically. Green represents automatically converted objects or objects with simple action items. Blue represents medium and complex action items that require manual intervention.

The Action items tab shows the recommended actions for each conversion issue. If you choose an action item from the list, AWS SCT highlights the object that the action item applies to.

The report also contains recommendations for how to manually convert the schema item. For example, after the assessment runs, detailed reports for the database and schema show you the effort required to design and implement the recommendations for converting action items. For more information about deciding how to handle manual conversions, see Handling manual conversions in AWS SCT. AWS SCT completes some actions automatically while converting the schema to Amazon Redshift; objects with such actions are marked with a red warning sign.

You can evaluate and inspect the individual object DDL by selecting it in the right pane, and you can also edit it as needed. In the following example, AWS SCT modifies the ID column data type from decimal(3,0) in Azure Synapse to the smallint data type in Amazon Redshift.

Apply the converted schema to the target Redshift data warehouse

To apply the converted schema to Amazon Redshift, select the converted schema in the right pane, right-click, and choose Apply to database.

Migrate data from Azure Synapse to Amazon Redshift using AWS SCT data extraction agents

AWS SCT extraction agents extract data from your source database and migrate it to the AWS Cloud. In this section, we configure AWS SCT extraction agents to extract data from Azure Synapse and migrate to Amazon Redshift. For this post, we install the AWS SCT extraction agent on the same Windows instance that has AWS SCT installed. For better performance, we recommend that you use a separate Linux instance to install extraction agents if possible. For very large datasets, AWS SCT supports the use of multiple data extraction agents running on several instances to maximize throughput and increase the speed of data migration.

Generate trust and key stores (optional)

You can use Secure Socket Layer (SSL) encrypted communication with AWS SCT data extractors. When you use SSL, all data passed between the applications remains private and integral. To use SSL communication, you need to generate trust and key stores using AWS SCT. You can skip this step if you don’t want to use SSL. We recommend using SSL for production workloads.

Follow these steps to generate trust and key stores:

  1. In AWS SCT, choose Settings, Global settings, and Security.
  2. Choose Generate trust and key store.

  1. Enter a name and password for the trust and key stores.
  2. Enter a location to store them.
  3. Choose Generate, then choose OK.

Install and configure the data extraction agent

In the installation package for AWS SCT, you can find a subfolder called agents (\aws-schema-conversion-tool-1.0.latest.zip\agents). Locate and install the executable file with a name like aws-schema-conversion-tool-extractor-xxxxxxxx.msi.

In the installation process, follow these steps to configure AWS SCT Data Extractor:

  1. For Service port, enter the port number the agent listens on. It is 8192 by default.
  2. For Working folder, enter the path where the AWS SCT data extraction agent will store the extracted data.

The working folder can be on a different computer from the agent, and a single working folder can be shared by multiple agents on different computers.

  1. For Enter Redshift JDBC driver file or files, enter the location where you downloaded the Redshift JDBC drivers.
  2. For Add the Amazon Redshift driver, enter YES.
  3. For Enable SSL communication, enter yes. Enter No here if you don’t want to use SSL.
  4. Choose Next.

  1. For Trust store path, enter the storage location you specified when creating the trust and key store.
  2. For Trust store password, enter the password for the trust store.
  3. For Enable client SSL authentication, enter yes.
  4. For Key store path, enter the storage location you specified when creating the trust and key store.
  5. For Key store password, enter the password for the key store.
  6. Choose Next.

Start the data extraction agent

Use the following procedure to start extraction agents. Repeat this procedure on each computer that has an extraction agent installed.

Extraction agents act as listeners. When you start an agent with this procedure, the agent starts listening for instructions. You send the agents instructions to extract data from your data warehouse in a later section.

To start the extraction agent, navigate to the AWS SCT Data Extractor Agent directory. For example, in Microsoft Windows, use C:\Program Files\AWS SCT Data Extractor Agent\StartAgent.bat.

On the computer that has the extraction agent installed, from a command prompt or terminal window, run the command listed for your operating system. To stop an agent, run the same command but replace start with stop. To restart an agent, run the same RestartAgent.bat file.

Note that you should have administrator access to run those commands.

Register the data extraction agent

Follow these steps to register the data extraction agent:

  1. In AWS SCT, change the view to Data Migration view choose Register.
  2. Select Redshift data agent, then choose OK.

  1. For Description, enter a name to identify the agent.
  2. For Host name, if you installed the extraction agent on the same workstation as AWS SCT, enter 0.0.0.0 to indicate local host. Otherwise, enter the host name of the machine on which the AWS SCT extraction agent is installed. It is recommended to install extraction agents on Linux for better performance.
  3. For Port, enter the number you used for the listening port (default 8192) when installing the AWS SCT extraction agent.
  4. Select Use SSL to encrypt AWS SCT connection to Data Extraction Agent.

  1. If you’re using SSL, navigate to the SSL tab.
  2. For Trust store, choose the trust store you created earlier.
  3. For Key store, choose the key store you created earlier.
  4. Choose Test connection.
  5. After the connection is validated successfully, choose OK and Register.

Create a local data migration task

To migrate data from Azure Synapse Analytics to Amazon Redshift, you create, run, and monitor the local migration task from AWS SCT. This step uses the data extraction agent to migrate data by creating a task.

Follow these steps to create a local data migration task:

  1. In AWS SCT, under the schema name in the left pane, choose (right-click) the table you want to migrate (for this post, we use the table tbl_currency).
  2. Choose Create Local task.

  1. Choose from the following migration modes:
    1. Extract the source data and store it on a local PC or virtual machine where the agent runs.
    2. Extract the data and upload it to an S3 bucket.
    3. Extract the data, upload it to Amazon S3, and copy it into Amazon Redshift. (We choose this option for this post.)

  1. On the Advanced tab, provide the extraction and copy settings.

  1. On the Source server tab, make sure you are using the current connection properties.

  1. On the Amazon S3 settings tab, for Amazon S3 bucket folder, provide the bucket and folder names of the S3 bucket you created earlier.

The AWS SCT data extraction agent uploads the data in those S3 buckets and folders before copying it to Amazon Redshift.

  1. Choose Test Task.

  1. When the task is successfully validated, choose OK, then choose Create.

Start the local data migration task

To start the task, choose Start or Restart on the Tasks tab.

First, the data extraction agent extracts data from Azure Synapse. Then the agent uploads data to Amazon S3 and launches a copy command to move the data to Amazon Redshift.

At this point, AWS SCT has successfully migrated data from the source Azure Synapse table to the Redshift table.

View data in Amazon Redshift

After the data migration task is complete, you can connect to Amazon Redshift and validate the data. Complete the following steps:

  1. On the Amazon Redshift console, navigate to the Query Editor v2.
  2. Open the Redshift Serverless workgroup you created.
  3. Choose Query data.

  1. For Database, enter a name for your database.
  2. For Authentication, select Federated user
  3. Choose Create connection.

  1. Open a new editor by choosing the plus sign.
  2. In the editor, write a query to select from the schema name and table or view name you want to verify.

You can explore the data, run ad-hoc queries, and make visualizations, charts, and views.

The following screenshot is the view of the source Azure Synapse dataset we used in this post.

Clean up

Follow the steps in this section to clean up any AWS resources you created as part of this post.

Stop the EC2 instance

Follow these steps to stop the EC2 instance:

  1. On the Amazon EC2 console, in the navigation pane, choose Instances.
  2. Select the instance you created.
  3. Choose Instance state, then choose Terminate instance.
  4. Choose Terminate when prompted for confirmation.

Delete the Redshift Serverless workgroup and namespace

Follow these steps to delete the Redshift Serverless workgroup and namespace:

  1. On the Redshift Serverless Dashboard, in the Namespaces / Workgroups section, choose the workspace you created
  2. On the Actions menu, choose Delete workgroup.
  3. Select Delete the associated namespace.
  4. Deselect Create final snapshot.
  5. Enter delete in the confirmation text box and choose Delete.

Delete the S3 bucket

Follow these steps to delete the S3 bucket:

  1. On the Amazon S3 console, choose Buckets in the navigation pane.
  2. Choose the bucket you created.
  3. Choose Delete.
  4. To confirm deletion, enter the name of the bucket.
  5. Choose Delete bucket.

Conclusion

Migrating a data warehouse can be a challenging, complex, and yet rewarding project. AWS SCT reduces the complexity of data warehouse migrations. This post discussed how a data migration task extracts, downloads, and migrates data from Azure Synapse to Amazon Redshift. The solution we presented performs a one-time migration of database objects and data. Data changes made in Azure Synapse when the migration is in progress won’t be reflected in Amazon Redshift. When data migration is in progress, put your ETL jobs to Azure Synapse on hold or rerun the ETL jobs by pointing to Amazon Redshift after the migration. Consider using the best practices for AWS SCT.

To get started, download and install AWS SCT, sign in to the AWS Management Console, check out Redshift Serverless, and start migrating!


About the Authors

Ahmed Shehata is a Senior Analytics Specialist Solutions Architect at AWS based on Toronto. He has more than two decades of experience helping customers modernize their data platforms. Ahmed is passionate about helping customers build efficient, performant, and scalable analytic solutions.

Jagadish Kumar is a Senior Analytics Specialist Solutions Architect at AWS focused on Amazon Redshift. He is deeply passionate about Data Architecture and helps customers build analytics solutions at scale on AWS.

Anusha Challa is a Senior Analytics Specialist Solution Architect at AWS focused on Amazon Redshift. She has helped many customers build large-scale data warehouse solutions in the cloud and on premises. Anusha is passionate about data analytics and data science and enabling customers achieve success with their large-scale data projects.

SK hynix HBM3e CXL Computational Memory MCRDIMM and More OCP Summit 2023

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/sk-hynix-hbm3e-cxl-computational-memory-mcrdimm-and-more-ocp-summit-2023/

At OCP Summit 2023, we saw SK hynix HBM3e, CXL Computational Memory, MCRDIMM for 2024, PCIe Gen5 NVMe SSDs, and Accelerator in Memory modules

The post SK hynix HBM3e CXL Computational Memory MCRDIMM and More OCP Summit 2023 appeared first on ServeTheHome.

Run Apache Hive workloads using Spark SQL with Amazon EMR on EKS

Post Syndicated from Amit Maindola original https://aws.amazon.com/blogs/big-data/run-apache-hive-workloads-using-spark-sql-with-amazon-emr-on-eks/

Apache Hive is a distributed, fault-tolerant data warehouse system that enables analytics at a massive scale. Using Spark SQL to run Hive workloads provides not only the simplicity of SQL-like queries but also taps into the exceptional speed and performance provided by Spark. Spark SQL is an Apache Spark module for structured data processing. One of its most popular use cases is to read and write Hive tables with connectivity to a persistent Hive metastore, supporting Hive SerDes and user-defined functions.

Starting from version 1.2.0, Apache Spark has supported queries written in HiveQL. HiveQL is a SQL-like language that produces data queries containing business logic, which can be converted to Spark jobs. However, this feature is only supported by YARN or standalone Spark mode. To run HiveQL-based data workloads with Spark on Kubernetes mode, engineers must embed their SQL queries into programmatic code such as PySpark, which requires additional effort to manually change code.

Amazon EMR on Amazon EKS provides a deployment option for Amazon EMR that you can use to run open-source big data frameworks on Amazon Elastic Kubernetes Service (Amazon EKS).

Amazon EMR on EKS release 6.7.0 and later include the ability to run SparkSQL through the StartJobRun API. As a result of this enhancement, customers will now be able to supply SQL entry-point files and run HiveQL queries as Spark jobs on EMR on EKS directly. The feature is available in all AWS Regions where EMR on EKS is available.

Use case

FINRA is one of the largest Amazon EMR customers that is running SQL-based workloads using the Hive on Spark approach. FINRA, Financial Industry Regulatory Authority, is a private sector regulator responsible for analyzing equities and option trading activity in the US. To look for fraud, market manipulation, insider trading, and abuse, FINRA’s technology group has developed a robust set of big data tools in the AWS Cloud to support these activities.

FINRA centralizes all its data in Amazon Simple Storage Service (Amazon S3) with a remote Hive metastore on Amazon Relational Database Service (Amazon RDS) to manage their metadata information. They use various AWS analytics services, such as Amazon EMR, to enable their analysts and data scientists to apply advanced analytics techniques to interactively develop and test new surveillance patterns and improve investor protection. To make these interactions more efficient and productive, FINRA modernized their hive workloads in Amazon EMR from its legacy Hive on MapReduce to Hive on Spark, which resulted in query performance gains between 50 and 80 percent.

Going forward, FINRA wants to further innovate the interactive big data platform by moving from a monolithic design pattern to a job-centric paradigm, so that it can fulfill future capacity requirements as its business grows. The capability of running Hive workloads using SparkSQL directly with EMR on EKS is one of the key enablers that helps FINRA continuously pursue that goal.

Additionally, EMR on EKS offers the following benefits to accelerate adoption:

  • Fine-grained access controls (IRSA) that are job-centric to harden customers’ security posture
  • Minimized adoption effort as it enables direct Hive query submission as a Spark job without code changes
  • Reduced run costs by consolidating multiple software versions for Hive or Spark, unifying artificial intelligence and machine learning (AI/ML) and exchange, transform, and load (ETL) pipelines into a single environment
  • Simplified cluster management through multi-Availability Zone support and highly responsive autoscaling and provisioning
  • Reduced operational overhead by hosting multiple compute and storage types or CPU architectures (x86 & Arm64) in a single configuration
  • Increased application reusability and portability supported by custom docker images, which allows them to encapsulate all necessary dependencies

Running Hive SQL queries on EMR on EKS

Prerequisites

Make sure that you have AWS Command Line Interface (AWS CLI) version 1.25.70 or later installed. If you’re running AWS CLI version 2, you need version 2.7.31 or later. Use the following command to check your AWS CLI version:

aws --version

If necessary, install or update the latest version of the AWS CLI.

Solution Overview

To get started, let’s look at the following diagram. It illustrates a high-level architectural design and different services that can be used in the Hive workload. To match with FINRA’s use case, we chose an Amazon RDS database as the remote Hive metastore. Alternatively, you can use AWS Glue Data Catalog as the metastore for Hive if needed. For more details, see the aws-sample github project.

The minimum required infrastructure is:

  • An S3 bucket to store a Hive SQL script file
  • An Amazon EKS cluster with EMR on EKS enabled
  • An Amazon RDS for MySQL database in the same virtual private cloud (VPC) as the Amazon EKS cluster
  • A standalone Hive metastore service (HMS) running on the EKS cluster or a small Amazon EMR on EC2 cluster with the Hive application installed

To have a quick start, run the sample CloudFormation deployment. The infrastructure deployment includes the following resources:

Create a Hive script file

Store a few lines of Hive queries in a single file, then upload the file to your S3 bucket, which can be found in your AWS Management Console in the AWS CloudFormation Outputs tab. Search for the key value of CODEBUCKET as shown in preceding screenshot. For a quick start, you can skip this step and use the sample file stored in s3://<YOUR_S3BUCKET>/app_code/job/set-of-hive-queries.sql. The following is a code snippet from the sample file :

-- drop database in case switch between different hive metastore

DROP DATABASE IF EXISTS hiveonspark CASCADE;
CREATE DATABASE hiveonspark;
USE hiveonspark;

--create hive managed table
DROP TABLE IF EXISTS testtable purge;
CREATE TABLE IF NOT EXISTS testtable (`key` INT, `value` STRING) using hive;
LOAD DATA LOCAL INPATH '/usr/lib/spark/examples/src/main/resources/kv1.txt' INTO TABLE testtable;
SELECT * FROM testtable WHERE key=238;

-- test1: add column
ALTER TABLE testtable ADD COLUMNS (`arrayCol` Array<int>);
-- test2: insert
INSERT INTO testtable VALUES 
(238,'val_238',array(1,3)),
(238,'val_238',array(2,3));
SELECT * FROM testtable WHERE key=238;
-- test3: UDF
CREATE TEMPORARY FUNCTION hiveUDF AS 'org.apache.hadoop.hive.ql.udf.generic.GenericUDTFExplode';
SELECT `key`,`value`,hiveUDF(arrayCol) FROM testtable WHERE key=238;
-- test4: CTAS table with parameter
DROP TABLE IF EXISTS ctas_testtable purge;
CREATE TABLE ctas_testtable 
STORED AS ORC
AS
SELECT * FROM testtable;
SELECT * FROM ctas_testtable WHERE key=${key_ID};
-- test5: External table mapped to S3
CREATE EXTERNAL TABLE IF NOT EXISTS amazonreview
( 
  marketplace string, 
  customer_id string, 
  review_id  string, 
  product_id  string, 
  product_parent  string, 
  product_title  string, 
  star_rating  integer, 
  helpful_votes  integer, 
  total_votes  integer, 
  vine  string, 
  verified_purchase  string, 
  review_headline  string, 
  review_body  string, 
  review_date  date, 
  year  integer
) 
STORED AS PARQUET 
LOCATION 's3://${S3Bucket}/app_code/data/toy/';
SELECT count(*) FROM amazonreview;

Submit the Hive script to EMR on EKS

First, set up the required environment variables. See the shell script post-deployment.sh:

stack_name='HiveEMRonEKS'
export VIRTUAL_CLUSTER_ID=$(aws cloudformation describe-stacks --stack-name $stack_name --query "Stacks[0].Outputs[?OutputKey=='VirtualClusterId'].OutputValue" --output text)
export EMR_ROLE_ARN=$(aws cloudformation describe-stacks --stack-name $stack_name --query "Stacks[0].Outputs[?OutputKey=='EMRExecRoleARN'].OutputValue" --output text)
export S3BUCKET=$(aws cloudformation describe-stacks --stack-name $stack_name --query "Stacks[0].Outputs[?OutputKey=='CODEBUCKET'].OutputValue" --output text)

Connect to the demo EKS cluster:

echo `aws cloudformation describe-stacks --stack-name $stack_name --query "Stacks[0].Outputs[?starts_with(OutputKey,'eksclusterEKSConfig')].OutputValue" --output text` | bash
kubectl get svc

Ensure the entryPoint path is correct, then submit the set-of-hive-queries.sql to EMR on EKS.

aws emr-containers start-job-run \
--virtual-cluster-id $VIRTUAL_CLUSTER_ID \
--name sparksql-test \
--execution-role-arn $EMR_ROLE_ARN \
--release-label emr-6.8.0-latest \
--job-driver '{
  "sparkSqlJobDriver": {
      "entryPoint": "s3://'$S3BUCKET'/app_code/job/set-of-hive-queries.sql",
      "sparkSqlParameters": "-hivevar S3Bucket='$S3BUCKET' -hivevar Key_ID=238"}}' \
--configuration-overrides '{
    "applicationConfiguration": [
      {
        "classification": "spark-defaults", 
        "properties": {
          "spark.sql.warehouse.dir": "s3://'$S3BUCKET'/warehouse/",
          "spark.hive.metastore.uris": "thrift://hive-metastore:9083"
        }
      }
    ], 
    "monitoringConfiguration": {
      "s3MonitoringConfiguration": {"logUri": "s3://'$S3BUCKET'/elasticmapreduce/emr-containers"}}}'

Note that the shell script referenced the set-of-hive-queries.sql Hive script file as an entry point script. It uses the sparkSqlJobDriver attribute, not the usual sparkSubmitJobDriver designed for Spark applications. In the sparkSqlParameters section, we pass in two environment variables S3Bucket and key_ID to the Hive script.

The property "spark.hive.metastore.uris": "thrift://hive-metastore:9083" sets a connection to a Hive Metastore Service (HMS) called hive-metastore, which is running as a Kubernetes service on the demo EKS cluster as shown in the follow screenshot. If you’re running the thrift service on Amazon EMR on EC2, the URI should be thrift://<YOUR_EMR_MASTER_NODE_DNS_NAME>:9083. If you chose AWS Glue Data Catalog as your Hive metastore, replace the entire property with "spark.hadoop.hive.metastore.client.factory.class": "com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory".

Finally, check the job status using the kubectl command line tool: kubectl get po -n emr --watch

Expected output

  1. Go to the Amazon EMR console.
  2. Navigate to the side menu Virtual clusters, then select the HiveDemo cluster, You can see an entry for the SparkSQL test job.
  3. Click Spark UI hyperlink to monitor each query’s duration and status on a web interface.
  4. To query the Amazon RDS based Hive metastore, you need a MYSQL client tool installed. To make it easier, the sample CloudFormation template has installed the query tool on master node of a small Amazon EMR on EC2 cluster.
  5. Find the EMR master node by running the following command:
aws ec2 describe-instances --filter Name=tag:project,Values=$stack_name Name=tag:aws:elasticmapreduce:instance-group-role,Values=MASTER --query 'Reservations[].Instances[].InstanceId[]'

  1. Go to the Amazon EC2 console and connect to the master node through the Session Manager.
  2. Before querying the MySQL RDS database (the Hive metastore), run the following commands on your local machine to get the credentials:
    stack_name='HiveEMRonEKS' 
    export secret_name=$(aws cloudformation describe-stacks --stack-name $stack_name --query "Stacks[0].Outputs[?OutputKey=='HiveSecretName'].OutputValue" --output text) 
    export HOST_NAME=$(aws secretsmanager get-secret-value --secret-id $secret_name --query SecretString --output text | jq -r '.host')
    export PASSWORD=$(aws secretsmanager get-secret-value --secret-id $secret_name --query SecretString --output text | jq -r '.password')
    export DB_NAME=$(aws secretsmanager get-secret-value --secret-id $secret_name --query SecretString --output text | jq -r '.dbname')
    export USER_NAME=$(aws secretsmanager get-secret-value --secret-id $secret_name --query SecretString --output text | jq -r '.username')
    echo -e "\n host: $HOST_NAME\n DB: $DB_NAME\n passowrd: $PASSWORD\n username: $USER_NAME\n"
    

  3. After connected through Session Manager, query the Hive metastore from your Amazon EMR master node.
    mysql -u admin -P 3306 -p -h <YOUR_HOST_NAME>
    Enter password:<YOUR_PASSWORD>
    
    # Query the metastore
    MySQL[(none)]> Use HiveEMRonEKS;
    MySQL[HiveEMRonEKS]> select * from DBS;
    MySQL[HiveEMRonEKS]> select * from TBLS;
    MySQL[HiveEMRonEKS]> exit();

  4. Validate the Hive tables (created by set-of-hive-queries.sql) through the interactive Hive CLI tool.

Note:-Your query environment must have the Hive Client tool installed and a connection to your Hive metastore or AWS Glue Data Catalog. For the testing purpose, you can connect to the same Amazon EMR on EC2 master node and query your Hive tables. The EMR cluster has been pre-configured with the required setups.

sudo su
hive
hive> show databases;

Clean up

To avoid incurring future charges, delete the resources generated if you don’t need the solution anymore. Run the following cleanup script.

curl https://raw.githubusercontent.com/aws-samples/hive-emr-on-eks/main/deployment/app_code/delete_all.sh | bash

Go to the CloudFormation console and manually delete the remaining resources if needed.

Conclusion

Amazon EMR on EKS releases 6.7.0 and higher include a Spark SQL job driver so that you can directly run Spark SQL scripts via the StartJobRun API. Without any modifications to your existing Hive scripts, you can directly execute them as a SparkSQL job on Amazon EMR on EKS.

FINRA is one of the largest Amazon EMR customers. It runs over 400 Hive clusters for its analysts who need to interactively query multi-petabyte data sets. Modernizing its Hive workloads with SparkSQL gives FINRA a 50 to 80 percent query performance improvement. The support to run Spark SQL through the StartJobRun API in EMR on EKS has further enabled FINRA’s innovation in data analytics.

In this post, we demonstrated how to submit a Hive script to Amazon EMR on EKS and run it as a SparkSQL job. We encourage you to give it a try and are keen to hear your feedback and suggestions.


About the authors

Amit Maindola is a Senior Data Architect focused on big data and analytics at Amazon Web Services. He helps customers in their digital transformation journey and enables them to build highly scalable, robust, and secure cloud-based analytical solutions on AWS to gain timely insights and make critical business decisions.

Melody Yang is a Senior Big Data Solutions Architect for Amazon EMR at AWS. She is an experienced analytics leader working with AWS customers to provide best practice guidance and technical advice in order to assist their success in data transformation. Her areas of interests are open-source frameworks and automation, data engineering, and DataOps.

Unleash the power of Snapshot Management to take automated snapshots using Amazon OpenSearch Service

Post Syndicated from Prashant Agrawal original https://aws.amazon.com/blogs/big-data/unleash-the-power-of-snapshot-management-to-take-automated-snapshots-using-amazon-opensearch-service/

Data is the lifeblood of any organization, and the importance of protecting it cannot be overstated. Starting with OpenSearch v2.5 in Amazon OpenSearch Service, we introduced Snapshot Management, which automates the process of taking snapshots of your domain. Snapshot Management helps you create point-in-time backups of your domain using OpenSearch Dashboards, including both data and configuration settings (for visualizations and dashboards). You can use these snapshots to restore your cluster to a specific state, recover from potential failures, and even clone environments for testing or development purposes.

Before this release, to automate the process of taking snapshots, you needed to use the snapshot action of OpenSearch’s Index State Management (ISM) feature. With ISM, you could only back up a particular index. Automating backup for multiple indexes required you to write custom scripts or use external management tools. With Snapshot Management, you can automate snapshotting across multiple indexes to safeguard your data and ensure its durability and recoverability.

In this post, we share how to use Snapshot Management to take automated snapshots using OpenSearch Service.

Solution overview

We demonstrate the following high-level steps:

  1. Register a snapshot repository in OpenSearch Service (a one-time process).
  2. Configure a sample ISM policy to migrate the indexes from hot storage to the UltraWarm storage tier after the indexes meet a specific condition.
  3. Create a Snapshot Management policy to take an automated snapshot for all indexes present across different storage tiers within a domain.

As of this writing, Snapshot Management doesn’t support single snapshot creation for all indexes present across different storage tiers within OpenSearch Service. For example, if you try to create a snapshot on multiple indexes with * and some indexes are in the warm tier, the snapshot creation will fail.

To overcome this limitation, you can use index aliases, with one index alias for each type of storage tier. For example, every new index created in the cluster will belong to the hot alias. When the index is moved to the UltraWarm tier via ISM, the alias for the index will be modified to warm, and the index will be removed from the hot alias.

Register a manual snapshot repository

To register a manual snapshot repository, you must create and configure an Amazon Simple Storage Service (Amazon S3) bucket and AWS Identity and Access Management (IAM) roles. For more information, refer to Prerequisites. Complete the following steps:

  1. Create an S3 bucket to store snapshots for your OpenSearch Service domain.
  2. Create an IAM role called SnapshotRole with the following IAM policy to delegate permissions to OpenSearch Service (provide the name of your S3 bucket):
{
    "Version": "2012-10-17",
    "Statement": [{
        "Action": ["s3:ListBucket"],
        "Effect": "Allow",
        "Resource": ["arn:aws:s3:::<s3-bucket-name>"]
    }, {
        "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
        "Effect": "Allow",
        "Resource": ["arn:aws:s3:::<s3-bucket-name>/*"]
    }]
}
  1. Set the trust relationship for SnapshotRole as follows:
{
    "Version": "2012-10-17",
    "Statement": [{
        "Sid": "",
        "Effect": "Allow",
        "Principal": {
            "Service": "es.amazonaws.com"
        },
        "Action": "sts:AssumeRole"
    }]
}
  1. Create a new IAM role called RegisterSnapshotRepo, which delegates iam:PassRole and es:ESHttpPut (provide your AWS account and domain name):
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": "iam:PassRole",
        "Resource": "arn:aws:iam::<aws account id>:role/SnapshotRole"
    }, {
        "Effect": "Allow",
        "Action": "es:ESHttpPut",
        "Resource": "arn:aws:es:region:<aws account id>:domain/<domain-name>/*"
    }]
}
  1. If you have enabled fine-grained access control for your domain, map the snapshot role manage_snapshots to your RegisterSnapshotRepo IAM role in OpenSearch Service.
  2. Now you can use Python code like the following example to register the S3 bucket you created as a snapshot repository for your domain. Provide your host name, Region, snapshot repo name, and S3 bucket. Replace "arn:aws:iam::123456789012:role/SnapshotRole" with the ARN of your SnapshotRole. The Boto3 session should use the RegisterSnapshotRepo IAM role.
import boto3
import requests
from requests_aws4auth import AWS4Auth
 
host = '<host>' # domain endpoint with trailing /
region = '<region>' # e.g. us-west-1
service = 'es'
credentials = boto3.Session().get_credentials()
awsauth = AWS4Auth(credentials.access_key, credentials.secret_key, region, service, session_token=credentials.token)
 
# To Register the repository

path = '_snapshot/<snapshot-repo-name>'
url = host + path
 
payload = {
  "type": "s3",
  "settings": {
    "bucket": "<s3-bucket-name>",
    "region": "<region>",
    "role_arn": "arn:aws:iam::123456789012:role/SnapshotRole"
  }
}
 
headers = {"Content-Type": "application/json"}
 
r = requests.put(url, auth=awsauth, json=payload, headers=headers, timeout=300)
 
print(r.status_code)
print(r.text)

The S3 bucket used as a repository must be in the same Region as your domain. You can run the preceding code in any compute instance that has connectivity to your OpenSearch Service domain, such as Amazon Elastic Compute Cloud (Amazon EC2), AWS Cloud9, or AWS Lambda. If your domain is within a VPC, then the compute instance should be running inside the same VPC or have connectivity to the VPC.

If you have to register the snapshot repository from a local machine, replace the following lines in the preceding code:

credentials = boto3.Session().get_credentials()
awsauth = AWS4Auth(credentials.access_key, credentials.secret_key, region, service, session_token=credentials.token)

Replace this code with the following and assume the RegisterSnapshotRepo role (make sure the IAM entity that you are using has appropriate permission to assume the RegisterSnapshotRepo role). Modify "arn:aws:iam::123456789012:role/RegisterSnapshotRepo" with the ARN of your RegisterSnapshotRepo role.

sts = boto3.Session().client("sts")
response = sts.assume_role(
    RoleArn="arn:aws:iam::123456789012:role/RegisterSnapshotRepo",
    RoleSessionName="Snapshot-Session"
)

awsauth = AWS4Auth(response['Credentials']['AccessKeyId'], response['Credentials']['SecretAccessKey'], region, service, session_token=response['Credentials']['SessionToken'])

Upon successfully running the sample code, you should receive output such as the following:

200
{"acknowledged":true}

You can also verify that you have successfully registered the snapshot repository by accessing OpenSearch Dashboards in your domain and navigating to Snapshots Managements, Repositories.

Create an index template

Index templates enable you to automatically assign configuration when new indexes are created that match a wildcard index pattern.

  1. Navigate to your domain’s OpenSearch Dashboards and choose the Dev Tools tab.
  2. Enter the following text in the left pane and choose the play icon to run it.

The index template applies to newly created indexes that match the pattern of "log*". These indexes are attached to the alias named hot and the replica count is set to 1.

PUT _index_template/snapshot_template
{
  "index_patterns" : ["log*"],
  "template": {
      "settings": {
      "number_of_replicas": 1
    },
    "aliases" : {
        "hot" : {}
    }
  }
}

Note that in the preceding example, you assign the template to indexes that match "log*". You can modify index_patterns for your use case.

Create an ISM policy

In this step, you create the ISM policy that updates the alias of an index before it is migrated to UltraWarm. The policy also performs hot to warm migration. This is to overcome the limitations where a snapshot can’t be taken across two storage tiers (hot and UltraWarm). Complete the following steps:

  1. Navigate to the Dev Tools page of OpenSearch Dashboards.
  2. Create the ISM policy using the following command (modify the values of index_patterns and min_index_age accordingly):
PUT /_plugins/_ism/policies/alias_policy
{
    "policy": {
        "policy_id": "alias_policy",
        "description": "Example Policy for changing the alias and performing the warm migration",
        "default_state": "hot_alias",
        "states": [{
            "name": "hot_alias",
            "actions": [],
            "transitions": [{
                "state_name": "warm",
                "conditions": {
                    "min_index_age": "30d"
                }
            }]
        }, {
            "name": "warm",
            "actions": [{
                "alias": {
                    "actions": [{
                        "remove": {
                            "aliases": ["hot"]
                        }
                    }, {
                        "add": {
                            "aliases": ["warm"]
                        }
                    }]
                }
            }, {
                "retry": {
                    "count": 5,
                    "backoff": "exponential",
                    "delay": "1h"
                },
                "warm_migration": {}
            }],
            "transitions": []
        }],
        "ism_template": [{
            "index_patterns": ["log*"],
            "priority": 100
        }]
    }
}

Create a snapshot policy

In this step, you create a snapshot policy, which takes a snapshot for all the indexes aliased as hot and stores them to your repository at the scheduled time in the cron expression (midnight UTC). Complete the following steps:

  1. Navigate to the Dev Tools page of OpenSearch Dashboards.
  2. Create the snapshot policy using the following command (modify the value of snapshot-repo-name to the name of the snapshot repository you registered previously):
POST _plugins/_sm/policies/daily-snapshot-for-manual-repo
{
    "description": "Policy for Daily Snapshot in the Manual repo",
    "creation": {
      "schedule": {
        "cron": {
          "expression": "0 0 * * *",
          "timezone": "UTC"
        }
      }
    },
    "deletion": {
      "schedule": {
        "cron": {
          "expression": "0 1 * * *",
          "timezone": "UTC"
        }
      },
      "condition": {
        "min_count": 1,
        "max_count": 40
      }
    },
    "snapshot_config": {
      "indices": "hot",
      "repository": "snapshot-repo-name"
    }
}

Clean up

Snapshots that you create incur cost in the S3 bucket used as the repository. With the new Snapshots Management feature, you can easily list and delete unwanted snapshots, and delete the ISM policy to stop taking manual snapshots directly from OpenSearch Dashboards.

Conclusion

With the new Snapshot Management capabilities of OpenSearch Service, you can create regular backups and ensure the availability of your data even in the event of unexpected events or disasters. In this post, we discussed essential concepts such as snapshot repositories, automated snapshot lifecycle policies, and Snapshot Management options, enabling you to make informed decisions when it comes to managing your data backups effectively. As you continue to explore and harness the potential of OpenSearch Service, incorporating Snapshot Management into your data protection strategy will undoubtedly provide you with the resilience and reliability needed to ensure business continuity.

If you have feedback about this post, share it in the comments section. If you have questions about this post, start a new thread on the Amazon OpenSearch Service forum or contact AWS Support.


About the authors

Prashant Agrawal is a Sr. Search Specialist Solutions Architect with Amazon OpenSearch Service. He works closely with customers to help them migrate their workloads to the cloud and helps existing customers fine-tune their clusters to achieve better performance and save on cost. Before joining AWS, he helped various customers use OpenSearch and Elasticsearch for their search and log analytics use cases. When not working, you can find him traveling and exploring new places. In short, he likes doing Eat → Travel → Repeat.

Hendy Wijaya is a Senior OpenSearch Specialist Solutions Architect at Amazon Web Services. Hendy enables customers to leverage AWS services to achieve their business objectives and gain competitive advantages. He is passionate in collaborating with customers in getting the best out of OpenSearch and Amazon OpenSearch

Utkarsh Agarwal is a Cloud Support Engineer in the Support Engineering team at Amazon Web Services. He specializes in Amazon OpenSearch Service. He provides guidance and technical assistance to customers thus enabling them to build scalable, highly available and secure solutions in AWS Cloud. In his free time, he enjoys watching movies, TV series and of course cricket! Lately, he his also attempting to master the art of cooking in his free time – The taste buds are excited, but the kitchen might disagree.

[$] Defining open hardware

Post Syndicated from jake original https://lwn.net/Articles/945870/

Open-source hardware (or open hardware) refers to hardware that is
developed in a manner similar to open-source software. There’s a widely
accepted definition of open-source hardware, but it is probably not as well
known as its open-source-software counterpart. In addition, there is a popular
certification program that hardware makers can use to indicate which of
their devices meets that criteria. But there are some vendors that are
showing more enthusiasm than others in participating in the process—or in
producing
open hardware at all.

The collective thoughts of the interwebz