Кх жмет лучше снаппи например, но проигрывает в количестве реплик

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

  КХ хранит каждую колонку в отдельном файле и жмет ее. Либо через LZ4 по умолчанию,  либо если хотите, то иначе (указывается на уровне колонки). Посмотрите про кодеки https://clickhouse.yandex/docs/ru/query_language/create/#codecs. Причем обратите внимание на возможности LowCardinality (можно тут почитать https://www.altinity.com/blog/2019/3/27/low-cardinality)
, что фактически является кодирование по словарю.
 
  Вот как данные в orc хранятся я не знаю, знаю только что там тоже есть кодирование по словарю как и в КХ
  и вроде оно даже само включается, а к КХ вам нужно будет при создании колонки установить это.
  в файле КХ не нужно для каждого файла хранить мета-информацию о типах и схеме. Она хранится один раз
  для всех файлов. в КХ у вас будет возможность создать разные идексы( для разных колонок).
  Это позволит вам избегать FS в каких-то еще случаях в дополнению к тем, когда в ваших
  запросах участвует столбцы из первичного ключа/ключа сортировки.
 
  В целом не обладая знаниями по orc не могу придумать, что позволит хранить более компактно
  чем КХ. ведь КХ хранит 1) каждую колонку в своем файле 2) жмет  3)использует кодирование по словарю 4)использует нативный формат для данных.

Спасибо за развернутый ответ и ссылки

Ну орк и паркет тот же колумнар формат

Каждая колонка ложится и сжимается отдельно (дикшионари енкодинг, рле енкодинг, дельту тоже вроде делали)

То что это один большой файл с отдельными сегментами большой роли не играет

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

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

https://habr.com/ru/post/485484/

ну, это. приветствуются лайки, шеры, ретвиты, вопросы, конструктивная критика

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

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

Боюсь, у меня маловато компетенции для подобающей оценки, но мне понравилось

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

а мы на вояк не работаем. зачем они нам.

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

впрочем, об этом я просто не имею права говорить...

а, понял о чём ты.

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

не бейте тапками
а насколько плохая идея развенуть кубернетес поверх марафона ? (dc/os может кто слышал)

очень плохая

Почему?

Кроме оверхедов @masitnikov 😉

Добро пожаловать в самое дружелюбное комьюнити.

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

GDPR по таким поставщикам не плачет?