ТОП-20 лучших статей про данные 2023

Уважаемый ресурс Dataversity подвел итоги года и опубликовал ТОП-20 самых читаемых и востребованных статей, которые вызвали на их канале в течение года наибольший интерес. Пробежавшись по списку глазами, можно без труда понять к каким ключевым темам информационное сообщество обращалось снова и снова.

Смотреть список статей

Есть две вещи, которые чрезвычайно важны в изучении программирования:
- практика;
- способность искать информацию самостоятельно.

В случае с изучением SQL я рекомендую использовать ресурс https://sql-ex.ru

Задачи с сайта sql-ex и будут использованы в качестве практической части повествования. Использовать сайт можно даже с телефона, так что если вы можете читать этот текст, то вам для начала изучения не нужно больше ничего кроме желания.

#sql

Одним из первых ликбезов по устройству компьютеров, который потребуется для рассказа про типы данных, - это представление данных в памяти. Очень сильно упрощая, компьютер умеет работать только с нулями и единицами. Каждая такая ячейка, в которой хранится 0 или 1 называется бит. Именно в количестве бит в секунду, например, измеряется скорость передачи данных (по сети интернет или же между жестким диском и оперативной памятью). И если математика в общем была готова к таком повороту (тут надо гуглить "основание системы счисления") и сравнительно легко мы смогли хранить и оперировать числами в памяти компьютера, то вот с остальными данными все сложней. Разберем как же хранятся те или иные вещи в памяти.

Числа
Набрав некоторое количество бит можно сохранить в них число в двоичной системе счисления. Например, десятичное число "64" потребует 7 ячеек и будет записано в виде: "1000000". Таким образом, от того, сколько бит выделено, зависит то, какое число максимум мы можем сохранить. В контексте типов данных мы можем сказать, что под каждое значение с тем или иным типом выделяется определенное количество ячеек. Например, тип данных Integer, который был использован в предыдущем посте для хранения идентификатора фрукта, под собой содержит 32 бита (ячейки) и в него может поместиться максимум десятичное число 2 147 483 647.

Слова (строки, буквы)
Символы, же хранятся в виде некоей таблицы, где каждой букве или символу сопоставляется число - номер в этой таблице символов. Таблиц символов великое множество и гуглятся они по словам "кодировка" или "таблица символов".

Например, слово "шум" в разных кодировках будет сохранено по разному:
- UTF-8: "209, 136", "209, 131", "208, 188"
- ISO-8859-5: "232", "227", "220"

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

В прошлом посте для хранения наименования фрукта fruit_name был выбран тип данных varchar(50). Это значит, предполагается хранить слова, состоящие не больше чем из 50 символов, где на каждый символ приходится 1 байт, то есть 50 байт максимум или не больше 400 бит (ячеек). При этом, если слово, которое мы храним, будет требовать меньше символов, то памяти оно займет меньше - ровно столько, сколько символов-байт потребовалось.

Даты
.... продолжение следует

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

В рамках работы с фруктовой лавкой был использован тип данных: Date, который занимает в случае с PostgreSQL 4 байта, а случае с MS SQL 3 байта. Сравните с 10-ю байтами, если хранить дату в виде строки "16.02.2024".

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

Числа (снова)
В прошлый раз я был не совсем честен и рассмотрел только целые числа. Исправляюсь и представляю вашему вниманию числа приблизительные и дробные.

Числа (дробные)
Тут все просто, суть - это такие же целые числа, но еще при объявлении этого типа указывается сколько мы готовы хранить знаков после запятой. Называются они Decimal или Numeric или еще как-нибудь (у мелкомягких, например, есть тип Money, а в Postgres он появился только с 12-ой версии 🤑 ) . В нашей фруктовой лавке был использован тип Numeric(15, 2) для хранения веса и сумм. Это значит что мы могли бы хранить число с количеством символов 15, из которых 2 - это числа после запятой. Места занимает столько, сколько укажете при объявлении. У разных СУБД тут по разному.

