Один из вариантов реализации Data Discovery в микросервисной архитектуре Базы данных и системы хранения
Chief Data Architect в ManyChat, отвечает за все pipeline и платформу данных для аналитики (хранилище, BI, ETL, интеграционные сервисы), все в AWS.
До этого — руководитель Data Platform в Avito. В область ответственности Data Platform входили системы больших данных (сотни Тб), OLTP-базы (PostgreSQL), NoSQL-базы (MongoDB, Redis, Tarantool, VoltDB), а также системы очередей и потоковой обработки данных (RabbitMQ, NSQ, Spark). Все про данные, их движение и обработку.
Помимо работы в ManyChat, Николай преподает в НИУ ВШЭ и занимается научными исследованиями в области современных методологий построения хранилищ данных, таких как Data Vault и Anchor Modeling, а также в области технологий BlockChain.
Тезисы
Представьте, что вы распиливаете монолит/реализуете микросервисную архитектуру на основе паттернов Database-per-service и Polyglot Persistence.
У каждого сервиса своя база, а иногда и несколько баз, данные ходят туда-сюда-обратно, выгружаются, кэшируются, изменяются, теряются вместе с упавшими серверами, восстанавливаются и консолидируются.
* Как оценить риски утечки данных?
* Как понять, какие части системы требуют внимания с точки зрения защиты персональных данных в широком смысле?
* Откуда лучше прогревать холодные кэши после старта сервиса в дев-тест-средах?
* Как отследить зависимости между сервисами А и Б, если данные между ними ходят через несколько промежуточных этапов сервисов?
* Как понять, какие сервисы могут пострадать, если в сервисе А меняется модель данных? Как найти потенциально затрагиваемых?
Много вопросов, и много потенциальных сложностей. Я хотел бы рассказать вам о концепции "Помнящей ткани", Persistence Fabric, которая, надеюсь, поможет решить сложности, и об элементах ее реализации на графовой СУБД Neo4J.
