Данные

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

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

Что происходит

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

В Android есть внутреннее Internal Storage (IS) и внешнее хранилище External Storage (ES). Исторически это были встроенная память в телефоне и внешняя SD-карта, поэтому ES был больше, но медленнее и дешевле. Отсюда и разделение настройки и критически важное записывали в IS, а в ES хранили данные и большие файлы, например, медиа. Потом ES тоже стал встраиваться в телефон, но разделение, по крайней мере логическое, осталось.

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

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

В Android решили всё это переделать ещё в 10-й версии, а в 11-й это стало обязательным.

Чтобы минимизировать риски для пользователя в Google решили внедрить Scoped Storage (SS) в ES. Возможность проникнуть в папки других приложений убрали, а доступ есть только к своим данным теперь это сугубо личная папка. А IS с 10-й версии ещё и зашифрована по умолчанию.

В Android 11 Google зафорсировала использование SS когда таргет-версия SDK повышается до 30-й версии API, то нужно использовать SS, иначе будут ошибки, связанные с доступом к файлам. Фишка Android в том, что можно заявить совместимость с определённой версией ОС. Те, кто не переходили на 11, просто говорили, что пока не совместимы с этой версий, но теперь нужно начать поддерживать нововведения всем. С осени не получится заливать апдейты, если не поддерживаешь Android 11, а с августа нельзя будет заливать новые приложения.

Если SS не поддерживается (обычно это для девайсов ниже 10-й версии), то для доступа к данным других приложений требуется получить доступ к чтению и записи в память. Иначе придётся получать доступ к файлам через Media Content, Storage Access Framework или новый, появившийся в 11-м Android, фреймворк Datasets в зависимости от типа данных. Здесь тоже придётся получать разрешение доступа к файлу, но по более интересной схеме. Когда расшариваемый файл создаёшь сам, то доступ к нему не нужен. Но если переустановить приложение доступ к нему опять потребуется. К каждому файлу система привязывает приложение, поэтому когда запрашиваешь доступ, его может не оказаться. Особо беспокоиться не нужно, это сложно отследить, поэтому лучше просто сразу запрашивать пермишен.

Media Content, SAF и Datasets относятся к Shared Storage (ShS). При удалении приложения расшаренные данные не удаляются. Это полезно, если не хочется потерять нужный контент.

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

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

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

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

Перейдём к практике.

Переход на новую версию

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

Для этого выделили в общий интерфейс работу с файлами, реализация которого зависела от версии API.

interface FilesManipulator {    fun createVideoFile(fileName: String, copy: Copier): Uri    fun createImageFile(fileName: String, copy: Copier): Uri    fun createFile(fileName: String, copy: Copier): Uri    fun getPath(uri: Uri): String    fun deleteFile(uri: Uri)}

FilesManipulator представляет собой интерфейс, который знает, как работать с файлами и предоставляет разработчику API для записи информации в файл. Copier это интерфейс, который разработчик должен реализовать, и в который передаётся поток вывода. Грубо говоря, мы не заботимся о том, как создаются файлы, мы работаем только с потоком вывода. Под капотом до 10-й версии Android в FilesManipulator происходит работа с File API, после 10-й (и включая её) MediaStore API.

Рассмотрим на примере сохранения картинки.

fun getContentValuesForImageCreating(fileName: String): ContentValues {    return ContentValues().apply {        put(MediaStore.Images.Media.DISPLAY_NAME, fileName)        put(MediaStore.Images.Media.IS_PENDING, FILE_WRITING_IN_PENDING)        put(MediaStore.Images.Media.RELATIVE_PATH, Environment.DIRECTORY_PICTURES + File.separator + appFolderName)    }}fun createImageFile(fileName: String, copy: Copier): Uri {    val contentUri = MediaStore.Images.Media.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)    val contentValues = getContentValuesForImageCreating(fileName)    val uri = contentResolver.insert(contentUri, contentValues)         ?: throw IllegalStateException("New image file insert error")    downloadContent(uri, copy)    return uri}fun downloadContent(uri: Uri, copy: Copier) {    try {        contentResolver.openFileDescriptor(uri, FILE_WRITE_MODE)                .use { pfd ->                    if (pfd == null) {                        throw IllegalStateException("Got nullable file descriptor")                    }                    copy.copyTo(FileOutputStream(pfd.fileDescriptor))                }        contentResolver.update(uri, getWriteDoneContentValues(), null, null)    } catch (e: Throwable) {        deleteFile(uri)        throw e    }}fun getWriteDoneContentValues(): ContentValues {    return ContentValues().apply {        put(MediaStore.Images.Media.IS_PENDING, FILE_WRITING_DONE)    }}

Так как операция сохранения медиафайлов достаточно длительная, то целесообразно использовать MediaStore.Images.Media.IS_PENDING, которая при установлении значения 0 не дает видеть файл приложениям, отличного от текущего.

По сути, вся работа с файлами реализована через эти классы. Шаринг в другие приложения автоматически сохраняют медиа в память устройства и последующая работа с URI уже происходит по новому пути. Но есть такие SDK, которые ещё не успели перестроиться под новые реалии и до сих пор используют File API для проверки медиа. В этом случае используем кеш из External Storage и при необходимости провайдим доступ к файлу через FileProvider API.

Помимо ограничений с памятью в приложениях, таргетированных на 30-ю версию API, появилось ограничение на видимость приложения. Так как iFunny использует шаринг во множество приложений, то данная функциональность была сломана полностью. К счастью, достаточно добавить в манифест query, открывающую область видимости к приложению, и можно будет также полноценно использовать SDK.

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

<manifest  ><queries><intent>    <action android:name="android.intent.action.SENDTO" />    <data android:scheme="smsto, mailto" /></intent>    <package android:name="com.twitter.android" />    <package android:name="com.snapchat.android" />    <package android:name="com.whatsapp" />    <package android:name="com.facebook.katana" />    <package android:name="com.instagram.android" />    <package android:name="com.facebook.orca" />    <package android:name="com.discord" />    <package android:name="com.linkedin.android" /></queries></manifest>

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

Первоначально в LogCat обнаружил, что приложение не может приконнектиться к процессу Orchestrator и выдает ошибку java.lang.RuntimeException: Cannot connect to androidx.test.orchestrator.OrchestratorService.

Эта проблема из разряда видимости других приложений, поэтому достаточно было добавить строку <package android:name="androidx.test.orchestrator" /> .

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

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

Так как нам нужно использовать этот пермишен только для тестов, то нам условия подходят. Поэтому я быстренько написал свой ShellCommandExecutor, который выполняет команду adb shell appops set --uid PACKAGE_NAME MANAGE_EXTERNAL_STORAGE allow на создании раннера тестов.

На Android 11 тесты удачно запустились и стали проходить без ошибок.

После попытки запуска на 10-й версии Android обнаружил, что отчет Allure также перестал сохраняться в память девайса. Посмотрев issue Allure, обнаружил, что проблема известная, как и с 11-й версией. Достаточно выполнить команду adb shell appops set --uid PACKAGE_NAME LEGACY_STORAGE allow. Сказано, сделано.

Запустил тесты всё еще не происходит сохранения в память отчёта. Тогда я обнаружил, что в манифесте WRITE_EXTERNAL_STORAGE ограничен верхней планкой до 28 версии API, то есть запрашивая работу памятью мы не предоставили все разрешения. После изменения верхней планки (конечно, для варианта debug) и запроса пермишена на запись тесты удачно запустились и отчёт Allure сохранился в память устройства.

Добавлены следующие определения пермишенов для debug-сборки.

<uses-permission android:name="android.permission.MANAGE_EXTERNAL_STORAGE" /><uses-permission    android:name="android.permission.WRITE_EXTERNAL_STORAGE"    android:maxSdkVersion="29"    tools:node="replace" />

После всех вышеописанных манипуляций с приложением, можно спокойно устанавливать targetSdkVersion 30, загружать в Google Play и не беспокоиться про дедлайн, после которого загружать приложения версией ниже станет невозможно.

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

Как выбирали систему построения отчетности

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

• Бесплатное использование ПО в коммерческих проектах с открытым исходным кодом

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

• Использование языка Java для построения отчетов

• ПО должно быть поддерживаемым и обновляемым c поддержкой обратной совместимости

• Редактор построения отчетов должен быть удобным и понятным

• Инструмент должен позволять создавать шаблоны отчетов всех основных форматов: excel, csv, pdf, html, и т.д

• Богатые возможности визуализации и построения дашбордов.

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

Как видно из нашего небольшого исследования, наиболее подходящим инструментом для нас стал JasperReports. В пользу этого open-source инструмента говорит наличие весьма удобного визуального редактора проектирования отчетов, богатого набора визуализаций, включая кросстаблицы, а самое главное - наличие REST API. Проектирование макетов отчетов в JasperReports не требует особых глубоких знаний, а результаты проекта сохраняются в xml-формат. Так же мы ориентируемся на опыт коллег, например, наши партнеры КРОК в своей статьеhttp://personeltest.ru/aways/habr.com/ru/company/croc/blog/244085/рекомендуют использовать Jasper. JasperSoft наибольшим образом подходит для построения фиксированной отчетности. Интересны любой компании, которой необходимы инструменты анализа данных. Конечно, у jasper есть определенные проблемы, когда требуется сделать гибкий шаблон, например, когда необходимо сделать гибкий вывод полей в таблице, но в нашей практике мы сталкиваемся как правило с фиксированными отчетами, которые обозначает заказчик.

Взаимодействие клиент-сервер с Jasper reports

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

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

Для того, чтобы получить отчет необходима авторизация в Jasper Server. Авторизация происходит путем передачи пары логин/пароль, а в ответ Jasper создает сессию и сохраняет session_id в куках. В обычном случае для того, чтобы напрямую взаимодействовать с JasperServer из JavaScript, нам необходимо авторизоваться, получить session_id из куки и запросить сам отчет. Однако на практике мы столкнулись с проблемой, что в случае использования кластера серверов с дублированием Jasper на всех инстансах, jasper отчеты то доступны, то недоступны для пользователя. Проблема заключается в том, что балансировщик, получив запрос от клиента, запрашивает ответ с разных JasperServer, но использует session_id только одного инстанса . То есть мы авторизовались в JasperServer на первом инстансе, получили от него session_id, затем c этим же session_id мы идем на другой инстанс и получаем ошибку доступа с сообщением Авторизуйтесь на JasperServer. Для решения этой задачи мы используем специальный проксировщик, который по сути является расширением бэкэнда платформы и устанавливается на все ноды кластера.Так как проксировщик установлен на том же сервере, что и Jasper server, ему нет необходимости обращаться по IP к ноде, а достаточно обратиться по localhost. Таким образом, балансировщик, передавая запрос от клиента на ту или иную ноду, запрашивает у проксировщика авторизацию уже на месте и гарантировано Jasper Server вернет ответ. Ниже представлен код проксировщика.

public Response getJasperReport(@QueryParam("url") String url) throws UnsupportedEncodingException {    url = url.replaceAll(";;", "&").replaceAll(" ","%20").replaceAll("\"","%22");     Client client = ClientBuilder.newClient();    Response authResponse = client            .target(jasperUrlLogin)            .queryParam("j_username", jasperLogin)            .queryParam("j_password", jasperPassword)            .request()            .header("Content-Type", "application/x-www-form-urlencoded")            .header("charset", "utf-8")            .post(Entity.json(""));    NewCookie sessionIdCookie = null;    if (authResponse.getStatus() == 200) {        Map<String, NewCookie> cookies = authResponse.getCookies();        sessionIdCookie = cookies.get("JSESSIONID");    } else {        LOGGER.warn("Cant auth JasperServer");        return null;    }     String requestUrl = jasperReportUrl + url;     Response response = client            .target(requestUrl)            .request()            .cookie(sessionIdCookie)            .header("Content-Type", "text/html")            .get();    return response;}

Проксировщик получает на вход некий URL отчета, который собирается из параметров на клиенте. По этому URL происходит авторизация в jasperServer, далее проксировщик достает из куки session_id и уже по нему запрашивает ответ непосредственно самого отчета. Ответ от jasper приходит виде html-страницы. Именно эту html-страницу мы передаем в iframe для отрисовки на клиенте, а не url, как это обычно бывает. Таким образом мы один раз запрашиваем отчет, далее вся работа с ним идет уже непосредственно на клиенте платформы.

Создаем Iframe

{    xtype: 'component',    margin: '20 0 0 0',    reference: 'report',    maxWidth: 1200,    height:485,    autoEl: {        tag: 'iframe',        src: '',        frameBorder: 0,        marginWidth: 0,    },    listeners: {        load: {            element: 'el',            fn: function () {                var panel = this.getParent().component;                panel.setLoading(false, panel.body);            }        }    }}

Подкладываем html страницу от Jasper Server

generateReport: function () {        var report_url = this.generateReportUrl('html');        if (report_url) {            var panel = this.view;            panel.setLoading(true, panel.body);            this.getHtmlAndUpdateReport(report_url);        }    }

generateReportUrl - метод, который генерирует URL с нужными параметрами для отчета и session_id.

Cоздание отчета в JasperReports

Далее поговорим про непосредственно создание отчетов и дашбордов в Jasper. Создание jasper отчета состоит из набора визуализаций, скомпонованных на едином макете:Для создания макета отчета мы используем визуальный редактор JasperSoft Studio, который может быть отдельным приложением или плагином для eclipse. Подробнее об этом инструменте можно легко найти информацию в документации и открытых источниках, Нам же важно выделить то, что в данном редакторе достаточно легко можно построить дашборд, а сам редактор достаточно удобен и понятен. Достаточно выбрать нужные визуализации, перетащить их на макет, заполнить параметры и функциональные элементы. Построение дашбордов не требует навыков программирования и каждый может разобраться с ними в достаточно короткое время. Ниже пример простого отчета в JasperStudio.

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

Начало структуры файла: пример параметров отчета

<?xml version="1.0" encoding="UTF-8"?><!-- Created with Jaspersoft Studio version 6.9.0.final using JasperReports Library version 6.9.0-cb8f9004be492ccc537180b49c026951f4220bf3  --><jasperReport xmlns:xsi="http://personeltest.ru/away/www.w3.org/2001/XMLSchema-instance" xmlns="http://personeltest.ru/away/jasperreports.sourceforge.net/jasperreports" xsi:schemaLocation="http://personeltest.ru/away/jasperreports.sourceforge.net/jasperreports http://jasperreports.sourceforge.net/xsd/jasperreport.xsd" name="pubsub_diagram" pageWidth="1150" pageHeight="550" columnWidth="555" leftMargin="20" rightMargin="20" topMargin="20" bottomMargin="20" uuid="e8ef4a20-ab26-44c0-8b4d-316411f7d350">    <property name="com.jaspersoft.studio.data.defaultdataadapter" value="postgres_local.xml"/>    <property name="net.sf.jasperreports.export.xls.ignore.graphics" value="false"/>    <parameter name="date_from_param" class="java.lang.String"/>    <parameter name="date_to_param" class="java.lang.String"/>    <parameter name="systems_param" class="java.util.Collection"/>    <parameter name="status_param" class="java.util.Collection"/>    <parameter name="entities_param" class="java.util.Collection"/>    <parameter name="count_details_param" class="java.lang.Integer"/>    <parameter name="group_param" class="java.lang.String"/>

