Приветствуем!
Вы на канале про Data Driven культуру, который бережно и старательно ведёт команда российского BI продукта Analytic Workspace.
Но мы не будем рассказывать здесь про наш продукт и нахваливать его, хотя нам есть чем хвастать 😉
Здесь мы делимся информацией из мира больших и малых данных — из мира, в который мы ежедневно окунаемся.
Про что мы здесь пишем:
— Интересные примеры визуализаций.
— Дата сторителлинг.
— ML в BI. BI без ML. ML без BI.
— Кейсы из практики внедрения (как удалось объединить необъединяемое, например).
— Культура DD в общем смысле.
— Тренды на рынке BI.
— Статистика с рынка BI: рост/падение популярности профессии, профиль специалиста и т.п.
— Что почитать.
— Где и чему учиться.
Для удобной навигации используем теги:
#новичкам – знания, точно полезные для тех, кто только погружается в тему.
#профи – информация для тех, кто уже в теме BI.
#ru_bi – информация из мира российских BI.
#визуал – пример классного (или страшного) дашборда.
#практика – примеры из практики, датасеты и прочее.
#мнение – оно и есть мнение.
#технологии – о технологиях в BI.
#статья – полезная статья из мира данных.
#книга – рекомендация книги.
#интервью – интервью с представителями отрасли.
#история – интересная история из мира данных.
#жиза – смешные и не очень зарисовки из Data Driven будней.
#дайджест – подборка ссылок на полезное, увиденное нами.
#мероприятия — анонс или запись классного мероприятия.
#знания — ценные знания из мира данных.
———————————
analyticworkspace.ru — это наш сайт.
@awcommunity — сообщество взаимопомощи специалистов, которые работают с Analytic Workspace.
Вы на канале про Data Driven культуру, который бережно и старательно ведёт команда российского BI продукта Analytic Workspace.
Но мы не будем рассказывать здесь про наш продукт и нахваливать его, хотя нам есть чем хвастать 😉
Здесь мы делимся информацией из мира больших и малых данных — из мира, в который мы ежедневно окунаемся.
Про что мы здесь пишем:
— Интересные примеры визуализаций.
— Дата сторителлинг.
— ML в BI. BI без ML. ML без BI.
— Кейсы из практики внедрения (как удалось объединить необъединяемое, например).
— Культура DD в общем смысле.
— Тренды на рынке BI.
— Статистика с рынка BI: рост/падение популярности профессии, профиль специалиста и т.п.
— Что почитать.
— Где и чему учиться.
Для удобной навигации используем теги:
#новичкам – знания, точно полезные для тех, кто только погружается в тему.
#профи – информация для тех, кто уже в теме BI.
#ru_bi – информация из мира российских BI.
#визуал – пример классного (или страшного) дашборда.
#практика – примеры из практики, датасеты и прочее.
#мнение – оно и есть мнение.
#технологии – о технологиях в BI.
#статья – полезная статья из мира данных.
#книга – рекомендация книги.
#интервью – интервью с представителями отрасли.
#история – интересная история из мира данных.
#жиза – смешные и не очень зарисовки из Data Driven будней.
#дайджест – подборка ссылок на полезное, увиденное нами.
#мероприятия — анонс или запись классного мероприятия.
#знания — ценные знания из мира данных.
———————————
analyticworkspace.ru — это наш сайт.
@awcommunity — сообщество взаимопомощи специалистов, которые работают с Analytic Workspace.
Про Data Lineage
В мире аналитики продолжает набирать популярность тема Data Lineage (линия данных), описывающая движение данных от источника их происхождения через этапы обработки к опубликованному отчету. Это дает возможность расследовать причины ошибки в данных вплоть до первопричины их возникновения.
Data Lineage на пальцах 👇
На начальном этапе внедрения BI у пользователей высокий уровень недоверия к данным в отчетах — это логично и ожидаемо.
Встретив неожиданную цифру в отчёте, пользователь пытается разобраться в том, как же эта цифра произошла. Этот клубок сначала разматывается средствами self service аналитики, когда формируются уточняющие срезы данных, drill-down, поэкранное сопоставление отчета с первичными данными в учетной системе.
Если в отчете все верно, пользователь копает глубже — идет в модуль ETL и тщательно проверяет все этапы манипуляций с данными. Хорошо, если на этом этапе BI позволяет визуализировать последовательность обработки данных в ETL. К примеру, у нас в Analytic Workspace можно построить DAG-граф в Apache Airflow и посмотреть, какие трансформации данные прошли. DAG-граф — это направленный ациклический граф (кружочки и стрелочки).
И вот в ETL можно прийти к любопытной развилке, которая влияет на восприятие качества внедрения BI.
❤️ BI помог: если неожиданная цифра оказывается верной, то рождается инсайт, побуждающий пользователя продолжить исследование и проводить «созидательный» анализ факторов, повлиявших на формирование такой версии данных. Иными словами — что-то не то в процессе сбора данных.
💔BI облом: если выясняется, что была допущена ошибка при обработке данных, то добавляется минус в карму проекта внедрения BI. Пользователь, плюнув и выругавшись: "К черту ваш BI”, возвращается к старому проверенному дедовскому способу — Экселю.
#технологии
В мире аналитики продолжает набирать популярность тема Data Lineage (линия данных), описывающая движение данных от источника их происхождения через этапы обработки к опубликованному отчету. Это дает возможность расследовать причины ошибки в данных вплоть до первопричины их возникновения.
Data Lineage на пальцах 👇
На начальном этапе внедрения BI у пользователей высокий уровень недоверия к данным в отчетах — это логично и ожидаемо.
Встретив неожиданную цифру в отчёте, пользователь пытается разобраться в том, как же эта цифра произошла. Этот клубок сначала разматывается средствами self service аналитики, когда формируются уточняющие срезы данных, drill-down, поэкранное сопоставление отчета с первичными данными в учетной системе.
Если в отчете все верно, пользователь копает глубже — идет в модуль ETL и тщательно проверяет все этапы манипуляций с данными. Хорошо, если на этом этапе BI позволяет визуализировать последовательность обработки данных в ETL. К примеру, у нас в Analytic Workspace можно построить DAG-граф в Apache Airflow и посмотреть, какие трансформации данные прошли. DAG-граф — это направленный ациклический граф (кружочки и стрелочки).
И вот в ETL можно прийти к любопытной развилке, которая влияет на восприятие качества внедрения BI.
❤️ BI помог: если неожиданная цифра оказывается верной, то рождается инсайт, побуждающий пользователя продолжить исследование и проводить «созидательный» анализ факторов, повлиявших на формирование такой версии данных. Иными словами — что-то не то в процессе сбора данных.
💔BI облом: если выясняется, что была допущена ошибка при обработке данных, то добавляется минус в карму проекта внедрения BI. Пользователь, плюнув и выругавшись: "К черту ваш BI”, возвращается к старому проверенному дедовскому способу — Экселю.
#технологии
Знаете ли вы, что в России есть профессиональный стандарт Специалист по большим данным, утверждённый Министерством труда и социальной защиты в 2020 году?
Визуализация данных в работе специалиста по большим данным занимает малый процент.
Львиная часть трудовых функций относится к работе с данными: извлечение, хранение, преобразование и прочие радости.
В стандарте есть интересная трудовая функция: Управление качеством больших данных.
Для выполнения этой функции требуется знать метрики качества больших данных.
Какие же основные метрики качества больших данных выделяют (это уже не из стандарта):
1. Полнота = % от общего количества значений, отличных от NULL + непустых значений.
2. Уникальность = % от не повторяющихся значений.
3. Согласованность = % данных, имеющих шаблоны. (пример: когда в поле с электронной почтой данные, которые не соответствуют маске электронной почты).
4. Допустимость = % от соответствия ссылок. (пример, когда данные внесены не в соответствии с общепринятой таксономией: условно льва вписали в семейство собачьих).
5. Точность = % от неотправленных значений. (пример, данные в систему аналитики отправили одни, а в учётной системе их после обновили).
6. Компоновка = % от хорошо интегрированных данных. (условно, данные по каким-то идентификаторам можно связывать с другими наборами данных).
Теперь, если на вечеринке за бокалом игристого кто-то со вздохом произнесёт: "Да! Качество больших данных нынче не то, что раньше.". Можете смело поинтересоваться, какие именно метрики качества больших данных имеются ввиду — завяжется интересная беседа.
А что касается профессиональных стандартов — по ссылке далее можно просмотреть множество проф.стандартов из области ИТ, действующих в России: от дизайнера, до девопса. Их делали крупные ИТ-компании России — можно понять, каких компетенций пока не хватает и что стоит прокачать.
Все профстандарты в ИТ: http://spk-it.ru/profs/
#технологии
Визуализация данных в работе специалиста по большим данным занимает малый процент.
Львиная часть трудовых функций относится к работе с данными: извлечение, хранение, преобразование и прочие радости.
В стандарте есть интересная трудовая функция: Управление качеством больших данных.
Для выполнения этой функции требуется знать метрики качества больших данных.
Какие же основные метрики качества больших данных выделяют (это уже не из стандарта):
1. Полнота = % от общего количества значений, отличных от NULL + непустых значений.
2. Уникальность = % от не повторяющихся значений.
3. Согласованность = % данных, имеющих шаблоны. (пример: когда в поле с электронной почтой данные, которые не соответствуют маске электронной почты).
4. Допустимость = % от соответствия ссылок. (пример, когда данные внесены не в соответствии с общепринятой таксономией: условно льва вписали в семейство собачьих).
5. Точность = % от неотправленных значений. (пример, данные в систему аналитики отправили одни, а в учётной системе их после обновили).
6. Компоновка = % от хорошо интегрированных данных. (условно, данные по каким-то идентификаторам можно связывать с другими наборами данных).
Теперь, если на вечеринке за бокалом игристого кто-то со вздохом произнесёт: "Да! Качество больших данных нынче не то, что раньше.". Можете смело поинтересоваться, какие именно метрики качества больших данных имеются ввиду — завяжется интересная беседа.
А что касается профессиональных стандартов — по ссылке далее можно просмотреть множество проф.стандартов из области ИТ, действующих в России: от дизайнера, до девопса. Их делали крупные ИТ-компании России — можно понять, каких компетенций пока не хватает и что стоит прокачать.
Все профстандарты в ИТ: http://spk-it.ru/profs/
#технологии
О простой непростой арифметике
Когда речь заходит о BI, у рядового пользователя возникают ассоциации с большими данными и сложной, непонятной внутренней структурой этих умных инструментов. Бывает даже, что в иной компании руководство внедряет новейшую BI-систему, а сотрудники тайком выгружают из нее результаты в старый добрый Excel - так спокойнее.
Привыкли мы к Excel. А вот полезешь на хабр и понимаешь, что привычный уютный Excel тоже набит пыльными шкафами с удивительными скелетами. Возьмем для примера простую… арифметику.
Присмотритесь к гифке внизу. Обратите внимание, что среднее MROUND с точностью до третьего знака после запятой в столбце G зависит от порядка сортировки чисел в столбце I. Как такое может быть? Ведь сортируемые числа-то одинаковые! Одинаковые, верно, но порядок их сложения разный и тут вступает в действие тот неприятный факт, что реальное устройство всегда имеет ограничения.
Процесс суммирования и округления можно воспроизвести, например, на Python (вычисления в честном аппаратном двоичном коде):
>>> 1.68+1.71+1.715+1.965
7.069999999999999
>>> 1.965+1.715+1.71+1.68
7.07
>>> (1.68+1.71+1.715+1.965)/4
1.7674999999999998
>>> (1.965+1.715+1.71+1.68)/4
1.7675
Ну а дальше функция MROUND() честно округляет по предписанным правилам.
И проблема в том, что Excel, как инструмент для экономической и финансовой сфер, должен был бы считать всю арифметику в десятичном режиме, а не в двоичном, как вшито в процессор. В этом случае ошибки бы не было.
В дотнете есть тип decimal, в котором представление десятичное. В Java есть BigDecimal. В процессорах IBM (линии SystemZ и POWER) бывает аппаратная десятичная арифметика. У той же IBM есть General Decimal Arithmetic Specification, в которой собраны рецепты реализации десятичной плавучки как библиотеки. В общем, процесс идёт. Почему в Excel держатся за двоичку, хотя десятичная арифметика для него достаточно дешевая — кто его знает…
#технологии
Когда речь заходит о BI, у рядового пользователя возникают ассоциации с большими данными и сложной, непонятной внутренней структурой этих умных инструментов. Бывает даже, что в иной компании руководство внедряет новейшую BI-систему, а сотрудники тайком выгружают из нее результаты в старый добрый Excel - так спокойнее.
Привыкли мы к Excel. А вот полезешь на хабр и понимаешь, что привычный уютный Excel тоже набит пыльными шкафами с удивительными скелетами. Возьмем для примера простую… арифметику.
Присмотритесь к гифке внизу. Обратите внимание, что среднее MROUND с точностью до третьего знака после запятой в столбце G зависит от порядка сортировки чисел в столбце I. Как такое может быть? Ведь сортируемые числа-то одинаковые! Одинаковые, верно, но порядок их сложения разный и тут вступает в действие тот неприятный факт, что реальное устройство всегда имеет ограничения.
Процесс суммирования и округления можно воспроизвести, например, на Python (вычисления в честном аппаратном двоичном коде):
>>> 1.68+1.71+1.715+1.965
7.069999999999999
>>> 1.965+1.715+1.71+1.68
7.07
>>> (1.68+1.71+1.715+1.965)/4
1.7674999999999998
>>> (1.965+1.715+1.71+1.68)/4
1.7675
Ну а дальше функция MROUND() честно округляет по предписанным правилам.
И проблема в том, что Excel, как инструмент для экономической и финансовой сфер, должен был бы считать всю арифметику в десятичном режиме, а не в двоичном, как вшито в процессор. В этом случае ошибки бы не было.
В дотнете есть тип decimal, в котором представление десятичное. В Java есть BigDecimal. В процессорах IBM (линии SystemZ и POWER) бывает аппаратная десятичная арифметика. У той же IBM есть General Decimal Arithmetic Specification, в которой собраны рецепты реализации десятичной плавучки как библиотеки. В общем, процесс идёт. Почему в Excel держатся за двоичку, хотя десятичная арифметика для него достаточно дешевая — кто его знает…
#технологии
Почему Clickhouse?
Точнее вопрос будет звучать так: почему в системах аналитики часто используется Clickhouse, а не традиционные БД(Postgres, MySQL, Oracle и т.д.)?
Ответ: из-за архитектурных особенностей баз данных.
В классических реляционных базах данные хранятся построчно, приблизительно так:
[A1, B1, C1], [A2, B2, C2], [A3, B3, C3]…
где A, B и С — это поля (столбцы), а 1,2 и 3 — номер записи (строки).
Такое хранение удобно для частых операций добавления новых строк в базу данных, хранящуюся как правило на жестком диске, и используется в транзакционных приложениях(создали нового пользователя - записали в базу, отправили сообщение - записали в базу и т.п.)
В случае аналитических систем наибольшая нагрузка создается тяжелыми выборками (select) сотен тысяч и миллионов записей, часто с группировками и расчетом агрегатов. Количество операций записи при этом невысоко, нередко менее 1% общего числа.
Однако что произойдет, если выбрать, например, только 3 поля из таблицы, в которой их всего 50? В силу построчного хранения данных в традиционных СУБД будут прочитаны абсолютно все строки целиком со всеми полями, пропущены через контроллер дискового ввода-вывода и переданы процессору, который уже отберет только необходимые для запроса.
Решить эту проблему призваны колоночные СУБД, к которым и относится Clickhouse. Основная идея колоночных СУБД — это хранение данных не по строкам, а по колонкам. С точки зрения SQL-клиента данные представлены как обычно в виде таблиц, при этом физически на диске значения одного поля хранятся последовательно друг за другом — приблизительно так:
[A1, A2, A3], [B1, B2, B3], [C1, C2, C3] и т.д.
Такая организация данных приводит к тому, что при выборе в SELECT 3 полей таблицы из 50, с диска физически будут прочитаны только 3 колонки. Это означает что нагрузка на канал ввода-вывода будет приблизительно в 50/3=17 раз меньше, чем при выполнении такого же запроса в традиционной СУБД. Кроме того, при поколоночном хранении данных появляется возможность сильно компрессировать данные, так как в одной колонке таблицы данные как правило однотипные, чего не скажешь о строке.
#новичкам #технологии #знания
Точнее вопрос будет звучать так: почему в системах аналитики часто используется Clickhouse, а не традиционные БД(Postgres, MySQL, Oracle и т.д.)?
Ответ: из-за архитектурных особенностей баз данных.
В классических реляционных базах данные хранятся построчно, приблизительно так:
[A1, B1, C1], [A2, B2, C2], [A3, B3, C3]…
где A, B и С — это поля (столбцы), а 1,2 и 3 — номер записи (строки).
Такое хранение удобно для частых операций добавления новых строк в базу данных, хранящуюся как правило на жестком диске, и используется в транзакционных приложениях(создали нового пользователя - записали в базу, отправили сообщение - записали в базу и т.п.)
В случае аналитических систем наибольшая нагрузка создается тяжелыми выборками (select) сотен тысяч и миллионов записей, часто с группировками и расчетом агрегатов. Количество операций записи при этом невысоко, нередко менее 1% общего числа.
Однако что произойдет, если выбрать, например, только 3 поля из таблицы, в которой их всего 50? В силу построчного хранения данных в традиционных СУБД будут прочитаны абсолютно все строки целиком со всеми полями, пропущены через контроллер дискового ввода-вывода и переданы процессору, который уже отберет только необходимые для запроса.
Решить эту проблему призваны колоночные СУБД, к которым и относится Clickhouse. Основная идея колоночных СУБД — это хранение данных не по строкам, а по колонкам. С точки зрения SQL-клиента данные представлены как обычно в виде таблиц, при этом физически на диске значения одного поля хранятся последовательно друг за другом — приблизительно так:
[A1, A2, A3], [B1, B2, B3], [C1, C2, C3] и т.д.
Такая организация данных приводит к тому, что при выборе в SELECT 3 полей таблицы из 50, с диска физически будут прочитаны только 3 колонки. Это означает что нагрузка на канал ввода-вывода будет приблизительно в 50/3=17 раз меньше, чем при выполнении такого же запроса в традиционной СУБД. Кроме того, при поколоночном хранении данных появляется возможность сильно компрессировать данные, так как в одной колонке таблицы данные как правило однотипные, чего не скажешь о строке.
#новичкам #технологии #знания