Интеграция TIS Практические действия ChunJun

Видео станции Б:

https://www.bilibili.com/video/BV1QM411z7w5/?spm_id_from=333.999.0.0

1. Обзор Чун Джуна

ChunJun — это простая в использовании, стабильная и эффективная унифицированная среда интеграции данных с пакетным потоком. Она может реализовывать синхронизацию данных и вычисления между несколькими разнородными источниками данных на основе вычислительного механизма Flink в реальном времени. Она может собирать статические данные, такие как MySQL, HDFS и т. д. также могут собирать изменяющиеся данные в реальном времени, например Binlog, Kafka и т. д.

Текущие основные функции включают в себя:

・Агрегация разнородных данных из нескольких источников

Поскольку система является открытой, пользователи могут по мере необходимости разрабатывать новые плагины, получать доступ к новым типам баз данных или использовать встроенные плагины баз данных. В настоящее время совместим с чтением, записью и вычислениями SQL из более чем 30 разнородных источников данных.

・Возобновить загрузку с точки останова

Для таких задач, как колебания сети, которые приводят к сбою синхронизации данных, данные будут автоматически синхронизированы с последней неудачной точкой данных в следующей задаче, чтобы избежать повторного запуска всей задачи.

・Восстановление данных

В дополнение к операциям DML некоторые операции DDL исходной базы данных также могут быть синхронизированы, чтобы в максимальной степени обеспечить единство и структуру данных исходной базы данных и целевой базы данных, а также обеспечить восстановление данных.

・Управление грязными данными

Во время процесса передачи данных данные не могут быть синхронизированы с целевой базой данных из-за других факторов, таких как качество данных или ограничения первичного ключа. Статистика и управление этими «грязными» данными выполняются для облегчения последующего анализа «грязных» данных.

・Контроль скорости

В процессе синхронизации данных ключевым моментом является эффективность передачи данных. ChunJun целенаправленно контролирует скорость для различных сценариев, чтобы в максимальной степени обеспечить нормальный ход синхронизации данных.

Более подробную информацию см.:

Github：https://github.com/DTStack/chunjun

Gitee：https://gitee.com/dtstack_dev_0/chunjun

Официальный сайт：https://dtstack.github.io/chunjun/

Архитектура Чуньцзюня:

2. Обзор ТИС

TIS изначально был основан на Solr, чтобы предоставить пользователям универсальный готовый продукт среднего уровня для поисковой системы с самообслуживанием. До 2020 года, когда механизмы Flink и MPP еще не приобрели большого влияния, TIS уже предоставляла услуги для анализа OLAP в реальном времени внутри интернет-компаний.

Чтобы удовлетворить потребности бизнеса в области больших данных, быстро интегрируйте стек инструментов. ТИС начала свою трансформацию в конце 2019 года и стала полностью поддерживать существующую промежуточную платформу хранилища данных реального времени, реконструируя из исходной технической архитектуры, которая была тесно связана с поисковыми системами. Поскольку он работает только со сценариями поисковых систем, он совместим с экологическими сценариями больших данных всех терминалов данных.

Благодаря усилиям разработчиков TIS, TIS теперь имеет мощную систему управления метаданными, и большинство рабочих сценариев могут автоматически генерироваться в соответствии с потребностями пользователя (TIS — это DataOps на основе моделей, который отличается от других систем DevOps на основе сценариев, основанных на задачах сценариев). market, избавьтесь от всех громоздких операций сценария), и когда ресурсы, необходимые для задачи, готовы, пользователь касается системы данных, чтобы начать работу.

Что еще более важно, TIS может разделить две роли профессиональных специалистов по большим данным и аналитиков больших данных. Что касается промежуточной платформы хранилища данных в реальном времени, людям, которые ее используют, не нужно разбираться в ее технических деталях, а также им не нужно знать технические детали Flink, Hive и Hadoop, если они знают, что делают. . Исходя из вышеизложенного, TIS не создавала код хранилища данных реального времени в начале трансформации. Вместо этого потребовалось почти год для создания базы продуктов TIS, уделяя особое внимание следующим аспектам:

Репозиторий плагинов/механизм теплового эффекта

Стеки инструментов, имеющиеся в существующей отрасли, необходимо развертывать самостоятельно в серверной системе. TIS упрощает этот процесс. При построении проекта TIS будет единообразно упаковывать сторонние пакеты зависимостей и заранее развертывать их на удаленном хранилище. можно просмотреть список доступных плагинов в TIS. При его использовании вам нужно всего лишь щелкнуть мышью, чтобы загрузить и нагреть его, чтобы он вступил в силу, и работа будет плавной.

Полное моделирование процесса