Далее предположим, что источником данных является во второй части после параметров пишем SQL-запрос

 <queryString>        <![CDATA[SELECT * FROM (Cnjbn with main_table AS(SELECT T3.status as status, count(T3.id) as count_status, (count(T3.id) / (to_date($P{date_to_param}, 'DD_MM_YYYY') - to_date($P{date_from_param}, 'DD_MM_YYYY') + 1)) as avg_count_status  FROM(SELECT T1.id,T2.status    FROM public.history     AS T1LEFT JOIN(SELECT DISTINCT ON (history_id) history_id, status FROM public.trackWHERE createdate >= to_date($P{date_from_param}, 'DD_MM_YYYY')    AND DATE(createdate) <= to_date($P{date_to_param}, 'DD_MM_YYYY')ORDER BY history_id, createdate DESC NULLS LAST) AS T2ON T1.id = T2.history_idWHERE T2.status IS NOT NULLAND $X{IN,T1.unidatasourcesystem, systems_param} AND $X{IN,T1.entity, entities_param}AND T1.createdate >= to_date($P{date_from_param}, 'DD_MM_YYYY')AND DATE(T1.createdate) <= to_date($P{date_to_param}, 'DD_MM_YYYY')AND $X{IN,T2.status, status_param}) AS T3GROUP BY T3.status)SELECT main_table.*, round((count_status * 100) / (SELECT SUM(count_status) FROM main_table), 2) AS percent_status FROM main_table) AS t_result order by status]]>    </queryString>

Стоит обратить внимание, что в запросе мы используем параметры $P{date_to_param}, которые динамически приходят от клиента, что так же является фишкой Jasper.

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

<columnHeader>    <band height="35">        <staticText>            <reportElement x="0" y="0" width="150" height="30" uuid="1972f653-13ec-41b8-987a-a1f25940e053"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12" isBold="true"/>            </textElement>            <text><![CDATA[Статус]]></text>        </staticText>        <staticText>            <reportElement x="150" y="0" width="150" height="30" uuid="bde4e86c-d3d8-4538-a278-44eae4cda528"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12" isBold="true"/>            </textElement>            <text><![CDATA[Количество сообщений]]></text>        </staticText>        <staticText>            <reportElement x="300" y="0" width="160" height="30" uuid="ab26081d-2c0b-45b3-8c43-5707e2b555e7"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12" isBold="true"/>            </textElement>            <text><![CDATA[Среднее в день]]></text>        </staticText>    </band></columnHeader><detail>    <band height="35" splitType="Stretch">        <textField>            <reportElement x="0" y="0" width="150" height="30" uuid="ea66974c-f627-4096-86c3-fc0f921a88d2"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12"/>            </textElement>            <textFieldExpression><![CDATA[$F{status}]]></textFieldExpression>        </textField>        <textField>            <reportElement x="150" y="0" width="150" height="30" uuid="a820021d-95d6-4ee5-a5a4-887aca484efb"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12"/>            </textElement>            <textFieldExpression><![CDATA[$F{count_status}]]></textFieldExpression>        </textField>        <textField>            <reportElement x="300" y="0" width="160" height="30" uuid="e7927fa9-5b8f-43ff-bea7-1d74d8a3ce27"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12"/>            </textElement>            <textFieldExpression><![CDATA[$F{avg_count_status}]]></textFieldExpression>        </textField>    </band></detail><summary>    <band height="370">        <staticText>            <reportElement x="0" y="0" width="150" height="30" uuid="d93b83c8-b168-4766-91d8-b9545e3239a7"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12" isBold="true"/>            </textElement>            <text><![CDATA[ИТОГО]]></text>        </staticText>        <textField>            <reportElement x="150" y="0" width="150" height="30" uuid="6e306a81-3522-437d-a973-0dcf8646aa5f"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12"/>            </textElement>            <textFieldExpression><![CDATA[$V{sum_status}]]></textFieldExpression>        </textField>        <textField>            <reportElement x="300" y="0" width="160" height="30" uuid="67d24b52-4d3e-47ae-a35d-dc98a9b230f5"/>            <textElement textAlignment="Center" verticalAlignment="Middle">                <font fontName="Arial" size="12"/>            </textElement>            <textFieldExpression><![CDATA[$V{sum_avg_count_status}]]></textFieldExpression>        </textField>        <pieChart>            <chart evaluationTime="Report">                <reportElement x="0" y="40" width="400" height="320" uuid="bf9f29b3-51c1-472d-822b-e7e4b20fa160"/>                <chartTitle/>                <chartSubtitle/>                <chartLegend/>            </chart>            <pieDataset>                <keyExpression><![CDATA[$F{status}]]></keyExpression>                <valueExpression><![CDATA[$F{count_status}]]></valueExpression>                <labelExpression><![CDATA["" + $F{percent_status} + "% " + $F{status}]]></labelExpression>            </pieDataset>            <piePlot>                <plot>                    <seriesColor seriesOrder="0" color="#33F54A"/>                    <seriesColor seriesOrder="1" color="#EB73C1"/>                    <seriesColor seriesOrder="2" color="#433DF2"/>                    <seriesColor seriesOrder="3" color="#FAEC52"/>                    <seriesColor seriesOrder="4" color="#FFC342"/>                    <seriesColor seriesOrder="5" color="#D9D2D8"/>                    <seriesColor seriesOrder="6" color="#DE522F"/>                </plot>                <itemLabel/>            </piePlot>        </pieChart>    </band></summary>

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

<subreport>    <reportElement x="460" y="40" width="650" height="320" uuid="e0d58e35-b1da-4bcc-9978-fbda3028ff5a"/>    <subreportParameter name="date_from_param">        <subreportParameterExpression><![CDATA[$P{date_from_param}]]></subreportParameterExpression>    </subreportParameter>    <subreportParameter name="date_to_param">        <subreportParameterExpression><![CDATA[$P{date_to_param}]]></subreportParameterExpression>    </subreportParameter>    <subreportParameter name="systems_param">        <subreportParameterExpression><![CDATA[$P{systems_param}]]></subreportParameterExpression>    </subreportParameter>    <subreportParameter name="status_param">        <subreportParameterExpression><![CDATA[$P{status_param}]]></subreportParameterExpression>    </subreportParameter>    <subreportParameter name="entities_param">        <subreportParameterExpression><![CDATA[$P{entities_param}]]></subreportParameterExpression>    </subreportParameter>    <subreportParameter name="group_param">        <subreportParameterExpression><![CDATA[$P{group_param}]]></subreportParameterExpression>    </subreportParameter>    <connectionExpression><![CDATA[$P{REPORT_CONNECTION}]]></connectionExpression>    <subreportExpression><![CDATA["repo:pubsub_grapf.jrxml"]]></subreportExpression></subreport>

Ключевым вопросом в построении отчета является передача параметров (фильтров) отчета от клиента на сервер. Для того, чтобы не отправлять пользователя на JasperServer и все параметры отчета заполнять в платформе удобным способом, Jasper предлагает использовать собственный REST API. Наличие такого мощного API было решающим аргументом в сторону выбора JasperSoftдля автоматизации отчетности. Вместо того, чтобы создавать ресурсы и заполнять параметры в среде Jasper Server мы просто воспользуемся методами, которое предоставляет нам API и передадим параметры GET-запросом от клиента. API jasper позволяет не только параметризировать данные, используемые в отчетах, но и сами отчеты, что позволяет очень гибко отображать нужные дашборды

Итого

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

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

1. Когда считать, что набор опоздал?

2. Какие данные часто опаздывают?

3. По какой причине набор опоздал?

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

Данные запаздывают

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

Для своевременной поставки данных Airbnb мы стремимся к тому, чтобы владельцы каждого промежуточного шага фиксировали соглашения об уровне обслуживания (SLA) по доступности данных к конкретному времени. Например, владелец набора обещает, что метрика "бронирование" будет содержать самые актуальные данные к 5 утра по UTC, и если набор к этому времени недоступен, то он опоздал.

Как часто наборы опаздывают?

Сначала мы решили, что, опираясь на представление отчёта, Report поставщики данных должны понимать, когда данные выгружены и как часто они соответствуют SLA (рис. 1).

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

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

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

Отчётность только вершина айсберга

Хотя Report сильно упрощает понимание того, действительно ли набор опаздывает, это представление не решило главные проблемы SLA:

• Каково разумное SLA набора?

• Как понять причину опоздания?

Это проблемные вопросы, потому что наборы зависят друг от друга и возникают последовательно: сначала одно преобразование, затем другое (рис. 2).

Таким образом, наличие одного набора неразрывно связано с иерархически сложным "происхождением" других наборов. Чтобы установить реалистичное SLA, нужно учитывать дерево зависимостей, которое иногда состоит из 100 сущностей, а также их SLA.

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

Почему набор опоздал?

Ранний дизайн

Чтобы поставщики данных видели зависимости набора и временные рамках этих зависимостей, разработано представление о происхождении набора Lineage.

Информация о происхождении данных это от 10 до 100 таблиц, а каждая таблица это 30 дней исторических данных, а также SLA и связей между ними, поэтому мы нуждались в краткой форме представления, а это от 1,000 до 10,000 отдельных точек данных.

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

Фокус на времени с помощью представления Timeline

Затем мы сместили акцент на последовательности во времени. Чтобы представлять последовательности, мы создали диаграмму Ганта, включающую зависимости (рис. 4) с такой функциональностью:

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

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

• Если набор имеет SLA, время обозначается вертикальной линией.

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

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

• Выделенные дуги представляют важнейшие узкие места.

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

Ищем иголку в стоге сена "узкие" места

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

Погружение в историческое представление (Historical)

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

Процесс и оснастка

Почти год мы потратили на разработку концепции, проектирование, создание прототипов и внедрения SLA Tracker в производственную среду. Большая часть этого времени потрачена на разработку API данных в UI и на итерации Lineage.

Чтобы упростить Report, мы использовали статические конструкции и прототипы экранов с хот-спотами (инструмент Clickthrough Prototypes) и универсальные поддельные данные. В альфа- и бета-релизах мы выполняли итерации визуального языка, то есть визуализировали данные так, чтобы их было проще охватить и понять (рис. 8).

Совершенно иначе мы подошли к проектированию Lineage. Его информационная иерархия продиктована формой данных. Таким образом, критично прототипирование на выборках реальных данных. Мы разработали эти прототипы на TypeScript, используя низкоуровневый набор компонентов визуализации visx для React, этот набор позволяет повторно использовать код при внедрении в производственную среду (рис. 9).

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

Заключение

В этом проекте мы применили визуализацию данных и UI/UX-дизайн междисциплинарную область, которую называем "Data Experience", в отношении важных проблем своевременности данных, требующих глубокого понимания сложной временной и иерархической информации. Это позволило сделать анализ своевременности данных доступным даже в сложной экосистеме данных крупной компании. Для разработки сложных инструментов визуального анализа требуются время и итерации, но результат работы может принести большую пользу.
Если хотите научиться работать с данными не хуже специалистов из Airbnb то приходите учиться. Будет сложно, но интересно!

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Представляем вам версию 0.2 библиотеки глубокого обучения KotlinDL.

KotlinDL 0.2 теперь доступен на Maven Central (до этого он лежал на bintray, но закатилось солнышко земли опенсорсной). Появилось столько всего нового: новые слои, специальный DSL для препроцессинга изображений, новые типы датасетов, зоопарк моделей с несколькими моделями из семейства ResNet, MobileNet и старой доброй моделью VGG (рабочая лошадка, впрочем).

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

Functional API

Прошлая версия библиотеки позволяла описывать нейронные сети лишь при помощи Sequential API. Например, используя метод Sequential.of(..), вы могли легко описать модель как последовательность слоев и построить VGG-подобную модель.

Однако с 2014 года (эпохи взлета и расцвета подобных архитектур) много воды утекло, и было создано множество новых нейросетей. В частности, стандартным подходом стало использование так называемых остаточных нейросетей (Residual Neural Networks или ResNet), которые решают проблемы исчезающих градиентов (vanishing gradients) и, напротив, взрывающихся градиентов (exploding gradients) а значит, и проблемы деградации обучения нейросети. Подобные архитектуры невозможно описать в виде Sequential API их корректнее представлять в виде направленного ациклического графа (Directed Acyclic Graph). Для задания таких графов мы добавили в версии 0.2 новый Functional API, который позволяет нам описывать модели, подобные ResNet или MobileNet.

Ну что же, давайте построим некое подобие ResNet. Нейросеть будет обучаться на датасете FashionMnist (небольшие изображения модных вещей). Черно-белые изображения размером 28х28 отлично подойдут на старте работы с нейросетями.

val (train, test) = fashionMnist()val inputs = Input(28, 28, 1)val conv1 = Conv2D(32)(inputs)val conv2 = Conv2D(64)(conv1)val maxPool = MaxPool2D(poolSize = intArrayOf(1, 3, 3, 1),strides = intArrayOf(1, 3, 3, 1))(conv2)val conv3 = Conv2D(64)(maxPool)val conv4 = Conv2D(64)(conv3)val add1 = Add()(conv4, maxPool)val conv5 = Conv2D(64)(add1)val conv6 = Conv2D(64)(conv5)val add2 = Add()(conv6, add1)val conv7 = Conv2D(64)(add2)val globalAvgPool2D = GlobalAvgPool2D()(conv7)val dense1 = Dense(256)(globalAvgPool2D)val outputs = Dense(10, activation = Activations.Linear)(dense1)val model = Functional.fromOutput(outputs)model.use {it.compile(optimizer = Adam(),loss = Losses.SOFT_MAX_CROSS_ENTROPY_WITH_LOGITS,metric = Metrics.ACCURACY)it.summary()it.fit(dataset = train, epochs = 3, batchSize = 1000)val accuracy = it.evaluate(dataset = test, batchSize = 1000).metrics[Metrics.ACCURACY]println("Accuracy after: $accuracy")}

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

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

Если вы знакомы с фреймворком Keras, то без особого труда сможете перенести модели, описанные при помощи Functional API, в Keras, используя KotlinDL.

Коллекция предварительно тренированных моделей ResNet и MobileNet

Начиная с релиза 0.2, в Kotlin DL появляется зоопарк моделей (или Model Zoo). По сути, это коллекция моделей с весами, полученными в ходе обучения на большом датасете изображений (ImageNet).

Зачем нужна такая коллекция моделей? Дело в том, что современные сверхточные нейросети могут иметь сотни слоев и миллионы параметров, обновляемых многократно в течении каждой итерации обучения. Тренировка моделей до приемлемого уровня точности (7080%) на таком большом датасете, как ImageNet, может занимать сотни и тысячи часов вычислительного времени большого кластера из видеокарт.

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

Доступны следующие модели:

• VGG16

• VGG19

• ResNet50

• ResNet101

• ResNet152

• ResNet50v2

• ResNet101v2

• ResNet152v2

• MobileNet

• MobileNetv2

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

Ниже вы видите пример загрузки одной из таких моделей (ResNet50):

// specify the model type to be loaded, ResNet50, for exampleval loader =ModelZoo(commonModelDirectory = File("cache/pretrainedModels"), modelType = ModelType.ResNet_50)// obtain the model configurationval model = loader.loadModel() as Functional// load class labels (from ImageNet dataset in ResNet50 case)val imageNetClassLabels = loader.loadClassLabels()// load weights if required (for Transfer Learning purposes)val hdfFile = loader.loadWeights()

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

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

Если вам не нужны предобученные веса, но вы не хотите описывать многослойные модели а-ля VGG или ResNet с нуля, у вас есть два пути: а) просто загрузить конфигурацию модели либо б) взять за основу полный код конструирования модели, написанный на Kotlin, он доступен для каждой из моделей через вызов функции высшего порядка, лежащей в пакете org.jetbrains.kotlinx.dl.api.core.model.

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

