Профессия Data Engineer: хайп или реально надо

Привет! Я Data Engineer в NIX, фанат обработки данных больших и маленьких, поклонник Python. В этой статье расскажу, как Data Engineer помогает превращать сухие цифры в инсайты и почему разработчикам стоит попробовать свои силы в этом направлении.

Только ленивый не говорит, что работа с Big Data — профессия будущего. А я даже больше скажу: это потребность «здесь и сейчас». До 2003 года мы создали столько петабайтов данных, сколько сегодня производим каждые два дня. Аналитики Gartner среди техно-трендов 2021 года назвали облачные сервисы и кибербезопасность.

Тенденция легко объясняется. Огромные массивы Big Data нужно хранить в безопасности и обрабатывать, получая полезную информацию. На удаленке эти потребности компаний стали более ощутимы. E-commerce, Healthcare, EdTech хотят знать все о своих онлайн-потребителях. Пока данные лежат на серверах, толку от них нет.

Есть данные? А если найду?

Чистить, структурировать, конвертировать — основные операции Data-инженерии. Специалист должен знать, как объединить данные разного формата, собранные из нескольких источников. Три года я программирую на Python, из них два года погружен в Big Data. На личном опыте понял: для ежедневной работы нужно уметь больше.

Data Engineer — это сборная солянка четырех профессий:

Software Engineer. Пишет код, тестирует и оптимизирует его. По моему мнению, Software Engineer — простейший путь в Data-инженерию. Специалист знает, как устроены компьютер/программы, базово знаком с разработкой качественного ПО и работой с базами данных.

Big Data Developer. Понимает принципы обработки данных, использует различные инструменты для их трансформации. Он готовит описание моделей данных в зависимости от задачи или бизнес-процессов клиента.

Database Administrator. На его плечах — построение архитектуры хранилищ. Знает, как оптимальнее хранить данные и проводить над ними базовые операции.

Cloud Engineer. Объемы данных сегодня настолько большие, что хранить их на серверах слишком дорого или невозможно — они там просто не помещаются. В помощь — облачные решения. Инженер разбирается, какие есть cloud-решения, какова их структура, специфика и взаимодействие между собой, как настроить облачные сервисы.

Из каждого направления можно перейти в Data Engineering.

Data Engineer, Data Scientist или Data Analyst — кто круче?

Эта тройка специалистов плотно работает с данными. У каждого — свои обязанности. Data Engineer получает запрос от коллег найти релевантные данные, чтобы, например, узнать эффективность новой фичи. Инженер извлекает определенные данные из разных источников (сервера, приложения или облака), упрощает, обрабатывает их и загружает в нужное хранилище. Оттуда их берет Data Analyst — анализирует информацию и переводит ее в понятный клиенту формат.

Например, в виде отчета, инфографики, презентации. Специалист видит связь между найденными показателями, сравнивает их. Когда нужно спрогнозировать результат от реализации фичи или какого-либо процесса, подключается Data Scientist. Давайте на примере рассмотрим сотрудничество всех ролей в проекте.

Представим условную соцсеть для изучения иностранных языков. Люди находят друзей по переписке и практикуют английский, немецкий, китайский. Миллионы ежедневных пользователей оставляют цифровые следы: авторизуются через личную почту, покупают премиум-аккаунты, скачивают приложение, созваниваются по видеосвязи. Каждый клик регистрируется и отправляется на сервер. Компания хочет отследить эффективность и прибыльность платформы. Как в этом поможет Data-инженер? Лично — никак. Но с коллегами Data Scientist и Data Analyst найденные им данные превращаются в полезную информацию — статистику, инфографику, прогнозы.

Нельзя сказать, что кто-то из них полезнее, выполняет больше работы или лучше справляется с обязанностями. Объем задач у них и правда может отличаться и зависит от поставленных клиентом задач. Единственное — Data-инженер будто работает в «тени». Если вы коммуникабельны и умеете общаться с заказчиками, стоит присмотреться к профессии аналитика или Data Scientist. Но решать, конечно, вам.

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

Как строится работа с данными

