Инжиниринг Данных – Telegram
Инжиниринг Данных
23.5K subscribers
1.98K photos
56 videos
192 files
3.2K links
Делюсь новостями из мира аналитики и карьерными советами.

15 лет в Аналитике и Инжиниринге Данных, 10 лет в MAANG

🛠️ dataengineer.ru | 🏄‍♂️ Surfalytics.com

№5017813306

Реклама:
https://almond-rule-130.notion.site/1199f595f76a8030ba1be1e607c9a8ce
Download Telegram
Вы знакомы с термином ACID в теории биз данных? Он описывает требования к транзакционной системе (например, к СУБД), обеспечивающие наиболее надёжную и предсказуемую её работу. Требования ACID были в основном сформулированы в конце 70-х годов Джимом Греем.

Расшифровывается:
Atomicity — Атомарность
Атомарность гарантирует, что никакая транзакция не будет зафиксирована в системе частично. Будут либо выполнены все её подоперации, либо не выполнено ни одной. Поскольку на практике невозможно одновременно и атомарно выполнить всю последовательность операций внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех её до сих пор произведённых действий будут отменены и система вернётся во «внешне исходное» состояние — со стороны будет казаться, что транзакции и не было.

Consistency — Согласованность
Транзакция, достигающая своего нормального завершения (EOT — end of transaction, завершение транзакции) и, тем самым, фиксирующая свои результаты, сохраняет согласованность базы данных. Другими словами, каждая успешная транзакция по определению фиксирует только допустимые результаты. Это условие является необходимым для поддержки четвёртого свойства.

Isolation — Изолированность
Во время выполнения транзакции параллельные транзакции не должны оказывать влияния на её результат. Изолированность — требование дорогое, поэтому в реальных БД существуют режимы, не полностью изолирующие транзакцию (уровни изолированности Repeatable Read и ниже).

Durability — Долговечность
Независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу. Другими словами, если пользователь получил подтверждение от системы, что транзакция выполнена, он может быть уверен, что сделанные им изменения не будут отменены из-за какого-либо сбоя.

А статья на медиум с примерами для Oracle/Postgres.
Кстати, согласно новостям Oracle doing great, то есть вроде как мы его уже не жалуем для хранилищ данных, но это возможно всего лишь мой когнитивный баис, и компанию чувствует себя прекрасно.
Про NULL в базе данных
еще одна смешная история. Я все склонялся к тому, что статья не очень по теме канала, но мне её столько раз прислали уже, что, видимо, я все-таки ошибаюсь (никогда такого не было, и вот опять!). Короче, статья о том, как чувак в Калифорнии зарегистрировал себе автомобильный номер NULL, возможно, надеясь, что это уменьшит количество штрафов, которые он будет получать. (ну и номер прикольный, да). Но оказалось, что штрафы в Калифорнии для их местного ГАИ выписывает коммерческий подрядчик, у которого в системе все было гораздо проще: если номер не распознался или отсутствует, в базу записывается NULL. Поэтому чуваку пришли все такие штрафы, на 12 тыс долларов. Хорошо.
https://www.wired.com/story/null-license-plate-landed-one-hacker-ticket-hell/
Интересны блогпост от убера. Уже очевидно, что с облаком можно масштабировать вычислительные мощности и сторадж бесконечно, но теперь крупные потребители начинают задумываться о цене на владения облаком и придумывают способы оптимизации затрат. На помощь приходит ML/AI, которы помогает оптимизировать затраты.

И действительно, в алексе сейчас большой проект по снижение затрат на облачные вычисления и там цели сотни млн долларов. Даже я уже подумываю о том, чтобы сделать отчёт в табло про стоимость владения нашей инфраструктурой и отслеживания ресурсов типа ,Spectrum/Athena, где вы платите за то, что используете.
Приходилось ли вам делать дашборды для мобильного телефона? Вот статья у табло учит нас как лучше это сделать.

Я уже больше 10 лет работаю с BI, и всегда хотел построить дашборд, чтобы менеджеры меня по головке погладили и сказали, ну какой же я молодец, подумал о них и сделал превосходный отчёт для телефона, они же жить без метрик не могут.

Так я всегда скачивал мобильную версию SAP Business objects, MicroStrategy, Tableau, Power BI и ТП. Но ни разу так и не сделал ничего путного и полезного. Обычно все упиралось в вопрос, а как доступ давать? VPN или ещё как-то, а что скажет служба безопасности и ИТ? Или куча других важных вещей. Поэтому я не фанат этих мобильных прибамбасов для аналитики.
Оказывается Cloudera вместе с IBM предлагают свое решение для озера данных и их сравнивают с Amazon Elastic Map Reduce (Hadoop). Логично если вы в облаке, то удобней использовать решение от того провайдера, услугами которого вы пользуетесь. Меня одно радует во всей это BigData всё движется к упрощению процесса развертывания. Быстрее развернули решение, быстрее получили результат и не надо париться с настройкой хадупа. Хотя, джава программисты, которые не плохо на этом зарабатывают со мной не согласиться.
Оракл сократил 300 человек, направление, которое занималось создание on-premise решением. Когда-то Лари (босс Оракл) говорил,. Что все это фигня ваше облако. А теперь все ресурсы направлены на создание облачной инфраструктуры.
И напоследок опять про Snowflake, о том как он забирает бизнес у всех конкурентов и растет с дикой скоростью. У нас в Канаде пока все на шкафах как на картинке выше, но я создал уже митап по Snowflake User Group в Ванкувере. Пока 23 человека записалось. В Бостоне тут было 500!
Австралийцы создали новый BI инструмент и он доступен бесплатно как open source.
Попался вводный курс по инжинирингу данных, по описанию это просто ETL разработчик, что в принципе почти одно и тоже.
Нашел в интернете пост про DevOps для инжиниринга данных. Идея главная в том, чтобы не было подхода "%уяк №уяк и в продакшн", это несомненно быстро, но какова цена ошибки? Если у вас маленькое решение и мало пользователей, то ничего страшного, а если у вас много пользователей, система взаимодействует с другими системами, то вам просто нельзя рисковать!

До сих пор вспоминаю свой опыт подхода выше, когда я обновлял сервер SAP BO в Lamoda и в середине процесса кабель с интернетом случайно выдернул... В Амазоне так же с Табло было... Да что там, на своем первом месте работы в BNP Paribas, я вообще грохнул всю отчетность на несколько дней. За то есть свои плюсы, в экстремальных условия можно очень хорошо разобраться что, как и почему работает😎 На своих ошибках всегда лучше учиться, да еще за чужой счет...
Вот примерно так будет выглядеть решение на AWS. Конечно мы можем заменить любой элемент системы на Native AWS или наоборот использовать стороннее коммерчесекое решение или открытое ПО.
Работаете с маркетинговой аналитикой? Вот вам 7 уроков от модного вендора - Segment. Прям такой хайповый продукт, у многих он есть, особенно стартапы его любят.

Вообще вне зависимости от инструмента, можно просто посмотреть, что они делают с данным, какие бизнес кейсы, какие проблемы хотят решить, ну и потом на следующем собеседовании выдать за свое😉 #faketillyoumakeit