В начале своей карьеры, во времена расцвета бизнес-аналитики (BI), я работал с внутренней командой по подготовке отчетов, предоставляя данные для процессов извлечения, преобразования и загрузки (ETL), которые использовали структуры данных, вдохновленные Ральфом Кимбаллом. Это было новое и захватывающее время в моей жизни, когда я понял, как оптимизировать данные для отчетности и анализа. Честно говоря, схема казалась мне перевернутой с ног на голову, исходя из моего опыта работы с транзакционно-ориентированными конструкциями.
В итоге, было много движущихся частей и даже некоторые зависимости от существования плоского файла, чтобы убедиться, что все работает правильно. Отчеты выполнялись быстро, но один ключевой фактор всегда беспокоил меня: Я всегда просматривал вчерашние данные.
В связи с увеличением объема, скорости и типов данных, производимых в современных технологических стеках, данные в реальном времени стали святым Граалем для обеспечения актуального и проактивного анализа и принятия бизнес-решений на основе данных. Когда мы используем обычный пакетный подход к получению данных, данные всегда оказываются несвежими и не могут ответить на насущные вопросы.
Чтобы использовать эти сценарии в режиме реального времени, данные должны быть доступны на уровне хранения и обработки, которые в настоящее время используются в организации.
В течение многих лет — и это верно и сегодня — транзакционные (OLTP) системы, такие как Oracle, Postgres и SQLServer, были основой большинства предприятий, и они являются центральными для последующей аналитики и обработки. Эта работа обычно выполняется группой инженеров по данным, которые тратят месяцы на создание конвейеров для извлечения и преобразования данных из этих OLTP-систем в аналитические озера и хранилища данных (OLAP).
За последнее десятилетие организации всех размеров потратили миллиарды долларов на то, чтобы улучшить свои возможности по обработке данных и извлечению из них бизнес-ценностей. Однако только 26,5% организаций считают, что они достигли цели стать компанией, управляемой данными. Одним из самых больших препятствий на пути к достижению состояния «Утопии данных» является приобретение способности создавать надежные конвейеры данных, которые извлекают данные из OLTP-систем, обеспечивая при этом согласованность данных и легкость масштабирования по мере роста данных.
Это заставило меня задуматься, есть ли лучший способ достичь тех же результатов без тяжелого ночного процесса. Первой моей мыслью было изучить модель захвата данных об изменениях (CDC) для удовлетворения этих потребностей.
Почему захват данных об изменениях (CDC) имеет значение
Извлечение данных из OLTP-систем может быть громоздким по следующим причинам:
-
В отличие от SaaS-инструментов, корпоративные базы данных не имеют гибких API, которые можно использовать для реагирования на изменения данных.
-
Создание и поддержка конвейеров для извлечения данных из OLTP-систем, особенно в масштабах предприятия, является сложным и дорогостоящим процессом для обеспечения согласованности данных.
С другой стороны, CDC — это шаблон проектирования программного обеспечения, который определяет и отслеживает обновления базы данных по мере их возникновения. Это позволяет сторонним потребителям реагировать на изменения в базе данных, значительно упрощая процесс получения изменений данных в OLTP-системе. События CDC могут быть получены с помощью нескольких различных подходов:
- На основе времени: в качестве источника данных используется требуемый столбец временной метки.
- Контрольная сумма: использует контрольную сумму таблиц в источнике/цели, используя различия в качестве источника данных.
- На основе журнала: считывание журналов базы данных в качестве источника данных.
В данной публикации мы сосредоточимся на подходе, основанном на журнале. CDC на основе журнала обычно считается лучшим вариантом для использования в реальном времени из-за его легковесного подхода к созданию изменений данных. Подходы на основе времени и контрольной суммы требуют больше накладных расходов и процессора, часто используя запросы к базе данных для поиска самых новых изменений в наборе данных. CDC, использующие чтение на основе журнала, могут сократить эти дорогостоящие и трудоемкие запросы, фиксируя изменения, обращаясь непосредственно к источнику: журналам.
При использовании журнального подхода записи в базу данных обрабатываются через журналы транзакций, часто называемые журналами изменений. Решения CDC прослушивают эти же журналы и генерируют события, когда применяются установленные условия. Используя журналы, служба CDC получает доступ к тем же самым данным, не дожидаясь фиксации транзакции и последующего запроса к базе данных для получения этих данных.
Благодаря внедрению решения CDC сторонние потребители данных получают более быстрый доступ к изменениям в базе данных. Кроме того, потребителям данных не требуется доступ к реальной базе данных, поскольку их интересуют только обновления в журналах изменений. CDC не только обеспечивает практически мгновенную репликацию данных, но и оказывает минимальное влияние на производительность производственных баз данных. Поскольку CDC обращается только к журналам и не представляет угрозы безопасности, ИТ-команды также любят его. Уникальные характеристики CDC сделали его широко распространенным среди многих технологических лидеров, для которых сценарии использования в реальном времени являются ключевыми в их бизнес-моделях (например, Shopify, Uber, CapitalOne).
Чтобы лучше понять CDC, давайте рассмотрим пример использования, связанный с финансовой индустрией.
Обнаружение мошенничества с помощью CDC
Мошеннические операции являются серьезной проблемой для финансовой отрасли. В этом отчете отмечается, что в 2020 году мошенничество с кредитными картами увеличилось на 44,7% по сравнению с предыдущим годом.
Предположим, что WorldWide Bank, вымышленное финансовое учреждение, хочет повысить скорость распознавания мошенничества. Их текущий подход основан на процессе ETL для запроса к базе данных Oracle и создания отчетов. Они хотели бы изучить возможность использования Arcion CDC для обработки журналов изменений базы данных Oracle с целью генерации событий, которые будут использоваться в прототипе Databricks Delta Lake. Как и многие другие организации, WorldWide Bank имеет множество транзакционных систем, включая большой набор данных в базе данных Oracle. У них растет потребность в расширении возможностей машинного обучения (ML), а также в объединении различных наборов данных в простой в использовании среде для анализа, что и привело их к использованию Databricks для создания озера данных.
Реляционная модель данных Oracle, а также хлопоты по привлечению других вспомогательных источников данных в Oracle и отсутствие поддержки для запуска ML непосредственно на Oracle делают Databricks легким выбором. Однако такой подход приводит к другой проблеме: как своевременно перенести транзакции Oracle в Databricks. Чтобы повысить скорость обнаружения мошенничества, для их работы очень важно иметь возможность быстро получать события CDC из Oracle, помещая их в озеро данных Databricks для дальнейшей обработки и обнаружения.
Что касается их решения использовать Arcion CDC, почему WorldWideBank выбрал именно Arcion, а не другой вариант, даже с открытым исходным кодом? Ответ прост. Debezium, например, является вариантом с открытым исходным кодом, но он требует установки и запуска Zookeeper, Kakfa и MySQL — и все это до того, как вы сможете начать использовать или устанавливать инструмент. Только для этого потребуется большая команда инженеров, чтобы просто установить и поддерживать технологический стек.
В то время как другие инструменты, например, HVR для CDC от Fivetran, могут предлагать бесплатные пробные версии, Arcion предлагает два бесплатных варианта на выбор: 30-дневную пробную версию с загрузкой или 14-дневную пробную версию в облаке. Это удобно для тестирования, поэтому выбор Arcion при выборе решения для CDC был легким.
На высоком уровне архитектуру Arcion CDC можно проиллюстрировать следующим образом:
Если этот подход пройдет успешно, WorldWide Bank расширит дизайн для замены других исходных баз данных Oracle, Microsoft SQL Server и MySQL.
Прототипирование Arcion CDC
Чтобы смоделировать сценарий WorldWide Bank, предположим, что входящие транзакции записываются в таблицу базы данных Oracle под названием TRANSACTIONS, которая имеет следующий дизайн:
Пример записи в таблице TRANSACTIONS в формате JSON будет выглядеть так, как показано ниже:
{
"id" : "0d0d6c35-80d0-4303-b9d6-50f0af04beb3",
"post_date" : 1501828517,
"trans_date" : 1501828517,
"type" : 1017,
"card_number" : "4532394417264260",
"account_number" : "001-234-56789",
"amount" : 27.67,
"vendor_number" : 20150307,
"vendor_location_latitude" : 42.3465698,
"vendor_location_longitude" : -71.0895284,
"vendor_name" : "Berklee College of Music Bookstore"
}
Для того чтобы использовать возможности Databricks и Delta Lake для предотвращения мошенничества, нам необходимо настроить службу CDC, которая будет выступать в качестве промежуточного программного обеспечения между этими двумя системами. Дизайн таблицы TRANSACTIONS и данные в Oracle должны существовать в качестве Bronze (Ingestion) уровня в Delta Lake. Как только существующие данные будут приняты, все будущие транзакции будут использовать поток CDC, включенный в решение Arcion.
Начало работы с CDC начинается с создания бесплатной учетной записи Arcion Cloud и получения информации о подключении/входе для базы данных Oracle и системы Databricks.
После сбора этой информации я запустил новую репликацию в приложении Arcion Cloud и определил режимы репликации и записи между исходной и целевой базой данных:
В данном случае я выбрал режим полной репликации. Это позволяет мне реплицировать полный снимок базы данных и обеспечивает работу в режиме реального времени для всех будущих обновлений. Я выбрал режим записи с заменой, чтобы полностью заменить существующий дизайн базы данных и данные на целевом узле.
Далее я установил соединение с базой данных Oracle, как показано ниже:
Мы можем проверить соединение с помощью кнопки Test Connection. Когда все готово, кнопка Continue to Destination перемещает прогресс на следующий шаг.
На экране Destination я могу добавить подключение к службе Databricks и выбрать ее в качестве цели для создаваемой репликации:
Используя кнопку Continue to Filter, я смог перейти к экрану фильтрации, показанному ниже:
Я выбрал исходную базу данных и таблицы на экране фильтрации. Когда все было готово, мне оставалось только нажать кнопку Start Replication, чтобы выполнить следующие задачи:
- Удалить все существующие базы данных в Databricks, которые соответствуют текущему запросу на репликацию
- Создать новые базы данных в среде Databricks
- Выполнить моментальную репликацию всех существующих данных, которые соответствуют фильтрам, указанным в запросе на репликацию
- Установить поток CDC между журналами изменений Oracle и Databricks для всех будущих транзакций.
Я выполнил все это с нулевым кодом.
Как только репликация началась, я мог контролировать процесс в пользовательском интерфейсе Arcion Cloud:
Как отмечалось выше, сначала будет выполнен моментальный снимок, а затем все последующие обновления будут поступать через поток CDC. После завершения пользовательский интерфейс обновляется, как показано ниже:
На этом этапе уровень Bronze (Ingestion) Delta Lake готов к использованию.
Полученные данные могут быть преобразованы в уровни Silver (переопределенные таблицы) и Gold (Feature/Agg Datastore), что позволит нам использовать преимущества функциональности Delta Lake для обнаружения и смягчения последствий мошенничества. В дальнейшем ожидается, что все данные из таблицы Oracle TRANSACTIONS будут автоматически попадать в Databricks.
У нас есть еще один заключительный шаг по вводу данных из CDC в озеро данных. Перед запуском модели мошенничества ML для получения результатов прогнозирования мы запустим предварительно созданные тесты dbt или контрольные точки Great Expectations, чтобы убедиться, что мы получили новые записи с момента последнего запуска обнаружения мошенничества. Это дает банку WorldWide уверенность в том, что полный сквозной CDC из Oracle поступает в Databricks в соответствии с ожиданиями.
Меня очень впечатляет, что я могу создать такой уровень проектирования, просто выполнив ряд шагов в пользовательском интерфейсе Arcion Cloud и не написав ни строчки программного кода. Для сценария использования Всемирного банка создание аналогичной репликации для других баз данных должно быть таким же простым, что позволит обрабатывать все данные о мошенничестве в одной системе.
Заключение
С 2021 года я стараюсь жить в соответствии со следующей миссией, которая, как мне кажется, может быть применима к любому ИТ-специалисту:
«Сосредоточьте свое время на предоставлении возможностей/функциональности, которые увеличивают ценность вашей интеллектуальной собственности. Для всего остального используйте фреймворки, продукты и услуги».
- J. Вестер
Arcion обеспечивает функциональность CDC, не изобретая велосипед. Их платформа позволяет командам разработчиков использовать подход «без кода» для создания исходных и целевых источников данных, а также все необходимое для маршрутизации входящих транзакций базы данных во вторичный источник до их записи в базу данных.
Кроме того, Arcion может быть развернут различными способами. Например, финансовые или медицинские предприятия могут иметь требования к безопасности или соответствию нормативным требованиям. Они могут развернуть Arcion на собственной площадке или в виртуальном частном облаке. Для компаний, не обладающих ресурсами DevOps для управления собственными развертываниями, хорошим вариантом будет полностью управляемое облако Arcion Cloud.
Кроме того, простота создания моментальных снимков и потоковых репликаций CDC позволяет дополнительным источникам данных использовать ту же логику обработки, что и в реализации Databricks Delta Lake. В конечном итоге это обеспечивает подход «не повторяйся» (DRY), позволяя одному источнику логики сосредоточиться на обнаружении мошенничества.
Команда Arcion определенно придерживается моего личного заявления о миссии и позволяет своим клиентам оставаться сосредоточенными на выполнении корпоративных приоритетов.
Если бы я работал с той самой командой BI, о которой я упоминал во введении, я бы, конечно, рекомендовал изучить Arcion Cloud для удовлетворения их потребностей. Это даст возможность получать данные в реальном времени, а не полагаться на данные однодневной давности для принятия решений.
Хорошего дня!