Nowe podejście Sprout Social do dużych zbiorów danych

Sprout Social jest w swej istocie firmą opartą na danych. Sprout codziennie przetwarza miliardy wiadomości z wielu sieci społecznościowych. Z tego powodu inżynierowie Sprout stają przed wyjątkowym wyzwaniem — jak przechowywać i aktualizować wiele wersji tej samej wiadomości (tj. retweetów, komentarzy itp.), które pojawiają się na naszej platformie w bardzo dużej liczbie.

Ponieważ przechowujemy wiele wersji wiadomości, inżynierowie Sprout mają za zadanie kilka razy dziennie „odtworzyć świat” — niezbędny proces, który wymaga iteracji całego zestawu danych w celu skonsolidowania każdej części wiadomości społecznościowej w jedno „źródło prawdy”.

Na przykład śledzenie polubień, komentarzy i retweetów pojedynczego posta na Twitterze. W przeszłości polegaliśmy na samodzielnie zarządzanych klastrach Hadoop, które utrzymywały i przetwarzały tak duże ilości danych. Każdy klaster Hadoop byłby odpowiedzialny za różne części platformy Sprout — praktyka, na której opiera się cały zespół inżynierów Sprout przy zarządzaniu projektami Big Data na dużą skalę.

Klucze do podejścia Big Data w Sprout

Nasz ekosystem Hadoop był zależny od Apache Hbase, skalowalnej i rozproszonej bazy danych NoSQL. To, co sprawia, że ​​Hbase ma kluczowe znaczenie dla naszego podejścia do przetwarzania dużych zbiorów danych, to jego zdolność nie tylko do szybkiego skanowania całych zbiorów danych, ale także do szybkiego, losowego wyszukiwania pojedynczych rekordów.

Hbase umożliwia nam również masowe ładowanie danych i aktualizowanie losowych danych, dzięki czemu możemy łatwiej radzić sobie z wiadomościami przychodzącymi w nieprawidłowej kolejności lub z częściowymi aktualizacjami oraz innymi wyzwaniami związanymi z danymi z mediów społecznościowych. Jednak samodzielnie zarządzane klastry Hadoop obciążają naszych inżynierów ds. infrastruktury wysokimi kosztami operacyjnymi, w tym ręcznym zarządzaniem odtwarzaniem po awarii, rozbudową klastra i zarządzaniem węzłami.

Aby pomóc skrócić czas potrzebny na zarządzanie tymi systemami z setkami terabajtów danych, zespoły ds. infrastruktury i rozwoju firmy Sprout połączyły siły, aby znaleźć lepsze rozwiązanie niż uruchamianie samodzielnie zarządzanych klastrów Hadoop. Naszymi celami było:

• Pozwól inżynierom Sprout na lepsze tworzenie, zarządzanie i obsługę dużych zbiorów danych
• Zminimalizuj czas poświęcany przez inżynierów na ręczne posiadanie i konserwację systemu
• Zmniejsz niepotrzebne koszty nadmiernej alokacji ze względu na rozbudowę klastra
• Zapewnij lepsze metody odzyskiwania po awarii i niezawodność

Oceniając alternatywy dla naszego obecnego systemu dużych zbiorów danych, staraliśmy się znaleźć rozwiązanie, które można łatwo zintegrować z naszymi obecnymi procesami i wzorcami oraz odciążyć trud operacyjny związany z ręcznym zarządzaniem klastrem.

Ocena nowych alternatywnych wzorców danych

Jednym z rozwiązań rozważanych przez nasze zespoły były hurtownie danych. Hurtownie danych działają jak scentralizowany magazyn do analizy i agregacji danych, ale bardziej przypominają tradycyjne relacyjne bazy danych niż Hbase. Ich dane są uporządkowane, filtrowane i mają ścisły model danych (tj. jeden wiersz dla pojedynczego obiektu).

W naszym przypadku przechowywania i przetwarzania wiadomości społecznościowych, w których istnieje wiele wersji wiadomości obok siebie, hurtownie danych miały nieefektywny model dla naszych potrzeb. Nie byliśmy w stanie skutecznie dostosować naszego istniejącego modelu do hurtowni danych, a wydajność była znacznie wolniejsza niż przewidywaliśmy. Ponowne sformatowanie naszych danych w celu dostosowania do modelu hurtowni danych wymagałoby znacznych nakładów pracy, aby przerobić je na osi czasu, którą mieliśmy.

