преза по ИИ

то что будет развиваться:
1) Deep Learning
2) Capsule Neural Networks
3) Deep reinforcement learning (DRL)
4) Generative adversarial network (GAN)
5) Lean and augmented data
6) Probabilistic programming
7) Hybrid learning models
8) Automated machine learning (AutoML) 9) Digital twin
10) Explainable AI
11) AI Chatbots
12) AI Accelerators

Я боюсь не того компьютера, который пройдет тест Тьюринга, а того, который его намеренно завалит...

Обмануть нейросеть
- Adversarial training (состязательное обучение)
- вредоносные примеры
- универсальное искажение
- PIXEL attack for fooling deep neural networks
- The Adversarial Patch
- специальные очки
- Дорожные знаки - обманки

https://www.youtube.com/watch?v=IY69r79iIJU

#prog #rust

Пара слов о трейте Copy.

Во-первых, это один из "магических" трейтов, помечен атрибутом #[lang = "copy"]. Компилятор проверяет, что если тип тем или иным способом задекларирован как Copy, то и всего его поля должны быть Copy. Следующий код не компилируется:

#[derive(Clone, Copy)]
struct StringHolder(String);

Ошибка:

error[E0204]: the trait `Copy` may not be implemented for this type
--> src/lib.rs:1:17
|
1 | #[derive(Clone, Copy)]
| ^^^^
2 | struct StringHolder(String);
| ------ this field does not implement `Copy`

Во-вторых, один и тот же тип не может реализовывать Copy и Drop одновременно. Скажем, следующий код не компилируется:

#[derive(Clone, Copy)]
struct Primitive;

impl Drop for Primitive {
    fn drop(&mut self) {}
}

Ошибка:

error[E0184]: the trait `Copy` may not be implemented for this type; the type has a destructor
 --> src/lib.rs:1:17
  |
1 | #[derive(Clone, Copy)]
  |                 ^^^^ Copy not allowed on types with destructors

Так как полноценных negative trait bounds в Rust всё ещё нет, ограничение Copy можно использовать как более сильную замену ограничению !Drop.

В-третьих, как сказано в документации к Copy, "Copies happen implicitly, for example as part of an assignment y = x. The behavior of Copy is not overloadable; it is always a simple bit-wise copy.". С другой стороны, Clone является супертрейтом Copy, и наличие реализации Copy не мешает вызывать .clone() явно. Однако, в отличие от Copy, Clone::clone в принципе может вызывать любой код. Поэтому, в частности, технически замена в итераторной цепочке .cloned() на .copied() является ломающим изменением, даже если элементы итератора реализуют Copy.

Продемонстрирую на примере:

use std::cell::Cell;

struct Counter<'a>(&'a Cell<u32>);

impl Clone for Counter<'_> {
    fn clone(&self) -> Self {
        self.0.set(self.0.get() + 1);
        Self(self.0)
    }
}

fn main() {
    let n = Cell::new(0);
    let arr = [Counter(&n), Counter(&n), Counter(&n)];
    arr.iter().cloned().for_each(drop);
    println!("`Counter::clone` called {} times", n.get());
}

Если запустить этот код, то он напечатает `Counter::clone` called 3 times. Теперь добавим к определению Counter аннотацию #[derive(Copy)] и допишем в main тот же код, что там есть, но с заменой .cloned() на copied():

fn main() {
    // ...

    let n = Cell::new(0);
    let arr = [Counter(&n), Counter(&n), Counter(&n)];
    arr.iter().copied().for_each(drop); // изменение в этой строке
    println!("`Counter::clone` called {} times", n.get());
}

Код теперь выводит:

`Counter::clone` called 3 times
`Counter::clone` called 0 times

Берегите себя и не пишите, пожалуйста, в Clone::clone что-то помимо собственно клонирования.

https://habr.com/ru/post/240405/ старая статья голопом по европам про хадуп и почти всю его инфру
- HDFS
- MapReduce, Spark, Tez
- Hive, Impala, Shark, Spark SQL, Drill, HBase
- Kafka
- Spark Streaming
- Mahout, MLlib
- Parquet, ORC, Thrift, Avro
- ZooKeeper
- Hue
- Flume
- Sqoop
- Oozie
- Azkaban

