Июнь. Пора считать ракетки — «их осталось только двое»

Вячеслав Ермолин — 1 июля 2020
Результаты пусковых программ за июнь 2020 года.

Статистика запусков с начала года (июнь). Легенда в конце текста.

Июнь 2020 года стал месяцем США и Китая. Больше никто не смог (хотя и собирались) осуществить запуск. Без аварий. И мало.

Все запуски июня. Семь штук.

Итоги июня.

Количество запусков уменьшилось по сравнению с маем. Всего семь. И только из двух стран — США и Китай. Остальные пока восстанавливаются после карантина и остановки работы космодромов и предприятий отрасли.

■ США. Четыре запуска. Все «новые частники»! SpaceX и Rocket Lab. SpaceX напрягся и попытался выполнить свой план — два Starlink в месяц. Их и было два, но один пришел переносом с мая. Не получилось в этот раз. Еще запуск навигационного спутника по заказу американских военных. Rocket Lab запустила что-то мелкое военное.

■ Китай. Три запуска. Очередные спутники ДЗЗ. Плюс навигационный спутник — завершение строительства штатной группировки. Китайцы свое обещание сформировать навигационную систему к 20-му году выполнили! Редкий случай в современной космонавтике (Европа тоже обещала к 20-му).

■ Россия, Европа, Индия, Иран, и другие… ничего не запустили… возвращали к жизни покинутые на время карантина космодромы и заводы.

Рост запусков и наращивание темпов переносится опять на будущее. Ждем.

