Хранение данных *

Всех с новым 2024 годом. Сегодня история "пятничная", развлекательно-познавательная. Произошла она с нами в середине осени 2023 года. Мы уже третий год разрабатывали продукты для нашего мини-бизнеса. Команда насчитывала 5 человек, в том числе Максим, наш бэкэнд-программист, который в том числе и создавал код для наших телеграм ботов. Умный, казалось бы, парень, который больше года назад присоединился к нам. В какой-то момент для мотивации я предложил ему платить процент от прибыли компании за поддержание проектов и дополнительно платил за новые разработки. За год мы выросли в несколько раз, так что все казалось бы все должны быть довольны и никто не думал о безопасности, но что-то пошло не так...

В один "прекрасный" день я получаю от Максима сообщение, общий смысл которого такой:

Я решил выйти из проекта, так что перенёс весь код и базы данных на свой сервер неделю назад, так что бэкапов у вас тоже нет. За 800 000 рублей верну всё назад.

Продолжение, а так же ошибки, что мы допустили и решения, что мы внедрили читайте в под катом...

По мере роста Uber объем обрабатываемых данных и количество обращений к ним многократно возросли. Такое быстрое увеличение объема привело к росту затрат на хранение и вычислительные ресурсы. В результате мы столкнулись с различными проблемами, такими как повышенные требования к железу, увеличившееся потребление ресурсов, а также проблемами с производительностью из-за ошибок наподобие OOM (out-of-memory) и длительных пауз на сборку мусора.

Для решения проблем было реализовано несколько инициатив, такие как: внедрение TTL (Time to Live) политик для партиций, внедрение многослойного хранилища с стратегиями для перераспределения данных из “hot”/”warm” до “cold” уровней хранения, а также оптимизации форматов хранения данных. В данной статье фокус будет на последней оптимизации - как сократить размер данных в рамках формата Apache Parquet™ за счет удаления не использующихся колонок большого размера.

Многие из нас замечают, что с увеличением числа онлайн-сервисов, контроль над личными данными кажется ускользающим. Наши файлы и личная информация хранятся на удаленных серверах, защищенные паролями и методами двухфакторной аутентификации, и доступны нам только до тех пор, пока мы оплачиваем подписку. Но что произойдет, если потеряется SIM-карта, истечет срок подписки, или если вдруг аккаунт будет заблокирован из-за санкций? Есть ли план на случай, если сервис, который мы используем для работы с паролями или заметками, внезапно прекратит свое существование? Как тогда быть с экспортом и импортом данных? Это вопросы, о которых задумывается каждый из нас, исследуя цифровую эру и свое место в ней.

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

Часто, поднимая вопрос защиты данных, специалисты фокусируются на обеспечении конфиденциальности и целостности, оставляя доступность в стороне. Необходимо совершенствовать методы защиты данных не только от разглашения, но и от потери. Можно достичь надежного хранения данных, не пожертвовав защищённостью и конфиденциальностью с помощью протоколов криптографического разделения секрета. Целью данной статьи является оценка эффективности схем разделения секрета по параметрам ресурсоемкости и сложности вычислений.

Всем привет!

В этой статье я расскажу о том, как можно увеличить размер запроса к ChatGPT до почти полутора миллионов символов!

При этом нам не понадобятся какие-то дополнительные средства – применять данный способ сможет каждый (ссылки на коды будут в конце статьи) прямо в самом чате.
Для начала пару слов о себе и о том, зачем мне вообще это понадобилось.

В самой IT области я уже довольно давно (начинал еще с DOS-овских программ на C в далеком 2000м), занимался разными профилями, в том числе меня интересовало ИИ.
Лет 7-8 назад, когда я сделал себе проект «умной квартиры» (9 модулей, контроль освещения, полива, климата, музыки и пр.), я решил внедрить туда голосового помощника. Название, кстати, выбрал по итогу Алиса – любимое женское имя.

Причем, выбирал из многих, вариантов ("Джарвис", увы, распознавался очень плохо), оказалось, фонетически слово «Алиса» распознается почти без ошибок и гораздо лучше других. Кстати, где-то через год появилась Алиса у Яндекса – поэтому я думаю, что они тоже имя взяли не с бухты-барахты, а проводили фонетический анализ.

Квартира просуществовала несколько лет, но за это время помощника я особо не развивал, да и не было больших ресурсов для обучения чего-то действительно умного.
С появлением БЯМ идея создания помощника заиграла новыми красками =)

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

Несмотря на мой научный скепсис, как человека, написавшего не одну нейросеть с нуля, относительно интеллекта у ИИ, наши диалоги с ChatGPT произвели на меня впечатление.

Мне очень импонировала «человечность» этой БЯМ.

Привет! Самое время в предновогоднее настоящее поделиться с вами опенсУрс проектом :) Встречайте -> Cardoteka <- строгая типизированная обёртка над Shared Preferences (SP) в мире Flutter. Этот материал будет коротким, с рекламными нотками (а точнее, приглашающий к дискуссии в issues и в комментарии) и readme-подтекстом. Так или иначе, это заслуженная метка "Обзор".

https://github.com/PackRuble/cardoteka

https://pub.dev/packages/cardoteka