val model = resnet50Light(imageSize = 28,numberOfClasses = 10,numberOfChannels = 1,lastLayerActivation = Activations.Linear)

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

DSL для предобработки изображений

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

Большинство библиотек для предобработки изображений, найденные на просторах Github и имеющие разную степень заброшенности, так или иначе используют класс BufferedImage, оборачивая его более понятным и согласованным API. Мы решили упростить жизнь Kotlin-разработчиков, предложив им простой DSL, построенный на лямбда-выражениях и объектах-приемниках.

На данный момент доступны следующие функции преобразования изображений:

• Load

• Crop

• Resize

• Rotate

• Rescale

• Sharpen

• Save

val preprocessing: Preprocessing = preprocess {   transformImage {       load {           pathToData = imageDirectory           imageShape = ImageShape(224, 224, 3)           colorMode = ColorOrder.BGR       }       rotate {           degrees = 30f       }       crop {           left = 12           right = 12           top = 12           bottom = 12       }       resize {           outputWidth = 400           outputHeight = 400           interpolation = InterpolationType.NEAREST       }   }   transformTensor {       rescale {           scalingCoefficient = 255f       }   }}

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

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

Новые слои

В релизе 0.2 появилось много новых слоев. В основном, это обусловлено тем, что они используются в архитектурах ResNet и MobileNet:

• BatchNorm

• ActivationLayer

• DepthwiseConv2D

• SeparableConv2D

• Merge (Add, Subtract, Multiply, Average, Concatenate, Maximum, Minimum)

• GlobalAvgPool2D

• Cropping2D

• Reshape

• ZeroPadding2D*

* Спасибо Anton Kosyakov за имплементацию нетривиального ZeroPadding2D!

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

Dataset API и парочка наследников: OnHeapDataset & OnFlyDataset

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

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

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

Набор встроенных датасетов

Если вы только начинаете путешествие в удивительный мир глубокого обучения, мы настоятельно рекомендуем вам строить и запускать ваши первые нейросети на широко известных датасетах, таких как MNIST (набор рукописных цифр), FashionMNIST(набор изображений модных вещей от компании Zalando), Cifar10 (подмножество ImageNet, насчитывающее 50 000 изображений) или коллекцию изображений кошек и собак со знаменитого соревнования Kaggle (по 25 000 изображений каждого класса различных размеров).

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

Как добавить KotlinDL в проект

Чтобы начать использовать KotlinDL в вашем проекте, просто добавьте дополнительную зависимость в файл build.gradle:

repositories {    mavenCentral()}dependencies {    implementation 'org.jetbrains.kotlinx:kotlin-deeplearning-api:0.2.0'}

KotlinDL можно использовать в Java-проектах, даже если у вас нет ни капли Kotlin-кода. Здесь вы найдете пример построения и тренировки сверточной сети, полностью написанный на Java.

Если вы думаете, что в вашем проекте будет полезен Java API, напишите нам об этом или создайте PR.

Полезные ссылки

Мы надеемся, что вам понравилась наша статья и новые возможности KotlinDL.

Хотите узнать больше о проекте? Предлагаем ознакомиться с Readme или со страничкой проекта на GitHub. А этот туториал поможет вам создать вашу первую нейросеть на Kotlin.

Если вам интересно, как устроен KotlinDL, как он появился и в каком направлении развивается, почему он так похож на Keras, и планируется ли поддержка PyTorch, посмотрите свежее видео от Алексея Зиновьева.

Также мы ждем вас в Slack-канале #kotlindl (инвайт можно получить тут). В нем вы можете задавать вопросы, участвовать в дискуссиях и первыми получать информацию о превью-релизах и новых моделях в зоопарке моделей.

Ваша обратная связь, ваши описания багов и краш-репорты, идеи и комментарии все это очень важно для нас. Мы ждем новых пользователей и контрибьюторов, как начинающих, так и опытных исследователей всех, кому интересны Deep Learning и Data Science на Kotlin, Java и Scala!

Привет, Хабр! У кого из вас black belt на sql-ex.ru, признавайтесь? На заре своей карьеры я немало времени провел на этом сайте, практикуясь и оттачивая навыки. Должен отметить, что это было увлекательное и вознаграждающее путешествие. Пришло время воздать должное.

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

SQL is intergalactic data speak. SQL - это межгалактический язык данных

- Michael Stonebraker

Моя цель - показать походы и самые распространенные проблемы на понятных и доступных примерах. Конечно, СУБД, на которой решается задача имеет значение. Поддержка функций и синтаксиса варьируется. В SQL Fiddle я задействовал PostgreSQL, Oracle, SQL Server. Для решения серьезных аналитических задач сегодня я чаще всего использую специальные СУБД, такие как Redshift, Vertica, BigQuery, Clickhouse, Snowflake.

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

Конкатенация значений из нескольких строк в одну через разделитель

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

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

SQL Fiddle (PostgreSQL 9.6): http://sqlfiddle.com/#!17/f3ace/2/0

select lead_id ,string_agg(tag, ', ') as tagsfrom leadsgroup by lead_id;

Аналитические функции при сохранении всех строк выборки

Речь пойдет о так называемых analytic functions, которые оперируют над партициями данных (окна, windows), возвращая результат для каждой строки. В отличие от aggregate functions, схлопывающих строки, оконные функции оставляют все строки выборки.

Окно определяется спецификацией (выражение OVER) и основывается на трех основных концепциях:

• Разбиение строк на группы (выражение PARTITION BY)

• Порядок сортировки строк в каждой группе (выражение ORDER BY)

• Рамки, которые определяют ограничения по количеству строк относительно каждой строки (выражение ROWS)

Таких функций существует немало, от аналитических: всем известные SUM, AVG, COUNT, менее известные LAG, LEAD, CUMEDIST, и до ранжирующих: RANK, ROWNUMBER, NTILE. Я же приведу несколько простых примеров часто встречающихся запросов:

• Ко всем транзакциям пользователя вывести дату первой покупки

• К каждой транзакции добавить дату предыдущей транзакции пользователя

• Показать сумму покупок пользователя нарастающим итогом

• Присвоить всем транзакциям пользователя / продавца / отделения порядковый номер

SQL Fiddle: http://sqlfiddle.com/#!17/ee00f/13

select  salesid ,dateid ,sellerid ,buyerid ,qty ,first_value(dateid) over (partition by buyerid order by dateid) as first_purchase_dt ,lag(dateid) over (partition by buyerid order by dateid) as previous_purchase_dt ,sum(qty) over (partition by buyerid order by dateid rows between unbounded preceding and current row) as moving_qty ,row_number() over (partition by buyerid order by dateid) as order_numberfrom winsales;

Работа с NULL и применение логики ветвления IF-THEN-ELSE в SQL

Про COALESCE / NVL знают все, и нет смысла останавливаться на них подробно. Зато с NVL2 и NULLIF знакомы уже не так много людей.

NULLIF сравнивает два значения и возвращает NULL, если аргументы равны. По сути эта функция - обратна к NVL / COALESCE. Формулировка задачи:

• Как обработать ошибку деления на 0 (divide by zero error)

• Как выводить NULL вместо пустых строк ()

SQL Fiddle (PostgreSQL 9.6): http://sqlfiddle.com/#!17/bf56e/2

select lead_id ,nullif(tag, '') as tagfrom leads;

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

SQL Fiddle (Oracle 11g R2): http://sqlfiddle.com/#!4/4cac9/11

select "transaction_id" ,"ts" ,"invoice_id" ,nvl2("invoice_id", 1, 0) as "is_b2b"from transactions;

Но больше всего мне нравится функция DECODE. Она в буквальном смысле позволяет расшифровать значения согласно заданной вами логике:

DECODE ( expression, search, result [, search, result ] [ ,default ] ).

Формулировка задачи: Присвоить численному коду (или, например, битовой маске) текстовые наименования.

SQL Fiddle (Oracle 11g R2): http://sqlfiddle.com/#!4/60341/1

select "transaction_id" ,decode("status", 0, 'charge', 1, 'authorize', 2, 'settle', 'void') as "status"from transactions;

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

Дедупликация данных

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

Формулировка задачи: Выбрать самую актуальную запись с учетом статуса (успешная / отмененная транзакция) и временнОй метки

SQL Fiddle (Oracle 11g R2): http://sqlfiddle.com/#!4/ad305/1

with decoded as (   select   "transaction_id"   ,"is_successful"   ,"ts"   ,decode("is_successful", 'true', 0, 'false', 1, 2) as "order_is_successful"   from transactions),ordered as (   select   "transaction_id"   ,"is_successful"   ,"ts"   ,row_number() over(partition by "transaction_id" order by "order_is_successful" asc, "ts" desc) as rn   from decoded)select "transaction_id" ,"is_successful" ,"ts"from orderedwhere rn = 1;

Некоторые СУБД, например, Teradata позволяют сделать запрос короче при помощи выражения QUALIFY:

select *from students_db.exam_resultsqualify row_number() over (partition by subject order by marks desc) = 1;

Анализ временных рядов

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

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

• Получение текущей даты (+ время) - CURRENTDATE, CURRENTTIMESTAMP

• Разница между событием и текущим временем - DATEDIFF

• Подсчет времени истечения срока действия события - DATEADD

• Дата начала недели, в которой произошло событие - DATETRUNC

• Конвертация Unix Timestamp (epoch) в человекочитаемый формат

SQL Fiddle (MS SQL Server 2017): http://sqlfiddle.com/#!18/618cf/6

select ts ,_metadata_ts_epoch ,convert(date, getdate()) as current_dt ,current_timestamp as current_ts ,datediff(minute, ts, getdate()) as minutes_since_ts ,dateadd(hour, 36, ts) as ts_expiration_ts  ,dateadd(week, datediff(week, 0, ts), 0) as ts_week ,dateadd(S, (_metadata_ts_epoch / 1000), '1970-01-01') as _metadata_tsfrom transactions;

Анализ истории со Slowly Changing Dimensions (SCD)

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

Формулировка задачи: Какой статус был у клиентов на 3-й день месяца?

SQL Fiddle (PostgreSQL 9.6): http://sqlfiddle.com/#!17/743e9/6

select  client_id  ,statusfrom clientswhere '2021-02-03' >= valid_from and '2021-02-03' < coalesce(valid_to, '2100-01-01');

Формулировка задачи: Как в течение недели росло количество активных клиентов?

SQL Fiddle (PostgreSQL 9.6): http://sqlfiddle.com/#!17/743e9/11

select   c.dt  ,h.status  ,count(distinct h.client_id)from calendar c  left join clients h      on c.dt >= valid_from and c.dt < coalesce(valid_to, '2100-01-01')::datewhere trueand c.dt between '2021-02-01' and '2021-02-07'and h.status in ('active')group by   c.dt  ,h.statusorder by 1, 3 desc;

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

Использование выражения CASE в агрегирующих функциях

Агрегирующие функции могут принимать в качестве аргумента результат оценки выражения CASE. Таким образом можно к агрегируемым строкам применить псевдофильтр. Это напоминает мне использование формулы СУММЕСЛИ из старого доброго Excel, только для реляционных баз данных. Смотрите сами:

• Подсчитать все лиды и выручку

• Подсчитать количество лидов со статусом success

• Подсчитать выручку лидов с тегом python

SQL Fiddle (MS SQL Server 2017): http://sqlfiddle.com/#!18/dc01d5/4

select dt ,count(1) as leads_total ,sum(case status when 'success' then 1 else 0 end) as leads_success ,sum(case when tags like '%python%' then 1 else 0 end) as leads_python ,sum(amount) as amount_total ,sum(case status when 'success' then amount else 0 end) as amount_successfrom leadsgroup by dtorder by dt;

Парсинг колонки с разделением на отдельные атрибуты

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

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

SQL Fiddle (PostgreSQL 9.6): http://sqlfiddle.com/#!17/205e7b/6

select campaign ,split_part(campaign, '-', 1) as network ,split_part(campaign, '-', 2) as region ,split_part(campaign, '-', 3) as category  ,nullif(split_part(campaign, '-', 4), 'None') as temperature  ,split_part(campaign, '-', 5) as brand from campagins;

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

Формулировка задачи: Разбить строку UTMContent на отдельные атрибуты cid, gid, aid, kwd с соблюдением соответствия ключ-значение. Каждое значение предваряется наименованием ключа, все значения разделены вертикальной строкой (|).

SQL Fiddle (PostgreSQL 9.6): http://sqlfiddle.com/#!17/4f65e/4

select substring("UTMContent" from '%cid_#"%#"_gid%' FOR '#' ) AS cid ,substring("UTMContent" from '%gid_#"%#"_aid%' FOR '#' ) AS gid ,substring("UTMContent" from '%aid_#"%#"_dvc%' FOR '#' ) AS aid ,substring("UTMContent" from '%kwd_#"%#"_pos%' FOR '#' ) AS kwdfrom utm;

FULL JOIN для соединений без потери строк

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

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

Формулировка задачи: Подготовить витрину-трекер для сквозной аналитики лидов из CRM и трат из Рекламных Кабинетов (Яндекс.Директ, Google Adwords, Facebook).

SQL Fiddle (PostgreSQL 9.6): http://sqlfiddle.com/#!17/227eaf/1

select coalesce(c.hash_key, l.hash_key) as hash_key ,coalesce(c.dt, l.dt) as dt ,coalesce(c.campaign_id, l.campaign_id) as campaign_id -- costs ,coalesce(c.platform, null) as platform ,coalesce(c.clicks, 0) as clicks ,coalesce(c.costs, 0) as costs -- leads ,coalesce(l.leads, 0) as leads ,coalesce(l.amount, 0) as amount -- meta ,case     when c.dt is not null then c.platform     when l.dt is not null then 'crm'   end as meta_row_origin ,case     when c.hash_key = l.hash_key then 1     else 0   end as meta_is_row_matchfrom costs as c   full join leads as l on l.hash_key = c.hash_key;

Пример упрощен и умозрителен. Однако этой задаче я посвятил одну из своих предыдущих публикаций: Сквозная Аналитика на Azure SQL + dbt + Github Actions + Metabase и недавнее выступление на вебинаре: Путь Инженера Аналитики: Решение для Маркетинга. Тема заслуживает отдельного внимания.

Разбиение пользовательских событий на сессии

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

Для чего это можно использовать? Прежде всего, для того, чтобы перейти от анализа хитов (кликов) к полноценному анализу пользовательского взаимодействия и поведения. Во-вторых, улучшение UX и качества сервисов, проведение A/B тестирования. Наконец, поиск паттернов, определенных сегментов пользователей, в том числе fraud monitoring (защита от мошенничества и ботов).

Чуть подробнее про дефиницию сессии от Google Analytics: How a web session is defined in Universal Analytics. Резюмируя, сессия - это набор пользовательских действий в рамках заданного промежутка времени. Сессия завершается при следующих событиях:

• 30 минут бездействия

• Начало новых суток

• Смена источника трафика (возврат на сайт по клику на новый рекламный баннер)

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

SQL Fiddle (PostgreSQL 9.6): http://sqlfiddle.com/#!17/17271/3

Попробуем декомпозировать и решить задачу по частям:

• Шаг 1. Для каждого пользователя берем идентификатор просмотра, время просмотра, источник трафика (хеш-сумма). Хеш-сумма берется от текстовой конкатенации атрибутов источника трафика: utm_source + utm_medium + utm_campaign. При этом обрабатываются null-значения в любом из столбцов (заменяются на литерал 'null'). По хеш-сумме легко проверить смену источника трафика.

 select   user_id   ,hit_id   ,ts   ,md5(concat(coalesce(utm_source, 'null'), coalesce(utm_medium, 'null'), coalesce(utm_campaign, 'null'))) as utm_hash from hits_raw

• Шаг 2. Для каждого хита выводим предыдущий хит и соответствующее ему время. Окно - по пользователю, сортировка по времени хита:

select   user_id   ,hit_id   ,ts   ,lag(ts, 1) over (partition by user_id order by ts) as lag_ts   ,utm_hash   ,lag(utm_hash, 1) over (partition by user_id order by ts) as lag_utm_hash from hits

• Шаг 3. Рассчитываем, является ли каждый хит началом новой сессии. Это проверка на выполнение любого из трех указанных выше условий окончания сессии:

select   user_id   ,hit_id   ,ts   ,lag_ts   ,case     when utm_hash <> lag_utm_hash then 1     when date_part('day', ts - lag_ts) <> 0 then 1     when date_part('hour', ts - lag_ts) * 60 +             date_part('minute', ts - lag_ts) > 30 then 1     else 0    end as is_new_session --    ,date_part('day', ts - lag_ts) as days_diff--    ,date_part('hour', ts - lag_ts) * 60 +--              date_part('minute', ts - lag_ts) as minutes_diff   ,utm_hash   ,lag_utm_hash from lags

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

select   user_id   ,hit_id   ,ts   ,is_new_session   ,sum(is_new_session) over (partition by user_id order by ts rows between unbounded preceding and current row) as session_index   ,md5(concat(user_id, sum(is_new_session) over (partition by user_id order by ts rows between unbounded preceding and current row))) as session_id from new_sessions

В реальном мире всё сложнее

Помимо логики, выраженной в SQL, не меньшее значение имеет ряд других факторов:

• СУБД, с которой вы работаете: то, какие функции и возможности она поддерживает, формат хранения данных: в виде колонок или строк

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

• Используемые физические и логические модели данных: индексы, материализованные представления, кеш, предварительно отсортированные данные

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

Советую посетить ближайшие открытые вебинары:

• ML в Spark, 11 февраля в 20:00

• MPP-базы данных, 17 февраля в 20:00

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

Следить за моими публикациями в авторском канале: https://t.me/enthusiastech

Благодарю за внимание.

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

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

from random import normalvariatefrom math   import pi, cosGtoR, Uo, To, D, B = pi/180., 0.7, 56.0, 1.0, 0.02def U(T):     return Uo * cos(GtoR*(T + normalvariate(0.0, D) - To))**2 + B with open('pyexp.dat', 'w') as fp:  for T in range(0,360,10):     fp.write('{:5.1f}  {:5.3f}\n'.format(T, U(T)))

Здесь я буду использовать минимальный набор импортируемых в python модулей, необходимых для решения поставленных задач. Поэтому, в частности, мы не будем использовать пакеты а-ля csv или pandas для записи/чтения табличных данных. Также воздержимся от прямого импорта numpy (его импортирует и использует matplotlib). Получившийся в итоге минималистичный python-сценарий обработки данных выглядит так:

from math           import pi, cos, sin   # для вычисленийfrom scipy.optimize import curve_fit      # алгоритм подгонкиfrom scipy.special  import gammainc       # чтобы определить p-valuefrom matplotlib     import pyplot as plt  # для рисования графиковGtoR = pi/180. angle, experiment = [], [] with open('pyexp.dat','r') as fp:  data = fp.readlines()for row in data:  a, u = row.strip().split()  angle.append(GtoR*float(a))    experiment.append(float(u))  def U(X, Uo, To, B): # Теоретическая функция  Y = []  for x in X: Y.append(Uo * cos(x - To)**2 + B )  return Ydef V(X, Uo, To, D): # Её производная  Y = []  for x in X: Y.append(abs(D*(Uo * sin(2*(To - x)))))  return Y# Подгонка без учёта ошибок измеренийpopt, pcov = curve_fit(U, angle, experiment, p0 = [0.7, 1.0, 0.01], bounds=(0.0, [1., 180., 0.5]))# Переводим ошибки измерений углов (1 градус) в ошибки напряжений errors = V(angle, popt[0], popt[1], 1.0*GtoR)# Подгонка с учётом ошибокpopt, pcov = curve_fit(U, angle, experiment, p0 = popt, sigma=errors, absolute_sigma=True)# "Вытаскиваем" результаты подгонкиtheory = U(angle, *popt)Chi2, NDF = 0.0, len(angle)-len(popt)for p in range(len(angle)): Chi2 += ((theory[p]-experiment[p])/errors[p])**2pvalue = 1 - gammainc(0.5*NDF, 0.5*Chi2) # gammainc - regularized upper incomplete gamma functionTo, dTo = popt[1]/GtoR, pcov[1][1]**0.5/GtoRtlabel  = 'теория: ' tlabel += r'$\chi^2/NDF$ = {:.1f}/{:2d}'.format(Chi2,NDF)tlabel += '\nP-value = {:.2f}%'.format(100*pvalue)theta   = [GtoR*i for i in range(0,360)] # чтобы рисовать функцию без изломовplt.rc('grid', color='#316931', linewidth=0.5, linestyle='-.')fig = plt.figure(figsize=(8, 8))ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], projection='polar', facecolor='#fffff0')ax.set_title('Поворот оси поляроида: ' + r'$\theta_0={:.2f}^\circ\pm{:.2f}^\circ$'.format(To, dTo)+'\n')ax.plot(angle, experiment, 'ro', label='эксперимент')ax.plot(theta, U(theta, *popt), 'b-', label = tlabel)ax.legend()plt.show()

В результате выполнения программы matplotlib нарисует нам график результатов моделирования (или измерений) и теоретической функции в полярных координатах:

Заключение

Итак, для решения поставленной задачи мы использовали другой набор инструментов
ударную тройку python + scipy + matplotlib вместо gnuplot. И да, задача решена. Преимущества такого метода решения приведены во введении, кроме того, использование python расширяет границы дозволенного почти до бесконечности. Недостатки, по сравнению с gnuplot-решением, на мой взгляд, таковы:

1. Неподготовленному человеку понять смысл сценария труднее, чем это было в случае с пакетом gnuplot.

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

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

Линейный график является неотъемлемой частью анализа данных. Он даёт нам представление о том, как величина изменяется при последовательных измерениях. В случае работы с временными рядами важность линейных графиков становится решающей. Тренд [направление], сезонность и корреляция вот некоторые характеристики, которые можно наблюдать на аккуратно сгенерированных линейных графиках. В этой статье мы будем создавать интерактивные линейные графики с помощью двух библиотек Python Pandas и Altair.

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

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

Давайте начнём с генерации данных. Типичный пример использования линейных графиков это анализ цен на акции. Один из самых простых способов получения данных о ценах на акции предоставляет библиотека pandas-datareader. Сначала нам нужно импортировать её вместе с уже установленной в Google Colab Pandas.

import pandas as pdfrom pandas_datareader import data

Мы получим цены на акции трёх компаний за один год. Необходимо указать начальную дату, конечную дату и источник данных:

start = '2020-1-1'end = '2020-12-31'source = 'yahoo'

Необходимо знать ещё одну деталь название акции:

apple = data.DataReader("AAPL", start=start ,end=end, data_source=source).reset_index()[["Date", "Close"]]ibm = data.DataReader("IBM", start=start ,end=end, data_source=source).reset_index()[["Date", "Close"]]microsoft = data.DataReader("MSFT", start=start ,end=end, data_source=source).reset_index()[["Date", "Close"]]

Сейчас у нас есть цены на акции Apple, IBM и Microsoft в 2020 году. Лучше располагать их в одном фрейме данных. Перед объединением нам нужно добавить колонку, которая указывает, к какой акции относится та или иная цена. Следующий блок кода добавляет соответствующие столбцы, а затем объединяет фреймы данных с помощью функции concat:

apple["Stock"] = "apple"ibm["Stock"] = "ibm"microsoft["Stock"] = "msft"stocks["Month"] = stocks.Date.dt.monthstocks = pd.concat([apple, ibm, microsoft])

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

Altair

Altair это библиотека статистической визуализации на Python. Как мы увидим в примерах, её синтаксис чист и прост для понимания. Также с помощью Altair очень просто создавать интерактивные визуализации. Я кратко объясню структуру Altair, а затем сосредоточусь на создании интерактивных линейных графиков. Если вы новичок в Altair, вот туториал по Altair в виде серии из 4 частей:

Вот простой линейный график без какой-либо интерактивности:

alt.Chart(stocks).mark_line().encode(   x="Date",   y="Close",   color="Stock").properties(   height=300, width=500)

Основная структура начинается с объекта диаграммы верхнего уровня. Данные могут иметь формат фрейма данных Pandas, или можно написать строку с URL, указывающим на файл JSON или CSV. Затем указывается тип визуализации (mark_circle, mark_line и так далее).

Функция encode указывает Altair, что нужно построить в заданном фрейме данных. Таким образом, всё, что мы пишем в функции encode, должно быть связано с данными. Различать акции мы будем при помощи параметра color, который аналогичен параметру hue в Seaborn. Наконец, с помощью функции properties задаются определённые свойства графика.

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

selection = alt.selection_multi(fields=["Stock"], bind="legend")alt.Chart(stocks).mark_line().encode(   x="Date",   y="Close",   color="Stock",   opacity=alt.condition(selection, alt.value(1), alt.value(0.1))).properties(   height=300, width=500).add_selection(   selection)

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

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

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

hover = alt.selection(   type="single", on="mouseover", fields=["Stock"], nearest=True)

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

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

# line plotlineplot = alt.Chart(stocks).mark_line().encode(   x="Date:T",   y="Close:Q",   color="Stock:N",)# nearest pointpoint = lineplot.mark_circle().encode(   opacity=alt.value(0)).add_selection(hover)# highlightsingleline = lineplot.mark_line().encode(   size=alt.condition(~hover, alt.value(0.5), alt.value(3)))

Теперь, объединив второй и третий графики, можно создать интерактивный линейный график:

point + singleline

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

Заключение

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

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

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

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

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

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

Мы только что описали План С "Цифровое бессмертие", разработанный в рамках проекта достижения личного бессмертия, над которым с 2014 года работает российский трансгуманист Алексей Турчин, поставивший перед собой задачу увеличения продолжительности человеческой жизни. Турчин изложил детали такого плана в статье "Классификация подходов к технологическому воскрешению", опубликованной им недавно в соавторстве с коллегой Максимом Черняковым, также трансгуманистом. (Планы A, B и D соответственно носят названия "Борьба со старением", "Крионика" и "Квантовое бессмертие". В статье раскрывается смысл каждого из этих планов и описываются соответствующие перспективы достижения бессмертия.)

Когда Турчину было 11 лет, умерла его одноклассница. И тогда он, ещё совсем юный, стал задумываться о вечной жизни: достижима ли она? как этого добиться? "Я стал размышлять, что можно предпринять для достижения этой цели, и додумался до теории, которую можно смело вставлять в научно-фантастические рассказы, рассказал Турчин в интервью Pop Mech.

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

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

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

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

Физик Фримен Дайсон (ныне покойный) в статье "Поиск искусственных звёздных источников инфракрасного излучения", опубликованной в 1960 году в журнале Science, предложил концепцию особой мегаструктуры. Её смысл заключался в следующем: это гипотетическая тонкая сферическая оболочка большого радиуса со звездой (в нашем случае Солнцем) в центре, способная использовать энергию центральной звезды невообразимые 400 септильонов джоулей, ежедневно излучаемых нашей звездой. Это в триллионы раз больше, чем потребляет всё земное население.

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

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

Однако есть одна небольшая проблема: такую конструкцию земляне просто не в состоянии создать.

