Да, один раз это может даже будет свежо и забавно, но только непонятно зачем вся остальная игра, все созданные геймдизайнерами уровни и сражения.
Ну иногда ведь смысл в том, чтобы можно было пройти разными способами. Из того, что приходит в голову: Hitman. Хочу - заморачиваюсь, хочу - проверяю можно ли пройти уровень максимально топорно. И то и то будто бы интересно.
Мне было бы интересно, можно ли применять LLM для дипломатии в играх типа Цивилизации. Играл только в третью, там дипломатия выглядит очень топорной. Кажется, что бот с подключенной LLM мог бы лучше понимать контекст партии.
Спасибо за подробный обзор, очень много аспектов приведено. Слышал про Data Mesh еще в 2020 году. Некоторые из обозначенных проблем на мой взгляд видны еще на стадии Data Lake. Если источник не может отдать нормальные данные в один единственный Data Lake, о каком Data Mesh может идти речь, ведь помимо приобретения новых компетенций (дата-специалисты) придется отвечать сразу перед всеми потребителями данных со своими требованиями у каждого. А если не учитывать эти требования, то как тогда оценить качество таких данных? В общем, есть о чем подумать.
чтобы не остаться на уровне валидаций данных 2010 года
Не совсем понятно, что в итоге предлагается. Заменить стандартные проверки на более "продвинутые" или дополнить мониторинг этими статистическими проверками? Если второе, то что делать с ложными срабатываниями?
Видим, что разница между средним и медианой в нашем случае огромна. Я бы не стал отдавать такие данные заказчику как минимум, а перепроверил бы слой raw.
Глазами видите. А проверка какая в итоге будет? И насколько универсальна и/или чувствительна будет такая проверка?
На мой взгляд в любом случае тема затронута очень интересная, поэтому спасибо за статью!
Понравилась идея с персональными блогами. Возможно было бы хорошо тогда и ссылки на телеграм-каналы разрешать только в статьях в этих блогах. В любом случае поддерживаю.
однако я не нашел никакой информации о паттернах работы с данными
На мой взгляд даже на хабре много статей про подходы, просто они не обозначены какими-то аббревиатурами, а представляют из себя описания внутренностей хранилищ данных разных компаний
Что касается Write-Audit-Publish, у нас такие проверки называют "блокирующими" в том плане, что они блокируют дальнейшую работу пайплайна при срабатывании проверки. И, например, в статье Ростелеком используется такое же название: https://habr.com/ru/companies/rostelecom/articles/675554/
Очень отозвалась статья. Как рулить командой, в которой только младшие специалисты, это прямо отдельная тема. Кто-то вообще ни за что не захочет с этим связываться или скажет, что такого не должно существовать в природе, кто-то пожалеет что с этим связался, кто-то наловчится и выжмет максимум из ситуации. Лично у меня совершенно другая область (DWH), но опыт видимо аналогичный, включая стажировки.
За кадром осталась тема развития сотрудников в такой команде. Также имею другой опыт по сравнению с тем, что описано в разделе про негативную обратную связь. Тоже считаю, что нельзя приводить к тому, чтобы сотрудник "защищался, замыкался или нападал", но мягкость на мой взгляд - это опционально. Я имею в виду не "ошибку" сотрудника как таковую - в этом случае я бы вообще не применял термин "негативная обратная связь", это обычный сбор граблей, а например про ситуации, когда ошибка повторяется или не соблюдается какая-то договоренность.
Не совсем понял, как изложенное в статье объясняет вывод
Я просто высказался, что NumPy — это худший язык для работы с массивами, кроме всех других языков работы с массивами.
Пересаживался с MATLAB на Python и NumPy тогда оказался спасением. На мой взгляд работа с многомерными таблицами - это не та область, где всегда можно обеспечить "очевидность" происходящего.
Когда я читаю какой-то код, чтобы было «очевидно», что он делает.
Вот, кстати, пример кода на MATLAB (кусок численного решения 3D задачи со временем, то есть идет работа с таблицами с 4 измерениями). Тяжело читать? Да, очень. Написать при этом было не очень сложно и сильно пересекается с тем, что было написано на бумаге.
Мучался год, не мог понять источник гула в квартире, из-за которого в один момент даже начал дрожать шкаф. Обратил внимание, что гул идет в холодное время и чаще всего по ночам. Разгадка оказалась проста: кондиционер в режиме на отопление у соседа снизу в панельном доме. По звуку как будто на улице едет трактор (но никак не уедет) или стоящий под окном грузовик с включенным двигателем.
Общение с соседом
Ссылки на посты на пикабу по теме шума / вибрации / гула в квартире, которые собрал в процессе поиска источника шума
Понимаю, что сарказм, но хотел бы добавить, что если заменить "точно знают, что этот код делает" на "точно знают, что этот код должен делать", то это уже похоже на правду.
За обзор некоторых инструментов спасибо. Но если по сути задачи, то разве не очевидно, что кастомизация мельчайших деталей не будет доступна в большинстве BI-инструментов? На мой взгляд, у них цель немного другая: покрыть 99% потребностей в визуализации. Для всего остального есть D3.js, ggplot2 и тд и тп
Он не отрисовывает в точности как в примере из статьи, но дальше там можно продолжать настраивать положения заголовков, параметры подписей осей, шрифты, параметры сетки, цвета линии трендов и даже модель для линии трендов (не обязательно линейную).
Если хочется добавить сопроводительный текст, то можно обернуть это все в R Markdown.
Лучше собирать лишние данные, чем страдать от того, что их не хватает.
Хорошая практика – подумать на этапе аналитики о том, какие данные и для чего хочется собирать в рамках задачи.
Первый пункт из Полезных советов на мой взгляд спорный. Это две отдельные проблемы, которые не обязательно противопоставлять. А вот второй пункт отлично дополняется цитатой из той же DAMA DMBOK
Определение критериев качества данных до начала планирования нового процесса или системы — признак зрелости организации в области управления данными и отличное средство укрепления административной дисциплины и налаживания плодотворного сотрудничества между функциональными подразделениями.
Делаю локальную копию одного сайта, который обновлялся в период с 2009 по 2017 год, но пока все еще доступен. Обратил внимание, что половина ссылок уже невалидны (собственно, почему и зашел перечитать этот пост).
Ну и какой тогда смысл во внешних ссылках, если срок их жизни меньше десятка лет?..
Кажется, что сейчас на практике решение этой проблемы сводится только к https://web.archive.org/.
История с тем, что решение через RANK кто-то может считать единственно верным, мне кажется немного натянутой.
Вообще, сам тест действительно очень древний, мне он тоже попадался. Раскопки привели к статье на хабре аж 2013 года: https://habr.com/ru/articles/181033/
А самое забавное, что она опубликована 27 мая, как и тест на сайте jitbit, если смотреть через веб-архив: http://web.archive.org/web/20130607185217/https://www.jitbit.com/news/181-jitbits-sql-interview-questions/
Вот только наборы задач в статье на хабре и на сайте jitbit отличаются, совпадают только 4 задачи, включая задачу с поиском сотрудников с максимальной зарплатой (идет под номером 2).
Так вот дело в том, что в оригинальной статье приведено как раз другое решение:
select a.*
from employee a
where a.salary = ( select max(salary) from employee b
where b.department_id = a.department_id )
Что-то сложнее COUNT(*) пробовали запускать? У меня вот как-то не сложилось. Натравил на директорию с parquet-файлами. Нужно было воспроизвести логику с DENSE_RANK и GROUP BY, запрос все время вылетал по памяти. Один из вариантов запросов для решения той же проблемы наоборот стал вечно крутиться. Пришлось обрабатывать все файлы в цикле и склеивать каждый новый файл с результатами обработки всех предыдущих. Особо деталей не приведу, так как было давно, но суть в том, что была надежда просто написать SQL и получить результат, но магии не случилось, поэтому пришлось писать код.
Про дэшборд написал в том плане, что система связанных DQ-дэшбордов позволяет видеть состояние на всех уровнях без дополнительных усилий. Например, DQ-дэшборд для инцидентов позволяет с одного взгляда понять, где что пошло не так. Его можно обогатить всякой сопутствующей информацией, чтобы DQ-аналитику не приходилось искать ее самостоятельно (история инцидентов, документация, ETL и тд). Это не роботизация, но тоже экономит кучу времени.
С другой стороны да, понятно, что скорее это делается в первую очередь, а затем идет уже более сложная автоматизация.
Даже добавить особо нечего...был очень похожий опыт в другом телеком-операторе. Точно также пришло осознание необходимости оптимизации и автоматизации вместо масштабирования команды.
Не в курсе, есть ли у вас такие наработки, но еще можно двигаться в сторону DQ-дэшбордов и интеграции с каталогом данных.
Когда бизнес просит «просто выгрузить файлик с городами», нужно понять, как он эти данные будет использовать
Будучи младшим специалистом работал с рядом задач, в которых фигурировала сущность "Город". Чем больше я над ними работал, тем меньше понимал, что такое город и для чего он вообще нужен. В итоге для себя вопрос закрыл обработкой результатов переписи населения. Причем это тоже задача не из разряда эксельки распарсить. Там и ошибки и опечатки и изменения перечня городов год к году. Получился список вида: Год, Код региона, Название города, Население. Потом через сервис геокодирования получил еще координаты центров городов. Этого оказалось достаточно.
На сайте Росстата есть несколько разделов: Статистика / Переписи населения или Статистика / Официальная статистика / Население. Но ни там ни там не будет подробной информации по годам. Архивы по годам лежат в: Публикации / Каталог публикаций / Численность населения Российской Федерации по муниципальным образованиям.
Ну иногда ведь смысл в том, чтобы можно было пройти разными способами. Из того, что приходит в голову: Hitman. Хочу - заморачиваюсь, хочу - проверяю можно ли пройти уровень максимально топорно. И то и то будто бы интересно.
Мне было бы интересно, можно ли применять LLM для дипломатии в играх типа Цивилизации. Играл только в третью, там дипломатия выглядит очень топорной. Кажется, что бот с подключенной LLM мог бы лучше понимать контекст партии.
Спасибо за подробный обзор, очень много аспектов приведено. Слышал про Data Mesh еще в 2020 году. Некоторые из обозначенных проблем на мой взгляд видны еще на стадии Data Lake. Если источник не может отдать нормальные данные в один единственный Data Lake, о каком Data Mesh может идти речь, ведь помимо приобретения новых компетенций (дата-специалисты) придется отвечать сразу перед всеми потребителями данных со своими требованиями у каждого. А если не учитывать эти требования, то как тогда оценить качество таких данных? В общем, есть о чем подумать.
Не совсем понятно, что в итоге предлагается. Заменить стандартные проверки на более "продвинутые" или дополнить мониторинг этими статистическими проверками? Если второе, то что делать с ложными срабатываниями?
Глазами видите. А проверка какая в итоге будет? И насколько универсальна и/или чувствительна будет такая проверка?
На мой взгляд в любом случае тема затронута очень интересная, поэтому спасибо за статью!
Делал примерно тоже самое после прочтения статьи https://habr.com/ru/articles/850674/
Я бы даже сказал, что в моей базе знаний лежит очень похожая по наполнению заметка, с таким же итогом
По сути просто более детальное описание https://iceberg.apache.org/spark-quickstart/ , еще что-то полезное можно посмотреть тут: https://iceberg.apache.org/spec/
Лично мне так не показалось. Смысла разбираться с этим в домашней песочнице кажется нет никакого.
В любом случае спасибо, почти единственная статья, которая за сегодня привлекла внимание, один сплошной ИИ вокруг...
Понравилась идея с персональными блогами. Возможно было бы хорошо тогда и ссылки на телеграм-каналы разрешать только в статьях в этих блогах. В любом случае поддерживаю.
Спасибо за статью!
На мой взгляд даже на хабре много статей про подходы, просто они не обозначены какими-то аббревиатурами, а представляют из себя описания внутренностей хранилищ данных разных компаний
Что касается Write-Audit-Publish, у нас такие проверки называют "блокирующими" в том плане, что они блокируют дальнейшую работу пайплайна при срабатывании проверки. И, например, в статье Ростелеком используется такое же название: https://habr.com/ru/companies/rostelecom/articles/675554/
Очень отозвалась статья. Как рулить командой, в которой только младшие специалисты, это прямо отдельная тема. Кто-то вообще ни за что не захочет с этим связываться или скажет, что такого не должно существовать в природе, кто-то пожалеет что с этим связался, кто-то наловчится и выжмет максимум из ситуации. Лично у меня совершенно другая область (DWH), но опыт видимо аналогичный, включая стажировки.
За кадром осталась тема развития сотрудников в такой команде. Также имею другой опыт по сравнению с тем, что описано в разделе про негативную обратную связь. Тоже считаю, что нельзя приводить к тому, чтобы сотрудник "защищался, замыкался или нападал", но мягкость на мой взгляд - это опционально. Я имею в виду не "ошибку" сотрудника как таковую - в этом случае я бы вообще не применял термин "негативная обратная связь", это обычный сбор граблей, а например про ситуации, когда ошибка повторяется или не соблюдается какая-то договоренность.
Не совсем понял, как изложенное в статье объясняет вывод
Пересаживался с MATLAB на Python и NumPy тогда оказался спасением. На мой взгляд работа с многомерными таблицами - это не та область, где всегда можно обеспечить "очевидность" происходящего.
Вот, кстати, пример кода на MATLAB (кусок численного решения 3D задачи со временем, то есть идет работа с таблицами с 4 измерениями). Тяжело читать? Да, очень. Написать при этом было не очень сложно и сильно пересекается с тем, что было написано на бумаге.
Скрытый текст
Мучался год, не мог понять источник гула в квартире, из-за которого в один момент даже начал дрожать шкаф. Обратил внимание, что гул идет в холодное время и чаще всего по ночам. Разгадка оказалась проста: кондиционер в режиме на отопление у соседа снизу в панельном доме. По звуку как будто на улице едет трактор (но никак не уедет) или стоящий под окном грузовик с включенным двигателем.
Общение с соседом
Ссылки на посты на пикабу по теме шума / вибрации / гула в квартире, которые собрал в процессе поиска источника шума
https://pikabu.ru/story/strannyie_vibratsii_v_komnate_8707862
https://pikabu.ru/story/neizvestnaya_vibratsiya_v_kvartire_6428099
https://pikabu.ru/story/otvet_na_post_strannyie_vibratsii_v_komnate_8710036
https://pikabu.ru/story/strannyie_vibratsii_v_komnate_8707862?cid=221024643
https://pikabu.ru/story/vibratsiya_v_kvartire__pomogite_7634580
https://pikabu.ru/story/neobyasnimyiy_gul_v_kvartire_7714889
https://pikabu.ru/story/pomogite_sovetom_pozhaluysta_v_kvartire_stoit_nevyinosimyiy_gul_8724462
https://pikabu.ru/story/shum_v_kvartire_poka_ne_resheno_6475810
https://pikabu.ru/story/nizkochastotnyiy_gul_v_kvartire__istoriya_so_schastlivyim_kontsom_10248616#comments
Понимаю, что сарказм, но хотел бы добавить, что если заменить "точно знают, что этот код делает" на "точно знают, что этот код должен делать", то это уже похоже на правду.
За обзор некоторых инструментов спасибо. Но если по сути задачи, то разве не очевидно, что кастомизация мельчайших деталей не будет доступна в большинстве BI-инструментов? На мой взгляд, у них цель немного другая: покрыть 99% потребностей в визуализации. Для всего остального есть D3.js, ggplot2 и тд и тп
Вот пример кода на R с использованием ggplot2:
Он не отрисовывает в точности как в примере из статьи, но дальше там можно продолжать настраивать положения заголовков, параметры подписей осей, шрифты, параметры сетки, цвета линии трендов и даже модель для линии трендов (не обязательно линейную).
Если хочется добавить сопроводительный текст, то можно обернуть это все в R Markdown.
Скрытый текст
Первый пункт из Полезных советов на мой взгляд спорный. Это две отдельные проблемы, которые не обязательно противопоставлять. А вот второй пункт отлично дополняется цитатой из той же DAMA DMBOK
Спустя 4 года ссылки все еще рабочие!)
Делаю локальную копию одного сайта, который обновлялся в период с 2009 по 2017 год, но пока все еще доступен. Обратил внимание, что половина ссылок уже невалидны (собственно, почему и зашел перечитать этот пост).
Ну и какой тогда смысл во внешних ссылках, если срок их жизни меньше десятка лет?..
Кажется, что сейчас на практике решение этой проблемы сводится только к https://web.archive.org/.
История с тем, что решение через RANK кто-то может считать единственно верным, мне кажется немного натянутой.
Вообще, сам тест действительно очень древний, мне он тоже попадался. Раскопки привели к статье на хабре аж 2013 года: https://habr.com/ru/articles/181033/
А самое забавное, что она опубликована 27 мая, как и тест на сайте jitbit, если смотреть через веб-архив: http://web.archive.org/web/20130607185217/https://www.jitbit.com/news/181-jitbits-sql-interview-questions/
Вот только наборы задач в статье на хабре и на сайте jitbit отличаются, совпадают только 4 задачи, включая задачу с поиском сотрудников с максимальной зарплатой (идет под номером 2).
Так вот дело в том, что в оригинальной статье приведено как раз другое решение:
Вот я почему-то думал, что там планировщик хитрее и не будет предварительно запихивать все в оперативную память
Честно говоря, в таком случае я даже не знаю, зачем мне был бы нужен DuckDB, обошелся бы polars
Что-то сложнее COUNT(*) пробовали запускать? У меня вот как-то не сложилось. Натравил на директорию с parquet-файлами. Нужно было воспроизвести логику с DENSE_RANK и GROUP BY, запрос все время вылетал по памяти. Один из вариантов запросов для решения той же проблемы наоборот стал вечно крутиться. Пришлось обрабатывать все файлы в цикле и склеивать каждый новый файл с результатами обработки всех предыдущих. Особо деталей не приведу, так как было давно, но суть в том, что была надежда просто написать SQL и получить результат, но магии не случилось, поэтому пришлось писать код.
Про дэшборд написал в том плане, что система связанных DQ-дэшбордов позволяет видеть состояние на всех уровнях без дополнительных усилий. Например, DQ-дэшборд для инцидентов позволяет с одного взгляда понять, где что пошло не так. Его можно обогатить всякой сопутствующей информацией, чтобы DQ-аналитику не приходилось искать ее самостоятельно (история инцидентов, документация, ETL и тд). Это не роботизация, но тоже экономит кучу времени.
С другой стороны да, понятно, что скорее это делается в первую очередь, а затем идет уже более сложная автоматизация.
Даже добавить особо нечего...был очень похожий опыт в другом телеком-операторе. Точно также пришло осознание необходимости оптимизации и автоматизации вместо масштабирования команды.
Не в курсе, есть ли у вас такие наработки, но еще можно двигаться в сторону DQ-дэшбордов и интеграции с каталогом данных.
Для городов это не актуально, а мне были нужны именно они, без пгт и тд
Повторяющихся названий городов не так много и они в разных регионах
Будучи младшим специалистом работал с рядом задач, в которых фигурировала сущность "Город". Чем больше я над ними работал, тем меньше понимал, что такое город и для чего он вообще нужен. В итоге для себя вопрос закрыл обработкой результатов переписи населения. Причем это тоже задача не из разряда эксельки распарсить. Там и ошибки и опечатки и изменения перечня городов год к году. Получился список вида: Год, Код региона, Название города, Население. Потом через сервис геокодирования получил еще координаты центров городов. Этого оказалось достаточно.
На сайте Росстата есть несколько разделов: Статистика / Переписи населения или Статистика / Официальная статистика / Население. Но ни там ни там не будет подробной информации по годам. Архивы по годам лежат в: Публикации / Каталог публикаций / Численность населения Российской Федерации по муниципальным образованиям.