Есть определенные источники данных. Задача инженера — получить оттуда информацию, «подружить» данные из разных источников, обработать и по запросу упростить и разнообразить их. Отправляем в БД запрос, написанный на Structured Query Language. SQL — самый распространенный язык для манипуляций с данными. Поэтому многие инструменты используют уже всем знакомый синтаксис. Например, Apache Hive или Impala.

Чтобы изменить данные, нужны специальные фреймворки. Apache Spark, Apache Flink и Hadoop MapReduce позволяют выполнять такие виды трансформаций:

  • data cleaning;
  • удаление дубликатов;
  • конвертация типов данных (строку в число или в дату);
  • фильтрация;
  • data joins;
  • data derivation.

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

Чаще всего для преобразования данных берут инструменты Python, Java и Scala. На Java созданы Hadoop, HDFS, Apache Cassandra, HBase и Apache Hive; на Scala — Apache Kafka и Apache Spark; на Python — Pandas/NumPy, Dask + обертки для фреймворков, написанных на других языках (PyFlink, PySpark, Python Hadoop API).

Чтобы все структурировать, есть два подхода — ETL и ELT. Если мы работаем с небольшим объемом или с базами готовых данных от разных клиентов, удобнее использовать ЕTL. Если много смешанной информации, подойдет ELT. В этом случае сначала загружаем данные в хранилище, трансформируем на отдельном сервере и по необходимости вытаскиваем.

Готовые данные попадают в data warehouse или data lakes. Доставку настраиваем через SQL-запрос или кастомный скрипт, включенный в API внешнего сервиса. Далее за дело берутся Data Analyst и Data Scientist. На основе данных они формируют полезную информацию. Первый — создает отчеты, графики и находит закономерности в данных, второй — с помощью подходов Machine Learning делает прогнозы.

Чем полезен Data Engineering

Без работы точно не останешься. Количество данных будет только расти. Понадобится их чистить, упорядочивать, анализировать. Знать основы Data Engineering полезно как минимум для следующих целей.

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

Увеличивать скорость доставки данных в целевую систему или к целевому пользователю. Скорость зависит от выбора фреймворка, подхода и сервиса. Например, Hadoop MapReduce более кост-эффективен по сравнению со Spark, но и скорость обработки данных ниже. Если у нас стриминговые данные, их удобнее и быстрее обрабатывать на лету, вместо того чтобы сохранять на диск, а обработкой заниматься когда-нибудь потом.

Уменьшать стоимость хранения данных. В 80-х годах 1 ГБ пространства на HDD стоил $500 тыс., а сейчас — $0,025. С тех пор объемы данных выросли в сотни раз, и жесткие диски с ними не справляются. Удобнее и безопаснее хранить информацию на облаке. Терабайты на сервисе обойдутся от нескольких десятков до сотен долларов в месяц. Специалисты могут подобрать клиенту наиболее выгодный сервис и тарифный план.

Big Data — «топливо» XXI века

Если откинем все данные, развитие человечества будет примерно на уровне XVIII века. Мы все так же печем хлеб, пользуемся транспортом, лечим людей, как и наши предки. Использование Big Data позволяет продавать еще больше хлеба, оптимизировать поездки и ускорять научные и другие открытия.

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось17
До обраногоВ обраному9
LinkedIn



36 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Привет! Подскажите, имеет ли смысл «счичнуться» с QA на Data Engineer? Я так понимаю, если идти дальше по тех. пути, то QA упирается в SDET. А как дела обстоят с Data Engineer? Мысль в голову не сама пришла, у товарища в Канаде своя компания и он предложил в свободное время практиковаться с его Data Engineer’ом несколько месяцев, после того, как я освою основы SQL и Airflow. И сейчас вот думаю, начать учиться в этом направлении, или всё же подтягивать автоматизацию, т.к. уже несколько лет Manual QA опыта есть. Но опять же не хочется упускать такую возможность оплачиваемой практики с последующим переходом на full time, который будет оплачиваться х2 от моей текущей зарплаты.

Software Engineer
базово знаком с разработкой качественного ПО

Навіть, не знаю як на це реагувати.

Навіть, не знаю як на це реагувати.

позитивно, само собой. Знает и понимает свои слабые еще места.

Немножко текст по-дебильному написан ©

да ладно вам к мелочам уж придираться

Звучит, лично для меня, как самое скучное, что может быть в айти для девелопера

З власного досвіду — нічим не гірше, ніж написання CRUD чи формошльопство. Є приємні бонуси — не треба перетинатися з JS, та й рідко з Java. Зазвичай це Python, Scala, SQL. Є багато можливостей більш тісно попрацювати з клаудом, в тому числі як DevOps.

Сильно не вчитывался, зацепило

Database Administrator. На его плечах — построение архитектуры хранилищ. Знает, как оптимальнее хранить данные и проводить над ними базовые операции.

Да ну, когда это DBA занимался архитектурой хранилищ ? Куда делись OLTP .....

Пропущены целые направления
— Database Developer
— BI
— DWH

OLTP никуда не делся — тот же PostgreSQL будет работать как OLAP и OLTP
BI сейчас сводится к правильной валидации метрик — больше про отрисовки графиков где-то в Tableu нежели про корректность и актуальность их содержимого...
DWH полностью делегируется облачным провайдерам, потому это больше в DevOps.

Надо понимать что большая часть продуктов и компаний не имеет не то что DBA, а даже нормализированной схемы БД... а современные БД типа PostgreSQL 13 страдают острым недостатком фич, да и использовать то что есть по просту некому — дальше DDL’я сгенерированного каким-то посредственным ORM’ом никто не лезет. Потому вопрос утилизации SQL баз стоит колом, а зачем нужны конкретные NoSQL базы — мало кто понимает... в итоге получается «а у нас MongoDB, PostgreSQL, MySQL... а почему ? ... а потому что не умеем ни одной из них». Наболевшее в общем...

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

Пичалька то какая...

OLTP никуда не делся — тот же PostgreSQL будет работать как OLAP и OLTP

Мой вопрос о проектировании олтп был а не выборе субд. Пои чем тут постгресс ? Будет работать
? Да тебя за такое обоснование и близко не подпустят к проекту.

Надо понимать что большая часть продуктов и компаний не имеет не то что DBA, а даже нормализированной схемы БД... а современные БД

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

DBA может заниматься архитектурой

Может и должн (входит в обязанности)
Две большие разницы. Я тоже много чего могу, но должен ли?

Примерно в таком же стиле и написана статья, мало информации, а та что подана — скудна и неточна.
Есть куда рости.

Да тебя за такое обоснование и близко не подпустят к проекту.

Можно не быть недалёким человеком и не переходить на личности ?
Не Вам судить к каким конкретно проектам меня «допускают».

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

Я много чего видел... и FDW в Scylla на постгрессе, где он выступал моделью чтения для CQRS, а ES был реализован отдельным плагином на C... и кастомные агрегаты с GPGPU... и Custom Storage на SPDK... если я видел много посредственных поделок в энтерпрайсе — отнюдь не повод делать вывод что я «не видел больше ничего вообще». Да и сам сейчас занимаюсь проектированием движкa СУБД на ПЛИСках...

Просто цирк «а зачем нормализировать схему до 4-5ой нормальной формы ?» имеет место быть почти везде.

Весело когда 40ка летние дядьки «не тянут» программу второго курса универа...

Я тоже много чего могу, но должен ли?

Ну значит конкретно у вас такая зона комфорта — «зачем напрягаться если больше не заплатят».
И это Ваш личный выбор.

Fail fast, Fail often, with shitload of hype, vague market fit, pointless self-confidence and clusterfucks each week, doesn’t satisfy any Long Term Market Viability Demand

Можно не быть недалёким человеком и не переходить на личности ?
Не Вам судить к каким конкретно проектам меня «допускают».

Что за детские обиды? Как обосновал так и получил.

Просто цирк «а зачем нормализировать схему до 4-5ой нормальной формы ?»

Действительно зачем?!

