Ефективна архітектура для обробки адрес у США
Стара система клієнта для парсингу адрес з Address Information System (AIS) і Topologically Integrated Geographic Encoding and Referencing (TIGER) була побудована на MS SQL Server і SSIS. Вона використовувала комбінацію збережених процедур, C# з регулярними виразами та функцій для парсингу, перевірки й очищення даних.
Ця система працювала, але не витримувала високого навантаження та великих обсягів даних. Ми розробили нову архітектуру Black stork, перенесли функції на Redis, оптимізували алгоритми, впровадили кешування та механізми видалення дублікатів. У результаті швидкість обробки зросла на 50%, а навантаження на трафік зменшилося.
Основні виклики в проєкті
Niska wydajność
System zaczynał zwalniać podczas przetwarzania ponad miliona rekordów. MS SQL Server i SSIS nie były w stanie skalować się do takiego wolumenu, a złożoność procedur składowanych dodatkowo pogarszała sytuację. Opóźnienia były nieakceptowalne dla klienta, który potrzebował szybkiego przetwarzania na potrzeby operacji biznesowych. Aby rozwiązać problem, musieliśmy całkowicie przeprojektować architekturę.
Trudne zarządzanie
Kontrolowanie przepływu danych w starym systemie było kolejnym poważnym wyzwaniem. Przetwarzanie żądań i odpowiedź systemu trwały długo, a opóźnienia były nieregularne. Nie można było przewidzieć, kiedy dane faktycznie zostaną dostarczone. Brakowało nam również narzędzi pozwalających podejmować działania naprawcze w przypadku opóźnień.
Aktualizacje
Jednym z głównych wymagań klienta było otrzymywanie świeżych danych co miesiąc. Około 80–90% nowych danych okazywało się duplikatami rekordów już zapisanych w systemie. Wielokrotne ładowanie tych samych danych powodowałoby zbędne opóźnienia i zajmowało przestrzeń dyskową. Naszym celem było wdrożenie rozwiązania rozróżniającego nowe i istniejące rekordy oraz dopuszczającego do przetwarzania wyłącznie świeże dane.
Nieprawidłowe dane wejściowe
Rygorystyczne algorytmy dopasowywania nie uwzględniały drobnych różnic, przez co nie odnajdywano wielu prawidłowych adresów. Jeśli na przykład w nazwie ulicy lub miasta występowała pomyłka w jednej literze, system zwracał wynik negatywny. Skoncentrowaliśmy się więc na ulepszeniu algorytmów, aby zwracały prawidłowe rezultaty również przy niewielkich błędach w danych wejściowych.
Różne formaty
Adresy w Portoryko mają nieco inną strukturę niż standardowe adresy w kontynentalnej części Stanów Zjednoczonych. System traktował wszystkie adresy jednakowo, co w przypadku adresów portorykańskich prowadziło do błędnej interpretacji i niedopasowania danych. Powodowało to dużą liczbę błędów. Aby rozwiązać problem, musieliśmy zaprojektować osobny algorytm uwzględniający różnice regionalne.
Ograniczenia technologiczne
Połączenie MS SQL Server, SSIS i niestandardowych procedur składowanych nie zostało zaprojektowane z myślą o szybkim wzroście wolumenu danych. Wraz z rozwojem system stawał się coraz trudniejszy w zarządzaniu i utrzymaniu. Było jasne, że używane technologie osiągnęły swoje granice i potrzebne jest bardziej elastyczne, skalowalne rozwiązanie odpowiadające zmieniającym się potrzebom klienta.
Етапи оптимізації системи обробки адрес
Przeprowadziliśmy szczegółową analizę wydajności za pomocą JetBrains DotTrace. Pozwoliło nam to zmierzyć szybkość każdej funkcji i wskazać elementy spowalniające system. Skupiliśmy się przede wszystkim na zapytaniach MSSQL i algorytmach parsowania adresów, które odpowiadały za największe wąskie gardła.
Aby zwiększyć wydajność, przenieśliśmy dane z MSSQL, gdzie początkowo były przechowywane w formacie JSON, do Redis. Zapewniło to szybsze operacje odczytu i zapisu oraz lepszą obsługę dużych zbiorów danych. Rozdzieliliśmy też dane między wiele instancji Redis, co usprawniło parsowanie i geokodowanie adresów. Rozproszona architektura pozwoliła systemowi przetwarzać dane znacznie szybciej.
Wdrożyliśmy wstępnie skompilowane zapytania MSSQL bezpośrednio współpracujące z Redis, co przyspieszyło przepływ danych między algorytmami parsowania a bazą. Programiści NannosTech opracowali sześć algorytmów, w tym jeden przeznaczony specjalnie dla Portoryko. Dzięki nim system odnajduje właściwy adres nawet przy drobnych błędach wejściowych. Podzieliliśmy również rekordy ZIP+4 na dwie części: pierwsza służy do początkowego parsowania, a druga do zbudowania pełnego wyniku adresowego.
Aby ograniczyć zbędne operacje, wprowadziliśmy wewnętrzny system cache. Umożliwiło to przechowywanie ostatnio przetworzonych rekordów i szybki dostęp do nich. Dzięki temu system działał szybciej, zwłaszcza podczas przetwarzania wsadowego, w którym często pojawiały się podobne dane. Do skalowania i deduplikacji użyliśmy Hadoop. Apache Solr służył do indeksowania, poprawiając wyszukiwanie i pobieranie danych w całym systemie.
Przez cały projekt regularnie testowaliśmy system za pomocą JetBrains DotTrace, aby upewnić się, że każdy komponent działa z optymalną wydajnością. Na podstawie wyników dostrajaliśmy algorytmy i mechanizmy cache, dzięki czemu końcowe rozwiązanie spełniło wyznaczone cele dotyczące szybkości, skalowalności i wydajności.
Технології, які ми використовували в проєкті
REDIS
MS SQL
C#
Hadoop
Apache Solr
JetBrains DotTrace
Результати: підвищена швидкість і масштабованість
Ми створили добре структурований, масштабований довідник адрес на основі даних із AIS та TIGER. Нова система автоматично доповнює неповні адреси (місто, індекс або штат) та включає потужний механізм перевірки для точності всіх елементів адреси.
- Швидкість обробки даних зросла вдвічі
- Скорочення трафіку обробки на 40% через використання структурованих довідників
- Стабільна й легко масштабована система, яка обробляє понад 1 мільйон записів
- Оптимізована пакетна обробка завдяки кешуванню
- Видалення дублікатів для швидкого та ефективного завантаження нових даних
- Нові алгоритми для виявлення адрес навіть із помилками
