1. Нормальний ETL має інтегруватись з batch планувальниками кубів, та мати свої оператори що зможуть виправити помилки планування та Topology Skew під час маштабування. Вбудований batch планувальник кубів прийнято заміняти на Volcano, бо по функціоналу там як раз є topo-awereness й нормальний descheduling який вже базується на descheduler’і.

Більшість актуальних й підтримуваних MLOps стеків (Ray) вже інтегруються з Volcano, та відповідно є нативні поробки (для AutoML’ю та RL)...

2. Якщо говорити про IO/Storage Amplification — треба також інтегруватись з IPC та мережевим стеком. Відповідні рішення поверх Apache Arrow / Apache DataFusion дозволяють датафрейми шерити між контейнерами через shmem й полінг, в обхід мережевого стеку, або ж безпосередньо інтегруються в XDP та за потреби в DPDK через Demikernel libos.

... на практиці то зменьшує сукупну вартість володіння до 20х разів порівняно там десь з DataBricks’ом й до 8х разів з самохостом без кубів чи AWS Managed Airflow (MWAA).

Кому воно зараз треба, може краще навчитись в куби й бути конкурентноспроможними на ринку ?...

AirFlow тільки починає аргументувати «нахіба воно треба» бо є паркетний Object Store... й є якийсь там кривий KubernetesExecutor який не взаємодіє з існуючими планувальниками кубів.

Тоді як більшість серйозних компаній вже давно на Arrow сидять, й ETL’ки або в KubeFlink або в DataFusion ганяють.

AirFlow дійсно чудово підходить для неконкурентноспроможного персоналу, який відмовляється вчитись, й знає лиш пітон...

-

Просто люде не вміють в SQL, а байки про мікросервіси на тому фоні виглядають тупо.

В нас просто не-кваліфікат панує... неконкурентноспроможні більшість українських розробників на ринку.

Я не вважаю себе дуже розумним, бо то небезпечно.
Але зараз при перевищені певної квоти обсягів, й розумності рішення, виникає конфлікт інтересів, з подальшими ризиками для життя-здоров’я.

Ото як на посаду погранця чи іншого держ службовця, знімають «кастинги» з нібито «дачею хабаря» «щоб були слухняні», то в відповідних підприємствах дуже схожі практики... з «нібито зрадниками».

Загалом посередня стаття з посередньою цінністю, суб’єктивщиною ... яка має мало спільного з реальними інженерними задачами, й принципами реалізації.

1. Є проблема синхронізації розподіленного стану — її вирішують через СRDT (похідна міток Лампорта). Відповідно це Вже вирішено зі сторони БД алгоритмами консенсусу. Зазвичай механізму безперервного сходження та реалізації безперервної синхронізації зі сторони додатку, долучення додатків до процесів MVCC та логічної реплікації нема... Відповідно реалізують СQRS-ES патерни, для розділення сховищ даних на сховища читання-запису, й застосовують ручні перетворення СDC стріма з сховища неблокуючого запису у сховище блокуючого читання...

Типовим прикладом є Typed Akka з її EventSourcedBehaviour Replicated Event Sourcing та Durable State.

Відповідно при записі події, відбувається синхронізація стану акторів, й при досягненні строгої консистентності в кінцевому рахунку (strong eventual consistency) відбувається безпосередньо зберігання агрегату в сховище запису (зазвичай колоночна АР з TTL типу Cassandra/Scylla з 300К-1М TPS на запис). Аграгат той повністю денормалізований, й перед читанням має бути нормалізований через CDC, часто як логічна репліка кудись в PostgreSQL через Spark / Flink / Debezium тощо (до 300К TPS на читання)... там далі в повністю нормалізованій моделі читання, можна застосовувати контролювану денормалізацію, та версіонувати схеми...

В фронті то може бути там, наприклад y.js, з стрімінгами там в tRPC.

CREATE TABLESPACE fast_ssd LOCATION '/var/data/postgresql/ssd'  WITH seq_page_cost =1.1, random_page_cost=1.2, effective_io_concurrency=16, maintenance_io_concurrency=8;

