Дмитрий Кутейников 

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

SQL появился очень давно - когда инженеры ещё не привыкли, что в мире информационных технологий всё меняется быстрее, чем успеваешь кофе попить, а потому спроектировали его тщательно, вдумчиво и строго. Есть таблица, есть разнообразные нормальные формы (из институтского курса помню, что их никак не менее шести, но в реальных задачах обычно безальтернативным выбором является третья), есть строгие правила объединения данных (всякие RIGHT/LEFT/INNER/FULL/прочие JOIN), строгие правила конвертации (включая кодировку для строк), строгие правила фильтрации (всякие WHERE [xxx].[yyy].[zzz] = 'Q' со всякой булевой алгеброй в условиях)...

Суть в том, что сам SQL спроектирован под работу с табличными данными: у таблицы есть сколько-то столбцов разных типов, в таблице есть некоторое произвольное количество строк и мы некоторым образом (по каким-то условиям) выбираем (и иногда по каким-то правилам группируем) подмножество строк/столбцов этой таблицы. Чтобы было интереснее - есть те счамые JOIN и другие страшные операторы (я уже порядочно позабыл, что нам в институте рассказывали, ибо, слава Богу, не DBA, а классический программист), всякие хранимые процедуры и VIEW - но всё равно это сводится к "получить некоторое множество строк некоторого множества столбцов". На самом деле, это гораздо сложнее, чем выглядит, и гораздо мощнее, чем можно было бы ожидать от такой простой формулировки - в частности поэтому классические СУБД живут и здравствуют и совершенно не собираются никуда уходить несмотря на огромное количество концептуально новых подходов к хранению и обработки данных - всякие "No-SQL" (учитывая, что SQL - это Structured Query Language, язык структурированных запросов, "No-SQL" - это обман в названии, там тоже есть язык запросов и он тоже структурированный).

Описанная концепция SQL позволила его очень качественно формализовать и разработать массу разных решений (в математическом смысле) для решения разных прикладных задач. Если брать бизнес-аналитику - например, какой-нибудь средний чек - то задача формализуется как "подсчитать количество уникальных чеков и их общую сумму и поделить второе на первое". Под это же адаптируется структура хранения данных, когда один чек записывается как несколько строк таблицы - по одной на каждый товар в чеке (что-то вроде кортежа {"идентификатор чека", "артикул товара", "количество товара"} - и потом из справочника товаров через упоминавшийся выше JOIN можно подтянуть цену единицы товара, а в ещё одну таблицу потом записать {"идентификатор чека", "дата-время покупки", "идентификатор кассового аппарата", "способ оплаты", "код скидки"} или как-то так, и ещё всякие дополнительные данные, размазанные по СУБД - магазин, например).

При обсуждении Rapeed я регулярно сравниваю его с ClickHouse. Тому есть две причины:

1. ClickHouse - офигительно хорош! Яндекс вложил в него сотни (а то и тысячи) человеко-лет разработки и сделал СУБД мирового уровня, которую можно смело поставить в один ряд с mysql, postrgesql и многими коммерческими. А потом отдал в OpenSource.

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

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

При массе сходств между Rapeed и ClickHouse есть принципиальное отличие: ClickHouse - честная СУБД (система управления базами данных) с полноценной поддержкой SQL, а Rapeed - нет. Rapeed - это система бизнес-аналитики, и всем остальным мы сознательно пожертвовали ради скорости и функционала расчётов.

К сожалению, у меня так и не дошли руки как следует разобраться в деталях, как именно ClickHouse хранит данные, и потому про него буду говорить очень поверхностно. Наш шеф категорически настаивает на неразглашении технических деталей (хотя на мой взгляд большинство их абсолютно очевидны, но тут действует старый принцип 90+9+1), так что про Rapeed я тоже расскажу в очень общих словах.

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

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

История компании гуглибельна и весьма поучительна, я за процессом наблюдал изнутри (работал в "Полиматике" с 2012-го года, лично занимался внедрением в ФНС и в нескольких коммерческих структурах, позже у нас появились специально обученные внедренцы и за установкой в ПФР я приглялывал буквально одним глазком).

Как это выглядит снаружи - лучше почитать у других (на хабре есть пара статей). "Я пишу код" и на интерфейс мне смотреть тупо некогда.

Я пишу ядро. Тот самый "тензорный движок" или "распределённый in-memory OLAP", который не совсем олап и не чисто тензорный и совсем не обязательно "in memory".

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

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

Прям юбилей-юбилей...

Даже как-то неожиданно.

Дети уже подросли (младшенькому уже 16, внучке скоро 4, кажется), с женой уже развелись, работа интересная и по профилю...

Осталась мечта - построить самолёт (и улететь отсюда). :-)

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

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

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

Так вот, о личном опыте.

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

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

"Непрерывное пиршество интеллекта!", как говорила одна барышня юридической ориентации в городе Морлоу (Morelaw, "Больше законов") из фильма "Трасса 60".

В смысле, никаких принципиально новых новостей нет, просто сообщить, что ещё жив и даже на что-то надеюсь. :-)

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

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

3. Рукодельное. Так как голова или забита работой на 146%, или "выбило предохранители" от перегруза - решил с пользой применить руки, благо, более-менее прямые. Делаю, внезапно, стул. Есть у меня хороший друг, он же кум, у которого со стульями отношения складываются грустно - постоянно ломаются. Хочу сделать такой стул, чтобы не сломался. План есть, материалы есть, инструменты есть (правда, самый минимум), прогресс по проекту тоже есть, что удивительно.

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

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

Я не Гоголь, так что второму тому - быть!

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

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

После дня напряжённой работы головой взять штангу и немного ей помахать - да не вопрос! Написать страничку текста - ээээ... а можно ограничиться одним абзацем? А ещё лучше - перечитать старое и очепятки поредактировать? Стиль там причесать? Чтобы не слишком думать... 0_о

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

Тем не менее, примерно половина главы про нашего общего железного знакомого уже написана (и даже четырежды вычитана, да)!