"Создать реальную сферу вокруг Солнца практически неразрешимая задача", считает Стюарт Армстронг (Stuart Armstrong), научный сотрудник Института будущего человечества при Оксфордском университете, проанализировавший различные концепции создания такой мегаструктуры (об этом ранее была статья в Pop Mech.

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

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

Но, даже если с помощью роботов удастся решить проблему использования всей этой энергии, Стивен Холлер (Stephen Holler), доцент кафедры физики Фордемского университета, к идее цифрового воскрешения всё равно относится скептически.

"Я не уверен, что можно с абсолютной точностью поставить человека в точно такие же условия развития, в каких он жил в прошлой жизни, ведь придётся учитывать абсолютно все условия, в которых он рос, развивался и жил к примеру, нужно будет учесть подзатыльник, которым этого человека наградил ещё в мальчишеском возрасте какой-нибудь другой мальчишка-задира, и так далее, каждую мелочь вплоть до самой смерти", сказал Холлер в интервью Pop Mech.

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

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

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

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

"Всем людям Земли предстоит неустанно трудиться над этим проектом в течение 100 лет", заявил Смит в интервью Pop Mech. Однако люди устроены так, что им привычнее планировать что-либо только на краткосрочную перспективу, их больше беспокоит сиюминутная прибыль, а не долгосрочная выгода. "Кто захочет посвятить всю жизнь созданию нечто такого, что не принесет пользы ни им, ни их детям, ни их внукам, а лишь людям, которые будут жить на планете через тысячу лет?" с удивлением спрашивает он.

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

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

За миллиарды лет работы имитационной модели в компьютерные коды, естественно, могут вкрасться ошибки. "Вполне может быть, что в конечном счёте мы сможем воспроизвести 90 процентов человеческого сознания, но будет ли созданный таким образом человек тем, кого мы ждали? задаётся вопросом Смит. Был ли бы я счастлив узнать, что после моей смерти вместо меня будет вечно жить, умирать и снова возрождаться моя восьмидесятипроцентная копия? Не знаю, не знаю..."

Эта проблема также беспокоит Турчина человека, разработавшего План С, хотя он полагает, что данная проблема имеет характер скорее философский, нежели физический: "Если копия похожа на оригинал до такой степени, что мы не в состоянии отличить оригинал от копии, можно ли считать, что копия тождественна оригиналу?"

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

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

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

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

Пластик: добро и зло

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

Изначально бакелит создавался в качестве замены шеллаку природной смоле, вырабатываемой тропическими насекомыми лаковыми червецами. Произведя реакцию поликонденсации фенола и формальдегида, Лео Бакеланд сначала получил термопластичную фенолоформальдегидную смолу, которая отверждалась только в присутствии отвердителей. Данный полимер Лео Бакеланд назвал 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 цель непростая. Здесь потребуются усилия на всех уровнях: государства, бизнеса, обывателей. Только все вместе мы сможем снизить деструктивные последствия деятельности человечества и сохранить природу Земли, флору и фауну. И сила данных нам тоже в этом поможет!

С началом работы программ лояльности, появилась возможность накапливать скидки, предоставляемых продавцами в виде бонусов. и оплачивать ими покупки. Сотрудники, обрабатывающие данные программ лояльности, оказываются перед соблазном использовать свои права доступа для неправомерных действий. Дмитрий Юдин, директор по развитию бизнеса Oracle СНГ, и Сергей Петраков, начальник службы информационной безопасности АО ТПК, специализированного оператора по процессингу пластиковых карт на корпоративном и розничном топливном рынке, рассказывают, почему тем, перед кем стоит задача защиты данных, стоит сосредоточиться не на поиске мошенников в своей команде и устранении последствий мошенничества, а на превентивных мерах защиты данных в информационных системах. О том, как с помощью встроенных в базы данных инструментов, можно исключить возможность мошенничества до того, как оно произошло.

Почему данные программ лояльности стали объектом интереса мошенников

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

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

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

На каких этапах обработки данных по программам возможны неправомерные действия

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

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

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

Выработка принципиального решения

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

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

Выбор средств, ограничивающих действия инсайдеров

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

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

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

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

Выбор между интегрированными средствами и внешними решениями

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

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

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

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

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

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

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

Какие интегрированные решения Oracle используют в ТПК

В качестве средства для шифрования данных клиентов программ лояльности в ТПК используют Oracle Advanced Security Transparent Data Encryption (TDE). Это решение обеспечивает возможность управления ключами шифрования и прозрачность шифрования конфиденциальных данных. В TDE задействован механизм шифрования на основе команд DDL. Он полностью исключает необходимость в изменении приложений и создании дополнительных программных средств для управления ключами шифрования, триггеров и представлений в базах данных. Шифрование дает возможность реализовать многоуровневую глубокую защиту. Данные защищены как при передаче, так и при хранении.

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

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

Результаты

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

Открывая будущее высокопроизводительных вычислений и искусственного интеллекта с революционными ускоренными вычислениями, представляем систему HPE Apollo 6500 Gen10 Plus. Это новаторское решение обеспечивает превосходно масштабируемую производительность и произведет революцию в использовании высокопроизводительных вычислений и искусственного интеллекта.

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

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

Гибридные (с использованием специализированных ГПУ) вычисления обеспечивают отлично масштабируемую производительность, а также более быструю и надежную вычислительную мощность для оптимизации самых требовательных рабочих нагрузок высокопроизводительных вычислений и искусственного интеллекта. Не так давно HPE объявило о новаторском дополнении к портфелю HPE Apollo, которое выводит гибридные вычисления на новый уровень. Система HPE Apollo 6500 Gen10 Plus следующее поколение в этой линейке продуктов, которое выведет использование высокопроизводительных вычислений и искусственного интеллекта на новый практический уровень.

Система HPE Apollo 6500 Gen10 Plus специально создана для обеспечения большой ценности для заказчиков:

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

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

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

• архитектура HPE Cray Supercomputer теперь включает систему HPE Apollo 6500 Gen10 Plus в качестве узла в ее версии с воздушным охлаждением, в сочетании с интерконнектом HPE Slingshot и поддерживаемой HPE Cray Operating System.
  

Для снижения нагрузок на устаревшую инфраструктуру и расширения возможностей для инноваций на основе обработки данных, система HPE Apollo 6500 Gen10 Plus использует вычислительную мощность новейших графических процессоров NVIDIA A100 с тензорными ядрами и процессоров AMD EPYC 2-го поколения. Графические процессоры NVIDIA A100 обеспечивают низкую задержку при высокой пропускной способности, чтобы улучшить эти мощные решения для гибридных вычислений. Благодаря тензорным ядрам третьего поколения NVIDIA A100 может эффективно масштабироваться до тысяч графических процессоров или, с помощью технологии NVIDIA Multi-Instance GPU (MIG), может быть разделена на семь изолированных инстансов графических процессоров для ускорения различных рабочих нагрузок. NVIDIA A100 предлагает значительные улучшения в тензорных ядрах и при работе с числами двойной точности, побив многочисленные рекорды по производительности на задачах ИИ и обеспечивая до 4,2 раза более высокую скорость обработки, чем в предыдущих поколениях ускорителей.

Система HPE Apollo 6500 Gen10 Plus обеспечивает максимальное использование графических процессоров (до 16 ГПУ на сервер) для быстрого сбора данных, их интеллектуального анализа и получения результатов, независимо от требований рабочих нагрузок высокопроизводительных вычислений и искусственного интеллекта. NVIDIA NVLink устанавливает бесшовное соединение между графическими процессорами, поэтому они могут работать вместе как единый мощный ускоритель. Интеконнект NVLink обеспечивает выделенную коммуникационную связь, которая позволяет переносить данные памяти с между ГПУ. Один ускоритель A100 поддерживает до 12 подключений NVLink с общей пропускной способностью 600 ГБ/с.

Процессоры AMD EPYC 2-го поколения предлагают огромную пропускную способность и большое количество ядер для непрерывной обработки требовательных к данным графических процессоров. Эти высокочастотные процессоры, интегрированные с NIVIDIA Mellanox HDR InfiniBand, добавляют до 200 Гб/с для полосы пропускания для каждых двух графических процессоров, поэтому даже продуктивные бизнес-системы, работающие в кластере, могут обмениваться данными с вдвое большей скоростью.

Для системы Apollo 6500 Gen10 Plus, HPE представила:

• первый сервер оптимизированный для 4-х графических процессоров, который обеспечивает лучшую цену, чем когда-либо для HPC;

• обновлённый двухпроцессорных сервер на базе процессоров AMD, который может поддерживать до 16 PCIe ГПУ, что в два раза больше, чем HPE поддерживало в прошлом.

Кроме того, система HPE Apollo 6500 Gen10 Plus предлагает обширные варианты организации подсистемы хранения, включая до 16 устройств хранения с доступом с передней панели, твердотельные диски SAS / SATA и до шести накопителей NVMe для более быстрого доступа к данным при меньшем потреблении энергии. HPE планирует дополнить эти возможности новыми решениями, которые будут включать 16 накопителей NVMe для увеличения пропускной способности почти в 6 раз. Теперь заказчики HPE могут использовать высокую мощность, частоту и вычислительную мощность гибридных вычислений, чтобы значительно сократить время, необходимое для получения аналитической информации.

Система HPE Apollo 6500 Gen10 Plus спроектирована с учетом плотности и гибкости для поддержки широкого спектра приложений HPC и ИИ. Наши решения давно признаны в отрасли благодаря высокой пропускной способности памяти, гибкости и безопасности для обеспечения быстрой передачи данных.

Созданные для эры Эксамасштабных вычислений, системы HPE Apollo 6500 Gen10 Plus еще больше увеличивают производительность для выполнения самых сложных рабочих нагрузок высокопроизводительных вычислений и искусственного интеллекта за счет графических процессоров NVIDIA HGX A100 с тензорными ядрами и интерконнектом NVLink или AMD Instinct MI100 с Infinity Fabric Link 2-го поколения. Суммарная производительность может превышать 100 Терафлопс (FP64). Возможность установки одного или двух процессоров позволяет улучшить баланс процессорных ядер, объема памяти и ввода/вывода. Повышение гибкости системы также достигается за счет поддержки 4, 8, 10 или 16 графических процессоров и широкого выбора операционных систем и предлагаемых опций, приближается к заказному (customized) дизайну, что означает для заказчиков снижение затрат, повышение надежности и удобства обслуживания.

Помимо ускорителей NVIDIA HGX A100 и AMD Radeon Instinct MI100, предлагается широкий выбор графических процессоров PCIe для высокопроизводительных вычислительных систем или искусственного интеллекта.

Система HPE Apollo 6500 Gen 10 Plus может содержать серверы следующих типов:

• До двух серверов HPE ProLiant XL645d Gen10 Plus это однопроцессорный сервер с поддержкой 4-х ускорителей NVIDIA HGX A100 или 4-х ускорителей AMD Instinct MI100 или 4-х ускорителей PCIe двойной ширины или 8-ми ускорителей PCIe стандартной ширины;

• один сервер HPE ProLiant XL675d Gen10 Plus это двухпроцессорный сервер с поддержкой 8-ми ускорителей NVIDIA HGX A100 или 8-ми ускорителей AMD Instinct MI100 или 10-ти ускорителей PCIe двойной ширины или 16-ти ускорителей PCIe стандартной ширины.

Также поддерживаются различные высокоскоростные фабрики интерконнекта Ethernet, HDR InfiniBand и HPE Cray Slingshot. В качестве опции для повышения эффективности и плотности мощности доступна система прямого жидкостного охлаждения (DLC), которая поставляется с заводов HPE предварительно заполненной, полностью интегрированной, установленной в стойку и готовой к подключению к водопроводу, что способствует сокращению сроков ввода в эксплуатацию, снижению стоимости владения, росту эффективности охлаждения и более высокой плотности по электрической мощности.

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

Удобное для обслуживания и модернизации решение с полным резервированием питания, легкодоступная модульная конструкция, вентиляторы с двойными роторами и возможностью горячей замены, а также фабрика интерконнекта с подключением кабелей к задней панели полностью совместимы со стандартной серверной стойкой глубиной 1075 мм, что обеспечивает быстрое и эффективное развертывание. Доступен и широкий выбор операционных систем, в том числе HPE Cray Operating System, Microsoft Windows Server, Ubuntu, Red Hat или VMware.

В системе HPE Apollo 6500 Gen10 Plus используется технология HPE iLO5 с аппаратным корнем доверия и процессор AMD Secure специализированный процессор для обеспечения повышенной безопасности, встроенный в процессор (систему на кристалле, SOC) AMD EPYC. Конструктивно сервер занимает 6U и изготовлен по модульному принципу. Такая конструкция позволят гибко конфигурировать систему сейчас и дает возможность для будущей модернизации.

Серверная плата позволяет устанавливать процессоры AMD EPYC с термопакетом до 280 Вт и имеет 32 слота для оперативной памяти DDR4-3200. Внутренняя подсистема хранения поддерживает до 16 накопителей малого форм-фактора, либо до 6 SFF NVMe, с удобным доступом на передней панели сервера. Интерфейс PCIe 4.0 позволяет использовать различные высокоскоростные вычислительные фабрики, среди которых Infiniband HDR (200 Гбит/с) и HPE Cray Slingshot.

Система Apollo 6500 Gen10 plus содержит в себе технологии эксамасштабной эры эры в которой производительность систем исчисляется Эксафлопсами (квинтиллионами операций с плавающей точкой). HPE уже строит несколько Эксафлопсных систем в США. Для построения этих систем необходимо было пересмотреть все подходы, которые были применимы для суперкомпьютеров, чтобы преодолеть супер- и выйти за рамки в масштаб Экса. Нами были разработаны продукты для этих суперкомпьютеров и теперь некоторые технологии, которые мы включили в эти продукты, стали доступны для корпоративного рынка, в том числе и в России. Узнать больше про эти продукты и технологии, а также про их применимость в корпоративных ЦОДах можно будет на вебинаре Стимулирование инноваций и инсайты по требованию, который состоится 24 марта в 10:00 по Москве. Зарегистрироваться на него вы можете по этой ссылке.

22 марта и 23 марта, 11.00-14.20 (GMT+3)

Изучите основные концепции баз данных в облачной среде. Присоединяйтесь к нам на мероприятии Microsoft Azure Virtual Training Day: основы данных, чтобы получить базовые знания об облачных сервисах обработки данных. Изучите предложения для работы с реляционными и нереляционными данными, а также решения для аналитики больших данных и современных хранилищ данных в Azure.

Подробности и регистрация.

Посетите это учебное мероприятие, чтобы:

• Изучить роли, задачи и обязанности, связанные с управлением данными в облачной среде.

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

• Изучить средства обработки данных, используемые при создании решений для аналитики данных, включая Azure Synapse Analytics, Azure Databricks и Azure HDInsight.

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

Вот, что мы вам предлагаем:

Подробности и регистрация.

Что делать с данными в 2021 году, если вы финансовая компания с традиционной инфраструктурой и не смотрели дальше BI? Как и зачем договариваться разным бизнесам в B2B и что можно найти среди маленьких данных?

Мы расскажем про опыт НРД центрального депозитария РФ. НРД хранит активы на сумму более 60 трлн руб. и аккумулирует практически весь рынок ценных бумаг в России. Основной бизнес сфокусирован на надежности: хранение, проведение расчетов, отчетность.

Если вы тоже задаетесь похожими вопросами или вам знакомы слова финансовый бэк-офис, добро пожаловать под кат.

Согласно Big Data Executive Survey 2020, 98,8% опрошенных компаний, входящих в список Fortune-1000, инвестировали в создание дата-центричного бизнеса. Две трети опрошенных компаний инвестировали больше 50 млн долл., а каждая пятая больше 500 млн долл. Но то же исследование из года в год показывает: примерно две трети опрошенных руководителей признают, что их бизнес так и не стал дата-центричным. А трое из четверых замечают, что эта тема стала для них настоящим вызовом. Что делать с этой информацией, если последние 15 лет вы прицельно не занимались данными и наконец решили, что пора?

Данные, или что мы делали позапрошлым летом

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

1. Сколько у нас данных? Как быстро они прирастают или обновляются? Какие они? Где хранятся?

2. Какие из наших данных уникальны?

3. Как устроены процессы работы с данными? Как данные появляются в системах, где дублируются и теряются?

4. С какой задержкой мы получаем информацию? Сколько занимает и стоит типичный запрос или сложная аналитика?

5. Что нам на самом деле нужно от данных?

Ответы на них не статичны и могут и будут меняться на разных стадиях зрелости компании. Например, мы ориентируемся на классификацию Google и Deloitte, а можно рассчитать data maturity index по аналогии с BCG. Сейчас мы считаем, что идеи ниже актуальны как минимум до уровня mature.

Чтобы понять картину в НРД, мы начали с аудита. Аудит данных и процессов работы с ними занял 3 месяца. Команда на этом этапе: продакт и техлид, занятые на 30-50%, по 1-2 представителя каждого бизнеса для интервью и по одному лиду ключевых систем для единичных запросов.

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

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

В целом если учитывать только объем и скорость прироста структурированной информации, то НРД при всём масштабе бизнеса раз в 10 не дотягивает до традиционной границы big data. Но если смотреть на ценность и уникальность наших данных, мы в топе.

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

2. Внутренних данных мало, доступные внешние данные не используются.

3. Не все доступные данные надлежащим образом собираются, обрабатываются и хранятся.

4. Те, что собираются, содержат ошибки и не всегда появляются вовремя.

5. Те, что собраны и почищены могут дублироваться незаметно для бизнес-процессов и критично для аналитики или наоборот.

6. Аналитика ассоциируется с ошибочным выбором метрик или возможностей монетизации.

Мы поймали все проблемы в разном объеме. Тут главное не отчаиваться. Если данных не хватает, проверьте открытые. Kaggle, тестовые датасеты вендоров, прямые запросы партнерам, открытые API интернет-сервисов. Проверьте на истории, насколько вам подходит сет. Как только вы поняли, что конкретные данные ценны для вас и работают, можно покупать. Если данные нужно разметить и они не конфиденциальные, привлекайте студентов, придумывайте исследование. Если данные дублируются, выбирайте мастер источник, которому будете доверять. Если в данных есть ошибки, оцените трезво, насколько они влияют на результат и вносят вклад в конечную точность анализа. Важно исправляйте, неважно смиритесь.

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

Технологии: копать, не копать, делать вид, что копаешь?

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

Для ответа на вопрос про размер данных можно ориентироваться на концепцию 3V Gartner: volume, velocity, variety. И добавить любые слова на V, которые кажутся вам подходящими для классификации (например, Спутник V к данным не относится, но если очень хочется, тоже можно использовать для классификации).

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

1. 1C/Excel все понятно. Данных мало, хоть мелом на заборе графики рисуй.

2. BI-решения. Могут быть витринами и собирать данные из нескольких БД, могут основываться на DWH. Сюда же Tableau, Cognus, Qlik и аналоги.

3. Специализированные решения для хранения и анализа больших или быстрых данных. Сюда попадает все дорогое и не всегда полезное и условно бесплатное, но требующее классной команды: in-memory БД, кластерные решения на основе Hadoop/Spark/Kafka/Hive/NiFi и другие.

4. Облачные решения: Amazon Athena/Redshift, Google BigQuery, Data Lake Analytics. Интересно, но страшно для финансовых компаний с точки зрения информационной безопасности. Как альтернатива возникают внутренние облака для группы компаний.

5. Платформы данных, комбинирующие пункты 2-4, виртуализация данных.

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

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

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

На первый взгляд, схема BI плюс прямые запросы к источникам под задачу работала. Но через полгода мы поняли, что с текущими технологиями получение данных, не включая очистку и разметку, занимает 75% времени аналитики. Основные ограничения: legacy мастер систем со сложными структурами баз данных, не унифицированные API и множественные интеграции систем, последовательное согласование между разными бизнес-линиями и ИТ-функциями и привязка ролей доступа к конкретным системам, а не данным.

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

Поэтому мы начали с proof of concept (POC). На POC стоит проверять максимальное количество технологий на реальной задаче. Задача должна включать в себя максимально разнообразные данные и проверять самые архитектурно сложные места. Как референс можно использовать riskiest assumption test из продуктовой разработки. То есть если вы больше всего сомневаетесь в работе с объемными данными, пробуйте на объеме. Если в сохранности данных прогоняйте все риск-сценарии для нагруженных систем. Если в объединении данных из разных источников и доступности для аналитики подключайте максимум источников и ограничивайте объем. Если в гибкости пробуйте радикальные изменения. Например, мы выбрали для тестирования работу с профилем клиента и предсказание вероятности покупки дополнительных продуктов из линейки с учетом того, что часть данных обезличена.

Команда на этом этапе: 1 продакт, 2 дата-аналитика/дата-сайнтиста, 1 ИТ тимлид, 1 дата-инженер, 1 ML-разработчик, 1/2 аналитика. С этого момента все завязано на людей.

Люди, или у нас другие cultural references

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

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

1. Аналитик(и).

2. Сервер или облако для экспериментов (Сюрприз! Даже если данные пролезают в 1 скрипт или на ПК, совместной работы не получается и времени на коммуникации уходит больше, чем на анализ).

3. Дата-инженер настраивать доставку данных не больше, чем за 30% времени задачи.

4. Участие бизнеса владельцев данных и дата-стюардов.

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

Такая структура матрицы дает взгляд на развитие с трех сторон: сам бизнес, ИТ-архитектура, управление данными (на C-level это управляющие директора, CIO и CDO) и подходит для текущего уровня зрелости компании.

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

Короче, сейчас мы понимаем data friendliness как открытость. Открытость для сотрудников компании: каждый может посмотреть задачи в работе, раз в 5-6 недель проводится демо и обсуждение с дата-стюардами и всеми, кому интересны данные. Открытость к идеям: идеи приходят из несвязанных областей, от студентов на конференциях, из самих данных. Открытость к людям: в финансы сложно нанимать звезд data science за разумные деньги, проще растить внутри.

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

И финальный совет: не отдавайте работу с данными на аутсорс. Да, растить или собирать команду внутри дорого на горизонте года, но стоит того, если смотреть на данные как на актив на ближайшие 5-10 лет.

Открытые данные в России, официально существуют уже 8 лет, 10 июня 2013 года был мой пост на хабре о принятии соответствующего закона.

Что изменилось за эти годы? Стало ли лучше или хуже? Работают ли порталы открытых данных? Публикуются ли данные?

Для тех кто интересуется состоянием открытых данных в России, я решил актуализировать цифры и собрать в виде набора фактов:

• за 2020 год на федеральном портале открытых данных (data.gov.ru) было опубликовано 223 набора данных, за 5 месяцев 2021 года - только 2 набора данных

• всего с 2020 года объём этих 225 наборов данных - 405 мегабайт из которых более 390 мегабайт - это данные Минкультуры России и ФНС России (и то есть подозрение что цифры завышены потому что в реестре наборов данных есть дублирующиеся записи. Скорее всего реально данных значительно меньше)

• лишь 9 178 наборов данных из 24 002 опубликованы федеральными органами власти, остальные региональными и муниципальными

• 10 ФОИВов не опубликовали ни одного нового набора данных с 2013 года (за 8 лет)

• 20 ФОИВов не опубликовали ни одного нового набора данных с 2015 года (за 6 лет)

• 42 ФОИВа не опубликовали ни одного нового набора данных с 2017 года (за 4 лет)

• 68 ФОИВов не опубликовали ни одного нового набора данных с 2019 года (за 2 года)

• иначе говоря в 2020 и 2021 года лишь 6 ФОИВов разместили хотя бы один новый набор данных на портале открытых данных

• некоторые ФОИВы, при этом, кое что опубликовали на своих сайтах, но куда меньше чем раньше и чем могли бы

• общий объём опубликованных данных на портале data.gov.ru оценить сложно, сайт не даёт статистики, API сайта очень куцое, требуется очень много запросов сделать чтобы подсчитать хоть самые приблизительные цифры, но они будут невелики.

• параллельно этому на сайтах и FTP серверах органов власти опубликовано открытых данных, оценочно, на 20 терабайт в форме архивов. Количественно - это сотни наборов данных, качественно - это данные большого объёма.

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

• источники наиболее крупных наборов данных:

  • Сайт ФНС России (nalog.ru)

  • Портал открытых данных Минкультуры России (opendata.mkrf.ru)

  • Портал госзакупок (zakupki.gov.ru)

  • Единый портал бюджетной системы (budget.gov.ru)

  • ФИАС (fias.nalog.ru)

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

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

• в других субъектах федерации перестали публиковать новые наборы данных, это касается и портала открытых данных Москвы и десятков других субъектов федерации (чуть ли не всех)

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

Если видите что какие-то события не упомянуты, смело добавляйте новые факты.

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

1. В чём разница между контролируемым и неконтролируемым машинным обучением?

Контролируемое машинное обучение:

• Использует известные и маркированные данные в качестве входных.

• Имеет механизм обратной связи.

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

Неконтролируемое обучение:

• Использует немаркированные данные в качестве входных.

• Не имеет механизма обратной связи.

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

2. Перечислите этапы построения дерева решений.

1. Взять весь набор входных данных.

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

3. Рассчитать прирост информации по всем атрибутам (информацию о том, как отсортировать разные объекты друг от друга).

4. Выбрать атрибут с наибольшим объёмом информации в качестве корневого узла.

5. Повторить ту же процедуру для каждой ветви, пока узел решения каждой ветви не будет завершён.

3. Что такое проблемы взрывающегося и затухающего градиента?

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

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

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

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

4. Как рассчитать точность прогноза, используя матрицу путаницы?

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

Формула точности:

Точность = (истинно положительные + истинно отрицательные) / общее количество наблюдений.

Предположим, что истинно положительных значений у нас 2981, истинно отрицательных 110, а всего 3311. Используя формулу, находим, что точность прогноза составляет 93,36 %.

5. Как работает ROC-кривая?

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

Если считать TPR и FPR для фиксированного порога [0,1], то их можно представить в виде функций от аргумента :

TPR = TPR(), FPR = FPR(). При этом обе функции монотонно возрастают от 0 до 1, а значит, определена функция:

ROC(x) = TPR(FPR^-1(x)), x [0,1]

ROC-кривая это график функции.

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

6. Объясните алгоритм машинного обучения SVM

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

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

7. Что такое ансамбль методов?

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

8. Что такое Random Forest?

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

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

9. Какой метод перекрёстной проверки вы бы использовали для набора данных временных рядов?

Нормальная k-кратная процедура перекрёстной проверки может быть проблематичной для временных рядов.

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

• сгиб 1: тренировка [1], тест [2];

• сгиб 2: тренировка [1 2], тест [3];

• сгиб 3: тренировка [1 2 3], тест [4];

• сгиб 4: тренировка [1 2 3 4], тест [5];

• сгиб 5: тренировка [1 2 3 4 5], тест [6].

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

10. Что такое логистическая регрессия? Или приведите пример логистической регрессии.

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

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

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

11. Что вы понимаете под термином нормальное распределение?

Нормальное распределение одно из основных распределений вероятности.

Плотность нормального распределения выражается функцией Гаусса:

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

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

12. Что такое глубокое обучение?

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

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

13. В чём разница между машинным обучением и глубоким обучением?

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

14. Что такое рекуррентные нейронные сети (RNN)?

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

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

15. Что такое обучение с подкреплением?

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

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

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

16. Объясните, что такое регуляризация и почему она полезна.

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

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

17. Что такое рекомендательные системы?

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

18. Какова цель A/B-тестирования?

A/B-тестирование это статистическая проверка гипотез для рандомизированных экспериментов с двумя переменными, A и B.

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

19. Что такое закон больших чисел?

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

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

К примеру, при бросках шестигранного кубика. Чем больше бросков, тем больше среднее значение близится к математическому ожиданию 3,5.

20. Назовите несколько фреймворков для глубокого обучения.

• Pytorch.

• TensorFlow.

• Microsoft Cognitive Toolkit.

• Keras.

• Caffe.

• Chainer.

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

• Курс по Data Science (12 месяцев)

• Курс по Аналитике данных (6 месяцев)

• Курс по Data Engineering

Жесткие дискиHAMRуже с нами!

Компания Seagate сообщила о старте коммерческих поставок жестких дисков с технологией термомагнитной записи (HAMR) с ноября 2020, а также расширила программу тестирования Mach.2 HDD с двойным приводом, о которых мы как раз писали ранее. Компания уверена, что имеющиеся технологии позволят наращивать емкость и повышать производительность жестких дисков в ближайшие годы.

Спрос на жесткие диски растет среди операторов дата-центров и экзаскейлеров, причем им требуются накопители с высокой емкостью и эффективностью энергопотребления. Летом 2020 года Seagate начала продажи 18-Тбайт жестких дисков с девятью пластинами. По мере апробирования новых емких HDD клиентами, они начнут все более широко использоваться в дата-центрах. Интересно, что данная платформа легла в основу первых 20-Тбайт жестких дисков HAMR, поэтому спецификации накопителей очень похожи.

На данный момент HAMR HDD могут купить лишь ограниченное число клиентов в рамках корпоративных систем хранения и решений Seagate Lyve. Позднее жесткие диски HAMR будут доступны и более широкой аудитории. Но первые 20-Тбайт жесткие диски HAMR могут и не выйти на массовый рынок, поскольку Seagate планирует повысить емкость на 20% в ближайшем будущем. Следовательно, можно ожидать скорое появление 24-Тбайт HDD. И они могут стать первыми розничными HDD на HAMR.

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

Сейчас мы рассмотрим принцип записи с использованием энергии, составной частью которой является термомагнитная запись HAMR. После чего перейдем к разгадкам тайн инженеров Seagate.

Магнитная запись с использованием энергии ключ к повышению емкости

Технологии магнитной записи с использованием энергии (EAMR, energy-assisted magnetic recording) уже давно на слуху у пользователей и энтузиастов. По сравнению со стандартной сегодня перпендикулярной магнитной записью PMR они обеспечивают дальнейшее увеличение плотности записи данных.

Из наиболее перспективных технологий EAMR выделяют термомагнитную запись (HAMR,heat-assisted magnetic recording) и запись с использованием микроволн (MAMR, microwave-assisted magnetic recording). По мнению Ассоциации передовых технологий хранения данных (Advanced Storage Technology Consortium, ASTC), HAMR станет новым знаковым этапом на пути к повышению плотности записи, то есть увеличению емкости жестких дисков при прежнем физическом размере. Эта инновация окажет большое влияние на развитие жестких дисков в течение следующего десятилетия.

Какой вариантEAMRлучше?

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

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

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

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

Современные накопители MAMR используют пластины со сплавом CoPt (кобальт-платина). К головке записи MAMR добавлен генератор электромагнитного поля, которое не нагревает пластину напрямую, но заставляет магнитные зерна "дрожать", облегчая их перемагничивание.

Что касается дисков HAMR, то там применяется более стабильный сплав FePt (железо-пластина). На поверхность FePt нельзя записать данные с помощью способов PMR или MAMR. Для метода HAMR используется маленький лазерный диод, установленный на каждой головке записи. Он используется для кратковременного нагрева небольшого участка пластины. Пока участок горячий, головка записи перемагничивает биты на нем, меняя их ориентацию. Процесс нагрева-охлаждения занимает считаные наносекунды, поэтому лазер совершенно не влияет на температуру отдельной пластины и накопителя в целом, равно как и на стабильность и надежность хранения данных. Как считают специалисты ASTC, на данный момент только поверхность FePt позволяет добиться емкости накопителей 30 Тбайт и выше.

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

Технические тайныHAMR

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

Чтобы увеличить плотность хранения данных, необходимо уменьшать объем зерен на пластине ("V" в формуле ниже). Но при этом теряется температурная стабильность зерен, и для компенсации следует увеличивать анизотропию материала пластины (буква "K"). Анизотропия пропорциональна усилиям, которые необходимы для изменения магнитной ориентации зерен.

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

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

Немного истории: как повышалась плотность записи

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

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

ОтPMRкSMRиHAMR

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

В итоге удалосьуменьшить размер зерен и увеличить плотность записи.

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

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

Технология SMR действительно обеспечивает увеличение емкости HDD. Seagate представила первый жесткий диск SMR в 2014 году, увеличив емкость на 25 процентов. При этом метод записи битов остался прежним, что позволило сочетать преимущества PMR и SMR. Но и данная технология не позволяет увеличивать плотность записи бесконечно. Современные жесткие диски PMR не могут дать выше 1 терабита на квадратный дюйм (Tbpsi). Законы физики обойти невозможно.

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

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

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

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

Головки HAMR напоминают обычные PMR. Но к ним добавлен лазер, оптический волновод и преобразователь ближнего поля NFT (near-field transducer) для облегчения нагрева материала.

Разрабатываем дискHAMR

А теперь давайте на минутку представим себя инженеромSeagateи попытаемся разработать и произвести дискHAMR. Для этого следует сделать несколько шагов.

• Добавить лазерный диод к головке

• Разработать оптический волновод для передачи света от лазера кNFT

• ВстроитьNFTв головку записи

• Разработать новые пластиныHAMR

• Доработать прошивку диска и тестовых систем

• Изменить процесс производства, чтобы выпускать дискиHAMR

• Сделать миллион разных мелочей, что входит в рабочий процесс инженеровSeagate

На головке HAMR лазер прикреплен к субмаунту. Затем оптоволокно передает свет от лазера к преобразователю NFT, который интегрирован в головку записи.

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

Как быть с дифракционным пределом?

Уже более ста лет известно, чтодифракция ограничивает размер пятна сфокусированного света(см.Дифракционный предел). У накопителяBlu-rayразмер пятна составляет 238 нанометров. Если перейти к масштабу дорожек диска, то пятно слишком крупное. Даже если пойти на оптические хитрости и использовать технологии записи в ближнем поле, то меньше около 100нмполучить сложно. Так что требуется какое-либо другое решение.

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

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

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

За последние 15 лет инженеры Seagate трудились, не покладая рук. Дизайн HAMR был много раз переработан и собран "с нуля". Инженерам удалось перейти от теоретической концепции к первым практическим реализациям. На протяжении цикла разработки HAMR было изготовлено более 25 млн. плазмонных преобразователей NFT!

Как дорабатывались пластиныHAMR

Конечно, сами пластины жесткого диска тоже пришлось существенно дорабатывать. Подложка пластинHAMR(DiskSubstrate) изготовлена из специального стекла, способноговыдерживатьнагрев записывающего слоя до высоких температур. ДляHAMRпотребовалось добавить слой-радиатор(HeatSink/SUL), чтобы он отводил тепло от записывающего слоя. Слишком быстрое отведение приводило бы к недостаточной мощности нагрева. Слишком медленное к перегреву участка, из-за чего нагревались бы соседние участки с последующей потерей информации. Для успеха жестких дисковHAMRбыло важно получить нужный баланс. Покрытие пластины тоже пришлось сменить, чтобы оновыдерживалонагрев до более 400C, но при этом обеспечивало надежный интерфейс между пластиной и головкой записи.

ВыходHAMRна рынок: важно быть лидером в исследованиях

Seagateуженачала коммерческую эксплуатацию технологииHAMR, запустив массовое производство 20-Тбайт жестких дисков в конце 2020 года. Но, как мы отметили выше, в рознице эти диски вряд ли появятся, они отгружаются только партнерам. Скорее всего,Seagateначнет массовую продажу накопителейHAMR,начиная с емкости 24 Тбайт.

9 ноября 2010 годаSeagateприсоединилась к двенадцати другим членам консорциумаAdvancedStorageTechnologyConsortium(ASTC). И каждый последующий годSeagateвместе с другими компаниями инвестирует немалые суммы в фундаментальные исследования технологий хранения данных под эгидойASTC.

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

Что нас ждет в будущем?

Как можно видеть по планам, технологияPMRбудет с нами еще несколько лет, учитывая наработки с гелиевым наполнениемHDD,SMRи использование нескольких приводов (см.SeagateMACH.2 и Exos 2X14: разбираемся в преимуществах двойного привода).

На конференцииASTC2020 доктор СтефанияЭрнандесиспользовала микромагнитное моделирование, которое масштабировало технологиюHAMRдо6,0Tbpsi(терабитна квадратный дюйм). А доктор СтивГранцв своей демонстрацииHAMRсмог получить плотность записи2,77Tbpsi, поставив новый рекорд по критериямASTC.

Seagateс жесткими дискамиHAMRуже удалось получить уровень2,0Tbpsi. Тестируется технология с плотностью записи2,381Tbpsi, она обеспечит емкость3 Тбайт на пластину, то естьHDDс девятью пластинами смогут дать уже27 Тбайтемкости. Переход на жесткие дискиHAMRне потребует изменения экосистемы и инфраструктуры. На данный момент прогнозируется20% ежегодный рост емкости, что позволит получить 24-ТбайтHDDв ближайшем будущем, а через несколько лет емкость достигнет 40 Тбайт и выше.

Рано или поздноHAMRбудет сочетаться с технологией записи, использующейбитовые шаблоныBPMR(bitpatternedmedia). В случаеSeagateданная технология называетсяHDMR(HeatedDotMagneticRecording), она позволит увеличить емкость жестких дисков до 100 Тбайт и выше.

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

А вот и продолжение истории из начала статьи, как говорится, это еще не все!

- А вы что, не делали мне бэкапы!? Зачем я тогда вообще размещаюсь по-вашему???

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

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

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

Как пропадают данные?

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

• молния ударила в дата-центр Google;

• что-то пошло не так при миграции сервера и MySpace потеряла все данные пользователей за 12 лет с 2003 по 2015 годы (включая музыку, фотографии и видео);

• 16000 результатов тестов на коронавирус было утеряно из-за технической ошибки в Excel в Великобритании, подробности не уточняются;

• Яндекс удалил виртуальные машины активных пользователей, применив некорректную фильтрацию и перепутав их с должниками;

• администратор ошибся, а gitlab лишился базы данных объемом 300Гб;

• в результате кибератаки вируса-шифровальщика все данные в базе данных компании ISS World были утеряны.

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

Наивность и дебиторка

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

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

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

• оплатить забыли или не успели;

• сейчас нет денег;

• не получили счет и забили;

• бухгалтерия где-то как-то что-то;

• прочая бюрократия.

Как хостеры обращаются с данными

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

Для понимания, обрисую ситуацию, которую мы транслировали при общении:

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

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

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

Работа встала, но еще не все потеряно.

Однако, что происходит после того, как предоставление услуг приостановлено?

После появления задолженности, в какие сроки сервер будет разукомплектован / удален?

Аренда физического сервера:

Аренда виртуального сервера:

Случилось страшное. Сервер разукомплектован или удален, но может быть еще есть шанс, что данные можно восстановить?

После того, как сервер разукомплектовали / удалили, есть ли возможность восстановить данные?

Аренда физического сервера:

Аренда виртуального сервера:

Раз уж статистика такая, может быть хостеры предлагают бэкапы, которые входят в услугу по умолчанию? (тут речь только про виртуальные сервера, для физических сразу 100% нет, что логично)

Имеется ли резервное копирование, которое входит в стоимость услуги по умолчанию?

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

Что еще можно отнести к наивности?

Значок Договор, покажи ему свой договор! (с)

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

Под меня будут подстраиваться. Уверены?

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

Ситуация, когда наша бухгалтерия платит только по четвергам (с) не единична, но весьма комична.

А мы счет не получали! (с)

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

Вы же профессионалы (с)

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

Уходя, гасите свет (с)

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

Заключение

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

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

• проверяйте бэкапы (а можно ли из них что-то развернуть?);

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

• убедитесь, что вы точно получите счет за услуги, резервируйте получателей;

• настройте автоплатеж, если не задействована бухгалтерия;

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

• спросите у своего хостера про бэкапы и другие, пусть даже самые очевидные ситуации;

• поинтересуйтесь у вашего менеджера как принято работать с дебиторкой, какие сроки у вас есть и как можно их оттянуть;

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

• не будьте наивными, это дорогого стоит.

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

1. Мы не сможем точно ответить на ряд вопросов, потому что подход индивидуальный (и вот тут придется объясниться);

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

Немного слов про индивидуальный подход при работе с дебиторкой.

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

Да, у нас есть бэкапы по умолчанию для виртуальных серверов, но спросите менеджера когда исчезнут ваши данные и он не ответит. Почему? Потому что подход все еще индивидуальный. Факторов масса, но один, наиболее важный - мы не доверяем автоматизированным оповещениям. Счета рассылаются автоматически по электронной почте, туда же, с завидной периодичностью падают письма с напоминанием и дублем счета. Еще мы используем смс-оповещение, остановились на API greensms.ru, но это все автоматика.

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

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

Исключения наверное есть, но это те, кто:

а) не прислал платежку;

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

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

