Apache DevLake – это интеграционный инструмент с функцией сбора информации DevOps, который презентует командам разработчиков другой этап данных через Grafana. Он также может помочь командам улучшить процесс разработки с помощью модели, основанной на данных.

Обзор архитектуры Apache DevLack

• Слева на следующем скриншоте – интеграционный плагин данных DevOps (среди имеющихся плагинов находятся Github, GitLab, JIRA, Jenkins, Tapd, Feishu и наиболее продвинутый механизм анализа на платформе Simayi).

• Основной фреймворк (в центре скриншота) завершает сбор, расширение и преобразование данных на доменном уровне путем выполнения подзадач в плагинах. Пользователь может запускать задачи с помощью config-UI или всех API.

• RMDBS (Реляционная система управления базами данных) в настоящее время поддерживает Mysql и PostgresSQL, в будущем будет поддерживаться больше баз данных.

• Grafana может генерировать различные типы необходимых данных с помощью SQL.

Затем перейдем к запуску DevLake.

Запуск системы

Перед запуском программы Golang автоматически вызовет метод init() в пакете. Нам нужно сосредоточиться на загрузке пакета сервисов. Нижеприведенный код снабжен подробными комментариями:

func init() {
var err error
// get initial config information
cfg = config.GetConfig()
// get Database
db, err = runner.NewGormDb(cfg, logger.Global.Nested("db"))
// configure time zone
location := cron.WithLocation(time.UTC)
// create scheduled task manager
cronManager = cron.New(location)
if err != nil {
panic(err)
}
// initialize the data migration
migration.Init(db)
// register the framework's data migration scripts
migrationscripts.RegisterAll()
// load plugin, loads all .so files in the folder cfg.GetString("PLUGIN_DIR")，in th LoadPlugins method()，specifically, LoadPlugins stores the pluginName:PluginMeta key-value pair into core.plugins by calling runner.
err = runner.LoadPlugins(
cfg.GetString("PLUGIN_DIR"),
cfg,
logger.Global.Nested("plugin"),
db,
)
if err != nil {
panic(err)
}
// run data migration scripts to complete the initializztion work of tables in the databse framework layer.
err = migration.Execute(context.Background())
if err != nil {
panic(err)
}

// call service init
pipelineServiceInit()
}

Принцип выполнения DevLake

Процесс выполнения пайплайна Прежде чем мы перейдем к пайплайну, нам нужно сначала узнать, что такое Blueprint.

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

Ниже приведена блок-схема работы пайплайна.

Пайплайн содержит двумерный массив задач, в основном для того, чтобы обеспечить выполнение ряда операций в заданном порядке. Как показано на следующем скриншоте, если плагин этапа 3 должен использовать другой плагин для подготовки данных (например: работа refdiff должна опираться на gitextractor и Github, для получения дополнительной информации об источниках данных и плагинах, пожалуйста, обратитесь к документации), то когда этап 3 начинает выполняться, он должен убедиться, что его зависимости были соблюдены на этапах 1 и 2.

Процесс выполнения задачи

Задачи плагина на этапах 1, 2 и 3 выполняются параллельно:

Следующий шаг – последовательное выполнение подзадач в плагине.

1. Перед RunTask необходимо подготовить параметры для вызова метода RunTask, такие как logger, db, context и т.д.

2. Основной принцип действия метода RunTask заключается в обновлении задач в базе данных, одновременно подготавливая к запуску опции задачи плагинов.

3. RunpluginTask получит соответствующую PluginMeta через core.Getplugin(pluginName), затем получит PluginTask через PluginMeta, а затем выполнит RunPluginSubTasks.

Процесс выполнения каждой подзадачи плагина (соответствующий интерфейс и функции будут описаны в следующем разделе)

1. Получите все доступные подзадачи subtaskMeta всех плагинов, вызвав SubTaskMetas().

2. Используйте опции ['task'] и subtaskMeta для формирования набора подзадач при выполнении subtaskMetas.

3. Вычислите общее количество подзадач

4. Создайте taskCtx с помощью helper.NewDefaultTaskContext.

5. Создайте taskData с помощью вызова pluginTask.PrepareTaskData.

6. Выполните перебор всех подзадач в subtaskMetas.

   1. Получите subtaskCtx подзадачи с помощью вызова taskCtx.SubTaskContext(subtaskMeta.Name).

   2. Выполните subtaskMeta.EntryPoint(subtaskCtx).

Важные интерфейсы в DevLake

1. PluginMeta: Содержит два основных метода плагинов, которые должны осуществлять имплементацию всех плагинов. Хранится в core.plugins при запуске системы. И получается через core.GetPlugin при выполнении задач плагинов.

type PluginMeta interface {
   Description() string
   //PkgPath information will be lost when compiled as plugin(.so), this func will return that info
   RootPkgPath() string
}

2. PluginTask: Он может быть получен с помощью PluginMeta, после того, как плагин реализовал этот метод, фреймворк может запускать подзадачу напрямую, вместо того, чтобы позволять самому плагину запускать ее. Самое большое преимущество этого в том, что подзадачи плагина легче реализовать. Мы можем этим запросто воспользоваться (например, добавление логов и т.д.) во время работы плагина.

type PluginTask interface {
   // return all available subtasks, framework will run them for you in order
   SubTaskMetas() []SubTaskMeta
   // based on task context and user input options, return data that shared among all subtasks
   PrepareTaskData(taskCtx TaskContext, options map[string]interface{}) (interface{}, error)
}

3. Каждый плагин имеет taskData, содержащий параметры конфигурации, apiClient и другие свойства плагинов (как на github информация о репо).

4. SubTaskMeta:: мета-данные подзадачи, каждая подзадача определяет SubTaskMeta.

var CollectMeetingTopUserItemMeta = core.SubTaskMeta{
   Name: "collectMeetingTopUserItem",
   EntryPoint: CollectMeetingTopUserItem,
   EnabledByDefault: true,
   Description: "Collect top user meeting data from Feishu api",
}

5. ExecContext: определяет все ресурсы, необходимые для выполнения (под) задач.

6. SubTaskContext: определяет все ресурсы, необходимые для выполнения подзадачи(включая ExecContext).

7. TaskContext: определяет все ресурсы, необходимые для выполнения задач (включая ExecContext). Разница с SubTaskContext заключается в том, что метод TaskContext() в SubTaskContext может вернуть TaskContext, а метод SubTaskContext (строка подзадачи) в TaskContext может вернуть SubTaskContext, что означает, что подзадача принадлежит подключаемой задаче, поэтому мы используем разные контексты, для того, чтобы различать это.

8. SubTaskEntryPoint: все подзадачи в плагине должны реализовать эту функцию, чтобы они могли быть скоординированы и упорядочены посредством фреймворка.

Дальнейший план

В этом блоге были представлены основы фреймворка DevLack и то, как он запускается и работает. Еще 3 контекста api_collector, api_extractor и data_convertor будут описаны в следующем блоге.

Завтра состоится открытое занятие «Clickhouse vs. Greenplum. Какую MPP-базу данных выбрать?». На этом уроке:

• Узнаете, что такое MPP-БД на самом деле.

• Познакомитесь с различными представителями таких систем.

• Разберетесь, когда и в каких случаях стоит выбирать каждую из них.

• На практике изучите наглядные примеры работы БД Clickhouse и Greenplum.

Записаться можно на странице онлайн-курса "Data Engineer".