Ссылка на видеодоклад https://www.youtube.com/watch?v=yYp6Nqf-SME
Всем привет. Я Николай Голов. Расскажу вам про микросервисы, но немного с другой точки зрения. Авито большая компания. Мы недавно стали вторым classified на планете. Небольшая приписка: "А еще мы монолит пилим".
Я считаю себя разработчиком баз данных (далее просто база). И тут внезапно вопрос: при чем тут микросервисы? Я возглавляю в Авито Data платформу. Мы занимаемся всеми базами, которые используются в Авито: Vertica, PostgreSQL, Redis, MongoDB, Tarantool, VoltDB. Cамая наша любимая база SQLite. Баз много. У нас сотни сервисов. У нас сотни баз.
Как должна быть построена микросервисной архитектура с точки зрения баз все неплохо знают. Вот паттерн с которого все обычно начинают. Есть общая база между сервисами. На слайде оранжевые это сервисы и между ними общая база.
Так жить нельзя, потому что вы не можете изолировано тестировать сервис, когда между ними помимо прямой связи есть еще вот такая связь через базу. Один сервис запросами может замедлять другой сервис. Это плохо.
С точки зрения работы с базами для микросервисной архитектуры должен применятся паттерн DataBase-per-Service - у каждого сервиса своя база. Если в базе много шардов, то база должна быть общая чтобы они синхронизировались.
Это теория, а в реальности все не так. В реальных компаниях используют не только микросервисы, но и монолит. Есть сервисы написанные правильно. Есть старые сервисы, которые до сих пор используют паттерн с общей базой.
Вадим Мэдисон на своей презентации показывал эту картину со связанностью. Только он не показывал без одного компонента и была равномерна сеть. В этой сети в центре есть точка, которая связана с многими точками (микросервисами). Это монолит. Он небольшой на схеме. На самом деле монолит большой. Когда мы говорим про реальную компанию, то вам нужно понимать нюансы сосуществования микросервисный возрождающиеся и уходящий, но по прежнему важной монолитической архитектуры.
С чего начинается переписывание монолита на микросервисную архитектуру на уровне планирования? Правильно доменное моделирование. Во всех пунктах написано что нужно сделать доменное моделирование. Мы в Авито несколько лет создавали микросервисы без доменного моделирования.
Вопрос: кто в компании может сделал доменное моделирование? Ответ из зала: Никто. Это тоже правильный ответ, но есть люди, которые могут попробовать. У нас в Авито так получилось что есть архитекторы, которые занимаются микросервисами. Но доменное моделирование делал я и разработчики баз данных. Мы имеем представление о полных потоков данных. Эти знания неплохо помогают спроектировать доменную модель.
У Data discovery есть классическая интерпретация - это как работать с данными разбросанными по разным хранилищам чтобы приводить к совокупным выводам и делать какие-нибудь правильные выводы. На самом деле это все маркетинговый bullshit. Эти определения про то как все данные с микросервисов загрузить хранилище. Про это у меня были доклады несколько лет назад.
Я вам расскажу про другой процесс, который ближе к процессу перехода на микросервисы. Хочу показать способ как вы можете осознать сложность непрерывно эволюционирующей системы с точки зрения данных, с точки зрения микросервисов. Где посмотреть цельную картину сотен сервисов, баз, команд, людей? Фактически этот вопрос является основной идеей доклада.
Чтобы в этой микросервисной архитектуре не умереть, вам нужен digital twin. Ваша компания это совокупность всего что обеспечивает технологическую инфраструктуру. Вам нужно создать адекватный образ всех этих сложностей, на основе которых можно быстро решать задачи. И это не аналитическое хранилище.
Кстати digital один из главных хайпов. Это уже круче blockchain.
Какие задачи мы можем поставить такому digital twin. Все начиналось с data discovery.
Вопросы:
- В каких сервисах хранятся важные данные?
- В каких не хранятся персональные данные?
- У вас сотни баз. В каких персональные данные есть? А в каких нет?
- Как важные данные ходят между сервисом?
- Например, в сервисе не было персональных данных, а потом он начал слушать шину и они появились. Куда данные копируются когда стираются?
- Кто с какими данными может работать?
- Кто может получить доступ напрямую через сервис, кто через базу, кто через шину слышать?
- Кто через другой сервис может дернуть API ручку (запрос) и себе что-то скачать?
Ответ на эти вопросы практически всегда является граф элементов, граф связей. Этот граф нужно наполнить, актуализировать и поддерживать свежими данными.
Мы этот граф решили назвать Persistent Fabric (в переводе помнящая ткань). Посмотрим что в этой помнящей ткани может быть.
Точки интерфейса. Начнем с пользователей. Это элементы пользовательского взаимодействия с графическим интерфейсом. На одной странице может быть несколько UI points. Это пользовательские ключевые действия, которые пользователь делает.
Endpoint. UI points дергают Endpoint. В русской традиции это называется ручками. Ручки сервисов. Endpoint дергают сервисы.
Сервисы. Сервисов сотни. Сервисы связаны друг с другом. Мы понимаем какой сервис может дернуть сервис. Мы понимаем какой вызов UI points может вызвать какие сервисы по цепочке. Это только начало.
Базы в логическом смысле. База как термин хранилища плохо звучит потому что под этим термином понимается что то аналитическое. Сейчас мы рассматривает базу как storage. Например, redis, postgresql, tarantool. Если сервис использует базу, то обычно использует несколько баз.
- Для долговременного хранения данных, например PostgreSQL.
- Redis используется как кэш.
- Tarantool, который может что-то быстро посчитать в потоке данных.
Хосты. У базы есть развертывание на хосты. Одна база, один redis на самом деле может жить на 16 машинах (мастер кольцо) и еще на 16 живут slave. Это даст понимание того к каким серверам нужно ограничивать доступ чтобы какие-то важные данные не утекли.
Сущности. В базах хранятся сущности. Примеры сущностей: пользователь, объявление, платеж. Сущности могут храниться в нескольких базах. И тут важно не просто знать что эта сущность там есть. Важно знать что у этой сущности 1 storage является Golden Source. Golden Source это база где сущность создается и редактируется. Все остальные базы являются функциональными кешами. Важный момент. Если не дай бог у какой-то сущности 2 golden source, то необходимо трудоемкое согласование разделенных источников. Сущностям лежащими в базе нужно выдать доступ для сервиса, если хотим этом сервис обогатить новой функциональностью.
Команды. Команды, которые владеют сервисами. Сервис, который не принадлежит командам, это плохой сервис. Трудно найти ответственного для такого сервиса.
Сейчас буду сильно коррелировать с докладом Вадима Мэдисона, потому что он упоминал что в сервисах отражается человек, который туда последним делал commit. Это неплохо как отправная точка для того, чтобы для сервиса найти крайне unit. В долгосрочной перспективе это плохо, потому что человек который последний туда делал commit может уволиться.
Поэтому нужно знать команды, людей в командах с их ролями. У нас получился такой простенький граф, где на каждом слое несколько сотен элементов. Знаете ли вы систему где вот это все можно хранить?
Ключевой момент. Чтобы этой Persistent Fabric жил, он должна не просто один раз наполнится. Можно всех разработчиков попросить заполнить, но Persistent Fabric должен жить. Так как сервисы создаются, умирают, storage выделяются, перемещаются по серверам, команды создаются, разбиваются, люди переходят в другие команды. Сущности появляются новые, добавляются в новые сервисы, удаляются. Endpoint создаются, регистрируется, пользовательские траектории с точки зрения GUI тоже переделываются.
Самое важное не то что где-то это технически хранить. Самое важное сделать так чтобы каждый слой Persistent Fabric был свежим и актуальным. Чтобы он актуализировался.
Предлагаю пройтись по слоям. Проиллюстрирую как делается у нас. Покажу как это можно сделать на уровне отдельных слоев.
Информацию про команды можно взять из организационной структуры 1С. Для заполнения Persistent Fabric не нужно заполнять весь гигантский граф. Нужно чтобы каждый слой правильно заполнялся.
Информацию про людей можно взять из LDAP. Один человек может в разных командах занимать разные роли. Это абсолютно нормально. Сейчас мы хотим сделать новую систему авито people и из нее брать людей, но это не так важно. Самое главное чтобы такие простейшие данные шли, чтобы хотя бы сохраняли ссылки на концы. Чтобы названия команд соответствовали командам из организационной структуры 1С.
Сервисы. Для сервиса нужно получить название и команду, которая им владеет. Источник это service discovery. Service discovery это та система, которую упоминал Вадим Мэдисон под названием Atlas. Atlas - общий реестр сервисов.
Важный нюанс. В Atlas сервисы есть не все. Почти все такие системы типа Atlas хранят информацию про 95% сервисов. 5% сервисов в таких системах отстутвуют, т.к. сервисы старые, созданные без регистрации в Atlas. Когда вы начинаете с этой схемой работать, вы чувствуете, чего вам не хватает.
Storages это обобщенные хранилища. Это может быть postgresql, mongodb, memcache, vertica. Есть несколько источников storage discovery. Для nosql баз используется своя половинка атласа. Для информации о postgresql базах применяется парсинг yaml. Но они хотят сделать свой storage discovery более правильным.
Итак, storages и информация о том, что сервис использует, ну или владеет (это разные типы) владеет storage. Смотрите, все, что я описал, в принципе, довольно просто.
Что с этим можно делать? Давайте представим, что это граф. Как работать с графом? Добавить его в графовую базу. Например, в neo4j. Это уже примеры реальных запросов и примеры результатов этих запросов.
Первый сценарий. Нам нужно выдавать права на базу. База должна быть строго в сервисе. Туда должен входить только этот сервис и только члены команды, которая сервисом владеет. Но мы живем в реальном мире. Довольно часто другим командам полезно сходить в базу другого сервиса. Вопрос: у кого спросить о выдаче прав. Реально большая проблема для сотни баз понять кто там главный. Кто ее создавал, давно уволился или перешел на другую должность, вообще не помнит, кто с ней работает.
И тут простейший графовый запрос (neo4j). Вам нужен доступ к storage. Вы от storage идете к сервису, который владеет им. Переходите в команду, которая владеет сервисом. Дальше для сервиса вы узнаете, кто у этой команды TechLead. В Авито у продуктовых команд есть технический руководитель и продуктовый руководитель, который не сможет помочь по базам. Это на самом деле только половина запроса. Доступ к storage это не атомарная операция. Чтобы получить доступ к storage нужно получить доступ к серверам, на которых он установлен.
Это довольно интересная отдельная задача. Для этого мы добавляем новую сущность. Это инсталляция. Здесь терминологическая проблема. Есть storage, например redis база (redis:address). Есть host - это может быть физическая машина, lxc-контейнер, kubernetes. Установка storage на хост мы называем Instance.
В примере показана 4 установки 1 storage (redis) на 3 хоста. Storage для production разумно установить на отдельные физические машины для увеличения performance. Для development среды вам достаточно установить на 1 хост и назначить redis разные порты.
Первый запрос по выдаче прав на базу ушел к руководителю. Руководитель подтвердил что права можно выдать.
Вторая часть запроса. Второй запрос от storage идет к instance и host. Этот запрос рассматривает все инсталляции для соответствующего окружения. На слайде пример для production окружения. Исходя из этого выдаются уже права на подключение к конкретным хостам, конкретным портам. Это был пример запроса по выдаче прав для сотрудника не из команды.
Рассмотрим пример, когда в команду нужно взять нового сотруднику. Новому сотруднику нужно выдать доступ (для начала readonly) ко всем сервисам, ко всем storage этой команды. На слайде реальная команда с неполной выборкой. Зеленые круги это руководители команд. Красные это команды. Желтые это сервисы. У ряда жёлтых сервисов есть storage. Синие это storage. Серые это хосты. Фиолетовые это инсталляции storage на хосты. Это пример небольшого unit. Есть много юнитов, у которых сервисов не 7, а 27. Для таких юнитов картинка будет большая. Если использовать есть Persistent Fabric, вы можете сделать запросы в ней и получить ответы списком.
Сущности в Авито это объявления, пользователи, платежи и так далее. Из моих докладах про хранилища данных вы знаете что в Авито этих сущностей сотни. На самом деле все их логировать не обязательно. Откуда можно получить список сущностей? Из аналитического хранилища. Из аналитического хранилища можно выгрузить информацию о том, откуда они эту сущность берут. На первом этапе этого достаточно.
Для каждой сущности необходимо составить список хранилищ где это сущность хранится. Там же указываем что storage же хранит сущность как кэш или storage хранит сущность как golden source - является ее первоисточником.
Когда вы заполняете этот граф, у вас появляется возможность делать запросы к этому графу. У вас есть некоторая сущность и вам нужно понять: в каких сервисах живет сущность, в каких storage, на какие хосты инсталлирована?
При обработке персональных данных нужно уничтожать лог-файлы. Для этого очень важно понять на каких физических машинах могут остаться лог-файлы.
На слайде иллюстрация простого запроса для воображаемой сущности. Количество storage уменьшено чтобы граф влез на слайд. Красные круги это сущности. Синие круги это базы где эта сущность находится. Остальные как на предыдущих слайдах. Серые круги это хосты. Фиолетовые это инсталляции storage на хосты.
Если вы хотите пройти PCI DSS вам нужно ограничить доступ к определенным сущностям. Для этого вам нужно ограничить доступ к серым кругам. Если нужно имеется ввиду real-time доступ, то закрываем доступ к фиолетовым кругам. Эта статическая информация.
Когда мы говорим про микросервисную архитектуру самое важное это то что она меняется. Важно иметь не просто иерархическую связь между сущностями, но и одноуровневые связи. Связка сервисов - пример одноуровневых связей, которую мы неплохо прокачали и используем. Связка вида сервис вызывает сервис. Тут есть информация о прямых вызовах - сервис вызывает API другого сервиса.
Здесь также должна быть информация о связи вида: сервис №1 отправляет в шину (очередь) события, a service №2 на это событие подписан. Это похоже на асинхронную медленную связь проходящую через шину. Такая связь важна с точки зрения движения данных. С помощью подобных связей можно проверить работу сервисов, если поменялась версия сервиса, на которые они подписаны.
Есть сущность и мы знаем что она хранится в определенных storage. Если мы рассматриваем задачу поиска точек использования сущности, то очевидный запрос, который у нас возникает это проверка периметра. Storage принадлежат некоторым сервисам. Куда эта сущность может быть утечь (скопирована) из периметра. Она может утечь через вызовы сервисов. Сервис обратился, получил и сохранил у себя пользователя. Она может утечь через шины. Шины могут вас могут быть соединены друг с другом используя RabbitMQ, Londiste. На слайде landis мы еще не подгрузили. А вот вызовы уже подгрузили.
Вот пример реального запроса: объявление, две базы где оно хранится, два сервиса, которые владеют этими базами. После трех колонок идут сервисы, которые работают с сервисами, владеющими этой сущностью. Это потенциальные утечки, которые стоит добавить.
Endpoints. Вадим упоминал, что для построения реестра endpoints сервисов можно использовать документацию. Можно сделать запрос в атлас. Эту информацию также можно получить из мониторинга. Если Endpoint важный, то сами разработчики добавят его в мониторинг. Если Endpoint не мониторится, то он нам не нужен.
Из мониторинга можно получить метрики. Привязка метрик к storage, к сервисам, к хостам, к instance (шардам баз) и endpoint.
Когда у вас возникает сбой, например endpoint выдает HTTP код 500, то чтобы отследить корень проблемы необходимо сделать запрос по этому endpoint. От endpoint переходите к сервису, переходите к сервисам, которые этот сервис вызывает, от сервисов идете к storage, от storage идете instance и хостам.
Дальше найдя этот граф вниз, вы можете взять и получить по ним мониторинги. Вы можете посмотреть для этого endpoint всю цепочку вниз что можно вызвать сбой. В микросервисной архитектуре сбой на endpoint, может быть вызван сбоем сети на каком-то сервере, на котором развернут 1 шард базы. В мониторинге это видно, но при большой структуре сервисов, проверять все сервисы в мониторинге очень трудозатратно.
Тестирование. Вадим описывал кейс как можно тестировать микросервисы в изоляции. Но на самом деле чтобы адекватно тестировать, вам нужно тестировать сервис с другими сервисами, которые нужны ему для работы. Вам нужно поднять в вашем тестовом окружении сервисы, которые он вызывает. А для вызываемых сервисов поднять все базы. Получается связный подграф. В этом графе не все связи нужны. Некоторыми связями можно пренебречь. Этот подграф изолировано нагрузочно тестировать как полностью замкнутую систему.
Изолированные подграфы микросервисов, которые можно поднять независимо, можно тестировать и выкатывать в production. На самом деле, оказалось что подграф вызовов у любого микросервиса входит и выходит из монолита. Монолит он ходит, выходит практически везде. Если разрабатывать микросервисы и не думать о таких последствиях, то в итоге микросервисная архитектура все равно не будет работать без монолита и изолированное тестирование не позволяет.
Подобное графовое представление позволяет вам найти кандидаты изолированных подграфов. Это подмножество сервисов почти готово для того чтобы работать изолировано. Необходимо отрефакторить пару вызовов. Это позволяет приоритезировать разбиение монолита в части уменьшения связанности архитектуры.
Поддержка и наполнение. Это довольно просто сделать при соблюдении небольших правил.
Нельзя заставлять людей заполнять все зависимости всех сервисов. Нужно чтобы каждый источник заполнял только свой небольшой кусок информации. Слой сервисов заполняется из основного источника. Отсутствующие в этом источнике сервисы заполняются из ручных инструментов. Из второго источника заполняются storage. Из третьего сервера. Из четвертого endpoint. Из отдельных источников заполняются ссылки что сервис принадлежит команде, что человек стал TechLead команды. Информация должна заполнятся быстро и просто.
Далее информация о графе с соблюдением историчности должна загружаться в базу. Здесь очень важна историчность. Так как реальная микросервисная архитектура постоянно дышит и меняется. Сервисы возникают, умирают, появляются новые базы, появляется connection, старый connection отменяют, люди ходят между командами. При расследовании инцидентов полезно знать в каком сервисе живет сущность и в каком сервисе сущность жила раньше. Нужно что все связи были историчны. Как делать граф исторических связей можно узнать в моих докладах про анкор modeling.
Большинству людей для того чтобы работать с данными историчность не нужна. Им нужен актуальный срез на сейчас. На основании исторического графа должна строится витрина графа на текущий момент. В Авито используется база данных Neo4j, которую можно использовать для визуализации. В Neo4j через API можно делать запросы, которые показывал ранее.
Чем больше сотрудники используют граф, тем больше у них появляются стимул самим следить за его актуальностью. Каждый слой этого ткани может наполнить отдельная команда. Например, UI points наполняют например frontend разработчики, сервисы заполняют backend разработчики, storage заполняют DBA, сервера заполняют DevOps инженеры, сущности заполняют аналитики. Все чем-то заняты и они должны чувствовать что их заполнение живет и приносит пользу.
По некоторым направлениям у нас продолжается работа.
Мы хотим добавить еще информацию о потоке данных через шину (Londiste, PGQ, RabbitMQ).
Еще мы пытаемся добавить графы пользовательских траекторий. Граф связи UI points формируется на информации о том как пользователь ходят между UI points. Это сделано на уровне клиентского логирования. В данное время переходим к объединению этой информацией и пробросов в ткань (Persistent Fabric), чтобы можно было пользовательский опыт оттранслировать в UI points, оттуда в Endpoint, оттуда в сервисы. Из этой информации понять чем у нас пользователи чаще всего пользуются. Например, почему вот этот небольшой сервис, который не очень нагруженный и не очень важный, на самом деле так аффектит пользовательский опыт. Дисклеймер: потому что вызов этого сервиса находится на важной пользовательской траектории.
Это все, что я хотел вам рассказать. Давайте перейдем к вопросам.
Вопрос: Кто наполняет эту ткань? Ее заполняют люди, которые меняют конфигурацию? Как происходит процесс изменения?
Ответ: Каждый слой наполняется отдельно. Каждый слой наполняется из API некоторого источника. Выполняется запрос к атласу с целью получения списка всех сервисов. Атлас выдает список всех сервисов. Есть интерфейс, который позволяет дополнительно вводить сервисы. В атласе не всех баз. В 1С нет всех сотрудников. В LDAP нет всех команд. Часть данных получается автоматически, недостающая информация добавляется руками.
Вопрос: Не кажется ли вам что это похоже на то что десятками лет делается в semantic web? Например, link data. В link data есть связи, семантика. В link data описывается как что с чем связано.
Ответ: Идея графа знаний много где используется. Например, в поисковых движках. Это все примерно про это. Вопрос как именно жить с этим, как это быстро поднять у себя в конторе. Это все делается руками без покупки стороннего программного обеспечения.
Вопрос: Мы учитываем информацию про item, откуда они взялись, куда залились (где они создались), где закешировались. В рамках этой концепции как-нибудь рассматривается история о том что item может быть закеширован не весь? И какая часть его закеширована?
Ответ: Каждый элемент (запрос) кэширует только фрагмент нужных им полей. На данный момент сейчас этот нюанс не копаем.
Вопрос: потому что вам не надо?
Ответ: Если это будет актуально, это тоже добавим. Суть этой ткани заключается в том, что она может разрастаться, если нужно. Возможно, мы обогатим каналы информацией о перетекающих атрибутах. Сейчас это пока излишняя сложность. Потребностей особо не было.
Вопрос: После появления у вас такой визуализации насколько ваш монолит уменьшился? Помогает ли это уменьшать монолит?
Ответ: Нет, он от этого не уменьшился. Просто с ним стало проще жить. Кейс про уменьшение монолита, про обоснование монолита - это вообще находится в другой зоне. Этим тоже я занимаюсь во многом в рамках доменного моделирования. Это происходит не на техническом уровне. Это происходит на уровне продажи идеи бизнесу, продажи числовых метрик, в которых видно что распил монолита позволит нам вот здесь заработать больше, а здесь терять меньше.
Вопрос: Есть такие системы CMDB. Есть вендорные решения от IBM, HP, BMC.
Ответ: CMDB мы знаем. Вот информация серверах, хостах, железах из CMDB.
Вопрос: В CMDB есть Spiral discovering. Spiral discovering начинает искать по address pool сервисы и выделять их, находить на них порты. Spiral discovering выполняет поиск вплоть до user experience, если есть интеграция в систему мониторинга. Почему вы решили использовать что-то новое, а не используйте что-то старое что уже десятками лет работает? Многие компании используют вендерные решения, которые хорошо себя показали. CMDB отображает графы. В этих графах можно найти связь от бизнес сервиса до его owner. Эта тема называется ITSM (IT Service Management, управление ИТ-услугами). В ITIL есть отдельная тема как управлять IT. Это ITSM. В ITSM есть отдельная ветка CMDB.
Ответ: ответ на этот вопрос состоит из двух частей. Во-первых, мы не очень любим вендерные решения. Мы не любим платить вендорам, кроме тех случаев, когда они делают что-то прорывное. В данном случае у нас был ряд заходов. К нам приходили крупные векторы. Последний кто к нам приходил это appdynamics. Они тоже это делают. Эта компания делает лучше, чем те компании что вы описали. Мы задаем практический вопрос: у нас монолит, у нас тут PHP, тут у нас Golang, тут у нас Kubernetes, тут у нас свой самописный атлас. Речь идет о том, что это простая вещь и вам для этого вендорное решение не нужно.
Вопрос: Как вы собираете делать tracing user experience?
Ответ: Все пользовательские действия логируются через шину в нашу аналитику. Каждое событие, которое пользователь делает, обогатили и там появилась ссылка назад. Человек делает действие, например открывает item, и мы знаем что такое событие у нее было предыдущие. Каждое событие логируются ссылкой. Специальным накопителем на потоке эти события c ссылками выстраиваем в траектории. Это называется логирование пользовательских траекторий, которые были представлены на последнем слайде. Там мы можем отличить насыщенные траектории от случайных.
Вопрос: Это уже реализовали или в процессе?
Ответ: Логируются реализовано, сшивка в процессе, аналитика частично используется. Специфика логирование в небольших отличиях разного окружения у клиентов: iOS, Android, Desktop.
Вопрос: Я не принуждаю использовать вендорные решения. Я говорю что есть технология CMDB, есть автоматический discovering. Технология старая, но неважно кто ее внедряет.
Ответ: Да. Мы доработали атлас. Возможности подкрутить под себя она хороша.
Вопрос: Понятно, как идет связь между сервисами, когда у нас идет синхронный запрос. По синхронным, когда мы посылаем какой-то запрос в шину, вы пытаетесь тоже идти от сервиса к сервису, а не по сообщениям, которые в него посылаются.
Ответ: По подпискам по типу сообщений. У нас тип сообщений в терминологии кафка он считается топиком. И там сервис вам публикует определенные топики и мы знаем кто на какой топик подписан. Это информация позволяет закрыть доступ на определенный топик, если сервису он не нужен.
Вопрос (Геннадий, Московская биржа): Вы упоминали в Data Fabric на самом нижнем уровне entity. Вы их как-то автоматически отслеживаете?
Ответ: Ребята из Сбербанка рассказывали, что у них провал проекта Data Fabric был. Они перевели как фабрика данных, построили фабрику. А вообще-то в оригинале имелось ввиду ткани. Поэтому все не получилось. Поэтому важно: это - не фабрика, это - ткань.
Вопрос: У меня департамент как раз фабрика. Понимаю. Вы как-то отдельно отслеживаете, автоматически наполняете или это ручная работа?
Ответ: Список сущностей?
Вопрос: Да. И их связи, если они есть. Или вы связи не отслеживаете?
Ответ: Более подробный ответ в моих докладов про анкор modeling и аналитическое хранилище. У нас хранилище автоматически генерируется по описанию сущности, связи, атрибута. И эта информация напрямую льется. Сложнее с источниками, потому что эта сущность поступает из разных источников. Путь, по которому прилетает сущность, не всегда допускает автоматический парсинг из-за промежуточных буферов. То есть сущности автоматические. Пути заливки сущностей в полуручном режиме.
Вопрос: А вы справляетесь со сложностью, когда сущности из одной в другую сильно пересекают, трансформируются? Например, в одной табличке храниться целая их пачка, разделенные по каким-то признакам.
Ответ: Прочитайте про анкор modeling. Там такого не бывает. У нас сущность - это бизнес-сущность, а не то что система там какую-то сущность назвала x или xdb user. У нас есть пользователь. Понимаете, пользователь - это человек из мяса. Разные системы могут его по-разному представлять. Но это одна сущность.