Смоделируйте каждый процесс ETL, абстрагируйте переменные факторы, извлеките их в точку расширения в системе TIS и единообразно заархивируйте их в основной проект TIS. В основном проекте не реализован какой-либо конкретный бизнес-код, поэтому он находится в стадии разработки. При реализации конкретной бизнес-логики нет необходимости менять код какого-либо основного проекта, а принцип OCP реализуется в наибольшей степени на архитектурном уровне.

Например, ниже представлена ​​блок-схема выполнения структурированных (с поддержкой интерфейса JDBC) и неструктурированных источников данных в ETL:

Построение системы UI-DSL

Поскольку в TIS интегрируется все больше функциональных компонентов, нагрузка на пользовательский интерфейс, который необходимо разрабатывать отдельно, огромна, а стиль сложно унифицировать. В то же время из-за этого сложно поддерживать большое количество перекодировок. Из-за утонченного разделения труда в отрасли этот процесс требует сотрудничества фронтенд- и бэкэнд-инженеров, что приводит к повышению эффективности разработки. Низкая: как дать возможность бэкэнд-разработчикам без опыта фронтенд-разработки работать независимо и плавное завершение разработки компонента пользовательского интерфейса стало важной темой. Чтобы решить эту проблему, TIS реализовала в базе систему UI-DSL. Инженер внутренней разработки использовал язык JAVA для написания сценария MetaData, соответствующего форме, который определял макет формы, проверку входных элементов и. другая информация Во время выполнения автоматически отображайте сценарии MetaData во внешние формы, что идеально решает эту проблему.

Как показано выше, это подключаемый модуль источника данных MySQL, определенный в TIS. Вам нужно только добавить идентификатор FormFieldAnnotation для соответствующего атрибута в соответствующем POJO, а также добавить значение по умолчанию, метку и другие файлы описания информации, соответствующие полю. :

 @FormField(ordinal = 3, // Порядок ранжирования в форме 
    type = FormFieldType.INPUTTEXT // Виды элементов управления в форме
   , validate = {Validator.require, Validator.identity}) // Правила проверки входных данных
	public String dbName;

DataSourceFactory.json

 { "dbName": {
 "label": "имя базы данных",
 "help": «Имя базы данных, используемое при создании экземпляра JDBC»
	 }}

3. Интегрируйте ChunJun для улучшения экосистемы TIS.

После нескольких месяцев исследований и разработок наконец-то была выпущена альфа-версия TIS V3.6.0. Самым ярким моментом этой версии является интеграция ChunJun, лидера в области инструментов синхронизации данных в области больших данных, которая поднимает бизнес-возможности TIS на новый уровень.

Последняя версия ТИС:

https://github.com/qlangtech/tis/releases/tag/v3.6.0-alpha

Еще в версии 3.6.0-альфа TIS интегрировала Alibaba DataX и Flink-CDC. Оффлайн-пакетная синхронизация реализована с помощью компонентов DataX, а что касается компонентов Source изменения данных в реальном времени, TIS реализован на базе Flink-CDC. Что касается части Sink, то она была завершена путем вторичной разработки на основе экологических пакетов API, предоставляемых различными терминалами данных.

Существующие проблемы заключаются в том, что цикл разработки длинный и отладка затруднена. Например, только для реализации реализации Sink на основе StreamFunction в StarRocks на разработку и тестирование ушло целых три недели.

Эти проблемы не были решены до интеграции ChunJun. ChunJun хорошо поддерживает большинство данных в области больших данных, включая источник и приемник. Его исходная сторона реализована на основе механизма опроса. По сравнению с исходной стороной, реализованной Flink CDC, она имеет свои особенности.

Например, не все терминалы поддерживают механизмы синхронизации в реальном времени, такие как MySQL binlog. Даже если они поддерживают LogMiner, как Oracle, если вы хотите включить его, вам понадобится помощь профессионального администратора базы данных Oracle, иначе установка разрешений отпугнет многих пользователей. Подписка на обновления в реальном времени, основанная на механизме опроса, может поддерживать все стороны источника, если реализован интерфейс JDBC.

Таким образом, исходная часть ChunJun очень универсальна. Единственным недостатком по сравнению с Flink CDC является то, что ее производительность в реальном времени ниже. Однако в большинстве сценариев OLAP пользователи не предъявляют таких высоких требований к производительности в реальном времени, поэтому она не имеет таких высоких требований. Обычно рекомендуется использовать источник ChunJun для отслеживания изменений данных в реальном времени.