== Форматы файлов в больших данных: краткий ликбез
https://habr.com/ru/company/mailru/blog/504952/
- Avro VS Parquet
Avro = хранит по строкам
Parquet = хранит по столбцам
Parquet лучше подходит для аналитики, = чтение эффективнее чем запись.
Avro записывает эффективней чем Parquet.
Avro лучше с эволюцией схем. Parquet поддерживает только добавление схемы
Parquet идеально подходит для запроса подмножества столбцов в многоколоночной таблице.
Avro подходит для операций ETL, где мы запрашиваем все столбцы.
- ORC VS Parquet
Parquet лучше хранит вложенные данные.
ORC лучше приспособлен к проталкиванию предикатов (predicate pushdown).
ORC поддерживает свойства ACID.
ORC лучше сжимает данные.

GCC ПОД КАПОТОМ
https://www.youtube.com/watch?v=HBFA6dKW7qE
- pre-processing
- compiler
- assembler
- linker

== Базы данных в современной IIoT-платформе
https://www.youtube.com/watch?v=wigSv2_zWBU&feature=youtu.be

прототип
* tarantool as db + app seerver
* lua - как язык для хранимые процедуры
* все данные в памяти

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

новая версия
- kubernates
- микросервисы
- стэйтлес и стейтфул приложения

требования к базе:
- ACID + строгая консистентность
- горизонтальное масштабирование на запись и чтение
- высокая доступность
- хранение больших обьемов данных
- хорошая производительность

Метаинформация (реляционные, правятся редко = CA = один мастер, много слэйвов)
* метаинформация, устройства, настройки, правила
* нужна поддержка деревьев с произвольной длиной и шириной
* нужна транзакционная модификация
* быстрый обход
=> Tarantool = это фрэймворк для построения базы данных в нужном виде

Данные от устройств (AP)
* показания датчиков, телеметрия. служебная информация
* Time Series
* OpenSource
* Бесплатный кластер
* хорошее сжатие
* успешная эксплуатация
=> Clickhouse

Clickhouse
= колоночная база данных
= кластер
= шардирование
= SQL
+ успешный опыт
- производительность на запись => буферизация записи и батч запись => Задержки
- производительность на чтение => кэш для данных за период

требования к Кэш бд = AP = много мастеров
- производительность
- горизонтальное масштабирование на чтение и на запись
- высокая доступность
- средства аналитики
- ттл
- персистентность
=> Tarantool + устаревание данных на хранимых процедурах

Требования к БД для состояний
- горизонтальное масштабирование на чтение и на запись
- высокая доступность
- отказоустойчивость
- консистентность на уровне документа
- можно пожертвовать общей консистентностью
- можно пожертвовать ACID транзакциями
=> MongoDB, Redis, Tarantool

Tarantool
= быстрое хранилище K-V
= фрэймворк для создания бд
= хранимые процедуры

= кафка как буфер перед кликхаусом. раз в секунду пушат в бд из буфера

== Greenplum: от двух до сотен серверов
https://youtu.be/FXij7xWqlsc

Greenplum = аналитическая СУБД
* Postgres based
* Opensource

+ сложные запросы, обрабатывающие большие обьемы, без знания какие запросы будет делать аналитик
+ ETL/ELT
+ Эффективное соединение больших таблиц = Ad-hoc запросы
+ Работа с индексами
+ Дата сайнс
+ Аналитические функция на PL
+ Ad-hoc аналитика
+ скорость при подключении нового кластера не падает, а ростет
+ партиционирование
+ одна таблица может содержать несколько партиций
+ партиции могут быть находится на разных устройствах, разного типа, сжатия и тп
+ транзакционирование на уровне БД
+ само разбивает на разные стораджи и строит внутренние запросы и само ходит в разные системы
== КлАССИЧЕСКИЙ МАП РЕДЬЮС НО
+ в транзакциях
+ SQL
+ и в разы проще для пользователя, так как он и не знает что это мап-редьюс
+ выделение ресурсов ядра под конкретные процессы явно, для конкретных юзверей
+ безопасность, группы, роли, права на обьекты
+ LDAP
+ SSL - от клиента к мастеру и от мастера к сегментам
+ Row-Level security
+ бэкапы делаются паралельно на всех сегментах

Схемы хранения данных
+ звезда
+ снежинка
+ Data Vault

Гринплан не ГЕО-распределенная система. он должен стоять в одном ЦОДе

Консистентность самое главное для гринплам

РАзрабатывался как замена терадаты, терадата быстрей, но все с терадаты уходят

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

== Безопасность и СУБД
https://youtu.be/n-54j9FHaMU

1) защищаем подключение

Сначала надо выяснить:
- 1 бизнес пользователь = 1пользователь в СУБД ?
- доступ к данным только через апи ?
- СУБД выделена в отдельный сетевой сегмент ?
- использует пулл соединений ?

