Однако при более внимательном анализе возникает существенное противоречие.
«90,7% используют английский в обучении, но при этом 57,4% оценивают свой уровень как начальный»
Не вижу никакого противоречия.
Если человек идет на техническую специальность, то с большей вероятностью у него есть способности к технической части, чем к иностранному языку.
Как ни крути - это второстепенный навык. Точно также какому-нибудь бэкенд разработчику необходим навык SQL, но точно также он оценит навык как начальный.
Как у вас устроено создание новых версий схем в Schema Registry? Новая версия согласуется командой Databus, или всё в руках команд сервисов, отправляющих события? Если первое, то сразу делаются схемы Dev/Stage/Prod или последовательно сначала только Dev, потом проверка данных по новой версии схемы на Dev и только потом Stage/Prod? Или как-то еще иначе?
к 2028 году 1% мировой вычислительной мощности будет находиться на орбите
Еще бредовее, чем высадка человека на Марс в {выберите любой год, озвученный Маском в прошлом или будущем} году. Ставлю, что и к 2128 году не будет.
Радиаторы размером с квартал, невозможность обслуживания, температурная нестабильность, излучение/частицы, отсутствие хоть каких-то необходимых технологий... И ладно еще было бы зачем (чего-то, чего нельзя было бы получить на Земле, как с некоторыми космическими телескопами), дак тут и этого нет.
Честно говоря, кажется, что описано что-то из фантастического мира сферических розовых пони в вакууме.
1. А оно точно нужно? Бизнес действительно не может жить без этого костыля прямо сейчас? Или мы просто боимся сказать «нет» и потратить время на нормальное решение?
Половина «срочных» временных решений нужна не бизнесу, а чтобы отчитаться о закрытии тикета в спринте.
Ответ менеджера в реальном мире: Да, естественно мы боимся потратить время, и нам надо закрыть задачу/проект.
2. Мы знаем, как сделать правильно? У нас есть четкое понимание, как должна выглядеть архитектура итогового решения? Все ли блоки мы можем реализовать?
Если правильное решение непонятно, то «временное» — это не решение, а отсрочка провала. Вы не покупаете себе время, а закладываете мину.
Ответ менеджера в реальном мире (да и мой в этом случае был бы таким же): Естественно, если мы сейчас знаем только одно решение, которое мы можем сделать сейчас и закрыть боль заказчика, то делаем это решение а потом думаем.
Мое любимое - это когда врут, не подозревая, что врут: stacked графики (когда каждая величина откладывается не от нуля, а вверх от предыдущей линии). На скриншоте значение оранжевой величины всегда неизменно, а кажется, что оно сильно падало в промежутке от x=4 до x=5.
Но есть и неочевидный минус офиса — «ложная социализация». «Люди в офисе могут тебя задерживать. Работа тебя не развивает, но люди привязали. Ты не хочешь уходить, потому что в офисе есть "родные", с которыми ты проводишь по 8 часов. Это ловушка комфорта».
Разве не этого хотели в самом начале, когда обсуждали плюшки/зп/коллектив и сошлись на коллективе и атмосфере? Неясно, почему в этом описании социализация ложная, а комфорт иллюзорный?
Сигнал №3: Размытые цели. «Матрицы компетенций и цели на квартал нужны, чтобы твой рост не зависел от настроения начальника. Ты сможешь прийти и сказать: "Я сделал X, Y, Z — я готов повысить свой грейд". Если цели ставишь ты сам себе — это фикция».
У нас за несколько лет пробовали несколько систем целей - ни один лично мне не зашел. Они все были фикцией. Независимо от того, какие были цели, если прилетит новый проект с высоким приоритетом - ты делаешь его. И оценивают по тому, что оказалось важно по факту, какую реальную пользу ты принес, а не по тому, что написано в целях. И это норм, а придумывание целей - лишняя трата времени.
По умолчанию ClickHouse использует для сжатия алгоритм zstd
Это в ClickHouse Cloud. В обычном LZ4 по умолчанию. В Yandex Cloud не в курсе. zstd в среднем экономит ~30% диска по сравнению с lz4, но больше кушает проц.
Партицирование по месяцам позволяет сэкономить время при обработке запросов — не загружать в память те файлы, которые заведомо не относятся к указанному в запросе интервалу времени.
Тут странное написано. Партиции не для этого, а для манипуляции данными (чтобы, например, по TTL дропать целиком месяц и т.п.). Если вы сделаете одну партицию, а на первое место в order by добавите ключ, по которому были партиции, то запросы станут быстрее. Вы этого, скорее всего, не заметите - заметно только если партиций очень много. Файлы в память не загружаются. Наоборот на каждый файл открывается буфер 2МБ, соответственно больше файлов - больше памяти. Но опять же это заметно только если очень много партиций (например, у вас партиции по дням, данные за много лет, много колонок, и вы хотите вставить/прочитать данные, в которых есть все даты). Не то чтобы я рекомендовал вам что-то менять в таблице, просто этот абзац вводит в заблуждение.
date_created Date32, hour_created Int16,
Мелочь, но наверное, вам хватит Date и Int8.
allow_nullable_key = 1
лучше уберите это. Однажды может очень больно выстрелить в ногу. Это хотели выпилить вовсе, но почему-то не выпилили.
После перехода на ClickHouse запрос стал выполняться 20-25 минут.
Попробуйте в конец запроса дописать settings optimize_aggregation_in_order = 1;. *В clickhouse есть countIf().
ценность для сообщества... Open-source данные... под лицензией MIT...
Вообще-то данные предоставлены в нарушение лицензии сервиса, откуда вы из взяли. Так вы не приносите ценность open-source сообществу, а вредите ему показывая ворованные данные в этом сообществе.
2.1 Platform access license
Subject to the terms of this Agreement and payment of applicable Fees, Twelve Data grants Customer a limited, revocable, non-exclusive, non-transferable, non-sublicensable license to access and use the Platform solely for Internal Use during the subscription term, except as otherwise expressly permitted by your Subscription Tier, Data add-ons, or a separate written agreement with Twelve Data.
"Internal Use" means use solely for Customer's internal business purposes and not for redistribution or external commercial purposes.
Log, как ни странно, не для логов - это скорее как временные маленькие таблицы. Для логов обычные *MergeTree, плюс можно пробовать всякие новые фичи типа полнотекстовых индексов.
Спасибо за читабельное описание sequenceMatch/sequenceCount/windowFunnel, а то иногда оно вроде надо было, но в доке как-то неочевидно описано, что я забивал разбираться надо оно мне или нет.
В комментариях расскажите, какие "непопулярные" функции кликхаус успростили вам жизнь.
Мой фаворит cityHash64(). Когда надо сджойнить или посчитать юники по строкам или по набору колонок, а сами значения этих колонок не нужны, то гораздо дешевле загнать всё это в cityHash64() (лучше cityHash64(tuple()), чтобы с null норм было) и посчитать по одному целому числу, чем по тяжелым строкам или набору колонок. Тоже самое при проверке на IN: cityHash64((col1, col2)) IN (select cityHash64((col1, col2)) ...). И когда сэмплирование надо сделать, тоже пригождается: where cityHash64(id) % 100 < 10.
Ну и assumeNotNull(), избавляющий от злобного Nullable (осторожно, есть нюансы с Nullable(Enum)).
То есть теперь можно писать красиво JOIN, и оно будет не хуже, чем dictGet‑функции.
Сомнительное утверждение. Это побуждает писать условия на where уже после джойна, что далеко не всегда оптимизируется. Для удобства, и чтобы было "красиво", мы создавали UDF-функции вместо прямого вызова словаря. Типа ipToCountry() - это читабельно, удобно компактно писать, плюс подсказки IDE-шки с этим работают в отличие от dictGet(), плюс внутрь UDF можно дополнительно зашить приведение типов и т.п.
Еще, наверное, стоит упомянуть, что clickhouse некорректно учитывает память, занимаемую словарями, и что можно подкрутить MAX_LOAD_FACTOR для экономии памяти, если такая необходимость есть.
Создадим файл ./clickhouse_init/init-db.sql и подготовим в нем скрипт для создания необходимых таблиц в базе данных: ..duration Float64, ..duration Float64, ... ..duration Float64
Вам где-то надо больше 7 значащих цифр в точности продолжительности событий? Очень сомневаюсь. Скорее всего вы просто так тратите x2 места на диске, x2 памяти на обработку и x2 сетевого трафика (то есть x2 денег работодателя) и пока не замечаете проблем с производительностью. При этом у коллег всё ok:
Да, в нашей внутренней системе мы собираем еще больше данных, но принципы анализа остаются теми же. ..duration Float32, ..duration Float32, ... ..duration Float32
(еще как вариант использовать везде для duration миллисекунды и UInt32/Int32, если ~месяца продолжительности хватает)
CREATE TABLE IF NOT EXISTS default.test_metrics ... run_timestamp DateTime64(3), nodeid String, ... ORDER BY (run_timestamp, nodeid);
Тут вероятно оптимальнее будет что-то вроде: ORDER BY (toDate(run_timestamp), nodeid, run_timestamp) или ORDER BY (nodeid, run_timestamp). Вообще удобно когда отдельная колонка с Date есть (не просто так оно в системных таблицах используется, хотя может показаться избыточным) - она сжимается практически в ноль, и удобнее везде использовать в готовом виде, чем постоянно приводить DateTime.
Немного оффтоп, но если такой упор на вело/СИМ (а на мой взгляд яндекс и раньше никак не подходил для вело), то позволю себе посоветовать заглянуть на https://bikerouter.de. Там 100500 разных профилей построения маршрутов для разных предпочтений катания. Мой любимый "Trekking-Fast-wet" (в основном дороги, но можно и на тропинку съехать). Похожи на него, но поменьше приоритет у дорог: "Randonneur" и "Trekking". По тротуарчикам, наверное, "MTB standard". Наоборот только по дорогам "Road bike" и совсем хардкор "Road Bike (Asia Pacific)".
А, нет - всё-таки зависит от масштаба в браузере, но нетривиально. Если при открытии страницы не 100%, то даже если потом поставить 100%, не перезагружая страницу, то зашакалено даже если масштаб карты туда-сюда двигать. А если поставить масштаб в браузере 100% и перезагрузить страницу, то не зашакалено даже если потом масштаб в браузере изменить и менять масштаб карты.
Я сейчас проверил. У меня как у автора поста всё зашакалено в chrome и vivaldi, а в яндекс-браузере вполне читабельно. Экран 27" 2560x1440, Windows 10, масштаб системы 100%. От масштаба браузера не зависит.
Слева Яндекс-браузер, справа chrome
*масштаб не удалось в точности одинаковый выставить на карте - всегда отличается немного, несмотря на 100% в обоих браузерах.
Не вижу никакого противоречия.
Если человек идет на техническую специальность, то с большей вероятностью у него есть способности к технической части, чем к иностранному языку.
Как ни крути - это второстепенный навык. Точно также какому-нибудь бэкенд разработчику необходим навык SQL, но точно также он оценит навык как начальный.
Что-то такой упор на число поворотов и оптимальные алгоритмы. Но кажется, что в первую очередь всё упирается на механическую скорость и точность.
Как у вас устроено создание новых версий схем в Schema Registry? Новая версия согласуется командой Databus, или всё в руках команд сервисов, отправляющих события? Если первое, то сразу делаются схемы Dev/Stage/Prod или последовательно сначала только Dev, потом проверка данных по новой версии схемы на Dev и только потом Stage/Prod? Или как-то еще иначе?
Это ничего не изменит в плане перспектив вывода ЦОД на орбиту.
появлением
Еще бредовее, чем высадка человека на Марс в {выберите любой год, озвученный Маском в прошлом или будущем} году. Ставлю, что и к 2128 году не будет.
Радиаторы размером с квартал, невозможность обслуживания, температурная нестабильность, излучение/частицы, отсутствие хоть каких-то необходимых технологий... И ладно еще было бы зачем (чего-то, чего нельзя было бы получить на Земле, как с некоторыми космическими телескопами), дак тут и этого нет.
Честно говоря, кажется, что описано что-то из фантастического мира сферических розовых пони в вакууме.
Ответ менеджера в реальном мире: Да, естественно мы боимся потратить время, и нам надо закрыть задачу/проект.
Ответ менеджера в реальном мире (да и мой в этом случае был бы таким же): Естественно, если мы сейчас знаем только одно решение, которое мы можем сделать сейчас и закрыть боль заказчика, то делаем это решение а потом думаем.
Мое любимое - это когда врут, не подозревая, что врут: stacked графики (когда каждая величина откладывается не от нуля, а вверх от предыдущей линии). На скриншоте значение оранжевой величины всегда неизменно, а кажется, что оно сильно падало в промежутке от x=4 до x=5.
Разве не этого хотели в самом начале, когда обсуждали плюшки/зп/коллектив и сошлись на коллективе и атмосфере? Неясно, почему в этом описании социализация ложная, а комфорт иллюзорный?
У нас за несколько лет пробовали несколько систем целей - ни один лично мне не зашел. Они все были фикцией. Независимо от того, какие были цели, если прилетит новый проект с высоким приоритетом - ты делаешь его. И оценивают по тому, что оказалось важно по факту, какую реальную пользу ты принес, а не по тому, что написано в целях. И это норм, а придумывание целей - лишняя трата времени.
Это в ClickHouse Cloud. В обычном LZ4 по умолчанию. В Yandex Cloud не в курсе. zstd в среднем экономит ~30% диска по сравнению с lz4, но больше кушает проц.
Тут странное написано. Партиции не для этого, а для манипуляции данными (чтобы, например, по TTL дропать целиком месяц и т.п.). Если вы сделаете одну партицию, а на первое место в order by добавите ключ, по которому были партиции, то запросы станут быстрее. Вы этого, скорее всего, не заметите - заметно только если партиций очень много. Файлы в память не загружаются. Наоборот на каждый файл открывается буфер 2МБ, соответственно больше файлов - больше памяти. Но опять же это заметно только если очень много партиций (например, у вас партиции по дням, данные за много лет, много колонок, и вы хотите вставить/прочитать данные, в которых есть все даты). Не то чтобы я рекомендовал вам что-то менять в таблице, просто этот абзац вводит в заблуждение.
Мелочь, но наверное, вам хватит Date и Int8.
лучше уберите это. Однажды может очень больно выстрелить в ногу. Это хотели выпилить вовсе, но почему-то не выпилили.
Попробуйте в конец запроса дописать
settings optimize_aggregation_in_order = 1;. *В clickhouse есть countIf().Две камеры (одна обычная, вторая сзади-сбоку) не решают проблему собесов? По крайней мере должно быть сильно труднее читерить.
Вообще-то данные предоставлены в нарушение лицензии сервиса, откуда вы из взяли. Так вы не приносите ценность open-source сообществу, а вредите ему показывая ворованные данные в этом сообществе.
Log, как ни странно, не для логов - это скорее как временные маленькие таблицы. Для логов обычные *MergeTree, плюс можно пробовать всякие новые фичи типа полнотекстовых индексов.
Спасибо за читабельное описание sequenceMatch/sequenceCount/windowFunnel, а то иногда оно вроде надо было, но в доке как-то неочевидно описано, что я забивал разбираться надо оно мне или нет.
Мой фаворит
cityHash64(). Когда надо сджойнить или посчитать юники по строкам или по набору колонок, а сами значения этих колонок не нужны, то гораздо дешевле загнать всё это вcityHash64()(лучшеcityHash64(tuple()), чтобы с null норм было) и посчитать по одному целому числу, чем по тяжелым строкам или набору колонок. Тоже самое при проверке на IN:cityHash64((col1, col2)) IN (select cityHash64((col1, col2)) ...). И когда сэмплирование надо сделать, тоже пригождается:where cityHash64(id) % 100 < 10.Ну и
assumeNotNull(), избавляющий от злобного Nullable (осторожно, есть нюансы с Nullable(Enum)).Сомнительное утверждение. Это побуждает писать условия на where уже после джойна, что далеко не всегда оптимизируется. Для удобства, и чтобы было "красиво", мы создавали UDF-функции вместо прямого вызова словаря. Типа ipToCountry() - это читабельно, удобно компактно писать, плюс подсказки IDE-шки с этим работают в отличие от dictGet(), плюс внутрь UDF можно дополнительно зашить приведение типов и т.п.
Еще, наверное, стоит упомянуть, что clickhouse некорректно учитывает память, занимаемую словарями, и что можно подкрутить MAX_LOAD_FACTOR для экономии памяти, если такая необходимость есть.
Вам где-то надо больше 7 значащих цифр в точности продолжительности событий? Очень сомневаюсь. Скорее всего вы просто так тратите x2 места на диске, x2 памяти на обработку и x2 сетевого трафика (то есть x2 денег работодателя) и пока не замечаете проблем с производительностью. При этом у коллег всё ok:
(еще как вариант использовать везде для duration миллисекунды и UInt32/Int32, если ~месяца продолжительности хватает)
Тут вероятно оптимальнее будет что-то вроде:
ORDER BY (toDate(run_timestamp), nodeid, run_timestamp)илиORDER BY (nodeid, run_timestamp). Вообще удобно когда отдельная колонка с Date есть (не просто так оно в системных таблицах используется, хотя может показаться избыточным) - она сжимается практически в ноль, и удобнее везде использовать в готовом виде, чем постоянно приводить DateTime.Немного оффтоп, но если такой упор на вело/СИМ (а на мой взгляд яндекс и раньше никак не подходил для вело), то позволю себе посоветовать заглянуть на https://bikerouter.de. Там 100500 разных профилей построения маршрутов для разных предпочтений катания. Мой любимый "Trekking-Fast-wet" (в основном дороги, но можно и на тропинку съехать). Похожи на него, но поменьше приоритет у дорог: "Randonneur" и "Trekking". По тротуарчикам, наверное, "MTB standard". Наоборот только по дорогам "Road bike" и совсем хардкор "Road Bike (Asia Pacific)".
А, нет - всё-таки зависит от масштаба в браузере, но нетривиально. Если при открытии страницы не 100%, то даже если потом поставить 100%, не перезагружая страницу, то зашакалено даже если масштаб карты туда-сюда двигать. А если поставить масштаб в браузере 100% и перезагрузить страницу, то не зашакалено даже если потом масштаб в браузере изменить и менять масштаб карты.
Я сейчас проверил. У меня как у автора поста всё зашакалено в chrome и vivaldi, а в яндекс-браузере вполне читабельно. Экран 27" 2560x1440, Windows 10, масштаб системы 100%. От масштаба браузера не зависит.
Слева Яндекс-браузер, справа chrome
*масштаб не удалось в точности одинаковый выставить на карте - всегда отличается немного, несмотря на 100% в обоих браузерах.
О, спасибо, оказывается можно это отключить разлогинившись:
Только можно вот это не делать, пожалуйста:
Они уже так на панорамах сделали.