Еще в свое время, когда я работал в одной из предыдущих компаний — я столкнулся с необходимостью настройки репликации данных. На тот момент мы были быстрорастущим стартапом и, как и большинство стартапов, допустили немало ошибок на этапе активного роста. Имея микросервисную архитектуру, у нас не было достаточно времени, чтобы хорошо их спроектировать. Это привело нас к ситуации, когда у нас была микросервисная архитектура, которая больше напоминала монолитную. 95% коммуникаций осуществлялось посредством прямых HTTP-вызовов. Это было именно то, что нас подвело.
В периоды пиковой нагрузки у нас было больше внутренних звонков, чем внешних. Я знаю, о чем вы думаете — «Они, должно быть, тупые», и я бы сказал, не до конца :)
Большинство функций мы создавали в краткосрочной перспективе, жертвуя стабильностью с большими надеждами исправить это позже.
Большинство проблем было вызвано сервисами, которые содержали важные данные, на которые нам приходилось полагаться в других сервисах. Таким образом, при каждом вызове клиента нам приходилось делать более двух базовых вызовов, чтобы вернуть эти данные. (Кэширование не было возможным, поскольку данные не могли быть старыми из-за требований)
Вскоре эти службы стали называться SPOF (единая точка отказа), и нам нужно что-то делать. Мы придумали внедрение CDC (также известного как репликация данных), на внедрение которого потратили бесчисленные часы, находя подходящие сервисы, инструменты и т. д. Но в конце концов это помогло. Нам удалось построить действительно великолепную архитектуру, которая без проблем выдерживает часы пик.
Теперь, когда предыстория установлена, давайте поговорим о пути, который мы проделали, чтобы решить наши проблемы с CDC.
Я могу сказать наверняка: CDC — это не волшебная таблетка, она, возможно, не решит всех ваших проблем, но может помочь вам выиграть драгоценное время для роста, поддерживая вовлеченность ваших клиентов и собирая больше денег для переписывания вашей архитектуры в будущем.
Видите ли, проблема здесь в том, что большинство служб репликации/ETL сосредоточены на нескольких вещах:
- База данных на склад для выполнения аналитики
- Полная репликация базы данных в базу данных без преобразований
В частности, когда вы начнете гуглить реализацию CDC, вы найдете массу ссылок на такие проекты, как Confluent.io и Debezium.
Не поймите меня неправильно, это проекты, которые продвигают вперед индустрию CDC, но они чрезвычайно сложны, когда вы видите их впервые в жизни. И вы, как технический директор/технический руководитель стартапа, обычно не можете позволить себе тратить столько времени на эти вещи, не зная, сработают они или нет.
Встречайте DataBrew
DataBrew — это SaaS-проект, который обеспечивает простой способ интеграции CDC (Change-Data-Capture) в вашу архитектуру. По сути, путем создания сетки данных, в которой вы определяете данные, которые предоставляют ваши службы, и любая служба может их использовать.
Мы постарались собрать все знания, полученные в ходе экспериментов и сопровождения CDC, и создать продукт, который поможет разработчикам.
DataBrew был создан с учетом нескольких целей:
- Мы хотим дать разработчикам больше времени для работы над бизнес-логикой и написанием кода, а не тратить бесчисленные часы на отладку Kafka.
- Мы хотим дать разработчикам самое главное — представление реальных потоков данных. Таким образом, они могут видеть все потоки данных, поступающие в сервис, и наоборот.
- Мы хотим иметь строгие контракты на передачу данных. Даже если ваш сервис имеет 45 таблиц, вы все равно можете определить, что он экспортирует только 2 из них. Чтобы люди не слепо создавали DataFlows, не задумываясь о стабильности системы.
- Мы хотим сделать его надежным. Внедрение #CDC может показаться немного рискованным решением, но при правильном оповещении и мониторинге беспокоиться не о чем.
В настоящее время мы работаем в режиме закрытой бета-версии, но собираемся открыть DataBrew для публичного доступа в сентябре этого года.
Смело подавайте заявку на ранний доступ — мы свяжемся с вами как можно скорее, чтобы обсудить все детали.
Имейте в виду, что во время закрытой бета-версии мы поддерживаем только базу данных PostgeSQL.
Спасибо за прочтение статьи! Мы надеемся, что смогли пробудить в вас интерес и дать шанс DataBrew.
Спасибо, что дочитали до конца. Пожалуйста, подумайте о том, чтобы подписаться на автора и эту публикацию. Посетите Stackademic, чтобы узнать больше о том, как мы демократизируем бесплатное образование в области программирования во всем мире.
Полезные ссылки
- Сайт проекта: https://databrew.tech
- Документация DataBrew — https://docs.databrew.tech/
- Твиттер: https://twitter.com/@usedatabrew
- Электронная почта: [email protected]