Числа (приблизительные)
Такие числа называются еще числами с плавающей запятой. Если интересна математика, которая стоит за, хранением этих чисел, то вам, наверное, в вики - объяснение нетривиально и требует некоторой подготовки. В нашем случае лишь хочу заметить, что такие числа имеют неопределенную точность, и потому зарплату на таких лучше не считать, а разность двух одинаковых чисел не обязательно будет равна нулю. Чаще всего называют их float или real и занимают они от 4 до 8 байт.

Уникальный идентификатор
Еще один "монстр" для понимания сути которого нужна математика, но кратко - это специальный тип, который хранит уникальную строку определенного формата. Используется для распределенных систем для идентификации справочников (часто можно видеть в Госуслугах или на ГИС ЖКХ), так как вероятность сгенерировать два одинаковых UUID настолько мала, что ею пренебрегают.

XML и JSON
Сами по себе эти форматы хранения (да, тут и формат и тип имеют одно наименование, так что масло масленное) достойны отдельного поста и так и будет. Если кратко, то такие типы данных эдакий правильный способ хранить JSON или XML, чтобы потом можно было к ним обращаться.

Двоичные данные
Тут все просто - это двоичный код (те самые нули и единицы), который сохраняется в таблице как есть без понимания со стороны СУБД, а что же там внутри. По сути, в это поле можно положить все что угодно, но и оперировать с этим всем чем угодно можно будет весьма ограничено. Нельзя сравнивать, например.

Немного поиграли в теорию и возвращаемся к более практическим задачкам. На досуге мы с супругой частенько играем в игру 5букф от Тиньков (ссылка, не реклама, https://5bukv.tinkoff.ru/). На самом деле, игра не нова и является клоном игры wordle, которую ребята из Тинькофф встроили в приложение и посыпали немного подарками. Видимо, это что-то про маркетинг и попытка заставить клиентов почаще гулять в приложение, но это не точно.

Так вот, как-то я обмолвился, что решение этой игры можно написать на SQL и вот момент настал. Попробуем написать решение на SQL + немного добавить анализа того, а есть ли воля случая в игре или за шесть попыток в можно раскрыть любое слово? А если не в русском, а в английском? Получается, интересная задачка про данные.

Приступим. Попробуем спланировать наш заход в этот "продукт" по шагам:
1) Создать структуру хранения для всех возможных слов из пяти букв. Говорим на русском и потому слова тоже будем использовать русские.
2) Найти где-то базу слов (причем по правилам игры там только существительные) и скопировать к себе. Дальше я буду использовать словарь отсюда.
3) Продумать алгоритм по которому мы будем подбирать слово за словом в игре. Возможно, найдется вариант, по которому за один проход мы будем доходить до некоей точки, в которой будет оставаться только одно доступное слово. Это уже похоже на анализ данных.
4) Проверить алгоритмы из третьего пункта и проверить на решаемость или опровергнуть возможность решения.
.....
N) Написать ИИ, который будет решать задачу с первой попытки.

Итак, понедельник - день тяжелый и мы подумаем про структуру. Первой мыслью может быть, что нам хватит просто таблички с перечнем слов. Но, вряд ли кто-то за нас уже собрал все слова из пяти букв и потому данные нужно будет немного подготовить. Следовательно, наша структура претерпевает изменения и нам нужны теперь две таблички:
1) Все слова русского языка
2) Все слова русского языка из пяти букв

-- Все существительные русского языка
CREATE TABLE nouns (word VARCHAR(255));

-- Все существительные русского языка из пяти букв
CREATE TABLE nouns5 (word CHAR(5));

В скрипте выше создается две таблицы, каждая из которых содержит по одной колонке. В первом случае колонка со всеми словами и потому там длина поля (сколько букв можно положить) используется максимальная, а во втором мы знаем что слова будут только из пяти букв и потому явно говорим СУБД, что там будут только строки на пять символов.

Важно! В скрипте выше впервые использованы комментарии. Комментарии - это часть кода, которая не исполняется, но которая помогает понять что же хотел сказать автор без учительницы русского языка и литературы и даже без гугла и искусственных интеллектов. Рекомендую использовать комментарии везде, где возможно неоднозначное трактование кода. В SQL комментарии к коду бывают однострочные и многострочные. Первые начинаются с "--", а вторые начинаются с "/*" и заканчиваются "*/". Например:

-- Это комментарий и он не будет выполнен
SELECT 1; -- Комментарий может быть даже тут, после куска кода, который выполняется
/* А это многострочный комментарий,
когда мысль настолько широкая, что ее не получается
уместить в одну строку */

... продолжение следует
#sql #sqlbasics #firstproject

Шпаргалка по Airflow от Marc Lamberti

Вот ещё шпаргалка

Собрал все части воедино, поменял название и тональность.
Получилось мутно, плотно, в меру горько, в меру крепко. NE DIPA.

https://telegra.ph/Poigraem-v-DataOps-davaj-vecherom-04-16

#dataops

«По «Маяку» Стахан Рахимов дуэтом с Иошпе песни пел…»

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

Тем более, что у меня наконец-то «дошел ход» до выпущенной в сентябре 2022 года товарищами из O'Reilly книги под названием «Data Quality Fundamentals», которая и послужит отправной точкой для данного повествования.
«Все, все как вчера…» - скажет внимательный читатель данного канала словами одной известной рок-поэтессы, ссылаясь на ее стихи практически сорокалетней давности. И будет безусловно прав…
Ибо фразу «работает - не трогай!» я избрал своим основным жизненным принципом еще тогда, когда никакого IT толком в моей жизни и не существовало.

Продолжение следует...

"А мужики-то не знали..."

https://habr.com/ru/companies/glowbyte/articles/821001/

Всех с пятницей!

«Опять мне снится сон,
Один и тот же сон,
Как мы с коллегой Колею
распарсили JSON…»

Впервые с понятием «качество данных» я столкнулся на собеседовании году этак в 2012. Там же я узнал, что у Висенте Феолы Ральфа Кимбалла помимо ставшего классическим труда есть чуть менее известная книга про ETL. Незнание этих двух очевидных для интервьюирующего вещей и стало основной причиной того, что #меняневзяли.

С тех пор термин сей уверенно сопровождает меня на карьерном пути и периодически мне приходилось решать различные задачи с ним связанные. Для тех, кто хоть раз сталкивался с чем-то подобным Great Expectations - всего лишь весьма и весьма посредственный «шираз». Но тут, как говорится, на вкус и цвет…

Логично, что с тех пор любые разговоры на тему «качества данных» вызывают у меня примерно такую же реакцию, как и постоянно звучавшие из уст отечественных футбольных комментаторов во времена, когда у меня еще хватало терпения футбол смотреть, фразы вроде «гол в раздевалку» или «выкрутил позвонки». Тем более, что, перефразируя Брайана Клафа, «больше всего о качестве данных рассуждают люди, едва способные написать простой SQL-запрос».

Несмотря на мое отношение к данному вопросу, не могу не подчеркнуть его животрепещущую актуальность, для описания которой идеально подходят слова другой легенды английского тренерского цеха - Билла Шенкли: «Многие думают, что качество данных - это вопрос жизни и смерти. Они ошибаются, это намного важнее.»

Перейдем к сути. Не стану и в этот раз изобретать велосипед, воспользуюсь проверенным приемом, заимствованным у Льва Николаевича Гумилева, - начну с определения (каким его видят авторы «Data Quality Fundamentals»).

Качество данных - это «уровень здоровья» данных на каждом этапе их жизненного цикла.

продолжение следует…

#dataquality

Marc Lambertti опубликовал свои приоритеты в обучении инженеров данных:

1️⃣ Data modeling
2️⃣ SQL
3️⃣ Data structure
4️⃣ Python
5️⃣ Version control
6️⃣ Containerization (Docker/K8s)
7️⃣ AWS or GCP or Azure
8️⃣ Data tools (dbt, Snowflake, Databricks, Airflow, Kafka, etc.)

Оригинал здесь - https://www.linkedin.com/posts/marclamberti_dataengineer-dataengineering-airflow-activity-7212461313275432960-XdMs?utm_source=share&utm_medium=member_desktop

https://youtu.be/DXq3qtMgvBU?feature=shared


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

Но нет...

«Double-crossed by Neon Pill»