первое что можно поменять
- db firewall
- парольные политики
- обогащайте контекст сессии в нужной иформации
- SSL (если нет сетевого разграничения)

Почему SSL Не оч хорошо:
- нагрузка на ЦПУ
- увеличение таймингов
- уменьшение TLS
=> На самом деле небольшие нагрузки не дают оверхэда
- Trust, md5 аутентификация

2) Аудит
для Postgres есть дефолтный
но есть и`pgaudit`
обязательно смотрим на pgbench

3) ограничение доступа к данным
- шифрование и обфускация процедур и функций (Wrapping)
- ограничение видимости данных по строкам (RLS)
- редактирование отображаемых данных (masking)
- разграничение доступа Security DBA / app dba/ dba
- ограничение доступа к файлам на уровне ФС
- мандантный доступ
- очистка паматия
- end2end шифрования
- шифрование данных

pgcrypto
- взять ключ на сервере
- взять ОДНУ колонку из бд
- зашифровать
=> замедляется запрос в ~50раз
- НЕ серебренная пуля!!!

лучше end-to-end шифрование

в энтерпрайзе все решалось уже давно
в опенсорсе мало чего есть

== Архитектура S3: 3 года эволюции Mail.ru Cloud Storage
https://youtu.be/NEgm1nsv-qg

просто хороший доклад про то как ребята варили с3 в майлРу

nginx
api
meta db = tarantool
fs = paired files storage
pair db = tarantool

bucket
-- project
-- segment
-- credentials
-- billing
-- obj

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

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

Nginx
- через луа расширения для выделения отдельных сертификатов

== Гибридное облако с помощью K8s, которое заменит DBaaS
https://www.youtube.com/watch?v=jM4hL2u6JM0

How to Read Rust Functions, Part 1
https://www.possiblerust.com/guide/how-to-read-rust-functions-part-1

== Всё о Kubernetes на Bare Metal
https://www.youtube.com/watch?v=yGKI5JoKMUY

какое железо надо:
- малеьнике ноды лучше чем большие
- необходимо унифицированное управление (ilo, ipmi, cli)
- !!! 10G-сеть НЕОБХОДИМА
- быстрые диски для ETCD (в идеале nvme)

используют загрузу ос по сети сразу в ОЗУ (CoreOS, LTSP).

LTSP - это таже убунта но интересней

LINSTOR - Block Storage Management For Containers
- оркестратор а не кластерная фс
- проверенные технологии (DRBD, LVM, ZFS)
- надежность
- высокая скорость начтение и запись
- небольшие накладные расходы в отличие от CEPH
- готовые provisioner и драйверы в kubernates
- состоит из двух компонентов: Controller и Satelite
- DRBD9 для репликаций
- неделимость ресурса
- разделение сетей
- планирование размещения (AUX-properties)
- каждый ресурс - это отдельный независимый DRBD-кластер
- поддержка разных бэкэндов (ZFS, LVM, Thin-LVM)
- поддержка шифрования томов

ReadWriteMany
запуск NFS сервера внутри кубернетеса
- используйте NFSv3 (стейтлес, легче переживает падения сервера и быстрей востанвливается) а не NFSv4 (стейтфул)
- soft - вслучае потери подключения вернет ошибку (ожидается!!!!)
- hard (default) - в случае потери подключений заморозит I/O
- https://github.com/ehough/docker-nfs-server готовый nfs сервер

Fencing
- механизм который ГАРАНТИРОВАННО убивает упавшую ноду. обеспечив востановление ресурсов на других нодах
- использует ILO, IPMI, управляемые UPS или другие способы изоляции сбойной ноды
- имеется большое количество гтовых агентов от clusterlabs
- есть некий fencing-controller который следит за нодами в кубернетес
- как только нода переходит в NotReady запускается скрипт
- скрипт перегружает ноду и при помощи fencing-агента
- если скритп завершился успешно, f-controller удаяет ноду из кластера (или пересоздает ее)
- кубер, убедившись, что требуемые ресурсы больше нигде не используются, перезапускает поды на оставшихся нодах
- https://github.com/kvaps/kube-fencing

Сеть
- единая L2-сеть с TRILL (network fabric) по типу динамической маршрутизации но на L2
- 10гб подключение к каждой ноде
- отсутсвие динамической маршрутизации между нодами
- отдельный VLAN под data-network

Сеть подов
- единая L2сеть с TRILL
- отдельный VLAN под поды
- плагин бридж (bridge CNI + обвязка)
- каждая нода является шлюзом по умолчанию дл яподов, запущенных на ней
- нет необходимости прописывать маршруты
- отсутсвие оверлеев
- https://github.com/kvaps/bridget