CREATE TABLESPACE not_so_fast_hdd LOCATION '/var/data/postgresql/hdd' WITH seq_page_cost =1.2, random_page_cost=8.0, effective_io_concurrency=2, maintenance_io_concurrency=1;

CREATE TABLESPACE archive_glacier LOCATION '/var/data/postgresql/s3_glacier'  WITH seq_page_cost =1.2, random_page_cost=16.0, effective_io_concurrency=4, maintenance_io_concurrency=1;

 
CREATE MATERIALIZED VIEW active_user_data ... TABLESPACE fast_ssd AS SELECT json_agg() FROM active_users... WHERE u.active = true;

Якщо не вказувати STORAGE OPTIONS для індексів, табличок, й tablespace’ів з відповідними вартостями sequential / random IO — можна втратити до 200 разів швидкодії... потім городити Redis/Memcached, й страждати який поганий SQL й який поганий JOIN. Жарти про швидкий SSD без оптимізації схем БД й «моноліт повільніше» виглядають тупо.

2. В сучасних фреймворках там Dapr, Temporal, Orleans, Knative... зазвичай розглядають лише модель запису та якийсь Eventing поверх CloudEvents, абстракції Message брокерів, безпосередньо нормалізації, оптимізації IO amplification’a там нема... зараз є нормальні оператори до кубів типу CNPG / Stackgress, які по грошах часто в 1.5-2х рази дешевше й гнучкіше RDS’a. Треба пам’ятати що усі реалізації MVCC однопоточні — якщо запускається Postmaster’ом 16 процесів, то з pg-bouncer’a має виходити 16 підключень... відповідно для AWS то чудова можливість апсейлу окремого сервіса AWS RDS Proxy...

3. Розбивка моноліту на мікросервіси... взагалі-то оптимізаційна задача, яку поки що не часто вирішують на етапі компіляції додатків — має бути частиною типів відповідної мови програмування... й там всякі TLA+ спеки й формальна верифікація потім вспливають.

Чому цей завод вичислять і знищать!?

Бо є певна домовленість.

Ціль для горішника «якось же ж знайшлась»... от за тими ж принципами знаходяться й інші.

виробляються і поставляються

То виробляються, чи поставляються ?

Варто почитати їх Whitepaper’и... в журналах по Control Theory публічно реверсять патріоти)
Описують як роями дронів захищати від перехоплення балістичні ракети...
Ну й лазерний синтез магній-гідриду в підвалах — вишенька на тортику.

-

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

50 метрів — мало, як вже показала практика.

-

Дослідіть трохи питання Simulation Intelligence, й подумайте чому відповідних спеціалістів вже нема в живих.

Але в реальності...

1. Jax + Neuron SDK тема не розкрита, особливо з використанням Inferentia / Trainium й якогось предикативного маштабування на PredictKube чи подібного — люди зазвичай просто прикручують звичайний Torch Forecasting на TFT
2. KServe вже порядком морально застарів... там зазвичай або Nvidia Triton / Nvidia Dynamo inference, в залежності від того чи будуть залазити в ONNX, та відповідно чи є оптимізації з TensorRT. Потреби залазить в Service Mesh на linkerd/istio та сайдкари, особливо коли там є вже Cilium Mesh, зазвичай нема...
3. Замість KubeFlow багато компаній злізло на Ray.io й відповідно PyTorch з Jax чи Nvidia Warp kernel’ами. Сам по собі KubeFlow не достатньо добре підтримується (бо є вендорні розширення), й частіш зустрічається mlflow в нових проектах... хоча люди починають ганяти RL чи AutoML’і з тюнінгом гіперпараметрів, й всеодно злазять на Ray.
4. Тема керування датасетами не розкрита, відбілювання та відповідний Compliance, особливо ISO27701 та ISO42001
5. Зазвичай є ще вимоги опису сцен по OpenUSD, то було б доречне порівняння з актуальними моделями типу NVIDIA Picasso тощо

Так то загалом матеріал застарів на років 5...

Було б доречно розглянути актуальні проблеми планувальника, та відповідно Nvidia Device Plugin’а, бо там є феєричні баги, й Nvidia не чухається.