Я сначала хотел написать что-то на стариковско-ворчательном: «Ничего, мол, нового, «книга-ради-книги» и все это уже было в «Симпсонах»…»
Но потом вдруг вспомнил, как когда-то давно зачитывался книгами Ицика Бен-Гана и Брайана Найта, и подумал, что для кого-то эта книга может стать чем-то подобным, важным шагом на пути к своей мечте, путеводной звездой, остающейся в памяти надолго, как «первая любовь, что известна с древности, и в которой так много неизвестности». Ищи ее потом, эту «Синюю птицу», взмахом крыла поманившую», на рагу уже небось пущена злостными недоброжелателями, не слыхавшими «как поет Дроздов».

Начало книги довольно бодрое и традиционное для подобного класса: описание трудностей, связанных с обработкой больших данных, которые инструмент призван был разрешить, затем установка, настройка и прочий «курс молодого бойца».

Вторая часть посвящена более продвинутым вещам таким, как архитектура Trino, описание модели выполнения запросов и оптимизатора. По паре глав уделено коннекторам и использованию SQL.

Третья часть описывает аспекты эксплуатации такие, как безопасность, мониторинг и совместное использование Trino c другими инструментами из мира данных: Apache Superset, Apache Airflow и т.п.

Подведем итоги: книга написана простым и доступным английским языком, содержит множество иллюстраций и примеров кода, так что прочтение вряд ли отнимет значительный промежуток времени. «Старикам здесь не место», для вас есть официальная документация. Подойдет тем, кто никогда не слышал слов типа «Query Plan» или «Cost-Based Optimizer» или только слышал.

Мое же впечатление от книги наиболее точно передается словом из заглавной песни с нового альбома кумиров из ВИА «Cage The Elephant», под который она и читалась, - «double-crossed».
Не видать им «Грэмми» за третий подряд альбом, это и без всяких предиктивных моделей ясно.

Так бывает, когда выбираешь не ту пилюлю…
#trino #books #напочитать

Если верить написанному на этой картинке, то я родился сразу синьором...

Глядя на нее, я вспомнил одну старую сказку, в которой героине - соискательнице на роль спутницы жизни принца предложили выполнить тестовое задание в виде сна на горе тюфяков и перин с подложенной под них горошиной.
И тут же решил добавить в свой список вопросов к интервьюируемым мной инженерам следующие "горошины":

- Ваши действия при встрече с миддлом?
- Какие звуки Вы издаете при знакомстве с новым фреймворком?
- Встречалась ли ранее в вашей практике "такая х..ня"?
и т. п.

P.S. Да, я знаю, что сегодня еще не пятница, и время безудержного веселья еще не пришло... Но я-то в отпуске...

Дата-контракты - тема сейчас, как очевидно, «хайповая», многим видится очередной «некстван», в то время как обитатели измайловских общежитий МГТУ имени Баумана нулевых годов почуяли теплый весенний ветерок и, позевывая, принялись искать в закромах жестких дисков тот самый текст: «Вот мы и в Канаде!!!»

Можно было бы,как обычно, начать с определения, но что в этом толку? Ибо как писал в «Закате Европы» Освальд Шпенглер: «Средство для уразумения живых форм — аналогия». А дата-контракты пока скорее живы. А раз так, то в очередной раз за иллюстрацией обратимся к лучшему сериалу для дата-специалистов любых профессий - «Тед Лассо».

В седьмом эпизоде третьего сезона под название «The Strings That Bind Us» игроки «Ричмонда» отрабатывают осознанность на поле при помощи предложенной Роем Кентом революционной методики: футболисты попарно соединены веревками, привязанными к их пенисам. «Скованным одной цепью» теперь приходится согласовывать свои действия друг с другом, «чтобы не было мучительно больно».

Вот эта веревка и есть дата-контракт или же «соглашение которое определяет, как данные должны быть структурированы, организованы для обмена между различными системами, приложениями или сторонами.»

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

Все будет идти как встарь, пока не реализуется «бессильная» тайна имени Сергея Витицкого (он же Борис Стругацкий): «Что-то загадочное и даже сакральное, может быть, должно произойти с этим миром, чтобы Человек Воспитанный стал этому миру нужен. Человечеству сделался бы нужен. Самому себе и ближнему своему.»