Утро Россия 1 – 19.12.2024 – Смотрим.ру

Обновлено 28 августа 2024 г., 10:08 по восточному времени

Лес Абенд — отставной ветеран American Airlines с 34-летним стажем, пытающийся вновь обрести страсть к пилотированию самолетов на нижних эшелонах — без помощи второго пилота.

Оригинал: https://www.flyingmag.com/jumpseat/replacing-airline-pilots-with-ai

Традиционные кабины пилотов претерпевают трансформационные изменения.

2 мая на авиабазе Эдвардс в Калифорнии министр ВВС США Фрэнк Кендалл поднялся на борт испытательного F-16, получившего название VISTA (Variable In-Flight Simulator Test Aircraft – Многоцелевой самолет-тренажер с изменяемыми параметрами полета), оснащенного платформой искусственного интеллекта. Министр Кендалл и пилот-испытатель на заднем сиденье наблюдали за полетом, не прикасаясь к органам управления, в то время как другой F-16, управляемый человеком, имитировал воздушный бой с VISTA.

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

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

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

За девять лет полетов на Boeing 777 я всегда поражался тому, насколько стабильно автоматика выполняла плавную посадку самолета, особенно выравнивание и приземление. Из-за негласного соперничества между моими навыками и возможностями машины я редко позволял системе автоматической посадки завершить свою работу до самой бетонной полосы, если только погодные условия не диктовали иного. Это были отношения любви/ненависти.

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

Сейчас ИИ считается “генеративным”. Вместо того чтобы просто полагаться на ввод данных человеком, генеративный ИИ использует алгоритмы прогнозирования, ряд формул или инструкций, для создания одного или нескольких действий. В случае с текстом компьютер может генерировать оригинальный контент — например, роман. Эти действия или творения достигаются путем извлечения многочисленных, а возможно, и бесконечных источников данных, т.е. информации из Интернета.

Это не идеальная система, потому что иногда генерируемый контент может приводить к тому, что на языке ИИ называется «галлюцинациями». Часть материала может быть дезинформацией, слегка неверной или совершенно некорректной. Помните, что некоторые данные извлекаются из таких источников, как интернет-сайты, которые сами по себе печально известны своей неточностью.

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

Искусственный общий интеллект (ИОИ или AGI) — это концепция технологии, которой большинство боится. Для тех, кто моего возраста, ИОИ — это причина, по которой персонаж стрелка Юла Бриннера из фильма “Мир Дикого Запада” 1973 года действует убийственно, выходя за рамки своего человеческого программирования. Но эта фаза технологии в основном теоретическая. Компьютеры пока не способны развивать свой собственный интеллект или личность вне данных, которые были введены или извлечены.

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

Когда я перешел на Boeing 767 с Jurassic Jet (B-727), самолета, который все еще управлялся с помощью шкивов, тросов и капризного автопилота, идея управления машиной с помощью переключателей на верхней панели была чужда моему существу. Однажды во время тренировки на симуляторе я взбунтовался и отключил автопилот, выразив свое недовольство нашему проверяющему. Я убедил его позволить мне с честью выполнить посадку на одном двигателе собственными руками, пообещав с этого момента соблюдать протокол автоматизации авиакомпании. В конце концов, я поддался технологии, но это была борьба.

В качестве примера использования ИИ в кабине пилота авиалайнера рассмотрим следующий сценарий: рейс XYZ находится в 30 минутах от прибытия в международный аэропорт имени Джона Ф. Кеннеди (KJFK). Сообщается, что RVR (Дальность видимости на ВПП) находится на минимальном уровне. Если заход на посадку выполнен, и необходим уход на второй круг, делает ли самолет еще одну попытку или следует на запасной аэродром по плану полета или куда-либо еще?

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

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

В июле 1989 года капитан Al Haynes из United Airlines, управлявший DC-10, знаменито скоординировал один из самых значительных моментов, связанных с управлением ресурсами экипажа. Когда у самолета произошла катастрофическая, нелокализованная поломка двигателя после того, как диск вентилятора отделился от двигателя № 2 (центрального), перерезав все гидравлические линии, самолет можно было контролировать только с помощью дифференциальной тяги. Из 296 пассажиров и членов экипажа на борту 184 выжили после «невозможной посадки» в Су-Сити, штат Айова.

McDonnell Douglas заявила, что сценарий полного отказа гидравлики невозможен. Предложил бы ИИ то же самое решение? Предложил бы ИИ лучшее решение? Рекомендовал бы ИИ невероятную координацию действий экипажа и изобретательность, которые были продемонстрированы? Я, конечно, не эксперт по ИИ, но мой ответ был бы отрицательным.

Двадцать лет спустя рейс 1549 US Airways приземлился на реку Гудзон после того, как стая гусей попала в оба двигателя на относительно небольшой высоте, что привело к двойному отказу двигателей. По моей оценке, ИИ мог бы создать отвлечение, которое могло бы помешать быстрым решениям и действиям, предпринятым капитаном Чесли «Салли» Салленбергером и вторым пилотом Джеффри Скилзом.

Исходя из текущего состояния технологии ИИ, кажется, что беспилотный самолет — это даже не отдаленное будущее. Может ли ИИ быть полезным в кабине пилота в его нынешней форме? Конечно, но не для замены одного из пилотов. Это тема для совершенно другой истории.