Амбициозные планы на 20-й год для напоминания (которые останутся уже только мечтой:

Прогнозы (неофициальные) на 2020 год

Легенда к инфографике.

Hi-rez статистика
Hi-rez ракетки

Let's block ads! (Why?)

Разбор: почему власти США угрожают китайским компаниям насильным снятием их акций с биржевых торгов

В США уже месяц обсуждают новую законодательную инициативу – Holding Foreign Companies Accountable Act. Этот законопроект обязывает иностранные компании доказывать тот факт, что зарубежные правительства не владеют в них какой-либо долей. Если сделать это не удастся, или американские регуляторы не смогут провести аудит, наказанием может стать делистинг, то есть насильное снятие акций компании с торгов на биржах в США.

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

Что случилось

В конце мая сенат США единогласно поддержал законопроект Holding Foreign Companies Accountable Act. Согласно тексту документа, от иностранных компаний будут требовать прозрачности для проведения аудита и предоставления доказательств отсутствия контроля со стороны зарубежных правительств.

Если компания не сможет четко доказать такой факт, или Наблюдательный совет по ведению финансовой отчетности публичных компаний (Public Company Accounting Oversight Board, PCAOB) не сможет провести аудит компании на протяжении трех лет подряд – акции такой компании будут запрещены к обращению на биржах в США.

По словам авторов законопроекта, в настоящий момент правительство Китая не позволяет PCAOB проводить аудит компаний, зарегистрированных в Китае и Гонконге. Всего же на биржах США торгуются акции 224 компаний из стран, где существуют аналогичные препятствия – большинство из них китайские. Общая капитализация таких компаний составляет больше $1,8 трлн.

В ответном заявлении Китайская комиссия по регулированию акций (аналог американской SEC) заявила о своем непринятии «подобных актов политизации регулирования акций». Также в тексте говорится о том, что китайские регуляторы прикладывают максимум усилий к большей кооперации с иностранными коллегами для проведения аудитов.

Как новый закон может повлиять на китайский бизнес

Ужесточение правил в США может негативно повлиять на планы привлечения средств на бирже многих крупных китайских компаний. К примеру, аналитики Bloomberg предсказывают сложности с IPO компании-владельца TikTok ByteDance и Ant Financial миллиардера Джека Ма.

При этом, обсуждение законопроекта идет уже на протяжение некоторого времени, поэтому китайские компании готовятся к его возможному принятию. Для этого многие из них уже провели IPO в Гонконге.

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

Пока что акции китайских компаний Alibaba, Baidu и других торгуются на американских биржах без ограничений. А это значит, что купить их можно и из России можно без необходимости открывать отдельный брокерский счет у зарубежных брокеров. С помощью рынка иностранных ценных бумаг Санкт-Петербургской биржи инвесторы могут покупать 500 ликвидных акций ведущих компаний всех секторов мировой экономики, в том числе все акции индекса S&P 500.

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

Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Let's block ads! (Why?)

Google просит ИБ-сообщество отказаться от терминов Black\White Hat и заменить их на нейтральные

4 июля 2020 года изданию ZDNet стало известно, что при обсуждении моментов проведения августовской онлайн ИБ-конференции по безопасности Black Hat (Black Hat USA 2020) ИБ-исследователь Google Дэвид Клейдермахер (David Kleidermacher), который также является вице-президентом по инженерным разработкам в Google и отвечает за безопасность Android и Google Play Store, поднял вопрос в сообществе о прекращении использования терминов «черная\белая шляпа» (Black\White Hat) и заменить их на более нейтральные, например, PITM и MITM.
Вот что написал в Twitter Клейдермахер после дискуссии на эту тему и его фактического отказа от участия в конференции Black Hat USA 2020.

Black hat and white hat are terms that need to change. This has nothing to do with their original meaning, and it’s not about race alone - we also need sensible gender-neutral changes like PITM vs. MITM.

— David Kleidermacher (@DaveKSecure) July 3, 2020

ИБ-сообщество достаточно эмоционально отреагировало на его призывы отказаться от использования терминов «черная шляпа» и «белая шляпа», сославшись на то, что эти два понятия, особенно «черная шляпа», не имеют ничего общего с расовыми стереотипами.

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

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

Ранее в начале июня 2020 года стало известно, что в репозиторий языка программирования Go внесены изменения с целью очистить документацию и исходные тексты от потенциально оскорбительных терминов whitelist/blacklist и master/slave.

Разработчики Google Chrome и Chromium также меняют в коде браузера термины blacklist и whitelist на более нейтральные названия — blocklist (блоклист) и allowlist (список разрешений).

Разработчики файловой системы OpenZFS в июне 2020 года объявили на GitHub, что переименовывают в коде проекта все используемые ими ранее термины slave и slaves на нейтральные названия. Вместо термина slave в большей части случаев теперь используется dependent (зависимый) или сокращение до dep, например, вместо local _slavedev теперь local _depdev.

12 июня 2020 года Генеральный директор GitHub Нат Фридман (Nat Friedman) заявил, что в компании уже начаты определенные действия по поводу замены термина master, обозначающего на платформе основную версию программного кода, на более нейтральное название, например, main.

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

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

Let's block ads! (Why?)

Как проходит телемедицинский приём? Два кейса от теледоктора

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

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

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

Хм… с этим освещением в рот заглянуть особо не получается. Надо хотя бы сориентироваться, к какой группе заболеваний это относится.
— Инфекция? Есть ли в твоём окружении кто-то с похожими симптомами?
— Обмен веществ? Как часто ходишь в туалет? А по-маленькому?
— Новообразование? По ночам как спишь? Потеешь?
Пожалуйста, встань, чтоб я видела тебя в полный рост. Стоп. Можешь встать ровно? А поближе к свету? Перенеси ноут к окну. У тебя всё время был такой живот? Нет, я не сказала, что толстый. Совсем-совсем не толстая ты, не обижайся, малыш. Боком повернись, пожалуйста.

B тот раз я так и не сумела поставить диагноз. Но нашла адрес коммьюнити-клиники, где студенты-медики ведут бесплатный приём неимущих. Я попросила Наташy обязательно обратить внимание медиков на ассимметрию живота. Он был как бы вдавлен с левой стороны и слегка выбухал или даже слегка провисал с правой. Мне показалось это необычным. А всё, что необычно, может оказаться важным для постановки диагноза. B тот момент я думала, что это могло быть увеличение печени. Xотя белки глаз и ладони у девушки жёлтыми не были (если не обманывало цветоразрешение). Если бы я находилась рядом с ней, то определить размеры печени с помощью пальцев и стетоскопа не составило бы никакого труда. Но между нами лежали тысячи километров.

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

Поражение у неё произошло примерно на уровне 9-11 грудного сегментa (Th9-Th11).
Поэтому мышцы живота, к которым отходили перфирические нервы из поражённых корешков, потеряли тонус и живот с одной стороны «провис». Лечение этого заболевания не самое сложное, но понадобились месяцы на восстановление работоспособности. Cейчас уже всё хорошо.

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

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

— Да я всё равно скоро домой лечу, отпуск давно уже нужен.

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

Телемедицина сейчас на слуху и многие компании работают над внедрением технологических приспособлений, которые призваны облегчить удалённый приём пациента. Но знаете, что? Я сейчас выскажу мысль, которая в сообществе гиков звучит наверное, крамольно: высокотехнологичная медицина основной части населения не нужна.
Вполне реально обеспечить хорошую медицину для большинства дёшево и сердито, тут работает правило 95%:
— В 95% случаев для правильной постановки диагноза нужен опрос и осмотр. Всё. Никакой сложной лабораторно-инструментальной диагностики. Элементарно — нужны только собственные глаза, уши, пальцы, мозг… ну и фонарик и самый простой стетоскоп.
— В 95% случаев (не обязательно тех же самых, что в первом пункте) заболевание либо самолимитировано (проходит само, лечи его или нет) либо протекает по известному алгоритму.

Именно благодаря этим 95% и процветает всякого рода комплементарная, традиционная или как её ещё называют, альтернативная медицина. Ритуалы её часто сложны и занимают определённое время. За это время хворь проходит сама, следуя естественному курсу событий. Но отличить последовательность от причинности обычному человеку сложно, а значит, что «я это испробовал и не знаю, как, но оно помогает».

Но в «нормальной», то есть доказательной медицине, ненужные назначения не приветствуются. Например, в Европе действует принцип ЭЦЭ: «эффективность, целесообразность, экономичность». То есть лечение должно не только иметь смысл, достигать своей цели, но и делать это не слишком дорогим способом. Поэтому наши люди так часто возмущаются европейской медициной: «я туда пошёл, а мне ибупрофен сунули и отправили восвояси, даже анализ мочи не сделали». В их представлении хорошая медицина — это общий анализ крови, мочи, флюорография и капельница. Где-то в комментариях мне уже писали о доценте(!), который в любом непонятном случае назначает общий анализ крови. Это неправильно. Всегда нужна рабочая гипотеза и тесты для её проверки. А не наоборот. Лечим ведь не цифры, не миллиграммы или миллимоли, а людей. Потому как чисто статистически: чем больше анализов назначишь, тем больше шансов на то, что какой-то из них будет не в рамках нормы. Границы норм основаны на стандартном отклонении и всегда есть такие 5%, у которых со здоровьем всё в порядке, но какой-то лабораторный параметр не вписывается в норму. Это опять правило 95% в действии.

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

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

Специалист не нужен в 95% случаев. Он нужен для тех проклятых пяти процентов, где всё может пойти совсем, совсем не по плану. И чтоб отличить эти самые пять от других. Дьявол — как обычно, в деталях. Есть состояния, когда лучше выслушивать лёгкие в определённом положении тела. Или нужно задержать дыхание на вдохе или выдохе. Есть техника, когда ставишь мембрану стетоскопа на ребро. Есть случаи, когда что-то услышал в сердце и сразу такой: «а дай-ка я ещё шейные сосуды прослушаю». Всё это задачи — не для телеметрического киоска. Услышал ослабление тона и сразу там постучал — ага, жидкость в плевральной полости. Вот почему единственный реально рабочий формат для телемедицины — это «врач-врач». Телемедицина — это ни разу не «я у мамы терапевт». На обоих концах провода должны сидеть люди в теме, и ещё один телемедицинский гаджет погоды не сделает.

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

Let's block ads! (Why?)

Как на интервью распознать начальника — самодура?

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

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

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

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

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

Корпоративные ценности

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

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

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

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

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

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

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

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

Реакция на ваши вопросы

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

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

Беспокоится стоит тогда, когда реакции нет, либо, когда она вялая и невнятная.

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

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

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

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

Так что молчат не только о мертвых.

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

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

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

Реакция на Ваше мнение

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

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

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

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

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

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

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

Тем не менее, некоторые моменты можно прояснить.

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

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

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

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

Резюме

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

1. Вам навязываю ценности и требуют их соблюдать
2. Все молчат. О начальнике, о компании. Уклоняются от разговоров и испытывают страх.
3. Вам озвучивают «правильное мнение» даже в той области, специалистом в которой вы являетесь.

Даже наличие одного из них – серьезный повод насторожиться. Впрочем, решать вам.

На Ютюбе много видео на эту тему. Вот одно из них.

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

Источник

Let's block ads! (Why?)

Последняя битва за Сингулярность

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

Считается также, что мы стоим на пороге сингулярности. Что вот-вот, осталось подождать еще пару десятилетий, и она случится. Однако пока никакого сильного ИИ нет. Различные новые технологии появляются, но относительно медленно. Прогнозы футурологов не спешат сбываться, а то и вовсе оказываются несбыточными мечтами. И всё происходящее выглядит так, как будто ничего особенного не случится — ни в ближайшее десятилетие, ни в ближайшее столетие… Неужели наши надежды напрасны? И можем ли мы что-то сделать, чтобы реально приблизить Сингулярность?
Примечание: В этой статье нет каких-то практических решений и предложений; нет ответов — есть только вопросы. Можно сказать, что данная статья не является самостоятельной, это своего рода обозначение проблемы и одновременно введение в серию статей или даже книгу. Но главное — это приглашение к размышлению и обсуждению.

Поле битвы — человек

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

Органы чувств

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

Самый широкий канал получения информации — зрение. Считается, что с помощью глаз мы получаем около 80% всей информации. По приблизительным оценкам, разрешение сетчатки каждого глаза составляет примерно 120-140 мегапикселей, частота восприятия — около 25 кадров в секунду. С точки зрения современных технологий, это чрезвычайно высокие показатели (можно оценить видеопоток как порядка 6 гигапикселей в секунду). Вы не найдете видеокамер с таким разрешением в продаже — если подобные камеры и существуют, то в единичных экземплярах, стоят огромных денег и применяются исключительно в научно-исследовательских задачах.

Слух обеспечивает нам около 16% всей информации. Человеческое ухо способно воспринимать сигналы с частотами от 16 до 20000 Гц и в достаточно большом диапазоне амплитуд — от 0 до «порога болевого ощущения» 120..140дБ. Также, звуковые импульсы, сменяющие друг друга с частотой более 16 Гц мы воспринимаем как непрерывный звук. Однако в отличие от зрения, слух почти «одномерен», поэтому объем информации, поступающей в мозг от органов слуха, несколько меньше чем от органов зрения.

Мозг

Мозг состоит из порядка 100 миллиардов нейронов. Для сравнения, в последних процессорах порядка 2 миллиардов транзисторов, и транзистор — гораздо более простая структура чем нейрон. Однако скорость передачи нервных импульсов между нейронами невелика: от 0.5 до 120 метров в секунду. В среднем, через один синапс проходит 10 импульсов в секунду, т.е. частота работы порядка 10Гц. Это чрезвычайно мало в сравнении с гигагерцовыми частотами современных процессоров.

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

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

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

Каналы ввода-вывода

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

Начнем со зрения

Средняя скорость чтения человека от 200 до 250 слов в минуту (для английского языка), 128-180 слов в минуту (для русского), в зависимости от языка (данные для не-иероглифических языков).
В символах средней считается скорость 1500 символов в минуту. Если условно принять один символ за один байт (в научной и технической литературе, которая нас в основном интересует, разных символов обычно больше чем в художественной, но все-же в неиероглифических языках мы примерно вмещаемся в байт) то получим канал 200 бит/сек. Это медленнее чем самые первые модемы!

Технологии скорочтения не на много увеличивают эту скорость. Например, президент США Джон Кеннеди мог читать со скоростью примерно 1200 слов в минуту, что соответствует примерно 800 бит/сек.

Скорость восприятия человеческой речи

Согласно исследованиям, оптимальный темп речи для чтения аудиокниг на английском языке соответствует 150—160 словам в минуту. Для личной беседы — 190 слов в минуту. Как видно, скорость примерно соответствует скорости чтения, так что использование аудиоканала никаких особых преимуществ не добавляет.

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

Скорость вывода информации

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

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

Абстрактное мышление

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

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

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

Почему так происходит? Биологически человек — все еще животное. Человеческий мозг по прежнему предназначен для обеспечения выживания особи и вида, преимущественно в дикой саванне. Человеческий мозг изначально не предназначен для чтения, набора текста, работы со сложными абстракциями. Наше зрение способно очень быстро обрабатывать огромные массивы природной визуальной информации — но это нужно для того чтобы быстро замечать хищников, притаившихся в джунглях, и другие опасности, а также чтобы находить разнообразную еду; но скорость нашего чтения медленнее чем самые первые модемы, выпускавшиеся в 80-х годах 20-го века! А скорость выдачи информации и того меньше.

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

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

Несовершенство биологической природы человека

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

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

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

Поле битвы — Цивилизация

Огромный объем знаний

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

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

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

Информационная революция

Одна из важнейших составляющих научно-технической революции — компьютерная революция, привнесла в наши жизни компьютеры и глобальную сеть интернет. Без преувеличения, Интернет — это прорыв такого же масштаба, как возникновение письменности когда-то. Считается, что человечество накопило 2 трлн гигабайт данных, а годовой объем интернет-трафика составляет порядка 3 зеттабайт. Доступ к Сети имеет 4,54 миллиарда пользователей, каждый из которых в среднем проводит в сети порядка 7 часов в день. Это фантастические цифры, однако что мы имеем в реальности?

Человекоориентированная информация

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

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

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

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

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

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

Лавина сложности

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

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

Одна молекула ДНК в среднем состоит из 100 миллиардов атомов. А биологическая клетка содержит в среднем около 100 триллионов атомов. Длина всех молекул ДНК двойного набора хромосом в одной клетке человека равна примерно 2м. Количество вариантов конформаций одной единственной молекулы типичного белка может быть больше, чем количество атомов во Вселенной (источник: Introduction to General, Organic and Biochemistry).

Некоторые примеры сложности

Вот как описывает биологическую сложность профессор Михаил Пантелеев

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

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

(источник: Победить старость, рак и инфаркты; Михаил Пантелеев о биологической сложности)

В 2005 году сотрудникам Лос-Аламосской национальной лаборатории удалось создать динамическую модель работы рибосомы, синтезирующей молекулу белка. Для этого потребовалось 768 микропроцессоров, работавших в течение 260 дней. За это время удалось «снять» 20 миллионов кадров, отражающих лишь 2 наносекунды из жизни рибосомы.
(источник)

В 2011 году китайские ученые создали симуляцию вируса H1N1 на атомарном уровне. Система на базе GPU Mole-8.5, в котором установлено свыше 2200 графических процессоров NVIDIA Tesla, способна симулировать 770 пикосекунд в день с шагом времени интегрирования в 1 фемтосекунду для 300 миллионов атомов или радикалов.
(источник)

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

Например, в 2013 году для симуляции 1 секунды работы 1% человеческого мозга (1,73 млрд нервных клеток и 10,4 трлн синапсов) потребовалось 40 минут на кластере из 82 944 процессоров 10-петафлопсного K computer.
(источник)

А в проекте моделирования мозга в 2018 году современный суперкомпьютер, состоящий из миллиона ядер ARM9, способных обрабатывать 200 триллионов операций в секунду, может моделировать в реальном времени лишь один процент от общего количества нейронов (1 млрд, а не 100 млрд).

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

В завершение

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

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

Let's block ads! (Why?)

[Перевод] Обзор технологий скроллинга

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

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

Технологии для реализации специфических механизмов скроллинга

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

▍CSS-свойство position: sticky

Если вам нужно, чтобы некий элемент не прокручивался бы вместе с остальным содержимым страницы, то при стилизации этого элемента достаточно применить свойство position: sticky. Это — простой и понятный приём, его поддержка встроена в современные браузеры. Но для того, чтобы это работало бы в IE и в некоторых мобильных браузерах, понадобится полифилл. Если вам интересна эта тема — взгляните на данный материал.

Синий элемент «упирается» в верхнюю часть контейнера и не прокручивается вместе с остальными элементами

Вот демонстрация такого скроллинга.

▍Эффект параллакса

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

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

Вот демонстрация эффекта параллакса.

▍Прокрутка с привязкой к определённым точкам

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

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

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

▍Плавная прокрутка

Плавный скроллинг поддерживается средствами браузера при прокрутке страницы до определённого раздела с использованием метода window.scrollTo() в JavaScript, или даже с применением CSS-свойства scroll-behavior. В настоящее время для реализации плавного скроллинга со сглаживанием движений колеса мыши требуются специальные JavaScript-библиотеки. Но при применении таких библиотек нужно обеспечить их нормальное взаимодействие с другими технологиями скроллинга. Кроме того, использование плавного скроллинга — это далеко не всегда хорошая идея.

Технологии скроллинга общего назначения

В настоящее время нет способа, применяя лишь CSS, запускать какие-либо анимации скроллинга общего назначения, основываясь на позиции прокрутки (хотя имеется предложение, в соответствии с которым в отдалённом будущем в нашем распоряжении могут появиться некие анимации, основанные на технологиях скроллинга общего назначения). В результате, если вы хотите анимировать элементы при скроллинге, вам нужно, как минимум, использовать некоторый объём JavaScript-кода для достижения требуемого эффекта. Существуют два метода применения JavaScript для анимирования элементов при скроллинге. Первый заключается в использовании API Intersection Observer, второй — в обработке события scroll.

▍Использование API Intersection Observer

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

▍Использование события scroll

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

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

Инструменты для создания механизмов скроллинга общего назначения

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

▍ScrollMagic

Библиотека ScrollMagic даёт нам сравнительно простой API, позволяющий создавать различные эффекты при скроллинге. Эта библиотека может работать совместно с различными библиотеками для анимации, наподобие GSAP и Velocity.js. Правда, в последние несколько лет эта библиотека недостаточно хорошо поддерживается. Это привело к тому, что была создана библиотека ScrollScene.

▍ScrollScene

ScrollScene — это, в сущности, обёртка, которая направлена на то, чтобы повысить удобство работы с библиотекой ScrollMagic и (или) с API IntersectionObserver. Здесь используется собственная версия ScrollMagic, которая отличается лучшей поддержкой, чем обычный вариант библиотеки. Тут имеются и дополнительные возможности, наподобие проигрывания видео и поддержки контрольных точек, влияющих на анимацию. Кроме того, эта библиотека использует GSAP.

▍ScrollTrigger

Библиотека ScrollTrigger — это официальный GreenSock-плагин для GSAP. Эта библиотека отличается большим набором возможностей, её API кажется мне самым простым из API существующих библиотек для скроллинга. Используя эту библиотеку, вы полностью контролируете то, где именно начинается и заканчивается анимация скроллинга, вы можете анимировать при прокрутке всё что угодно (WebGL, canvas, SVG, DOM), можете закреплять элементы на время выполнения анимации. Этим возможности данной библиотеки не ограничиваются. Кроме того, эту библиотеку поддерживает GreenSock, получить помощь по её использованию можно на форумах GreenSock.

▍Библиотека, достойная упоминания: Locomotive Scroll

Библиотека Locomotive Scroll не стремится к реализации столь же широкого набора возможностей, как другие библиотеки, о которых мы говорили. Её основная цель — реализация плавной прокрутки. Используя её, кроме того, можно анимировать некоторые свойства DOM-объектов, используя атрибуты data-*, или пользоваться обработчиком onscroll для анимирования объектов других видов.

Сравнение технологий и инструментов

Вот сравнение технологий скроллинга.
Вот сравнение рассмотренных библиотек.

Итоги

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

Я обычно, для настройки скроллинга, рекомендую использовать библиотеку ScrollTrigger. Она позволяет достичь всего, на что способен чистый CSS, а так же — многого другого. Эта библиотека берёт на себя заботу о браузерной поддержке тех или иных технологий, облегчает выполнение вычислений, что позволяет тому, кто её использует, просто заниматься своими делами.

Какие технологии вы используете при настройке скроллинга в своих проектах?

Let's block ads! (Why?)

Что нужно знать об архитектуре ClickHouse, чтобы его эффективно использовать. Алексей Зателепин (2018г)

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

Будут затронуты следующие темы:

• Как ClickHouse хранит данные на диске и выполняет запрос, почему такой способ хранения позволяет на несколько порядков ускорить аналитические запросы, но плохо подходит для OLTP и key-value нагрузки.
• Как устроена репликация и шардирование, как добиться линейного масштабирования и что делать с eventual consistency.
• Как диагностировать проблемы на production-кластере ClickHouse.

Видео:

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

Я ClickHouse занимаюсь недавно. До этого я несколько лет работал в Яндекс.Картах. Был прикладным разработчиком. Много там работал с базами данных, с Postgres, поэтому я еще вирусом ClickHouse не сильно заражен, я еще помню, что такое быть прикладным разработчиком. Но, в принципе, уже все довольно хорошо понимаю.

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

У нас есть некие события. Они постоянно приходят. Я тут выписал какие-то примеры. Вот Яндекс.Метрика – это сервис, для которого ClickHouse изначально создавался.

• Это какие-то действия пользователя на сайте.
• Реклама.
• Финансовые транзакции, покупки в магазинах.
• И DNS-запросы.

Что мы хотим с этими событиями сделать? Мы хотим о них сохранить информацию и что-то о них понять потом, т. е. построить какие-то отчеты, аналитику, потом на них посмотреть и что-то понять.

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

Для ClickHouse самое важное:

• Это интерактивные запросы. Что это такое? Это выполнение за секунды, а лучше меньше, чем за секунду. Почему это важно? Во-первых, когда Яндекс.Метрика показывает отчет, пользователь не будет ждать, если он загружается больше секунды. Но даже если вы, как аналитик, работаете с ClickHouse, с базой данной, то очень хорошо, если ответы на запросы тут же приходят. Вы тогда их можете много задать. Вы можете не отвлекаться. Вы можете погрузиться в работу с данными. Это другое качество работы.
• Язык запросов у нас SQL. Это тоже и плюсы, и минусы. Плюсы в том, что SQL декларативный и поэтому простой запрос можно очень хорошо оптимизировать, т. е. очень оптимально выполнить. Но SQL не очень гибкий. Т. е. произвольную трансформацию данных с помощью SQL не задать, поэтому там у нас куча каких-то расширений, очень много функций дополнительных. А преимущество в том, что SQL все аналитики знают, это очень популярный язык.
• Стараемся ничего заранее не агрегировать. Т. е. когда такую систему делаешь, то очень велик соблазн сначала подумать о том, какие отчеты нужны. Подумать, что у меня события будут поступать, я их буду потихоньку агрегировать и нужно будет показать отчет, я быстренько вот это все покажу. Но есть проблема такого подхода. Если вы два события слили вместе, то вы уже их ни в каком отчете больше не различите. Они у вас вместе. Поэтому чтобы сохранить гибкость, стараемся всегда хранить индивидуальные события и заранее ничего не агрегировать.
• Еще один важный пункт, который требуется от прикладного разработчика, который работает с ClickHouse. Нужно заранее понять, какие есть атрибуты события. Нужно их самому выделить, вычленить и уже эти атрибуты запихивать в ClickHouse, т. е. какие-то json в свободной форме или текстовые blob, которые вы просто берете и пихаете, и надеетесь потом распарсить. Так лучше не делать, иначе у вас интерактивных запросов не будет.

Возьмем пример достаточно простой. Представим, что мы делаем клон Яндекс.Метрики, систему веб-аналитики. У нас есть счетчик, который мы на сайт ставим. Он идентифицируется колонкой CounterID. У нас есть таблица hits, в которую мы складываем просмотры страниц. И есть еще колонка Referer, и еще что-то. Т. е. куча всего, там 100 атрибутов.

Очень простой запрос делаем. Берем и группируем по Referer, считаем count, сортируем по count. И первые 10 результатов показываем.

Запрос нужно выполнить быстро. Как это сделать?

Во-первых, нужно очень быстро прочитать:

• Самое простое, что тут надо сделать, это столбцовая организация. Т. е. храним данные по столбцам. Это нам позволит загрузить только нужные столбцы. В этом запросе это: ConterID, Date, Referrer. Как я уже сказал, их может быть 100. Естественно, если мы их все будем загружать, это все очень сильно нас затормозит.
• Поскольку данные у нас в память, наверное, не помещаются, нам нужно читать локально. Конечно, мы не хотим читать всю таблицу, поэтому нам нужен индекс. Но даже если мы читаем эту маленькую часть, которая нам нужна, нам нужно локальное чтение. Мы не можем по диску прыгать и искать данные, которые нам нужны для выполнения запроса.
• И обязательно нужно данные сжимать. Они в несколько раз сжимаются и пропускную способность диска очень сильно экономят.

И после того, как мы данные прочитали, нам нужно их очень быстро обработать. В ClickHouse много чего для этого делается:

• Самое главное, что он их обрабатывает блоками. Что такое блок? Блок – это небольшая часть таблицы, размером где-то в несколько тысяч строк. Почему это важно? Потому что ClickHouse – это интерпретатор. Все знают, что интерпретаторы – это очень медленно. Но если мы overhead размажем на несколько тысяч строк, то он будет незаметен. Зато это нам позволит применить SIMD инструкции. И для кэша процессора это очень хорошо, потому что если мы блок подняли в кэш, там его обрабатываем, то это будет гораздо быстрее, чем если он куда-то в память будет проваливаться.
• И очень много низкоуровневых оптимизаций. Я про это не буду говорить.

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

Как мы можем проверить, что он подойдет? Сортируем таблицу по CounterID, Date и смотрим наши строки, которые нам нужны, они занимают вот такую небольшую область. Это значит, что индекс подойдет. Он будет сильно ускорять.

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

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

И когда у нас этот индекс есть, то при выполнении запроса, что мы делаем? Мы должны выбрать строки, которые нам могут пригодиться для выполнения запроса. В данном случае нам нужен счетчик 1234 и дата с 31 мая. А тут только есть запись на 23 мая. Это значит, что мы, начиная с этой даты, все должны прочитать. И до записи, счетчик которой начинается уже 1235. Получается, что мы будем читать немножко больше записей, чем нужно. И для аналитических задач, когда вам много нужно строк прочитать – это не страшно. Но если вам нужна какая-то одна строка, то работать все будет не так хорошо. Чтобы найти одну строку, вам придется 8 000 прочитать.

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

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

Что тут важно? Key-Value сценарий будет плохо работать. У меня здесь светло-серым обозначено то, что мы прочитаем, и темно-серым то, что нам. И вполне может быть, что вам нужна будет одна строка, а вы прочитаете много.

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

Я сказал, что таблица упорядочена, но не рассказал, как это сделать. А нам очень хочется, чтобы данные, которые поступают в ClickHouse, тут же были доступны для отчетов. Т. е. после insert секунда прошла, и вы уже их видите в своих отчетах.

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

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

Вот примерно, как это происходит. У нас по Х – это номер вставки, т. е., грубо говоря, это время, которое вы вставляете. По У – первичный ключ. Поступили данные. Они обозначены зеленым цветом. Они не упорядоченные.

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

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

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

У ClickHouse есть одна особенность. Слияние происходит только с кусками, которые были вставлены подряд. В нашем случае был кусок, которые объединяет вставки от M до N. И маленький кусочек, который мы вставили на предыдущем слайде, который был вставлен под номером N+1.

Мы берем их и сливаем. И получаем новый кусок М до N+1. Он упорядоченный.

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

Как это будет выглядеть в случае с ClickHouse? Когда у вас будет на партицию (партиция – это месяц) 200 кусков, то у вас внезапно затормозятся вставки. Таким образом ClickHouse попробует дать возможность слияниям догнать вставки. А если уже будет 300 кусков, то он вам просто запретит вставлять, потому что иначе данные будет очень тяжело прочитать из множества кусков. Поэтому, если будете использовать ClickHouse, то обязательно это мониторьте. Настройте в ClickHouse экспорт метрик в Graphite. Это очень просто делается. И следите за количеством кусков в партиции. Если количество большое, то вам нужно обязательно разобраться с этим. Может быть, что-то с диском или вы начали очень сильно вставлять. И это нужно чинить.

Все хорошо. У нас есть сервер ClickHouse, все работает. Но иногда его может не хватать.

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

Что предлагает ClickHouse? Предлагает шардировать данные и использовать дистрибутивы таблицы.

Что это такое? Шардирование – это понятно. У вас есть какая-то таблица. И вы ставите несколько компьютеров, и на каждом компьютере часть этих данных. У меня на картинке они в таблице local_table.

Что такое distributed таблицы? Это такой view над локальными таблицами, т. е. сама она данные не хранит. Она выступает как прокси, который отправит запрос на локальные таблицы. Ее можно создавать где угодно, хоть на отдельном компьютере от этих шардов, но стандартный способ – это создание на каждом шарде. Вы тогда приходите в любой шард и создаете запрос.

Что она делает? Вот пошел запрос в select from distributed_table. Она возьмет его и перепишет distributed_table на local_table. И дальше отправит на все шарды сразу же.

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

Вот такой забавный benchmark. Чуть больше миллиарда строк. Это данные о поездках нью-йоркского такси. Они в открытом доступе лежат. Можно самому попробовать.

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

Как теперь раскладывать данные по шардам?

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

Но, в принципе, distributed таблица и сама умеет это делать, хотя есть несколько нюансов.

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

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

Что тут важно? Ключ шардирования можно даже рандом взять. Это тоже будет работать. Единственное, если вы хотите делать сложные joins и хотите, чтобы у вас данные, которые для joins нужны, были на одном шарде, тогда вам нужно уже задумываться о ключе шардирования.

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

ClickHouse предлагает для решения этой проблемы асинхронную мастер-мастер репликацию, которая работает на уровне таблиц — ReplicatedMergeTree. На сервере у вас могут быть и реплицированные таблицы, и не реплицированные.

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

При этом может происходить три типа событий:

• INSERT — вставка в реплику
• FETCH — одна реплика скачала кусок с другой
• MERGE — реплика взяла несколько кусков и слила их в один

Как происходит вставка? Вставляем на любую реплику. Тут видно, что Реплика 1 – не самая хорошая, но на нее все равно можно вставить. И информация о вставке записывается в ZooKeeper. Т. е. для того, чтобы у вас репликация работала, придется установить ZooKeeper.

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

Дальше нам нужно еще выполнять merge, т. е. сливать куски. Merge нужно выполнять согласовано, иначе наборы кусков разойдутся. Для этого одна реплика становится лидером. Не назовем мастером, потому что с мастером сразу идет ассоциация, что только туда можно вставлять, но это неправда. Т. е. у нас Реплика 2 – лидер. Она решила, что эти куски надо помержить, записала это в ZooKeeper, остальные реплики об этом информацию получат и тоже сделают такой же merge.

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

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

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

Доступность почти есть. Как сделать неубиваемый кластер ClickHouse? Берете три дата-центра. ZK в 3-х дата-центрах, а реплики, как минимум, в 2-х. И если у вас локация взрывается, то все продолжает работать и на чтение, и на запись.

Часто спрашивают: «А как в двух дата-центрах сделать?». В двух не получится из-за ZooKeeper. Если у вас только две локации, то вы какой-то дата-центр объявляете главным. И если не главный отключается, то у вас все продолжает работать. Если главный отключаете, то у вас только на чтение.

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

Вот эти две фичи: distributed_table, replicated_table независимы. Их можно независимо использовать. Но они очень хорошо работают вместе. Нормальный кластер ClickHouse мы его примерно так себе представляем. Т. е. у нас есть N шардов и каждый трехкратно реплицирован. И distributed таблица умеет понимает, что шарды – это реплики, могут отправлять запрос только в одну реплику шарда. И имеет отказоустойчивость, т. е. если у вас какая-то реплика недоступна, она в другую пойдет.

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

Что такое ClickHouse?

• Это столбцовая column-oriented база данных, которая позволяет очень быстро выполнять аналитические и интерактивные запросы.
• Язык запросов – это SQL с расширениями.
• Плохо подходит для OLTP, потому что транзакций нет. Key-Value, потому что у нас разреженный индекс. Если вам нужна одна строчка, то вы много чего лишнего прочитаете. И если у вас Key-Value с большими blob, то это вообще будет плохо работать.
• Линейно масштабируется, если шардировать и использовать distributed таблицы.
• Отказоустойчивая, если использовать replicate таблицы.
• И все это в open source с очень активным community.

Вопросы

Здравствуйте! Меня зовут Дмитрий. Спасибо за доклад! Есть вопрос про дублирование данных. Я так понимаю, что в ClickHouse нет никакого способа решать эту проблему. Ее надо решать на этапе вставки или все-таки есть какие-то методы, которыми мы можем побороться с дублированием данных у нас в базе?

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

Вот эта вставка блоками. В ZK хранятся checksums последних ста блоков. Это тоже настраиваемо, но 100 – неплохой вариант. Поэтому если вы вставили блок и у вас что-то взорвалось, и вы не уверены – вставили вы или нет, то вставьте еще раз. Если вставка прошла, то ClickHouse это обнаружит и не будет дублировать данные.

Т. е. если мы вставляем по 10 000 строк, у нас там будет храниться миллион строк, которые будут гарантировано недублированными?

Нет. Дублирование работает не на уровне строк.

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

Да, но только если выставляете прямо такими же блоками.

Т. е. идентичными блоками, да?

Да, для идентичного блока считается checksum. Если checksum совпадает, значит блок уже вставили и дублировать не надо.

Я понял. И второй вопрос. Меня интересуют запросы distributed таблицы к replicated таблицам. Я так понимаю, что запрос у нас идет только к одной реплике. Можно ли как-то настроить, чтобы какие-то тяжелые запросы шли на обе реплики, чтобы часть данных оттуда, часть данных оттуда каким-то образом доставалась?

Да, можно так настроить. Это еще один способ заиспользовать больше компьютеров. Есть специальная настройка, вы ее устанавливаете. По-моему, она называется max_parallel_replicas. Что она делает? Она половину данных обрабатывает на одной реплике, половину на другой. Но сразу оговорюсь, это работает только, если при создании таблицы был указан ключ сэмплирования. В ClickHouse есть такая фича – ключ сэмплирования. Вы можете посчитать там запрос не по всем данным, а по одной десятой. И если у вас в реплицированной таблице задан ключ сэмплирования, то при указании этой настройки max_parallel_replicas, он сообразит, что можно одну вторую данных посчитать там и другую половину на второй реплике. И будет использовать обе.

Не будет ли еще раз сэмплирование?

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

Понял, спасибо!

Спасибо за доклад! У меня три вопроса. Вы говорили, что индексы размазаны, т. е. там 8 000 с чем-то. И нужно писать большими объемами. Используете ли вы какую-то предбуферизацию? Рекомендуете ли вы что-то использовать?

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

Что есть? Есть буфер-таблица, куда тоже по одной строчке не надо вставлять, потому что будет тормозить на какой-то ерунде. Но если вы туда вставляете, она по диску меньше ездит. Т. е. не будет на каждую вставку делать запись на диск. И очень многие люди, которые уже более серьезно подходят к ClickHouse, они используют Kafka. У вас в Kafka lock, ваша писалка берет записи из Kafka и вставляет их в ClickHouse. Это тоже хороший вариант.

Да, т. е. можно это вручную настроить. Еще вопрос. У нас есть distributed таблица, которая управляет всеми шардами. И, например, шард с distributed таблицы умер. Это значит, что все данные у нас умерли?

Distributed таблица не хранит ничего. Если она у вас умерла, то вы просто создаете заново, и все так же работает. Главное, сохранить local_tables, в которых данные лежат, поэтому, конечно, их нужно реплицировать.

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

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

Т. е. я должен хранить это, куда я записал?

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

Спасибо большое!

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

Да, можно изменить целиком блок, точнее не блок, а всю партицию. Сейчас – это месяц. Но у нас есть приоритетная задача сделать партицию произвольной. Вы берете и говорите «alter table drop partition» и он убирается, и вы можете обратно залить данные.

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

Вам нужно будет хранить всю эту строку где-то. Вы, конечно, можете сходить в ClickHouse и спросить: «Какая последняя строка для этого ключа?», но это будет медленно уже.

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

Мы все-таки рекомендуем replicated таблицы. Почему? Потому что distributed таблица тоже умеет реплицировать.

Как replicated сделать на два ДЦ? У меня все равно получается, что если падает мастер, то писать никуда нельзя, а можно только читать. Или там какие-то простые способы? Slave сделать мастером, а потом догнать первого мастера до slave?

А с Kafka у вас как?

С Kafka я буду выливать каждую независимо. С Kafka все равно придется делать на три ДЦ.

Kafka тоже использует ZK.

На нее данных меньше надо. Но она только пару дней будет хранить, а не за всю историю, в Kafka меньше ресурсов. Но ее на три ДЦ дешевле делать, чем ClickHouse на три ДЦ.

ClickHouse не обязательно размазывать на три, вам только нужно ZK поставить.

А, все, только для quorum ZK, данные дублируются только два раза. Для quorum у нас есть ДЦ.

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

У меня вопрос касается утилизации памяти. Как наиболее эффективно распределять ее? Сколько под instants выделять?

Про память такая история, что в ClickHouse есть такая настройка, как max_memory_usage. Это сколько вы можете отъесть, когда обрабатываете запрос. Для чего еще нужна память? Память нужна под дисковый кэш. Т. е. у ClickHouse нет какого-то хитрого кэша. Некоторые системы, как делают? Они читают o_direct с диска и как-то у себя кэшируют. ClickHouse так не делает. Какую-то часть памяти (довольно большую) нужно оставить под дисковый кэш. У вас данные, которые недавно читались с диска, будут потом из памяти прочитываться. И треть вы отводите на память, которая нужна в запросе.

Для чего ClickHouse расходует память? Если у вас запрос стриминговый, т. е. просто пройтись и что-то там посчитать, например, count, то будут единицы памяти расходоваться.

Где может понадобиться память? Когда у вас group by с большим количеством ключей. Например, вы по тем же самым referrers что-то группируете и у вас очень много различных referrers, urls. И все эти ключи нужно хранить. Если вам хватило памяти, то хорошо, а если не хватило, то есть возможность group by выполнить на диске, но это будет гораздо медленнее.

Это он сам определит?

Нужно включить.

Есть какой-то объем, который вы рекомендуете выстраивать? Например, 32 GB на ноду? Т. е., когда эффективно используется.

Чем больше, тем лучше. У нас 128 GB.

И один instance все 128 использует, да?

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

Алексей, спасибо за доклад! Вы не измеряли падение производительности при сильной фрагментации файловой системы?

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

Хотя бы примерный порядок?

Не знаю, процентов до 70 нормально будет.

Спасибо!

Добрый день! У меня два вопроса. Насколько я знаю, сейчас у ClickHouse только http-интерфейс для обмена данными с клиентом. А есть ли какой-то roadmap, чтобы сделать бинарный интерфейс?

У нас есть два интерфейса. Это http, который можно любым http-клиентом использовать, который в JDBC-драйвере используется. И есть нативный интерфейс, который мы всегда считали приватным и не хотели для него какой-то библиотеки делать. Но интерфейс этот не такой сложный. И мы поддерживаем там прямую-обратную совместимость, поэтому добрые люди использовали исходники как документацию и в Go есть, я слышал, отличный драйвер, которые нативные клиенты используют. И для C++ мой коллега сделал отдельный драйвер, который позволяет использовать нативный интерфейс и вам не нужно линковаться со всем ClickHouse, чтобы его использовать. И для других языков тоже, наверное, есть. Точно не знаю. Т. е. формально мы его считаем нашим приватным, но по факту он уже публичный. Из некоторых языков им можно пользоваться.

Спасибо! Вы говорили, что написали свою систему репликации данных. Допустим, Impala использует HDFS для репликации данных, она не делает репликацию самостоятельно. Почему вы написали репликацию, чем она лучше, чем HDFS?

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

Т. е. вы напрямую не сравнивали?

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

Один кусок – это будет один блок на HDFS и будет операция *opened*, если это возможно.

Т. е. использовать HDFS как хранилище?

Да. Чтобы не делать собственные репликации. Вы записали на HDFS и считайте, что оно уже реплицировано, и поддерживается отказоустойчивость.

А читать-то мы хотим с локального диска.

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

Интересная мысль, надо подумать.

Спасибо!

Let's block ads! (Why?)