Русский
Русский
English
Статистика
Реклама

Хранилища данных

С днём бэкапа! Но не бэкапом единым

31.03.2021 16:16:13 | Автор: admin
31 марта это такой Хэллоуин безопасников: по легенде именно в этот день всякая нечисть вылезает из даркнета и бомбит атаками ИТ-инфраструктуру компаний. Кто-то нацеливается на компании покруче и ищет славы, кто-то тихо крысит коммерческую информацию, чтобы продать её подороже И тут день бы выстоять да ночь продержаться. Но это, конечно, чистой воды сказка и миф: на самом деле угрозы информационной безопасности существуют не в последний день марта, а в режиме 24/7/365. Но многим почему-то пофиг: у них есть подушки безопасности в автомобиле, они пристёгивают ремень, надевают шлем на картинге, страхуют жилище, ставят сигнализацию на квартиру и автомобиль, надевают чехол на дорогой телефон, но на работе упорно пишут пароли на стикерах, жмотятся на средства безопасности и наивно полагают, что уж их компания-то точно никому не сдалась.

Ребята, чьё второе имя риск и опасность, этот пост для вас.


В 2019 году в США прошёл опрос 1200 владельцев малого бизнеса. Выяснилось, что с 2015 года процент малых предприятий, сообщивших о кибератаках, увеличился втрое, а почти 80% респондентов заявили, что им трудно угнаться за постоянно меняющимся киберпространством. Так, кибератакам подвержены 12% компаний малого бизнеса, более 20% среднего бизнеса и почти 33% крупного бизнеса. На фоне постоянного роста тренда кибератак это очень опасные и немного удручающие цифры. Удручающие прежде всего потому что эти атаки зачастую не результат продуманных действий самых мощных хакерских группировок, а закономерный итог всеобщего раздолбайства, прижимистости руководства, алчности сотрудников и подлости конкурентов. И самое интересное, что ситуация эта применима почти ко всем регионам мира. Эти слова подтверждает ещё один факт из исследования: каждый четвёртый респондент не верил, что его бизнес когда-нибудь подвергнется кибератаке. И то правда: зачем небольшая или даже средняя компания международным хакерам и кому придёт в голову внедрить в ИТ-инфраструктуру такой компании вредоносное ПО?

В том-то и дело, что современные киберугрозы живы далеко не одними хакерами, вирусами, червями и прочим malware. Как минимум, есть программы-вымогатели и социальная инженерия, от которой трудно обезопасить компанию в условиях тесной связанности всех виртуальных сущностей и слагаемых человека. Злоумышленники (а иногда и конкуренты с их помощью) выстраивают сложные схемы взаимодействия с сотрудниками компании и таким образом добиваются едва ли не добровольной передачи всей нужной информации.

Так что в 2021 году может угрожать кибербезопасности?

Несерьёзное отношение к кибербезопасности


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

Что касается бизнес-процессов, то здесь ключевая проблема компаний лежит в сфере разрозненности отделов и других подразделений компании. То есть служба безопасности или системный администратор делают всё для защиты компании, а сотрудники других отделов пишут пароли на стикерах, входят в рабочие системы с Wi-Fi в любимом или случайном кафе, имеют один пароль на офисную CRM, доступ к корпоративной системе знаний, рабочей почте, личной почте, страничке ВКонтакте и Инстаграму. То есть работа одного подразделения может пойти насмарку из-за безалаберности отдельных сотрудников и человеческого фактора.

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

Реактивная, а не проактивная кибербезопасность


Если сотрудник, отвечающий за безопасность компании, способен отразить атаку, предотвратить кражу данных и фрод со стороны сотрудников, это настоящий Супермен. Но не молодец. Молодец тот (или те) сотрудник, который способен обеспечить безопасность таким образом, чтобы атаки и утечки данных были просто невозможными или останавливались на подступах к информационным системам компаний.

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

Пароли, пароли, пароли...


Это очень смешно, но пароли по-прежнему приносят много проблем компаниям просто потому что человек со скомпроментированной базой в руках уже кулхацкер. Промахнуться с паролями проще простого: стандартные наборы из топ-10 взламываемых паролей, угадываемые значения (дни рождения, имена и т.д.), пароли от соцсетей на корпоративных системах, общие пароли для всей компании, админские пароли для всех пользователей. Ну и конечно, всё это хранится ровно в трёх местах: на стикерах на мониторе, в блокнотах на столе и особо секьюрно на перевёрнутой бумажке под клавиатурой. Есть, конечно, у офисных сотрудников сверхсекьюрный способ хранения паролей: они находятся в отдельном txt-файлике на рабочем столе компьютера. Ну а о том, чтобы регулярно обновлять пароли и речи не идёт тут мозг бухгалтера или продажника может переполниться и выдать полный stack overflow.

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

Авось оно само работает, никто же не проник


Проблема подавляющего большинства компаний любого масштаба отсутствие тестирования безопасности, причём его нет как со стороны внутренних служб и сотрудников, так и со стороны внешних агентов (профессиональных пентестеров). Это чревато тем, что дорогостоящие (и любые) средства безопасности могут работать неправильно и/или неполноценно, а какие-то участки инфраструктуры оказываются уязвимыми. И если для небольшой компании это может закончиться простой утечкой данных (клиентской базы, операционных показателей или базы сотрудников), то для крупного предприятия или завода отсутствие адекватного аудита безопасности скорее всего обернётся катастрофой (и не факт, что не странового и даже не планетарного масштаба).

Профессиональные пентестеры ищут незащищённые уязвимости в контуре безопасности вашей компании, проводят преднамеренные и управляемые атаки, тестируют фишинг, работают с SQL-инъекциями на всех веб-ресурсах, ломают законным путём инфраструктуру так, как бы её могли сломать незаконным. Внешние аудиторы безопасности это не только профессионалы, но и люди со свежим взглядом на ваш бизнес: порой они видят очевидные проблемы, которые лежат на поверхности, но остаются незамеченными из-за того, что сотрудники к ним привыкли. Более того, иногда бывает, что в компании привычно обходят дыру в безопасности каким-то временным воркэраундом, который был создан на пару дней пять админов назад, но жив до сих пор. Ну и конечно, немаловажно, что внешние пентестеры полностью беспристрастны им некого покрывать в вашей компании. И это здорово минимизирует человеческий фактор: увы, самые серьёзные проблемы безопасности могут исходить именно от сотрудников.

Инсайдерская угроза: чужой среди своих


Инсайдерская угроза одна из самых трудно обнаруживаемых и не поддающихся профилактике угроз. Она может исходить от сотрудников компании, должностных лиц и партнёров, связанных с компанией. Более того, это могут быть бывшие сотрудники, аудиторы, юристы, заказчики и прочие лица, которые когда-либо получали доступ к конфиденциальной коммерческой информации. При этом внутренние сотрудники обеспечивают большинство утечек внешние агенты гораздо более трепетно относятся к подписанным договорам с NDA и дорожат репутацией своих организаций. Самое страшное, что такие угрозы невозможно обнаружить и предотвратить привычными методами.

Методы инсайдеров также весьма изощрённы: от стандартного слива и копирования до вхождения в группировки заинтересованных лиц и логических бомб (когда бывшие сотрудники оставляют разнообразные гхм программные сюрпризы в ИТ-инфраструктуре и хранилищах данных компаний). Причём целью может быть как нажива, так и банальная месть. Более того, иногда сотрудник даже не догадывается, что он участвует в инсайдерской схеме.

Сложно сказать, как бороться с инсайдерами. Здесь все меры хороши: от кротов в подразделениях до тотального контроля подозрительных сотрудников. Проблема в том, что нередко главной угрозой становится самый тихий и аккуратный сотрудник. И это страшно, потому что в погоне за таким сучком (ох уж эта игра слов) можно всю компанию в щепки разнести. Будьте бдительны и осторожны, проанализируйте инсайдерские каналы и воздействуйте на них точечно.

Небезопасные корпоративные системы и бизнес-софт


Увы, даже самые дорогие корпоративные программы могут быть скомпрометированы и не гарантируют полной безопасности, более того как раз небольшие разработчики софта управляют безопасностью своих программ эффективно из-за того что у них более плотная разработка, компактнее команда и они уделяют много времени рефакторингу и проектированию систем и алгоритмов (но это не точно, точнее точно не для всех). Проблемы могут быть связаны как с архитектурой программ, так и с облачным провайдером-партнёром вендора и даже с человеческим фактором, когда фактором риска являются сотрудники компании-разработчика.

Поэтому не стоит слепо доверять вашему поставщику ПО, защитите себя, задавая вопросы и принимая меры: обратите внимание на репутацию разработчиков, узнайте всё о мерах безопасности и способах защиты данных, узнайте периодичность бэкапов, возможности распределения прав доступа. Рекомендуем вам не пользоваться облачным провайдером поставщика (никто не знает, на чём он там сэкономил и как хранит данные), выбирайте своего VPS-провайдера (например, мы в уделяем безопасности максимальное внимание и готовы помочь разместить ваш софт на наших мощностях) и размещайте софт у него либо вообще на своих серверах (дорого, но при наличии хорошего сисадмина максимально секьюрно).

Помимо этого обратите внимание на патчи, минорные и мажорные обновления программного обеспечения. Если разработчик ПО их выпускает, обязательно накатывайте, чтобы обеспечить актуальное и безопасное состояние ПО.

Кстати, об облачных провайдерах и хостингах. Не храните данные в мешке за сараем: с осторожностью подходите к выбору поставщика облачных услуг, уточняйте, в какой юрисдикции хранятся их данные. Всегда уточняйте у потенциального поставщика облачных услуг, где они размещают свои данные. Хорошие хостеры должны предлагать хостинг в различных юрисдикциях и должны быть в состоянии рассказать вам о законах, действующих в каждой юрисдикции, чтобы вы могли осознанно и мотивированно выбрать, где хранить ваши данные. Для России это особенно важно если не знаете, почему, смотрите федеральный закон 152-ФЗ.

Один за всех


По состоянию на 2021 год ассортимент средств обеспечения информационной безопасности настолько велик, что можно предотвратить практически все угрозы (включая форс-мажоры из-за пожара в дата-центре). Вот только небольшой список, доступный любой компании: брандмауэр, антивирусы и антиспам, VPN, системы мониторинга и ITSM, системы контроля цифровой активности сотрудников (зло, конечно, но есть), функции распределения прав доступа внутри бизнес ПО, средства безопасности операционных систем и проч. Их комплексное использование способно надёжно защитить компанию от большинства типов атак. Но компании нередко отдают предпочтение лишь одному способу из соображений экономии, безалаберности и фразы и так сойдёт.

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

Цена ошибки жизнь компании


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

Выход один: обучать сотрудников и буквально делать рассылки с каждым новым способом атаки. Но нет никаких гарантий, что завтра не появится в корне новый метод, о котором вы не успеете предупредить коллег. Например, был случай, когда у компании с международными продажами софт решила закупить полиция Миннесоты они попросили 120 лицензий, прислали гарантийное письмо, что оплатят полученные ключи в течение месяца. Всё было максимально серьёзно и официально. Ключи были переданы, никто их не оплатил. Да, это всего лишь недополученный доход для компании: подумаешь, виртуальный ключ. Но, увы, никто не может предположить, как они будут использованы или перепроданы. Пока выяснили, пока проверили, пока заблокировали, можно было причинить очень много проблем повезло, что это скорее всего были какие-то глупые хулиганы.

Управление безопасностью для галочки


В компании могут быть самые дорогие средства безопасности и самые продвинутые безопасники на большой заработной плате, а потом утром на Хабре напишут пост про то, как вашу систему взломали. И причина тому клубок жадности и невнимательности. Но это полбеды: поругались, связались с автором, поблагодарили его (да же?) и закрыли уязвимость. А вот если никто не напишет на Хабр, а будет ежедневно эксплуатировать уязвимость и использовать ваши коммерческие данные для своих выгод, это настоящая беда.

Поэтому нужно менять отношение сотрудников к безопасности: они должны знать, что безопасность в компании контролируется, исполняется и каждый из них несёт ответственность за компоненты информационной безопасности на своём месте. При этом недостаточно подписывать дополнительные соглашения и озвучивать цели, важно включить элементы управления безопасностью во все бизнес-процессы и системы, чтобы сотрудники видели, что проблема не номинальна. Кстати, неплохо мотивируют награждения сотрудников за соблюдение правил информационной безопасности: вы можете это реализовать в формате геймификации, системы KPI, регламентов и т.д. Главное, сотрудники должны видеть глубокую и искреннюю обеспокоенность руководства проблемой корпоративной безопасности.

Иногда угрозы безопасности возникают из ниоткуда. Старая ИТ-мудрость гласит: Вы в безопасности настолько, насколько безопасно ваше самое слабое звено. Вы точно знаете, где это звено в вашей компании? Например, автор этой статьи работал в одной региональной компании и сидел на городском автовокзале, ждал автобус. Рядом сидел человек, который по телефону громко и возмущённо рассказывал схему отката и работы с поставщиком довольно эксклюзивной продукции. И так совпало, что автор был работником конкурента. Более эпичный слив информации сложно представить. Информацией никто не воспользовался, но это было уже дело принципа. Так вот, дыру в безопасности могут породить болтуны, любители селфи на фоне рабочего монитора или внутри инфраструктуры (если речь идёт о производстве), случайные скриншоты с адресом и портом админки в адресной строке и другие случайности такие как потерянные ноутбуки и телефоны, оставленные бумаги, забытые флешки и т.д.

Поэтому соблюдайте гигиену информационной безопасности и приучайте к ней ваших коллег и сотрудников. И да, делайте бэкапы не только 31 марта.

Делайте, мать их, бэкапы!

Подробнее..

Из хлама в NAS и немного темы майнинга

18.06.2021 12:04:53 | Автор: admin

Начну с того, что очень часто, рядом со мной аккумулируется разного рода железо (в простонародье хлам), а так как я по своей природе Плюшкин, в том плане, что я очень редко выкидываю технику, а если и случается предварительно вытаскиваю оттуда всё, что может хоть как-то пригодиться. И что бы ничего не выкидывать, периодически приходится находить применение всему этому железу, об этом сегодня и будет идти речь.

Итак мы имеем: ПК 11 летней давности в состоянии трэш.
Если подробнее: у блока питания вздуты все конденсаторы на выходе, у жёсткого диска взорванный полимерный конденсатор на входе питания, видеокарта тоже не стартует. По моим догадкам, по 12в линии явно пошло сильно больше 12в. При этом материнка с процессором остались живы. Чудо!

Порывшись в закоулках нахожу 4 плашки ddr2 пару на 1гб и пару на 2гб.

По характеристикам


Процессор: Celeron E3400
Материнская плата: P5K PRO
Оперативная память: 6 Gb ddr2
Жёсткий диск: 400 Gb IDE
Видеокарта: GeForce 8400 GS
Блок питания: FSP 350W



Ну вот всё что нужно есть, приступаем к оживлению трупа!


Начал с БП. Конденсаторов на большую ёмкость у меня нет (2000-3000мкФ) и пришлось городить этажами, получился вот такой лес:

image

На плате жёсткого диска, припаял конденсатор (старый просто испарился, одни следы только были), так же заодно покрыл припоем контактные площадки, чтобы не коррозировали, и даже не надеялся что он заработает, однако ожил:

image

С видеокартой немного сложнее, питание gpu звонится с малым сопротивлением в обе стороны, явно что то не то. При прозвоне нашёл два подозрительных силовых транзистора, перепаял на те, что были в закромах, заработало это только с помощью черной магии, других объяснений нет!Хотя сильно в нагрузке не тестировал:

image

Обновляю bios, накатываю win 10 и подключаю подготовленные под это дело диски (восстановленные). Я осознал насколько он тормоз в плане быстродействия, так что все планы по установке чего либо в него, я убрал (по крайне мере до того момента как найду, хотя бы четырёхъядерный процессор).

image

Тут больше ничего не оставалась как сделать из него NAS (сетевое хранилище) с возможностью подключения по RDP, к тому же в материнке была рабочая родная гигабитная сетевая карта (кто много возился со старым железом, знает что рабочая сетевуха в материнке это джекпот).
Далее я в прямую сделал доступ к локальным дискам по SMB включая C и разрешил подключение по RDP:

image

Майнинг


Сразу понятно что речь идёт о новой одноимённой монете.
Так как я не дата центр, будем экспериментировать с пулом.
Еще к этому NAS я подключил заплоченные диски, по-другому никак, характеристики вы сами видели.

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

image

После 24ч теста всё хорошо, ничего не взорвалось. Синхронизация кошелька ест 90% процессора и идёт со скоростью ленивца, который должен преодолеть 50 км ХД.

По итогу, у нас 6 портовый NAS, ещё и с 400Гб памяти на борту. Ради интереса глянул сколько стоит подобные готовые решения и удивился 700$ и это минимум.

Что можно сделать дальше?


Можно отрыть 4 ядерный процессор, подоткнуть usb 3.0 контроллер, настроить мультимедийный DLNA сервер и это только то, что мне пришло на ум.

На момент написания текста статьи, 1Тб приносит 10 рупий рублей в день.

Ни одна деталь не была куплена, всё собиралось из того, что есть.

Финал


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


Подробнее..

Musiphone децентрализованный музыкальный плеер

22.04.2021 16:18:43 | Автор: admin


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


Свой рассказ я бы хотел поделить на две части:


1. Плеер изнутри (musiphone, museria-player)


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


const Node = require('musiphone').Node;(async () => {try {const node = new Node({port: 4000,hostname: 'localhost',musicStorageAddress: 'storage.museria.com:80'});await node.init();}catch(err) {console.error(err.stack);process.exit(1);}})();

