3D-карта вместо инстинктов: как робот учится ползать и прыгать
В Гонконге разработали технологию для передвижения четвероногих роботов. Теперь они почти как настоящие животные способны автономно преодолевать экстремально сложные препятствия. Роботы находят обходные пути там, где кажется, что пройти невозможно. Как это стало возможно и какие возможности открывает новая технология?
Читать: https://habr.com/ru/companies/cloud4y/articles/965758/
#ru
@big_data_analysis | Другие наши каналы
В Гонконге разработали технологию для передвижения четвероногих роботов. Теперь они почти как настоящие животные способны автономно преодолевать экстремально сложные препятствия. Роботы находят обходные пути там, где кажется, что пройти невозможно. Как это стало возможно и какие возможности открывает новая технология?
Читать: https://habr.com/ru/companies/cloud4y/articles/965758/
#ru
@big_data_analysis | Другие наши каналы
Сверхбыстрые запросы: принципы Compaction при разделении хранения и вычислений в StarRocks и руководство по тюнингу
StarRocks при каждом импорте данных создаёт новую версию, что со временем приводит к росту числа мелких файлов и падению эффективности запросов. Фоновый процесс Compaction объединяет версии, устраняет дубликаты и сокращает количество I/O. В материале разобраны: архитектура Compaction в режиме разделения хранения и вычислений (FE — Scheduler, BE/CN — Executor), диспетчеризация по Partition и Tablet, критерии безопасной очистки данных, а также практики тюнинга. Показано, как смотреть Compaction Score на уровне Partition, отслеживать и отменять задачи, и какие параметры FE/BE/CN действительно влияют на производительность (compact_threads, lake_compaction_max_tasks и др.). Отдельно затронут мониторинг и алерты в Grafana/Prometheus. Текст ориентирован на инженеров DWH/OLAP и эксплуатацию высоконагруженных систем хранения данных.
Читать: https://habr.com/ru/articles/966322/
#ru
@big_data_analysis | Другие наши каналы
StarRocks при каждом импорте данных создаёт новую версию, что со временем приводит к росту числа мелких файлов и падению эффективности запросов. Фоновый процесс Compaction объединяет версии, устраняет дубликаты и сокращает количество I/O. В материале разобраны: архитектура Compaction в режиме разделения хранения и вычислений (FE — Scheduler, BE/CN — Executor), диспетчеризация по Partition и Tablet, критерии безопасной очистки данных, а также практики тюнинга. Показано, как смотреть Compaction Score на уровне Partition, отслеживать и отменять задачи, и какие параметры FE/BE/CN действительно влияют на производительность (compact_threads, lake_compaction_max_tasks и др.). Отдельно затронут мониторинг и алерты в Grafana/Prometheus. Текст ориентирован на инженеров DWH/OLAP и эксплуатацию высоконагруженных систем хранения данных.
Читать: https://habr.com/ru/articles/966322/
#ru
@big_data_analysis | Другие наши каналы
Как мы тестируем RT.Warehouse: тестовые сценарии, сбор и анализ метрик по результатам тестирования
Привет, Хабр! Меня зовут Ольга Проскурякова, я лид направления тестирования в компании TData. Эта статья - моя первая публикация на Хабре. Буда рада поделиться своим опытом.
Платформа, которую разрабатывает TData – это комплексное решение для работы с большими данными: сбор, управление, хранение, визуализация и анализ. В центре платформы – десяток ключевых продуктов. Все они проходят проверку нашей командой тестировщиков. Сегодня я расскажу о том, как мы тестируем один из них.
Для наглядности опишу предметную область тестирования. Это продукт RT.Warehouse - массивно-параллельная СУБД для построения хранилищ данных, разработанная на базе Greenplum.
RT.Warehouse обеспечивает высокую степень производительности и отказоустойчивости благодаря гибкости горизонтального масштабирования, использованию в ядре продвинутого оптимизатора запросов и адаптации архитектуры для хранения и обработки больших массивов данных.
Читать: https://habr.com/ru/companies/rostelecom/articles/966416/
#ru
@big_data_analysis | Другие наши каналы
Привет, Хабр! Меня зовут Ольга Проскурякова, я лид направления тестирования в компании TData. Эта статья - моя первая публикация на Хабре. Буда рада поделиться своим опытом.
Платформа, которую разрабатывает TData – это комплексное решение для работы с большими данными: сбор, управление, хранение, визуализация и анализ. В центре платформы – десяток ключевых продуктов. Все они проходят проверку нашей командой тестировщиков. Сегодня я расскажу о том, как мы тестируем один из них.
Для наглядности опишу предметную область тестирования. Это продукт RT.Warehouse - массивно-параллельная СУБД для построения хранилищ данных, разработанная на базе Greenplum.
RT.Warehouse обеспечивает высокую степень производительности и отказоустойчивости благодаря гибкости горизонтального масштабирования, использованию в ядре продвинутого оптимизатора запросов и адаптации архитектуры для хранения и обработки больших массивов данных.
Читать: https://habr.com/ru/companies/rostelecom/articles/966416/
#ru
@big_data_analysis | Другие наши каналы
👍1
Как создать динамическую сводную таблицу на Power BI Report Server
Всем привет! Меня зовут Максим Кушнер, и я занимаюсь BI-разработкой в команде HR-аналитики «Лемана Тех». Дашборды, которые создаёт и поддерживает наша команда, охватывают широкий круг HR-процессов компании, в т. ч. состояние и движение персонала, расходы на персонал, продуктивность, контроль использования рабочего времени, обучение, профессиональное развитие, вовлечённость, внутренние конкурсы, различные рейтинги и др. Пользователями дашбордов могут быть все 40 000+ сотрудников нашей компании – от топ-менеджмента до любого работника в магазине. Соответственно, количество различных срезов данных и бизнес-показателей в дашбордах может исчисляться десятками.
И очень часто наши коллеги говорят: «Ваш дашборд, конечно, классный, но нам хочется самим покрутить данные». Другими словами, пользователи хотят построить аналитику в нужных им разрезах и структуре, которые не предусмотрены разработчиком по умолчанию.
Если не пытаться решить эту боль пользователя, то он просто экспортирует сырые данные из дашборда в Excel, где использует инструмент сводных таблиц (pivot tables) для выстраивания аналитики в нужном ему виде. Но тогда встаёт вопрос: зачем нужен такой дашборд (и его разработчики), если пользователь использует его как перевалочный пункт, а основную ценность извлекает из другого инструмента?
Читать: https://habr.com/ru/companies/lemana_tech/articles/965670/
#ru
@big_data_analysis | Другие наши каналы
Всем привет! Меня зовут Максим Кушнер, и я занимаюсь BI-разработкой в команде HR-аналитики «Лемана Тех». Дашборды, которые создаёт и поддерживает наша команда, охватывают широкий круг HR-процессов компании, в т. ч. состояние и движение персонала, расходы на персонал, продуктивность, контроль использования рабочего времени, обучение, профессиональное развитие, вовлечённость, внутренние конкурсы, различные рейтинги и др. Пользователями дашбордов могут быть все 40 000+ сотрудников нашей компании – от топ-менеджмента до любого работника в магазине. Соответственно, количество различных срезов данных и бизнес-показателей в дашбордах может исчисляться десятками.
И очень часто наши коллеги говорят: «Ваш дашборд, конечно, классный, но нам хочется самим покрутить данные». Другими словами, пользователи хотят построить аналитику в нужных им разрезах и структуре, которые не предусмотрены разработчиком по умолчанию.
Если не пытаться решить эту боль пользователя, то он просто экспортирует сырые данные из дашборда в Excel, где использует инструмент сводных таблиц (pivot tables) для выстраивания аналитики в нужном ему виде. Но тогда встаёт вопрос: зачем нужен такой дашборд (и его разработчики), если пользователь использует его как перевалочный пункт, а основную ценность извлекает из другого инструмента?
Читать: https://habr.com/ru/companies/lemana_tech/articles/965670/
#ru
@big_data_analysis | Другие наши каналы
Forwarded from Типичный программист
С кем знакомятся типичные программисты: 2D-тян или живая девушка?
Согласно недавним исследованиям Vantage Point Counseling Services, треть американцев хотя бы раз состояла в романтических отношениях с ИИ. Появилось даже приложение Loverse для виртуальных знакомств, где вместо реальных людей роль партнёров выполняют чат-боты с искусственным интеллектом.
Мы решили провести своё исследование и выяснить где и с кем сегодня знакомятся пользователи стран СНГ. Пожалуйста, пройдите наш небольшой опрос. Это поможет нашему исследованию.
Пройти опрос.
Согласно недавним исследованиям Vantage Point Counseling Services, треть американцев хотя бы раз состояла в романтических отношениях с ИИ. Появилось даже приложение Loverse для виртуальных знакомств, где вместо реальных людей роль партнёров выполняют чат-боты с искусственным интеллектом.
Мы решили провести своё исследование и выяснить где и с кем сегодня знакомятся пользователи стран СНГ. Пожалуйста, пройдите наш небольшой опрос. Это поможет нашему исследованию.
Пройти опрос.
👎1
Как устроена ценуза изнутри. На примере слитого китайского фаерволла (блокировки Tor, VPN, анализ трафика)
Продолжаем нашу серию статей с разбором работы Китайского Firewall'а (GFW). В этой статье углубимся в техническую часть этой системы
Читать: https://habr.com/ru/companies/femida_search/articles/966980/
#ru
@big_data_analysis | Другие наши каналы
Продолжаем нашу серию статей с разбором работы Китайского Firewall'а (GFW). В этой статье углубимся в техническую часть этой системы
Читать: https://habr.com/ru/companies/femida_search/articles/966980/
#ru
@big_data_analysis | Другие наши каналы
🔥1
Проанализировал 3000 n8n workflow и выделил топ-40 нод. Забирайте в виде pdf
Недавно меня попросили мои студенты сделать для них какой-нибудь гайд по самым популярным нодам в n8n, чтобы быстро погрузить в их разнообразие.
Чтобы моя подборка была действительно из самых часто используемых n8n нод - я спарсил большую коллекцию из 3000 workflows. Разбил ее на ноды. Удалил ноды, которые редко используются в СНГ. Добавил к каждой ноде короткое описание и примеры использования, в итоге получился cheat sheet гайд на почти 40 n8n нод в виде pdf - забирайте pdf по ссылка с гугл драйва!
Забрать pdf файл с результатом анализа
Читать: https://habr.com/ru/companies/datafeel/articles/966656/
#ru
@big_data_analysis | Другие наши каналы
Недавно меня попросили мои студенты сделать для них какой-нибудь гайд по самым популярным нодам в n8n, чтобы быстро погрузить в их разнообразие.
Чтобы моя подборка была действительно из самых часто используемых n8n нод - я спарсил большую коллекцию из 3000 workflows. Разбил ее на ноды. Удалил ноды, которые редко используются в СНГ. Добавил к каждой ноде короткое описание и примеры использования, в итоге получился cheat sheet гайд на почти 40 n8n нод в виде pdf - забирайте pdf по ссылка с гугл драйва!
Забрать pdf файл с результатом анализа
Читать: https://habr.com/ru/companies/datafeel/articles/966656/
#ru
@big_data_analysis | Другие наши каналы
Добавляем MapReduce в этот наш SQL: генераторы на основе курсоров
Вот уже который год я потихоньку разрабатываю SQL-ный движок на основе Apache Spark, специализированный под задачи ETL. И хотя диалект языка изначально называется «Transform Definition Language», писать трансформации данных непосредственно на нём самом было до сих пор невозможно. Вместо этого на фазе Transform предполагалось использовать подключаемые модули, которые рантайм интерпретатора предоставляет из Java classpath.
Это очень эффективный с точки зрения производительности, но довольно долгий с точки зрения внедрения, и дорогой в разработке способ. Сначала трансформацию надо описать формально в виде статьи-whitepaper'а (это делает data scientist), потом написать прототип на Python (ответственность data analyst), отладиться на сэмпле реальных данных (тоже аналитик), и тогда уже делать и оптимизировать финальную имплементацию на Java с использованием низкоуровневого API Spark (собственно, задача разработчика). Неудобно.
Нельзя ли его как-нибудь сократить? Например, дать аналитикам инструмент для написания трансформаций непосредственно в самом SQL, вынеся некоторую часть функциональности MapReduce как разновидность итерирующих функций? Можно, конечно!
Давайте узнаем, как именно
Читать: https://habr.com/ru/articles/958362/
#ru
@big_data_analysis | Другие наши каналы
Вот уже который год я потихоньку разрабатываю SQL-ный движок на основе Apache Spark, специализированный под задачи ETL. И хотя диалект языка изначально называется «Transform Definition Language», писать трансформации данных непосредственно на нём самом было до сих пор невозможно. Вместо этого на фазе Transform предполагалось использовать подключаемые модули, которые рантайм интерпретатора предоставляет из Java classpath.
Это очень эффективный с точки зрения производительности, но довольно долгий с точки зрения внедрения, и дорогой в разработке способ. Сначала трансформацию надо описать формально в виде статьи-whitepaper'а (это делает data scientist), потом написать прототип на Python (ответственность data analyst), отладиться на сэмпле реальных данных (тоже аналитик), и тогда уже делать и оптимизировать финальную имплементацию на Java с использованием низкоуровневого API Spark (собственно, задача разработчика). Неудобно.
Нельзя ли его как-нибудь сократить? Например, дать аналитикам инструмент для написания трансформаций непосредственно в самом SQL, вынеся некоторую часть функциональности MapReduce как разновидность итерирующих функций? Можно, конечно!
Давайте узнаем, как именно
Читать: https://habr.com/ru/articles/958362/
#ru
@big_data_analysis | Другие наши каналы
Глубокое сравнение StarRocks и ClickHouse в задачах аналитики в реальном времени и соображения по выбору
Статья представляет техническое сравнение StarRocks и ClickHouse для real‑time аналитики. На идентичных AWS‑кластерах с набором ~1 ТБ (Parquet, >3 млрд строк) смоделированы параллельные нагрузки (k6) и непрерывный поток UPSERT из PostgreSQL через CDC. Оцениваются субсекундная Latency, согласованность обновлений, полнофункциональные JOIN и операционная простота (TCO). ClickHouse с Replacing/CollapsingMergeTree обеспечивает eventual consistency и нередко требует FINAL/внешних потоковых компонентов. StarRocks с Primary Key Model дает нативный UPSERT с мгновенной видимостью изменений и асинхронным Compaction. В бенчмарках StarRocks показал до ~40% преимущество в длинных запросах, лучший p99/QPS и стабильность (без HTTP 5xx). В контексте Lakehouse StarRocks сильнее за счет внешних таблиц и записи в Apache Iceberg. Рекомендации: ClickHouse — для append‑only сценариев; StarRocks — для real‑time аналитики с частыми обновлениями.
Читать: https://habr.com/ru/articles/967214/
#ru
@big_data_analysis | Другие наши каналы
Статья представляет техническое сравнение StarRocks и ClickHouse для real‑time аналитики. На идентичных AWS‑кластерах с набором ~1 ТБ (Parquet, >3 млрд строк) смоделированы параллельные нагрузки (k6) и непрерывный поток UPSERT из PostgreSQL через CDC. Оцениваются субсекундная Latency, согласованность обновлений, полнофункциональные JOIN и операционная простота (TCO). ClickHouse с Replacing/CollapsingMergeTree обеспечивает eventual consistency и нередко требует FINAL/внешних потоковых компонентов. StarRocks с Primary Key Model дает нативный UPSERT с мгновенной видимостью изменений и асинхронным Compaction. В бенчмарках StarRocks показал до ~40% преимущество в длинных запросах, лучший p99/QPS и стабильность (без HTTP 5xx). В контексте Lakehouse StarRocks сильнее за счет внешних таблиц и записи в Apache Iceberg. Рекомендации: ClickHouse — для append‑only сценариев; StarRocks — для real‑time аналитики с частыми обновлениями.
Читать: https://habr.com/ru/articles/967214/
#ru
@big_data_analysis | Другие наши каналы