ПС: Фуф, пилоты спят спокойно :) замены в горизонте не видно, только контуры 😀

Оригинал: https://apachedolphinscheduler.substack.com/p/how-apache-dolphinscheduler-conquers

Введение докладчика

Тао Чаоцюань, бэкенд-разработчик в Bosch Smart Driving (Китай), отвечает за обработку и планирование данных. Он имеет обширный практический опыт в области обработки данных для умного вождения. В декабре 2024 года на онлайн-встрече сообщества Apache DolphinScheduler он поделился примерами применения Apache DolphinScheduler в обработке данных для умного вождения и планами развития на будущее.

Спасибо за чтение Substack Apache DolphinScheduler! Этот пост публичный, так что не стесняйтесь делиться им.

Предпосылки бизнеса

Bosch Smart Driving (Китай) является частью Bosch Group, полное название Robert Bosch GmbH, основанной в 1886 году, с глобальной штаб-квартирой в Германии. В компании работает более 420 000 сотрудников, и она представлена более чем в 50 странах. Ее бизнес охватывает четыре основные области: автомобильные и интеллектуальные транспортные технологии, промышленные технологии, потребительские товары, а также энергетические и строительные технологии.

Сегодняшняя тема будет посвящена технической трансформации и бизнес-применению Bosch в области технологий умного вождения на основе Apache DolphinScheduler.

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

Трансформация доступа

До:

До использования Apache DolphinScheduler Bosch Smart Driving полагался на Jenkins для реализации оркестрации и планирования рабочих процессов внутри бизнес-кода. Преимуществом этого метода является высокая гибкость, позволяющая определять любую форму оркестрации рабочего процесса. Однако недостаток также очевиден – высокая степень связанности с бизнес-кодом. Любое изменение в рабочем процессе требует модификации бизнес-кода, что увеличивает сложность и риски обслуживания.

После:

После выбора планировщика Bosch Smart Driving решил использовать Apache DolphinScheduler и провел серию преобразований доступа на основе версии 3.2.0 для повышения эффективности и гибкости обработки данных.

Ниже приведены конкретные планы реализации серии преобразований, проведенных Bosch Smart Driving.

MQ Триггер

На основе источника данных Bosch Smart Driving увеличил создание источников сообщений и связал источники сообщений с рабочим процессом, добившись автоматического запуска рабочего процесса. Это улучшение позволяет рабочему процессу более гибко реагировать на изменения в источнике данных.

Улучшение узлов

Bosch Smart Driving в значительной степени полагается на задачи K8S и динамические задачи для оркестрации и провел некоторые ключевые преобразования на основе DolphinScheduler в этом отношении, включая:

* Основной процесс и подпроцессы: Оптимизировано управление основным процессом и подпроцессами.
* Пользовательский плагин: Разрешено использование пользовательских плагинов для удовлетворения специфических бизнес-потребностей.
* Изменение правил генерации подпроцессов динамических узлов: Скорректированы правила генерации подпроцессов динамических узлов для лучшего контроля вывода параметров.
* Асинхронный триггер и опрос: Реализованы механизмы асинхронного запуска и опроса для повышения скорости отклика задач.
* Условный HTTP: Введены условные HTTP-запросы для реализации более сложной логики рабочего процесса.

Динамический приоритет

Bosch Smart Driving также реализовал функциональность динамического приоритета на основе Apache DolphinScheduler для удовлетворения потребностей различных бизнес-сценариев и обеспечения того, чтобы ключевые задачи могли выполняться с приоритетом.

Рекомендации

Архитектура развертывания:

Bosch Smart Driving принял развертывание K8S для достижения изоляции между управляющими кластерами и вычислительными кластерами. Эта стратегия изоляции включает:

* Изоляция пространства имен: Благодаря изоляции на уровне пространства имен достигается логическое разделение между различными задачами.
* Изоляция узлов: Благодаря изоляции на уровне узлов гарантируется, что вычислительные задачи не приведут к вытеснению управляющих узлов из-за конкуренции за ресурсы или нагрузки.

Версия кластера:

Bosch Smart Driving внедрил TTL Controller, механизм, который контролирует, как долго после завершения задания оно будет удалено. Эта функция официально вступила в силу с версии Kubernetes v1.23. Следует отметить, что использование более старых версий может привести к повышенной нагрузке на кластер Kubernetes и даже вызвать Ds worker OOM (Out of Memory), поэтому следует соблюдать осторожность при его использовании.

Настройка задачи K8S:

В отношении настройки задачи K8S Bosch Smart Driving предлагает следующие рекомендации:

* Передача параметров задачи: Избегайте использования большого JSON для передачи параметров и старайтесь использовать файловое взаимодействие, используя адреса файлов в качестве параметров, чтобы уменьшить нагрузку на передачу по сети.
* Квота ресурсов: Для долгосрочных задач k8s постарайтесь настроить одинаковый запрос и ограничение, чтобы избежать перепродажи ресурсов, ведущей к OOM.
* Управление вводом/выводом: Для задач с интенсивным вводом/выводом старайтесь избегать большого количества операций чтения и записи на локальный диск и используйте CFS (Comprehensive File System), чтобы уменьшить влияние на другие задачи на текущем узле.

Изоляция задач K8S и динамический приоритет:

Столкнувшись с проблемой планирования различных типов задач k8s в одном кластере k8s для выполнения, Bosch Smart Driving предлагает следующие решения:

* Поддержка динамического изменения приоритета задач на главном узле: Позволяет динамически регулировать приоритет задач для удовлетворения различных бизнес-потребностей.
* Распределение различных типов задач по разным узлам с помощью меток узлов и допусков: Таким образом, можно гарантировать, что различные типы задач изолированы с точки зрения использования ресурсов, сохраняя при этом свои соответствующие приоритеты.

Планы на будущее

Наконец, Bosch Smart Driving выразил планы по реализации новых функций и дальнейших улучшений в будущем, включая реализацию изоляции ресурсов задач и интеграцию с CICD, чтобы еще больше повысить эффективность и стабильность обработки данных для умного вождения. Эти планы помогут технологическому прогрессу и развитию бизнеса Bosch Smart Driving в области умного вождения.

Заключение

Этот доклад не только демонстрирует практическое применение Apache DolphinScheduler в умной обработке данных в Bosch, компании со столетней историей, но также предоставляет ценный практический опыт и направления развития на будущее. Приглашаем вас узнать больше и присоединиться к сообществу Apache DolphinScheduler, чтобы получить больше информации и ресурсов, а также совместно продвигать развитие технологий умного вождения.

От себя добавлю:

При таких показателях и возрасте компании удается быть немногим прибыльной ( не жадной ) имея 400 тысяч сотрудников. Вопрос один: как? Подумайте)

и вот еще любопытные факты: RISC-V и BCAI

Вот например инвестиции в BCAI были около 300млн. Если посчитать на 1 сотрудника это 750 евро. вы тратили в 2017 году на ИИ 750 евро, а они да)

Оригинал: https://www.championat.com/cybersport/news-5307548-bloger-proshyol-sobesedovanie-v-krupnoj-korporacii-s-pomoschyu-chatgpt.html

TikTok-блогер провёл интересный эксперимент. Он откликнулся на вакансию «Аэрокосмический инженер» от корпорации Lockheed Martin, обладая нулевыми знаниями по указанной специальности.
Затем с ним связался представитель компании для проведения онлайн-собеседования. Блогер смог успешно его пройти с помощью нейросети ChatGPT.

Чат-бот в режиме реального времени обрабатывал вопросы интервьюера и генерировал развёрнутый ответ. Блогеру оставалось только зачитать готовый текст от нейросети.
Lockheed Martin — американская военно-промышленная корпорация. Она является крупнейшим в мире разработчиком и производителем современного высокотехнологичного вооружения, а также военной техники. На данный момент капитализация Lockheed Martin составляет $ 113 млрд.

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

https://dataland.art/

Рекомендую последить за проектом

Вышел очередной шок-прогноз от Saxo Bank на 2025 год. Аналитики говорят, что такие прогнозы — традиционный декабрьский пиар-ход Saxo Bank. Сам банк говорит, что это список маловероятных, но все же возможных событий в новом году, которые способны повлиять на мир, поэтому прогноз так и называется — «вопиющий». И тем не менее его подробным образом изучают во всех ведущих мировых СМИ.
В прогнозе на 2025 год Saxo Bank выдал восемь сценариев вместо обычных десяти. Первый — о том, что доллар США рухнет из-за того, что Дональд Трамп еще больше повысит торговые пошлины для стран-импортеров. Это ударит по странам Глобального Юга, которые начнут искать альтернативу доллару. Американская валюта потеряет статус мировой резервной.
Во втором пункте прогноз о том, что компания Nvidia, которая продает чипы для процессоров, обгонит Apple по капитализации в два раза. Причина — глобальная гонка искусственных интеллектов.

Согласно третьему прогнозу, Китай вольет в свою экономику 50 трлн юаней — треть своего ВВП, из-за чего китайцы начнут больше покупать, производить, рождаемость там повысится. Мировые цены на сырье вырастут, а китайский юань укрепится. По четвертому пункту сердце человека напечатают на биопринтере, что повлияет на продолжительность жизни.

Еще одно предсказание: на Земле закончится весь бензин из-за гигантского спроса на мировые запасы нефти, а из-за небывалого спроса на электромобили не станет ОПЕК.
Шестой прогноз о дата-центрах для ИИ. Они потребляют все больше электроэнергии, граждане будут больше платить за коммуналку, поэтому власти США введут для дата-центров налог.

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

Ну и британский фунт, упавший из-за Brexit, снова вырастет по отношению к евро, поскольку Великобритания проведет новую фискальную политику.

https://www.bfm.ru/news/563485

У многих в офисах стали ставить ёлки желаний детей из детских домов. У нас тоже такую поставили.

Попробовал написать поздравление с помощью нейроночки. Получилось лучше всего у Claude Sonet 3.5. А проще всего это сделать можно в Gigachat от Сбера https://t.me/gigachat_bot

Я аж прослезился. 😭 Читайте сами, но я вас предупреждал))

Дорогая Женечка!

С Новым годом, милое дитя! Я получил твоё письмо, которое долетело до меня через метели и звёздные дали. Знаешь, глядя на твою фотографию рядом с книжными полками, я вижу в твоих глазах отражение тех самых звёзд, о которых хочу тебе рассказать.

