Autor: Igor Lushchyk i Ravi Autar

Adyen podejmuje wiele decyzji w ramach przepływu płatności i poza nim, aby zapewnić najnowocześniejsze przetwarzanie płatności. Wyzwania, które należy rozwiązać, to między innymi „optymalizacja współczynników konwersji płatności”, „ratowanie nieudanych płatności za subskrypcję” czy „przewidywanie i monitorowanie wielkości płatności”. Wszystkie te decyzje podejmowane są poprzez umożliwienie szeregu wyspecjalizowanym zespołom danych wykorzystania ogromnej ilości danych generowanych w całym przepływie płatności. Jednak, aby wykorzystać te dane, potrzebujemy wszechstronnej platformy i zestawu narzędzi, które zaspokoją wszystkie typowe potrzeby zespołów danych, jednocześnie dając każdemu zespołowi elastyczność w pracy nad unikalnym i specyficznym dla domeny rozwiązaniem. Budowa takiej platformy pozwala nam osiągnąć doskonałość operacyjną i pozwala naszym zespołom danych na szybkie uruchamianie i iterację swoich rozwiązań. W tym poście na blogu przyjrzyjmy się, jak rozpoczęliśmy pracę z własnym frameworkiem ETL, jakie problemy napotkaliśmy i jak przeszliśmy na Airflow

Spoink

Na początku inicjatywy Adyen dotyczącej danych opracowaliśmy ramy do tworzenia i „planowania potoków przetwarzania danych”, które nazwaliśmy „Spoink”. Zbudowaliśmy framework Spoink z wieloma koncepcjami projektowymi zaczerpniętymi z Airflow. W rezultacie nasz framework odziedziczył wiele API Airflow, takich jak „definicja zależności DAG i zadań”. Pierwotnym planem było przekształcenie Spoinka w kompletny framework ETL o otwartym kodzie źródłowym.,

W „poprzednim poście na blogu” omówiliśmy różne powody zaprojektowania własnego frameworka ETL, wśród których kluczowymi powodami były lekkość, bezpieczeństwo i dopasowanie do istniejącej infrastruktury w Adyen. Prostota jego użycia przez interesariuszy odegrała kluczową rolę, ponieważ coraz więcej zespołów przyjmowało to narzędzie do analizy i przygotowania danych. Co więcej, za pośrednictwem Spoink wdrożono również wiele potoków uczenia maszynowego. Po tym, jak staliśmy się centralnym elementem infrastruktury danych, zrozumieliśmy, że jesteśmy bardzo uzależnieni od Spoinka.

Problemy ze Spoinkiem

W miarę jak nasze zrozumienie i przypadki użycia naszej platformy Big Data rosły przez lata, tak samo jak dług techniczny, który zaciągnęliśmy dla Spoink; urósł do tego stopnia, że ​​nie dało się go utrzymać. Jedną z takich decyzji było użycie jednego DAG, w którym wszystkie strumienie miały wspólną własność, w przeciwieństwie do własności modułowej opartej na produkcie danych. Kolejny szczegół implementacji uniemożliwiał przesyłanie zadań Spark w trybie klastra, co prowadziłoby do zwiększenia kosztów operacyjnych, ponieważ pojedynczy węzeł brzegowy byłby cały czas przeciążony. Planowanie i uzupełnianie zadań wymagałoby od użytkowników skomplikowanej znajomości frameworka Spoink, a wszelkie popełnione błędy prowadziłyby do dużych kosztów operacyjnych zarówno dla zespołów inżynieryjnych, jak i ds. infrastruktury.

Dodając do tych problemów, najbardziej widocznym problemem związanym ze Spoinkiem był jego zamknięty charakter. Wraz ze wzrostem zadłużenia technicznego i jednoczesnym wzrostem zespołów i produktów zależnych od platformy Big Data, obsługa bazy kodu Spoinka stawała się coraz trudniejsza. Bycie zamkniętym źródłem oznaczało również, że przegapiliśmy mnóstwo ostatnich zmian w orkiestracji ETL opracowanej przez społeczność open source. Kontynuowanie pracy nad Spoinkiem zamknęłoby również możliwość ponownego wniesienia wkładu do społeczności open-source.