Весело когда 40ка летние дядьки «не тянут» программу второго курса универа...

Это к чему приплел? Ты тоже будешь сорокалетним, или не планируешь? А вдруг не будешь тянуть? Жизнь она такая, можно и свичнутся и деградировать.
Я 40 прошел, и может не тяну программу второго курса, а может и тяну — честно я не задумывался.
Скажи, по твоему примеру, должен ?

Ну значит конкретно у вас такая зона комфорта — «зачем напрягаться если больше не заплатят».
И это Ваш личный выбор.

Конкретно ты ничего не понял. Наверное не ту программу учил.
Деньги — это твоя мотивация работать, плохая мотивация

можно и свичнутся и деградировать.

Ну так деградируйте и дальше, просто не надо это в комментах выпячивать.

Я не могу опускается до твоего уровня, был бы рад увидеть диалог на уровне.
Любой прочитавший комменты сделает свое суждение, вы свое сделали и оно достойно именно вас.
Удачи

Просто цирк «а зачем нормализировать схему до 4-5ой нормальной формы ?» имеет место быть почти везде.

То есть по твоему мнению, всегда и везде нужно нормализовать схему до 4-5ой нормальной формы ? Такого даже в рассвет нормализации не было принято — консенсус тогда был, что 3й обычно достаточно. А особым мастерством была выборочная денормализация.

Да, но так учили в универах когда ещё понятия не имели про 5ую и 6ую нормальные формы.
Никто представить не мог что будут Тбайтовые таблички и что их ещё надо как-то индексировать и подчищать страницы после удаления...

«Выборочная денормализация» была во времена «пятого мускуля» когда либо её делали топорно, без ограничений для индексов (partial index) и без эмуляции мат представлений на триггерах... потом это всё кушало по 64Гб оперативки, и никто ничего с этим не мог поделать, и это было принято за норму — на запросы по 3-5 секунд люди почти что молились (так продолжают работать некоторые украинские сервисы, типа Prozorro, только ещё 20-30% транзакций умудряются терять).

Тут надо понимать что у нас ещё есть Tablespace’ы и весы для планировщика... и можно денормализованное прям в jsonb хранить на SSD/Provisioned IO, нормализованное на винтах, а архивное — на ленте или холодных б/у HDD... там ещё всплывают колоночные упаковщики в deflate (zson) и пр. если действительно хотите в «правильную денормализацию».

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

Базы данных важны. Важнее зачастую кода. Но это не значит они должны быть переусложненны до того, когда это реально нужно.

с нормальным мессаджингом между ними

Ну любая ES прослойка вливается в риск IO Amplification’a и сложности реализации CD с конкретным lifecycle’ом соответствующих сервисов, и их зависимостей — иначе не было там вот этих вот всяких Spinnaker, ArgoCD, Flux, Airflow... и тучи k8s операторов «как с версии 1 перегнать сообщения в версию 2 и что делать с конфликтами».

Потому «шило на мыло»: упростили БД — усложнили операционку, проигнорировали риски...

Но это не значит они должны быть переусложненны

«Переусложнены» и «использовать тут функционал который уже в них есть, для тех задач для которых он был предусмотрен» — разные вещи. Люди и 10% фич того же постгреса не знают и городят на всяких J2EE непойми что.

Потому «шило на мыло»: упростили БД — усложнили операционку, проигнорировали риски...

Ну как-бы базы похуже скейлятся. Так что может и усложнили, но риски этим уменьшили.

Ну как-бы базы похуже скейлятся

Есть для этого уже операторов...

Тут надо понимать на сколько вам важна консистентность и какая (strong/eventual и т.п.) если в БД не предусмотрено — лучше действительно делигировать в отдельный стэк типа cloudstate в стриммингах типа Cloudflow или knative eventing.

Просто если даже и есть там какая-то FSM модель работы взаимосвязных сервисов (для примера можно рассмотреть тот же AWS StepFunctions) — управление консистентностью (CRDT+Vector clocks или в raft) никто не отменял...

То что очередь сообщений и ES внедрили — не гарантирует консистентность и отсутствие побочки.