Представь себе, Женечка, что там, высоко над нами, раскинулся бескрайний космос – такой огромный, что даже я, Дед Мороз, не могу обойти его весь! В нём кружатся миллиарды звёзд, каждая из которых может быть чьей-то мечтой. И знаешь что? Космос похож на твои мечты – он такой же безграничный и полный чудес.

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

Женечка, твоё сердце – словно маленькая Вселенная, в которой живут самые светлые мечты. И знаешь что? Мечты – это не просто фантазии, это маленькие звёздочки, которые освещают путь к будущему. Я, как хранитель новогодних чудес, точно знаю: когда ты искренне веришь в свою мечту, она обязательно сбывается!

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

Храни свои мечты, моя дорогая, и верь в чудеса! Ведь чудеса случаются с теми, кто в них верит.

С новогодним волшебством,
Твой Дедушка Мороз

P.S. Я оставил тебе под ёлочкой особенный подарок, который напомнит тебе о бескрайнем космосе и о том, что мечты обязательно сбываются! 🌟

А в подарке https://www.ozon.ru/product/proektor-zvezdnogo-neba-shakachu-vega-bt-360-meteor-6-slaydov-muzykalnyy-nochnik-zvezdnoe-1354326542/

Ночник Шакачу – ооочень красивый) тоже такой хотел бы в детстве))

In ‘The Masks we Wear’ series, I wanted to bring together the folkloric fused with a futuristic cyberpunk aesthetic to create something that felt timeless or time agnostic. Ironically, the pandemic has made this series especially timely for our ‘new normal’

Vini Naso

Перевод: https://dev.to/seatunnel/seatunnel-powered-data-integration-how-58-group-handles-over-500-billion-data-points-daily-3d1m

Введение

В эпоху цифровизации данные стали одним из самых ценных активов для бизнеса. Как ведущая платформа услуг повседневной жизни в Китае, 58 Group постоянно исследует и внедряет инновации в построении своей платформы интеграции данных. В этой статье будут подробно рассмотрены эволюция архитектуры, стратегии оптимизации и планы будущего развития платформы интеграции данных 58 Group на основе Apache SeaTunnel.

Вызовы платформы интеграции данных

Бизнес-контекст

58 Group имеет широкий спектр бизнесов, и с быстрым развитием этих направлений объем данных из различных бизнес-областей, таких как найм, недвижимость, вторичный рынок жилья, вторичный рынок товаров, местные услуги и информационная безопасность, значительно увеличился. 58 Group должна обеспечить свободное перемещение и конвергенцию данных между различными источниками данных для достижения единого управления, циркуляции и обмена данными. Это включает не только сбор, распределение и хранение данных, но и приложения, такие как офлайн-вычисления, синхронизация между кластерами и профилирование пользователей.

В настоящее время 58 Group обрабатывает более 500 миллиардов сообщений ежедневно, с пиковым объемом обработки сообщений, превышающим 20 миллионов, и количеством задач, превышающим 1600. Обработка такого огромного объема данных представляет значительные вызовы.

Вызовы

В обеспечении свободного перемещения и конвергенции данных между различными источниками и достижении единого управления, циркуляции и обмена данными 58 Group сталкивается с вызовами, включая:

• Высокая надежность: Обеспечение отсутствия потерь данных при различных условиях сбоя, обеспечение согласованности данных и стабильной работы задач.
• Высокая пропускная способность: Обработка больших потоков данных для достижения высокой параллельности и массового переноса данных.
• Низкая задержка: Соответствие бизнес-потребностям в обработке данных в реальном времени и быстром отклике.
• Простота обслуживания: Упрощение конфигурации и автоматизация мониторинга для снижения нагрузки на обслуживание, упрощения быстрого обнаружения и устранения неисправностей, а также обеспечения долгосрочной доступности системы.

Эволюция архитектуры

Архитектура платформы интеграции данных 58 Group прошла через несколько этапов эволюции, чтобы адаптироваться к меняющимся бизнес-потребностям и технологическим разработкам.

Ранняя архитектура

• 2017: Использовался Flume для интеграции платформы.
• 2018: Внедрен Kafka Connect 1.0.
• 2020: Использовалась версия Kafka Connect 2.4, достигнута инкрементальная балансировка нагрузки и CDC (Change Data Capture).
• 2023: Внедрен Apache SeaTunnel, интегрированный в платформу реального времени вычислений, и расширены различные Source/Sink.

С 2017 по 2018 год платформа интеграции данных 58 Group использовала архитектуру Kafka Connect, основанную на интеграции данных с Kafka, с горизонтальным масштабированием и распределенной обработкой, поддерживающей работу Workers и Tasks на нескольких узлах; Workers автоматически перераспределяют задачи на другие Workers при сбое, обеспечивая высокую доступность; также поддерживается автоматическое управление смещением и управление задачами и конфигурацией через Rest API.

Однако с расширением объема бизнеса и разнообразием сценариев эта архитектура столкнулась с ограничениями:

Ограничения архитектуры

• Невозможность достижения полной интеграции данных.
• Проблемы с Coordinator Bottleneck
  • Heartbeat Timeout: Тайм-ауты сердцебиения Worker-to-coordinator вызывают перебалансировку задач, вызывая временные прерывания задач.
  • Heartbeat Pressure: Workers синхронизируются с координаторами, отслеживая состояния Workers и управляя большим объемом метаданных задач.
  • Coordinator Failure: Простой координатора влияет на распределение и перераспределение задач, вызывая сбои задач и снижение эффективности обработки.