Podsumowując, było jasne, że musimy ponownie ocenić sposób, w jaki planowaliśmy zadania ETL i jak zarządzaliśmy własnością danych.

Ewolucja podejścia do danych

Przed podjęciem decyzji o nowej strukturze orkiestracji najpierw musieliśmy przemyśleć sposób organizacyjnego zarządzania danymi pod kątem zadań ETL i własności danych. Platforma Spoink miała jeden dzienny DAG, który zawierał wszystkie zadania ETL w wielu zespołach produktowych. Dlatego DAG był aktualizowany i utrzymywany przez każdy zespół, co skutkowało długimi czasami pracy, zmniejszoną elastycznością i zwiększonymi kosztami operacyjnymi w przypadku nieudanych przebiegów. Musieliśmy przejść na bardziej zdecentralizowane podejście, w którym zespoły miały jasną odpowiedzialność za swoje procesy ETL, a także większą przejrzystość w zakresie własności danych. Aby to osiągnąć, przyjęliśmy architekturę siatki danych przedstawioną w tym poście na blogu

Siatka danych w Adyen

Każdy zespół danych w Adyen specjalizuje się w rozwiązywanych przez siebie problemach oraz opracowaniu i utrzymaniu całego potoku danych dla swojego rozwiązania. W zależności od zespołu i problemu, który rozwiązuje, produkt danych może mieć różne formy, takie jak pulpity nawigacyjne, raporty lub artefakty ML. Zaczynając od surowych danych, zespół jest właścicielem wszystkich tabel/artefaktów pośrednich wymaganych do ułatwienia rozwiązania danych.

Stosując w praktyce architekturę siatki danych, należy wziąć pod uwagę wiele wyzwań. Nadanie zespołom własności procesów ETL wprowadza również większą różnorodność w typach przypadków użycia, które zespoły CDI muszą uwzględnić. Niektórzy z nich są.

  • Harmonogram ETL: jednym z niekwestionowanych wymagań jest możliwość planowania różnych ETL o unikalnych cechach. Podczas gdy większość zespołów wymaga, aby ich zadania ETL były uruchamiane codziennie, niektóre zadania muszą działać co godzinę, co tydzień lub co miesiąc. Zespoły potrzebują nie tylko elastyczności, aby określić różne interwały planowania, ale także różne czasy rozpoczęcia/zakończenia i zachowania ponawiania prób dla ich określonego ETL.
  • Zależności zadań: zespoły muszą również określić zależności między różnymi zadaniami ETL. Mogą to być zależności między różnymi zadaniami należącymi do jednego zespołu, ale można je również rozszerzyć o zależności od zadań należących do innych zespołów, tj. Zależności między zespołami. Przykładem tego jest sytuacja, gdy zespół Business Intelligence chce ponownie wykorzystać tabelę utworzoną przez zespół ds. uwierzytelniania, aby zbudować tabele podsumowań, które ostatecznie zasilają ich pulpity nawigacyjne.
  • Cofanie i uzupełnianie: każdy zespół w Adyen stara się szybko produkować swoje tabele i powtarzać je. Zwykle oznacza to, że zespoły wymagają kilkukrotnego ponownego uruchomienia niektórych swoich ETL. Czasami dane mogą być uszkodzone/niekompletne dla niektórych zakresów dat. To nieuchronnie wymaga od nas ponownego uruchomienia ich potoków ETL dla określonych zakresów dat dla niektórych tabel, przy jednoczesnym uwzględnieniu ich dalszych zależności i (prawdopodobnie różnych) interwałach harmonogramu.

Przyjęcie przepływu powietrza

Wspomniane wcześniej problemy i zmiana spojrzenia na pracę z danymi skłoniły nas do poszukiwania zastępczego frameworka, do którego wybraliśmy Airflow.

Airflow to platforma planowania typu open source, która umożliwia korzystanie z szybkich zmian dokonanych przez społeczność open source. Było wiele powodów, dla których wybraliśmy go spośród konkurentów. Żeby wymienić tylko kilka:

  • Skalowalność. Dzięki swojemu projektowi można go skalować przy minimalnym wysiłku ze strony zespołu ds. infrastruktury.
  • Rozszerzalny model. Niezwykle łatwo jest dodać niestandardowe funkcje do Airflow, aby spełnić określone potrzeby.
  • Wbudowane zasady ponawiania prób, czujniki i uzupełnianie. Dzięki tym funkcjom możemy dodać DAG/zadanie i wstecznie uruchomić ETL, lub będziemy po bezpiecznej stronie, czekając na zdarzenie, które wyzwoli DAG.
  • Interfejs monitorowania i zarządzania.
  • Wbudowany interfejs do interakcji z logami.