Сеть сервисов (kube-proxy)
- IPTables - по умолчанию, работает из коробки
- IPVS = быстрей, требует IP-адрес на локальном интерфейсе (который может сломать маршрутизацию к ноде). ПРОСТОЙ ДИЗАЙН и ПОНЯТНЫЙ ВЫВОД

Организация доступа извне
Pipework
- позволяет прокинуть сетевой интерфейс прямо в под
- не нативно (кубер ничего не знает об этих изменениях)
MetalLB
- использует родные для кубера абстракции
- контроллер позволяет автоматизировать IP адресов
- Speaker поддерживает L2 и BGP режимы

Ansible
- управление физическими нодами
- сбор инфы о нодах
- обнолвение DNS/DHCP записей

Kubeadm лучше чем Kubespray
- деплой/обновление кубера

Ksonnet
- деплой приложений в кластер
- декларативно описывает приложение

OIDC-авторизация
- rolebindings можно настраивать как на пользователей так и на группы пользователей
- все кластеры можно описывать в одном kubeconfig
- переключение между кластерами работает очень просто
- можно использовать keycloack-gatekeepr для защиты простых сервисов
- для начальной аутентификации можно использовать kuberos

== Управление конкурентным доступом. Изоляция транзакций
https://postgrespro.ru/docs/postgresql/9.6/transaction-iso#xact-serializable

вначале юзать Serializable, разобравшись что делаешь - можно понизить изоляцию. меньше проблем, если не знаешь

== Evolution of the x86 context switch in Linux
https://www.maizure.org/projects/evolution_x86_context_switch_linux/

== Архитектура операционной системы UNIX
http://www.linuxlib.ru/unixarch/contents.htm

опять наткнулся и всеж положу тут. что бы таки начать читать

== Dmitry Stolyarov (Flant) on Introduction to werf: Another view on GitOps
https://www.youtube.com/watch?v=WetiGGcNZGw

== WERF - What you Git
is what you get!
https://ru.werf.io/

== Лучшие практики CI/CD с Kubernetes и GitLab (обзор и видео доклада)
https://habr.com/ru/company/flant/blog/345116/

== werf — наш инструмент для CI/CD в Kubernetes (обзор и видео доклада)
https://habr.com/ru/company/flant/blog/460351/
https://www.youtube.com/watch?v=cK3ackGUTLw
https://www.youtube.com/watch?v=XXAjvsIvuDg

== WERF Automates Kubernetes-based GitOps from the Command Line
https://thenewstack.io/werf-automates-kubernetes-based-gitops-workflows-from-the-command-line/

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

== шикарный сборкник алертов прометеуса
https://github.com/samber/awesome-prometheus-alerts

== ПОЛНАЯ ЗАЩИТА СМАРТФОНА И МЕССЕНДЖЕРОВ ОТ СПЕЦСЛУЖБ И ЖЕНЫ
https://www.youtube.com/watch?v=xpaY958gMKY

Приватность - невозможно прочитать переписку

Анонимность - невозможно установить автора

лучше гарантированная анонимность

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

поставить код на симкарту

или Е-СИМ

все всегда попадает в интернет. рано или поздно

== СРОЧНО ВЫБРОСЬТЕ АЙФОН: СОВЕТЫ ТОПОВОГО БОРЦА С ХАКЕРАМИ
https://www.youtube.com/watch?v=iQE2G0mMR9I

впн это всего лишь тоннель
снифы видят только две точки

НЕ ДОВЕРЯТЬ ЛЮБЫМ КОММЕРЧЕСКИМ ВПНам

если впн, то только сами настраивайте все, сами шифруете, сами обновляете, и сами настраиваете логирование

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

мак иногда можно менять на железе

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

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

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

Вирусы для маки существует
Маскируются под площадки крипты или торговли

Если программа требует икс-код, то надо насторожиться

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

Микрофоны и Камеры это уязвимости

Кернелы линукса долго необновляемые - уязвимость

Пока нет законов, которые заставляли производителей обновлять сертификаты и безопасность протоколов

телеки - это линукс или андроид, который не обновляет никто

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

пока нет квантовых компьютеров доступных - можно не вообще париться.

хэш 256символов подобрать нереально. забудьте.

самое слабое звено - человек и его пороки

мессенжеры вполне ок

ряд мессенжеров вскрыты

там где защита смс - там дыра. перехватывают даже на уровне оператора