Звісно вона буває різна. Проте культура і підхід формують систему котра дає не тимчасовий ефект, а постіний на рівні масштабу.

Це абсолютно ніяк не впливає на бюджет компанії, бо це не матеріальна частина. Ви чи будуєте таку культуру, або ні.
Я працював і в стартапах на ранній стадії, і зрілих продуктах. Тож можу сказати сміливо, це залежить лише від бажання.
Приводжу приклади

1-й приклад це масштабування компанії Rocket Delivery від 12 людей до 130 в команді, ми наймали по 20 інженерів за квартал у середньому. На швидкість масштабування це не впливало. Запустили 8 країн і продукт ніколи не був гальмуючим фактором.

2-й приклад це перезапуск продукту в MAUDAU. Компанія мала проблеми зі швидкістю продукту, за 1,5 роки ми перизібрали команду і процеси, переписали все легасі і запустили мобільний застосунок. Зараз продуктова команда найшвидший департамент в компанії.

Звісно ідеального варіанту немає. Але даю реальні приклади де у мене це працювало без блокерів.

Так, але і мішленівську зірку вони не отримають. Тут питання цілей бізнес.
Ну і як на мене називати людей ідіотами досить токсична історія. Якими б вони не були впершу чергу це люди.

Бюрократія і жорстке централізоване управління дійсно можуть давати дуже швидкий результат. І приклади з Кореї чи Китаю це добре показують. Стаття не заперечує цього. Питання скоріше в довгостроковій стійкості і в ціні такого результату.
Такі моделі добре працюють, коли потрібна швидкість, дисципліна і виконання. Але вони часто обмежують ініціативу, знижують рівень ownership і роблять систему сильно залежною від центру прийняття рішень. Це нормально для держав або дуже великих структур, де головна задача масштаб і контроль. Ну і варто памʼятати, що це не будується за 1-2 роки.
У продуктових командах, на мою думку, де потрібні швидкі рішення на місцях, експерименти і постійні зміни, такий підхід починає гальмувати. Там важливо, щоб люди самі брали відповідальність і могли впливати на результат без постійного погодження зверху.

Є відчуття, що публікацію читали з цілю знайти питання, а не для того, щоб побачити сторонній погляд :)
Цитата з публікації "

В одному проєкті можна одночасно використовувати Data Warehouse і Data Mart або Data Mart і Data Lake

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

time travel і Slowly changing dimensions

ви, не бачите, бо ціль була ознайомити конкретно з 3-ма підходами на рівні концепту, поділитись баченням. Вона звісно не може бути вичерпною і не претендує такою бути. Думаю це може бути гарною темою для окремої публікації, де можна заглибитись в технічну складову і технічні критерії вибору.

Ахах) Це смішно)
Так, працюємо над виправленням. В нашому кейсі то нажаль наявність легасі частини.

Можливо в певних проєктах. Я чесно кажучи ще не зустрічав цей підхід на реальних проєктах. Проте враховуючи, що Delta Lake це допрацьований Data Lake, просто має уже напівструктурованні дані, то думаю вони разом розвивають цей напрямок.

1. Цікава думка) Наш мозок звик все класифікувати, гадаю звідти виходить така потреба.
2. Ну враховуючи обсяги даних і використання ML то більш ніж впевнений, що там Data Lake. Якщо я вірно зрозумів питання.

ось тут у AWS є гарна публікація на цю тему aws.amazon.com/what-is/structured-data.
сподіваюсь буде корисна

Дякую за зауваження і публікацію. Це гарна публікація і, на мою думку, вірне міркування.
Проте, варто зауважити, що в моїй публікації твердження про інформацію було вжито як один із варіантів даних. Інформація виникає, коли дані організовуються в контексті та структуровані таким чином, що набувають значення. Наприклад, це відбувається, коли ми аналізуємо дані про продажі та визначаємо тенденції.

Так, в AWS це Amazon Redshift, який є фактично прямою альтернативою Google BigQuery (GBQ). У Microsoft Azure найближчою альтернативою є Azure Synapse, який можна вважати аналогічним рішенням.