Берегите свои данные, не позволяйте хостерам их уничтожать!

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

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

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

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

Ключевые характеристики жестких дисков

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

Форм-фактор

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

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

Отдельная категория внешние накопители. Они представляют собой те же 2,5" или 3,5" HDD, заключенные в корпус. В случае 2,5" HDD есть преимущество дополнительное питание чаще всего не требуется. Кроме того, внешние накопители часто предлагают бонусы, такие как USB-концентратор или дополнительный софт резервирования.

Емкость

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

Скорость вращения шпинделя

Раньше данный параметр был один из основных, поскольку влиял на производительность жесткого диска (пропускную способность и задержки). Но поскольку в качестве системных накопителей все чаще устанавливают SSD, а HDD используют для хранения данных, то скорость вращения шпинделя уже не так важна. Распространены два варианта: 7.200 об/мин и 5.400 об/мин. При прочих равных большая скорость вращения дает более высокий уровень производительности. Но при этом возможны жертвы по энергопотреблению и уровню шума, поэтому слепо гнаться за высокой скоростью вращения не стоит. Она должна быть достаточной, чтобы жесткий диск давал приемлемый уровень производительности.

Тип записи и другие технологии

Жесткие диски высокой емкости (обычно 10 Тбайт и выше) перешли на гелиевое наполнение вместо обычного воздуха, что привело к улучшениям по уровню шума и энергопотреблению. В нашем обзоре гелиевые HDD представлены линейкой Exos. Пластины при этом получается располагать ближе друг к другу, что позволяет добиться рекордных уровней емкости в каждом поколении. Из-за себестоимости гелиевые жесткие диски начинаются только с определенного уровня емкости. А младшие линейки HDD используют воздух.