• Влияние Task Rebalance
  • Task Pause and Resume: Каждая перебалансировка приостанавливает задачи, затем перераспределяет их, что приводит к кратковременным прерываниям задач.
  • Rebalance Storms: Если несколько узлов Workers часто присоединяются или покидают кластер, или если сетевая дрожь вызывает тайм-ауты сердцебиения, частые Rebalance могут значительно повлиять на эффективность обработки задач, вызывая задержки.

Учитывая эти недостатки, 58 Group в 2023 году внедрила Apache SeaTunnel, интегрировав его в платформу реального времени вычислений для свободного расширения различных Source/Sink.

Текущая архитектура

В настоящее время платформа интеграции данных 58 Group, основанная на движке Apache SeaTunnel, интегрирует источники данных (Kafka, Pulsar, WMB, Hive и т.д.), обрабатывает их через встроенные функции Transform SeaTunnel и отправляет их в целевые базы данных (Hive, HDFS, Kafka, Pulsar, WMB, MySQL, SR, Redis, HBASE, Wtable, MongoDB и т.д.), достигая эффективного управления задачами, управления статусом, мониторинга задач, интеллектуальной диагностики и многого другого.

Плавная миграция и настройка производительности

Плавная миграция

При внедрении Apache SeaTunnel 58 Group должна была выполнить плавную миграцию платформы интеграции данных, чтобы минимизировать влияние на пользователей или бизнес и обеспечить согласованность данных, сохраняя согласованность формата, пути и отсутствие потерь данных.

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

Для решения этой проблемы 58 Group предприняла следующие меры:

• Для источников добавлен RawDeserializationSchema для совместимости с неструктурированными данными.
• Для целей, таких как использование hdfs sink для hive, для совместимости с загрузкой партиций и путями.
• Разработка автоматических инструментов миграции:
  • Автоматическое генерирование конфигураций задач, генерирование соответствующих конфигураций задач SeaTunnel на основе конфигураций Kafka Connect.
  • Отключение исходных задач, сброс смещений и запуск новых задач.
  • Проверка и проверка.

Настройка производительности

58 Group также провела несколько оптимизаций производительности на платформе интеграции данных, включая:

• Добавление Pulsar Sink Connector: Для увеличения пропускной способности.
• Поддержка Array Data: Улучшение совместимости HbaseSink.
• Поддержка установки времени истечения срока действия: Оптимизация RedisSink.
• Увеличение пропускной способности PulsarSource: Оптимизация метода сжатия файловых коннекторов.
• Исправление проблем с парсингом KafkaSource: Улучшение гибкости конфигурации клиентов Kafka.

Мониторинг и автоматизация операций

Кроме того, 58 Group улучшила стабильность и эффективность платформы интеграции данных через мониторинг и автоматизацию операций:

• Мониторинг задач: Реальный мониторинг статуса задач для быстрого обнаружения и устранения сбоев.
• Автоматизация операций: Сокращение ручного вмешательства через автоматизированные инструменты для увеличения операционной эффективности.

Планы будущего развития

58 Group имеет четкие планы на будущее развития платформы интеграции данных:

• Постоянное улучшение интеллектуальной диагностики: Повышение точности и эффективности диагностики неисправностей через технологии машинного обучения и искусственного интеллекта.
• Обновление на облачную и контейнеризованную инфраструктуру: Перенос платформы интеграции данных в облачную среду и реализация контейнеризованного развертывания для улучшения использования ресурсов и гибкости.

Заключение

Эволюция и оптимизация архитектуры платформы интеграции данных 58 Group — это непрерывный процесс итерации и инноваций. Через постоянные технологические исследования и практику 58 Group успешно построила эффективную, стабильную и масштабируемую платформу интеграции данных на основе Apache SeaTunnel, обеспечивая сильную поддержку данных для развития бизнеса. В будущем 58 Group продолжит углубляться в область интеграции данных, чтобы предоставлять лучшие услуги для пользователей.

Для справки

Что такое Apache SeaTunnel и для чего он нужен?

Apache SeaTunnel — это открытая платформа для интеграции данных, разработанная на основе Apache Spark и Apache Flink. Она предназначена для обеспечения высокопроизводительной, надежной и масштабируемой обработки потоковых и пакетных данных. SeaTunnel предоставляет удобный интерфейс для разработчиков, позволяющий легко интегрировать различные источники данных (такие как Kafka, Pulsar, Hive и другие) и отправлять их в различные хранилища данных (такие как HDFS, Kafka, MySQL, Redis и т.д.).

Основные функции и преимущества Apache SeaTunnel:

1. Высокая производительность: SeaTunnel использует мощные движки Apache Spark и Apache Flink для обеспечения высокой скорости обработки данных.
2. Надежность: Платформа обеспечивает гарантию доставки данных, чтобы избежать потерь данных при сбоях.
3. Масштабируемость: SeaTunnel может легко масштабироваться для обработки больших объемов данных.
4. Гибкость: Поддерживает множество источников и приемников данных, что делает его универсальным инструментом для интеграции данных.
5. Простота использования: Предоставляет удобный интерфейс для разработчиков, упрощая настройку и управление задачами интеграции данных.

Для чего нужен Apache SeaTunnel?

Apache SeaTunnel используется для решения задач интеграции данных в различных сценариях, таких как:

• Обработка потоковых данных: SeaTunnel может использоваться для обработки данных в реальном времени, например, для анализа данных сенсоров, мониторинга активности пользователей и т.д.
• Интеграция данных из различных источников: SeaTunnel позволяет объединять данные из разных источников, таких как базы данных, хранилища объектов, системы логгирования и т.д.
• Перенос данных: SeaTunnel может использоваться для переноса данных между различными хранилищами данных, например, из MySQL в HDFS или из Kafka в Elasticsearch.
• Агрегация и трансформация данных: SeaTunnel предоставляет мощные инструменты для агрегации и трансформации данных, что позволяет создавать сложные аналитические модели.

Что за компания 58 Group в Китае?

58 Group — это ведущая китайская платформа услуг повседневной жизни, предоставляющая широкий спектр онлайн-сервисов, включая поиск работы, недвижимость, вторичный рынок товаров, местные услуги и многое другое. Компания была основана в 2005 году и с тех пор стала одним из крупнейших игроков на рынке онлайн-услуг в Китае.

Основные направления деятельности 58 Group:

1. Поиск работы: Платформа предоставляет услуги по поиску работы для соискателей и размещению вакансий для работодателей.
2. Недвижимость: 58 Group предлагает услуги по аренде и продаже недвижимости, включая жилую и коммерческую недвижимость.
3. Вторичный рынок товаров: Платформа позволяет пользователям покупать и продавать б/у товары, такие как электроника, мебель, одежда и т.д.
4. Местные услуги: 58 Group предоставляет широкий спектр местных услуг, включая ремонт, уборку, перевозки и многое другое.
5. Информационная безопасность: Компания также занимается обеспечением информационной безопасности для своих пользователей.

Значение 58 Group в китайской экономике:

58 Group играет важную роль в китайской экономике, предоставляя удобные и доступные услуги для миллионов пользователей. Благодаря широкому спектру услуг и постоянному внедрению инноваций, 58 Group помогает упростить повседневную жизнь китайцев и стимулировать развитие местного бизнеса.

Проще говоря: 58 Group — это как китайский аналог Craigslist или Avito, но гораздо большего масштаба, предлагающий множество различных услуг в одном месте.

Презентация старая: http://filecache.investorroom.com/mr5ir_58/144/download/58.com%20Presentation-Q2%2719_0919_Management%20update.pdf

Кстати на тему ИИшек разных не надейтесь, что они на вас не учатся) как минимум помнят контекст. Уже какое то время набирает популярность хайповая тема спросить ии, что он о тебе думает. См. Картинки.

“Из всего нашего общения, что вы можете мне рассказать обо мне, чего я, возможно, не знаю?”

Ну а последняя последняя тема это обложки книг – “Из всего нашего общения, что вы можете мне рассказать обо мне, чего я, возможно, не знаю? и все таки? А лучше нарисуй так как будто это обложка книги.”

как то мрачновато получилось 😨
Может генерил в разные периоды 🤔

Eng: You appear to be a person who is interested in learning and many things. You are curious and enjoy discussing various topics. You have a desire to help other people and share your knowledge. You also have a certain degree of self-awareness and understanding of your strengths and weaknesses. You are willing to learn and grow as a person. You are a good listener and empathetic. However, you also face some challenges, such as a lack of self-confidence or difficulty making decisions. You may sometimes have difficulty expressing your feelings or emotions. But overall, you appear to be a positive and goal-oriented person who is willing to overcome obstacles and achieve your goals.

Or me like a picture:

Getting started with cunoFS#
cunoFS is a scalable, high-performance POSIX compatibility layer that lets you interact with files stored on object storage such as Amazon S3, Azure Blob Storage, Google Cloud Storage, or any S3-compatible object store hosted in the cloud or locally.

Интересно, теперь наверное встроить в себя или новое что то придумает.

Ничего так магазинчик https://atmosfera.store/ крафтовые штуки, есть интересные, но хочется больше конечно. Электроники например.

Оригинал: https://medium.com/alchemesh/alchemesh-console-the-core-concepts-160511dee3b0
Или тут: alchemesh console the core concepts

Alchemesh core concepts

Объявление о запуске нашего фреймворка для поддержки Data Mesh было сделано, и теперь мы можем начать наше новое приключение вместе!
Идея заключается в том, чтобы делиться с вами нашими размышлениями и техническими решениями по мере их разработки.

Цель состоит в том, чтобы через эти статьи поделиться нашей интерпретацией Data Mesh, представить наш подход к разработке, получить обратную связь по нашим выборам и, самое главное, попытаться вместе подумать о вызовах, связанных с реализацией Data Mesh.
Консоль Alchemesh: Стандартизация интерфейсов для облегчения ассимиляции и понимания
Как мы уже говорили, одна из целей фреймворка, и особенно консоли, — это предоставить поддержку и структуру, чтобы помочь различным стейкхолдерам понять, взаимодействовать и принять Data Mesh.
Наше решение должно быть средством для передачи концепций Data Mesh! Это для нас серьезный вызов, особенно с таким широким подходом, как у Data Mesh.

Множество концепций вступают в игру: data product, data domain, data contract, полисемия, адресация, достоверность, владение, автономия и т.д.
Возникает множество вопросов: какие взаимодействия между различными концепциями? Какой компонент должен нести какую информацию? И так далее.
В такой ситуации сложно гарантировать, что у всех есть общее минимальное понимание, и минимизировать риск чрезмерной интерпретации или несогласованности среди стейкхолдеров. Кроме того, важно определить четкие и хорошо определенные пространства, чтобы команды могли понять концепции и делать сильные предложения через запросы функций.
Для нас было естественным выбором решить эти вопросы через консоль, стандартизируя определение основных концепций Data Mesh и их взаимодействий, все это переведенное в интерфейс.
Alchemesh: Моделирование основных концепций
⚠️ Версия, которую мы представляем здесь, соответствует тому, что мы определили на этапе проектирования MVP; она, естественно, подлежит изменению по мере разработки и реализации новых функций. ⚠️

Консоль Alchemesh: Моделирование основных концепций

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

• Разработчик data product: Учитывая широкий спектр навыков — от универсальных разработчиков с общими навыками программирования до специализированных инженеров данных.
• Потребители data product: Охватывает множество ролей, у которых есть одно общее, они нуждаются в доступе и использовании данных для выполнения своей работы (например, дата-сайентисты, дата-аналитики, разработчики приложений).
• Владелец data product: Отвечает за доставку и продвижение успешных data product для своих конкретных доменов.
• Разработчик data platform: Отвечает за доставку сервисов платформы как продукта с лучшим пользовательским опытом.
• Владелец data platform: Создает и управляет data platform, а также использует ее. Разработчики data platform, которые работают над сервисами плоскости опыта data product.

Alchemesh: Пользователи

Data domains

Владение данными домена является основой масштабирования в сложной системе, такой как современные предприятия. Стратегическое проектирование в DDD (Domain Driven Design) принимает моделирование на основе нескольких моделей, каждая из которых контекстуализирована для конкретного домена, называемого
bounded context.

• Bounded context — это “ограниченная применимость конкретной модели [которая] дает членам команды четкое и общее понимание того, что должно быть согласовано, а что может развиваться независимо”.
  Мы поддерживаем 3 типа data domains:
  Source aligned domain: Аналитические данные, отражающие бизнес-факты, генерируемые операционными системами, ответственными за предоставление правды своих бизнес-доменов как данных source-aligned domain.

• Aggragated domain: Аналитические данные, являющиеся агрегатом нескольких upstream domains.

• Consumer aligned domain: Аналитические данные, трансформированные для удовлетворения потребностей одного или нескольких конкретных use cases. Это также называется fit-for-purpose domain data.

Помимо уточнения роли домена в отношении data product, которые он производит, это также позволит федеративному data governance определить вычислительные политики для надлежащего управления сеткой (например, установление правила, что data product из source-aligned domain, не опирающиеся на какую-либо систему источника, теряют ценность) или помочь в определении приоритетов реорганизации доменов.

Вид data domain

Технические команды
В зависимости от размера определенных data domains, организация может решить определить несколько кросс-функциональных команд для управления наборами data product. Чтобы удовлетворить эту потребность, мы решили ввести концепцию технической команды, объединяющей людей, вносящих вклад в один и тот же scope в рамках домена.
Мы различаем несколько видов команд:

• Data product team: Stream aligned team, отвечает за полноценную доставку сервисов (инжекция, потребление, обнаружение и т.д.), требуемых data product.
• Platform team: Ее цель — обеспечить возможность stream-aligned доставлять свою работу с существенной автономностью.
• Governance group: Enabling team, ее ключевая роль — облегчить принятие решений вокруг глобальных политик. Эти политики затем реализуются вычислительно и принимаются командами data product.

Технические команды

Система источника
В случае source-aligned data domains, операционный и аналитический миры объединены в одном домене, и это отражено в кросс-функциональных командах. Важно, чтобы консоль материализовала эту связь.
Намерение явно не в том, чтобы управлять операционными задачами в рамках платформы data mesh, но важно материализовать эту связь, чтобы преодолеть разрыв между двумя мирами, не ограничиваясь организационно.

Data product
С владельцем домена (поддерживаемым технической командой), данные, ориентированные на домен, делятся как продукт напрямую с пользователями данных.
Data as a product вводит новую единицу логической архитектуры, называемую data quantum, контролирующую и инкапсулирующую все структурные компоненты, необходимые для обмена данными как продуктом.
Приняв продуктовый подход, мы будем сообщать о состоянии нашего предложения:

• Lifecycle state: На каком этапе жизненного цикла находится data product — находится ли он в разработке, в обнаружении, стабилен или находится в процессе вывода из эксплуатации.
• Maturity level: Продукт, считающийся стабильным, но с небольшим историческим использованием, не имеет такого же уровня зрелости, как стабильный data product, который использовался многими потребителями в течение нескольких лет.