const Client = require('musiphone').Client;(async () => {try {const client = new Client({address: 'localhost:4000'});await client.init();const title = 'Playlist title';const songs = ['Onycs - Eden','Onycs - Shine','Onycs - Timeless'];// Add the playlistconst response = await client.addPlaylist(title, songs);// Get the playlistconst playlist = await client.getPlaylist(response.hash);}catch(err) {console.error(err.stack);process.exit(1);}})();

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


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


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


2. Плеер извне (сайт, android приложение)


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


Интерфейс везде примерно одинаковый, поэтому разберем все на примере сайта.


Создание и сохранение плейлиста в сеть.



Вначале вы попадаете на интерфейс с бобром и неактивной кнопкой "NEW PLAYLIST". Это означает, что сейчас идет создание нового плейлиста. Чтобы добавить песню, нужно найти ее в музыкальном хранилище, используя поле ввода слева. Если нужной песни там нет, то вы можете сами добавить ее, перейдя по ссылке "MUSIC STORAGE" сверху, тем самым вы поможете и себе и другим людям, которые в дальнейшем будут ее искать.


Для примеров будут использоваться рандомные песни, разрешенные для свободного распространения и прослушивания. Давайте поищем "Onycs Eden"



В хранилище нашлось пару вариантов, можно их прослушать и добавить нужный, нажатием на плюсик. Добавим несколько песен.



Теперь у нас три песни в плейлисте. По ним можно производить поиск, сортировать, перетаскивая и.т.д. Коричневое предупреждение означает, что были сделаны какие-либо изменения и если не сохранить их в сеть, то они исчезнут после очистки localStorage.


Попробуем сначала сохранить все в сеть. Для этого нажимаем "SAVE TO WEB".



Ввели название и сохраняем.



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


Также мы видим, что исчезло коричневое предупреждение и появилось синее табло, в котором у нас ссылка на плейлист. Вы можете дать эту ссылку любому человеку, перейдя по ней, он увидит тоже самое. Создадим еще один плейлист. Для этого нажимаем "NEW PLAYLIST". Повторяем те же шаги и получаем:



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


Сохранение плейлистов в файл
Для большей надежности вы можете сохранять плейлисты в файлы. Для этого нажимаем "SAVE TO FILE". Файл будет сохранен в общепринятом формате m3u и может быть загружен и прослушан в любом другом плеере.


Загрузка плейлистов
Чтобы загрузить плейлист, нажимаем "LOAD PlAYLIST".



В модальном окне у нас есть два варианта. Мы либо загружаем по ссылке, либо из файла. В первом случае существует два типа ссылок:


  • Статическая ссылка. Это обычная ссылка с хэшем на плейлист в хранилище: http://player.museria.com:80/musiphone/3deeb6052c5a46c05d6bec2cab5bade9 Напрашивается вопрос, зачем ее грузить через форму, если можно просто по ней перейти. Дело в том, что во-первых это нужно для мобильной версии, а во вторых узлы относительно которых создается ссылка рандомные. Это может быть неудобно когда вы уже настроили свое окружение на каком-то хосте, ведь вся временная информация хранится в localStorage. Поэтому переходы по таким ссылкам удобны, чтобы ознакомится с плейлистами, но чтобы формировать свое пространство нужно работать с интерфейсом какого-то одного узла, например, дефолтного: player.museria.com


  • Динамическая ссылка. Такая ссылка не связана с хранилищем, она должна содержать путь к любому валидному m3u файлу/ответу сервера в интернете. Содержимое будет автоматически трансформировано в плейлист приложения. Каждые 10 секунд будет происходить новый фоновый запрос по этой ссылке, на случай, если вдруг данные изменились и нужно обновить список. Динамическая ссылка проебразуется в следующий вид, для того, чтобы ею можно было также делиться: http://player.museria.com:80/musiphone/external:someUrlHash



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


Конфиги
Все, что вы настраиваете в плеере хранится в localStorage. Чтобы сохранить эту информацию в файл(json), используйте кнопку "SAVE CONFIG", для загрузки "LOAD CONFIG". Вы можете настраивать различные группы плейлистов, уровень громкости плеера и прочее, создавая разные конфиги. Вот, например, вам конфиг из примеров в этой статье.


Вы можете помочь проекту, запустив хотя бы один узел для музыкального хранилища у себя на сервере пространством 50-1000гб, от 2гб оперативки, 2 ядра. Чем больше узлов, тем больше песен будет доступно.


Либо узел для сети плеера: от 300 мб свободного пространства, 1гб оперативки, 1 ядро. Больше узлов дольше живут ссылки.


Группа в телеграм на английском, либо сразу пишите мне в личку ortex

Подробнее..

Обратная сторона копирайта

22.04.2021 20:09:52 | Автор: admin

16 ноября 2012 года на сайте Республиканского исследовательского комитета (Republican Study Committee, или RSC), объединяющего более 170 членов палаты представителей США от республиканской партии, появился занимательный доклад. Документ провисел в открытом доступе не более суток его убрали под предлогом того, что он не соответствовал принятым стандартам RSC и не прошел всех согласований. Впоследствии доклад так и не вернулся на страницы сайта. О чем же говорилось в этом документе и почему его так поспешно изъяли из публичного доступа?

Таинственный доклад, с полным текстом которого по-прежнему можно ознакомиться на Scribd, представлял собой последовательную критику сложившейся системы авторского права и вскрывал основные недостатки копирайта в цифровую эпоху. Хотя авторы документа закономерно опирались на законодательство США, многие обозначенные в нем проблемы актуальны для всего мира. Кратко перечислим основные тезисы.

1. Копирайт наносит ущерб науке, задерживая ее дальнейшее развитие

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

2. Копирайт ограничивает доступность литературы

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

3. Ограничение развития различных отраслей искусства

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

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

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

4. Цензура

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

Книги, преданные забвению

Все перечисленные пункты достаточно очевидны и вряд ли требуют научного базиса для подтверждения, однако подобные труды существуют. Одной из самых ярких работ является исследование американского писателя, профессора Иллинойского университета Пола Хилда. В своих изысканиях он опирался на WorldCat крупнейшую в мире библиографическую базу данных, созданную Фредериком Гридли Килгуром еще в 1967 году и успешно развивающуюся и по сей день. Этот ресурс содержит свыше 240 миллионов записей практически обо всех видах произведений, когда-либо созданных на 470 языках мирах, что позволяет собрать весьма точную статистику.

Профессор Иллинойского университета, писатель Пол ХилдПрофессор Иллинойского университета, писатель Пол Хилд

Проанализировав сведения, представленные на WorldCat, ученый обнаружил интересную закономерность. По мере распространения грамотности и развития технологий в XX веке, количество ежегодно создаваемых печатных трудов значительно превысило показатели XIX века, причем это касается как художественной, так и научной литературы. Для сравнения: в 1980-х годах было издано в 8 раз больше новых книг, чем в 1880-х. С учетом такого распределения можно было бы ожидать, что в ассортименте магазинов книги, написанные в конце XX века, будут встречаться примерно в 8 раз чаще, нежели книги, впервые увидевшие свет в конце века XIX. Однако на деле распределение выглядит совершенно иначе.

Как видно из приведенного графика, шансы встретить в магазине книгу, написанную в период с 1820 по 1920 год, значительно выше, чем что-то более современное. Все дело в том, что произведения, увидевшие свет в этот временной период, уже получили статус общественного достояния и могут быть перепечатаны без дополнительных авторских отчислений или выкупа эксклюзивных прав у автора.

Продавать новые романы выгодно лишь в течение ограниченного периода времени: при наличии должной маркетинговой кампании охватить максимум целевой аудитории удается уже в первые год-два, затем же продажи существенно падают, поэтому выпуск дополнительных тиражей оказывается нецелесообразным. И хотя затраты на цифровую дистрибуцию несоизмеримо ниже по сравнению с издержками на печать бумажных книг, издателю все равно необходимо иметь лицензию на распространение соответствующего произведения, а приобретать таковую на срок более 2 лет опять же не имеет смысла, если только речь не идет о каких-то мегапопулярных тайтлах. С научными трудами все совсем печально: будучи слишком нишевыми, они и так плохо продаются, исчезая с книжных полок куда быстрее проходных дамских романов.

Из всего сказанного выше профессор делает неутешительный вывод:

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

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

Устранение конкурентов: быстро, эффективно, законно

Справедливость же третьего тезиса можно с легкостью подтвердить многочисленными примерами из игровой индустрии. Вспомним тот же MERP (Middle-Earth Roleplaying Project) глобальную модификацию для Skyrim, разработчики которой поставили перед собой весьма амбициозную цель, пожелав не просто в точности воссоздать в виртуальном пространстве мир Средиземья, но и сделать настоящую RPG мечты во вселенной Властелина колец, где игрок мог бы примерить на себя роль Фродо Бэггинса и пройти нелегкий путь от Хоббитона до Ородруина, дабы уничтожить Кольцо Всевластия, или же оставить могущественный артефакт себе, попытавшись стать новым Властелином.

Разработка мода началась в 2008 году. Изначально небольшая команда энтузиастов взяла за основу движок Oblivion, однако после выхода следующей части Древних свитков ребята, оценив возможности обновленного Creation Kit, решили перенести свои наработки на новые рельсы. Возможно, этот проект никогда не дошел бы до релиза, разделив судьбу множества других фанатских долгостроев, застрявших на этапе вечной альфы, а может быть, однажды мы с вами действительно смогли бы поиграть в величайшую ролевую игру всех времен. Однако финал этой истории оказался куда прозаичнее: 31 августа 2012 года моддеры получили официальное письмо от юристов Warner Bros. Interactive Entertainment, в котором правообладатель потребовал прекратить дальнейшую работу над модификацией, пригрозив энтузиастам судом. Оно и понятно: на тот момент студия Monolith уже работала над Middle-earth: Shadow of Mordor, официальный анонс которой состоялся всего год спустя, и Warner Bros. не хотела конкуренции даже в виде бесплатного мода.

Похожая судьба ждала и мультиплеерный шутер Star Wars: Galaxy in Turmoil. Фанаты вселенной Звездных войн, опечаленные отменой Battlefront 3, решили создать собственный мультиплеерный шутер с нуля, взяв на вооружение игровой движок Unreal Engine 4. Разработчикам удалось довести проект до вполне играбельного состояния и даже выпустить в раннем доступе Steam, но однажды письмо счастья пришло и на их e-mail.

Electronic Arts, получившая эксклюзивные права на разработку игр по легендарной вселенной, оказалась недовольна появлением подобной игры: лишние конкуренты, особенно на фоне лутбоксового скандала, разворачивающегося вокруг нового Battlefront, который EA на старте всеми силами пыталась превратить в pay-2-win-проект, издателю были не нужны, тем более в виде абсолютно бесплатной игры.

Однако авторы Star Wars: Galaxy in Turmoil не сдались. Они полностью удалили все ассеты, так или иначе связанные с франшизой Звездных войн, переформатировав игру в научно-фантастический сетевой шутер с элементами киберпанка. Данный шаг помог уберечь проект от закрытия, но не от краха: без должного продвижения, которое было не по карману разработчикам, без громкого имени и статуса наследника того самого Battlefront, который так полюбился сообществу, игра перестала развиваться, растеряв львиную долю пользовательской базы.

Двухмерный файтинг My Little Pony: Fighting is Magic один из тех редких примеров, когда фанатская работа смогла выжить после релонча. Подобно создателям Star Wars: Galaxy in Turmoil, получив иск от Hasbro, авторы файтинга (команда из 9 человек, известная в сети под именем Mane6) полностью переработали оригинальную игру и привлекли необходимые для завершения разработки средства через краудфандинговую платформу Indiegogo, сумев добраться до полноценного релиза, который состоялся 30 апреля 2020 года. На этапе перезапуска проекта команда Mane6 нашла неожиданную поддержку в лице аниматора My Little Pony Лорен Фауст, которая помогла энтузиастам с созданием новых персонажей для файтинга в характерном визуальном стиле. Новая версия игры получила название Them's Fightin' Herds.

Впрочем, история Them's Fightin' Herds скорее исключение, чем правило. В Hasbro обратили внимание на проект слишком поздно: на момент, когда Mane6 получила официальное требование прекратить разработку, файтинг уже был достаточно известен в кругу ценителей и даже едва не вошел в перечень официальных дисциплин ежегодного киберспортивного турнира Evolution Championship Series благодаря уникальным движениям и комбо. Сложись обстоятельства иначе, игра канула бы в Лету, как и многие другие подобные проекты.

Продолжение Chrono Trigger под кодовым названием Crimson Echoes (Square Enix), ремейк Metal Gear Solid (Konami), MMO во вселенной покемонов PokeNet (Nintendo) перечислять отмененные по воле правообладателей фанатские проекты и их убийц можно бесконечно. И если мотивацию той же Nintendo еще можно понять (как ни крути, японский гигант старательно развивает принадлежащие ему франшизы), то Konami ведет себя подобно собаке на сене из поговорки, ведь во вселенных некогда знаковых Silent Hill и Metal Gear сегодня выходят лишь автоматы патинко.

Вот как выглядит официальный ремейк MGS 3 от KonamiВот как выглядит официальный ремейк MGS 3 от Konami

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

Правообладатели на страже нравственности

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

Обратимся к событиям лета 2020 года. 10 июня на фоне массовых протестов в США стриминговый сервис HBO Max снял с ротации нестареющую киноклассику Унесенные ветром. После закономерного недовольства подписчиков конгломерат WarnerMedia выпустил следующее заявление:

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

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

Вчерашняя классика может впасть в немилость по воле трендовВчерашняя классика может впасть в немилость по воле трендов

Спустя 15 дней фильм действительно вернулся в каталог HBO Max. Впрочем, иного исхода сложно было ожидать: вряд ли кто-то осмелился бы предать забвению картину, завоевавшую 8 статуэток Оскар и включенную в 1989 году в Национальный реестр фильмов США. Однако теперь перед началом фильма зрителям демонстрируется лекция профессора Чикагского университета кинематографии Жаклин Стюарт, повествующая о стереотипном изображении афроамериканцев в кино, а вторую часть картины предваряет запись круглого стола на тему Сложное наследие Унесенных ветром, состоявшегося на кинофестивале TCM в 2019 году.

А вот современным сериалам повезло куда меньше. Так, Netflix, BBC и BritBox отказались от проката скетч-шоу Маленькая Британия. Причиной этого послужило неподобающее поведение актеров, которые карикатурно изображали представителей других рас. Тот факт, что британские комики Мэтт Лукас и Дэвид Уильямс изначально стремились создать максимально неполиткорректное шоу, в котором бы высмеивались все возможные стереотипы и пороки общества (причем в первую очередь под удар попали коренные англичане), руководством стриминговых сервисов был благополучно проигнорирован. Впал в немилость даже документальный (!) сериал Полицейские, выходивший с 1989 года: телеканал Paramount Network объявил о закрытии шоу всего за 5 дней до премьеры 33-го сезона. Официальной причиной для этого послужило унижающее человеческое достоинство изображение афроамериканцев.

Если в нулевых над скетчами Лукаса и Уильямса смеялся весь мир, то сегодня их шоу считается аморальнымЕсли в нулевых над скетчами Лукаса и Уильямса смеялся весь мир, то сегодня их шоу считается аморальным

Не остался в стороне и Дисней, хотя медиагиганту и понадобилось для раскачки больше времени. В соответствии с новой политикой инклюзивности компания ввела ограничения на доступ к ряду классических полнометражных мультфильмов в стриминговом сервисе Disney+, которые долгие годы оставались визитной карточкой компании. Такие анимационные ленты, как Питер Пен, Думбо, Книга джунглей, Коты-аристократы, и ряд других произведений перестали отображаться в детских профилях, а их описания были дополнены предупреждениями о содержащихся в мультфильмах расовых и культурных стереотипах, существовавших во время создания произведений.

Целесообразность подобного поступка вызывает вопросы. Если вы еще не прочли манифест Диснея, то попробуйте навскидку вспомнить, что такого криминального было в перечисленных мультфильмах. Вряд ли, будучи ребенком, вы задумывались о том, что вороны из Думбо являются прообразом уличных комиков, высмеивающих африканцев в характерном гриме (так называемый блэкфейс), а имя их главаря и вовсе отсылка к Законам Джима Кроу времен расовой сегрегации в США. Это весьма тонкий момент, на который могут обратить внимание лишь взрослые, хорошо знающие историю.

Да и для того, чтобы отыскать расистский подтекст в песенке Короля Луи, блестяще исполненной джазовым музыкантом Луи Прима, надо очень постараться. Во всяком случае, на формирование мировоззрения ребенка это произведение уж точно никак не повлияет (ну разве что привьет вкус к хорошей музыке).

Впрочем, повышение возрастного рейтинга весьма мягкая мера, ведь Дисней уже не раз демонстрировал, на что способен в борьбе за нравственные устои общества. Достаточно вспомнить хотя бы релиз фильма Всплеск, в котором все сцены с обнаженной Дэрил Ханна, даже самые невинные, на которых и так не разглядеть каких-либо подробностей, были любовно зацензурены с помощью компьютерной графики (к слову, довольно низкого качества).

А еще раньше Диснея уличили в удалении целого эпизода из культового мультсериала Симпсоны, один из персонажей которого, Леон Камповски, считал себя Майклом Джексоном и разговаривал его голосом, однако совершенно не умел петь. Так что в случае с классическими мультфильмами все еще обошлось малой кровью.

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

Напомним, что еще в апреле 2019 года компания объявила об ужесточении контроля за контентом эротического характера в играх, выходящих на платформе PlayStation. В интервью The Wall Street Journal официальные представители Sony четко обозначили причины данного поступка:

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

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

Слева версия обложки для семейной консоли Nintendo Switch, справа для взрослой PlayStation 4Слева версия обложки для семейной консоли Nintendo Switch, справа для взрослой PlayStation 4

Новый регламент ударил по небольшим студиям. Все дело в том, что на первых порах у Sony вообще не было строгих критериев или письменного свода правил: ужесточение требований в отношении взрослого контента в играх вступило в силу неожиданно для всех, вскоре после череды скандалов, связанных с движением MeToo (судя по всему, именно они и послужили основной причиной столь скоропалительного пересмотра внутренней политики). И если крупные издатели вроде Capcom могли позволить себе выпускать специальные версии игр для консолей PlayStation, то у инди-разработчиков начались серьезные проблемы.

В Devil May Cry 5 мотоцикл Данте обзавелся мощными ксеноновыми фарами, призванными скрыть прелести ТришВ Devil May Cry 5 мотоцикл Данте обзавелся мощными ксеноновыми фарами, призванными скрыть прелести Триш

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

Здесь обозначена вторая по важности (после самого факта корпоративной цензуры) проблема постоянно меняющиеся правила игры. Те же Унесенные ветром снимались во времена действия Кодекса Американской ассоциации кинокомпаний, более известного как Кодекс Хейса (назван по имени Уильяма Харрисона Хейса, возглавлявшего ассоциацию в период с 1922 по 1945 год). Данный свод правил включал в себя 11 пунктов, соблюдение которых было обязательным, и еще 25 носящих рекомендательный характер. Хотя в этом перечне было немало странных (даже по тогдашним меркам) требований, если кинокартина им соответствовала, ее выпускали в прокат без каких-либо ограничений.

Уильям Харрисон Хейс главный борец за нравственность в Голливуде начала XX векаУильям Харрисон Хейс главный борец за нравственность в Голливуде начала XX века

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

Для нас же с вами как потребителей контента последствия будут также весьма печальными: в эпоху цифровой дистрибуции правообладатель способен отменить или искалечить любое неправильное произведение, вырезав неудобные моменты, и никто ничего не сможет с этим поделать. Увы, главным девизом современного бизнеса стала любимая фраза Беликова Как бы чего не вышло. В рамках превентивного damage-control правообладатели предпочитают заблаговременно избавляться от всего, что потенциально может принести репутационные и/или финансовые потери, а когда речь заходит о миллионах и даже миллиардах долларов, интересы конечного потребителя уже мало кого волнуют.

Мой магазин мои правила: ноу-хау от Ubisoft

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

Ранее мы уже обращались к теме копирайта в цифровую эпоху применительно к онлайн-магазинам компьютерных игр, однако прошлая публикация была встречена читателями неоднозначно: кто-то решил, что мы критикуем конкретно Steam (хотя на самом деле мы критиковали сложившуюся модель дистрибуции в целом, при которой издатель может сделать с приобретенной вами игрой все, что посчитает нужным, в том числе изменить до неузнаваемости и даже отобрать), а кто-то не воспринял высказанные опасения всерьез. Но Ubisoft расставила все точки над i, убедительно доказав, что мы были правы, хотя компания и превзошла все наши самые смелые ожидания.

Еще 12 мая 2020 года издатель изменил текст пользовательского соглашения, в котором появился весьма интересный пункт 8.2, касающийся условий прекращения действия учетной записи, необходимой для использования сервисов Ubisoft. Согласно ему, компания может закрыть ваш аккаунт в том случае, если он был неактивен более 6 месяцев. Разумеется, ни о какой компенсации денежных средств, потраченных на игры, речи не идет, о чем прямо сказано в пункте 8.3.

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

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

С точки зрения бизнеса обосновать данный шаг легко. Лояльной аудитории Ubisoft, которая покупает и играет в игры издателя на постоянной основе, бояться нечего: они и так будут регулярно авторизовываться в сервисе и никогда не получат подобный email. В то же время это неплохой способ стимулировать к покупке тех, кто заходит в Uplay лишь время от времени (например, чтобы поиграть в Реймана или перепройти старых Принцев Персии), делать это чаще: возможно, в очередной раз запустив лаунчер, такой пользователь польстится на скидку и прикупит что-нибудь новенькое, а там, глядишь, распробует новых Ассасинов и станет приобретать по игре каждый год (а может быть, и во внутриигровой магазин занесет немного наличности).

Прозорливые читатели могут возразить: никакое соглашение, будь то публичная оферта или подписанный собственноручно бумажный договор, не могут противоречить действующему законодательству, а значит, EULA Ubisoft не имеет силы в подавляющем большинстве стран, так как идет вразрез с законом о защите прав потребителей. И это действительно так, но, чтобы вернуть заблокированный аккаунт или получить компенсацию, вам придется подать иск против весьма крупного и богатого издателя.

А теперь ответьте для себя на следующие вопросы. Попав в подобную ситуацию, вы пойдете в суд? Решив судиться, сможете ли вы найти единомышленников для подачи коллективного иска? Есть ли у вас на примете кто-либо из влиятельных персон (представитель законодательной власти или известная медийная личность), кто был бы заинтересован в подобном процессе (например, ради пиара или из идейных соображений) и взялся бы участвовать в таком разбирательстве, оказывая посильную помощь?

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

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

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

Спасение утопающих

Для начала стоит вспомнить о возможности приобретения контента на физических носителях. Хотя сегодня на золото уходит отнюдь не каждый фильм, музыкальный альбом или игра, это не значит, что их вообще перестали выпускать: оптические диски, винил и даже картриджи для консолей прошлых лет все еще можно отыскать на полках магазинов или на том же Ebay, если речь идет о каких-то раритетных изданиях.

Старый добрый винил в наше время становится как никогда актуаленСтарый добрый винил в наше время становится как никогда актуален

Помимо этого, вы можете использовать сервисы, которые позволяют приобрести цифровую копию того или иного произведения и пользоваться ею без онлайн-активации или привязки к аккаунту. Пусть подобных площадок не так много, но они существуют и зачастую способны по-настоящему удивить. Взять, к примеру, тот же Bandcamp: здесь представлены сотни уникальных в своей самобытности коллективов, которых не найти на Deezer и Spotify, к тому же, в отличие от популярных стриминговых сервисов, здесь вы можете скачать любые приобретенные композиции и альбомы в lossless-качестве.

Наконец, не стоит забывать о проектах вроде Public Domain Torrents, Legit Torrents и аналогичных. Названия этих площадок говорят сами за себя: здесь энтузиасты выкладывают фильмы, музыку, игры, имущественные авторские права на которые истекли или вообще никогда не существовали, то есть произведения, находящиеся в статусе общественного достояния. Копирование и распространение таких материалов является полностью легальным, так что, пользуясь услугами подобных площадок, вы не нарушаете действующее законодательство.

Сохранить же резервные копии полученного тем или иным способом цифрового контента вам поможет надежное сетевое хранилище и накопители Western Digital. На Хабре уже неоднократно выходили публикации, посвященные самостоятельной сборке NAS, так что вы сможете без труда отыскать не один десяток готовых рецептов. Что же касается накопителей для реализации подобного проекта, то лучшим выбором были и остаются жесткие диски WD Red Plus.

Данная линейка включает в себя девять моделей емкостью от 2 до 14 терабайт, предназначенных для эксплуатации в составе сетевых устройств хранения данных и вобравших в себя последние технологические достижения Western Digital. Ниже мы во всех подробностях рассмотрим каждую из используемых технологий, чтобы вы, уважаемые читатели, смогли по достоинству оценить предлагаемые нами решения.

  • Высокая надежность

Одна из особенностей жестких дисков WD Red Plus заключается в том, что парковка блока головок дисков осуществляется только при обесточивании NAS, поскольку параметр APM (Advanced Power Management) по умолчанию имеет значение 0. Параметр spindown (standby) timer также принимает нулевое значение: полная остановка мотора происходит лишь при отключении питания. Это позволяет, во-первых, сократить время отклика накопителя, а во-вторых, дополнительно продлить срок службы электродвигателя. И это при том, что привод блока головок может похвастаться ресурсом в 600 тысяч циклов парковки, что вдвое больше, чем у обычных винчестеров.

  • Платформа HelioSeal четвертого поколения

Жесткие диски WD Red Plus и WD Red Pro емкостью 8 терабайт и более созданы на базе платформы HelioSeal версии 4.0. Их корпуса абсолютно герметичны и заполнены инертным газом гелием, плотность которого практически в семь раз меньше плотности воздуха. Низкое сопротивление газовой среды дало возможность использовать более тонкие магнитные пластины, что позволило увеличить их количество, а снижение силы трения способствовало сокращению энергозатрат на раскрутку шпинделя. В свою очередь, уменьшение турбулентности помогло повысить точность позиционирования магнитных головок, благодаря чему удалось уменьшить зазор между ними и поверхностью блинов, а также сократить площадь треков, расположив их более компактно.

Как следствие, гелиевые накопители оказываются не только вместительнее, но и практически на 50% экономичнее и на 45C холоднее воздушных аналогов, что делает такие устройства идеальным решением для эксплуатации в составе сетевых хранилищ, работающих в режиме 24/7, а также ультракомпактных устройств серии My Cloud, потенциал системы охлаждения которых ограничен вследствие малых размеров корпуса.

  • Защита от вибрации

При вращении на каждую магнитную пластину действуют дисбалансирующие силы, причем одновременно в двух плоскостях: горизонтальной (блины смещаются в плоскости сечения оси шпинделя) и вертикальной (вектор приложен перпендикулярно, блок пластин как бы колеблется вверх-вниз). Чтобы нивелировать перечисленные эффекты, в заводских условиях проводится тщательная балансировка каждого устройства, в ходе которой подбирается оптимальная длина фиксирующих винтов. Помимо этого, мы используем систему демпферов и амортизаторов, которые эффективно гасят возникающую вибрацию. Данный комплекс мер получил название 3D Active Balance Plus.

Дополнительную надежность механизму придает технология StableTrac, предусматривающая двухстороннюю фиксацию вала электропривода.

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

  • Прошивка NASware 3.0

Фирменная микропрограмма Western Digital гарантирует совместимость накопителей с широким спектром материнских плат и дисковых контроллеров, что полностью исключает возникновение конфликтов между комплектующими на аппаратном уровне. Поддержка набора команд ATA Streaming Feature Set обеспечивает возможность параллельного выполнения операций чтения/записи за счет оптимизации использование кэш-памяти диска, благодаря чему вы сможете использовать NAS в качестве мультимедийного сервера, транслируя потоковое видео одновременно на несколько устройств и не опасаясь падения производительности системы хранения.

В свою очередь, поддержка технологии TLER (Time Limited Error Recovery) помогает дополнительно обезопасить вашу цифровую коллекцию за счет наличия обратной связи между накопителем и RAID-контроллером. Все дело в том, что даже при штатной работе жесткого диска неизбежно возникают ошибки считывания, обусловленные нестабильностью сектора или сбоем во время записи. В подобных случаях HDD действует согласно следующему алгоритму:

  • происходит повторная попытка записи в тот же сектор с последующим контрольным чтением;

  • если уровень сигнала по-прежнему остается низким, контроллер расценивает это как однозначный признак износа магнитного покрытия;

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

Схема отлично работает, когда речь идет об одиночных винчестерах, однако, если накопители объединены в массив, в дело вступает RAID-контроллер, который должен отслеживать состояние каждого устройства. Проблема в том, что во время коррекции ошибок диск не реагирует на отправляемые команды, и, если период латентности превышает 7 секунд (по умолчанию), диск исключается из массива, так как контроллер воспринимает такое молчание как признак отказа оборудования.

TLER решает данную проблему следующим образом. При выявлении ошибки инициируется стандартный алгоритм коррекции, однако, если уложиться в положенное время не удается, диск отправляет сигнал RAID-контроллеру. Последний фиксирует сообщение в журнале, откладывая процедуру исправления до более удачного момента (например, до простоя системы), что позволяет не только полностью исключить вероятность произвольного распада массива, но и дополнительно снизить нагрузку на систему хранения.

Все перечисленное делает жесткие диски семейства WD Red Plus практически идеальным решением для построения высокоемкого производительного NAS, который поможет сохранить ваши любимые фильмы, музыку, компьютерные игры, записи любимых шоу и другой цифровой контент и оградить вашу коллекцию от вероломных действий со стороны правообладателей.

Подробнее..

Нагрузочное тестирование СХД на Эльбрусе на базе нового ядра Линукс версии 5.4

31.05.2021 06:09:55 | Автор: admin


Тестирование СХД Аэродиск Восток на базе процессоров Эльбрус 8С на новом ядре 5.4 показало крайне позитивный результат: 1,4 миллиона IOPS! Пока оптимисты верили и надеялись, а пессимисты снисходительно улыбались, программисты работали писали код. В итоге новая версия ядра Линукс v5.4 для архитектуры Эльбрус позволила в разы улучшить производительность подсистемы ввода-вывода и полностью реализовать процессора Эльбрус 8С/СВ для систем хранения данных.


По этому прекрасному поводу мы в Аэродиске, предварительно обновив боевую версию встроенного Альт-Линукса в СХД ВОСТОК до ядра 5.4, повторно выполнили нагрузочное тестирование СХД, которое мы публиковали полгода назад. С прошлым отчетом можно ознакомиться по данной ссылке.


Новые тесты проводились на долгожданном ядре Линукс для e2k версии 5.4, которое появилось начале 2021 года, за что хотим сказать огромное спасибо коллективам разработчиков МЦСТ, Базальт СПО, а также Михаилу Шигорину лично.


В ядре 5.4 изменений много, но нас интересуют только основные изменения с точки зрения СХД, а их можно разделить на следующие группы:


Общие обновления:


  • переработан планировщик ввода-вывода, что позволяет лучше параллелить IO между дисками;
  • много мелких оптимизаций под скоростные твердотельные накопители;
  • и самое главное изменение новый компилятор от МЦСТ (LCC версии 1.25).

Обновления от Аэродиска:


  • обновлённый таргет-драйвер, который позволяет лучше параллелить IO между процессорными ядрами;
  • обновление логики работы связки ядро процессора диск для систем на Эльбрусе.

Тестовый стенд


Тестирование мы выполняли на том же железе, что и в прошлый раз. Стенд состоит из сервера с Линуксом, подключенного через FC-коммутатор к двум контроллерам СХД Восток, в которой установлено 12 SAS SSD дисков.


Конфигурация оборудования следующая:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16G 1 шт.
  • СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Ниже схема стенда.



Методика тестирования


Также как и в прошлый раз для нагрузочных тестов мы использовали популярную и проверенную временем программу Flexible IO (FIO).


СХД сконфигурирована исходя из наших рекомендаций к высокой производительности на блочном доступе или просто настройки для ALL-Flash систем. Поэтому используем не менее двух дисковых пулов DDP (Dynamic Disk Pool). Чтобы не бить в одну точку и максимально реализовать вычислительный потенциал платформы создаем несколько LUN-ов в RAID-10 (8 шт. по 500 ГБ каждый).


Все LUN-ы презентуем двум контроллерам (пополам, по 4 каждому), чтобы максимально утилизировать все ресурсы СХД.


В ходе тестирование будут выполняться следующие популярные сценарии использования СХД, в частности:


Последовательная нагрузка маленькими блоками 4k


  • 100%_read_4k_sequential
  • 100%_write_4k_sequential

Случайная нагрузка маленькими блоками 4k


  • 100%_read_4k_random
  • 100%_write_4k_random

Последовательная нагрузка большими блоками 128k


  • 100%_read_128k_sequential
  • 100%_write_128k_sequential

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


Во всех тестах мы, чтобы не искажать результаты тестирования, намеренно отключаем RAM-кэш СХД, который используется для ускорения ввода-вывода, компрессии и дедупликации. Забежим вперед и отдельно скажем про утилизацию оперативной памяти СХД в целом (чтобы к этому вопросу больше не возвращаться). Во всех тестах RAM утилизируется практически одинаково, т.е. слабо, т.к RAM-кэш, дедуп и компрессия отключены. Вся утилизация RAM это внутренние системные операции СХД. Если бы мы включили RAM-кэш, то результаты были бы заметно лучше, но тогда тест был бы не совсем честным. При этом график утилизации оперативки мы для порядка все-равно приводим в отчете ниже.


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


100%_read_4k_sequential

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=read
numjobs=16
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/read-iodepth-128-numjobs-16
write_iops_log=./logs/read-iodepth-128-numjobs-16
write_lat_log=./logs/read-iodepth-128-numjobs-16
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_write_4k_sequential

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=write
numjobs=16
runtime=2400
time_based=1


write_bw_log=./logs/4k-seq-write.results


write_iops_log=./logs/4k-seq-write.results


write_lat_log=./logs/4k-seq-write.results


[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_read_4k_random

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=64
group_reporting
rw=randread
numjobs=2
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/4k-rand-read.results
write_iops_log=./logs/4k-rand-read.results
write_lat_log=./logs/4k-rand-read.results
[job-1]
filename=/dev/sdc
[job-2]
filename=/dev/sdd
[job-3]
filename=/dev/sde
[job-4]
filename=/dev/sdf
[job-5]
filename=/dev/sdg
[job-6]
filename=/dev/sdh
[job-7]
filename=/dev/sdi
[job-8]
filename=/dev/sdj


100%_write_4k_random

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=16
group_reporting
rw=randwrite
numjobs=2
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/4k-rand-write.results
write_iops_log=./logs/4k-rand-write.results
write_lat_log=./logs/4k-rand-write.results
[job-1]
filename=/dev/sdc
[job-2]
filename=/dev/sdd
[job-3]
filename=/dev/sde
[job-4]
filename=/dev/sdf
[job-5]
filename=/dev/sdg
[job-6]
filename=/dev/sdh
[job-7]
filename=/dev/sdi
[job-8]
filename=/dev/sdj


100%_read_128k_sequential

[global]
blocksize=128k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=read
numjobs=16
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/128k-seq-read.results
write_iops_log=./logs/128k-seq-read.results
write_lat_log=./logs/128k-seq-read.results
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_write128k_sequential

[global]
blocksize=128k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=16
group_reporting
rw=write
numjobs=2
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/128k-seq-write.results
write_iops_log=./logs/128k-seq-write.results
write_lat_log=./logs/128k-seq-write.results
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]


Результаты тестов


Последовательная нагрузка маленькими блоками 4k


100%_read_4k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_4k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Результаты теста с использованием последовательного характера нагрузки небольшими блоками 4k нас впечатлили, получилось !1,4 миллиона! IOPS на чтение и 700k на запись. Если сравнивать это с предыдущим нашим тестом на ядре 4,19 (371k и 233k IOPS), то это скачек в четыре раза при том, что железо мы не меняли.


Также отмечаем довольно небольшую утилизацию CPU, она примерно на 20% ниже предыдущего теста (69/71% против 76/92%).
Задержки при этом остались на том же уровне, что и полгода назад, это не значит, что с этим мы думаем мириться, это значит, что над этим мы ещё будем работать. В конце статьи, будет итоговая таблица сравнения с тестом полугодовой давности на ядре 4,19.


Случайная нагрузка маленькими блоками 4k


100%_read_4k_random
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_4k_random
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Показатели случайной нагрузки маленькими блоками, характерной для транзакционных СУБД остались практически без изменений по сравнению с прошлым тестом. СХД Восток на Эльбрусе вполне нормально справляется с подобными задачами, выдавая 118k IOPS на чтение и 84k IOPS на запись при довольно высокой утилизации CPU.


Отмечаем, что для Эльбруса в отличии от других процессоров работа в режиме постоянной загрузки близкой к 100% является штатной ситуацией (он для этого создавался). Мы это проверяли, оставляя СХД Восток с нагруженным процессором под 95% на несколько дней и результат был следующий: 1) процессор был холодный; 2)процессор и система в целом работали в нормальном режиме. Поэтому к высокому уровню утилизации процессоров Эльбрус следует относиться спокойно.


Также с прошлого ядра сохранилась приятная особенность. Если посмотреть на задержки при случайной нагрузке маленькими блоками, то внимание привлекает то, что задержки на запись ниже, чем на чтение (3 мс против 8 мс), когда мы все привыкли, что должно быть наоборот. Эльбрус с точки зрения случайного характера нагрузки по-прежнему любит запись больше чем чтение, что несомненно является отличным преимуществом, которое грех не использовать.


Последовательная нагрузка большими блоками 128k


100%_read_128k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_128k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Ещё полгода назад СХД Восток на базе процессоров Эльбрус показала отличный результат в тесте последовательной нагрузки большими блоками, что актуально для видеонаблюдения или трансляций. Особой фишкой Эльбруса были ультранизкие задержки при работе с большими блоками (0,4-0,5 мс против 5 6 мс у аналогичного процессора архитектуры x-86).


При чтении данных большими блоками данное преимущество удалось не только закрепить, но и развить. Максимальную скорость на новом ядре удалось поднять в два раза (5,7 ГБ/с на ядре 5.4 против 2,6 ГБ/с на ядре 4.19) при задержках 0,3 мс! Также нагрузка на процессор при данном тесте тоже выглядит лучше (52% на 5,4 против 75% на 4,19).


А вот с записью не так все радужно. К сожалению, в новой версии ядра получить ультранизкие задержки на запись уже не удается, во всяком случае пока. Они находятся на уровне 11 мс (а было 0,5 мс), что в целом не плохо, т.к. примерно такой же уровень задержек при таком тесте мы видим на процессорах других архитектур. Так или иначе это наше домашнее задание, над которым мы будем работать. При этом позитивный момент все-таки есть. Как и в других тестах утилизация процессора значительны снижена (74% против 95%).


Итоговые результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8 С, ядро 5.4


Улучшение в 5.4 зеленые, ухудшения 5.4 оранжевые


Для сравнения, результаты тестирования АЭРОДИСК ВОСТОК на базе процессоров Эльбрус 8С, ядро 4.19


Улучшение в 5.4 зеленые, ухудшения в 5.4 оранжевые


Прогресс виден не вооруженным глазом! Новая версия ядра 5.4 для архитектуры Эльбрус позволила выжать практические максимумы из совсем не нового процессора Эльбрус 8С (2016 г. выпуска). На данный момент даже у самых ярых пессимистов уже не повернется язык назвать процессор Эльбрус медленным, все таки полтора миллиона IOPS это много.


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


Кроме того, Эльбрус отлично себя показывает в случайной нагрузке на запись, показывая минимальные задержки, что актуально для классических транзакционных СУБД.


Безусловно есть ещё над чем работать (те же задержки при записи больших потоков), но за прошедшие полгода коллектив МЦСТ проделал титаническую работу, и она дала видимый результат, что не может не радовать.


В конце этого 21-ого года мы ожидаем новый процессор Эльбрус 16С, который, кроме того что будет намного быстрее, ещё будет поддерживать аппаратную виртуализацию, а это значит что у нас в России наконец-то появится полностью отечественные не только СХД, но и системы виртуализации, и гиперконвергентные системы (кто сказал АИСТ и vAIR?))).


Кстати о птичках! В течение этой недели мы определимся с датами следующего технического вебинара ОколоИТ про нашу систему виртуализации АИСТ и гиперконвергентную систему vAIR, ссылка на регистрацию появится в этой статье (следите за обновлением), а также в нашем телеграмм-чате.
Ну и само собой, не можем не напомнить о бесплатных курсах по системам Аэродиск, на которые можно записаться тут.


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

Подробнее..

Как мы внедрили свою модель хранения данных highly Normalized hybrid Model. Доклад Яндекса

26.05.2021 12:10:08 | Автор: admin
Общепринятый и проверенный временем подход к построению Data Warehouse (DWH) это схема Звезда или Снежинка. Такой подход каноничен, фундаментален, вотрфоллен и совсем не отвечает той гибкости, к которой призывает Agile. Чтобы сделать структуру DWH гибкой, существуют современные подходы к проектированию: Data Vault и Anchor modeling похожие и разные одновременно. Задавшись вопросом, какую из двух методологий выбрать, мы в Яндекс Go пришли к неожиданному ответу: выбирать надо не между подходами, а лучшее из двух подходов.

Темы доклада, который вместе со мной прочитал Николай Гребенщиков:
DV и AM: в чем разница и где точки соприкосновения
Гибридный подход к построению хранилища
Сильные и слабые стороны этого подхода
Примеры кода
Дальнейший вектор развития hNhM

Меня зовут Евгений Ермаков, я руководитель Data Warehouse в Яндекс Go.

Я расскажу историю о том, как два руководителя объединились и сделали нечто крутое как минимум, по мнению этих двух руководителей. Расскажу про наш подход к хранению данных в детальном слое. Мы его называем highly Normalized hybrid Model. Надеюсь, что корректно произнес по-английски, я тренировался.

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



Рассказ у нас будет достаточно долгий, из двух глав. Первая глава будет моя я расскажу, как мы вообще к этому пришли. Она, наверное, будет для тех, кто сведущ в этой теме, или послужит повторением того, что вы уже знаете.

