Forwarded from Maksim
Data Engineering / reposts & drafts
Игорь спасибо! Я бы с вами тоже выпил! Хорошо отдохнуть!
Дмитрий, можешь сбросить в канал интересный проект - бенчмарк по оценке, когда llm смогут нашу Data работу делать. Пока можно не сильно беспокоиться, но видимо не долго 😂
https://spider2-v.github.io/
https://spider2-v.github.io/
Forwarded from Maksim
Data Engineering / reposts & drafts
Шляпа какая то
Нет, не шляпа. Потом опубликуешь, когда начнут в линкединах про это писать или когда gpt5 выйдет.
Forwarded from Сиолошная
Spider2-V: How Far Are Multimodal Agents From Automating Data Science and Engineering Workflows?
Хорошие бенчмарки для ИИ-агентов — это нам надо обязательно (особенно в преддверии GPT-5 / Gemini-2). Есть отдельное направление бенчмарков, которые симулируют работу с привычными нам инструментами — с сайтами или приложениями, которыми специалисты пользуются в работе каждый день (WorkArena, WebArena, OSWorld).
В данной работе, созданной в коллаборации нескольких компаний и учебных заведений (преимущественно, китайских), создается бенчмарк для оценки ИИ-агентов в дата-инженерии и дата-саенс (джуны-вкатыватели напряглись). Покрыт полный цикл, разделённый на 5 компонент (в скобках — поддерживаемые инструменты):
— Data Warehousing (Snowflake, BigQuery)
— Data Ingestion (Airbyte, никогда не пользовался)
— Data Transformation (dbt)
— Data Visualization (Superset, Metabase)
— Data Orchestration (Airflow, Dagster)
(а ещё есть эксели, куда без них,😥 )
В общем, если вы касались дата-инженерии, то понимаете, что набор увесистый, и хоть и не покрывает всего зоопарка решений, которые встречаются на местах. Но самое интересное тут — принцип сбора данных. Суммарно 10 разметчиков подготовили 494 задачи, в среднем на одну уходило 4 часа. В самом начале процесса они искали и изучали учебные курсы/туториалы (больше 200 ссылок для доп. информации).
Из этих туториалов создавались задачи, но требовалось, чтобы как минимум 2 ключевых аспекта задачи были изменены. На практике это означает, что скорее всего используются те же инструменты, что и в туториале, но с немного другой целью / условиями и ограничениями по данным — всё это помогает предотвратить переобученность LLM под задачи. Например, в задаче оркестрации скриптов один проект для запуска меняется на другой, а также добавляется условие запуска ежедневно в 10 утра (в оригинальном уроке этого условия вообще не было).
Также каждая задача сопровождается некоторым количеством вспомогательного кода, который позволяет развернуть среду и запустить нужные приложения, то есть как бы имитировать рабочее пространство в момент времени начала решения. После окончания работы над задачей она независимо проверяется ещё двумя разметчиками, что они могут сами взять и повторить решение, и что всё работает. Так что потолок метрики доли решенных задач тут 100%.
В среднем, каждая задача требует обращения к 2.5 разным приложениям (включая терминал и IDE для написания кода). Все таски разделены на простые (не более 5 шагов для решения, где шаг — это нажатие на кнопку или этап написания кода) - 20%, средние (6-16 шагов) - 63%, и 17% сложных задач с более чем 15 шагами.
Хорошие бенчмарки для ИИ-агентов — это нам надо обязательно (особенно в преддверии GPT-5 / Gemini-2). Есть отдельное направление бенчмарков, которые симулируют работу с привычными нам инструментами — с сайтами или приложениями, которыми специалисты пользуются в работе каждый день (WorkArena, WebArena, OSWorld).
В данной работе, созданной в коллаборации нескольких компаний и учебных заведений (преимущественно, китайских), создается бенчмарк для оценки ИИ-агентов в дата-инженерии и дата-саенс (джуны-вкатыватели напряглись). Покрыт полный цикл, разделённый на 5 компонент (в скобках — поддерживаемые инструменты):
— Data Warehousing (Snowflake, BigQuery)
— Data Ingestion (Airbyte, никогда не пользовался)
— Data Transformation (dbt)
— Data Visualization (Superset, Metabase)
— Data Orchestration (Airflow, Dagster)
(а ещё есть эксели, куда без них,
В общем, если вы касались дата-инженерии, то понимаете, что набор увесистый, и хоть и не покрывает всего зоопарка решений, которые встречаются на местах. Но самое интересное тут — принцип сбора данных. Суммарно 10 разметчиков подготовили 494 задачи, в среднем на одну уходило 4 часа. В самом начале процесса они искали и изучали учебные курсы/туториалы (больше 200 ссылок для доп. информации).
Из этих туториалов создавались задачи, но требовалось, чтобы как минимум 2 ключевых аспекта задачи были изменены. На практике это означает, что скорее всего используются те же инструменты, что и в туториале, но с немного другой целью / условиями и ограничениями по данным — всё это помогает предотвратить переобученность LLM под задачи. Например, в задаче оркестрации скриптов один проект для запуска меняется на другой, а также добавляется условие запуска ежедневно в 10 утра (в оригинальном уроке этого условия вообще не было).
Также каждая задача сопровождается некоторым количеством вспомогательного кода, который позволяет развернуть среду и запустить нужные приложения, то есть как бы имитировать рабочее пространство в момент времени начала решения. После окончания работы над задачей она независимо проверяется ещё двумя разметчиками, что они могут сами взять и повторить решение, и что всё работает. Так что потолок метрики доли решенных задач тут 100%.
В среднем, каждая задача требует обращения к 2.5 разным приложениям (включая терминал и IDE для написания кода). Все таски разделены на простые (не более 5 шагов для решения, где шаг — это нажатие на кнопку или этап написания кода) - 20%, средние (6-16 шагов) - 63%, и 17% сложных задач с более чем 15 шагами.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Сиолошная
Примеры пары простых задачек:
1. Закинуть данные из папки в Google Drive в таблицу в BigQuery
2. Выгрузить топ-20 драматических фильмов из IMDB-таблички в Snowflake в csv доп. требованиями
Обе задачи решаются только кликами в UI и написанием простого кода запросов (тоже в браузере).
Больше примеров можно посмотреть вот тут — там прямо целые видео того, как GPT-4o справляется с задачами (больше 30 примеров)
1. Закинуть данные из папки в Google Drive в таблицу в BigQuery
2. Выгрузить топ-20 драматических фильмов из IMDB-таблички в Snowflake в csv доп. требованиями
Обе задачи решаются только кликами в UI и написанием простого кода запросов (тоже в браузере).
Больше примеров можно посмотреть вот тут — там прямо целые видео того, как GPT-4o справляется с задачами (больше 30 примеров)
Forwarded from Сиолошная
Выводы и результаты такие:
— для открытых LLM использовалось текстовое описание происходящего на экране, без картинок. Потому качество сильно хуже и его даже рассматривать не будем
— для фронтир VLM (GPT-4o, Claude-3) подаются картинки с экрана, а также ещё пара трюков: дополнительная информация в контекст (RAG над документацией) + Set-of-Mark (когда кнопки/текст на экране распознают и выделяют на картинке для модели)
— глобально решается 14% задач, что очень мало, но тут можно сделать много срезов
— например, простых задач решается уже 40% (сложных — 1.2%)
— также решается 20% задач, требующих только работу с графическим интерфейсом, без консоли или IDE
— (см. картинку) GPT-4V решает 25% задач на визуализацию, GPT-4o 24% на Data Ingestion
— GPT сильно превосходит модели Google и Anthropic
Так что пока живём, джунов не заменит. Но очень хочется, чтобы при релизе GPT-5 и Claude-3.5-Opus прям сразу рассказали про метрики на этом и схожих бенчмарках — чтобы понимать, какую долю работу мы скоро потеряем...
— для открытых LLM использовалось текстовое описание происходящего на экране, без картинок. Потому качество сильно хуже и его даже рассматривать не будем
— для фронтир VLM (GPT-4o, Claude-3) подаются картинки с экрана, а также ещё пара трюков: дополнительная информация в контекст (RAG над документацией) + Set-of-Mark (когда кнопки/текст на экране распознают и выделяют на картинке для модели)
— глобально решается 14% задач, что очень мало, но тут можно сделать много срезов
— например, простых задач решается уже 40% (сложных — 1.2%)
— также решается 20% задач, требующих только работу с графическим интерфейсом, без консоли или IDE
— (см. картинку) GPT-4V решает 25% задач на визуализацию, GPT-4o 24% на Data Ingestion
— GPT сильно превосходит модели Google и Anthropic
Так что пока живём, джунов не заменит. Но очень хочется, чтобы при релизе GPT-5 и Claude-3.5-Opus прям сразу рассказали про метрики на этом и схожих бенчмарках — чтобы понимать, какую долю работу мы скоро потеряем...
Forwarded from Сиолошная
Сиолошная
Выводы и результаты такие: — для открытых LLM использовалось текстовое описание происходящего на экране, без картинок. Потому качество сильно хуже и его даже рассматривать не будем — для фронтир VLM (GPT-4o, Claude-3) подаются картинки с экрана, а также ещё…
Понятно ли вам примерно, как именно «простая LLM которая генерирует следующее слово» решает эти задачи?
Anonymous Poll
15%
Да, прекрасно понимаю функционал агента
49%
Нууу очень примерно, плюс минус
37%
Нет, вообще не понимаю, модель же просто текст генерирует?
Forwarded from DE
Оказывается есть стандарт OpenFeature с которым фича-флаги выглядят ещё более удобными и привлекательными при разработке.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DE
DE
Feature flags (или флаги функций) важный инструмент в современном программировании. Они позволяют тебе включать и выключать определённые функции в коде без необходимости вносить изменения в основной код базы. Это особенно полезно при разработке и тестировании новых функций.
✔️ Преимущества использования feature flags
1️⃣ Контроль над функциями:
Можно безопасно тестировать новые функции на ограниченной группе пользователей.
2️⃣ Ускорение разработки:
Новые функции могут быть внедрены быстрее, так как их можно включать или выключать без релиза новой версии приложения.
3️⃣ Уменьшение риска:
Если новая функция вызывает проблемы, её можно быстро отключить, минимизируя влияние на пользователей.
4️⃣ Персонализация:
Различные пользователи могут видеть разные наборы функций в зависимости от своих предпочтений, групп или политик безопасности.
✅ Влияние feature flags на кодовые базы
1️⃣ Усложнение кода:
При неправильном использовании количество условий в коде (многообразие if-elif, которые ты так любишь🙃 ) может увеличиться, что сделает его сложнее для чтения и сопровождения.
2️⃣ Тестирование:
Необходимо тестировать каждую комбинацию включённых и выключенных флагов, что может увеличить объём работы тестировщиков.
3️⃣ Технический долг:
Если feature flags не удаляются после стабилизации функции, они могут накопить технический долг, усложняя кодовую базу.
📎 Заключение
Feature flags являются мощным инструментом при правильном использовании, помогая управлять развитием продукта и уменьшать риски. Однако важно следить за их количеством и своевременно удалять неиспользуемые флаги, чтобы поддерживать кодовую базу в чистоте.
#dev #featureflags #if
Можно безопасно тестировать новые функции на ограниченной группе пользователей.
Новые функции могут быть внедрены быстрее, так как их можно включать или выключать без релиза новой версии приложения.
Если новая функция вызывает проблемы, её можно быстро отключить, минимизируя влияние на пользователей.
Различные пользователи могут видеть разные наборы функций в зависимости от своих предпочтений, групп или политик безопасности.
При неправильном использовании количество условий в коде (многообразие if-elif, которые ты так любишь
Необходимо тестировать каждую комбинацию включённых и выключенных флагов, что может увеличить объём работы тестировщиков.
Если feature flags не удаляются после стабилизации функции, они могут накопить технический долг, усложняя кодовую базу.
Feature flags являются мощным инструментом при правильном использовании, помогая управлять развитием продукта и уменьшать риски. Однако важно следить за их количеством и своевременно удалять неиспользуемые флаги, чтобы поддерживать кодовую базу в чистоте.
#dev #featureflags #if
Please open Telegram to view this post
VIEW IN TELEGRAM
https://www.datanami.com/2024/07/08/dont-believe-the-big-database-hype-stonebraker-warns/
YandexGPT
краткий пересказ статьи от нейросети
Не верьте шумихе вокруг базы данных, предупреждает Стоунбрейкер
Кратко
Подробно
◦ Обзор состояния баз данных
◦ • Реляционные базы данных (RM) доминируют, но их будущее под вопросом.
◦ • Новые технологии, такие как NoSQL, не смогли заменить RM.
◦ • Некоторые технологии, такие как Hadoop и MapReduce, устарели.
•
◦ Тенденции в базах данных
◦ • Хранилища ключей и значений и хранилища документов эволюционировали, но не вытеснили RM.
◦ • Столбчатые базы данных и векторные базы данных имеют ограниченное будущее.
◦ • Базы данных Graph и облачные базы данных стали популярными.
•
◦ Архитектура баз данных
◦ • Хранилища данных в столбцах и облачные базы данных доминируют на рынке.
◦ • Хранилища данных / Lakehouses предлагают гибкость для обработки данных не-SQL.
◦ • Системы NewSQL не получили широкого распространения.
◦ • Аппаратные ускорители баз данных не оправдали затрат.
•
◦ Базы данных блокчейна
◦ • Базы данных блокчейна не нашли широкого применения за пределами Даркнета.
•
◦ Будущее разработки баз данных
◦ • Сообщество баз данных должно стремиться к стандартизации и открытому исходному коду.
◦ • Необходимо извлекать уроки из истории и стремиться к постоянному развитию.
•
◦ Сопутствующие товары и поставщики
◦ • Статья содержит ссылки на дополнительные материалы и продукты от различных поставщиков.
•
◦ Теги
◦ • В статье используются различные теги для описания различных аспектов баз данных.
•
YandexGPT
краткий пересказ статьи от нейросети
Не верьте шумихе вокруг базы данных, предупреждает Стоунбрейкер
Кратко
Подробно
◦ Обзор состояния баз данных
◦ • Реляционные базы данных (RM) доминируют, но их будущее под вопросом.
◦ • Новые технологии, такие как NoSQL, не смогли заменить RM.
◦ • Некоторые технологии, такие как Hadoop и MapReduce, устарели.
•
◦ Тенденции в базах данных
◦ • Хранилища ключей и значений и хранилища документов эволюционировали, но не вытеснили RM.
◦ • Столбчатые базы данных и векторные базы данных имеют ограниченное будущее.
◦ • Базы данных Graph и облачные базы данных стали популярными.
•
◦ Архитектура баз данных
◦ • Хранилища данных в столбцах и облачные базы данных доминируют на рынке.
◦ • Хранилища данных / Lakehouses предлагают гибкость для обработки данных не-SQL.
◦ • Системы NewSQL не получили широкого распространения.
◦ • Аппаратные ускорители баз данных не оправдали затрат.
•
◦ Базы данных блокчейна
◦ • Базы данных блокчейна не нашли широкого применения за пределами Даркнета.
•
◦ Будущее разработки баз данных
◦ • Сообщество баз данных должно стремиться к стандартизации и открытому исходному коду.
◦ • Необходимо извлекать уроки из истории и стремиться к постоянному развитию.
•
◦ Сопутствующие товары и поставщики
◦ • Статья содержит ссылки на дополнительные материалы и продукты от различных поставщиков.
•
◦ Теги
◦ • В статье используются различные теги для описания различных аспектов баз данных.
•
Datanami
Don’t Believe the Big Database Hype, Stonebraker Warns
How we store and serve data are critical factors in what we can do with data, and today we want to do oh-so much. That big data necessity is the mother of
Forwarded from Alex. Seconds.
Media is too big
VIEW IN TELEGRAM
📈Weekly Data Stand-Up — 📆22.07.2024
Текущие задачи/планы:
• CrowdStrike наносит удар, но не по нам
• Snowflake UDTF все-таки заработала
• Grafana Alerts по метрикам (или их отсутствию) из Airflow
• нехватка open source коннекторов, но смотрим на Airbyte
• планы добавить линтеры и форматеры для SQL/dbt (SQLfluff) и HCL (tflint)
Предложения/вопросы из чата:
• передача метрик GitHub через OpenTelemetry
Спасибо всем, кто забежал поучаствовать ранним утром понедельника💙
P.S.: кстати, если кто-то хочет поучаствовать в таком формате #weeklydatastandup и рассказать о своих текущих задачах/сложностях/успехах, пишите мне и присоединяйтесь в роли спикера!
Текущие задачи/планы:
• CrowdStrike наносит удар, но не по нам
• Snowflake UDTF все-таки заработала
• Grafana Alerts по метрикам (или их отсутствию) из Airflow
• нехватка open source коннекторов, но смотрим на Airbyte
• планы добавить линтеры и форматеры для SQL/dbt (SQLfluff) и HCL (tflint)
Предложения/вопросы из чата:
• передача метрик GitHub через OpenTelemetry
Спасибо всем, кто забежал поучаствовать ранним утром понедельника💙
P.S.: кстати, если кто-то хочет поучаствовать в таком формате #weeklydatastandup и рассказать о своих текущих задачах/сложностях/успехах, пишите мне и присоединяйтесь в роли спикера!
Forwarded from Data1984
Forwarded from Руслан
Всем привет. Посоветуйте пожалуйста пару курсов или статей по проектированию хранилищ данных, построение правильных молей данных ( слои, интеграции, олап кубы)?
Forwarded from Andre
Руслан
Всем привет. Посоветуйте пожалуйста пару курсов или статей по проектированию хранилищ данных, построение правильных молей данных ( слои, интеграции, олап кубы)?
А что значит правильные модели?
Forwarded from Vadim
Руслан
Всем привет. Посоветуйте пожалуйста пару курсов или статей по проектированию хранилищ данных, построение правильных молей данных ( слои, интеграции, олап кубы)?
Литературы очень мало, причем, понятия различаются.
Попробуй начать с этого ресурса
https://dataengineering.wiki/Concepts/Concepts
Попробуй начать с этого ресурса
https://dataengineering.wiki/Concepts/Concepts
Data Engineering Wiki
Concepts - Data Engineering Wiki
Core Concepts How to build a data pipeline Data Modeling Batch vs Stream processing Indexing Relational vs Non-relational data OLTP vs OLAP Database ConceptsCAP Theorem Column-oriented Database Docum…
Forwarded from DataWorkshop - AI & ML
Кстати, в мире технологии постоявнно появляются новые инструменты и найтись во всем этом становится трудно.
Есть такая библиотека, которая называется Ibis (это не призыв к действиям, чем заняться 14 февраля, хотя случайностей не бывает 😂).
Ibis — это как универсальный "переводчик" для работы с данными в Python. Позволяет манипулировать огромными объемами данных, хранящимися где угодно, используя знакомый интерфейс в стиле pandas.
Самое крутое — код выполняется там, где хранятся данные, благодаря чему всё работает быстрее, не загружая Твой компьютер. Это как иметь один инструмент, который подходит для любой работы с данными, не нужно переучиваться или переписывать код при смене базы данных или увеличении объемов данных.
Поддерживает
- Apache Arrow DataFusion
- Apache Druid
- Apache Flink
- Apache Impala
- Apache PySpark
- BigQuery
- ClickHouse
- Dask
- DuckDB
- Exasol
- HeavyAI
- MySQL
- Oracle
- Pandas
- Polars
- PostgreSQL
- SQL Server
- SQLite
- Snowflake
- Trino
Хочешь узнать больше? Поставь сердечко ❤️
Есть такая библиотека, которая называется Ibis (это не призыв к действиям, чем заняться 14 февраля, хотя случайностей не бывает 😂).
Ibis — это как универсальный "переводчик" для работы с данными в Python. Позволяет манипулировать огромными объемами данных, хранящимися где угодно, используя знакомый интерфейс в стиле pandas.
Самое крутое — код выполняется там, где хранятся данные, благодаря чему всё работает быстрее, не загружая Твой компьютер. Это как иметь один инструмент, который подходит для любой работы с данными, не нужно переучиваться или переписывать код при смене базы данных или увеличении объемов данных.
Поддерживает
- Apache Arrow DataFusion
- Apache Druid
- Apache Flink
- Apache Impala
- Apache PySpark
- BigQuery
- ClickHouse
- Dask
- DuckDB
- Exasol
- HeavyAI
- MySQL
- Oracle
- Pandas
- Polars
- PostgreSQL
- SQL Server
- SQLite
- Snowflake
- Trino
Хочешь узнать больше? Поставь сердечко ❤️
Forwarded from Инжиниринг Данных (Dmitry)
Cheat sheet for data engineering ramp up in 2022.
🟢 SQL/data modeling
Install Postgres. Load dummy data with \copy
Understand ACID
Different consistency levels: Strict, Linearizable, Serializable, Eventual, Casual
Aggs with GROUP BY.
Joins: INNER, LEFT.
Filter records with WHERE. Filter groups with HAVING.
Aggs persisted to summary tables.
ORDER BY foo LIMIT n --> top n by foo.
Organize queries with CTEs and temp tables. Subselect sparingly
Window functions to look at trends within arbitrary partitions.
Unique constraints. Foreign key constraints.
Dimensions vs Fact tables. Star, snowflake schemas.
EXPLAIN <query>. Read the plan.
Add an index. How does the EXPLAIN change?
🟢 CompSci concepts you must know
Uniformly distributed hash functions.
Tuples vs Arrays.
Iterator design pattern.
External Merge sort.
Bit vectors, HashMap. Sets.
Directed graphs.
Serialization
🟢 Time representation
ISO 8601 strings
Prefer native date and timestamp objects.
UTC.
🟢 Fundamentals of distributed data processing
Cap theorem.
Replication.
Horizontal vs Vertical scaling.
Sharding vs clustering.
Share-nothing principle.
Partitioning data at-rest.
Planning for fault tolerance and failure.
Exponential back off retries.
Latency vs bandwidth.
How to code to iterators without the input fully buffered in memory.
🟢 Spark
Dataframe and Dataset batch API.
Shuffle challenges. When to repartition().
Runtime partitioning by key.
Tuning: executors num, memory, cores. Num shuffle partitions.
Dataframe ops split up into composable driver functions.
Construct fixture Dataframes for unit tests.
Create temporary views as staging tables.
Data quality checks over staging views. Lots of logging.
Fail driver if checks fail.
Block any downstream dependencies until the checks pass.
Hive metastore for data lake catalog.
🟢 Common structured data formats
TSV, Tar, Zip, XLSX, Avro, Parquet, Protobufs, Delta
Splittable file format?
Compression: Bz2. Gzip, Snappy, LZO.
Hadoop mergeUtils to help small files problem.
🟢 Cloud providers
Top players for distributed computing: AWS, GCP, Azure
S3/GCS object stores
Managed Airflow = pipelining
EMR/Dataproc = processing
Container registries. EKS/GKE for container execution
IAM access controls. As-needed access. No shared service creds.
🟢 Languages (1 - 10 goal proficiency)
SQL (10)
Python (8)
Java (7)
Scala (4)
Bash (4)
🟢 Metrics/monitoring/alerting
Statsd, Prometheus.
HTTP vs. UDP
Gauge vs increment vs histogram.
Measurement vs tag.
Visualize measurement time series: Grafana, Datadog.
Observe what normal is. Alert on abnormal thresholds.
Alert messaging clarity.
Runbooks for on-call.
🟢 Linux familiarity
tail -f
tmux
ps -ef, kill -9
vim
ssh, scp
cat, less, more, grep, find, echo, xargs, |, >, >>, <
sudo
.bash_profile, EXPORT, unset, $PATH
🟢 Containers
Linux cgroups.
Dockerfile. Docker Desktop.
docker-compose
Basic understanding of Kubernetes. Kubectl
Anything I leave out that's important?
🟢 SQL/data modeling
Install Postgres. Load dummy data with \copy
Understand ACID
Different consistency levels: Strict, Linearizable, Serializable, Eventual, Casual
Aggs with GROUP BY.
Joins: INNER, LEFT.
Filter records with WHERE. Filter groups with HAVING.
Aggs persisted to summary tables.
ORDER BY foo LIMIT n --> top n by foo.
Organize queries with CTEs and temp tables. Subselect sparingly
Window functions to look at trends within arbitrary partitions.
Unique constraints. Foreign key constraints.
Dimensions vs Fact tables. Star, snowflake schemas.
EXPLAIN <query>. Read the plan.
Add an index. How does the EXPLAIN change?
🟢 CompSci concepts you must know
Uniformly distributed hash functions.
Tuples vs Arrays.
Iterator design pattern.
External Merge sort.
Bit vectors, HashMap. Sets.
Directed graphs.
Serialization
🟢 Time representation
ISO 8601 strings
Prefer native date and timestamp objects.
UTC.
🟢 Fundamentals of distributed data processing
Cap theorem.
Replication.
Horizontal vs Vertical scaling.
Sharding vs clustering.
Share-nothing principle.
Partitioning data at-rest.
Planning for fault tolerance and failure.
Exponential back off retries.
Latency vs bandwidth.
How to code to iterators without the input fully buffered in memory.
🟢 Spark
Dataframe and Dataset batch API.
Shuffle challenges. When to repartition().
Runtime partitioning by key.
Tuning: executors num, memory, cores. Num shuffle partitions.
Dataframe ops split up into composable driver functions.
Construct fixture Dataframes for unit tests.
Create temporary views as staging tables.
Data quality checks over staging views. Lots of logging.
Fail driver if checks fail.
Block any downstream dependencies until the checks pass.
Hive metastore for data lake catalog.
🟢 Common structured data formats
TSV, Tar, Zip, XLSX, Avro, Parquet, Protobufs, Delta
Splittable file format?
Compression: Bz2. Gzip, Snappy, LZO.
Hadoop mergeUtils to help small files problem.
🟢 Cloud providers
Top players for distributed computing: AWS, GCP, Azure
S3/GCS object stores
Managed Airflow = pipelining
EMR/Dataproc = processing
Container registries. EKS/GKE for container execution
IAM access controls. As-needed access. No shared service creds.
🟢 Languages (1 - 10 goal proficiency)
SQL (10)
Python (8)
Java (7)
Scala (4)
Bash (4)
🟢 Metrics/monitoring/alerting
Statsd, Prometheus.
HTTP vs. UDP
Gauge vs increment vs histogram.
Measurement vs tag.
Visualize measurement time series: Grafana, Datadog.
Observe what normal is. Alert on abnormal thresholds.
Alert messaging clarity.
Runbooks for on-call.
🟢 Linux familiarity
tail -f
tmux
ps -ef, kill -9
vim
ssh, scp
cat, less, more, grep, find, echo, xargs, |, >, >>, <
sudo
.bash_profile, EXPORT, unset, $PATH
🟢 Containers
Linux cgroups.
Dockerfile. Docker Desktop.
docker-compose
Basic understanding of Kubernetes. Kubectl
Anything I leave out that's important?
Forwarded from commit -m "better"
CAP теорема от PG: интересный проект, хорошая команда, деньги - выбери два.