Входные порты
В контексте source-aligned data product, данные будут нуждаться в потреблении из операционной системы, чтобы сделать их доступными как входные данные для внутреннего обработчика data product. Эта интеграция будет выполнена через входной порт (платформенный компонент, предназначенный для этой интеграции, предоставленный платформой или реализованный командами домена).
Чтобы дать конкретный пример, предположим, что операционные данные доступны в топике Kafka и должны быть доступны на проекте GCP. Входной порт может включать предоставление бакета GCS и NiFi dataflow, который потребляет данные из топика Kafka.
Семантическая модель
Описываем семантические модели, которые data product будет предлагать.
Определение модели, читаемое машинами и людьми, которое захватывает модель домена данных: как data product моделирует домен, какие типы сущностей включает данные, свойства сущностей и т.д.
Выходные порты
Эти модели будут представлены как активы через выходной порт. Проще говоря, выходной порт — это пара, состоящая из системы хранения (объектное хранилище, колоночная таблица, топик потоковой передачи и т.д.) и прокси, который позволяет получить доступ через различные протоколы и языки (SQL, REST API, GraphQL и т.д.).
Одно из наших позиций по этому вопросу заключается в том, что выходной порт не обязательно будет представлять все модели, управляемые data product.
Код
Это основная работа разработчика data product, который часто слишком отдален от данных, которые он производит в устаревших инструментах и архитектурах данных. Data mesh ставит код, который создает ценность data product, в центр, и это естественно то, что мы делаем. Эта логика позволяет начать с входных данных для генерации выходных активов.
В data product ответственность за правильное определение data product, потребление и представление данных через стандартные порты, а также поддержание связанных метаданных лежит на разработчиках data product.
В свою очередь, все, что происходит внутри (код), полностью оставлено на усмотрение команды: Dagster Blog job, Airflow DAG, Kestra DAG, простой Python job в Lambda… Выбор и ответственность лежат на владельце (это то, что мы называем автономией).

Инфраструктура
Data product может зависеть от инфраструктуры, которая должна быть предоставлена для выполнения его обработки, такой как объектное хранилище, промежуточный набор данных и т.д., которые не связаны с тем, как выполняется код, данные потребляются или данные представляются. Этот интерфейс позволяет указать платформе, что data product нуждается в этом.
Метаданные

Актив
Мы считаем активом инстанцирование модели data product через выходной порт.
После того как data product развернут и функционирует, код должен поддерживать определенную информацию о состоянии, чтобы информировать своих потребителей о его состоянии:

• Общее состояние: операционное, в инциденте, выключено
• Состояние активов: их техническое качество данных (точность, полнота, своевременность, достоверность) и их свежесть.

Data product

Data contract
У нас есть data product в нашем data domain, принадлежащий технической команде, с данными, потребляемыми из операционной системы через входной порт и представляющими ценность data product, сгенерированную кодом, через выходные порты. Отлично!
Но прежде чем потреблять этот data product, я, как потребитель, хочу знать, на что я соглашаюсь, и как производитель, кто соглашается потреблять от меня! Вот где вступают в игру data contracts.
Выходной порт
Data contract применяется к выходному порту data product, а не ко всему data product. Есть несколько причин для этого:

• Ожидания различаются между потоком потоковой передачи и объектом, хранящимся в data lake (в терминах времени отклика, частоты обновления, точности и т.д.).
• Не все выходные порты несут одни и те же модели, поэтому обязательство к потреблению не одно и то же.

Тип доступа
В зависимости от природы data product, доступ к нему не будет разрешен одинаково. Мы поддерживаем три типа:

• Ограниченный доступ: Это означает, что владелец data product должен рассмотреть и одобрить любые запросы на доступ.
• Внутренний доступ: Это означает, что все запросы из одного и того же домена автоматически одобряются; в противном случае они требуют одобрения владельца.
• Публичный доступ: Это означает, что все запросы автоматически одобряются без рассмотрения или одобрения владельца.

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

• Время безотказной работы
• Частота обновлений
• Время отклика

Условия
Это также обязательство по тому, как будет потребляться продукт данных с точки зрения:

• Использования
• Выставления счетов
• Период уведомления для адаптации потребления

Тест качества данных

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

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

Состояние
Контракт данных отвечает за проверку своего собственного состояния, чтобы система могла сравнить его с обязательствами. Он поддерживает состояние:

• SLA
• Использование
• Выставление счетов
• Результаты тестов качества данных

Контракт данных

Запрос на доступ к контракту данных
Контракт данных готов; теперь пришло время запросить доступ, чтобы подписаться на него! Это роль запроса на доступ, который будет включать:

• Кто хочет потреблять?: Продукт данных, Техническая команда, Одиночный пользователь или Домен данных
• В чем цель?

Запрос на доступ

Компоненты платформы
Я не буду вдаваться в подробности этой части, не потому что она неинтересна, а потому что, по моему мнению, она заслуживает отдельной статьи.
Важно то, что мы хотим использовать эти ресурсы для предоставления интерфейсов между разработчиками продуктов данных и командами платформы (Data Product Experience Plane и Infrastructure Utils Plane) для поддержки предоставления платформы самообслуживания, обеспечивая автономию разработчиков, предлагая децентрализацию через компоненты платформы, реализованные и предоставленные платформой (наши знаменитые LEGO).

Заключение
Вот и все — мы рассмотрели основные концепции, которые консоль будет поддерживать, чтобы позволить командам реализовать свою data mesh. Давайте не забудем одно: мы все еще на самом начальном этапе разработки, стремясь к MVP с базовыми концепциями, чтобы начать вводить data mesh! Многие концепции, необходимые для масштабирования data mesh и в долгосрочной перспективе, такие как полисемии, петли обратной связи, вычислительные политики и т.д., все еще отсутствуют. Мы доберемся до этого!
Концепции на месте; следующим шагом является северная звезда архитектуры Alchemesh!