Также я расскажу про архитектуру хранилища Яндекс Go в целом, вместе с детальным слоем, где как раз эта модель и применяется. Потом сравню Data Vault и якорное моделирование так, как мы у себя их сравнивали, и объясню, почему мы из этого сравнения сделали вывод, что нужно создавать нечто свое. И расскажу базисные основы про hNhM.



А во второй главе я передам слово Коле.

Николай Гребенщиков:
Я расскажу о нашем фреймворке, который позволяет нам описывать сущности и загружать данные. Покажу, как мы с ним работаем, как загружаем используем и строим витрины над нашим детальным слоем.

В конце мы подведем итоги, самое главное, что можно из этого доклада почерпнуть. посмотрим, куда мы пришли, что сделали и как это можно переиспользовать.



Итак, архитектура Data Warehouse (DWH) в Яндекс Go. Расскажу об архитектуре слоев данных, какая она у нас, какие инструменты хранения и обработки информации есть, и покажу место детального слоя во всей этой архитектуре.



По моему мнению, архитектура слоев данных в нашем хранилище максимально классическая. Мы шли от глаголов действий над данными, которые происходят с хранилищами. Что мы делаем с данными?

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

Потом мы предоставляем эти данные для анализа, непосредственно анализируем и все. Классика.

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



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

Задача этого слоя сформировать набор сущностей источника и предоставить стандартный интерфейс доступа к этим данным, вне зависимости от особенностей источника. Все примерно в стандартном виде.

Дальше детальный слой. Ядро хранилища. Здесь мы храним детальную историю изменений и консолидируем данные между всеми источниками.



На базе этого детального слоя есть слой витрин Common Data Marts.



Здесь мы уже формируем плоские, удобные для аналитиков витрины и оптимизируем доступ на чтение.



В слое отчетов мы храним отчетные срезы в контексте без потребителя, агрегаты, нечто более понятное для потребителя.



В итоге классика, все по слоям, от RAW до REP. Данные протекают в хранилище, все как завещали Кимбалл и Инмон в своих подходах.

Если это рассматривать прямо по системам, то для того, чтобы захватывать данные, у нас есть сервис репликации данных. Он забирает инкременты и снепшоты из источников самых разных типов, которые есть в Яндексе. И преобразовывает эти данные к устойчивому формату.



RAW, ODS это такой Data Lake. Здесь у нас полуструктурированные данные, каркас MapReduce и всевозможные внутренние аналоги экосистемы Hadoop.

Центр хранилища это непосредственно Data Warehouse. Здесь у нас слои ODS, DDS, CDM.



Основные цели давать ответ на всевозможные ad-hoc-запросы наших аналитиков, выдерживать большое количество Join и достаточно малое время отклика на всевозможные вопросы.

И витрины. Помимо того, что они служат Data Warehouse, мы еще отгружаем их содержимое в системы анализа и визуализации данных. Это кубы данных, отчеты, дашборды, Tableau.



Если мы эти слои разложим по системам, то получится приблизительно такая картина.

То есть RAW, ODS и части CDM-слоя на супербольших данных это у нас Data Lake.



Маленькая ремарка: в Яндексе много внутренних инструментов, которые мы делаем сами. У нас есть своя собственная платформа, есть такие внутренние инструменты, как YT. Можно проводить аналоги: YT это как Hadoop. И в принципе, есть всевозможные аналоги Hadoop-стека.

На Greenplum у нас находятся часть слоя ODS, детальный слой и витрины. Построенные в Greenplum витрины мы затем отгружаем в MS SSAS или ClickHouse для ряда пользователей. Некоторым удобно пользоваться кубами данных, некоторым широкимb плоскими таблицами, и ClickHouse здесь прямо идеален.

Часть витрин доступно для биосистем, или мы делаем из них агрегаты, доступные для нашего BI. BI у нас это Tableau.

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

Смотреть доклад Владимира

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

Если посмотреть на детальный слой, он не зря находится в самом центре хранилища, потому что это ядро, сердце, ключевое для построения всей доменной модели хранилища.



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

Два важных пункта. Детальный слой должен быть устойчив к изменению в бизнесе. Это достаточно сложно: допустим, мы изменили кардинальные связи или добавили новые сущности. Или у нас полностью изменился подход к бизнесу.

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

Когда мы начали проектировать детальный слой, то провели анализ а какие подходы к построении детального слоя вообще есть? Первое, что приходит на ум, это когда нет никакого детального слоя или подхода.

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

А подход, который называется никакого подхода, это когда мы просто сваливаем данные в кучку и потом пытаемся их них что-то извлечь. Если огрублять, это что-то вроде болота данных.

К сожалению, такой подход тоже имеет право на жизнь только потому, что он часто встречается. Так-то он, конечно, не имеет права на жизнь. Тем не менее, тут у нас денормализация. Можно использовать без подготовки в том плане, что легко селектить. Однако здесь нет устойчивости к изменениям, при любых изменениях в источнике придется все это перестраивать.



Пойдем дальше. Следующий подход классическая звезда и снежинка. Нормализация до третьей нормальной формы, то, что описывал у себя Билл Инмон. Это можно использовать с минимальной подготовкой нужно понимать, что такое первичный ключ, внешний ключ, join-таблички, SCD2, если мы говорим про измерения. И понимать, какие SCD вообще существуют.

Это может быть неудобно перестраивать при изменении кардинальности. Например, есть клиент и заказ. У одного клиента может быть много заказов, но у одного заказа только один клиент. Бизнес поменялся, у одного заказа теперь может быть несколько клиентов, и клиенты могут делить между собой заказ, как это, например, реализовано в такси. Перестраивать все это крайне больно.

При этом минимальное дублирование информации, если мы используем SCD. И какое-то приемлемое количество join. Если аналитики работают с SQL, они должны уметь работать и с этим.

Следующие походы Data Vault и Anchor modeling. Почему я их вывел одновременно? Потому что они предлагают, на самом деле, нечто очень похожее. Это достаточно строгая нормализация, их сложно использовать без подготовки, без понимания, какие таблицы и какие правила они накладывают.



Обе методологии обещают, что их не надо перестраивать. Для Data Vault это работает с ограничениями, я дальше проговорю, какими. Здесь ультрабольшое количество join. При этом обе методологии относительно современны и обещают гибкость.

Посмотрим на эксплуатацию. Все, что справа, Data Vault и якорное моделирование достаточно сложно эксплуатировать из-за большого количества join. Чем больше join, тем сложнее писать SQL-запросы и в целом получать отсюда информацию. При этом проще вносить изменения в модель. Во всяком случае, обе методологии это обещают.

И наоборот, если у нас никакого подхода нет и мы всё вкладываем в плоскую табличку или нормализуем, то эксплуатировать проще. join или вообще нет, или их приемлемо малое количество. Но при этом вносить изменения, перестраивать сложно.

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



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

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

Сперва стоит спрогнозировать требования, а потом подумать, согласовать, подумать еще. Я уверен, что все, кто работал с классическими DWH, которые построены не по Data Vault или по якорю, понимают, что DWH это не быстро.

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

И вообще, у нас Agile, мы гибкие, давайте все переделывать максимально быстро. Желательно, завтра. Примерно так выглядит классический дэвэхашник, когда попадает в Agile-среду, в которой невозможно использовать Waterfall.

Логичные вопросы: откуда родились методологии Data Vault и якорь; может ли DWH быть agile; можно ли подходить к разработке хранилища гибко?

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



Взамен они обещают уменьшить постоянное дублирование данных в SCD2, если у нас меняется только один атрибут. Те, кто работают с SCD2, знают, что если у нас большое измерение, много атрибутов, а меняется только один, то нам приходится снова эту строчку вставлять. И это больно. Обе модели обещают избавить от деструктивных изменений, только расширять модель и позволить дорабатывать хранилище легко и быстро. Мистика для любого хранилищного аксакала.



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

Data Vault вводит и регламентирует несколько основных тип таблиц. Ключевые это Hub, Link и Satellite, дальше я буду о них говорить. Hub хранит сущности, Link обеспечивает связь между хабами, Satellite предоставляет атрибуты и описания Data Vault.

Data Vault 2.0 я не буду касаться. Есть еще специальные таблицы типа bridge и point-in-time. Они упрощают или соединение данных через несколько связей, или получение информации из сателлитов с разной частотой обновления. Это скорее расширяющие, упрощающие модель сущности. Ключевые таблицы это все-таки Hub, Link и Satellite.

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



Link или связь это физическое представление отношения между сущностями. При этом они всегда реализованы в виде таблиц многие-ко-многим, в виде отдельных таблиц. Атрибуты Link включают в себя суррогатный ключ Link, ключи хабов в зависимости от того, какие хабы связаны через эту связь, и техническую информацию временную отметку даты загрузки и код источника.

Satellite или сателлит это описательная информация хаба, обычно с историзмом по SCD2. Здесь есть информация о ключе связи или хаба, в зависимости от описательных характеристик того, что находится в этом сателлите, сама информация и технические записи: SCD2, временная отметка даты загрузки, код источника данных.

Если на это посмотреть с точки зрения третьей нормальной формы, то есть вот такая неплохая картинка из презентации самого автора Data Vault:


Ссылка со слайда

Посмотрим на третью нормальную форму. Видно, что бизнес-ключи мигрируют в хабы. Все внешние ключи мигрируют и фактически являются связями. А все описательное, все наши поля, которые несут какой-то смысл, уходят в сателлиты. Сателлитов может быть несколько. Нет явных правил, как правильно разбить атрибуты на сателлит. Есть разные подходы: можно бить по частоте изменений, по источнику, по чтению это такой творческий момент в Data Vault.



Если мы посмотрим на якорное моделирование, то я бы его сформулировал как такую крайнюю форму Data Vault, когда у нас правила еще строже и нормализация еще выше.

У этой методологии есть четыре основных типа таблиц якорь, атрибут, связь и узел. Про узел я не буду подробно рассказывать, фактически это словарь ключ-значение. А про якорь, атрибут и связь сейчас коротко расскажу.

Якорь фактический аналог хаба с важным отличием: здесь нет бизнес-ключей, есть только суррогатный ключ и временная отметка даты загрузки, техническая информация. Все бизнес-ключи фактически являются атрибутами и хранятся в таблицах атрибутов.



Tie связь многих ко многим, один в один как в Data Vault. Внешние таблицы это принципиальный момент, даже если кардинальность связи другая. Но в якорном моделировании есть отличие у связи принципиально не может быть атрибутов.

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

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

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



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



Внешние ключи находятся в наших связях.


Ссылка со слайдов

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

Возникает вопрос: нельзя ли хоть как-нибудь прохачить систему и навесить атрибут на связь? Можно через словарь. Но это именно что словарик, некий типизатор связи. Ничего более сложного на связь в якорной модели навесить нельзя.

Посмотрим на стандартный тест TPC-H. Я уверен, что многие из вас знают, что это такое, но кратко напомню: это стандартный тест для проверки аналитических хранилищ, внизу на слайде есть ссылка на одну из его версий.


Ссылка со слайда

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

Если мы эту схему преобразуем в Data Vault, то видно, насколько больше таблиц становится, появляются отдельные хабы, отдельные Link. Причем Link сделаны в виде таблиц многие-ко-многим.


Ссылка со слайда

У нас вешаются сателлиты как на Link, так и на отдельные хабы. И в целом, таблица становится больше.

Если мы это конвертируем в якорную модель, получится нечто подобное.



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

В чем же схожести и различия, если их в лоб сравнивать?



И в Data Vault, и в якоре создается специальная таблица на сущность. В Data Vault это Hub, в якоре это якорь. Разница в том, что в хабе есть бизнес-ключ, а в якоре бизнес-ключ это атрибут.

В Data Vault атрибуты группируются в таблицы-сателлиты. В якоре все строже: один атрибут одна таблица, шестая нормальная форма, все раскладываем на отдельные кубики-элементы.

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

И есть специальные таблицы, в Data Vault point in time и bridge, в якоре knot.

Когда мы вот так, в лоб, их сравнили, ощущение было что выбрать? В чем-то лучше якорь, в чем-то Data Vault. У каждого достаточно цельная методология. Якорь построже, но, с другой стороны, возникает меньше вопросов и больше пространства для автоматизации.


В общем, как-то так. Яндекс славится тем, что создает свои инструменты. Почему бы нам не создать свою модель?

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



Из этой идеи и родилась наша гибридная модель highly Normalized hybrid Model, hNhM. Здесь я кратко расскажу ключевые идеи модели. (...)



Ключевая идея выбирать оптимальный формат хранения. Мы не ограничиваем себя ни Data Vault, ни строгостью якоря. Но при этом позволяем выбрать либо одно, либо другое. А если мы позволяем это выбрать, то с точки зрения методологии классно было бы разделить логическое и физическое моделирование.

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

И удобство построения витрин. Потому что да, таблиц очень много, есть большой риск написать не оптимально. Это даже не то чтобы риск. Просто вокруг тебя раскиданы мины. Очень хочется дать инструментарий, чтобы со всем этим было удобно работать.

Если пойти по этим идеям, посмотреть очень верхнеуровнево, то мы это представляли так.



У нас есть слои, про которые я рассказывал, RAW. ODS это наш Data Lake. В RAW мы захватили данные, они лежат как есть. В ODS мы их чуть почистили, но это операционные данные, без истории. В детальном слое мы фактически разложили это все на маленькие кубики-сущности. С точки зрения логического проектирования это сущности-связи между ними. С точки зрения физического хранения на нашем Greenplum это скрыто с точки зрения использования.

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

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

Про разделение логического и физического уровня. Мы хотели на старте их разделить явным образом.

Логический уровень это всем известные ER-диаграммы. Уверен, что все, кто работает с данными, про ER-диаграммы знает. Здесь есть сущности и их ключи, связи между сущности и атрибутивный состав сущностей. Мы еще добавили необходимость их историзации, но это как дополнительная информация к атрибутам.

Логический уровень когнитивно сложная часть проектирования. Он не зависит от СУБД в общем виде и достаточно сложен. Трудно выделить сущности и домены в бизнесе, особенно если ты его не знаешь так, как основатели этого бизнеса.



Физический уровень это скрипты DDL. Здесь выполняется партицирование сущностей, объединение атрибутов в группы, дистрибьюция в системах MPP. И индексы для ускорения запросов. Все перечисленное мы хотели скрыть. Во-первых, оно зависит от СУБД и технических ограничений, которые у нас есть. Во-вторых, нам хотелось сделать так, чтобы этот физический уровень был невидим, чтобы мы могли переключаться между Data Vault и якорем, если захотим.



Разделяя так логический и физический уровень, мы фактически делим задачи между нашими ролями. У нас есть две роли:

  • Партнер по данным, Data Partner. Мы так переименовали Data steward. Да, слово steward имеет здравое значение в переводе: распорядитель чего-то чужого, а данные в этом смысле чужие. Но все равно партнер по данным звучит гораздо лучше.

    Партнер по данным на логическом уровне должен ответить на вопрос концептуальной модели: какие вообще направления бизнеса и взаимосвязи между ними у нас есть, как часто будут меняться атрибуты. И из этого построить логическую модель, прямо по классике.
  • И инженер данных, здесь все классически. Он отвечает на вопросы физической модели: как хранить атрибуты, нужны ли партиции, нужно ли закрытие SCD2. И обеспечивает сам расчет данных по инкременту, а также пересчет истории, то есть фактически ETL-процесс.

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



В итоге, базируясь на ER-диаграммах, мы используем сущность и связь. Сущность базовый кубик любого описания домена. Здесь, на логическом уровне, мы хотели сделать так, чтобы сущности описывались наименованием и комментарием; именем сущности и его описанием; бизнес-ключом, который обязателен для любой сущности, чтобы понимать, что его определяет; и каким-то набором атрибутов.

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

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

Атрибут это таблица. Она содержит информацию об одном атрибуте, может содержать историю, а может не содержать. Group это группа атрибутов, как сателлит в Data Vault. Она может содержать информацию о нескольких атрибутах. Важное ограничение на уровне модели: все атрибуты должны приходить в эту группу сателлита из нового источника и иметь один тип историзма.



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

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

Итого мы получаем примерно такую картинку: На логическом уровне рисуем ER-диаграмму или описываем нашу сущность.



А на физическом уровне получаем вот такой набор таблиц. Видно, что тут есть и группы атрибутов, и просто атрибуты, и связи. Хотелось бы, чтобы все это было скрыто. Причем на обоих уровнях работы с DDS: и на загрузке данных, и на построении витрин.



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

Мы хотим скрыть сложности загрузки SCD2. Если приходят данные, то мы в этом месте требуем, чтобы в слое DDS обязательно помимо ключа была еще дата, актуальная с точки зрения бизнеса, по которой мы простраиваем SCD2 в детальном слое.

На уровне построения витрин скрываем сложность групп, связей, хабов. Мы работаем с сущностями на логическом уровне, а они с таблицами на физическом уровне. Это нам позволяет скрыть сложности исторической обработки записей и максимизировать простоту работы с инкрементом.

Всего тут есть три концептуальные идеи:

  • Закрепить разделение логического и физического проектирования в методологии, полностью закрыть физическое проектирование.
  • Сокрытие физического проектирования провести как при загрузке данных, так и при использовании модели, чтобы было удобно загружать и строить витрины.
  • И так как мы все сокрыли с физической точки зрения, то нужно еще выбирать оптимальный формат хранения для каждого конкретного случая: группировать и догруппировать атрибуты. Все это скрыто внутри.

Если возвращаться к Data Vault и якорю, то фактически из Data Vault мы взяли сателлиты и назвали их у себя группой атрибутов. Позволили отойти от этой строгости якоря, где один атрибут одна таблица.

Из якоря мы взяли к ебе сам якорь. То есть мы не храним бизнес-ключи в ключевой таблице, а смотрим на них как на еще одни атрибуты. Связи идут через отдельную таблицу, как в Data Vault или якоре, но мы запретили вешать на них атрибуты. В перспективе хотим разрешить.



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

Из Data Vault мы взяли специальные таблицы point in time и bridge для упрощения своей собственной внутренней работы с hNhM.

И если подводить итог, этим всем категорически невозможно управлять без фреймворка. Если вы попробуете все это воссоздать полуавтоматически или DDL-скриптами, то можно буквально убиться об количество таблиц и весь объем данных, метаданных, которыми надо управлять.



Поэтому мы разработали так называемый hNhM-фреймворк. Здесь я передаю слово Коле. Он подробно расскажет, что мы конкретно разработали и как мы этим пользуемся у себя внутри.

Да, я расскажу о нашем фреймворке что сделали, как храним и как с этим работаем.

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

Смотреть доклад Владимира

В левой части сервис репликации, написанный в Go на базе MongoDB, которая позволяет получать данные из всех возможных источников. Это может быть как реляционная база данных, так и нереляционная. Это может быть API, при этом и мы можем читать из API, и API может к нам пушить данные. То есть перед нами вещь, которая в себе собирает изменения.



В центральной части находится наш Data Lake, который хранится на YT. Это аналог экосистемы Hadoop, в нем мы храним слои RAW и ODS. Сейчас у нас объем данных около двух петабайт.

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

Детальный слой основной элемент хранилища на Greenplum. На его основе мы строим все наши витрины.



Отличительная особенность платформы: все сущности на всех слоях описываются в питонячем коде, но это видно и на слайде. Особенности описания сущностей в DDS мы рассмотрим на основе сущностей Person сотрудник.



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

Для чего нам нужна документация? На ее основе во время релиза платформа собирает документацию по всем нашим объектам и автоматически выкладывает на внутренний ресурс, это удобно для пользователей. Потому что им не надо следить за анонсами по изменению структуры. Они могут пойти в документацию, попробовать найти то, что им нужно, и начать пользоваться данными.



Далее необходимо описать технические параметры layout. С помощью трех полей Layer, Group и Name мы определяем путь до места хранения объекта в нашем хранилище. Неважно, будет ли это YT, Greenplum или что-то еще в будущем.



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

Для каждого атрибута указываем тип историчности.



Сейчас у нас есть три типа. Ignore это когда пришедшее значение записывается, а мнение с большей бизнес-датой игнорируется. Update когда при изменении значение перезаписывается. New исторический атрибут.

Атрибуты с Ignore и Update не хранят историю изменений и отличаются тем, что в Ignore предпочтение отдается значению с меньшей бизнес-датой, а в Update с большей.



Также для каждой сущности мы указываем логический ключ.

На слайде видно, во что физически превращается каждая сущность.





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

Также в каждой таблице есть поля, в которых хранятся даты действия атрибута.





Если у данного атрибута историчность New, то это два столбца utc_valid_from_dttm и utc_valid_to_dttm. То есть это метка во времени, с которой определяется действие конкретной записи.

Для атрибутов типа историчности Update и Ignore действует только один столбец: utc_valid_from. Это бизнес-дата, с которой мы узнали, что атрибут имеет текущее значение.





Также в каждой из таблиц находится два системных столбца: дата последнего изменения записи и система источника, из которой пришел этот атрибут.

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



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

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

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

Структура после объединения части атрибутов в группы выглядит уже гораздо более компактно.





Например, все флаги мы объединили в группу flg, общую информацию в группу info, ключевые атрибуты в группу key.

Теперь поговорим про объявление связей. Каждая связь тоже описывается в отдельном классе.



Атрибутами связи являются сами сущности, поэтому атрибуты Link должны быть объединены с объектами специального класса. Также обязательно для Link указывать ключ. Ключ определяет набор сущностей, которые однозначно идентифицируют строку в Link.

Каждый Link по умолчанию является историческим. Таким образом, в нем всегда есть два поля: utc_valid_from и utc_valid_to.

В этом примере мы делаем Link между департаментом и сотрудником. В данном случае ключом Link является сотрудник.



На слайде мы видим, как это физически реализовано.



Видно, что у Link нет суррогатного ключа, потому что его суррогатным ключом являются все те сущности, которые входят в ключ Link.

Теперь мы обсудим, как загружаем сущности.

Для загрузки был разработан ETL-кубик, который является частью нашего ETL-процесса. Он также описывается на Python. Мы описываем, что подается на вход, как данные распределяются по атрибутам и что является полем с бизнес-датой.



В самом простом случае этот кубик выглядит так.



В самом начале мы описываем источник. Это stage-таблица, для которой есть точно такой же класс, написанный отдельно в платформе.

Также мы указываем поле, в котором хранится бизнес-дата и система-источник.

Далее мы делаем маппинг между атрибутами. Описание таргета состоит из двух частей указание сущности, куда мы загружаем атрибуты, и маппинг самих атрибутов.



Как мы видим, в качестве таргета указана таблица Person. Дальше следует маппинг атрибутов. Это самый простой вариант описания. В реальной жизни все выглядит гораздо сложнее. Например, так.



Мы видим, что из одной stage-таблицы данные грузятся в несколько сущностей. Одна сущность может грузиться несколько раз. Это в данном случае e-mail, он может быть в stage-таблице и персональным, и рабочим.

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

А если нет, то, скорее всего, это ошибка и мы об этом сообщаем пользователю.



Но в ряде случаев мы не можем автоматически этого сделать. Например, в stage-таблицу приходит и персональный почтовый ящик, и рабочий. Но и в обоих Link используется одна и та же сущность e-mail. Мы их специально не разделяем, потому что в реальном мире e-mail единая сущность. В то же время нам надо понять, какое здесь поле, какой Link грузить. Мы добавили специальный параметр, который позволяет определить, какое поле куда идет.

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



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



Дальше я расскажу, как мы используем наш hNhM.

На основе DDS мы строим витрины. Пользователи напрямую могут обращаться к нашим сущностям и просматривать данные.



У нас есть два основных типа потребления данных DDS: ad-hoc-запросы от бизнес-пользователей и построение витрин. ad-hoc-запрос реализован двумя способами либо view, либо через функции. И то и то скрывает реализацию от пользователей.

Витрины мы строим с помощью нашего фреймворка и тоже полностью скрываем реализацию.

Почему нельзя писать чистый SQL для детального слоя? В первую очередь потому, что дата-инженер должен знать о всех сущностях и атрибутах, должен знать, какой тип историчности у конкретного атрибута, и правильно это использовать в запросе.

После изменения описания сущности все витрины, которые использует тот или иной атрибут, теоретически могут развалиться, потому что атрибут был исторический, стал не исторический, и это изменит структуру таблицы.

В конце концов, это просто очень сложно написать что-то с select, где будет 20-30 join.

Как у нас происходит доступ к сущностям из Python?



Было разработано несколько классов, которые позволяют сформировать SQL-запрос к определенной сущности и затем использовать его в построении витрины. Как это выглядит?



Мы описываем CTE. Оно может быть либо историческое, либо актуальное.



В первую очередь мы указываем сущность, которую хотим использовать.



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



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

А так выглядит SQL-запрос для построения витрины. Есть переменные постановки, которые полностью скрывают реализацию. Потом идет сам запрос, который их использует. При этом можно использовать переменные как в визе, так и во временных таблицах. Это уже зависит от объема данных.



Как происходит доступ к сущностям из СУБД?



У нас есть вьюхи и есть две специальные процедуры. Первая get_entity. Она получает в качестве параметров сущность, столбцы и создает временную таблицу, в которой будут, собственно, все необходимые данные процедуры.

И вторая процедура это когда мы от entity к существующей таблице через Link добавляем дополнительную сущность и расширяем нашу табличку. Теоретически ключ у нее даже может поменяться.

А сейчас чуть более подробно покажу, как это работает.



Мы вызываем специальную функцию.



Указываем сущность.



Указываем столбцы, которые необходимо получить. Получить все столбцы сейчас нельзя, потому что для больших сущностей достаточно дорого считать всё вместе. Поэтому мы заставляем пользователя указать конкретные атрибуты, которые он хочет получить.



Дальше указываем временную таблицу, в которую надо положить данные.

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



Примерно так же выглядит добавление сущности к уже созданной таблице.



Мы указываем таблицу, в которой уже есть сущность.



Указываем Link, через который мы хотим подключить дополнительную сущность.



Указываем саму сущность, которую мы хотим добавить.



И столбцы этой новой сущности. При этом мы можем как положить данные в уже существующую таблицу, так и создать новую.



Дальше мы расскажем, какие задачи оптимизации мы решали. Тут я передам слово Жене.

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

Посмотрим на объявление класса. Например, на объявление сущности Person.



В физическом мире мы можем представить ее в виде один атрибут одна табличка.





Это будет вполне нормально с точки зрения якорной модели. А можем ли мы сгруппировать атрибут? Здесь часть сгруппирована: флаги отдельно, информация о персоне отдельно, ключи отдельно, атрибуты отдельно.





Какая схема лучше? С точки зрения загрузки данных все то же самое. С точки зрения чтения данных все это скрыто, Коля про это рассказал. И с точки зрения использования будет одинаково.Не можем ли мы сделать так, чтобы эта физическая модель выбиралась наилучшим, оптимальным образом?



Мы постарались это свести к оптимизационной задаче. У нас буквально стояла проблема с объемом данных на Greenplum. Сейчас она не стоит. У нас действительно полупетабайтовый кластер на Greenplum, это достаточно много. Но еще буквально год-полтора назад даже такого не было.

Перед нами стоял вопрос: как оптимально объединить атрибуты по группам так, чтобы минимизировать объем хранения информации. У нас были метаданные объектов, это все наше описание того, что за объекты у нас есть. Маппинги полей и загрузчиков, количество строк в объекте и инкремент, а также накопленное знание о частоте изменений. У нас свой metaDWH, в который мы складываем всю эту информацию, и могли бы ее переиспользовать.

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

Будем минимизировать занимаемое место на диске. Вот такую задачу мы себе поставили. Как мы ее решали?



Прежде всего мы формализовали и стандартизовали операции, меняющие схему, но не меняющие логику. Они совсем простые и очевидные. Можем объединять группы атрибутов в какую-нибудь еще группу, еще более крупную. Можем разъединять набор групп или вообще разъединить до атрибутов.

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

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



Из них следующие, из них следующие так мы получаем пространство всех возможных состояний, в которые мы можем этими атомарными операциями попасть.

Дальше все просто. Мы из нашего состояния генерим новое мутациями атомарными преобразованиями. Чтобы не обходить все, мы ограничиваем выборку и оцениваем каждое состояние.

Берем лучшие, скрещиваем их между собой, проводим новые мутации и так далее, классический генетический алгоритм.

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

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

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



К чему мы пришли, зачем мы сюда пришли и стоит ли вообще повторять наш путь?

Первый, на наш взгляд, инсайт от доклада сравнение Data Vault и якоря. Мы поняли, что нам нужен детальный слой, что есть современные методологии Data Vault и якорь, и провели между ними сравнение. Они очень похожи. Я воспринимаю якорь как более жесткую форму Data Vault: в последнем есть правила, а в якоре эти правила еще более сложные.



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


Наш вариант это гибридная модель, мы ее назвали hNhM. Требования я не буду перечислять, они на слайде. Основных идей три. Логическое и физическое проектирование, физический мир полностью скрыть как с точки зрения загрузки информации, так и с точки зрения ее получения.

Раз мы все это скрыли, то можем для физического мира выбирать нечто наиболее оптимальное. Оптимизировали именно хранение информации, но можно сделать нечто более интересное, например чтение.

На слайде показано, что мы взяли из Data Vault, а что из якоря.

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



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

Этот путь мы не советуем повторять. Если у вас нет свободной горы разработчиков, которые настолько круто прокачаны в Python, что готовы все это повторить и аккуратно сделать так же, как у нас, лучше не вступать на этот скользкий путь. Вы просто убьете очень много времени и не получите того бизнес-результата, который можно получить, используя Data Vault, якорь или гибридную модель, как мы.



Что же делать? У нас есть большой roadmap развития. Можно добавить больше гибкости например, я говорил, что на связь мы не вешаем ни атрибуты, ни группы. Но здесь можно это реализовать и воссоздать все типы таблиц Data Vault и якоря.

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