Из современных технологий магнитной записи следует упомянуть перпендикулярную (PMR), на которой работают большинство жестких дисков. Для дальнейшего увеличения емкости без чрезмерного удорожания была разработана технология черепичной записи (SMR). С одной стороны, она позволяет в прежний бюджет уместить большую емкость. С другой стороны, придется жертвовать снижением скорости записи. Для многих сценариев SMR остается вполне разумным выбором. Например, большинство представленных в статье 2,5" накопителей опираются на SMR. Подробнее об этой технологии можно прочитать в нашей статье SMR: понятно в теории, сложно на практике.

В этом году на рынок должны выйти жесткие диски с передовыми технологиями записи HAMR и MAMR, которые позволяют перейти на новые уровни емкости. Здесь мы рекомендуем прочитать статью От витражей к терабайтам: разгадываем тайны HAMR. Как только жесткие диски появятся на рынке, мы добавим их в обзор.

Выбираем лучший 3,5" HDD

Жесткие диски 3,5" формата остаются наиболее популярными на рынке из-за оптимального сочетания размеров, емкости и скорости. Seagate разделяет свои 3,5" жесткие диски на несколько линеек: Barracuda (Pro) для настольных ПК, IronWolf (Pro) для NAS, SkyHawk (AI) для видеонаблюдения, Exos для серверов. Разница кроется в различных рабочих характеристиках, прошивке, сертификации и т.д. В принципе, нет ничего страшного в том, чтобы использовать тот же серверный жесткий диск Exos в домашнем ПК, но придется смириться, например, с более высоким уровнем шума.

Мы рассмотрим только накопители с интерфейсом SATA. Потребительская линейка Seagate Barracuda остается весьма выгодной до своей максимальной емкости 8 Тбайт. Но затем пальму первенства перехватывает семейство Exos, как мы покажем ниже.

2.500 и 1 Тбайт - Seagate Desktop HDD ST1000DM003

Мы начнем с минимальной емкости 1 Тбайт, которую можно приобрести за 2.500 . Меньшие варианты емкости брать смысла не имеет, поскольку преимущества по цене нет. Жесткий диск Seagate Desktop HDD ST1000DM003 сравнительно старый, поколения 2014 года (7200.14), но со своей работой он справляется. Скорость вращения шпинделя 7.200 об/мин, заявленная скорость передачи до 210 Мбайт/с, рабочее энергопотребление 5,9 Вт. Гарантия 2 года. См. подробные спецификации.

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

Купить Seagate Desktop HDD ST1000DM003 за 2.500

3.800 и 2 Тбайт Seagate Barracuda ST2000DM008

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

Жесткий диск Seagate Barracuda ST2000DM008 относится к современному поколению со скоростью вращения шпинделя 7.200 об/мин, скорость передачи данных до 220 Мбайт/с, рабочее энергопотребление 4,3 Вт. Жесткий диск опирается на всего одну пластину, поэтому и результаты энергопотребления приятно радуют. Гарантия 2 года. См. подробные спецификации.

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

Купить Seagate Barracuda ST2000DM008 за 3.800

5.600 и 3 Тбайт Seagate Barracuda ST3000DM008

Следующий ценовой уровень позволяет нарастить емкость еще на 1 Тбайт, доплатив разумную сумму (1.867 /Тбайт). ST3000DM008 относится к той же современной линейке, что 2-Тбайт модель ST2000DM008. Скорость вращения шпинделя 7.200 об/мин, скорость передачи данных до 210 Мбайт/с, рабочее энергопотребление 8 Вт. По энергопотреблению видно, что число пластин увеличилось до трех. Гарантия 2 года. См. подробные спецификации.

Купить Seagate Barracuda ST3000DM008 за 5.600

7.400 и 4 Тбайт Seagate Barracuda ST4000DM004

Емкость 4 Тбайт тоже масштабируется практически линейно по цене (1.850 /Тбайт). Семейство накопителей не изменилось, но 4-Тбайт ST4000DM004 опирается на две пластины, а также меньшую скорость вращения шпинделя 5.400 об/мин. Поэтому энергопотребление чуть ниже 3-Тбайт версии 3,7 Вт. Скорость передача данных заявлена до 190 Мбайт/с. Как мы отмечали выше, жесткие диски уже редко используются в качестве системных. Но если такая необходимость возникнет лучше брать модель на 7.200 об/мин. В данном случае мы получаем классический HDD для хранения данных. Гарантия 2 года. См. подробные спецификации.

Внимание: возможно, более выгодным вариантом станет покупка внешнего Seagate Backup Plus Portable Drive с 2,5" накопителем на 4 Тбайт или Seagate Basic с 2,5" HDD на 5 Тбайт (см. ниже).

Купить Seagate Barracuda ST4000DM004 за 7.400

11.800 и 6 Тбайт - Seagate Barracuda ST6000DM003

Жесткие диски емкостью 5 Тбайт стоят не дешевле 6-Тбайт вариантов, поэтому брать их смысла нет. Следующая ценовая ступенька 6-Тбайт ST6000DM003. Здесь работают три пластины на 5.400 об/мин, энергопотребление заявлено 5,3 Вт, скорость последовательной передачи данных до 190 Мбайт/с. Жесткий диск можно рекомендовать тем пользователям, кому емкости 4 Тбайт будет недостаточно. Масштабирование цены в расчете на терабайт здесь немного ухудшается по сравнению с HDD младшей емкости 1.967 /Тбайт. Но 6 Тбайт остается довольно популярным вариантом для хранения данных. Гарантия 2 года. См. подробные спецификации.

Внимание: возможно, более выгодным вариантом станет покупка внешнего Seagate Backup Plus Hub 6 TB (см. ниже).

Купить Seagate Barracuda ST6000DM003 за 11.800

13.700 и 8 Тбайт Seagate Barracuda ST8000DM004

Переход на 8 Тбайт оказался более привлекателен по цене, поскольку здесь мы получаем 1.712 /Тбайт. Поэтому данную модель ST8000DM004 брать выгоднее, чем многие другие. Жесткий диск относится все к той же современной линейке Barracuda. Несмотря на четыре пластины, энергопотребление не увеличилось 5,3 Вт. Скорость последовательной передачи данных прежняя до 190 Мбайт/с, как и скорость вращения шпинделя 5.400 об/мин. Гарантия 2 года. См. подробные спецификации.

Внимание: возможно, более выгодным вариантом станет покупка внешнего Seagate Expansion Desktop Drive 8 TB (см. ниже).

Купить Seagate Barracuda ST8000DM004 за 13.700

19.100 и 12 Тбайт - Seagate Exos X16 ST12000NM001G

Следующее выгодное предложение жесткий диск на 12 Тбайт ST12000NM001G из линейки Exos X16 с гелиевым наполнением. Емкость 10 Тбайт пришлось пропустить, поскольку выгодных цен мы не нашли. В случае 12-Тбайт HDD цена терабайта весьма привлекательная 1.592 . Здесь проявляется феномен емкости: чем она выше, тем вкуснее цена гигабайта. Данный накопитель лидирует в нашем руководстве по минимальной цене в расчете на емкость (если не учитывать внешние HDD).

Линейка ST12000NM001G относится к корпоративному классу, поэтому гарантия составляет пять лет, есть и сертификат на режим работы 24/7. Скорость вращения шпинделя 7.200 об/мин, пропускная способность передачи данных до 245 Мбайт/с, максимальная потребляемая мощность 9,5 Вт. См. подробные спецификации.