В современных СУБД обычно просто strong eventual consistency с two-stage commits просто из-за требований ACID’а... и то куча побочки в зависимости от уровня изоляции транзакций всплывает (фантомное чтение и еже с ним). В распределённых системах, с кучей зависимых сервисов, консистентностью обычно просто жертвуют под соответствующими притворными предлогами... until shit hits the fan...

Есть для этого уже операторов...

операторов / не операторов — они в принципе плохо скейлятся если ACID.

То что очередь сообщений и ES внедрили — не гарантирует консистентность и отсутствие побочки.

Что такое ES ? Если нормально очередь сообщений внедрили (консистентная публикация — через те же strongly consistent исходящие таблицы в реляционной базе), и дедупликацию на принимающей стороне от at least once сделали — откуда и какие побочки вылезут?

В современных СУБД обычно просто strong eventual consistency с two-stage commits просто из-за требований ACID’а...

Я так понимаю, мы про реляционные ACID СУБД тут говорим? Что-то не представляю как это в таком контексте «strong eventual consistency с two-stage commits» может быть ? ACID вроде как strong immediate consistency гарантирует (при правильном уровне изоляции транзакции). two-stage commits — это тот который распределенные транзакции обещал? Жутко медленный и гарантированно не работающий?

В распределённых системах, с кучей зависимых сервисов, консистентностью обычно просто жертвуют под соответствующими притворными предлогами... until shit hits the fan...

Какой консистентностью кто жертвует? Или ты предлагаешь сложные системы полностью сильно-консистентно строить?

ACID СУБД тут говорим?

Вообще любые...

strong immediate consistency гарантирует

Если это не распределённая система...

two-stage commits — это тот который распределенные транзакции обещал?

Ну пока мастер-мастер на нём и работает...

Жутко медленный и гарантированно не работающий?

Зависит от конкретной реализации — в зависимости от требований к сходимости он может быть не таким уж и медленным.

Какой консистентностью кто жертвует?

Когда просто её игнорируют и вообще никак не контролируют состояние при конкурентном доступе — просто пишут в БД под предлогом «будь что будет».

Или ты предлагаешь сложные системы полностью сильно-консистентно строить?

Нет конечно, хотя бы в CRDT научится вручную где надо... так уже и в Akka давно оно так работает и в CloudState.

Да да — без перехода на личности — цитата

Три года я программирую на Python, из них два года погружен в Big Data.

— Вы считаете, что пусть даже три года в теме — достаточный уровень экспертизы?

Тут есть большая проблема, которую Вы, как молодой специалист, не замечаете (слава Богу если не стыкались с подобным) — Тим лиду или менеджеру «навязали» ТИ по теме. НаТИ он, в силу своей психологии, не может показать свое незнание темы — потому рыскает по интернету, находит Вашу статью и, прочитав ее, считает что он уже эксперт. А к нему на ТИ приходит реальный специалист и он его бортирует, потому что у Вас написано по другому... Конечно, я немного гипербализирую, но ... по меньше категоричности. Статья действительно поверхностная и «начального уровня». Современных подходов описано минимум... Хотя с другой стороны — а что тут напишешь? Реально хватило бы одного аргумента — которого у Вас как раз нету — это было выведено на одной из Конференций Data Science UA — если в команде есть дата аналитики и дата-сайнтисты, то лидом команды должен быть по любому дата-инжинер... Без вариантов. Иначе будет что-то корявое типа маршрутизации Убера... :)

что пусть даже три года в теме — достаточный уровень экспертизы?

Не считаю, нужно хотя бы 4-5... и желательно 3-4 языка помимо питона, с соответствующим инструментарием, библиотеками и фреймворками. Я не автор статьи, и не говорю что она не поверхностная... речь о том что очень много компаний на рынке и до такого уровня не дотягивает.

то лидом команды должен быть по любому дата-инжинер

Я не понимаю зачем плодить тайтлы, потом выяснять кто что должен делать — либо люди берут ответственность, либо не могут в PgRouting и A*, Флойд-Уоршелл и TRSP, как в случае с тем же убером...