Nasz system danych jest oparty na platformach Spark i Hadoop do obsługi naszych zadań ETL i ML z HDFS jako magazynem danych. Używamy Apache YARN jako głównego menedżera zasobów. Ta standardowa konfiguracja znacznie ułatwiła proces instalowania i wdrażania Airflow, ponieważ Airflow ma wbudowaną obsługę przesyłania zadań Spark za pośrednictwem YARN. Mamy również uruchomione następujące komponenty Airflow:

  • Serwer internetowy Airflow: główny komponent odpowiedzialny za interfejs użytkownika, z którym będą współdziałać wszyscy nasi interesariusze. Jednak przestój serwera WWW nie przekłada się automatycznie na niemożność uruchomienia ETL (jest to obsługiwane przez harmonogram i pracowników)
  • Harmonogram przepływu powietrza: mózg przepływu powietrza. Odpowiedzialny za serializację DAG, definiowanie planu wykonania DAG i komunikację z pracownikami Airflow.
  • Pracownik przepływu powietrza: koń roboczy instalacji i otrzymuje zadania od harmonogramu i uruchamia się w określony sposób. Dzięki pracownikom możemy skalować w nieskończoność. Ponadto mogą istnieć różne typy pracowników o różnych konfiguracjach. W Adyen korzystamy z pracowników Selera.

Oprócz standardowych komponentów Airflow potrzebujemy również kilku innych usług wspierających naszą instalację:

  • Kolejka brokera jest odpowiedzialna za śledzenie zadań, które zostały zaplanowane i nadal wymagają wykonania. Wybrana tutaj technologia powinna być niezawodna i skalowalna. W Adyen używamy Redis.
  • Relacyjna baza danych do przechowywania metadanych potrzebnych do uruchomienia DAG i Airflow oraz przechowywania wyników wykonania zadań. W Adyen korzystamy z bazy danych Postgres
  • Kwiat. Ten składnik jest opcjonalny, jeśli chcesz monitorować i rozumieć, co dzieje się z pracownikami Celery i wykonywanymi przez nich zadaniami.

Przynajmniej dla następnych musimy mieć wysoką dostępność: pracownicy Airflow, baza danych PostgreSQL i Redis. Co oznacza więcej instancji i większe obciążenie klastra. Po dokładnym przemyśleniu wprowadziliśmy do naszej instalacji Hadoop nowy typ maszyny. Te typy maszyn będą miały wszystkich klientów wymaganych do interakcji z platformami Spark, HDFS, Apache Ranger, Apache YARN, ale nie będą obsługiwać żadnego obciążenia związanego z uruchamianiem zadań ETL lub ML. Nazywamy je węzłami krawędziowymi. Maszyny, które obsługują obciążenie ETL/ML, to pracownicy. W tym poście na blogu nie zagłębimy się w dokładną architekturę każdego pojedynczego komponentu, który jest zaangażowany w naszą platformę Big Data. Ale oto schemat architektoniczny, który przedstawia ogólną konfigurację.

Dzięki rozdzieleniu maszyn, które wykonują prace i je kontrolują, możemy mieć bezbolesne konserwacje i być bezpieczni w przypadku awarii:

  • W przypadku porażki pracownika zachowujemy wszystkie informacje o powodzeniu lub niepowodzeniu zadań i możemy je przełożyć w przyszłości.
  • W przypadku awarii krawędzi nadal możemy wykonywać bieżące zadania.

Aktualizacja: niedawno zaktualizowaliśmy do Airflow 2.0, a teraz używamy również harmonogramu Airflow w trybie HA.

Migracja do Airflow

Jednym z największych wyzwań podczas przyjęcia przepływu powietrza była migracja już istniejących rurociągów ze Spoink. Podczas takiej migracji starannie musieliśmy wybrać naszą strategię, ponieważ większość zadań wykonywanych w Spoink miała również kluczowe znaczenie dla produkcji dla naszych zespołów produktowych. Musieliśmy zapewnić nieprzerwane działanie istniejącej infrastruktury, jednocześnie wdrażając nową architekturę oraz migrując zadania produkcyjne i użytkowników.