Innym rozwiązaniem, które rozważaliśmy, były domy jezior danych. Domy jezior danych rozszerzają koncepcje hurtowni danych, aby umożliwić mniej ustrukturyzowane dane, tańsze przechowywanie i dodatkową warstwę bezpieczeństwa wokół wrażliwych danych. Chociaż centra danych oferowały więcej niż hurtownie danych, nie były tak wydajne, jak nasze obecne rozwiązanie Hbase. Testując nasz rekord scalania oraz nasze wzorce przetwarzania wstawiania i usuwania, nie byliśmy w stanie wygenerować akceptowalnych opóźnień zapisu dla naszych zadań wsadowych.

Zmniejszenie kosztów ogólnych i utrzymania dzięki AWS EMR

Biorąc pod uwagę to, czego dowiedzieliśmy się o hurtowniach danych i rozwiązaniach typu lakehouse, zaczęliśmy szukać alternatywnych narzędzi obsługujących zarządzaną Hbase. Chociaż zdecydowaliśmy, że nasze obecne wykorzystanie Hbase jest skuteczne w tym, co robimy w Sprout, zadaliśmy sobie pytanie: „Jak możemy lepiej obsługiwać Hbase, aby zmniejszyć obciążenie operacyjne, zachowując jednocześnie nasze główne wzorce użytkowania?”

Wtedy zaczęliśmy oceniać usługę zarządzaną Elastic Map Reduce (EMR) firmy Amazon dla Hbase. Ocena EMR wymagała oceny jego wydajności w taki sam sposób, w jaki testowaliśmy hurtownie danych i jeziora, na przykład testowanie pozyskiwania danych w celu sprawdzenia, czy może spełnić nasze wymagania dotyczące wydajności. Musieliśmy również przetestować przechowywanie danych, wysoką dostępność i odzyskiwanie po awarii, aby upewnić się, że EMR odpowiada naszym potrzebom z punktu widzenia infrastruktury/administracji.

Funkcje EMR udoskonaliły nasze obecne samozarządzane rozwiązanie i umożliwiły nam ponowne wykorzystanie naszych obecnych wzorców do odczytu, zapisu i wykonywania zadań w taki sam sposób, jak w przypadku Hbase. Jedną z największych zalet EMR jest wykorzystanie systemu plików EMR (EMRFS), który przechowuje dane w S3, a nie w samych węzłach.

Wyzwanie, które znaleźliśmy, polegało na tym, że EMR miał ograniczone opcje wysokiej dostępności, co ograniczało nas do uruchamiania wielu głównych węzłów w jednej strefie dostępności lub jednego głównego węzła w wielu strefach dostępności. Ryzyko to zostało ograniczone przez wykorzystanie EMRFS, ponieważ zapewniało dodatkową odporność na awarie w przypadku odzyskiwania po awarii i oddzielenie przechowywania danych od funkcji obliczeniowych. Używając EMR jako naszego rozwiązania dla Hbase, jesteśmy w stanie poprawić naszą skalowalność i odzyskiwanie po awarii oraz zminimalizować ręczną interwencję potrzebną do utrzymania klastrów. Ostatecznie zdecydowaliśmy, że EMR najlepiej pasuje do naszych potrzeb.

Proces migracji został z łatwością przetestowany wcześniej i wykonany w celu migracji miliardów rekordów do nowych klastrów EMR bez żadnych przestojów klienta. Nowe klastry wykazały lepszą wydajność i obniżone koszty o prawie 40%. Aby dowiedzieć się więcej o tym, jak przejście na EMR pomogło obniżyć koszty infrastruktury i poprawić naszą wydajność, zapoznaj się ze studium przypadku Sprout Social i AWS.

Czego się nauczyliśmy

Rozmiar i zakres tego projektu dał nam, zespołowi ds. inżynierii niezawodności bazy danych infrastruktury, możliwość współpracy międzyfunkcyjnej z wieloma zespołami inżynierskimi. Choć było to trudne, okazało się niesamowitym przykładem projektów na dużą skalę, którymi możemy się zająć w Sprout jako współpracująca organizacja inżynierska. Dzięki temu projektowi nasz zespół ds. infrastruktury lepiej zrozumiał, w jaki sposób dane Sprout są wykorzystywane, przechowywane i przetwarzane, dzięki czemu jesteśmy lepiej przygotowani do rozwiązywania przyszłych problemów. Stworzyliśmy wspólną bazę wiedzy dla wielu zespołów, która może pomóc nam w tworzeniu nowej generacji funkcji dla klientów.

Jeśli interesuje Cię to, co tworzymy, dołącz do naszego zespołu i już dziś aplikuj na jedno z naszych otwartych stanowisk inżynierskich.