Кроме того, реализация ChunJun на стороне Sink также является важной функцией. Как правило, реализация Flink Sink предоставляется в экологических продуктах на стороне данных. Например, официальный сайт ElasticSearch Flink предоставляет реализацию, основанную на SinkFunction, а StarRocks также предоставляет реализацию Sink. на его официальном сайте. Однако у каждой компании разные методы реализации, а единой абстрактной модели не существует. Кроме того, реализации, предоставляемые различными производителями, по сути, являются лишь какими-то полуфабрикатами, такими как аварийное восстановление и мониторинг, которые не предусмотрены. В результате TIS действительно тратит много энергии на интеграцию различных стоковых терминалов, и это сложно. сделать это идеально.

Поэтому ChunJun v1.12.5 использовался в TIS v3.6.0, чтобы полностью переписать исходную реализацию TIS Sink. Поскольку реализация ChunJun хорошо инкапсулирована и была протестирована в производственной среде, а методом реализации было унифицированное моделирование. методы доступа каждого терминала могут быть унифицированы, что значительно повышает эффективность комплексной разработки для ТИС, а также реализует аварийное восстановление, мониторинг и управление «грязными» данными.

ChunJun поддерживает широкий спектр терминалов Connector. В TIS v3.6.0 для инкапсуляции выбираются только несколько терминалов, которые часто используются пользователями. Инкапсуляция других терминалов будет постепенно реализована в последующих версиях. Ниже приведены конечные типы, реализованные в версии 3.6.0:

4. Как TIS интегрирует ChunJun

Используйте систему управления метаданными TIS, чтобы взять на себя управление типом данных потока ChunJun.

Экземпляр RowData, встроенный в потоковую обработку ChunJun, автоматически генерируется через целевые метаданные Jdbc (пользователю не нужно задавать их в файле конфигурации JSON), и внутри него необходимо передать fieldType информации метаданных в целевом объекте (Source/Sink). ) поле JDBC в качестве параметра. Чтобы сопоставить экземпляр DataType flink, вызывающим интерфейсом является com.dtstack.chunjun.converter.RawTypeConverter,

public interface RawTypeConverter {   
 DataType apply(String type);
 }

В ходе фактической обработки было обнаружено, что простого использования JDBC col MetaDatafieldType в качестве параметра недостаточно. Например: таблицы MySQL определяются как целые числа bigint, int, smallint. Когда пользователь добавляет беззнаковую модификацию, тип отображения bigint во Flink. необходимо изменить с BigIntType на DataTypes.DECIMAL, исходный тип smallint необходимо изменить на IntType, иначе произойдет ошибка выполнения. Кроме того, Jdbc Oracle внутренне реализует набор спецификаций типа oracle.jdbc.OracleTypes, который отличается от стандарта Jdbc. После получения типа Oracle его необходимо нормализовать в тип Jdbc java.sql.Types, иначе он не будет работать. выполняться нормально.

Хотя сопоставление типов очень просто, поскольку Java является строго типизированным языком, ClassCastException возникнет, если вы не будете осторожны во время выполнения потоковой обработки, поэтому вы должны обращаться с ним с особой осторожностью. Поэтому TIS представил новую абстракцию типа com в ChunJun. qlangtech.tis.plugin.ds.ColMeta инкапсулирует информацию о столбцах метаданных Jdbc, позволяя более детально управлять внутренними типами столбцов Flink во время конкретного процесса выполнения.

 public interface RawTypeConverter {   
   DataType apply(ColMeta type);
	 }
 
	public class ColMeta implements Serializable {
public final String name;
public final DataType type;
public final boolean pk;

public ColMeta(String name, DataType type, boolean pk) {
    this.name = name;
    this.type = type;
    this.pk = pk;
}
//...
}

public class DataType implements Serializable { 
public final int type;
public final int columnSize;
public final String typeName;
// decimal из Длина десятичной цифры
private Integer decimalDigits;

public DataType(int type, String typeName, int columnSize) {
    this.type = type;
    this.columnSize = columnSize;
    this.typeName = typeName;
}
/**
 * is UNSIGNED
 */
public boolean isUnsigned() {
  //...  
} 
 }

Замените задачи, управляемые конфигурацией JSON, задачами, управляемыми моделью метаданных.

Благодаря поддержке управления взаимосвязями метаданных, лежащего в основе TIS, большая часть работы по определению задач синхронизации данных может быть выполнена автоматически, и пользователю нужно выполнить только некоторую вспомогательную работу. Например, пользователю необходимо импортировать таблицу с 10 столбцами. пользователю необходимо сделать дополнительное подтверждение: чтобы сторона источника подтвердила первичный ключ таблицы, время интервала опроса стратегии опроса и имя столбца опроса, а сторона приемника выбрала стратегию вставки, это можно выполнить с помощью просто щелчок мыши. Логика отображения в пользовательском интерфейсе страницы и ChunJun. соответствует правилам.

