Привет! Меня зовут Максим Бабенко, я руковожу отделом технологий распределённых вычислений в Яндексе. Сегодня мы выложили в опенсорс платформу YTsaurus — одну из основных инфраструктурных BigData-систем, разработанных в Яндексе.

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

В Github-репозитории находится серверный код YTsaurus, инфраструктура развёртывания с использованием k8s, а также веб-интерфейс системы и клиентский SDK для распространённых языков программирования — C++, Java, Go и Python. Всё это — под лицензией Apache 2.0, что позволяет всем желающим загрузить его на свои серверы, а также дорабатывать его под свои нужды.

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

В чём проблема GIF?

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

Оптические атомные часы в университете Токио. Credit: H. Katori

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

Этим постом хочу открыть небольшую серию постов по материалам доклада на HighLoad++-2008. Впоследствии весь текст будет опубликован в виде одной большой PDF-ки.

Введение

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

Корпорации как люди

“Корпорации не существуют ради людей. Они не существуют ради великих идей. Они существуют исключительно ради денег”. Я любил так говорить, объясняя какой-нибудь очередной затейливый поворот истории Intel. Действительно, далеко не все решения поддаются объяснению с чисто технологической точки зрения. Соображения бизнеса играют не меньшую роль. Также надо принимать во внимание внутреннюю политику, оргструктуру и массу других факторов. Корпорация напоминает живой организм cо своей внутренней логикой, зачастую противоречивой. Сегодня может быть так, а завтра по-другому. Наблюдая за развитием ведущих мировых IT-компаний в течение примерно четверти века я пришел к выводу, что между корпорациями и людьми можно провести некоторые аналогии. Сегодня я попытаюсь проиллюстрировать эту мысль, сравнивая Intel c такими it –гигантами, как IBM, Microsoft, Apple и Huawei. Как и люди компании обладают своим “темпераментом” (о котором можно судить например по волатильности курса акций :)) “характером”, “возрастом”… Даже от места “рождения” кое что зависит. Ну вот, например IВM – корпорация восточного побережья США. С глубокой иерархией, склонностью к дипломатии и близким к европейскому менталитетом. В то время как Intel (да наверно и Microsoft) типичные компании “дикого Запада”, в методах себя особенно не стесняющие. Однако сегодня я бы хотел сосредоточиться на том, как меняются корпорации с течением времени. Как они проходят периоды роста, расцвета, зрелости и ... перерождения (хотя и не все).

Это - продолжение (но еще не окончание!) первой главы. Начало – здесь.

Linpack – как важнейшее из искусств

Второй важнейший “культ”, который определял развитие серверной архитектуры на протяжении десятилетий – это “сакрализация” Linpack. Сам бенчмарк представлен Джеком Донгаррой аж в 1979 году. Но  культовым статусом своим он обязан усилиями маркетологов из многих IT компаний (Intel, AMD, IBM, Nvidia, Fujitsu и тд). Linpack имеет массу неоспоримых достоинств.

• Это всего лишь ОДИН тест, в отличие от скажем SPEC CPU, где их 40 с хвостиком.

• К тому же (в отличие от SPEC) он совершенно бесплатный.

• Очень легко обьяснить, что Linpack делает. Он решает систему линейных алгебраических уравнений с числами двойной точности. Используется метод (P)LU разложения (Гаусса) с выбором ведущего элемента.

• В качестве результата Linpack выдает ОДНО число – измеренную производительность системы  в (гига -, тера -, пета -, экза) флопах. На основании Linpack строится мировой рейтинг суперкомпьютеров  TOP500 и российский TOP50.  Так же вычисляют эффективность (искушенные люди обращают на нее внимание), как отношение измеренной производительности к пиковой. Правда, в последнее время само понятие эффективности является несколько “размытым”, из-за того что в процессе исполнения теста тактовая частота может “плавать”.

• Linpack идеально параллелится (MPI, OpenMP и вообще что угодно) и векторизуется.

• И наконец Linpack обеспечивает практически полную (>90%) загрузку вычислительных устройств. В то время как обычные приложения редко показывают больше 20.

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

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

Газета "Коммерсантъ" опубликовала важный материал "Британия морозит «Байкал». Российские процессоры лишаются доступа к технологиям". К сожалению, авторы заметки никогда не видели то, о чем они написали, то бишь semiconductor IP, и не понимают его природы. Зато его видел я. Поэтому я решил написать к их заметке своего рода толкование:

1. Что именно британские компании ARM и Imagination продают российским лицензиатам, таким как Байкал? (Спойлер: не патенты, хотя патенты в картину входят)

2. Чем Apple отличается от Байкала в лицензировании semiconductor IP?

3. Сколько стоят лицензии на ядра и сколько стоит архитектурная лицензия?

4. Как компания-разработчик semiconductor IP может обнаружить, что произведенный кем-то чип использует ее ядро?

5. Были ли прецеденты подобных высоких отношений с китайскими компаниями?

6. Почему в статье упоминается МЦСТ (Эльбрус)? Они же вроде сами спроектировали CPU собственной архитектуры? (Спойлер: а GPU?)

7. Могут ли британские патенты стать проблемой для разработчиков российcких ядер с архитектурой RISC-V?

8. Что логично ожидать от российских полупроводниковых стратегов?

Два года назад я написал на хабре статью Как живется в США «неайтишникам», которая собрала 194 000 просмотров, 561 комментарий и вошла в список лучших статей 2020 года. И вот, два года спустя я решил пробежаться по тем же тезисам, чтобы провести некий срез, как изменилась обстановка в США и мое место в ней, особенно в свете последних событий.

Про жизнь, траты, поиск и смены работы и перспективы. Мне 38, я по образованию биотехнолог, семья — два человека, английский язык — так себе. Живу в Северной Каролине почти два года. Обещаю без политики и максимально объективно.

На протяжении всей жизни мне приходится экономить вычислительные и сетевые ресурсы: сначала были компьютеры с 300 кГц (кило — не гига!) и 32 Кбайт RAM, интернет по dial-up. Потом я решал олимпиадные задачки. Теперь имею дело с терабайтами трафика и 50 млрд событий в сутки. И хотя современные телефоны в 1 000 раз мощнее любого оборудования двадцатилетней давности, я до сих пор оптимизирую. Думал даже, что это со мной что-то не так. Но потом понял, что все постоянно что-нибудь оптимизируют. 

Эта статья в меньшей степени о том, почему нужно бороться за производительность, и в большей о том, на что сейчас стоит заменить устаревший стек из JPEG, JSON, gzip и TCP — и как это сделать. 

Спойлер: у нас есть решение и мы его не только показываем — ссылки на open source в конце статьи.

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

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

• Собираем все данные по портфелю и по всем операциям через Tinkoff API.

• Строим огромную Excel таблицу со всеми данными.

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

• Пытаемся понять, что нам с этим делать.

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

class Observable {
  listeners = new Set();
  subscribe(listener){
    this.listeners.add(listener)
  }
  unsubscribe(listener){
    this.listeners.delete(listener)
  }
  notify(){
    for(const listener of this.listeners){
       listener();
    }
  }
}

В redux-е этот паттерн применяется без всяких изменений  — пакет "react-redux" предоставляет функцию connect которая оборачивает компонент и при вызове componentDidMount вызовет subscribe() метод у Observable, при вызове componentWillUnmount()  вызовет  unsubscribе() а dispatch() просто вызовет метод trigger() который в цикле вызовет всех слушателей где каждый в свою очередь вызовет mapStateToProps() и потом в зависимости от того изменилось ли значение  —  вызовет setState() на самом компоненте. Все очень просто, но платой за такую простоту реализации является необходимость работать с состоянием иммутабельно и нормализировать данные а при изменении отдельного объекта или даже одного свойства оповещать абсолютно всех подписчиков-компонентов даже если они никак не зависят от той измененной части состояния и при этом в компоненте-подписчике необходимо явно указывать от каких частей стора он зависит внутри mapStateToProps()

(Нашёл в твиттере тред с очень крутым объяснением работы симметричных шифров. Его написал Colm MacCárthaigh один из основных контрибьюторов Apache. Я спросил разрешение Колма на перевод, он любезно согласился).

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

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

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

Вот простой пример. Допустим, у меня есть строка "Ovaltine" и я хочу её зашифровать. Я мог бы воспользоваться rot13 — очень простым олдскульным шифром Цезаря, который делает хоровод из букв, где a и z держатся за ручки, и заменяет каждую букву другой буквой алфавита, которая находится от заменяемой буквы на расстоянии 13 символов. Таким образом "O" превращается в "B", а "v" становится "i", в итоге "Ovaltine" превращается в "Binygvar". Конечно, это не очень безопасно. Это наивный пример, который очень легко взломать, так как атакующий может выяснить, какая буква встречается чаще всего (обычно в оригинальном тексте это "e") и найти оставшиеся буквы подобным образом.