Do takiej aktywności wybieramy podejście „zielono-niebieskie” zielono-niebieskie. Ta stosunkowo prosta metoda pozwala nam na przestrzeganie wyżej wymienionych ograniczeń podczas tej migracji. Aby zastosować to podejście, musisz wziąć pod uwagę następujące założenia:

  • Musieliśmy mieć uruchomione stare i nowe instalacje w tym samym czasie i osiągnąć parzystość funkcji. Zasadniczo oznaczało to, że wszystkie zadania produkcyjne działają jednocześnie na Spoink i Airflow dla wielu
  • Nie dodajesz nowych funkcji do starej instalacji. Wprowadziliśmy zamrożenie kodu na czas migracji, aby uniknąć dodawania kolejnych ruchomych komponentów do procesu migracji (2–3 tygodnie)
  • Nie migrujesz zespołów za jednym razem, ale powoli, z odpowiednim testowaniem i walidacją.

Jeśli chodzi o potok ETL i własność danych, postanowiliśmy rozwiązać ten problem strukturalnie, odzwierciedlając odpowiednie prawa własności bezpośrednio w bazie kodu. W rezultacie baza kodu zawierająca logikę dla każdego potoku ETL została podzielona na zespoły produktowe, które były pierwszym punktem kontaktu dla tej konkretnej logiki. Własność tabel została również odzwierciedlona za pomocą plików DDL (Data Definition Language), które zawierają schemat tej tabeli i ponownie są podzielone między zespoły posiadające tę tabelę.

Lewy obraz przedstawia definicje potoku ETL podzielone między różne zespoły, a prawy obraz przedstawia definicje tabel (DDL) podzielone między zespoły danych. Ta segregacja podkreśla własność i odpowiedzialność różnych strumieni.

Każdy zespół ma następnie własne DAGs Airflow i tabele, które tworzą/aktualizują za pomocą tych DAG. W tym sensie użycie Airflow umożliwiło nam podzielenie jednego ogromnego DAG-a, który mieliśmy w Spoink, na wiele mniejszych DAG-ów; każdy należący do konkretnego strumienia z unikalnymi konfiguracjami planowania.

Wyniki

Rozszerzyliśmy przepływ powietrza, wprowadzając niestandardowe widoki przepływu powietrza, operatory, czujniki i haki, które są dostosowane do uruchamiania ETL na platformie Big Data firmy Ayden. W ten sposób zbudowaliśmy narzędzia i funkcje, które są wspólne dla różnych strumieni, jednocześnie dając strumieniom swobodę pracy nad rozwiązaniem do obsługi danych, w którym są ekspertami w dziedzinie.

Dzięki wbudowanej funkcji Airflow do zarządzania harmonogramami i definiowania w ramach zależności DAG nasze zespoły danych wykorzystały nowo zdobytą elastyczność i nagle były w stanie zdefiniować dziesiątki zadań ze skomplikowanymi zależnościami między sobą (pokazano przykładowy obraz)

Podczas gdy gotowe funkcje Airflow rozwiązały już wiele problemów, z którymi musieliśmy się zmierzyć w opracowanym przez nas frameworku, nadal napotkaliśmy wiele problemów operacyjnych związanych z uzupełnianiem i określaniem zależności w wielu DAG Airflow. W naszej następnej serii „Airflow at Adyen” głębiej zagłębiamy się w wyzwania, z jakimi musieliśmy się zmierzyć w związku z zależnościami między DAG i wypełnianiem kopii zapasowych oraz jak rozszerzyliśmy funkcje Airflow, aby rozwiązać te problemy.

Kariera techniczna w Adyen

Poszukujemy utalentowanych inżynierów i pracowników technicznych, którzy pomogą nam zbudować infrastrukturę globalnego handlu!

Sprawdź oferty pracy dla programistów

Biuletyn dla programistów

Otrzymuj na bieżąco nowe posty na blogu i inne wiadomości dla programistów.

"Zapisz się teraz"

Pierwotnie opublikowano na stronie https://www.adyen.com 19 maja 2021 r.