Добавить новую точку расширения TIS для Чуньцзюня.

Чтобы успешно интегрировать ChunJun Connector в TIS в версии 3.6.0, необходимо добавить две точки расширения функций. Одна из них — установить com.qlangtech.tis.plugins.incr.flink.chunjun.source для свойств инкрементальной таблицы Source. .SelectedTabPropsExtends, второй — установить свойства таблицы приемника. com.qlangtech.tis.plugins.incr.flink.chunjun.sink.SinkTabPropsExtends

5. Совместное строительство с открытым исходным кодом и процветающая экология

Концепция построения TIS заключается в том, чтобы решительно избегать изобретения велосипеда. Мы должны стоять на плечах отраслевых гигантов и быть связующим звеном для отличных наборов инструментов в индустрии больших данных. TIS V3.6.0alpha удалось выпустить вовремя. Благодаря существованию в отрасли таких прекрасных проектов с открытым исходным кодом, как ChunJun, DataX, Flink-CDC и Flink, общая надежность TIS гарантирована. Особая благодарность выражается Apache Flink, который предоставляет мощную вычислительную экосистему в реальном времени. Flink CDC, ChunJun и TIS — это процветающие саженцы, растущие в этой экосистеме. Каждый проект фокусируется на своих областях знаний и дополняет друг друга.

По мере приближения релиза я обнаружил очень интересный сценарий использования, то есть пользователи могут выбрать плагин MySQL Source на основе Flink-CDC для отслеживания дополнительных изменений в таблице MySQL и синхронизации данных с Sink, созданным с помощью ChunJun such. метод смешанного использования. Он дает пользователям больше свободы выбора и позволяет избежать экологической инволюции, вызванной изобретением велосипеда в рамках соответствующих структур Flink-CDC и ChunJun.

6. Используйте CloudNative

Наступление эры Cloud Native рисует для нас прекрасную картину. Она предоставляет конечным пользователям недорогие и надежные базовые ИТ-услуги, и они могут сосредоточиться на развитии бизнеса, что очень хорошо.

Но у практиков интернет-технологий, похоже, есть скрытое беспокойство: интернет-дивиденды достанутся поставщикам облачных услуг, таким как Alibaba Cloud, а мелкие поставщики могут только тупо смотреть на проекты с открытым исходным кодом, такие как TIS, которые мы так кропотливо создавали. не будет использоваться в облаке. Есть ли еще место для времени? На самом деле такие беспокойства излишни.

Здоровая экология должна обеспечивать биоразнообразие. Каждый вид в экологии не независимый, а взаимозависимый. Аналогичным образом, в экосистеме больших данных, если только крупные интернет-компании, такие как Alibaba Cloud и Amazon, процветают и образуют черную дыру талантов, поглощающую все ресурсы других небольших компаний, такая экосистема не может существовать долго.

По сути, необходимым условием для любого сотрудничества между отдельными людьми или организациями является наличие сравнительных преимуществ. Точно так же, как слепой несет хромого, помогая друг другу двигаться вперед, то же самое справедливо и для сотрудничества между странами. дешевая рабочая сила и обширный рынок. В дополнение к технологическим преимуществам развитых стран такое сотрудничество является устойчивым.

Крупные облачные фабрики могут создать дорогостоящую интернет-инфраструктуру, использовать преимущества масштаба интенсивных закупок для значительного сокращения затрат, а затем использовать технические средства для преобразования этого оборудования в услуги IAAS и предоставления их клиентам. Технология небольших фабрик является гибкой, эффективной и требует меньше усилий. Технический персонал. Преимущество в затратах на заработную плату. Использование этого преимущества для создания служб PAAS поверх IAAS, аналогично планированию задач, очень подходит для хранилища данных в реальном времени. За рубежом уже есть успешные примеры, такие как сотрудничество между облачным хранилищем данных реального времени, предоставляемым Snowflake, и поставщиками облачных услуг, такими как Amazon. Некоторые студенты наверняка спросят: «Почему Amazon не может создать такое же хранилище данных, как Snowflake, самостоятельно. На самом деле ответ есть ранее. Уже упоминалось.

Хотите узнать или узнать больше о Kangaroo Cloud big данныепродукт、Отраслевые решения、Случай клиентаиздруг,Просмотр облака-кенгуру Официальный сайт：https://www.dtstack.com/?src=sztxkfz

Добавьте [Маленький кенгуру: dtstack001] в qun и получите большой бесплатно данные&开源干货

项目地址：https://github.com/DTStack