DSL у нас хоть и есть, но хотелось бы полноценный язык, который позволит строить витрины с учетом инкремента так, чтобы была полная кодогенерация. Пока она частичная.

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

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

Следите за обновлениями или, если не хотите следить, приходите к нам и создавайте гибридную модель вместе с нами. На этом все. Спасибо за внимание.
Подробнее..

Транзакции. Часть 1. Конспект книги Designing Data-Intensive Applications

16.05.2021 10:11:39 | Автор: admin

Эта статья является конспектом книги Designing Data-Intensive Applications.

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

Транзакции в течение десятилетий считались предпочтительным механизмом решения этих проблем. Транзакция способ группировки приложением несколькихопераций записи и чтения в одну логическую единицу. По сути, все операции записии чтения в ней выполняются как одна: вся транзакция или целиком выполняетсяуспешно (с фиксацией изменений), или целиком завершается неудачно (с прерываниеми откатом). Транзакции значительно упрощают для приложения обработку ошибок,поскольку нет нужды заботиться о частичных отказах.

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

Скользкая концепция транзакции

В конце 2000-х годов приобрели популярность нереляционные (NoSQL) базыданных. Их целью было улучшить существующее положение дел с реляционными БД с помощью новых моделей данных, репликациии секционирования. Транзакции оказались главной жертвой этогоновшества: многие базы нового поколения полностью от них отказались или поменяли значение термина: теперь он стал у них означать намного более слабый наборфункциональных гарантий, чем ранее.

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

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

Обеспечиваемые транзакциями гарантии функциональной безопасности частоописываются известной аббревиатурой ACID (atomicity, consistency, isolation,durability атомарность, согласованность, изоляция и сохраняемость).

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

Системы, не соответствующие критериям ACID, иногда называются BASE: как правило, доступна (BasicallyAvailable), гибкое состояние (Soft state) и конечная согласованность (Eventualconsistency). Это понятие еще более расплывчатое, чем ACID.

Давайте посмотрим на определения атомарности, согласованности, изоляции и сохраняемости. Это позволит уточнить наши представления о транзакции.

Атомарность

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

Напротив, в контексте ACID атомарность не связана с конкурентным доступом.Этот термин не описывает, что происходит, когда несколько процессов пытаютсяобратиться к одним и тем же данным одновременно, поскольку относится к понятию изоляции, то есть букве I в аббревиатуре ACID.

Атомарность в ACID описывает происходящее при сбое в процессе выполнения клиентом несколькихопераций записи, в момент, когда выполнена лишь их часть. Если операции записисгруппированы в атомарную транзакцию и ее не удается завершить (зафиксироватьизменения) из-за сбоя, то она прерывается и базе данных приходится откатить все уже выполненные в рамках этой транзакции операциизаписи.

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

Согласованность

Слово согласованность ужасно перегружено.

  • Согласованность реплик и вопрос конечной согласованности, возникающий в асинхронно реплицируемых системах.

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

  • В теореме CAP слово согласованность используется для обозначения линеаризуемости (linearizability).

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

О первых трех пунктах можно подробнее прочесть в книге. Для репликации и секционирования автор книги выделил по целой главе.

К сожалению, одно и то же слово применяется как минимум в четырех различныхсмыслах.

Идея согласованности в смысле ACID состоит в том, что определенные утверждения относительно данных (инварианты) должны всегда оставаться справедливыми например, в системе бухгалтерского учета кредит всегда должен сходитьсяс дебетом по всем счетам. Если транзакция начинается при допустимом (в соответствии с этими инвариантами) состоянии базы данных и любые производимыево время транзакции операции записи сохраняют это свойство, то можно бытьуверенными, что система всегда будет удовлетворять инвариантам.

Атомарность, изоляция и сохраняемость свойства базы данных, в то время каксогласованность (в смысле ACID) свойство приложения. Оно может полагаться на свойства атомарности и изоляции базы данных, чтобы обеспечить согласованность, но не на одну только базу. По мнению автора книги, букве C на самом деле не местов аббревиатуре ACID.

Изоляция

К большинству баз данных обращается одновременно несколько клиентов.Это не вызывает проблем, когда они читают и записывают в различные части базыданных. Но если они обращаются к одним и тем же записям базы, то могут возникнуть проблемы конкурентного доступа (состояния гонки).

Рис. 1 - Состояние гонки между двумя клиентами, конкурентно увеличивающимизначение счетчикаРис. 1 - Состояние гонки между двумя клиентами, конкурентно увеличивающимизначение счетчика

Изоляция в смысле ACID означает, что конкурентно выполняемые транзакции изолированы друг от друга они не могут помешать друг другу. Классические учебники по базам данных понимают под изоляцией сериализуемость (serializability).То есть каждая транзакция выполняется так, будто она единственная во всей базе.БД гарантирует, что результат фиксации транзакций такой же, как если бы они выполнялись последовательно, хотя в реальности они могутвыполняться конкурентно.

Сохраняемость

Сохраняемость (durability) обязательство базы не терять записанных (успешно зафиксированных) транзакций данных, даже в случае сбоя аппаратного обеспечения илифатального сбоя самой БД.

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

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

Выводы по ACID

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

  • Атомарность. Если посередине последовательности операций записи происходит ошибка, то транзакцию необходимо прервать, а выполненные до тогомомента операции аннулировать.

  • Изоляция. Конкурентно выполняемые транзакции не должны мешать друг другу. Например, если одна транзакция выполняет несколько операций записи, тодругая должна видеть или все их результаты, или никакие, но не какое-то подмножество.

Эти определения предполагают, что необходимо модифицировать несколько объектов (строк, документов или записей) одновременно. Подобные многообъектныетранзакции часто оказываются нужны для обеспечения синхронизации несколькихэлементов данных.

Обработка ошибок и прерывание транзакций

Отличительная особенность транзакций возможность их прерывания и безопасного повторного выполнения в случае возникновения ошибки. На этом принципепостроены базы данных ACID: при возникновении риска нарушения гарантий атомарности, изоляции или сохраняемости БД скорее полностью отменит транзакцию,чем оставит ее незавершенной.

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

Хотя повторение прерванных транзакций простой и эффективный механизмобработки ошибок, он имеет недостатки:

  • Если причина ошибки в перегруженности, то повтор транзакции толькоусугубит проблему.

  • Имеет смысл повторять выполнение транзакций только для временных ошибок (происходящих, например, из-за взаимной блокировки, нарушения изоляции, временных проблем с сетью или восстановления после сбоя). Попытка повтора выполнения при постоянной ошибке (допустим, при нарушенииограничения) бессмысленна.

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

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

Слабые уровни изоляции

Транзакции, не затрагивающие одних и тех же данных, могут спокойно выполняться конкурентно, поскольку друг от друга не зависят. Проблемы конкурентногодоступа (состояния гонки) возникают, только если одна транзакция читает данные,модифицируемые в этот момент другой, или две транзакции пытаются одновременно модифицировать одни и те же данные.

Базы данных долгое время пытались инкапсулировать вопросы конкурентного доступа от разработчиков приложений путем изоляции транзакций(transaction isolation). Теоретически изоляция должна была облегчить жизнь разработчиков, которые смогли бы сделать вид, что никакого конкурентного выполненияне происходит: сериализуемая изоляция означает гарантию базой данных такогорежима выполнения транзакций, как будто они выполняются последовательно.

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

Автор книги не стал отдельно рассматривать уровень изоляции чтение незафиксированных данных (read uncommitted). Он предотвращает грязные операции записи,но не грязные операции чтения.

Чтение зафиксированных данных

Этот уровень изоляции обеспечивает две гарантии:

  • При чтении из БД клиент видит только зафиксированные данные (никакихгрязных операций чтения).

  • При записи в БД можно перезаписывать только зафиксированные данные (никаких грязных операций записи).

Если транзакция записала данные в базу, но еще не была зафиксирована или была прервана и другая транзакция увидела эти незафиксированные данные, то такая операция чтения называется грязной (dirty read).

Выполняемые при уровне изоляции транзакций read committed (чтение зафиксированных данных) транзакции должны предотвращать грязные операции чтения.Это значит, что любые операции записи, выполняемые транзакцией, становятсявидны другим транзакциям только после фиксации данной.

Рис. 2 - Никаких грязных операций чтения: пользователь 2 видит новое значение x только после фиксации результатов транзакции, выполняемой пользователем 1Рис. 2 - Никаких грязных операций чтения: пользователь 2 видит новое значение x только после фиксации результатов транзакции, выполняемой пользователем 1

Если более ранняя операция записи представляет собой часть еще не зафиксированной транзакции и более поздняя транзакция перезаписывает незафиксированное значение, то такая операция называется грязной операцией записи.

Чтение зафиксированных данных предотвращает казусы, например, как на рис. 3, связанные с грязной операцией записи.

Рис. 3 - В случае грязных операций записи конфликтующие операции записи различных транзакций могут оказаться перепутаныРис. 3 - В случае грязных операций записи конфликтующие операции записи различных транзакций могут оказаться перепутаны

Чтение зафиксированных данных очень популярный уровень изоляции. Он используется по умолчанию в Oracle 11g, PostgreSQL, SQL Server 2012, MemSQLи многих других базах данных.

Чаще всего базы используют блокировки строк для предотвращения грязныхопераций записи: прежде чем модифицировать конкретный объект (строку илидокумент), транзакция должна сначала установить блокировку на этот объект.Данная блокировка должна удерживаться вплоть до фиксации или прерываниятранзакции. Удерживать блокировку на конкретный объект может только однатранзакция одновременно, другой транзакции, желающей выполнить операциюзаписи в этот объект, придется дождаться фиксации или прерывания первойтранзакции и лишь затем получить на него блокировку и продолжить свою работу.Подобные блокировки выполняются базами автоматически в режиме чтения зафиксированных данных (и на более сильных уровнях изоляции).

Большинство БД предотвращают грязные операции чтения с помощьюподхода, показанного на рис. 2: база запоминает для каждого записываемого объекта как старое зафиксированное значение, так и новое, устанавливаемое транзакцией, удерживающей в данный момент блокировку записи. Во время выполнениятранзакции всем другим транзакциям, читающим объект, просто возвращаетсястарое значение. Только после фиксации нового значения транзакции начинаютполучать его при чтении.

Изоляция снимков состояния и воспроизводимое чтение

На первый взгляд уровня изоляции чтения зафиксированных данных вполнедостаточно для транзакций.

Однако на этом уровне изоляции все еще существует множество возможных ошибок конкурентного доступа. Например, на рис. 4 показана одна из вероятныхпроблем при чтении зафиксированных данных.

Рис. 4 - Асимметрия чтения: Алиса видит базу данных в несогласованном состоянииРис. 4 - Асимметрия чтения: Алиса видит базу данных в несогласованном состоянии

Подобная аномалия носит название невоспроизводимого чтения (nonrepeatable read)или асимметрии чтения (read skew): если Алиса прочитала бы баланс счета 1 опятьв конце транзакции, то увидела бы значение ($600), отличное от прочитанного предыдущим запросом. Асимметрия считается допустимой при изоляции уровнячтения зафиксированных данных: видимые Алисе балансы счетов были, безусловно, зафиксированы на момент их чтения.

В случае Алисы это лишь временная проблема. Однако в некоторых ситуациях подобные временные несоответствия недопустимы.

  • Резервное копирование. Резервная копия представляет собой копию всей базыданных, и ее создание на большой БД может занять несколько часов. Операциизаписи в базу продолжают выполняться во время создания резервной копии.Следовательно, может оказаться, что одни части копии содержат старые версииданных, а другие новые. В случае восстановления БД из подобной резервной копии упомянутые расхождения (например, пропавшие деньги) станут извременных постоянными.

  • Аналитические запросы и проверки целостности. Иногда приходится выполнятьзапросы, просматривающие значительные части базы данных. Они также могут быть частьюпериодической проверки целостности (мониторинга на предмет порчи данных).Если подобные запросы будут видеть разные части БД по состоянию на различные моменты времени, то их результаты будут совершенно бессмысленными.

Изоляция снимков состояния чаще всего используемое решение этой проблемы. Ее идея состоит в том, что каждая из транзакций читает данные из согласованного снимка состояния БД, то есть видит данные, которые были зафиксированыв базе на момент ее (транзакции) начала.

В других источниках данный уровень изоляции может называться повторяющимся чтением (repeatable read)

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

Базы данных применяют для реализации изоляции снимков состояния похожий механизм, действие которого по части предотвращения грязных операций чтения мы наблюдали на рис. 2. БД должна хранить для этого несколько различныхзафиксированных версий объекта, поскольку разным выполняемым транзакциямможет понадобиться состояние базы на различные моменты времени. Вследствиехранения одновременно нескольких версий объектов этот метод получил названиемноговерсионного управления конкурентным доступом (multiversion concurrencycontrol, MVCC).

Если базе необходима только изоляция уровня чтения зафиксированных данных,но не уровня изоляции снимков состояния, достаточно было бы хранить толькодве версии объекта: зафиксированную версию и перезаписанную, но еще не зафиксированную версию. Однако поддерживающие изоляцию снимков состояния подсистемы хранения обычно используют MVCC и для изоляции уровня чтениязафиксированных данных. При этом обычно при чтении таких данных применяется отдельный снимок состояния для каждого запроса, а при изоляции снимковсостояния один и тот же снимок состояния для всей транзакции.

Рис. 5 - Реализация изоляции снимков состоянияс помощью многоверсионных объектовРис. 5 - Реализация изоляции снимков состоянияс помощью многоверсионных объектов

В каждой строке таблицы есть поле created_by, содержащее идентификатор транзакции, вставившей эту строку в таблицу. Более того, в каждой строке таблицы естьполе deleted_by, изначально пустое. Если транзакция удаляет строку, то строка на самом деле не удаляется из базы данных, а помечается для удаления путемустановки значения этого поля в соответствии с идентификатором запросившейудаление транзакции. В дальнейшем, когда уже никакая транзакция точно не обратится к удаленным данным, процесс сборки мусора БД удалит все помеченныедля удаления строки и освободит занимаемое ими место.

Более подробно о правилах видимости для согласованных снимков состояния можно прочесть в книге.

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

Ссылки на все части

Подробнее..

Транзакции. Часть 2. Конспект книги Designing Data-Intensive Applications

23.05.2021 14:09:40 | Автор: admin

Эта статья является конспектом книги Designing Data-Intensive Applications.

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

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

Асимметрия записи и фантомы

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

Теперь представим, что Алиса и Боб два дежурных доктора на конкретной смене.Оба плохо себя чувствуют, и оба решили попросить отгул. К сожалению, они нажали на кнопку запроса отгула примерно в одно время. Происходящее после этогопоказано на рис. 1.

Рис. 1 - Пример асимметрии записи, вызванной ошибкой в коде приложенияРис. 1 - Пример асимметрии записи, вызванной ошибкой в коде приложения

В каждой из транзакций приложение сначала проверяет наличие в данный моментдвух или более дежурных врачей. При положительном результате оно считает, чтоможно безопасно дать одному из врачей отгул. Поскольку база данных используетизоляцию снимков состояния, обе проверки возвращают 2 и выполнение обеих транзакций продолжается. Алиса и Боб успешно обновляют свой график и получают отгул. Происходит фиксация обеих транзакций, после чего оказывается, что ни одного дежурного врача нет. Требование наличия хотя бы одногодежурного врача оказалось нарушено.

Такая аномалия носит название асимметрии записи (write skew). Это не грязная операция записи и не потеря обновления, поскольку две наши транзакции обновляют два различных объекта. Наличие конфликта тут менее заметно, но это, безусловно, состояние гонки:если две транзакции выполнялись бы одна за другой, то второй врач не получил быотгула.

Асимметрию записи можно рассматривать как обобщение проблемы потери обновлений. Эта асимметрия может происходить при чтении двумя транзакциямиодних и тех же объектов с последующим обновлением некоторых из них (различныетранзакции могут обновлять разные объекты). В частном случае, когда различныетранзакции обновляют один объект, происходит грязная операция записи илипотеря обновления (в зависимости от хронометража).

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

BEGIN TRANSACTION;SELECT * FROM doctorsWHERE on_call = trueAND shift_id = 1234 FOR UPDATE;UPDATE doctorsSET on_call = falseWHERE name = 'Alice'AND shift_id = 1234;COMMIT;

Предложение FOR UPDATE указывает базе установить блокировкуна все возвращенные данным запросом строки.

В примере с дежурными врачами измененная строка была одной из строк,возвращенных в первом запросе, так что можно было обезопасить транзакцию и избежатьасимметрии записи, блокируя строки (SELECT FOR UPDATE). Однако если выполняется проверка на отсутствиеудовлетворяющих определенному условию поиска строк, а операция записи вставляет соответствующую этому же условию строку, то первый запрос на получения данных не вернетничего и SELECT FOR UPDATE не на что будет устанавливать блокировки.

Такой эффект, при котором операция записи в одной транзакции меняет результатзапроса на поиск в другой, называется фантомом (phantom).

Для предотвращения таких ситуация в большинстве случаев предпочтительнее использоватьизоляцию уровня сериализуемости.

Сериализуемость

Сериализуемость (serializability) обычно считается самым сильным уровнем изоляции. Она гарантирует, что даже при конкурентном выполнении транзакцийрезультат останется таким же, как и в случае их последовательного выполнения, без всякой конкурентности. Следовательно, база предотвращает всевозможные состояния гонки.

Но если сериализуемость настолько лучше более слабых уровней изоляции, почему бы не использовать ее повсеместно? Для ответа на данный вопрос рассмотримвероятные реализации сериализуемости и их производительность. Большинство современных БД, обеспечивающих сериализуемость, применяют один из трех методов:

  • действительно последовательное выполнение транзакций;

  • двухфазную блокировку;

  • методы оптимистического управления конкурентным доступом, например,сериализуемую изоляцию снимков состояния (SSI).

Рассматривать эти методы будем применительно к одноузловым базам данных. Однако в книге в отдельной главе рассматриваются их возможности в распределенных системах.

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

Хотя эта идея довольно очевидна, создатели баз данных только относительнонедавно решили, что однопоточный цикл выполнения транзакцийоправдывает себя. Как случилось, что однопоточное выполнение стало считаться допустимым?

Этот пересмотр концепции был вызван двумя факторами.

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

  • Создатели баз данных осознали, что OLTP-транзакции обычно короткие и выполняют лишь небольшое количество операций записи и чтения. Напротив, длительные аналитические запросы обычно только читаютинформацию, поэтому их можно выполнять на согласованном снимке состояния (на уровне изоляции снимков состояния), вне цикла последовательноговыполнения.

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

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

  • Набор данных должен помещаться в памяти целиком. Потенциально можнопереместить на диск редко используемые данные, но, если понадобится обратиться к ним в однопоточной транзакции, система способна очень сильнозамедлиться.

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

Двухфазная блокировка (2PL). В течение долгого времени в базах данных широко использовался только один алгоритм сериализуемости: двухфазная блокировка (two-phase locking, 2PL).

Обратите внимание, что, хотя название двухфазной блокировки (2PL) оченьсхоже с названием двухфазной фиксации транзакций (2PC), это две совершенно разные вещи.

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

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

Из-за столь большого количества блокировок часто встречается ситуация, когдатранзакция A ждет снятия блокировки транзакции B и наоборот. Такая ситуацияназывается взаимной блокировкой (deadlock). База данных автоматически обнаруживает взаимные блокировки между транзакциями и прерывает одну из них, чтобыостальные могли продолжить работу.

Главный недостаток двухфазной блокировки и причина, по которой ее не используют повсеместно ее низкая производительность: пропускнаяспособность по транзакциям и время отклика запросов значительно хуже придвухфазной блокировке, чем при слабой изоляции.

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

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

Сериализуемая изоляция снимков состояния (SSI). В этом конспекте мы увидели довольно мрачную картину управления конкурентнымдоступом в БД. С одной стороны, имеющиеся реализации сериализуемости или демонстрируют низкую производительность (двухфазная блокировка), илиплохо масштабируются (последовательное выполнение). С другой слабые уровниизоляции показывают высокую производительность, но подвержены различнымсостояниям гонки (потеря обновлений, асимметрия записи, фантомы и т. д.). Такчто же, сериализуемая изоляция и хорошая производительность вещи принципиально взаимоисключающие?

Очень многообещающим представляется алгоритм под названиемсериализуемая изоляция снимков состояния (serializable snapshot isolation, SSI).Он обеспечивает полную сериализуемость за счет лишь небольшого сниженияпроизводительности по сравнению с обычной изоляцией снимков состояния. SSI относительно новый метод: он был впервые описан в 2008 году.

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

Напротив, сериализуемая изоляция снимков состояния представляет собой оптимистический метод управления конкурентным доступом. Оптимистическийв этом контексте означает следующее: вместо блокировки в случае потенциальноопасных действий транзакции просто продолжают выполняться в надежде, что всебудет хорошо. При фиксации транзакции база данных проверяет, не случилось личего-то плохого (например, не была ли нарушена изоляция). Если да, то транзакцияпрерывается и ее выполнение приходится повторять еще раз.

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

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

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

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

  • выявление операций чтения устаревших версий MVCC-объектов (перед чтением произошла незафиксированная операция записи);

  • выявление операций записи, влияющих на предшествующие операции чтения(операция записи произошла после чтения).

Выявление операций чтения устаревших версий MVCC объектов. Изоляция снимков состояния обычно реализуется с помощьюMVCC.Транзакция, читающая из согласованного снимка состояния в базе данных MVCC,игнорирует все операции записи, которые были выполнены транзакциями, ещене зафиксированными на момент получения снимка состояния. На рис. 2 транзакция 43 видит, что Алиса находится на дежурстве (on_call = true), посколькутранзакция 42 не зафиксирована. Однако на моментфиксации транзакции 43 транзакция 42 уже зафиксирована. Это значит, что операция записи, проигнорированная при чтении из согласованного снимка состояния,теперь уже вступила в силу и исходные условия транзакции 43 более не соответствуют действительности.

Рис. 2 - Выявление чтения транзакцией устаревших значений из снимка состояния MVCCРис. 2 - Выявление чтения транзакцией устаревших значений из снимка состояния MVCC

Для предотвращения этой аномалии база данных должна отслеживать случаи игнорирования транзакцией вследствие правил видимости MVCC операций записидругих транзакций. При попытке фиксации транзакции база проверяет, были лизафиксированы какие-либо из проигнорированных операций записи. Если да, тотранзакцию необходимо прервать.

Выявление операций записи, влияющих на предшествующиеоперации чтения. Второй случай когда другая транзакция модифицирует данные после их чтения.

Рис. 3 - Выявление при сериализуемой изоляции снимков состояния случаев модификации транзакцией данных, прочитанных другой транзакциейРис. 3 - Выявление при сериализуемой изоляции снимков состояния случаев модификации транзакцией данных, прочитанных другой транзакцией

На рис. 3 обе транзакции, 42 и 43, выполняют поиск дежурящих в смену 1234 врачей. При наличии индекса по shift_id база может воспользоваться его записью 1234, чтобы отметить факт чтения транзакциями 42 и 43 этих данных (еслииндекса нет, информацию можно отслеживать на уровне таблицы). Сама информация требуется только временно: после завершения выполнения транзакции(ее фиксации или прерывания) и завершения всех конкурентных транзакций БДможет спокойно забыть о том, какие данные читались этой транзакцией.

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

На рис. 3 транзакция 43 уведомляет транзакцию 42, что прочитанные ею в предыдущей операции чтения данные устарели и наоборот. Первой выполняется фиксация транзакции 42, и она проходит успешно: хотя операция записи транзакции 43влияет на 42, транзакция 43 пока еще не зафиксирована, поэтому данная операциязаписи еще не вступила в силу. Однако на момент фиксации транзакции 43 конфликтующая операция записи транзакции 42 уже была зафиксирована, так чтотранзакцию 43 придется прервать.

Вывод

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

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

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

  • Грязные операции чтения. Клиент читает записанные другим клиентомданные до их фиксации. Уровень изоляции чтения зафиксированных данныхи более сильные предотвращают грязные операции чтения.

  • Грязные операции записи. Клиент перезаписывает данные, которые другойклиент записал, но еще не зафиксировал. Практически все реализации транзакций предотвращают грязные операции записи.

  • Асимметрия чтения (невоспроизводимое чтение). Клиент видит различные части базы данных по состоянию на разные моменты времени. Чаще всего такуюпроблему предотвращают с помощью изоляции снимков состояния, при которойтранзакция читает данные из согласованного снимка состояния, соответствующего определенному моменту времени. Обычно это реализуется благодарямноговерсионному управлению конкурентным доступом (MVCC).

  • Потерянные обновления. Два клиента выполняют в конкурентном режиме циклчтения изменения записи. Один переписывает записанные другим данныебез учета внесенных им изменений, так что данные оказываются потеряны.Некоторые реализации изоляции снимков состояния предотвращают эту аномалию автоматически, а в других требуется установка блокировки вручную(SELECT FOR UPDATE).

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

  • Фантомные чтения. Транзакция читает объекты, соответствующие определенному условию поиска. Другой клиент выполняет операцию записи, котораякаким-то образом влияет на результаты этого поиска. Изоляция снимков состояния предотвращает непосредственно фантомные чтения, но фантомы в контексте асимметрии записи требуют отдельной обработки, например, блокировокпо диапазону значений индекса.

Слабые уровни изоляции защищают от некоторых из этих аномалий, но другиепридется обрабатывать вручную (например,с помощью явной блокировки). Только изоляция уровня сериализуемых транзакций предотвращает все подобные проблемы. Рассмотрели три различных подходак реализации сериализуемых транзакций.

  • По-настоящему последовательное выполнение транзакций. Если вы можетесделать отдельные транзакции очень быстрыми, причем количество транзакций,обрабатываемых за единицу времени на одном ядре CPU, достаточно невелико,то для обработки этот вариант окажется простым и эффективным.

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

  • Сериализуемая изоляция снимков состояния (SSI). Довольно свежий алгоритм,лишенный практически всех недостатков предыдущих подходов. В нем используется оптимистический подход, благодаря чему транзакции выполняются без блокировок. Перед фиксацией транзакции выполняется проверка,и если выполнение было несериализуемым, то транзакция прерывается безфиксации.

Ссылки на все части

Подробнее..

Recovery mode Создаём компанию мечты управление качеством данных

27.04.2021 22:20:31 | Автор: admin
Самой дорогой ошибкой в истории, вызванной неправильными исходными данными, считается авария ракеты Ариан-5. Суммарный урон по итогу этого случая оценивают в 0.5 миллиардов долларов в ценах начала 1996 года.

Ещё одной, возможно, самой курьёзной, стала ошибка в огромном заказе от французских железных дорог SNCF на 2 тыс. поездов в 2014 году. Команда, которая формировала технические требования, собственноручно провела замеры габаритов перронов на нескольких десятках станций. Желая увеличить комфорт, они задали ширину составов впритык к максимальной. Измерения они проводили в окрестностях Парижа и о том, что в регионах на многих станциях перроны находятся ближе к путям, узнали уже при испытаниях. Цена ошибки модернизация всей инфраструктуры на сотни миллионов евро. Им бы там MDM с характеристиками станций

image

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

Эта статья продолжает статью "мастер-данные и интеграция" и более подробно освещает вопрос контроля качества данных, в первую очередь мастер-данных. Статья будет особенно интересна руководителям IT, архитекторам, интеграторам, а также всем, кто работает в достаточно крупных компаниях.

Содержание:


1. Словарь, виды бизнес-данных: мастер-данные, нормативно-справочная информация, операционные данные.
2. Коротенько о том, какие бывают ошибки.
3. Архитектура решений DQS.
4. Технические и нетехнические приёмы борьбы с ошибками:
4.1. НСИ.
4.2. Мастер-данные.
4.3. Операционка.
5. Что делать, когда ничего из перечисленного не помогло внедрять DQS.
6. И как делить ответственность?

Если терминология и проблематика вам уже знакомы, переходите сразу к части 3, про архитектуру DQS.

1. Словарь, виды бизнес-данных.



Уже пару десятков лет IT-евангелисты убеждают нас, что данные новая нефть. Что любой бизнес всё больше зависит от обладаемой информации. Аналитические и дата-отделы появляются не только в IT-компаниях, но и в максимально далёких от цифры индустриальных и промышленных отраслях.

Многим уже набил оскомину пример того, как компании General Electric и Boeing создают цифровых дочек и зарабатывают на огромном объёме информации, собираемой от владельцев их техники самолётов, турбин, электростанций. Эти данные позволяют им повышать надёжность техники, предсказывать возможные отказы, сильно экономя на потенциальном ущербе, наконец, просто спасать жизни людей!

Данных становится всё больше, и накопление их нелинейно зависит от роста бизнеса, рост опережающий. Любая растущая компания на определенном этапе своего развития (примерно на 6-7 уровне по шкале из прошлой статьи) сталкивается с проблемами некорректных данных, и обязательно происходит несколько случаев, когда цена этих ошибок оказывается достаточно высокой.

image
традиционная картинка про рост объёма данных почти всегда экспонента

По ходу деятельности особую важность для компании представляют собой три вида данных:

мастер-данные это информация, которая должна быть единой и синхронизированной во всех местах организации, во всех информационных системах. Это список клиентов компании, перечень товаров и услуг (со всеми дополнительными реквизитами: цена, категория, условия), организационная структура компании, персонал, имущество и т.д.;

нормативно-справочная информация (НСИ) это понятие близко к мастер-данным, и во многих компаниях объединяется с ними. Разница в том, что эти данные существуют независимо от вашей компании: список (классификатор) стран мира, адресный классификатор, реестры банков, курсы валют;

операционные (они же транзакционные) данные факт продажи конкретного товара конкретному клиенту, счета и акты, пройденные курсы, заказы курьеров и поездки на такси в зависимости от того, чем занимается ваша компания.

Если НСИ можно сравнить с несущим скелетом, мастер-данные с венами и артериями, то операционка это кровь, которая бежит по этим венам.

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

