Ефективна архітектура для обробки адрес у США
Стара система клієнта для парсингу адрес з Address Information System (AIS) і Topologically Integrated Geographic Encoding and Referencing (TIGER) була побудована на MS SQL Server і SSIS. Вона використовувала комбінацію збережених процедур, C# з регулярними виразами та функцій для парсингу, перевірки й очищення даних.
Ця система працювала, але не витримувала високого навантаження та великих обсягів даних. Ми розробили нову архітектуру BAIST, перенесли функції на Redis, оптимізували алгоритми, впровадили кешування та механізми видалення дублікатів. У результаті швидкість обробки зросла на 50%, а навантаження на трафік зменшилося.
Основні виклики в проєкті
Повільна робота
Коли система починала обробляти понад мільйон записів, швидкість значно падала. MS SQL Server і SSIS просто не могли масштабуватися під такий обсяг, а складні збережені процедури ще більше ускладнювали ситуацію. Для клієнта це було неприпустимо, оскільки швидкість обробки критично важлива для його бізнесу. Щоб вирішити це, ми вирішили повністю переглянути архітектуру.
Труднощі з контролем
Контроль за потоком даних у старій системі був ще однією суттєвою проблемою. Під час обробки запитів система відповідала повільно й непередбачувано. Це ускладнювало роботу, оскільки не було можливості точно знати, коли дані надійдуть. Крім того, ми не мали інструментів для швидкого реагування на ці затримки.
Щомісячні оновлення
Клієнт хотів отримувати нові дані кожного місяця. Однак, приблизно 80-90% цих даних були дублями тих, що вже були в системі. Постійне завантаження старої інформації призвело б до затримок і зайвого витрачання місця в сховищі. Нашою метою було розробити рішення, яке б розрізняло нові записи й ті, що вже є, щоб обробляти тільки свіжі дані.
Помилки введення
Алгоритми системи були занадто жорсткими, і через це система не могла враховувати дрібні помилки у введенні. Це призводило до того, що багато правильних адрес не знаходилися. Наприклад, якщо в назві вулиці чи міста була одна помилка в літері, система повертала негативний результат. Ми вирішили зосередитися на вдосконаленні алгоритмів, щоб система могла знайти правильні адреси навіть із незначними помилками у введенні.
Різні формати
Адреси Пуерто-Рико мають дещо іншу структуру, ніж стандартні адреси континентальної частини США. Але система обробляла їх однаково, що призводило до плутанини й помилок у даних. Це створювало багато помилок. Щоб виправити ситуацію, ми розробили окремий алгоритм, який адаптується до цих регіональних відмінностей.
Технічні обмеження
Комбінація MS SQL Server, SSIS та кастомних збережених процедур не була розрахована на стрімке зростання обсягів даних. Із розширенням системи її ставало все складніше контролювати та підтримувати. Було очевидно, що поточні технології досягли своїх меж, і нам потрібне більш гнучке та масштабоване рішення.
Етапи оптимізації системи обробки адрес
Ми виконали детальний аналіз продуктивності за допомогою JetBrains DotTrace. Це дозволило нам оцінити швидкість кожної функції та визначити вузькі місця системи. Основна увага була зосереджена на MSSQL запитах і алгоритмах парсингу адрес, які спричиняли найбільші затримки.
Щоб підвищити продуктивність, ми перенесли дані з MSSQL, де вони зберігалися у форматі JSON, до Redis. Це забезпечило швидші операції читання/запису та краще управління великими обсягами даних. Крім того, ми розподілили дані між кількома екземплярами Redis, що оптимізувало процеси парсингу адрес і геокодування. Така розподілена архітектура дозволила значно прискорити обробку даних.
Ми реалізували попередньо скомпільовані MSSQL запити для прямої взаємодії з Redis, що дало змогу пришвидшити обробку даних між алгоритмами парсингу та базою даних. Команда Intsurfing розробила шість алгоритмів (один спеціально для Пуерто-Рико), які дозволяють системі знайти правильну адресу навіть з незначними помилками введення. Ми також розбили ZIP+4 на дві частини: перша частина використовувалася для початкового парсингу, друга — для формування повної адреси.
Щоб мінімізувати зайві операції, ми впровадили внутрішню систему кешування. Це дало змогу зберігати та швидко отримувати доступ до нещодавно оброблених записів. Завдяки цьому швидкість системи значно покращилася, особливо під час пакетної обробки, де часто траплялися схожі дані. Для масштабування й видалення дублікатів ми використовували Hadoop, а для індексації застосували Apache Solr, що покращило пошук і доступ до даних у всій системі.
Протягом проєкту ми постійно тестували систему за допомогою JetBrains DotTrace, щоб гарантувати, що кожен компонент працює з максимальною ефективністю. На основі цих тестів ми налаштовували алгоритми та механізми кешування, щоб досягти потрібної швидкості, масштабованості та продуктивності.
Технології, які ми використовували в проєкті
REDIS
MS SQL
C#
Hadoop
Apache Solr
JetBrains DotTrace
Результати: підвищена швидкість і масштабованість
Ми створили добре структурований, масштабований довідник адрес на основі даних із AIS та TIGER. Нова система автоматично доповнює неповні адреси (місто, індекс або штат) та включає потужний механізм перевірки для точності всіх елементів адреси.
- Швидкість обробки даних зросла вдвічі
- Скорочення трафіку обробки на 40% через використання структурованих довідників
- Стабільна й легко масштабована система, яка обробляє понад 1 мільйон записів
- Оптимізована пакетна обробка завдяки кешуванню
- Видалення дублікатів для швидкого та ефективного завантаження нових даних
- Нові алгоритми для виявлення адрес навіть із помилками
Перетворіть великі дані на ваші можливості
Зв'яжіться з нами сьогодні. Ми розглянемо ваш проєкт, надамо індивідуальне рішення та кошторис, і почнемо працювати, як тільки ви погодитесь.
Зв'яжіться з нами
Заповніть форму з проєктними даними, щоб ми могли запропонувати вам персоналізоване рішення.