Жесткие диски Exos X16 отлично подойдут для NAS. При использовании в домашней системе следует учитывать высокий уровень шума.

Внимание: возможно, более выгодным вариантом станет покупка внешнего Seagate Backup Plus Hub 12 TB (см. ниже). Но при этом теряются плюшки Exos.

Купить Seagate Exos X16 ST12000NM001G за 19.100

24.600 и 14 Тбайт - Seagate Exos X16 ST14000NM001G

Серверные накопители Exos X16 продолжают лидировать по соотношению цена/емкость, обеспечивая при этом отличную производительность. Прирост емкости ST14000NM001G на 2 Тбайт оказался менее эффективным: 1.753 /Тбайт. В остальном мы получаем ту же гелиевую линейку со всеми преимуществами корпоративного класса, главные из которых гарантия 5 лет и сертификация на работу 24/7. Скорость вращения шпинделя составляет 7.200 об/мин, пропускная способность передачи данных до 261 Мбайт/с, максимальная потребляемая мощность 10 Вт. См. подробные спецификации.

Жесткие диски Exos X16 отлично подойдут для NAS. При использовании в домашней системе следует учитывать высокий уровень шума.

Внимание: возможно, более выгодным вариантом станет покупка внешнего Seagate Expansion Desktop Drive 14 TB (см. ниже). Но при этом теряются плюшки Exos.

Купить Seagate Exos X16 ST14000NM001G за 24.600

29.700 и 16 Тбайт - Seagate Exos X16 ST16000NM001G

Серверная линейка Exos X16 продолжает оставаться выгодной и в старшем варианте емкости ST16000NM001G - 1.860 /Тбайт. К преимуществам гелиевого накопителя отнесем срок гарантии 5 лет и сертификат на работу в режиме 24/7. Скорость вращения шпинделя составляет 7.200 об/мин, пропускная способность передачи данных до 261 Мбайт/с, максимальная потребляемая мощность 10 Вт. См. подробные спецификации.

Жесткие диски Exos X16 отлично подойдут для NAS. При использовании в домашней системе следует учитывать высокий уровень шума.

Внимание: возможно, более выгодным вариантом станет покупка внешнего Seagate Expansion Desktop Drive 16 TB (см. ниже). Но при этом теряются плюшки Exos.

Купить Seagate Exos X16 ST16000NM001G за 29.700

33.800 и 18 Тбайт - Seagate Exos X18 ST18000NM000J

Таким же выгодным приобретением оказывается вариант ST18000NM000J в максимальной емкости 18 Тбайт, доступной на рынке. Здесь мы получаем всего 1.880 /Тбайт. Но линейка X18 более современная, недавно мы как раз опубликовали тест Seagate Exos X18 жесткий диск корпоративного класса на 18 Тбайт, где приведены подробности. Конечно, не обошлось без солидной гарантии на 5 лет и сертификата на работу 24/7. Максимальная скорость новой линейки была увеличена до 270 Мбайт/с. Максимальная потребляемая мощность снижена до 9,4 Вт. См. подробные спецификации.

Жесткие диски Exos X18 отлично подойдут для NAS. При использовании в домашней системе следует учитывать высокий уровень шума.

Купить Seagate Exos X18 ST18000NM000J за 33.800

Выбираем лучший 2,5" HDD

Еще лет десять назад основной сферой использования 2,5" HDD были ноутбуки, но сегодня место системных мобильных накопителей заняли SSD. Если в ноутбуке предусмотрен отсек под второй накопитель в формате 2,5", то его как раз можно занять емким жестким диском, так как SSD в расчете на гигабайт остаются значительно дороже. Кроме того, 2,5" HDD можно использовать во внешнем боксе как переноску. Следует обращать внимание на толщину накопителя. Многие устройства рассчитаны на установку 2,5" HDD толщиной 7 мм. Самые емкие модели имеют толщину 15 мм, поэтому они подойдут далеко не для всех ноутбуков или боксов. Ниже мы рассмотрим 2,5" HDD только с интерфейсом SATA.

2.900 и 1 Тбайт Seagate ST1000LM035

Мы вновь выставили минимальную планку 1 Тбайт, поскольку брать меньшую емкость нерационально. Жесткий диск ST1000LM035 использует одну пластину, скорость вращения шпинделя составляет 5.400 об/мин, скорость последовательной передачи до 140 Мбайт/с. Энергопотребление всего до 1,6 Вт. Срок гарантии два года. Перед нами экономичный жесткий диск, который хорошо подойдет и как дополнительный накопитель ноутбука (толщина 7 мм), и для переносного бокса. Конечно, если емкости 1 Тбайт будет достаточно. См. подробные спецификации.

Купить Seagate ST1000LM035 за 2.900

4.200 и 2 Тбайт Seagate ST2000LM007

Следующая планка емкости 2 Тбайт оказывается более выгодной, мы получаем уже 2.100 /Тбайт. ST2000LM007 опирается на две пластины, поэтому энергопотребление поднялось до 1,7 Вт. Скорость вращения шпинделя 5.400 об/мин, гарантия два года, скорость передачи данных до 140 Мбайт/с. Как и модель на 1 Тбайт, его можно рекомендовать для ноутбуков (вторым HDD, толщина 7 мм) и переносных боксов. См. подробные спецификации.

Купить Seagate ST2000LM007 за 4.200

7.700 и 4 Тбайт Seagate Barracuda ST4000LM024

Емкость 4 Тбайт ST4000LM024 оказалась еще более привлекательной 1.930 /Тбайт. Причем линейка уже другая Barracuda, но скорость вращения шпинделя не изменилась 5.400 об/мин. Среднее энергопотребление при чтении/записи составляет до 2,1 Вт, скорость передачи данных до 140 Мбайт/с. Гарантия 2 года. Жесткий диск имеет толщину 15 мм, поэтому он подойдет далеко не для всех ноутбуков и боксов. Проверяйте совместимость перед покупкой. См. подробные спецификации.

Внимание: возможно, более выгодным вариантом станет покупка внешнего Seagate Backup Plus Portable Drive с данным накопителем (см. ниже).

Купить Seagate Barracuda ST4000LM024 за 7.700

12.000 и 5 Тбайт Seagate Barracuda ST5000LM000

Жесткий диск ST5000LM00 на 5 Тбайт уже выходит из окна оптимального соотношения емкости и цены 2.400 /Тбайт. Зато он позволяет уместить в компактном объеме целых пять терабайт! Но, как и в случае модели на 4 Тбайт, следует учитывать толщину 15 мм. Поэтому проверяйте совместимость перед покупкой. Скорость вращения шпинделя 5.400 об/мин, среднее энергопотребление до 2,1 Вт, скорость передачи данных до 140 Мбайт/с, гарантия два года. См. подробные спецификации.

Внимание: возможно, более выгодным вариантом станет покупка внешнего Seagate Basic с данным накопителем (см. ниже).

Купить Seagate Barracuda ST5000LM000 за 12.000

Внешние накопители

Внешний накопитель можно легко сделать самому, достаточно купить бокс для 2,5" или 3,5" жесткого диска с нужным интерфейсом, после чего установить HDD самостоятельно. Сегодня наиболее распространены боксы с подключением USB, причем поддерживаются разные стандарты: USB 3.2 Gen1 (5 Гбит/с), USB 3.2 Gen2 (10 Гбит/с) или USB 3.2 Gen2x2 (20 Гбит/с). Но учтите, что на практике скорость будет упираться в производительность HDD, поэтому даже USB 3.2 Gen1 более чем достаточно, поскольку 5 Гбит/с это на практике около 500 Мбайт/с, а жесткий диск намного медленнее.

Как правило, боксы для 2,5" жестких дисков не требуют дополнительного питания, но для вариантов под 3,5" HDD оно необходимо. Максимальная емкость 2,5" HDD составляет 5 Тбайт, поэтому более емкие модели опираются на 3,5" HDD.

3.500 и 1 Тбайт - Seagate Backup Plus Slim Portable Drive

Внешний HDD Seagate Backup Plus Slim Portable Drive с подключением USB 3.2 Gen1 и емкостью 1 Тбайт имеет компактные габариты 114,8 x 78 x 11,7 мм и вес 126 г. Гарантия составляет два года. Внутри, по неофициальной информации, используется Seagate ST1000LM035, приведенный выше. Хороший вариант для переносного накопителя, но при небольшой доплате выгоднее взять емкость 2 Тбайт. См. подробные спецификации.

Внимание: накопители Backup Plus скоро исчезнут из розницы, их заменит линейка Seagate One Touch HDD. Так что с покупкой по выгодной цене стоит поторопиться.

Купить Seagate Backup Plus Slim Portable Drive 1 TB за 3.500

4.800 и 2 Тбайт - Seagate Backup Plus Slim Portable Drive

В емкости 2 Тбайт самой выгодной покупкой оказывается та же линейка Seagate Backup Plus Slim Portable Drive с габаритами 114,8 x 78 x 11,7 мм, весом 126 г и подключением USB 3.2 Gen1. Гарантия два года, внутри (неофициально) используется Seagate ST2000LM007, рассмотренный выше. Цена 1 Тбайт составляет 2.400 . См. подробные спецификации.

Внимание: накопители Backup Plus скоро исчезнут из розницы, их заменит линейка Seagate One Touch HDD. Так что с покупкой по выгодной цене стоит поторопиться.

Купить Seagate Backup Plus Slim Portable Drive 2 TB за 4.800

7.000 и 4 Тбайт - Seagate Backup Plus Portable Drive

С емкостью 3 Тбайт выгодных вариантов нет, чего нельзя сказать о 4 Тбайт. Линейка Seagate Backup Plus Portable Drive с подключением USB 3.2 Gen1 использует 2,5" HDD Seagate с толщиной 15 мм. Причем покупать внешний накопитель дешевле, чем 2,5" HDD отдельно. Цена 1 Тбайт всего 1.750 . Корпус довольно компактный 114,5 x 78 x 20,5 мм, вес 247 г. По неофициальной информации, внутри установлен ST4000LM024. Гарантия составляет 2 года. См. подробные спецификации.

Внимание: накопители Backup Plus скоро исчезнут из розницы, их заменит линейка Seagate One Touch HDD. Так что с покупкой по выгодной цене стоит поторопиться.

Купить Seagate Backup Plus Portable Drive 4 TB за 7.000

8.000 и 5 Тбайт Seagate Basic

Еще один очень любопытный накопитель в линейке Seagate Basic на 5 Тбайт. Габариты 117 x 80 x 20 мм немного больше Backup Plus Portable, как и вес 270 г, но не принципиально. Подключение тоже осуществляется через USB 3.2 Gen1, гарантия всего 1 год. Цена в расчете на Тбайт приятно радует всего 1.600 . Внутри, по неофициальной информации, установлен ST5000LM000. См. подробные спецификации.

Купить Seagate Basic 5 TB за 8.000

10.000 и 6 Тбайт - Seagate Backup Plus Hub

С емкостью больше 5 Тбайт уже приходится переходить на внешние боксы в формате 3,5". И здесь выгодным предложением является Seagate Backup Plus Hub 6 TB STEL6000200 с ценой 1 Тбайт всего 1.667 . Подключение все то же USB 3.2 Gen1, габариты 41 x 198,1 x 118 мм, вес 1,06 кг, в качестве бонуса встроен аккумулятор и два порта USB для зарядки или подключения устройств (по сути, USB-концентратор). Внутри, по неофициальной информации, используется HDD Barracuda ST6000DM003. Гарантия составляет 2 года. Необходимо дополнительное питание.

См. подробные спецификации.

Купить Seagate Backup Plus Hub 6 TB за 10.000

11.700 и 8 Тбайт - Seagate Expansion Desktop Drive

В емкости 8 Тбайт мы нашли более выгодную линейку Seagate Expansion Desktop Drive, которая в варианте STEB8000402 дает стоимость 1 Тбайт всего 1.470 . Габариты составляют 176 x 120,6 x 36,6 мм, вес 950 г. Подключение USB 3.2 Gen1. По неофициальной информации внутри установлен ST8000DM004. Гарантия составляет 2 года. Необходимо дополнительное питание. См. подробные спецификации.

Купить Seagate Expansion Desktop Drive 8 TB за 11.700

17.400 и 12 Тбайт - Seagate Backup Plus Hub

С емкостью 10 Тбайт мы не обнаружили выгодных предложений, поэтому сразу же переходим к варианту на 12 Тбайт - Seagate Backup Plus Hub STEL12000400. Цена терабайта стала еще более привлекательной 1.450 . Подключение все то же USB 3.2 Gen1, габариты 41 x 198,1 x 118 мм, вес 1,06 кг, в качестве бонуса встроен аккумулятор и два порта USB для зарядки или подключения устройств (по сути, USB-концентратор). Гарантия составляет 2 года. Необходимо дополнительное питание. См. подробные спецификации.

Купить Seagate Backup Plus Hub 12 TB за 17.400

19.200 и 14 Тбайт - Seagate Expansion Desktop Drive

С увеличение емкости еще на 2 Тбайт до 14 Тбайт более выгодной вновь становится линейка Seagate Expansion Desktop Drive, а именно накопитель STEB14000400. Мы получаем цену 1 Тбайт всего 1.371 . Габариты составляют 176 x 120,6 x 36,6 мм, вес 950 г. Гарантия составляет 2 года. Необходимо дополнительное питание. См. подробные спецификации.

Купить Seagate Expansion Desktop Drive за 19.200

25.500 и 16 Тбайт - Seagate Expansion Desktop Drive

Еще 2 Тбайт емкости дали максимальный вариант среди внешних HDD - накопитель Seagate Expansion Desktop Drive STEB16000400 на 16 Тбайт. Однако цена 1 Тбайт повысилась до 1.600 . Так что брать накопитель на 16 Тбайт имеет смысл только в том случае, если емкости 14 Тбайт будет недостаточно. Габариты составляют 176 x 120,6 x 36,6 мм, вес 950 г. Гарантия 2 года. Необходимо дополнительное питание. См. подробные спецификации.

Купить Seagate Expansion Desktop Drive за 25.500

Какой накопитель выбрать?

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

Среди обычных HDD 3,5" формата лидером до емкости 8 Тбайт включительно была линейка Barracuda. Младшие HDD работают со скоростью вращения шпинделя 7.200 об/мин, но в емкости 4-8 Тбайт она составляет уже 5.400 об/мин. Что вполне логично: младшие HDD могут использоваться и как системные в самых бюджетных ПК, где не получается докупить SSD. С емкости 4 Тбайт ценовой уровень уже подразумевает, что у пользователя есть средства на системный SSD. Поэтому HDD емкостью от 4 Тбайт будут работать не как системные, а для хранения данных. И здесь высокие обороты шпинделя не так важны.

В вариантах емкости 12-18 Тбайт самыми выгодными HDD неожиданно оказались серверные Exos. Здесь главный бонус гарантия 5 лет и сертифицированная нагрузка 24/7. Диски хорошо подойдут для NAS, а также и для домашних ПК, но уровень шума у них может быть сравнительно высоким. К бонусам можно отнести гелиевое наполнение, которое приводит к низкому энергопотреблению, несмотря на 7.200 об/мин.

В сегменте 2,5" жестких дисков мы привели экономичные варианты на 1 и 2 Тбайт для ноутбуков, а также на 4 и 5 Тбайт для внешних боксов. Но у последних следует учитывать высоту 15 мм, ограничивающую совместимость.

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