image

2. Коротенько о том, какие бывают ошибки.



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


Основные виды ошибок, от которых страдает бизнес:

человеческий фактор. Опечатки всех видов, перепутанные поля и не туда внесённая информация. Забытые или случайно пропущенные действия и шаги при её внесении (у вас ведь тоже в карточке клиента по 50 полей?) Статически это самый вероятный вид ошибок, поэтому частота и эффект от них может оказаться самым большим. К счастью, для борьбы с ними придумано и самое большое количество методов;

неполнота информации. Говорят, что полуправда хуже неправды, и в бизнесе это часто бывает критичным. Например, вы заключили крупный контракт с организацией и через некоторое время узнали, что в отношении руководства компании ведётся судопроизводство. Ваш контрагент может уклоняться от налогов или, чего хуже, заниматься противозаконной деятельностью. Через некоторое время с вами свяжутся конечно, ваш бизнес полностью легален, но кого обрадуют лишние проверки? А как хорошо было бы, если бы тогда, при нанесении контрагента в базу, ваша учётная система или CRM предупредила бы: внимание! Контрагент не прошёл проверку на благонадёжность!

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

И если третье это предмет работы службы информационной безопасности, там есть свои методы, то с человеческим фактором и неполнотой мы поработаем предметно.

3. Архитектура решений DQS.



DQM data quality management, управление качеством данных.
DQS data quality system, система [управления] качеством данных.


Перед тем, как рассказать непосредственно о системах управления качеством данных (DQS это не столько конкретное программное обеспечение, сколько подход к работе с данными), опишу IT-архитектуру.

Обычно, к тому моменту, когда возникает вопрос управления качеством данных, IT-ландшафт представляет собой следующее:

image
(схема из предыдущей статьи)

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

Традиционно на первом этапе DQS подключается к системе MDM, поскольку управление качеством мастер-данных считается более приоритетным, чем операционки. Однако, в дальнейшем она включается в общую шину данных как один из этапов процессов, либо представляет свои услуги в формате API. В конкретных цифрах между первой и второй схемой примерно десятикратная разница в объёме данных или один уровень по шкале из прошлой статьи.

4. Технические и нетехнические приёмы борьбы с ошибками.

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

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

4.1. Нормативно-справочная информация.

В случае нормативно-справочной информации (по сути, государственных классификаторов) есть максимально категоричное решение, и оно универсальное: вы не должны вести нормативку самостоятельно! Никогда, не при каких обстоятельствах!

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

Пример #1. Наверняка вам для работы понадобится список стран мира. На него будут ссылаться многие другие справочники: контрагенты и клиенты (страна регистрации), валюты (курс какой страны), ваша география (в какой стране и по какому адресу расположен офис).

Значит, любая сущность, которая содержит в себе страну мира (даже если вы в ней выбираете из двух-трёх стран) должна ссылаться на этот справочник. А сам справочник должен заполняться строго на основании официальных классификаторов, в случае РФ это ОКСМ (общероссийский классификатор стран мира).

Если вы работаете на международном рынке, обратите внимание на нюанс: в разных странах разное представление о странах мира и их количестве. И речь не только про такие частично-признанные республики, как Абхазия или Южная Осетия. Например, около двадцати стран не признают существование Израиля и Китайской Народной Республики. Есть и точечные непризнания на территории СНГ, например, Армения не признаётся Пакистаном.

Страны мира (в РФ это и ниже ОКСМ), валюты (ОКВ), виды экономической деятельности (ОКВЭД), адреса (ФИАС), банки и их счета, клиенты и поставщики (ЕГРЮЛ и ЕГРИП) эта и множество другой информации публикуется государственными органами практически всех стран в виде открытых API и сервисов, и она должна загружаться только таким образом.


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

image

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

4.2. Мастер-данные.



Главная стратегия в отношении мастер-данных прозвучит, возможно, парадоксально: превращайте их в нормативку!

Пример #2. Справочник контрагентов юридических лиц и ИП, являющихся вашими клиентами или поставщиками (в компаниях уровня выше 5-6 часто одновременно и тем, и тем).

Какой бы набор полей вы не решили добавить в справочник контрагентов в систему MDM, ваша цель такова: все данные должны заполняться автоматически, с поиском по одному из естественных полей. В случае контрагентов РФ это наименование или ИНН.

Это не значит, что вы должны занести в свой справочник контрагентов все несколько миллионов записей из открытых данных. Но новые записи должны добавляться как раз на их основании. Базовые реквизиты можно взять с сайта налоговой. Если вас интересуют данные бухгалтерской отчётности или среднесписочной численности (например, в целях аналитики, развивать отношения с наиболее крупными клиентами) берите их у Росстата (ссылка). Если у вас есть процедура проверки на благонадёжность берите данные с сайтов соотв. служб с помощью своей ИТ-команды, либо есть вариант покупать уже подготовленные и выверенные данные у провайдеров (например, СПАРК-Интерфакс). Цена вопроса, сотни тысяч рублей в год, при ваших масштабах окупается за несколько месяцев.

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


Пример #3. Физические лица, сотрудники вашей компании. Ошибки в паспортных данных, неправильные ФИО и дата рождения, СНИЛС. Сокрытая информация о судимости, просроченной задолженности перед госорганами, алиментах.

Список сотрудников почти всегда является мастер-данными в крупных компаниях. Как их сделать нормативкой? Самый простой способ наладить интеграцию с порталом Госуслуг. Возможен также вариант авторизации на ваших сервисах через портал Госуслуг. Ключевое слово для поиска: ЕСИА. Нужно будет обзавестись рядом сертификатов, но при ваших масштабах и уровне развития это не составит проблем.

Естественным продолжением этой истории будет электронный кадровый документооборот электронная трудовая книжка, электронные больничные и др., что значительно сэкономит трудозатраты у кадровиков. В пределе это позволит одному кадровику обслуживать не 200-300 сотрудников, а 1000+.

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

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


4.3. Операционка.



Здесь подходов уже больше. Первый аналогичен предыдущему подключать внешние источники информации.

Пример #4. Хорошо, скажете вы, контрагенты и физлица это просто. Но что делать с более бизнес-специфичными процессами и данными? Искать государственные классификаторы и другие гарантированные источники этой информации.

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

Создаём справочник автомобилей это мастер-данные. Модель автомобиля, его нормы расхода топлива и характеристики выбираем из гос. классификатора моделей (не забывайте настроить регулярную интеграцию, чтобы данные не устаревали!)
Информацию о конкретном автомобиле заполняем строго по госномеру на основании подключаемого справочника (например, Автокод).

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


Пример #5. Командировки сотрудников: билеты, гостиницы и прочие расходы.

Для билетов и гостиниц пользоваться агрегаторами, все они позволяют, во-первых, значительно экономить на организации поездок (цены на билеты, гостиницы). Во-вторых, дают API со всей возможной информацией, вплоть до ЭДО. По всем прочим расходам пользоваться электронными чеками, они уже принимаются везде. Т.е. человеческий фактор будет если не исключён, то сведён к минимуму.


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

Информация (данные) новая нефть, и все государства стремятся к тому, чтобы получить максимально возможный объем информации о своих субъектах, включая бизнес, обо всех процессах, в которых они участвуют.

Нам даже тяжело представить, какую информацию государство собирает, могу сказать только, что на момент написания этой статьи на портале открытых данных России представлено около 20 тысяч наборов данных. И Россия только в начале этого пути, так, на аналогичном портале Евросоюза доступно больше миллиона наборов открытых данных!

image
www.europeandataportal.eu/en

Где же здесь DQS, спросит внимательный читатель?

А про неё ещё ничего и не было :)
Всё вышеперечисленное это, по сути, стандартные инструменты и методы для организации бизнес-процессов с минимальным количеством ошибок.

5. Что делать, когда ничего из перечисленного не помогло внедрять DQS.



Сунь-цзы учит, что лучшая битва та, которую удалось избежать.

Ситуация с внедрением DQS чем-то похожа.

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

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

На каком уровне развития компании нужно вводить DQS? Как процесс DQM на 4-5 (раньше MDM-системы!), как организационно выделенную функцию на 7-8.

5.1. DQM как процесс.



Если у вас в компании есть бухгалтерская или кадровая система, то и процесс DQM в каком-то виде у вас будет. Во все эти системы встроен определённый набор правил для вводимых данных. Например, обязательность и строгий формат даты рождения для сотрудника, обязательность наименования для контрагентов.

Ваша задача на данном этапе будет заключаться в выстраивании процесса DQM. Он следующий:

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

Если вы сумели внедрить в компании MDM, значит, пункты со второго и далее не должны вызвать у вас особых затруднений, это текущая планомерная работа.

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

5.2. Правила.



Если для такой сущности, как ФИО, ваша фантазия ограничивается обязательностью фамилии и имени, а для даты проверкой на не больше ста лет, не расстраивайтесь!

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

По сути, это пошаговый скрипт, у которого на входе определение ваших данных, а на выходе набор правил на все случаи жизни. Методика, известная под названием таксономия грязных данных, была разработана группой европейских data-scientistов в начале XXI века.

Суть подхода, а также практические примеры приведены в их системной статье, к счастью, уже опубликованной в переводе здесь, на Хабре habr.com/ru/post/548164

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

Пример #6. Строгая типизация. Если в справочнике используется тип данных дата, то структура даты должна быть максимально явной. Если вы решили сэкономить две секунды для операторов, и сделали шаблон вида __.__.__ с подсказкой день, месяц, год, будьте уверены, что в первый же день появятся записи 18.04.21, 21.04.18 и 04.18.21.


Хорошим способом ввода даты являются три поля с явным обозначением (день, месяц, год) и быстрым переходом при вводе двух цифр в каждом из полей. Если вы хоть раз платили за что-нибудь картой в интернете, поймёте.

Пример #7. Запрещённые символы в максимально широком списке полей, словарные проверки. Например, если речь идёт про образование (должность), и классификаторы специальностей не помогли, вы позволяете пользователю ввести данные в текстовом поле, пусть там будут запрещены точки, кавычки, отдельно стоящие чёрточки (список не полный). Пример информации, качество которой повышается: доктор технических наук, д.т.н., ДТН, д-р техн. наук и т.д.


Пример #8. Пустое и неуказанное значение (NULL) это два разных значения. Например, неуказанное высшее образование/отсутствие высшего образования, неуказанное отчество/отсутствие отчества разница велика, и она должна быть зафиксирована в явном виде. Хороший пример реализации сайты по продаже билетов справа от отчества размещают галочку нет отчества.

Кстати, про ФИО, и особенно про отчество. Если вы предполагаете работу с физическими лицами из стран Средней Азии или Ближнего Востока, кейсы с ибн, бен, кызы, оглы (и др.) могут стать критичными в вопросах качества данных, например, при поиске дубликатов. Аналогичная история с порядком употребления этих данных (Джон Смит, Смит, Джон) и с двойными именами (Анна Мария, Анна-Мария, Джон Чарьлз Смит). Также для многих не иметь фамилию это нормально. А ещё, с точки зрения одних, Наталья и Наталия разные имена, а с точки зрения других одинаковые. А ещё есть сэр, доктор

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


6. Кто несёт ответственность за DQS?



В вопросах управления и ответственности правильных ответов не бывает, скорее всё зависит от конкретных команд и личностей. Инженер-ракетчик может быть главным бухгалтером, художник финансовым директоров, а учительница начальных классов руководителем службы охраны.

Вопрос про ответственность за процесс DQM, на самом деле, даже более общий: кто несёт ответственность за качество данных в компании? Традиционно бизнес-пользователи и IT-департамент в ответе на этот вопрос выступают антагонистами.

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

Выстраивание работающего процесса DQM и запуск DQS является тем самым компромиссом, удовлетворяющим обе стороны. Задача IT и аналитиков заключается в разработке максимально возможного количества правил и ограничений для вводимых данных, чтобы свести риск возникновения ошибки к минимуму.

Позиция бизнеса, как правило, вызвана отсутствием прозрачности в процессах DQM. Однако, если свести его до наглядной демонстрации ошибки, позиция смягчается. И может дойти до согласия в случае демонстрации последствий тому, кто вводит первичные данные.

Восхитительнейший пример и мотивацией и даже визуализацией последствий ошибок приведён в статье habr.com/ru/post/347838 в этом примере ответственным за процесс DQM выступает служба IT с развитыми компетенциями бизнес-анализа. Причём сами по себе компетенции в DQM не сложны, и могут быть развиты у любого аналитика за пару месяцев.

Ещё один пример, интересный тем, что в процесс DQM включено также управление качеством бизнес-процессов, приведён в статье habr.com/ru/company/otus/blog/526174.

Итоги



Общие выводы из этой статьи парадоксальны.

Если в вашей компании был задан вопрос кто несёт ответственность за качество данных, то вы попали в ловушку. На него нет правильного ответа, т.к. сам вопрос неправильный. Если вы попробуете сходить по этому пути, со временем поймёте, что единственный подходящий ответ на этот вопрос (все) ничего не даст вам на практике.

Правильный подход разделение вопроса на два блока.

Первый выстраивание DQM как процесса, внедрение DQS, формирование правил (не на разовой основе, а как постоянно идущий процесс). Этот блок живёт там, где сильны функции анализа, обычно, в IT, но необязательно.

Второй блок сам ввод первичных данных это место, где принимаются решения о конкретных данных, но не наобум, а на основании всех правил. Таким образом, внедрение DQS важный шаг в сторону data driven company.

Приглашаю к дискуссии!
Подробнее..

Recovery mode Создаём компанию мечты нет хайпу

01.06.2021 00:14:15 | Автор: admin
Наверняка в вашей компании уже не раз появлялись ребята в дорогих костюмах и с хорошо подвешенным языком, увлекательно рассказывающие, что без современных айти-штучек компания не проживет и несколько лет!

Все эти data lake (болото данных), КХД (корпоративное кладбище данных), data mining (смотри, не подорвись), data governance (стань рабом своих данных) и им подобные не исчезают из их рассказов, периодически сменяя друг друга. Срок жизни очередного хайпа редко превышает год-два, но при желании для вас с большим удовольствием откопают любую почти забытую технологию.

При этом биг-дату продают как такой волшебный сундук, из которого можно доставать разные чудеса: то ковер-самолёт, то сапоги-скороходы, а то и шамаханскую царицу (кому что актуально). Вот только, как правило, ковёр-самолёт проеден волшебной же молью и больше не летает, сапоги с отвалившейся подошвой и пешком-то в них ходить неудобно, а про дряхлую царицу и говорить нечего.

В этой статье я постараюсь рассказать о старых-добрых технологиях, которые всё ещё работают. О том, что можно извлечь из перечисленных выше хайповых технологий и как всем этим пользоваться простым смертным, типа нас, не нанимая толпу дата-сайентологов с зарплатами >10 тысяч $ в месяц.

image


Статья продолжает цикл:
Создаём компанию мечты: мастер-данные и интеграция
Создаём компанию мечты: управление качеством данных

Содержание


1. Big data: постановка проблемы
2. Мастер-данные: бессмертная классика
3. Как хранить данные: нужны ли КХД
4. Нормализация, или зачем вам болота данных
5. Почему дата-сайентист получает больше аналитика, а делает меньше?
6. Шина данных vs микросервисы
7. Как вообще не попасть на хайп?

1. Big data: постановка проблемы


Роль big data в развитии современной цивилизации впечатляющая. Но не по той причине, которая вам кажется.

Если интернет в каждой деревне и каждом телефоне появился благодаря порно и соцсетям (мессенджерам), то big data подарила триллионы долларов производителям жёстких дисков и оперативной памяти.

Проблема в том, что реальная польза от современной big data (в широком смысле слова) для всего человечества близка к пользе от порнографии, т.е. за несколькими исключениями нулевая!

Как же так, удивитесь вы. Ведь любой консультант и продажник рассказывает целую дюжину примеров, начиная с General Electric с их диагностикой состояния авиадвигателей, заканчивая таргетированной рекламой от Гугла!

Проблема, если быть точнее, в повторяемости результатов. Скажу по секрету, что скамейка запасных у продажников big data короткая. Если вы попросите их привести ещё несколько примеров, список закончится на втором десятке. Уверен, что мессенджеров и порносайтов они смогут назвать куда больше :) потому что их просто физически больше.

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

А General Electric сформировала своё конкурентное преимущество основываясь на методах математического анализа и статистики, которые можно найти в любом курсе математики для университета. Понятия big data тогда ещё не было.

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

Что же делать? Работать! Долго, скучно и уныло, стараясь создать такую атмосферу, которая поощряла бы активное думание. Как в канонических примерах от Bell Labs или той же GE. Это вполне возможно, более того, на это способны самые обычные люди, как вы и я, если их нужным образом замотивировать.

А начать нужно с

2. Мастер-данные: бессмертная классика


Мастер-данные это такой подход в структурировании информации, которая есть в компании. Если вы в какой-то момент обнаруживаете, что та или иная сущность используется одновременно в двух или большем количестве систем в вашей компании (например, список сотрудников на внутреннем сайте, в базе 1С-Бухгалтерии или CRM-системе), нужно выносить его в отдельную систему мастер-данных (MDM) и заставлять все системы пользоваться только этим справочником. По ходу понадобиться всем участникам договориться о нужных полях и атрибутах, а также придумать множество правил для контроля качества этих данных.

В среде дата-сайентистов младше 30 лет встречается убеждение, что окно для внедрения систем MDM началось примерно в 2008 и закончилось в районе 2012-15 годов. Что после этого появилось так много новых инструментов (всякие hadoop и spark), что заморачиваться с мастер-данными уже не нужно, не нужно ходить и договариваться с владельцами всех систем, думать о последствиях выбора архитектуры MDM и каждого конкретного реквизита в каждом справочнике.

К сожалению для них и к счастью для вас, это окно не закрылось. MDM-системы всё так же актуальны, как и системы бухучета или взаимодействия с клиентами. И думать и договариваться всё ещё нужно.

3. Как хранить данные: нужны ли КХД


Нет, корпоративные кладбища данных вам не нужны.

Идея, что для целей аналитики нужно иметь специальным образом подготовленные наборы всех данных (идеологи КХД не только выделяют это слово жирным, но и подчёркивают его двойной чертой) в вашей компании, абсурда. Коэффициент реального использования этих данных минимальный, 99% из них не используются никогда.

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

4. Нормализация, или зачем вам болота данных


Это раздел про data lake, или болото данных. Легенды гласят, что можно сваливать все данные без разбору в одну большую кучу. Не нужно приводить все данные к одному формату, не нужно нормализовать и вычищать их!

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

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

И главный вопрос как какие-то жулики сумели убедить хоть кого-то в работоспособности этого подхода. Я склоняюсь к гипнозу :)

5. Почему дата-сайентист получает больше аналитика, а делает меньше?


Маркетинг, грамотная самопрезентация, максимум уверенности в себе. Не исключаю также гипноз :)

6. Шина данных vs микросервисы


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

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

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

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

Уже на десяти системах прекрасно выглядевшая на старте архитектура, подход превращается в некий такой клубок, паутину, когда определённые потоки отваливаются и не работают месяцами.

image

На нескольких десятках систем (цифра только кажется внушительной, в любом энтерпрайзе используется куда больше информационных систем) подход хоронит сам себя. И спустя несколько лет возникает какая-то централизация и шина. Делают её, как правило, уже другие люди.

7. Как вообще не попасть на хайп?


Вы познакомились с несколькими примерами хайпа, когда какой-то подход или технология могут оказаться бесполезными. И это с учётом того, что, по мировой статистике, доля успешно выполненных проектов по разработке и внедрению в IT редко превышает 40%.

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

Чтобы не попасть на хайп, перед очередным внедрением нужно выяснить следующее:

у технологии есть большая скамейка запасных. Количество приводимых примеров успешного применения должно превышать пару десятков, и от них не должно возникать ощущения, что тут происходит какая-то магия;
технология должна проходить тест на бабушку (объяснение сути должны быть настолько понятным, что его осилит даже ваша бабушка повторю, никакой магии);
у технологии должен быть конкретный, оцифрованный список ачивок, которые в результате получит ваша компания. Внедренцы MDM, CRM или той же 1С-бухгалтерии могут часами рассказывать о пользе их решения на примере ваших конкретных задач. Внедренцы Big data вообще начинают рассказывать, что сначала соберём кучу данных, а потом посмотрим, что с ней делать;
и, наконец, технология должна быть фальсифицируемой (в смысле критерия Поппера), т.е. внедренец должен чётко понимать область её применения и актуальности и суметь привести доводы против (!) внедрения. Не нужно забивать гвозди микроскопом, и вообще, например, если у вас мало клиентов, нужна ли вам супер-пупер CRM?

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

Можете предложить ещё какие-нибудь критерии?
Приглашаю к обсуждению!
Подробнее..

Как Microsoft Analysis Services финансовым аналитикам жизнь упростил

07.04.2021 16:22:59 | Автор: admin
Как мало пройдено дорог как много сделано отчетов

Введение


Василий, мы установили новый BI продукт, наш САМЙ ГЛАВНЙ от него просто в восторге!
Да, но я не знаю, как выгрузить данные для анализа из этой системы?! Он, похоже, только в html может что-то показывать.
Ничего, я думаю ты справишься, сам понимаешь, чем шире улыбка шефа, тем выше премия.
Но, Иван Васильевич, этот продукт в качестве источника данных использует только PDF файлы.
Зато он показывает шикарные разноцветные графики, у него анимация как в Звездных войнах, а руководство просто в восторге от его интерактивных возможностей. Там ещё и пасхалочка есть. Если три раза кликнуть в правом нижнем углу, появится Дарт Вейдер и споёт Марсельезу. Да и в целом, Вася, будь оптимистом! Хочешь анекдот в тему?

Что у вас запланировано на 1 января?
Катание на санках
А если снег не выпадет?
Это нас огорчит, но не остановит.

Не грусти Вася, принимайся за работу, а мне пора спешить утренняя планерка, эээ Daily Standup Meeting точнее, всё никак не могу запомнить.

Вася садится за свой рабочий стол и с грустью смотрит в монитор. Да уж, красивые графики, только толку от них? В Excel не выгрузить, с формулами не сверить, хоть бери тетрадку с ручкой и делай всё на бумаге. Плюс ещё как-то KPI на основе этого надо посчитать. Зато в ИТ отдел, говорят, художника взяли, чтобы он красивые отчеты для руководства оформлял. Глядя на новый продукт, Вася загрустил. В голове у него крутились пару строк из стихотворения C.А. Есенина Мне грустно на тебя смотреть:
Так мало пройдено дорог,
Так много сделано ошибок.

Ну что ж, оставим Васю на едине со своей болью и посмотрим на проблему шире. Видя переделку строк C.А. Есенина, которая вынесена в цитату к этой статье, мне кажется, что он не одинок в своих мыслях. Сложно понять, как работают современные BI системы и для кого их пишут то ли для аналитиков, то ли для руководителей. Очень много теории и информации, причём, в зависимости от источника, эта информация может противоречить самой себе. К этому стоит добавить обилие научных терминов и трудный для понимания язык описания. Сложно угадать с выбором, а цена ошибки велика, так как системы дорогие и работа с ними часто требует определенной квалификации. Понимая всё это, я решил поделиться своим опытом в BI сфере. Попытаюсь написать об этом простым языком и не вдаваться глубоко в теорию. Речь пойдет о Microsoft Analysis Services и о том, как он может решить часть проблем связанных с аналитической отчетностью. Другую часть этих проблем, я решил, написав специальную программу, которая позволяла формировать отчеты непосредственно в Excel, минуя HTML формы и минимизируя нагрузку на Web сервер, но о ней я уже писал тут http://personeltest.ru/aways/habr.com/ru/post/281703/, а тут даже видео снял: https://youtu.be/_csGSw-xyzQ. Приятного вам чтения.
Если лень читать, то есть кортокое видео (11 минут)
Создание OLAP-куба в Microsoft Analysis Services: https://youtu.be/f5DgG51KMf8
Но в этом видео далеко не всё то, о чём пойдёт речь далее!!!


Отчетность и её проблемы


Все началось с задачи, поставленной финансовым отделом крупного банка. Надо было создать систему отчетности, которая бы позволяла быстро и оперативно оценивать текущую ситуацию в организации. Для решения этой задачи мы взяли базу данных. Организовали в ней Хранилище (Data Warehouse), настроили процессы загрузки данных и установили систему отчетности. В качестве которой мы взяли SQL Server Reporting Services, так как этот продукт входил в MS Sharepoint, использовавшийся в тот момент в банке. В принципе всё работало, но у заказчика были претензии:

  • Претензия 1. HTML -> MS Excel: отчеты изначально формируются в HTML, а аналитики работают с MS Excel. Надо постоянно делать экспорт из одного формата в другой. При этом часто сбивается разметка и в Excel часто подгружается множество дополнительной информации, большой объём которой, в некоторых случаях, существенно влияет на производительность.
  • Претензия 2. Параметры для отчета: данные в отчетах зависят от параметров, причём при их изменении формируется новый отчет, который надо опять выгружать в Excel, что не всегда удобно.
  • Претензия 3. Добавление изменений в отчет: для того, чтобы что-то изменить в отчете, добавить новую колонку или создать группировку, надо обращаться к специалисту, который может поправить этот отчет на сервере.
  • Претензия 4. Анализ данных: отчеты получаются статическими и когда нужно посмотреть различные разрезы, поменять строки с колонками, отфильтровать или добавить, либо удалить какие-то значения, надо делать все эти манипуляции в Excel, что не всегда удобно, а порой и сложно, из-за проблем с производительностью компьютеров, на которых работают аналитики.

Стоит отметить, что сотрудники банка не рассматривали для себя никакого другого инструмента в качестве замены MS Excel. И на то были веские основания. Весь его функционал сложно чем-то заменить. К примеру, аналитики очень часто:

  • сверяли данные из базы по формулам, которые можно добавить в Excel,
  • хранили одни и те же срезы данных, сделанные в разные дни, с целью обнаружить ошибки,
  • добавляли туда свои данные,
  • писали различные скрипты

В общем использовали его на все 100%. Хотя были те, кто предлагал им что-то другое, точнее не столько предлагал, сколько заставлял. Как итог таких предложений, у нас в системе появились SAP BO, Oracle Reports Services и ряд других BI инструментов. Возможно, они в чем-то превосходили SQL Server Reporting Services, но суть работы с ними кардинально не изменилась:

  1. формируем отчет в HTML,
  2. экспортируем его в Excel,
  3. начинаем заниматься бесконечными танцами вокруг данных.

Требовалось что-то более кардинальное, не просто отчет, а некий набор данных, с которым удобно было бы работать.

Выход из ситуации


К найденному решению подтолкнули PivotTable в Excel



