bebyk написав:frz написав:Сервер API при завантаженні великих кількостей даних починає відповідати 500 Internal Server Error (наче звична ситуація для стартапів, коли на серваки дали мінімум ресурсів поки продукт не "вистрілить"). І це ще не найцікавіше, бо це так звана false-positive відповідь: насправді часто дані завантажені успішно, просто сервер не мав ресурсів аби відповісти з коректним джейсоном. Але коли мільйони записів просто пробувати знову, це не дуже продуктивно. Тож почав шукати рішення і щось наче знайшов - веду лог завантажених даних, записую як успішні так і неуспішні відповіді. Збільшив таймаути і встановив певну кількість повторних спроб при 500 Internal Server Error. При спробі завантажити ті ж дані знову, сервер відповідає (якщо йому достатньо ресурсів для цього) - "Already exists", такі відповіді теж записую в лог і наступного разу відфільтровую такі записи щоб зменшити кількість false-positive відповідей. Проблема що "Already exists" повертається не коректним джейсоном, тому доводиться парсити потрібні шматки і потім застосовувати try...except аби перетворювати відповідь у коректний dict.
Цікаво, що за бекенд використовуєте для API? Наприклад, Akka мав би опрацьовувати не пожираючи багато ресурсів (принаймні вертикально).
Сам сервер API - це інший самостійний продукт, до якого я поки що не маю стосунку (пропозиції з мого боку щодо його оптимізації - є в планах SEO, але це буде одне з наступних завдань для мене). Основна мова там - Python, детальніше поки що не скажу.
bebyk написав:І чому не користуватися Kafka? Там і розподілена черга, і dedupliсation без костурів (і зайвих викликів до API). Чи й на це не вистачає бюджету?
Тут було так. Я накидав проект дизайну клієнтської аплікації на Python + Flask з розумінням що треба буде застосовувати батчі і паралельний процесинг. Почитали CEO, CTO i дата сцаєнтист, ні в кого зауважень не було. Про те що на самому сервері API недостатньо ресурсів - на тому етапі я ще не знав, хоча знаючи що це стартап - мав би здогадуватися. Продуктові об'єми даних отримав через декілька місяців розробки.
З Kafka я ще не стикався. Зате працював із PySpark. Але ж толку з того що на стороні клієнта я застосую рокет сцаєнс, якщо сервер не вигрібає.
Ну і в принципі батчів і concurrent.futures поки що достатньо. Процес дедуплікації особливо не складний на рівні pandas. Основну проблему я описав - це false-positive відповіді від API, коли ресурсів сервера не вистачає для віддачі коректного json з результатами обробки батчу.
Також завжди можна зменшити розмір батчів і кількість concurrent процесів. Тут взагалі вимог не було, це я сам придумав що за допомогою concurrent.futures можна мінімізувати час обробки. Тепер завдяки логуванню і парсингу негативних відповідей сподіваюся довести це до якогось вигляду.
----
Upd:
bebyk написав:зайвих викликів до API
Із false-positive відповідями від API частина запитів все одно буде надсилатися повторно; не існує такої рокет сцаєнс технології, яка б здогадувалася із стовідсотковою імовірністю про успіх запиту, якщо сервак відповідає 500 Internal Server Error.
Вже наступного разу, коли на запит приходить "already exists", то цю відповідь записуємо в лог і на підставі обробки логу більше цей запис надалі не надсилаємо.
Цей та інші нюанси на минулих проектах призвели до того, що куплені ETL-рішення у порівнянні з власними розробками програвали, бо не враховували важливі моменти.