Просто Big Data — на что акцентирует статья — не основной и не обязательный елемент работы дата-инжинера.

Но вот про основной елемент, без которого нет дата-инженера, в статье ни слова.
Data Mining. Нет Data Mining, нет Data Engineer. Без вариантов.

Это тоже самое, если б рассказывая о современном DevOps, Вы исходили исключительно из практики работы с github/gitlab, ничего не упоминув про Docker/K8/OpenShift, Jenkins/Puppets/Bamboo/TeamCity и так далее...

Да, Вы написали про ETL/ELT... но Вы с таким же упехом могли бы написать про кубы и аналитические запросы в БД — все это подходы десяти-двадцати летней давности...

Вот Вы описали что есть еще Data Science, но не показали — а при чем тут Data Engineer?
А ведь именно формализация профессии Data Science как математика, который занимается ML, и обусловила появление Data Engineer как тех, кто для первых поднимает, программирует и настраивает экосистему... И да, как один из тысячи разработчиков TensorFlow, я крайне огорчен отсутствием упоминания про него — с котрым работает 90 процентов Data Science и две трети Data Engineer...

Вы концентрируетесь в реятивных БД, но как раз на нормальных проектах с ними Data Engineer и не работает — потому что есть Oracle DB Engineer, Postgres DB Engineer или кто-то еще с узкой профилезацией по конкретной БД...

Тема же Data Engineer:
— выбор между OLTP/OLAP/Parquet или что там еще и реализация выбора
— выбор между батч/батч-стрим/стрим процессингом и его реализация
— выбор между Hadoop/Spark/Kafka/Storm/Solace/Akka Framework и так далее...

Что же касается языков программирования... то python про который Вы пишете — любимый язык Data Science и отнють не Data Engineer — я помню какую революцию мы поднимали на TensorFlowForSpark (тогда он так назывался) убеждая коммюнити про переход с python на scala... (В итоге сейчас четыре разные версии имеются на разных языках!) И вот именно scala — самый популярный язык среди Data Engineer ...хотя, конечно, есть язык R, который изначально разрабатывался для Data Mining, есть просто безкрышный Clojure,на котором написан Apache Storm и много другого интересного... Да, конечно, и java, и python тоже используются — но только там, где это будет более еффективно...

И это я так, очень поверхносно...
Тема Data Engineering крайне интересна и крайне перспективна и НЕХОРОШО такими вот бездарными статьями отбивать у людей охоту этим заниматься... :)

А так — просто совет. Есть в Киеве такая хорошая коммюнити Data Science UA --- закончится пандемия --- советую поучаствовать в очередных конференциях — там собираются лучшие и Data Science и Data Engineer --- возможно расширите свои горизонты...

Я в курсе про Data Science UA... мне, лично, ловить там особо нечего...

овременные БД типа PostgreSQL 13 страдают острым недостатком фич

Каких фич остро не хватает в постгресе?

Надо понимать что большая часть продуктов и компаний не имеет не то что DBA, а даже нормализированной схемы БД...

Да, это действительно так — в чем тут проблема? Базы в общем случае стали commodity, DBA нужны меньше, а польза от нормализации сильно упала с падением стоимости хранения и отходом от интеграции через базы лет 20 назад по индустрии. И это хорошо.

остро не хватает в постгресе?

• online/incremental materialized views, пока есть только патч на incremental
• кроме ZHeap не хватает хранилищ на LSM-tree с Commitlog’ом для хранения денормализированных представлений (пока обходимся FDW в Scylla)
• было бы очень хорошо так же иметь какой-то официальный SPDK-enabled storе
• банально не хватает нормального дашборда (типа pgDash) и встроенного профилятора — что бы не нужно было лезть в pg_flame / plprofiler / sr_plan и прочее, когда неправильно срабатывает встроенный планировщик (на кривых схемах — часто)

в чем тут проблема?

Стоимость долгосрочной эксплутации и поддержки таких БД слишком дорога и может стать причиной большего количества проблем при росте продукта...