и PivotGrid от фирмы DevExpress ( https://demos.devexpress.com/blazor/PivotGrid).

Детально изучив эти решения вышли на MS Analysis Services и решили попробовать. Его можно использовать в Excel, и он может работать с Oracle, как с источником данных, что нас на тот момент устраивало. С точки зрения архитектуры, источником данных для него может служить что угодно, был бы нужный провайдер. Суть его в том, что он способен хранить в себе большие объемы данных со всеми их агрегациями и выдавать их клиенту максимально быстро. К Excel его можно легко подключить и манипулировать данными в Pivot Table.



В MS Analysis Services есть возможность партиционирования данных (хранение их в виде множества отдельных частей) и так же инкрементальное обновление данных. Это даёт ему возможность загружать данные из внешних систем небольшими кусочками и хранить их во множестве партиций. С точки зрения максимальных объемов, у него есть ограничения, но они довольно большие https://docs.microsoft.com/en-us/analysis-services/multidimensional-models/olap-physical/maximum-capacity-specifications-analysis-services?view=asallproducts-allversions.

MS Analysis Services является OLAP системой, которая использует отдельный сервер для хранения данных, либо части данных. Его плюсом является то, что он способен довольно быстро работать с миллионами записей, будучи установленным на обычный, современный компьютер. Так же он позволяет анализировать данные непосредственно в Excel и может заменить собой десятки отчетов на MS Reporting Services или ему подобных. Причем при работе с ним не надо писать и править различные запросы типа SQL, хотя при желании можно, только вместо SQL он использует MDX.

Правда есть тут и ложка дегтя. В Excel можно запросить разом очень большой объём данных и OLAP их вернет, но отобразить такой объем Excel не сможет, либо сможет, но работать при этом будет очень медленно. На первых порах это раздражало аналитиков, но поняв причину и настроив фильтры в Pivot Table эту проблему решили.

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

Немного теории


Чаще всего, когда анализируют данные их объединяют в группы, а сами группы так же объединяют в иерархии. Для примера возьмём торговую точку. С точки зрения бизнеса, интерес представляют продажи. То есть сколько товара было продано за день (1-группа), за месяц (2-ая) и за год (3-я). Где день месяц и год это разные уровни одной иерархии. Получается, что продажи за месяц это сумма всех продаж за все дни в месяце, а продажи за год это сумма продаж за все месяцы в этом году. Отсюда получается, что для получения максимального быстродействия, можно заранее собрать данные в группы и рассчитать агрегаты (в нашем примере суммы продаж) для каждого уровня иерархи. Вот на этом принципе и работают MS Analysis Services. Им достаточно сказать что надо считать, по какой формуле и на какие группы это можно разбить. Остальную работу они сделают сами. Тут немного о том как они это делают: http://citforum.ru/consulting/BI/molap_overview/node7.shtml. Стоит отметить, что в современных OLAP системах все агрегаты, чаще всего, не рассчитываются заранее. Это всё делается на лету, в момент запроса.

Теперь о терминах:


MS Analysis Services это одна из OLAP систем, где OLAP это аббревиатура online analytical processing. Дословно это означает интерактивная (online) аналитическая обработка данных. Со временем данная формулировка утратила свой первоначальный смысл, так как появились системы, способные обрабатывать данные с большой скоростью и передавать их пользователю без использования подходов, декларируемых в OLAP. Поэтому, сейчас есть более полное описание требований к системам, которые могут называться OLAP, это:


По своему опыту, могу сказать, что чем больше ваш OLAP куб удовлетворяет описанию Е.Ф. Кодда, тем лучше, как с точки зрения работы с ним, так и с точки зрения его создания.

Вкратце, OLAP это система хранения, организованная таким образом, чтобы данные в ней:

  • были взаимосвязаны,
  • собирались в иерархии,
  • имели функции агрегации по всему множеству иерархий

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

При построении OLAP выделяют Факты и Измерения. Факты это цифровые значения измеряемых величин. Измерения это сами измеряемые величины. Совокупность всех связанных между собой измерений, фактов и функций для их агрегации называют OLAP-кубом. Факты и Измерения связанны между собой. По типу связи выделяют 2 схемы организации хранения данных Звезда и Снежинка. Звезда это когда все измерения напрямую связаны с фактом, снежинка это когда есть измерения, которые связанны с фактом через другие измерения. Эти схемы можно создавать и просматривать в разделе Data Source Views в SSAS.







Создание OLAP-куба в Microsoft Analysis Services


Построение OLAP кубов делается через проект в Visual Studio. По большей части там реализована технология визуального программирования перетащить, кликнуть мышкой, настроить. Отсюда это проще показать, чем описать. Что я и сделал в моем видео: https://youtu.be/f5DgG51KMf8. Так же стоит отметить то, что Microsoft, в ознакомительных целях, предоставляет свои продукты бесплатно. Отсюда, посмотреть, как он работает можно на любом компьютере с ОС Windows 10, удовлетворяющем следующим требованиям: https://docs.microsoft.com/en-us/sql/sql-server/install/hardware-and-software-requirements-for-installing-sql-server-ver15?view=sql-server-ver15. Требования по ссылке к MS SQL Server, так как MS Analysis Services являются его частью.

Заключение


OLAP это относительно простой способ повысить скорость и удобство работы с данными. В данный момент существует множество решений, основанных на этой технологии. Я работал с MS Analysis Services (SSAS) и вот что мне в нём понравилось:

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

В заключение, хочу сказать, что мне MS Analysis Services, в свое время, очень сильно помог и я надеюсь, что знания, которыми я поделился в этой статье, так же кому-то помогут.
Подробнее..

Будущее без пластика как данные помогают экологии

20.05.2021 18:13:57 | Автор: admin

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

Пластик: добро и зло

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

Изначально бакелит создавался в качестве замены шеллаку природной смоле, вырабатываемой тропическими насекомыми лаковыми червецами. Произведя реакцию поликонденсации фенола и формальдегида, Лео Бакеланд сначала получил термопластичную фенолоформальдегидную смолу, которая отверждалась только в присутствии отвердителей. Данный полимер Лео Бакеланд назвал Novolak, однако успеха на рынке он не имел. Продолжая исследования в области реакции между фенолом и формальдегидом, а также подбирая различные наполнители (асбестовый порошок и др.), Лео Бакеланд получил полимер, не требующий отвердителей, для которого не смог найти растворителя. Это навело его на мысль, что такой практически нерастворимый и не проводящий электричества полимер может оказаться очень ценным. В 1909 году Лео Бакеланд сообщил о полученном им материале, который он назвал бакелитом. Данный материал был первым синтетическим реактопластом пластиком, который не размягчался при высокой температуре. Источник

Первый синтетический пластик Бакелит был изобретен в начале XX века, после чего мир сошел с ума. Если верить Our World in Data, за последние 65 лет ежегодное производство пластика увеличилось почти в 200 раз, до 381 млн. тонн. Пластик повсеместно вошел в жизнь каждого человека на планете.

К сожалению, популярность столь универсального материала негативно сказывается на экологии. По информации Национального управления океанических и атмосферных исследований США и Woods Hole Sea Grant, некоторые виды пластика могут разлагаться до 600 лет. Обочины дорог заполняются пластиковыми отходами, в океане образуются острова из пластика, флора и фауна страдают.

Вот несколько ключевых цифр:

  • За свою истории человечество произвело 8,3 млрд тонн пластика;

  • Половина этих объемов изготовлена в течение последних 13 лет;

  • Около 30% этих объемов до сих пор находятся в использовании;

  • Из пластика, оказавшегося на свалке, были переработаны менее 9%;

  • 12% были сожжены, еще 79% находятся на свалках;

  • Самое короткое использование у упаковочного пластика в среднем менее года;

  • Дольше всего пластиковая продукция используется в строительстве и машинном оборудовании;

  • Нынешние тенденции прогнозируют, что к 2050 году человечество изготовит 12 млрд. тонн пластика.

Мировой экономический форум предсказал, что к 2050 году океан будет содержать больше пластика (по весу), чем рыбы. По оценке The Ocean Cleanup Большое тихоокеанское мусорное пятно между Калифорнией и Гавайскими островами имеет площадь в три раза превышающую Францию. Вероятно, на этом участке находится более ста миллионов тонн мусора.

Мусорное пятно занимает большой, относительно стабильный участок на севере Тихого океана, ограниченный Северо-тихоокеанской системой течений (область, которую часто называют конскими широтами, или широтами штилевого пояса). Водоворот системы собирает мусор со всей северной части Тихого океана, в том числе из прибрежных вод Северной Америки и Японии. Отходы подхватываются поверхностными течениями и постепенно перемещаются к центру водоворота, который не выпускает мусор за свои пределы. Точный размер области неизвестен. Приблизительные оценки площади варьируются от 700 тыс. до 1,5 млн км и более (от 0,41 % до 0,81 % общей площади Тихого океана). Источник

Печальная статистика вместе с фотографиями погибших от пластика птиц и млекопитающих позволяет оценить масштаб проблемы. Многие морские животные даже принимают пластик как пищу, после чего тоже погибают. За последние годы в социальных сетях стал популярным хештег #plasticfree, на проблему пластика обратили свой взор не только простые обыватели, но и правительственные учреждения и бизнес.

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

Где и сколько?

Платформа TOPIOS (Tracking of Plastic in Our Seas) посвящена моделированию движения пластика в мировом океане. Проект координирует доктор Эрик ван Себиль из Университета Утрехта, известный океанолог и исследователь климатических изменений Земли.

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

Платформа TOPIOS как раз помогает найти оставшиеся 99 процентов пластика, скрывающиеся в толще морей и океанов. Цель заключается в том, чтобы оценить распределение пластика по поверхности и разным слоям океана. Сколько пластика оседает на дно и выбрасывается вдоль береговой линии? Сколько съедают морские животные?

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

Команда из Университета Утрехта моделирует пути распространения пластикового мусора, используя собранные данные из разных мест океана, а также симуляцию океанских течений в высоком разрешении. В компьютерные модели добавляется виртуальный пластик, который затем отслеживается через инструментарий oceanparcels с открытым исходным кодом. Код на Python и C доступен на GitHub, где над ним работает как команда TOPIOS, так и энтузиасты со стороны.

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

Платформа TOPIOS показывает, где накапливаются отходы пластика. А проект Our World in Data, который находится под патронажем Оксфордского университета и Global Change Data Lab, позволяет получить эти данные в удобной форме всем желающим. Причем можно посмотреть обширные статистические сведения по производству пластика, использованию в разных секторах деятельности человека. Какие страны хуже всего справляются с переработкой пластика и дают больше всего отходов? Какие реки выносят в океан больше всего пластика? Какие океаны можно назвать наиболее загрязненными? Все это вы можете посмотреть в подробном отчете.

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

На сайте можно отследить прогресс выполнения Целей устойчивого развития ООН. Несколько таких целей как раз касаются пластиковых отходов. Например, к 2025 году предотвратить и существенно снизить загрязнение океана всеми видами отходов.

Команда Our World in Data получает данные из трех основных источников: международные исследовательские организации и институты, опубликованные статьи и документы, информация статистических агентств, в том числе ОЭСР, Всемирный банк, ООН. Обработанные данные используются ведущими изданиями во всем мире, в том числе The New York Times, BBC и El Pais. Причем Our World in Data работает не только над темой пластика, но и, например, бедности и глобального изменения климата.

Сведения, предоставленные TOPIOS и Our World in Data, помогают оценить масштаб проблемы. Теперь остается перейти к ее решению.

#plasticfree будущее без пластика?

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

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

Как считают авторы отчета, наступил поворотный момент запрета пластиковых пакетов, 66 процентов стран в мире приняли законы, ограничивающие их оборот. Но те же пластиковые микрогранулы запрещены всего в восьми странах из анализируемых 192.

Трудно оценить, какой процент пластикового мусора составляют микрогранулы, поскольку большинство крупномасштабных исследований анализируют общие характеристики и количество микропластика в окружающей среде. Однако, по предварительным оценкам, микрогранулы составляют от 0,4 % до 4,1 % от всего пластикового мусора, находящегося в водной среде. Опасность таких частиц заключается в их размере и, соответственно, лёгком попадании в водную систему. В водной среде микрогранулы становятся частью пищевой цепи, поскольку многие морские обитатели принимают фрагменты пластика за еду. Согласно исследованию 2013 года, более 250 видов морских животных принимали микрогранулы за пищу, в том числе рыбы, черепахи и чайки. При попадании в организм микрогранулы не только лишают их необходимых питательных веществ, но и могут застревать в пищеварительном тракте и закупоривать жабры. Микрогранулы становятся неотъемлемой частью рациона мальков и коралловых полипов, предпочитающих микрогранулы зоопланктону. Также микрогранулы могут переносить и содержать другие адсорбированные загрязняющие вещества, такие как стойкие органические загрязнители и тяжёлые металлы. При употреблении микрогранул вредные вещества попадают в организм биоты. Источник

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

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

Пример команды Our World in Data показывает, как данные могут менять мир. Задача поставлена весьма амбициозная: если мир будет серьезно подходить к достижению поставленных целей, мы будем точно определять прогресс и публиковать результаты в доступной и понятной форме на публичной платформе. Только такой подход позволит сравнивать текущую ситуацию с предыдущими этапами. Мы сможем ответить на вопрос, движемся ли мы в правильном направлении. Либо, наоборот, выбран ошибочный путь.

Будущее без пластика #plasticfree цель непростая. Здесь потребуются усилия на всех уровнях: государства, бизнеса, обывателей. Только все вместе мы сможем снизить деструктивные последствия деятельности человечества и сохранить природу Земли, флору и фауну. И сила данных нам тоже в этом поможет!

Подробнее..

Как упростить доработки и поддержку хранилища данных?

08.06.2021 12:19:01 | Автор: admin

1. Адаптированная методология Anchor modeling

Архитектура ядра хранилища данных должна соответствовать описанной ниже адаптированной (не оригинальной) методологии Anchor modeling (но не Data Vault).

Тип таблицы

Примеры имени таблицы (в скобках описание)

С таблицами каких типов может быть связана

Обязательный тип поля

Примеры имени поля

Сущности (Anchor, Entity type). Обозначается квадратом

TR_Transaction (полупроводка по дебету или по кредиту), AC_Account (синтетический счет)

Связи, Атрибут сущностей

Суррогатный ключ сущности

TR_ID, AC_ID

Атрибут сущностей (Attribute). Обозначается кругом

TR_TDT_TransactionDate (дата заключения сделки)

Сущности

Суррогатный ключ сущности (является первичным ключом в течение срока действия записи)

TR_ID

Дата и время начала срока действия записи

TR_TDT_FROM

Дата и время окончания срока действия записи (не включительно)

TR_TDT_BEFORE

Атрибут сущностей

TR_TDT

Связи (Tie, Relationship). Обозначается ромбом

TR_AC_DC_Transaction_Account_DrCr (счет главной книги в полупроводке)

Сущности

Суррогатные ключи каждой связанной сущности (вместе с некоторыми атрибутами связей, обозначающими тип связи, образуют составной ключ в течение срока действия записи)

TR_ID, AC_ID

Дата и время начала срока действия записи

TR_AC_DC_FROM

Дата и время окончания срока действия записи (не включительно)

TR_AC_DC_BEFORE

Опциональный атрибут или несколько атрибутов связей

DC (дебет/кредит)

Схема данных примераСхема данных примера

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

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

В ядре хранилища данных не должны использоваться значения NULL, за исключением тех атрибутов связей, которые не входят в составной ключ (обычно это наименования, обозначения, коды, ссылки, выбранные значения, флаги). Если неизвестны начало и/или окончание срока действия записи, то должны указываться принятые условные даты (например, '0001-01-01', '-infinity', '9999-12-31', 'infinity').

Для облегчения создания полиморфных связей двухсимвольный код в именах должен совпадать с двумя последними символами в соответствующих суррогатных ключах, которыми обозначается тип сущностей или атрибут связей (см. ниже). Поэтому в нем необходимо использовать символы алфавита Crockford's base32.

Таблицы типа узел (knot) исключены из адаптированной методологии Anchor modeling. Однако типовое обозначение узла на схеме в виде квадрата с закругленными углами удобно использовать для обозначения атрибутов связей.

Набросок БД может быть сделан (в том числе, офлайн) с помощью наглядных и удобных веб-инструментов Online Modeler или Online Modeler (test version), но сгенерированный ими SQL-код непригоден для использования. Для генерации SQL-кода (включая SQL-запросы) по методологии Anchor modeling все известные компании используют самостоятельно разработанные ими инструменты на основе языка программирования Python и Microsoft Excel.

2. Суррогатные ключи в адаптированном формате ULID

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

В качестве суррогатного ключа должна использоваться адаптированная (не оригинальная) версия ULID (но не UUID), имеющая любой из двух форматов:

  • ttttttttttrrrrrrrrrrrrrrxx (пример: 01F5B023PBG3C48TSBDQQ3V9TR)

  • ttttttttttsssrrrrrrrrrrrxx (пример: 01F5B023PB00448TSBDQQ3V5TR)

где

t дата и время генерации с точностью до миллисекунды (Timestamp) (10 символов или 48 бит), UNIX-time в миллисекундах (UTC)

s счетчик от 0 до 32768, сбрасываемый каждую миллисекунду, (Sequence) (3 символа или 15 бит)

r случайное число (Randomness) (14/11 символов или 65/55 бит)

x тип сущностей (Entity type) (2 символа или 10 бит)

Должна использоваться кодировка и алфавит Crockford's base32.

Генератор ULIDов должен удовлетворять следующим требованиям:

  1. Соблюдение требуемого формата ULIDов

  2. Однократное использование каждого генерируемого ULIDа в качестве суррогатного ключа сущности

  3. Использование (достаточно производительного) криптографически стойкого генератора псевдослучайных чисел или генератора истинно случайных чисел

  4. Монотонное возрастание ULIDов в интервале менее миллисекунды (за счет инкремента случайного числа для формата без счетчика, или за счет счетчика для формата со счетчиком)

  5. Генерация ULIDов в формате (текстовый, бинарный, UUID или целочисленный), наиболее производительном для операций поиска в применяемых СУБД и носителе данных (HDD или SSD)

  6. Пиковая (в течение 5 мс) производительность генерации ULIDов должна быть выше максимальной производительности записи в применяемых СУБД и носителе данных (HDD или SSD) (например, за счет буферизации заранее вычисленных частей ULIDа)

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

3. Указание начала и окончания срока действия записи

Для сохранения историчности данных должен применяться второй тип медленно меняющегося измерения SCD2 с добавлением двух унифицированных полей (столбцов): Дата и время начала срока действия записи (имя столбца с суффиксом _FROM) и Дата и время окончания срока действия записи (не включительно) (имя столбца с суффиксом _BEFORE).

Единственным условием связи записей в таблицах, помимо суррогатного ключа, должно быть одновременное действие (valid time) связанных записей, определяемое унифицированными полями начала и окончания срока действия записи, но не датой загрузки в систему или датой создания записи (transaction time). Данные не должны храниться в форме срезов на отчетные или на текущую дату или за календарный период (например, месяц).

4. Указание даты и времени создания записи

Если нужно знать не только изменение состояния реального мира во времени, но и изменение состояния самой учетной системы (когда в учетной системе изменяются сведения об одном и том же моменте в реальном мире), то во все таблицы необходимо добавить поле с датой и временем создания записи (transaction time), являющееся частью составного ключа. Чтобы точно воспроизвести отчет, сформированный в определенный момент в прошлом, достаточно игнорировать записи, чьи дата и время создания позднее этого момента в прошлом.

Примеры имени поля: TR_TIMESTAMP, TR_TDT_TIMESTAMP, TR_AC_DC_TIMESTAMP.

5. Только внешние источники пунктов классификаторов

В учетной системе необходимо использовать пункты классификаторов (статьи доходов и расходов, синтетические счета, категории клиентов, типы продуктов и т.п.), полученные непосредственно из реального мира без каких либо изменений вместо разработки собственных или соединения в гибридных классификаторах. Пункты классификаторов могут быть получены из законодательства, из требований топ-менеджмента к отчетам и т.п.

Если при загрузке свежей версии классификатора изменился (исчез, появился) пункт классификатора, то должны автоматически рассчитываться и указываться окончание срока действия прежней запаси, а также начало и окончание действия новой записи.

6. Фасетная классификация

Необходимо по возможности использовать фасетную классификацию вместо иерархической классификации.

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

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

  • признак счета активный/пассивный,

  • глава,

  • раздел,

  • счет первого порядка,

  • тип контрагента,

  • срок.

7. Теги

Если есть большое количество атрибутов с логическими значениями true и false, то эти атрибуты удобнее заменить соответствующими тегами, которые можно хранить в одном поле типа array, типа hstore или типа jsonb.

8. Полиморфные связи

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

Однако использование таблиц связей в таких случаях нежелательно, так как их будет слишком много, и на их поддержание будет затрачиваться слишком много ресурсов IT-подразделения.

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

Если полиморфные связи необходимы одновременно с несколькими таблицами, то суррогатные ключи записей в этих связанных таблицах можно хранить в основной таблице в одном поле типа array, типа hstore или типа jsonb.

9. Устранение витрин данных

Каждый отчет должен формироваться непосредственно из реплики ядра хранилища данных.

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

10. Типовые SQL-запросы и материализованные представления

Разработка SQL-запросов к базе данных, соответствующей методологии Anchor modeling, трудоемка. Поэтому для облегчения работы системных аналитиков и SQL-программистов могут быть созданы типовые SQL-запросы или материализованные представления, соединяющие сущности с их атрибутами на задаваемую дату. Но использование таких SQL-запросов и материализованных представлений может привести к усложнению БД и снижению производительности. Поэтому для рабочей системы вместо них необходимо использовать автоматическую генерацию SQL-запросов (с использованием языка программирования Python и Microsoft Excel).

В качестве источника значений для заполнения полей могут использоваться соответствующие SQL-запросы, материализованные представления или созданные на их основе таблицы допустимых значений. Допустимые значения для заполнения полей могут определяться и таблицей решений (см. ниже).

Сильная нормализация данных в Anchor modeling не позволяет производить многие автоматические проверки целостности на уровне таблиц. Поэтому для проверки целостности и качества данных нужны соответствующие SQL-запросы, автоматически запускаемые перед вставкой данных в таблицы.

11. Вынесение логики из программного кода в таблицы решений

Логику необходимо по возможности выносить из программного кода на языках программирования, SQL и различных ORM в таблицы решений. Например, в таблице решений может быть закодирован выбор дебетуемого синтетического счета в зависимости от типа операции, категории контрагента и срока погашения финансового инструмента. Таблица решений может быть реализована двумя способами:

  • таблица сущностей правил, к которой привязаны входные атрибуты и один выходной атрибут,

  • таблица связей, соединяющая входные сущности и атрибуты с выходной сущностью либо с выходным атрибутом.

Первый способ очевидно более гибкий и упорядоченный.

Подробнее..

Шардинг, от которого невозможно отказаться

22.04.2021 10:12:30 | Автор: admin
image

А не пора ли нам шардить коллекции?
Не-е-е:


  • у нас нет времени, мы пилим фичи!
  • CPU занят всего на 80% на 64 ядерной виртуалке!
  • данных всего 2Tb!
  • наш ежедневный бекап идет как раз 24 часа!

В принципе, для большинства проектов вcё оправдано. Это может быть еще прототип или круг пользователей ограничен Да и не факт, что проект вообще выстрелит.
Откладывать можно сколько угодно, но если проект не просто жив, а еще и растет, то до шардинга он доберется. Одна беда, обычно, бизнес логика не готова к таким "внезапным" вызовам.
А вы закладывали возможность шардинга при проектировании коллекций?


Эта статья для продвинутых разработчиков.
Для тех, кто планирует шардинг своего кластера.
Для тех, кто уже шардировал кластер ранее, но админы все еще плачут.
Для тех, кто руками перемещал jumbo-чанки.


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


Всем привет, от команды разработки Smartcat и наших счастливых админов!


Мы разберём распространенный сценарий, который обычно мешает нам равномерно распределять данные. И опишем способ ослабления требований к ключу шардирования, который при этом не приведет к деградации производительности нашего кластера.


Зачем нам шардинг


Шардинг штатная возможность горизонтального масштабирования в MongoDB. Но, чтобы стоимость нашего шардинга была линейной, нам надо чтобы балансировщик MongoDB мог:


  • выровнять размер занимаемых данных на шард. Это сумма размера индекса и сжатых данных на диске.
  • выровнять нагрузку по CPU. Его расходуют: поиск по индексу, чтение, запись и агрегации.
  • выровнять размер по update-трафику. Его объем определяет скорость ротации oplog. Это время за которое мы можем: поднять упавший сервер, подключить новую реплику, снять дамп данных.

Конечно, мало толку будет от нового шарда, если на него переместится только пара процентов данных или не дойдет нагрузка на CPU или update-трафик.


Особенности шардинга в MongoDB


Как мы знаем балансировщик MongoDB при отсутствии ограничений (превышение размера данных на шард, нарушение границ зон) выравнивает только количество чанков на шард. Это простой, надежный и сходящийся алгоритм.
Есть документация про лимиты количества чанков и про порядок выбора размещения чанка.
Этот алгоритм и определяет главные ограничения на балансируемые данные:


  1. Ключ шардирования должен быть высокоселективный. В противном случае мы не получим достаточного числа интервалов данных для балансировки.
  2. Данные должны поступать с равномерным распределением на весь интервал значений ключа. Тривиальный пример неудачного ключа это возрастающий int или ObjectId. Все операции по вставке данных будут маршрутизироваться на последний шард (maxKey в качестве верхней границы).

Самое значимое ограничение гранулярность ключа шардирования.
Или, если сформулировать отталкиваясь от данных, на одно значение ключа должно приходиться мало данных. Где "мало" это предельный размер чанка (от 1Mb до 1Gb) и количество документов не превышает вот эту вот величину.


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


Бизнес логика требует слонов


Теперь давайте посмотрим, с чем мы будем сталкиваться при проектировании бизнес логики.
Я рассмотрю только самый чувствительный для шардирования случай, который заставляет наши данные группироваться в неравномерные объемы.
Рассмотрим следующий сценарий:


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

Пример модели:


{    _id: ObjectId("507c7f79bcf86cd7994f6c0e"),    projectId: UUID("3b241101-e2bb-4255-8caf-4136c566a962"),    name: "job name 1",    creation: ISODate("2016-05-18T16:00:00Z"),    payload: "any additional info"}

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


Теперь, надо выбрать второе поле ключа или оставить только первое.
Например, у нас 20% запросов используют только поле name, еще 20% только поле creation, а остальные опираются на другие поля.
Если в ключ шардирования включить второе поле, то крупные проекты, те у которых объем работ не помещается в одном чанке, будут разделены на несколько чанков. В процессе разделения, высока вероятность, что новый чанк будет отправлен на другой шард и для сбора результатов запроса нам придётся обращаться к нескольким серверам. Если мы выберем name, то до 80% запросов будут выполняться на нескольких шардах, тоже самое с полем creation. Если до шардирования запрос выполнялся на одном сервере, а после шардирования на нескольких, то нам придется дополнительную читающую нагрузку компенсировать дополнительными репликами, что увеличивает стоимость масштабирования.


С другой стороны, если оставить в ключе только первое поле, то у нас "идеальное" линейное разделение нагрузки. Т.е. каждый запрос с полем projectId будет сразу отправлен на единственный шард. Поэтому имеет смысл остановиться на этом выборе.
Какие риски есть у этого выбора:


  • у нас могут появляться не перемещаемые jumbo-чанки. При большом объеме работ в одном проекте мы обязательно превысим предельный размер чанка. Эти чанки не будут разделены балансировщиком.
  • у нас будут появляться пустые чанки. При увеличении проекта, балансировщик будет уменьшать диапазон данных чанка для этого проекта. В пределе, там останется только один идентификатор. Когда большой проект будет удален, то на этот узкий чанк данные больше не попадут.

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


В общем, мы можем посмотреть текущее распределение данных или просто прикинуть развитие проекта и допустить, что хоть jumbo-чанки и будут появляться, но их должно быть не много.


Проблемы с масштабированием


Итак, мы, вопреки ожиданиям, набрали достаточно неперемещаемых чанков, чтобы это стало заметно. То есть буквально, случай из практики. Вы заказываете админам новый шард за X$ в месяц. По логам видим равномерное распределение чанков, но занимаемое место на диске не превышает половины. С одной стороны весьма странное расходование средств было бы, а с другой стороны возникает вопрос: мы что же, не можем прогнозировать совершенно рутинную операцию по добавлению шарда? Нам совсем не нужно участие разработчика или DBA в этот момент.


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


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


Надеюсь, тут уже все уже запуганы и потеряли надежду. ;)


Решение


Попробуем сначала поправить основную боль администрирования.
Конечно, не хочется заново писать балансировку данных, нам надо просто "попросить" существующий балансировщик перекинуть часть чанков туда, где есть неиспользуемое место. Вариантов у нас два.


1-й воспользоваться командой moveChunk прямое указание балансировщику о перемещении конкретного чанка.


2-й воспользоваться командой addTagRange привязка диапазона значений ключа шардирования к некоторому шарду и их группе.


В обоих случаях потребуется также точное знание размера чанка. Это можно сделать командой dataSize, которая возвращает некоторую статистику по объектам в коллекции на заданном интервале ключей.


Предварительное прототипирование 1-го варианта выявило дополнительные особенности.


Команды moveChunk не отменяют работы штатного балансировщика. Он вполне может принять решение об обратном переносе. Тут надо блокировать работу штатного балансировщика. Или кроме перемещения больших чанков на недогруженный шард, надо искать на нем маленькие чанки и синхронно перемещать их на перегруженный шард.


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


Массовые сканирования dataSize ухудшают отзывчивость сервера на боевых запросах.


Ну и остается тупиковая ситуация, когда все чанки кроме jumbo просто равны по размеру. В этом случае перемещать просто нечего, или опять же придется блокировать работу штатного балансировщика.


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


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


Диапазоны ключей привязываются к тегу, а не к шарду. А сам шард может содержать несколько тегов. Поэтому для упрощения дальнейшего описания и работы условимся, что на каждый шард мы добавляем по одному тегу с названием этого шарда. Это позволит привязывать диапазон ключей на конкретный шард.


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


Группировка данных


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


Итак, коллекция уже шардирована.


  • Читаем все ее чанки из коллекции config.chunks с сортировкой по возрастанию ключа {min: 1}
  • Распределяем чанки по шардам, так чтобы их было примерно одинаковое количество. Но при этом все чанки на одном шарде должны объединяться в один интервал.

Например:


У нас есть три шарда sh0, sh1, sh2 с одноименными тегами.
Мы вычитали поток из 100 чанков по возрастанию в массив


var chunks = db.chunks.find({ ns: "demo.coll"}).sort({ min: 1}).toArray();

Первые 34 чанка будем размещать на sh0
Следующие 33 чанка разместим на sh1
Последние 33 чанка разместим на sh2
У каждого чанка есть поля min и max. По этим полям мы выставим границы.


sh.addTagRange( "demo.coll", {shField: chunks[0].min}, {shField: chunks[33].max}, "sh0");sh.addTagRange( "demo.coll", {shField: chunks[34].min}, {shField: chunks[66].max}, "sh1");sh.addTagRange( "demo.coll", {shField: chunks[67].min}, {shField: chunks[99].max}, "sh2");

Обратите внимание, что поле max совпадает с полем min следующего чанка. А граничные значения, т.е. chunks[0].min и chunks[99].max, всегда будут равны MinKey и MaxKey соответственно.
Т.е. мы покрываем этими зонами все значения ключа шардирования.


Балансировщик начнёт перемещать чанки в указанные диапазоны.
А мы просто ждем окончания работы балансировщика. Т.е. когда все чанки займут свое место назначения. Ну за исключением jumbo-чанков конечно.


Коррекция размера


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


sh.addTagRange( "demo.coll", {shField: MinKey}, {shField: 1025}, "sh0");sh.addTagRange( "demo.coll", {shField: 1025}, {shField: 5089}, "sh1");sh.addTagRange( "demo.coll", {shField: 5089}, {shField: MaxKey}, "sh2");

Вот так будет выглядеть размещение чанков:


Командой db.demo.coll.stats() можно получить объем данных, которые хранятся на каждом шарде. По всем шардам можно вычислить среднее значение, к которому мы хотели бы привести каждый шард.


Если шард надо увеличить, то его границы надо перемещать наружу, если уменьшить, то внутрь.
Так как уже явно заданы диапазоны ключей, то балансировщик не будет их перемещать с шарда на шард. Следовательно, мы можем пользоваться командой dataSize, мы точно знаем данные какого шарда мы сканируем.
Например, нам надо увеличить sh0 за счет h1. Границу с ключем будем двигать в бОльшую сторону. Сколько именно данных мы сместим перемещением конкретного 34-го чанка, мы можем узнать командой dataSize с границами этого чанка.


db.runCommand({ dataSize: "demo.coll", keyPattern: { shField: 1 }, min: { shField: 1025 }, max: { shField: 1508 } })

Последовательно сканируя чанки по одному мы мы можем смещать границу до нужного нам размера sh0.


Вот так будет выглядеть смещение границы на один чанк