Відповідно по ціні NPU/TPU Inferenсе зазвичай в два рази дешевше за звичайний GPU Inference... там ще є FPGA Inference в AWS F1/F2 для всякого Simulation intelligence ...

Переходи на особистості, приниження, й замір «кваліфікіції» — теж не мають.

Мені прикро що людей обділило не тільки інтелектом... а й емоційним інтелектом.

p.s. що VxWorks що WindRiver я теж вважаю помийкою... але то деталі.

Аргументний аргумент.

Ваш досвід автомагічно робить Autherion системою реального часу ?
Чи може в освіту привносить якійсь практичні навички, які можуть забезпечити реальну користь ?

Просто шкода людей що звичайний розподілений консенсус в merkle деревах називають advanced алгоритмом...

Якщо після п’ятничного деплою трапився rollback — то він має трапитись спершу з перевіркою наслідків, на репліці... а для того треба в Immutable Infra, й девупси мають бути там з AWS SRA/PRA й infra drift’ом ...

Якщо й навіть трапляється феєрія — люди принаймні перевіряють можливість відкату, щоб продовжити після вихідних. Це, я вважаю, — нормальна практика. Коли не можна ролбекнутись без наслідків — нема сенсу деплоїти...

за допомогою Prophet

Ви ж в курсі що профет то звичайний stan обгорнутий отак пістоном ? Й в нормальні demand forecasting й anomaly detection завозять TFT / N-Beats / N-Hits на торчі.

де вся автоматика провалилася, але людина бачить проблем

Ну... весь AIOps зараз будується на LLM-агентах з відповідними MCP серверами в Observability, то зараз авторегресивна й автокорелятивна «автоматика» на типових статичних методах є лише першою ланкою автоматизації.

Скільки тестів — достатньо? Як виміряти «достатність»?

Мутаційним.

Найпростіше рішення — rollback

Є момент з healthcheck’ом, бо типові Liveness, Readiness, Startup проби не відпрацьовують для сервісів з деградованою доступністю — треба агрегувати затримки по викликах за останні 5-10хв та від того гарантувати вимоги р95 р99 до доступності. Зазвичай то зручно робити через k6 та пром.

Ви в курсі що для DefTech’у бракує спеціалістів з систем контролю та автоматизації математичного моделювання, й увесь той блокчейн йде лісом ?

Найближча до поточних задач комерційна компанія — це SpaceX, бо вони LBM/rVPM методи виконують на відеокартах, за тими ж принципами що й звичайні ML моделі.

Мені, особисто, огидно що хтось вважає що можна от просто «взяти й запустити» там Docker чи Kubernetes на дроні, й наліпити на те наліпку «система реального часу». Так вже є з auterion’ом, на який всі рівняються, бо довбо...

От... ну якщо вже говорити про LST, то там GPS потрібен лише на пуску, щоб розрахувати початкову траекторію та спланувати політ звичайним LQR’ом. Лише от в Excalibur S впровадили MPРІ з доводкою для рухомих цілей, й вона «така собі». У райте-гона системи наведення дублювані й доволі тупі, бо траекторії можливого руху цілі обчислюються під час пуску, й часто зі значним відхиленням (до 10м), дуже погано йому стає якщо джамиться джепас...

Є технологія композитної екструзії glass-filled pp з вакуумними всякими штуками... то до 50кг 155мм типу того ж екскалібура М982 можна робити в «домашніх промислових маштабах».

Ну по брейву віджималось раніш майже все... зараз не знаю як, й не цікавлюсь — довіри нема.

тригерить, це питання вимог і ЗП

Має більше тригерити питання військових злочинів й кругової поруки.
Вимоги на рівні «ми ніколи не бачили підручника Ogata чи Poley» та не можем визнати переваги MPPI/MPC над PID контролем, бо страшно. ЗП — як писав вище, в більшості випадків, з ухиленням від сплати податків то на цифру в 20к можна не дивитись.

Теорія контролю не дотягує до підходів 1970 року.

Це ті гранти які є основою для безумовної передачі інтелектуальної власності, прототипів, виробничих зразків, матеріальних й нематеріальних засобів виробництва ?