«Пользу нормализации» можно даже на MongoDB, когда официальной рекомендацией при снижении производительности является нормализация схемы. В Киеве хватает продуктовых компаний, которые терпят серьёзные убытки из-за невозможности нормализации в собственных проектах, так как монга воспринималась как schemaless и никто даже миграций не писал...

Да-да... монга реляционная NoSQL БД, хватает компаний и разработчиков принявших этот факт, но где-то 80% остаются в «неведении» так как «больно признать» :)

Если речь идёт о паре сотен Гб — вопросов нет... можно как угодно запустить и лечить то что болит, но когда гоняется уже пару Тб — там надо думать про размеры индексов/таблиц, страницы, freespacemap ... самые безобидные правки могут как срезать 20-30Гб, так и добавить.

DBA нужны меньше, а польза от нормализации сильно упала

Ждать по 5-7 сек запроса к 8-10Тб базе это не хорошо — такие решения сложно называть жизнеспособными. А держать какое-то DynamoDB и платить по 40-50$ за транзакцию на запись «потому что DBA не нужны» и «вообще всё в облаках» — довольно наивно.

online/incremental materialized views, пока есть только патч на incremental
• кроме ZHeap не хватает хранилищ на LSM-tree с Commitlog’ом для хранения денормализированных представлений (пока обходимся FDW в Scylla)
• было бы очень хорошо так же иметь какой-то официальный SPDK-enabled storе
• банально не хватает нормального дашборда (типа pgDash) и встроенного профилятора — что бы не нужно было лезть в pg_flame / plprofiler / sr_plan и прочее, когда неправильно срабатывает встроенный планировщик (на кривых схемах — часто)

Понял. Ну да, с точки администрирования Оракулы всякие и Мускулы для DBA поприятнее будет. Но там и цены на лицензии становятся астрономическими при серьезном росте. С точки зрения разработки, большинство этих проблем сносно решается на уровня приложения, IMHO. Ничего критического.

Стоимость долгосрочной эксплутации и поддержки таких БД слишком дорога и может стать причиной большего количества проблем при росте продукта...

по секрету скажу — при серьезном росте нужно будет что-то менять по любому. Мне вот пять лет назад пришлось срочно мигрировать базу с Оракла на постгрес из-за роста ;)

Ждать по 5-7 сек запроса к 8-10Тб базе это не хорошо — такие решения сложно называть жизнеспособными. А держать какое-то DynamoDB и платить по 40-50$ за транзакцию на запись «потому что DBA не нужны» и «вообще всё в облаках» — довольно наивно.

Ну еще вопрос, что дешевле — наивно платить в облака, или толковому DBA запрлату. Терабайтные таблички это никак не типичный случай, и вполне вероятно — архитектурная проблема скорее, чем базы.

Мускулы для DBA поприятнее будет

Ну часто всплывал вопрос «может ли DBA полезть в сишку и написать EXTENTION что бы потом в CREATE AGGREGATE можно было»... в мускуле плагины не настолько гибкие, а у Oracle работает только то что предусмотрено функционалом СУБД. Потому решает чаще гибкость и безопасностью чем непосредственно удобство.

архитектурная проблема скорее, чем базы.

Ну эт проекты от 10М пользователей — просто «пользовательские данные» отпартицированы, логи/история всякого отбрасывается в колоночные т.к. растут безразмерно ...

Ну часто всплывал вопрос «может ли DBA полезть в сишку и написать EXTENTION что бы потом в CREATE AGGREGATE можно было»... в мускуле плагины не настолько гибкие, а у Oracle работает только то что предусмотрено функционалом СУБД. Потому решает чаще гибкость и безопасностью чем непосредственно удобство.

Я что-то запутался. Где правда? Что пользовать?

Просто используйте существующий функционал БД что бы предотвратить падение производительности при росте проекта и количества данных.

Не всегда БД — это лучшее место для решения вопросов производительности.

Ну лечат то что болит... а лучшее не лучшее место — вопрос наличия выхолопа профилятора, флеймграфов и трейсов.

А зараз як (чи як буде в майбутньому)?

Підписатись на коментарі