Вот пример команд для фиксации нового состояния границ в конфигурации кластера.
Мы сначала удаляем пару интервалов со старыми значениями границ, потом заводим новые интервалы с актуальными значениями границ.


sh.removeTagRange( "demo.coll", {shField: MinKey}, {shField: 1025}, "sh0");sh.removeTagRange( "demo.coll", {shField: 1025}, {shField: 5089}, "sh1");sh.addTagRange( "demo.coll", {shField: MinKey}, {shField: 1508}, "sh0");sh.addTagRange( "demo.coll", {shField: 1508}, {shField: 5089}, "sh1");

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


Выгодные особенности этого подхода:


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

Дополнительные возможности


Вообще, на практике требуется выравнивание используемого объема диска на шардах, а не только части шардированных коллекции. Частенько, нет времени или возможности проектировать шардирование вообще всех БД и коллекций. Эти данных лежат на своих primary-shard. Если их объем мал, то его легко учесть при коррекции размера и просто часть данных оттащить на другие шарды.


С течением времени, особенно после частых удалений, будут образовываться пустые чанки. Не то чтобы они теперь сильно мешают, но их может быть сильно больше чанков с данными. Чтобы они не заставляли страдать роутер, было бы хорошо их прибрать. Раньше (до дефрагментации) их надо было найти, переместить к другому чанку-соседу на один шард, потом запустить команду mergeChunks. Перемещение нужно, т.к. команда объединяет только соседние чанки на одном шарде.
Есть даже скрипты для автоматизации, но они долго работают, и есть один тикет с печально низким приоритетом.


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


Почти итог


Итак, проблема решена.
Хорошо, что не пришлось заменять или сильно вмешиваться в работу штатного балансировщика. Он продолжает рулить другими коллекциями или диапазонами данных. А в наших настроенных диапазонах он выполняет разделение чанков и таскает чанки между серверами как мы попросим.


Наши плюсы:


  • точная балансировка занимаемого размера
  • лучшее распределение update-трафика
  • минимальное сканирование при коррекциях
  • бесплатная уборка пустых чанков
  • минимальные допуски на запасное/неиспользуемое дисковое пространство на каждом шарде
  • мы всегда можем удалить привязки диапазонов ключей и вернуться к исходному состоянию

Минусы:


  • требуется настройка и сопровождение привязок диапазонов ключей.
  • усложняется процесс добавления нового шарда.

Но это было бы слишком скучно Время победить слонов и не вернуться!


Победа над слонами!


Как мы уже отмечали, единственная причина неперемещаемых чанков недостаточная селективность ключа шардирования. Мы сами снижали селективность ключа для привязки запроса к шарду. Но мы уже сгруппировали данные, а теперь мы можем этим коварно воспользоваться!


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


Вспомним пример модели:


{    _id: ObjectId("507c7f79bcf86cd7994f6c0e"),    projectId: UUID("3b241101-e2bb-4255-8caf-4136c566a962"),    name: "job name 1",    creation: ISODate("2016-05-18T16:00:00Z"),    payload: "any additional info"}

Ранее мы выбрали ключ шардирования {projectId: 1}
Но теперь при проектировании можно выбрать любые уточняющие поля для ключа шардирования:


  • {projectId: 1, name: 1}
  • {projectId: 1, creation: 1}
  • {projectId: 1, _id: 1}

А если вы пользуетесь MongoDB версии 4.4 и выше, то там есть удобная функция уточнение ключа шардирования на существующих данных.


Данные дефрагментированы, а это дает нам гарантии того, что основной объем документов работ с одинаковым projectId будет находиться на одном шарде. Как это выглядит на практике?


Вот иллюстрация примеров размещения работ по чанкам. В случае, если мы выбрали ключ шардирования {projectId: 1, _id: 1}



Здесь, для упрощения примера, идентификаторы представлены целыми числами.
А термином "проект" я буду называть группу работ с одинаковым projectId.


Некоторые проекты будут полностью умещаться в один чанк. Например, проекты 1 и 2 размещены в 1м чанке, а 7-й проект во 2-м.
Некоторые проекты будут размещены в нескольких чанках, но это будут чанки с соседними границами. Например, проект 10 размещен в 3, 4 и 5 чанках, а проект 18 в 6 и 7 чанках.
Если мы будем искать работу по ее полю projectId, но без _id, то как будет выглядеть роутинг запросов?


Планировщик запросов MongoDB отлично справляется с исключением из плана запроса тех шардов, на которых точно нет нужных данных.
Например, поиск по условию {projectId: 10, name: "job1"} будет только на шарде sh0


А если проект разбит границей шарда? Вот как 18-й проект например. Его 6-й чанк находится на шарде sh0, а 7-й чанк находится на шарде sh1.
В этом случае поиск по условию {projectId: 18, name: "job1"} будет только на 2х шардах sh0 и sh1. Если известно, что размер проектов у нас меньше размера шарда, то поиск будет ограничен только этими 2-мя шардами.


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


Теперь переформулируем для более общего случая.
У нас есть составной ключ шардирования. По первому полю нам требуется группировка, но оно слабоселективное. Второе поле, нужно просто чтобы увеличить общую селективность ключа.
С помощью дефрагментации, мы добиваемся следующих свойств:


  • группа располагается на одном, максимум двух шардах.
  • число групп которые имели несчастье разместиться на 2х шардах ограничено числом границ. Для N шардов будет N-1 граница.

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


И вот теперь, от дефрагментации данных нам уже никуда не деться.


Точно итог


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


Теперь уже можно оценить достижения и потери.
Достижения:


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

Потери:


  • если за счет дефрагментации мы убирали jumbo-чанки, то мы теперь с ней навсегда. Вернуть ключ мы не можем. Удаление границ приведет к фрагментации данных и снижению доли одно шардовых запросов.
  • периодически надо проводить коррекции границ. Но кажется это мы сможем автоматизировать.
  • при добавлении нового шарда надо явно планировать переразбиение.

Осталось спроектировать весь процесс дефрагментации, расчета поправок и коррекции границ Ждите!

Подробнее..

Автоматизация в центрах обработки данных

17.05.2021 12:14:39 | Автор: admin

В большинстве серверов HPE имеется встроенный контроллер управления Integrated Lights Out (iLO). Его первоначальное назначение удаленное управление сервером:
включение/выключение, перехват графической консоли, подключение медиа-устройств что и иллюстрирует название Lights-Out Свет выключен в ЦОД, где трудятся серверы HPE, администратору нет необходимости быть рядом. Все действия с серверами можно выполнить из любой точки мира. Функционал iLO постоянно расширялся и сейчас его можно назвать центром управления полетом сервера, фактически это мини-компьютер внутри большого компьютера. У iLO есть процессор, оперативная и флэш-память, Ethernet порт и, естественно, интерфейс управления: веб-браузер, командная строка, скрипты и программируемые интерфейсы REST API. Через REST API и осуществляется автоматизированное управление серверами HPE в соответствии со стандартом Redfish, пришедшим на смену устаревшему IPMI.

Следующий уровень управления инфраструктурой HPE программный продукт HPE OneView. Для стоечных и блейд-серверов c-Class это виртуальная машина (поддерживаются все основные гипервизоры), для платформы HPE Synergy это аппаратный модуль Composer. Управляется HPE OneView аналогично iLO: веб-интерфейс, скрипты и команды RESTful API / Redfish.

HPE OneView обеспечивает полное низкоуровневое управление серверной инфраструктурой: настройка BIOS, конфигурирование сетевых интерфейсов, подключение к SAN, создание томов на внешних системах хранения (HPE Primera, HPE Nimble, HPE 3PAR), контроль и обновление драйверов и микропрограмм. Все эти действия можно выполнять для одного или нескольких серверов, как используя консоль браузера, так и с помощью скриптов PowerShell или Python. Но самых интересных результатов можно достичь путем интеграции OneView со средствами развертывания операционных систем и приложений. В этом случае администратору вообще не нужно обращаться к OneView, все необходимые действия выполняются в вышестоящей консоли управления. Например, для среды VMware единой консолью служит vCenter, для Microsoft Windows Admin Center.

REST и Redfish

Если говорить о REST (Representational State Transfer), то он представляет собой обычный HTTP(s) запрос, передавая необходимые данные в качестве параметров запроса. В отличие от Redfish (более современной версии REST), REST никак не стандартизирован, он лишь является архитектурным стилем, позволяющим придерживаться определенных последовательностей, таких как запрос, тело запроса и параметры запроса. При этом какое дерево запроса, по какому стандарту передается тело запроса (JSON, XML или другой), каждый производитель решает на свое усмотрение. В итоге это привело к тому, что если пользователь работал с REST-интерфейсами от нескольких вендоров, то к ним требовался разный подход, а часто и разный набор кода, что не позволяло масштабировать решения основанные на REST-запросах.

В отличие от REST, Redfish является стандартизированным интерфейсом и позволяет работать пользователю с разными производителями с одинаковым подходом и тем самым, обеспечивать масштабируемость решения. В решениях HPE стандарт Redfish появился в ILO4 (v2.30) и более поздних продуктах.

Решение HPE по автоматизации (Deployment Automation Solution)