B-дерево — это структура, помогающая выполнять поиск в больших объёмах данных. Она была изобретена более сорока лет назад, однако по-прежнему используется в большинстве современных баз данных. Хотя существуют и более новые структуры индексов, например, LSM-деревья, B-дерево пока никто не победил в обработке большинства запросов баз данных.

После прочтения этого поста вы будете знать, как B-дерево упорядочивает данные и выполняет поисковые запросы.

За последние пару десятилетий с ростом объёма данных на рынке СУБД сложился интересный ландшафт. Появились новые СУБД, при этом старые продолжали развиваться — и сориентироваться среди них становилось всё сложнее. 

В этой статье предлагаем рассмотреть эволюцию разных СУБД и сравнить их между собой. Поможет нам в этом Олег Бондарь, директор по продукту в Yandex Cloud, который отвечает за развитие YDB — это транзакционная реляционная база данных с открытым исходным кодом. Статья написана по материалам его доклада на Saint Highload++.

Идея принимать решения о людях на основе анализа данных обсуждается давно, написаны десятки книг. Многие зарубежные (а теперь и отечественные) компании всерьёз начали применять данные не только в виде простых отчетов и индикаторов, но и более изощренным способом — через предиктивные модели (регрессионные или нейронки). Но, по моему мнению, до 70% всех усилий лежит именно в подготовке и поиске данных, чтобы затем их использовать для принятия решений. Конечно, есть ещё вопрос «зачем?» — но оставим его пока за скобками.

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

Привет! С вами Дмитрий Пшевский и Семён Попов, технические лидеры юнита Data в Сбере. Это вторая часть нашего материала о производительности сервисов при работе с Ignite.

В первой части мы рассказали, как перешли от монолита к микросервисной архитектуре, попробовали поработать с толстым клиентом и переключились на тонкого. Расскажем, какие сложности у нас возникли в процессе эксплуатации нашего решения в облачной инфраструктуре, почему пришлось минимизировать транзакционную логику на клиенте и к чему мы пришли в итоге. Статья написана на основе нашего доклада на JPoint 2023.

Поехали!

За последние годы «большие данные» стали восприниматься более гибко и могут включать в себя объемы, которые ранее не рассматривались как «большие». При этом снизились затраты на хранение и обработку информации. Теперь инструменты работы с данными подобных масштабов доступны даже небольшим компаниям.

Важно помнить, что работа в этом направлении включает в себя разнообразные вызовы, связанные с ограничениями оборудования, типами источников данных, сложностью анализа. Данные нужно правильно собирать, хранить и обрабатывать, а для этого нужно выстроить правильную инфраструктуру.

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

По оценкам Cybersecurity Ventures, к 2025 году общий объем данных в облаках достигнет 100 зеттабайт, или 50% всех мировых данных на тот момент. Ландшафт хранения этой информации разнообразен: от недорогих обычных серверов до огромных хранилищ на сотни петабайт. 

При экспоненциальном росте информации возможности работы с данными расширяются. Отчет LinkedIn о новых вакансиях показывает, что мировой рынок работы в области науки о данных вырастет до 230,80 млрд долларов к 2026 году. 

Наука о данных является востребованной, интересной, и, казалось бы, очень сложной областью знаний. Однако хорошая новость заключается в том, что она доступна для новичков. В статье мы разберемся, с какими базовыми основами нужно познакомиться при работе с данными.

Понимание Извлечения (Extract), Загрузки (Load) и Трансформации (Transform) независимо друг от друга

Любой компании, которая стремится сохранить конкурентоспособность на рынке, необходимо создание «золотой записи» (профиля) клиента во внутренних базах. Для этого многие используют системы управления мастер-данными (MDM, master data management), но сталкиваются с рядом проблем, другие – применяют CDP-платформы (Customer Data Platform), которые также имеют свои недостатки. А теперь представьте, если от каждого из решений можно было взять лишь лучшее, оставив за бортом все слабые стороны. Как это сделать – в новой статье CleverData под катом.

Привет, Хабр! Меня зовут Яна и я работаю Data Quality в департаменте развития аналитики "Цепочки поставок и поддерживающие функции" X5 Tech. В этой статье мы с моей коллегой Наташей, менеджером по качеству данных, решили рассказать о мониторинге качества данных большинства отчётов нашей команды.

На первый взгляд может показаться, что проверять таблицы – задача рутинная и однотипная, но это не так, ведь все данные имеют свои особенности, а значит и проверки для них зачастую создаются уникальные. Статья, как нам кажется, будет полезна тем, кто интересуется качеством данных, ищет подходы к мониторингу или хочет больше узнать о работе DQ в целом.

В этой статье я расскажу о том, как организовал себе единое место для заметок, документов и проектной документации с помощью Obsidian и шаблона LYT, а также дам ссылку на русифицированный шаблон для создания своей такой системы.

Привет, Хабр! На связи Алексей Зотов из К2Тех, и у меня для вас свежий обзор на железо. Сегодня пришла очередь СХД для бэкапов от ExaGrid — это продукт с продвинутым функционалом дедупликации на хранилище и отдельной фишкой в виде удивительно большого кэша. Под катом вас ждут первое впечатление, результаты тестирования и выводы об этой системе.