При преодолении определенной численности информационных систем и нарастании запросов со стороны бизнеса, сотрудники отдела сопровождения часто приходят к целесообразности автоматизации ежедневных, рутинных операций. Это помогает вводить и обслуживать информационные системы быстрее, а сотрудникам сконцентрироваться на более важных задачах. Обычно администраторы пытаются автоматизировать задачи собственными силами и привычными им средствами. В этом им помогает широкий набор инструментов (https://github.com/hewlettpackard/), таких как Ansible, Python, Puppet и других. При этом, как правило самостоятельно написанные скрипты приходится часто править, особенно при масштабировании решения в условиях продуктивной среды.

Deployment Automation Solution представляет собой услугу по настройке решения автоматизации ежедневных операций, построенного на открытом исходном коде, либо их коммерческих аналогов, которые уже используются на предприятии. Таким образом потребители решения смогут вносить правки, как в само решение, делая его более заточенным под конкретную организацию, так и добавлять в решение собственные наработки, тем самым расширяя функционал базового решения. Deployment Automation Solution основан на стандартных программных компонентах, таких как Ansible, для автоматизации и оркестрации, Nginx для предоставления библиотеки образов микрокодов, операционных систем и файлов конфигураций и GitLab как способ централизованной доставки скриптов и Ansible playbooks. Таким образом, использование стандартных отраслевых инструментов с помощью сценариев Ansible, связанных с базовым репозиторием кода и инфраструктурным конвейером DevOps с помощью GitLab делает подход системным, а масштабирование удобным. Большинство компонент работает в контейнерах, что дает возможность быстро развертывать и обновлять само решение.

Весь процесс взаимодействия построен на программно-определяемой инфраструктуре посредством использования существующих богатых функций OneView Ansible collection / REST API, предназначенных для среды управления HPE OneView, или Redfish / iLO для управляемых сред, без OneView, а также API-интерфейсов хранилищ данных. Также используются API конкретного программного производителя, например:

  • Ansible Playbooks от RHEL могут связываться с серверами Linux через SSH;

  • Подключение к VMware может осуществляться через REST API или SSH;

  • Связь с Windows может быть через WinRM.

Для удобства оркестрации решения и построения сложных рабочих процессов автоматизации используется AWX (https://github.com/ansible/awx, upstream project для Ansible Tower) или Ansible Automation Platform (https://www.ansible.com/integrations/infrastructure/hpe), для объединения и инкапсуляции атомарной инфраструктуры в виде базовых операций кода в рабочие процессы автоматизации для реализации задач выделения ресурсов и управления жизненным циклом. Этот модульный подход позволяет гибко настраивать интеграцию аппаратных и программных элементов решения. При этом AWX, или Ansible Automation Platform не является обязательным атрибутом. Все рабочие процессы доступны через REST API и могут быть вызваны из любого существующего решения, такого как HPE ServiceNow или Morpheus. решение достаточно гибкое, чтобы интегрироваться с порталом управления, выбранным каждым клиентом, и обеспечивает интеграцию с любым сторонним решением.

В базовом варианте решения HPE предоставляет два основных сценария использования:

  • Установка операционных систем, включая настройку аппаратных компонент: презентация томов СХД, настройка зонинга для SAN и т.д, а также программных компонент, включая настройки безопасности и манипуляции с ПО;

  • Обновление микрокодов, в том числе и без прерывания работы серверов.

При этом заказчик получит доступ к репозиторию с обновлениями playbooks для поддержки новых сценариев и компонент. Из коробки решение заточено под аппаратную платформу HPE, включая новейшие аппаратные ресурсы: DL Gen10, Synergy, Apollo и 3PAR / Primera / Nimble, однако открытый исходный код и поддержка разнообразных API позволит пользователям интегрировать решения сторонних производителей.

Заключение

Инфраструктура Hewlett Packard Enterprise предоставляет широкие возможности по автоматизации ежедневных ИТ-операций: подготовка и развертывание новых серверов, подключение к сетям передачи данных и системам хранения, установка операционных систем, контроль и обновление драйверов и firmware, реконфигурирование систем под изменяющиеся требования приложений. Заказчики сами выбирают уровень автоматизации: от простых сценариев групповых операций с iLO до решений Инфраструктура как код с HPE OneView и Ansible AWX / Automation Platform.

Подробнее..

На каких серверах держится Архив Интернета?

31.03.2021 12:04:48 | Автор: admin

Фото 1. Один из дата-центров Internet Archive в Сан-Франциско

Internet Archive некоммерческая организация, которая с 1996 года сохраняет копии веб-страниц, графические материалы, видео- и аудиозаписи и программное обеспечение. Каждый может зайти в Wayback Machine и посмотреть, как выглядел Хабр в 2006 году или Яндекс в 1998 году, хотя загрузка архивных копий занимает около минуты (это не для реализма 90-х, а по техническим причинам, см. ниже).

Архив быстро растёт. Сейчас объём всех накопителей достиг 200 петабайт. Но Internet Archive принципиально не обращается к стороннему хостингу или облачному сервису вроде AWS. У некоммерческой организации собственные дата-центры, свои серверы и свои инженеры. Это гораздо дешевле, чем услуги AWS.

Архив Интернета против облаков


Технические подробности серверного устройства Internet Archive раскрыл Джона Эдвардс (Jonah Edwards), руководитель инженерной группы Core Infrastructure Team.

По его мнению, понятие облако многих людей вводит в заблуждение как нечто абстрактное. На самом деле это просто чужие компьютеры, то есть серверы посторонней компании. Для Internet Archive это неприемлемо. У организации собственные серверные в собственных зданиях, компьютеры принадлежат им, и персонал тоже свой.


Четыре дата-центра Internet Archive располагаются в Сан-Франциско, Ричмонде и Редвуд-Сити (это пригороды Сан-Франциско)

Кто-то может посчитать такой подход архаичным, но в некоторых случаях он действительно оправдан. В случае Internet Archive на то есть три причины: это дешевле, обеспечивает лучший контроль за серверами и даёт гарантию, что пользователей не отслеживают рекламные трекеры.

Деньги на обслуживание инфраструктуры и зарплаты сотрудникам собираются преимущественно за счёт пожертвований и грантов, годовой бюджет составляет около $10 млн.

Инфраструктура


Что представляет собой инфраструктура, которой управляет Core Infrastructure Team? На февраль 2021 года цифры такие:

  • 750 серверов, возраст до 9 лет;
  • 1300 виртуальных машин;
  • 30 000 устройств хранения данных;
  • более 20 000 жёстких дисков в парах друг с другом (paired storage), обычно пара разнесена по дата-центрам или странам для надёжности;
  • общий объём накопителей почти 200 петабайт.

Разумеется, техника постепенно обновляется. На смену старым накопителям приходят новые. Например, маленькие диски на 2 и 3 терабайта полностью вышли из обращения в 2017 и 2018 годах, соответственно, а с прошлого года постоянно растёт доля дисков на 16 ТБ.

Как показано на графике ниже, несмотря на увеличение ёмкости накопителей, общее число HDD тоже постепенно растёт: за три года оно выросло с 15 тыс. до 20 тыс.


Количество жёстких дисков разного объёма на серверах Internet Archive

Диски реплицируются по дата-центрам, для производительности контент по запросу выдаётся одновременно со всех копий. Все элементы Архива представляют собой директории на дисках. Веб-страницы Wayback Machine хранятся в файлах WARC (Web ARChive, сжатые файлы Web Archive). При запросе отдельной страницы её нужно извлечь из середины архива WARC, а если страница требует загрузки дополнительных ресурсов, то процесс повторяется. Это одна из причин, почему полная загрузка страниц из Wayback Machine достигает 90 секунд, хотя закэшированные копии и популярный контент загружаются быстрее.



Для надёжности копии Архива хранятся не только в Сан-Франциско, но и ещё в нескольких локациях по всему миру, в том числе в Амстердаме (Нидерланды) и Новой Александрийской библиотеке (Египет).

В 1996 году первые серверы Internet Archive подняли на недорогих компьютерах из стандартных комплектующих: по сути, на обычных десктопах под Linux. Хотя инфраструктура сильно выросла, в качестве операционной системы всегда использовали только Linux. С 2004 года все серверы перешли на Ubuntu, сейчас продолжается миграция на Ubuntu 20.4 LTS (Focal Fossa).

Объём Архива


В последнее время объём Архива возрастает примерно на 25% в год, сейчас это соответствует 56 петабайтам в квартал. С учётом резервных копий нужно добавлять накопителей на 1012 петабайт в квартал.

Одна копия Архива занимает более 45 петабайт, но на дисках и лентах хранится минимум две копии каждого объекта.

Как видно на графике вверху, обновление дискового массива происходит только за счёт моделей максимальной ёмкости. Например, в конце 2021 года планируется переход на диски по 20 ТБ, и тогда в серверы будут устанавливать только их. Остальные HDD постепенно доживают свой век, и их количество медленно снижается.

Internet Archive возлагает большие надежды на новые технологии записи данных, такие как HAMR (heat-assisted magnetic recording), чтобы ёмкость HDD увеличивалась ещё быстрее. Технология HAMR предусматривает предварительное нагревание магнитной поверхности лазером в процессе записи, что позволяет значительно уменьшить размеры магнитной области, хранящей один бит информации и увеличить плотность записи. Нагрев выполняется с помощью лазера, который за 1 пс разогревает область записи до 100 C.

Разработка этой технологии затянулась на 15 лет, но в январе 2021 года были официально представлены первые диски HAMR на 20 ТБ. Пока что они официально поставляются только избранным клиентам в рамках фирменного сервиса Seagate Lyve, но вскоре должны появиться в свободной продаже.

Seagate обещает, что HAMR позволит наращивать ёмкость HDD на 20% в год. Поэтому в ближайшее время можно ожидать модель на 24 ТБ, а в будущем диски на 30 и 50 ТБ. Internet Archive тоже надеется на это и внимательно следит за последними разработками.

На текущем размере дисков понадобится 15 вот таких серверных стоек, чтобы разместить одну копию Архива:


У Internet Archive 750 серверов и 20 000 жёстких дисков

Сейчас в дата-центрах установлено 75 серверных стоек, что обеспечивает некоторый запас и избыточное копирование.

По состоянию на февраль 2021 года на серверах хранились копии 534 млрд веб-страниц, 16 млн аудиозаписей, 8,7 млн видеозаписей фильмов, клипов и телепередач, 3,8 млн изображений, 629 тыс. компьютерных программ, более 29 млн книг и текстов, в том числе 72 771 текст на русском языке.



Любой пользователь может создать аккаунт и добавить в архив медиафайлы.

Internet Archive поддерживает API для внешних сервисов. Например, сторонний сервис может забирать контент из хранилища и показывать его на своём сайте или в приложении. Можно строить собственные каталоги на базе этого хранилища, эксплуатируя IA просто как удалённый бесплатный хостинг файлов с хотлинками. Подобную модель использует книжный каталог Open Library на базе Internet Archive. Хотлинки и модель подобной эксплуатации собственных ресурсов поощряется со стороны Архива. Кстати, аналогичные правила действуют в Wikimedia Commons: холинкинг разрешён и даже поощряется, что недавно вызвало казус с фотографией цветка: по непонятной причине ежедневно в сеть Wikimedia Commons поступало около 90 млн одинаковых запросов на получение одного файла AsterNovi-belgii-flower-1mb.jpg. Будем надеяться, что у Internet Archive таких инцидентов не случится.

Сеть


В 2020 году Internet Archive пережил серьёзный рост количества запросов и объёма внешнего трафика с 40 до 60 Гбит/с. Из-за пандемии коронавируса и самоизоляции ресурсы Архива стали более востребованы. Количество запросов росло так быстро, что в определённый момент маршрутизаторы Internet Archive перестали справляться с нагрузкой, пришлось делать апгрейд сетевой инфраструктуры быстрее, чем планировалось. Сейчас веб-сайт входит в топ-300 крупнейших сайтов интернета.

Работа на собственных серверах имеет и свои недостатки. Основные причины сбоев Internet Archive обрывы оптоволокна из-за строительных работ в городе, сбои энергоснабжения, случайные провалы напряжения в сети. Впрочем, прошлый год сайт завершил с аптаймом 99,9%.



Internet Archive планирует расширять внешний канал. Ожидается, что в ближайшее время внешний трафик вырастет до 80 Гбит/с.

Примерно так выглядит дизайн внутренней сети:



Дата-центры подключены к нескольким провайдерам первого уровня (Tier 1) и соединены между собой по оптоволокну с применением технологии плотного спектрального уплотнения (DWDM). Локальные университетские сети подключаются к этому кольцу напрямую через локальные точки обмена трафиком.

Вместо нынешнего оптоволокна планируется проложить пары 100-гигабитных кабелей по всему кольцу из четырёх дата-центров, так что внешний трафик тоже можно будет увеличить до 100 Гбит/с.

Прокладка новых кабелей по Сан-Франциско весьма хлопотное и дорогое дело. Приходится перекладывать асфальт на автомобильных дорогах и тротуарах. К счастью, Internet Archive удалось получить официальный статус библиотеки, что даёт доступ к государственным субсидиям, в том числе к бюджету Федеральной комиссии по связи США (FCC) на подключение всех библиотек к интернету. Таким образом, львиную долю расходов на прокладку, обслуживание оптоволокна и трафик оплачивает FCC по программе E-Rate Universal Service Program.

С 2005 года Internet Archive начал проект Open Library по сканированию книг. С одной стороны, это действительно важный общественный проект. С другой стороны, он позволил получить государственные льготы и финансирование в качестве публичной библиотеки.

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

Планы на будущее


Инженеры Internet Archive сейчас обдумывают варианты использования SSD и GPU в основных серверах, чтобы увеличить их производительность. Главная проблема здесь в том, что все дата-центры находятся в стеснённых городских условиях Сан-Франциско и пригородов с очень ограниченными возможностями охлаждения (см. фото 1). Так что каждый апгрейд требуется хорошо обдумать: не приведёт ли он к повышению температуры.

Интересно наблюдать за ростом инфраструктуры Internet Archive с увеличением количества серверных стоек. Есть подозрение, что рано или поздно наступит момент, когда сложность поддержания своей инфраструктуры превысит некий порог и библиотека откажется от собственных дата-центров. Но пока что инженеры Core Infrastructure Team успешно справляются с работой.

В зависимости от методологии расчёта, хранение данных в собственных дата-центрах Internet Archive обходятся в 25 раз дешевле, чем в облаке. И это только хранение. Сложно даже посчитать, сколько будет стоить круглосуточный исходящий трафик 60 Гбит/с на AWS. Вероятно, он обойдётся даже дороже, чем хранение 200 петабайт.

Похоже, что некоторые сервисы просто слишком велики для облака. Компаниям приходится поднимать собственные дата-центры, потому что у них нет выхода. Другой вопрос: должна ли библиотека заниматься этим самостоятельно? Получается, что современная цифровая библиотека это по сути хостинг-провайдер и дата-центр?



На правах рекламы


Эпичные серверы это надёжные VDS на Linux или Windows с мощными процессорами семейства AMD EPYC и очень быстрой файловой системой, используем исключительно NVMe диски от Intel. Попробуйте как можно быстрее!

Подробнее..

Новая схватка двух якодзун или Scylla vs Aerospike ( HBase для массовки)

08.04.2021 18:23:51 | Автор: admin
В прошлый раз обсуждение битвы тяжеловесов Cassandra VS HBase вызвало весьма бурную дискуссию, в ходе которой было много раз упомянута Scylla которая позиционируется как более быстрый аналог Cassandra (далее CS). Также меня заинтересовал весьма любопытный Aerospike (далее AS), который в своих тестах предсказуемо побеждает CS с разгромным счетом.
image

По удивительному совпадению Scylla (далее SC) также легко бьет CS, о чем гордо сообщает прямо на своей заглавной странице:



Таким образом естественным образом возникает вопрос, кто кого заборет, кит или слон?

В моем тесте оптимизированная версия HBase (далее HB) работает с CS на равных, так что он тут будет не в качестве претендента на победу, а лишь постольку, что весь наш процессинг построен на HB и хочется понимать его возможности в сравнении с лидерами.

Понятно, что бесплатность HB и CS это огромный плюс, однако с другой стороны если для достижения одинаковой производительности нужно в х раз больше железа, выгоднее бывает заплатить за софт, чем выделять этаж в ЦОД под дорогие грелки. Особенно учитывая, что если уж речь зашла про производительность, то так как HDD в принципе не способны дать хоть сколько-нибудь приемлемую скорость Random Access чтений (см. "Почему HDD и быстрые Random Access чтения несовместимы"). Что в свою очередь означает покупку SSD, который в объемах нужных для настоящей BigData весьма недешевое удовольствие.

Таким образом, было сделано следующее. Я арендовал 4 сервера в облаке AWS в конфигурации i3en.6xlarge где на борту каждого:
CPU 24 vcpu
MEM 192 GB
SSD 2 x 7500 GB


Если кто-то захочет повторить, то сразу отметим, что очень важно для воспроизводимости брать конфигурации, где полный объем дисков (7500 GB). Иначе диски придется делить с непредсказуемыми соседями, которые обязательно испортят ваши тесты, как им наверняка кажется весьма ценной нагрузкой.

Далее, раскатал SC при помощи конструктора, который любезно предоставил производитель на собственном сайте. После чего залил утилиту YCSB (которая уже практически стандарт для сравнительного тестирования БД) на каждую ноду кластера.

Есть только один важный нюанс, мы практически во всех случаях используем следующий паттерн: прочитать запись до изменения + записать новое значение.

Поэтому я модифицировал update следующим образом:

  @Override  public Status update(String table, String key,                       Map<String, ByteIterator> values) {    read(table, key, null, null); // << added read before write    return write(table, key, updatePolicy, values);  }


Далее я запускал нагрузку одновременно со всех 4х хостов (тех же самых где расположены сервера БД). Это сделано сознательно, потому что бывает клиенты одних БД больше потребляют ЦПУ чем другие. Учитывая, что размеры кластера ограничены, то хочется понимать совокупную эффективность реализации как серверной, так и клиентской части.

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

Насчет AS это весьма привлекательная БД, лидер в номинации удовлетворенности клиентов по версии ресурса g2.


Признаться, мне она тоже как-то приглянулась. Ставится легко, вот этим скриптом достаточно легко раскатывается в облако. Стабильная, конфигурировать одно удовольствие. Однако есть у ней один очень большой недостаток. На каждый ключ она выделяет 64 байта оперативной памяти. Кажется немного, но в промышленных объемах это становится проблемой. Типичная запись в наших таблицах весит 500 байт. Именно такой объем value я использовал почти* во всех тестах (*почему почти будет ниже).

Так как мы храним по 3 копии каждой записи, то получается что для хранения 1 PB чистых данных (3 PB грязных) мы должны будем выделить всего-то 400 TB оперативки. Идем дальше нет чтооо?! Секундочку, а нельзя ли с этим что-нибудь сделать? спросили мы у вендора.

Ха, конечно можно много чего, загибаем пальцы:
1. Упаковать несколько записей в одну (хопа).
2. Тоже самое что в п.1, только за счет расширения числа полей.
3. Включить режим all-flush. Суть хранить индекс не в памяти, а на диске. Правда есть нюанс, Ватсон, опция доступна только в entreprise версии (в моем случае в рамках trial-периода)

Хорошо, теперь разберемся с HB и можно уже будет рассмотреть результаты тестов. Для установки Hadoop у Амазона предусмотрена платформа EMR, которая позволяет легко раскатать необходимый вам кластер. Мне пришлось только поднять лимиты на число процессов и открытых файлов, иначе падало под нагрузкой и заменил hbase-server на свою оптимизированную сборку (подробности тут). Второй момент, HB безбожно тормозит при работе с одиночными запросами, это факт. Поэтому мы работаем только батчами. В данном тесте батч = 100. Регионов в таблице 100.

Ну и последний момент, все базы тестировались в режиме strong consistency. Для HB это из коробки. AS доступно только в enterprise версии. SC гонялась в режиме consistency=all.

Итак, поехали. Insert AS:

10 sec: 360554 operations; 36055,4 current ops/sec;
20 sec: 698872 operations; 33831,8 current ops/sec;

230 sec: 7412626 operations; 22938,8 current ops/sec;
240 sec: 7542091 operations; 12946,5 current ops/sec;
250 sec: 7589682 operations; 4759,1 current ops/sec;
260 sec: 7599525 operations; 984,3 current ops/sec;
270 sec: 7602150 operations; 262,5 current ops/sec;
280 sec: 7602752 operations; 60,2 current ops/sec;
290 sec: 7602918 operations; 16,6 current ops/sec;
300 sec: 7603269 operations; 35,1 current ops/sec;
310 sec: 7603674 operations; 40,5 current ops/sec;
Error while writing key user4809083164780879263: com.aerospike.client.AerospikeException$Timeout: Client timeout: timeout=10000 iterations=1 failedNodes=0 failedConns=0 lastNode=5600000A 127.0.0.1:3000
Error inserting, not retrying any more. number of attempts: 1Insertion Retry Limit: 0


Упс, а вы точно продюссер промышленная база? Можно подумать так на первый взгляд. Однако оказалось, что проблема в ядре амазонской версии линукса. На них завели тикет и в версии amzn2-ami-hvm-2.0.20210326.0-x86_64-gp2 проблему исправили. Но для этих тестов вендор предложил использовать скрипты ансибла под ubuntu, где эта проблема не возникала (для раскатки нужно выбрать соответствующую ветку в гите).

Ладно, продолжаем. Запускаем загрузку 200 млн. записей (INSERT), потом UPDATE, потом GET. Вот что получилось (ops операций в секунду):


ВАЖНО! Это скорость одной ноды! Всего их 4, т.е. чтобы получить суммарную скорость нужно умножать на 4.

Первая колонка 10 полей, это не совсем честный тест. Т.е. это когда индекс в памяти, чего в реальной ситуации BigData недостижимо.

Вторая колонка это упаковка 10 записей в 1. Т.е. тут уже реально идет экономия памяти, ровно в 10 раз. Как отлично видно из теста, такой фокус не проходит даром, производительность существенно падает.

Ну и наконец all-flush, тут примерно такая же картина. Чистые вставки хуже, но ключевая операция Update быстрее, так что дальше будем сравнивать только с all-flush.

Собственно не будем тянуть кота, сразу вот:


Все в общем-то понятно, но что тут стоит добавить.
1. Вендор AS подтвердил, что результаты выше по их БД релевантные.
2. У SC вставки были какие-то не очень правильные, вот более подробный график в разрезе по серверам:


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

Еще нужно понимать, что это весьма скромный объем данных и на больших объемах ситуация может измениться. В ходе экспериментов я спалил несколько сотен баксов, так что энтузиазма хватило только на long-run тест лидера и в ограниченном одним сервером режиме.


Почему оно так просело и что за оживление в последней трети загадка природы. Можно также заметить, что скорость радикально выше, чем в тестах чуть выше. Полагаю это потому что выключен режим strong consistency (т.к. сервер всего один).

Ну и наконец GET+WRITE (поверх залитых тестом выше пары миллиардов записей):


Что за просадка такая, в душе не догадываюсь. Никаких посторонних процессов не запускалось. Возможно как-то связано с кешом SSD, потому что утилизация во время всего хода тестирования AS в режиме all-flush была 100%.


На этом собственно все. Выводы в целом очевидны, нужно больше тестов. Желательно всех самых популярных БД в одинаковых условиях. В инете этого как-то этого жанра как-то не особо много. А хорошо бы, тогда вендоры баз будут мотивированы оптимизироваться, мы осознанно выбирать лучших.
Подробнее..

Подключаем SSD форм-фактора М2 к материнке, у которой нет разъема М2 и делаем этот SSD системным. Танцы с бубном

02.04.2021 16:10:53 | Автор: admin

Предыстория

Давным-давно, когда в мире жестких дисков только стали появляться твердотельные, я, как все прогрессивное человечество, озаботился приростом производительности посредством этой самой твердотельности носителей. Был куплен недорогой SSD марки Vertex, объемом 120 Гб и с успехом водружен в потроха компьютера. Не помню уже как туда заливалась система (и какая), с трудностями или без, но прирост скорости ощутился конкретно. К диску прилагалась наклейка со словами My SSD is faster then your HDD, что грело обладателя сего девайса.

Как видим из картинки c тех прошло более 4 лет, и за это время номер Винды вырос до десятки, а место на диске сократилось до критического. Как я не старался чистить загрузочный диск, десятая винда пухла неподецки, пока уже негде стало разворачивать пополнение, и на экран стали выплевываться разные меседжи от макрософта по этому поводу И тут кто-то мне сказал, что винда пухнет просто от времени и чистить диск бесполезно Поможет только либо переустановка, либо покупка нового диска. Наверно это правда.

А тут еще мне попалась статейка о том, что оказывается пропускная способность у шины PCI Express огого, а используется она как-то неправильно.

А тут еще появилась память форм-фактора М2 с какими-то бешенными цифрами по доступу

Судите сами:

SSD Kingston A2000 250GB SA2000M8/250G M.2, PCI Express 3.0 x4, контроллер Silicon Motion SM2263EN, микросхемы 3D TLC NAND, последовательный доступ: 2000/1100 MBps, случайный доступ: 150000/180000 IOps

Kingston потому что в два раза дешевле самсунга, а ежели не видно разницы, то зачем платить больше

Вот я и подумал, раз апгрейдиться, то в новый форм-фактор. Беда заключалась в том, что у моей материнской платы не было разъема М2, а поставить систему на такой скоростной диск очень хотелось

А еще я нашел, как кто-то уже проделал такой финт ушами и мне осталось только повторить. Причем агрейдили на моей материнке Ежели кому интересно, смотрим здесь.

а здесь еще и видос можно посмотреть на эту же тему

Казалось бы, все просто! Но не тут-то было

История

Был скачан новый биос, модифицирован для М2 по инструкции, все подготовлено, осталось дождаться переходника от китайцев М2 -> PCIExpress.

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

Ура, система видит диск! Ну все, готовим загрузочную флеху, заливаем десятую винду

И в этом месте обнаруживается, что установка винды на данный диск невозможна Потому как выбранный диск имеет стиль разделов MBR

Ну ладно. Во время инициализации можно сделать стиль GPT. Опять лезем в инициализацию устанавливаем стиль разделов GPT, заливаем десятую винду

И в том же месте обнаруживается, что установка винды на данный диск невозможна Потому как выбранный диск имеет стиль разделов GPT (оказывается, это тоже противопоказание!) А еще в биосе типо нету какого-то драйвера для этого диска Впадаем в ступор

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

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

В ступоре долго сидеть не рекомендуется, посему надо искать какой-то выход.

Случайно на разорванной упаковке от кингстоновского диска нахожу Softwate Activation Key для Acronis True Image HD О, эта же приблуда умеет клонить диски. В том числе и с системой.

Ну думаю, сейчас клонирую старый диск на новый и вуаля

Чтобы воспользоваться этим методом пришлось зарегистрироваться на сайте, создать эккаунт, установить прогу, активироваться Все, клонируем. Пробуем загрузиться

Обломатушки Выдало целый экран сообщений, что не фига, не буду загружаться нету бута или он какой-то не тот уже не важно

Более того, Acronis разфигачил диск 250 Гиг на тома на 120 Гиг (старая система) и остаток, еще 130 Гиг И соединить их обратно никак

После гугления находим несколько неработающих способов, но в конечном итоге помог этот:

Запускаем командную строку от имени администратора.

В командной строке вводим diskpart

Выводим список дисков при помощи команды list disk

Запоминаем номер нужного диска, и вводим select disk *, где вместо звёздочки вводим нужный номер.

Выводим список разделов - list partition

Тут находим раздел восстановления, запоминаем его номер и вводим select partition * вместо звезды номер раздела.

Наконец, вводим команду delete partition override после неё раздел будет затёрт.

Все эти манипуляции на Ваш страх и риск! Удалите не тот раздел - система не запустится!

Фух Сработало! Объединяем диск в первоначальный объем. Думаем, что дальше делать Продолжаем гуглить И тут я натыкаюсь на вот этот вот видос:

Там пол видео идет расжевывание не очень мне интересной информации, а вот во второй половине, как раз то, что мне было нужно. Вкратце я изложу, что было сделано, а кому нужно будет поподробнее смотрите видос. Там все понятно. Даже я понял.

Во-первых, использование программы Bootice, о которой я даже никогда не слыхал. Она понадобилась для переформатирования диска М2 для дальнейшего его использования в UEFI BIOS платформах. В этой проге создается так называемые ESP раздел (EFI System Partition) или загрузочный том. В видосе показано, как это делается. Появилась надежда, что раз диск форматируется таким специальным образом, то может он все-таки запустится

Во-вторых, далее показывается использование программы WinNTSetup. С помощью этой программы можно заливать Винду из образа, расположенного на локальном компе на другой диск этого же компа, что очень удобно. Как раз наш случай. Обращаю внимание, что в качестве загрузчика используется тот самый ESP раздел, о котором шла речь в предыдущем абзаце. Ну и в завершение нужно указать куда (на какой диск) мы будем заливать Винду.

Там, при указании пути к образу есть нюанс. Я не сразу понял, что произошло: указываешь один путь (причем каким-то странным способом), а в строке отображается совсем другое. Оказалось, что это нормально.

После установки некоторых дополнительных параметров программы запускается заливка Винды на новый SSD формата М2. По окончании процесса WinNTSetup попросит перезагрузку.

В этом случае я рекомендую загрузить сначала биос, там указать первым появившийся загрузчик ESP, после него наш диск M2 (они там отображаются раздельно) и после этого уже дать системе загрузиться. И еще я для чистоты эксперимента отключил старый SSD.

После загрузки должна начаться стандартная установка Windows 10. Во всяком случае у меня так было. Система встала без сучка и задоринки! Теперь у меня на диске С 250Gb на достаточно шустром SSD. Надеюсь хватит на ближайшие 4 года. А также надеюсь, что изложенное кому-то поможет не наступать на мои грабли. Всем удачи!

Подробнее..

Что нам стоит загрузить JSON в Data Platform

16.06.2021 16:13:28 | Автор: admin

Всем привет!

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

То есть, если возвращаться к финальной картинке из упомянутой выше статьи (специально дублирую ее, чтобы уважаемым читателям было удобнее), то сегодня мы будем более углубленно говорить о реализации правой части схемы той, что лежит после Apache NiFi.

Схема из прошлой нашей статьи.Схема из прошлой нашей статьи.

Напомним, что в нашей компании более 350 реляционных баз данных. Естественно, не все они уникальны и многие представляют собой по сути разные экземпляры одной и той же системы, установленной во всех магазинах торговой сети, но все же зоопарк разнообразия присутствует. Поэтому без какого-либо Frameworkа, упрощающего и ускоряющего интеграцию источников в Data Platform, не обойтись.

Общая схема доставки данных из источников в ODS-слой Greenplum посредством разработанного нами frameworkа приведена ниже:

Общая схема доставки данных в ODS-слой Greenplum Общая схема доставки данных в ODS-слой Greenplum
  1. Данные из систем-источников пишутся в Kafka в AVRO-формате, обрабатываются в режиме реального времени Apache NiFi, который сохраняет их в формате parquet на S3.

  2. Затем эти файлы с сырыми данными с помощью Sparkа обрабатываются в два этапа:

    1. Compaction на данном этапе выполняется объединение для снижения количества выходных файлов с целью оптимизации записи и последующего чтения (то есть несколько более мелких файлов объединяются в несколько файлов побольше), а также производится дедубликация данных: простой distinct() и затем coalesce(). Результат сохраняется на S3. Эти файлы используются затем для parsing'а , а также являются своеобразным архивом сырых необработанных данных в формате как есть;

    2. Parsing на этой фазе производится разбор входных данных и сохранение их в плоские структуры согласно маппингу, описанному в метаданных. В общем случае из одного входного файла можно получить на выходе несколько плоских структур, которые в виде сжатых (как правило gzip) CSV-файлов сохраняются на S3.

  3. Заключительный этап загрузка данных CSV-файлов в ODS-слой хранилища: создается временная external table над данными в S3 через PXF S3 connector, после чего данные уже простым pgsql переливаются в таблицы ODS-слоя Greenplum

  4. Все это оркестрируется с помощью Airflow.

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

  • создать в ODS-слое Хранилища таблицы-приемники данных;

  • в репозитории метаданных в Git согласно принятым стандартам прописать в виде отдельных YAML-файлов:

    • общие настройки источника (такие как: расписание загрузки, входной и выходной формат файлов с данными, S3-бакет, имя сервисного пользователя, имя и email владельца для нотификации в случае сбоя загрузки и т.п.);

    • маппинг данных объектов источника на таблицы слоя ODS (при этом поддерживаются как плоские, так и вложенные структуры и массивы, а также есть возможность данные из одного объекта раскладывать в ODS-слое по нескольким таблицам). То есть описать, как необходимо сложную вложенную структуру разложить в плоские таблицы;

До недавнего времени такой подход удовлетворял текущие наши потребности, но количество и разнообразие источников данных растет. У нас стали появляться источники, которые не являются реляционными базами данных, а генерируют данные в виде потока JSON-объектов. Кроме того на горизонте уже маячила интеграция источника, который под собой имел MongoDB и поэтому будет использовать MongoDB Kafka source connector для записи данных в Kafka. Поэтому остро встала необходимость доработки нашего frameworkа для поддержки такого сценария. Хотелось, чтобы данные источника сразу попадали на S3 в формате JSON - то есть в формате "как есть", без лишнего шага конвертации в parquet посредством Apache NiFi.

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

df = spark.read.format(in_format) \               .options(**in_options) \               .load(path) \               .distinct()    new_df = df.coalesce(div)new_df.write.mode("overwrite") \             .format(out_format) \            .options(**out_options) \            .save(path)

Но если мы проделаем все те же манипуляции с JSON-данными, то волей-неволей внесем изменения во входные данные, так как при чтении JSONов Spark автоматом определит и сделает mergeSchema, т.е. мы тем самым можем исказить входные данные, чего не хотелось бы. Ведь наша задача на этом шаге только укрупнить файлы и дедублицировать данные, без какого-либо вмешательства в их структуру и наполнение. То есть сохранить их как есть.

По-хорошему, нам надо было просто прочитать данные как обычный текст, дедублицировать строки, укрупнить файлы и положить обратно на S3. Для этого был предложен достаточно изящный способ:

рассматривать файлы с JSON-объектами как DataFrame с одной колонкой, содержащей весь JSON-объект.

Попробуем сделать это. Допустим, мы имеем следующий файл данных:

file1:

{productId: 1, productName: ProductName 1, tags: [tag 1, tag 2], dimensions: {length: 10, width: 12, height: 12.5}}{productId: 2, price: 10.01, tags: [tag 1, tag 2], dimensions: {length: 10, width: 12, height: 12.5}}

Обратите внимание на формат этого файла. Это файл с JSON-объектами, где 1 строка = 1 объект. Оставаясь, по сути, JSON-ом, он при этом не пройдет синтаксическую JSON-валидацию. Именно в таком виде мы сохраняем JSON-данные на S3 (есть специальная "галочка в процессоре Apache NiFi).

Прочитаем файл предлагаемым способом:

# Читаем данныеdf = spark.read \          .format("csv") \          .option("sep", "\a") \          .load("file1.json")# Схема получившегося DataFramedf.printSchema()root |-- _c0: string (nullable = true)# Сами данныеdf.show()+--------------------+|                 _c0|+--------------------+|{"productId": 1, ...||{"productId": 2, ...|+--------------------+

То есть мы тут читаем JSON как обычный CSV, указывая разделитель, который никогда заведомо не встретится в наших данных. Например, Bell character. В итоге мы получим DataFrame из одного поля, к которому можно будет также применить dicstinct() и затем coalesce(), то есть менять существующий код не потребуется. Нам остается только определить опции в зависимости от формата:

# Для parquetin_format = "parquet"in_options = {}# Для JSONin_format = "csv"in_options = {"sep": "\a"}

Ну и при сохранении этого же DataFrame обратно на S3 в зависимости от формата данных опять применяем разные опции:

df.write.mode("overwrite") \           .format(out_format) \.options(**out_options) \  .save(path)  # для JSON     out_format = "text" out_options = {"compression": "gzip"}  # для parquet   out_format = input_format out_options = {"compression": "snappy"}

Следующей точкой доработки был шаг Parsing. В принципе, ничего сложного, если бы задача при этом упиралась в одну маленькую деталь: JSON -файл, в отличии от parquet, не содержит в себе схему данных. Для разовой загрузки это не является проблемой, так как при чтении JSON-файла Spark умеет сам определять схему, и даже в случае, если файл содержит несколько JSON-объектов с немного отличающимся набором полей, корректно выполнит mergeSchema. Но для регулярного процесса мы не могли уповать на это. Банально может случиться так, что во всех записях какого-то файла с данными может не оказаться некоего поля field_1, так как, например, в источнике оно заполняется не во всех случаях. Тогда в получившемся Spark DataFrame вообще не окажется этого поля, и наш Parsing, построенный на метаданных, просто-напросто упадет с ошибкой из-за того, что не найдет прописанное в маппинге поле.

Проиллюстрирую. Допустим,у нас есть два файла из одного источника со следующим наполнением:

file1 (тот же что и в примере выше):

{productId: 1, productName: ProductName 1, tags: [tag 1, tag 2], dimensions: {length: 10, width: 12, height: 12.5}}{productId: 2, price: 10.01, tags: [tag 1, tag 2], dimensions: {length: 10, width: 12, height: 12.5}}

file2:

{productId: 3, productName: ProductName 3, dimensions: {length: 10, width: 12, height: 12.5, package: [10, 20.5, 30]}}

Теперь прочитаем Sparkом их и посмотрим данные и схемы получившихся DataFrame:

df = spark.read \          .format("json") \          .option("multiline", "false") \          .load(path)df.printSchema()df.show()

Первый файл (схема и данные):

root |-- dimensions: struct (nullable = true) |    |-- height: double (nullable = true) |    |-- length: long (nullable = true) |    |-- width: long (nullable = true) |-- price: double (nullable = true) |-- productId: long (nullable = true) |-- productName: string (nullable = true) |-- tags: array (nullable = true) |    |-- element: string (containsNull = true)+--------------+-----+---------+-------------+--------------+|    dimensions|price|productId|  productName|          tags|+--------------+-----+---------+-------------+--------------+|[12.5, 10, 12]| null|        1|ProductName 1|[tag 1, tag 2]||[12.5, 10, 12]|10.01|        2|         null|[tag 1, tag 2]|+--------------+-----+---------+-------------+--------------+

Второй файл (схема и данные):

root |-- dimensions: struct (nullable = true) |    |-- height: double (nullable = true) |    |-- length: long (nullable = true) |    |-- package: array (nullable = true) |    |    |-- element: double (containsNull = true) |    |-- width: long (nullable = true) |-- productId: long (nullable = true) |-- productName: string (nullable = true)+--------------------+---------+-------------+|          dimensions|productId|  productName|+--------------------+---------+-------------+|[12.5, 10, [10.0,...|        3|ProductName 3|+--------------------+---------+-------------+

Как видно, Spark корректно выстроил схему отдельно для каждого файла. Если в какой-либо записи не было обнаружено поля, имеющегося в другой, то в DataFrame мы видим корректное проставление null (поля price и productName для первого файла).

Но в целом схемы получились разные, и если у нас в маппинге прописано, что нам нужно распарсить эти данные (то есть оба файла) в следующую плоскую структуру,

root |-- price: double (nullable = true) |-- productId: long (nullable = true) |-- productName: string (nullable = true)

а во входных данных у нас присутствуют только файлы а-ля file2, где поля price нет ни у одной записи, то Spark упадет с ошибкой, так как не найдет поля price для формирования выходного DataFrame. С parquet-файлами такой проблемы как правило не возникает, так как сам parquet-файл генерируется из AVRO, который уже содержит полную схему данных и, соответственно, эта полная схема есть и в parquet-файле.

Еще надо отметить, что, естественно, мы хотели по максимум переиспользовать уже существующий и зарекомендовавший себя код нашего frameworkа, а не городить какую-то полностью отдельную ветку для обработки JSONов то есть все изменения хотелось сделать на этапе чтения JSON-файлов с S3.

Таким образом очевидно, что для корректной загрузки данных из JSON-файлов необходимо предопределить схему JSON-файла с данными и читать файлы уже с применением этой схемы. Тогда у нас даже если в JSONе нет какого-то поля, то в самом DataFrame это поле будет, но его значение подставится как null:

df = spark.read \          .format("json") \          .option("multiline","false") \          .schema(df_schema) \          .load(path)

Первая мысль была использовать для хранения схемы имеющийся сервис метаданных - то есть описать схему в YAML-формате и сохранить в имеющемся репозитории. Но с учетом того, что все данные источников у нас проходят через Kafka, решили, что логично для хранения схем использовать имеющийся Kafka Schema Registry, а схему хранить в стандартном для JSON формате (другой формат, кстати говоря, Kafka Schema Registry не позволил бы хранить).

В общем, вырисовывалась следующая реализация:

  • Читаем из Kafka Schema Registry схему

  • Импортируем ее в pyspark.sql.types.StructType что-то типа такого:

# 1. получаем через Kafka Schema Registry REST API схему данных # 2. записываем ее в переменную schema и далее:df_schema = StructType.fromJson(schema)
  • Ну и с помощью полученной схемы читаем JSON-файлы

Звучит хорошо, если бы Давайте посмотрим на формат JSON-схемы, понятной Sparkу. Пусть имеем простой JSON из file2 выше. Посмотреть его схему в формате JSON можно, выполнив:

df.schema.json()  
Получившаяся схема
{    "fields":    [        {            "metadata": {},            "name": "dimensions",            "nullable": true,            "type":            {                "fields":                [                    {"metadata":{},"name":"height","nullable":true,"type":"double"},                    {"metadata":{},"name":"length","nullable":true,"type":"long"},                    {"metadata":{},"name":"width","nullable":true,"type":"long"}                ],                "type": "struct"            }        },        {            "metadata": {},            "name": "price",            "nullable": true,            "type": "double"        },        {            "metadata": {},            "name": "productId",            "nullable": true,            "type": "long"        },        {            "metadata": {},            "name": "productName",            "nullable": true,            "type": "string"        },        {            "metadata": {},            "name": "tags",            "nullable": true,            "type":            {                "containsNull": true,                "elementType": "string",                "type": "array"            }        }    ],    "type": "struct"}

Как видно, это совсем не стандартный формат JSON-схемы.

Но мы же наверняка не первые, у кого встала задача конвертировать стандартную JSON-схему в формат, понятный Sparkу - подумали мы и В принципе, не ошиблись, но несколько часов поиска упорно выводили исключительно на примеры, из серии:

как сохранить схему уже прочитанного DataFrame в JSON, затем использовать повторно

либо на репозиторий https://github.com/zalando-incubator/spark-json-schema, который нам бы подошел, если мы использовали Scala, а не pySpark

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

К счастью, у нас уже был один источник, генерирующий данные в формате JSON. Как временное решение схема его интеграции в DataPlatform была незамысловата: NiFi читал данные из Kafka, преобразовывал их в parquet, использую прибитую гвоздями в NiFi схему в формате AVRO-schema, и складывал на S3. Схема данных была действительно непростой и с кучей вложенных структур и нескольких десятков полей - неплохой тест-кейс в общем-то:

Посмотреть длинную портянку, если кому интересно :)
root |-- taskId: string (nullable = true) |-- extOrderId: string (nullable = true) |-- taskStatus: string (nullable = true) |-- taskControlStatus: string (nullable = true) |-- documentVersion: long (nullable = true) |-- buId: long (nullable = true) |-- storeId: long (nullable = true) |-- priority: string (nullable = true) |-- created: struct (nullable = true) |    |-- createdBy: string (nullable = true) |    |-- created: string (nullable = true) |-- lastUpdateInformation: struct (nullable = true) |    |-- updatedBy: string (nullable = true) |    |-- updated: string (nullable = true) |-- customerId: string (nullable = true) |-- employeeId: string (nullable = true) |-- pointOfGiveAway: struct (nullable = true) |    |-- selected: string (nullable = true) |    |-- available: array (nullable = true) |    |    |-- element: string (containsNull = true) |-- dateOfGiveAway: string (nullable = true) |-- dateOfGiveAwayEnd: string (nullable = true) |-- pickingDeadline: string (nullable = true) |-- storageLocation: string (nullable = true) |-- currentStorageLocations: array (nullable = true) |    |-- element: string (containsNull = true) |-- customerType: string (nullable = true) |-- comment: string (nullable = true) |-- totalAmount: double (nullable = true) |-- currency: string (nullable = true) |-- stockDecrease: boolean (nullable = true) |-- offline: boolean (nullable = true) |-- trackId: string (nullable = true) |-- transportationType: string (nullable = true) |-- stockRebook: boolean (nullable = true) |-- notificationStatus: string (nullable = true) |-- lines: array (nullable = true) |    |-- element: struct (containsNull = true) |    |    |-- lineId: string (nullable = true) |    |    |-- extOrderLineId: string (nullable = true) |    |    |-- productId: string (nullable = true) |    |    |-- lineStatus: string (nullable = true) |    |    |-- lineControlStatus: string (nullable = true) |    |    |-- orderedQuantity: double (nullable = true) |    |    |-- confirmedQuantity: double (nullable = true) |    |    |-- assignedQuantity: double (nullable = true) |    |    |-- pickedQuantity: double (nullable = true) |    |    |-- controlledQuantity: double (nullable = true) |    |    |-- allowedForGiveAwayQuantity: double (nullable = true) |    |    |-- givenAwayQuantity: double (nullable = true) |    |    |-- returnedQuantity: double (nullable = true) |    |    |-- sellingScheme: string (nullable = true) |    |    |-- stockSource: string (nullable = true) |    |    |-- productPrice: double (nullable = true) |    |    |-- lineAmount: double (nullable = true) |    |    |-- currency: string (nullable = true) |    |    |-- markingFlag: string (nullable = true) |    |    |-- operations: array (nullable = true) |    |    |    |-- element: struct (containsNull = true) |    |    |    |    |-- operationId: string (nullable = true) |    |    |    |    |-- type: string (nullable = true) |    |    |    |    |-- reason: string (nullable = true) |    |    |    |    |-- quantity: double (nullable = true) |    |    |    |    |-- dmCodes: array (nullable = true) |    |    |    |    |    |-- element: string (containsNull = true) |    |    |    |    |-- timeStamp: string (nullable = true) |    |    |    |    |-- updatedBy: string (nullable = true) |    |    |-- source: array (nullable = true) |    |    |    |-- element: struct (containsNull = true) |    |    |    |    |-- type: string (nullable = true) |    |    |    |    |-- items: array (nullable = true) |    |    |    |    |    |-- element: struct (containsNull = true) |    |    |    |    |    |    |-- assignedQuantity: double (nullable = true) |-- linkedObjects: array (nullable = true) |    |-- element: struct (containsNull = true) |    |    |-- objectType: string (nullable = true) |    |    |-- objectId: string (nullable = true) |    |    |-- objectStatus: string (nullable = true) |    |    |-- objectLines: array (nullable = true) |    |    |    |-- element: struct (containsNull = true) |    |    |    |    |-- objectLineId: string (nullable = true) |    |    |    |    |-- taskLineId: string (nullable = true)

Естественно, я не захотел перебивать руками захардкоженную схему, а воспользовался одним из многочисленных онлайн-конвертеров, позволяющих из Avro-схемы сделать JSON-схему. И тут меня ждал неприятный сюрприз: все перепробованные мною конвертеры на выходе использовали гораздо больше синтаксических конструкций, чем понимала первая версия конвертера. Дополнительно пришло осознание, что также как и я, наши пользователи (а для нас пользователями в данном контексте являются владельцы источников данных) с большой вероятностью могут использовать подобные конвертеры для того, чтобы получить JSON-схему, которую надо зарегистрировать в Kafka Schema Registry, из того, что у них есть.

В результате наш SparkJsonSchemaConverter был доработан появилась поддержка более сложных конструкций, таких как definitions, refs (только внутренние) и oneOf. Сам же парсер был оформлен уже в отдельный класс, который сразу собирал на основании JSON-схемы объект pyspark.sql.types.StructType

У нас почти сразу же родилась мысль, что хорошо бы было поделиться им с сообществом, так как мы в Леруа Мерлен сами активно используем продукты Open Source, созданные и поддерживаемые энтузиастами со всего мира, и хотим не просто их использовать, но и контрибьютить обратно, участвуя в разработке Open Source продуктов и поддерживая сообщество. В настоящий момент мы решаем внутренние орг.вопросы по схеме выкладывания данного конвертера в Open Source и, уверен, что в ближайшее время поделимся с сообществом этой наработкой!

В итоге благодаря написанному SparkJsonSchemaConverterу доработка шага Parsing свелась только к небольшому тюнингу чтения данных с S3: в зависимости от формата входных данных источника (получаем из сервиса метаданных) читаем файлы с S3 немного по-разному:

# Для JSONdf = spark.read.format(in_format)\            .option("multiline", "false")\            .schema(json_schema) \            .load(path)# Для parquet:df = spark.read.format(in_format)\            .load(path)

А дальше отрабатывает уже существующий код, раскрывающий все вложенные структуры согласно маппингу и сохраняющий данные DataFrameа в несколько плоских CSV-файлов.

В итоге мы смогли при относительном минимуме внесенных изменений в код текущего frameworkа добавить в него поддержку интеграции в нашу Data Platform JSON-источников данных. И результат нашей работы уже заметен:

  • Всего через месяц после внедрения доработки у нас на ПРОДе проинтегрировано 4 новых JSON-источника!

  • Все текущие интеграции даже не заметили расширения функционала frameworkа, а значит, мы точно ничего не сломали произведенной доработкой.

Подробнее..

Вебинар DataLine Безопасное хранение корпоративных документов и совместная онлайн-работа 14 апреля

02.04.2021 12:23:26 | Автор: admin

Разберем доступные на рынке решения для организации хранения документов и расскажем о возможностях сервисов на базе open-source решения Nextcloud. Вебинар будет интересен тем, кто ищет безопасное для компании и удобное для сотрудников решение для хранения корпоративных файлов и совместной работы над документами.

В программе:

  • Удобно, но небезопасно, и наоборот: сетевой диск, публичные облачные хранилища и диски.

  • Open-source решение Nextcloud.

  • Разворачиваем Nextcloud самостоятельно.

  • Сервис DataLine на базе Nextcloud: возможности, которые сложно получить в варианте on-premise.

  • Не просто хранилище: платформа для совместной работы на базе Nextcloud.

  • Кейсы и демонстрация основных модулей решения Nextcloud.

Начало вебинара в 11.00. Продолжительность 1 час. Участие бесплатное, но нужно зарегистрироваться.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru