Незважаючи на те, що даних зараз багато майже скрізь, аналітичні БД ще досить екзотичні. Їх погано знають і ще гірше вміють ефективно використати. Багато хто продовжує "єсть кактус" з MySQL або PostgreSQL, які спроектовані під інші сценарії, мучитися з NoSQL або переплачувати за комерційні рішення. ClickHouse змінює правила гри та значно знижує поріг входження у світ аналітичних DBMS.
Доповідь з BackEnd Conf 2018 і він опублікований з дозволу доповідача.
Хто я такий і чому я розповідаю про ClickHouse? Я директор з розробки у компанії LifeStreet, яка використовує ClickHouse. Крім того, я засновник Altinity. Це партнер Яндекса, який просуває ClickHouse та допомагає Яндексу зробити ClickHouse більш успішним. Також готовий ділитися знаннями про ClickHouse.
І ще не брат Петі Зайцева. Мене часто про це запитують. Ні, ми не брати.
"Всім відомо", що ClickHouse:
- Дуже швидкий,
- Дуже зручний,
- Використовується в Яндекс.
Трохи менш відомо, в яких компаніях та як він використовується.
Я вам розповім, навіщо, де і як використовується ClickHouse, окрім Яндекса.
Розкажу, як конкретні завдання вирішуються за допомогою ClickHouse у різних компаніях, які засоби ClickHouse ви можете використовувати для своїх завдань та як вони були використані у різних компаніях.
Я підібрав три приклади, які показують ClickHouse з різних боків. Гадаю, це буде цікаво.
Перше питання: "Навіщо потрібен ClickHouse?". Начебто б питання досить очевидне, але відповідей на нього більше, ніж одна.
- Перша відповідь – заради продуктивності. ClickHouse дуже швидкий. Аналітика на ClickHouse також дуже швидка. Його часто можна використовувати там, де щось інше працює дуже повільно чи дуже погано.
- Друга відповідь – це вартість. І насамперед вартість масштабування. Наприклад, Vertica – абсолютно чудова база даних. Вона дуже добре працює, якщо у вас не дуже багато терабайт даних. Але коли йдеться про сотні терабайтів або про петабайти, то вартість ліцензії та підтримки виходить у досить суттєву суму. І це дорого. А ClickHouse безкоштовний.
- Третя відповідь – це операційна вартість. Це підхід трохи з іншого боку. RedShift – чудовий аналог. На RedShift можна швидко зробити рішення. Воно буде добре працювати, але при цьому щогодини, щодня і кожного місяця ви будете досить дорого платити Amazon, тому що це суттєво дорогий сервіс. Google BigQuery також. Якщо ним хтось користувався, він знає, що там можна запустити кілька запитів і отримати рахунок на сотні доларів раптово.
У ClickHouse цих проблем немає.
Де використовується ClickHouse зараз? Крім Яндекса ClickHouse використовується в купі різних бізнесів та компаній.
- Насамперед це аналітика веб-додатків, тобто це use case, який прийшов з Яндекса.
- Багато AdTech компаній використовують ClickHouse.
- Численні компанії, яким необхідно аналізувати операційні логи з різних джерел.
- Декілька компаній використовують ClickHouse для моніторингу логів безпеки. Вони завантажують їх у ClickHouse, роблять звіти, отримують потрібні їм результати.
- Компанії починають його використовувати у фінансовому аналізі, тобто поступово великий бізнес теж підбирається до ClickHouse.
- CloudFlare. Якщо хтось за ClickHouse стежить, то, напевно, чув назву цієї компанії. Це один із суттєвих контрибуторів з community. І у них дуже серйозна ClickHouse-інсталяція. Наприклад, вони зробили Kafka Engine для ClickHouse.
- Телекомунікаційні компанії почали використовувати. Декілька компаній ClickHouse використовують або як proof on concept, або вже в production.
- Одна компанія використовує ClickHouse для моніторингу виробничих процесів. Вони тестують мікросхеми, списують купу властивостей, там близько 2 000 параметрів. І далі аналізують – гарна партія чи погана.
- Блокчейн-аналітика. Є така російська компанія як Bloxy.info. Це аналіз ethereum-мережі. Це вони теж зробили на ClickHouse.
Причому розмір немає значення. Є багато компаній, які використовують один маленький сервер. І він їм дозволяє вирішити їхні проблеми. І ще більше компаній використовують великі кластери з багатьох серверів чи десятків серверів.
І якщо стежити за рекордами, то:
- Яндекс: 500+ серверів, 25 мільярдів записів на день вони там зберігають.
- LifeStreet: 60 серверів, приблизно 75 мільярдів записів на день. Серверів менше, записів більше, ніж у Яндексі.
- CloudFlare: 36 серверів, 200 мільярдів записів на день вони зберігають. Вони ще менше серверів і ще більше даних вони зберігають.
- Bloomberg: 102 сервери, приблизно трильйон записів на день. Рекордсмен із записів.
Географічно – це також багато. Ось ця карта показує heatmap, де ClickHouse використовується у світі. Тут яскраво виділяється Росія, Китай, Америка. Європейських країн замало. І можна виділити 4 кластери.
Це порівняльний аналіз, тут не треба шукати абсолютні цифри. Це аналіз відвідувачів, які читають англомовні матеріали на сайті Altinity, тому що там немає російськомовних. І Росія, Україна, Білорусь, тобто російськомовна частина спільноти, це найчисленніші користувачі. Потім іде США та Канада. Дуже сильно наздоганяє Китай. Там півроку тому Китаю майже не було, зараз Китай уже випередив Європу і продовжує зростати. Бабуся Європа теж не відстає, причому лідер використання ClickHouse - це, як не дивно, Франція.
Навіщо я це все розповідаю? Щоб показати, що ClickHouse стає стандартним рішенням для аналізу великих даних і вже дуже багато де використовується. Якщо ви його використовуєте, ви у правильному тренді. Якщо ви ще його не використовуєте, то можна не боятися, що ви залишитеся одні і вам ніхто не допоможе, тому що вже багато хто цим займається.
Це приклади реального використання ClickHouse у кількох компаніях.
- Перший приклад - це рекламна мережа: міграція з Vertica на ClickHouse. І я знаю кілька компаній, які з Vertica перейшли або перебувають у процесі переходу.
- Другий приклад - транзакційне сховище на ClickHouse. Це приклад, побудований на антипаттернах. Все, що не потрібно робити в ClickHouse за порадами розробників, тут зроблено. І при цьому зроблено так ефективно, що це працює. І працює набагато краще, ніж типове транзакційне рішення.
- Третій приклад – це розподілені обчислення на ClickHouse. Було питання про те, як можна ClickHouse інтегрувати в Hadoop екосистему. Я покажу приклад, як компанія зробила на ClickHouse щось типу аналога map reduce контейнера, стежачи за локалізацією даних тощо, щоб порахувати дуже нетривіальне завдання.
- LifeStreet – це Ad Tech компанія, яка має всі технології, супутні рекламної мережі.
- Займається вона оптимізацією оголошень, programmatic bidding.
- Багато даних: близько 10 мільярдів подій на день. При цьому там події можуть на кілька подій ділитися.
- Багато клієнтів цих даних, причому це не тільки люди, набагато більше – це різні алгоритми, які займаються програмним bidding.
Компанія пройшла довгий і тернистий шлях. І я про нього розповідав на HighLoad. Спочатку LifeStreet перейшла з MySQL (з невеликою зупинкою на Oracle) до Vertica. І можна про це знайти розповідь.
І все було дуже добре, але досить швидко стало зрозуміло, що дані зростають та Vertica – це дорого. Тому шукалися різні альтернативи. Деякі їх тут перераховані. І насправді ми зробили proof of concept або іноді performance testing майже всіх баз даних, які з 13 по 16 рік були доступні на ринку і приблизно підходили за функціональністю. І про частину з них я також розповів на HighLoad.
Стояло завдання – мігрувати з Vertica насамперед, тому що дані зростали. І вони росли експоненційно кілька років. Потім вони вийшли на полицю, проте. І прогнозуючи це зростання, вимоги бізнесу на обсяг даних, за якими потрібно робити якусь аналітику, було зрозуміло, що незабаром йтиметься про петабайти. А за петабайти платити вже дуже дорого, тож шукали альтернативу, куди йти.
Куди йти? І довгий час було зовсім не зрозуміло, куди йти, тому що з одного боку є комерційні бази даних, вони начебто непогано працюють. Деякі працюють майже так само добре, як Vertica, деякі гірші. Але вони всі дорогі, нічого дешевшого і краще знайти не вдавалося.
З іншого боку, є Open source рішення, яких не дуже багато, тобто для аналітики їх можна перерахувати на пальцях. І вони безкоштовні чи дешеві, але працюють повільно. І в них часто не вистачає потрібної та корисної функціональності.
І того, щоб поєднувало те добре, що є в комерційних базах даних і все те безкоштовне, що є в Open Source, — нічого не було.
Нічого не було доти, доки несподівано Яндекс не витяг, як кролика фокусник із шапки, ClickHouse. І це було рішення несподіване, і досі запитують: «Навіщо?», проте.
І відразу влітку 2016 року ми стали дивитися, що таке ClickHouse. І виявилося, що він іноді може бути швидше за Vertica. Ми тестували різні сценарії на різні запити. І якщо запит використовував тільки одну таблицю, тобто без будь-яких джойни (join), то ClickHouse був швидше за Vertica в два рази.
Я не полінувався і ще подивився тести Яндекса. Там те саме: вдвічі ClickHouse швидше за Vertica, тому вони часто про це говорять.
Але якщо в запитах є джойни, то все виходить не дуже однозначно. І ClickHouse може бути повільніше за Vertica в два рази. А якщо трохи запит підправити і переписати, то приблизно рівні. Не погано. І безкоштовно.
І отримавши результати тестів і подивившись з різних сторін на це, LifeStreet поїхав на ClickHouse.
Це 16-й рік, нагадую. Це було як в анекдоті про мишей, які плакали та кололися, але продовжували їсти кактус. І про це було детально розказано, є про це відео тощо.
Я тому не буду докладно про це розповідати, розповім лише про результати та про кілька цікавих речей, про які я не розповідав тоді.
Результати – це:
- Успішна міграція та більше року система вже працює у продакшені.
- Продуктивність та гнучкість зросли. З 10 мільярдів записів, які ми могли дозволити собі зберігати на день і то недовго, тепер LifeStreet зберігає 75 мільярдів записів на день і може це робити 3 місяці та більше. Якщо порахувати у піку, то це до мільйона подій на секунду зберігається. Більше мільйона SQL-запитів на день прилітають у цю систему, переважно від різних роботів.
- Незважаючи на те, що для ClickHouse стали використовувати більше серверів, ніж для Vertica, економія і на залізі вийшла, тому що у Вертику використовувалися досить дорогі диски SAS. У ClickHouse використовували SATA. А чому? Тому що у Vertica insert синхронний. І синхронізація вимагає, щоб диски не дуже сильно гальмували, а також щоб мережа не дуже гальмувала, тобто досить дорога операція. А в ClickHouse insert асинхронний. Більш того, можна все локально завжди писати, ніяких додаткових витрат на це немає, тому дані в ClickHouse можна вставляти набагато швидше, ніж у Вертику навіть на не найшвидших дисках. А на читання приблизно однаково. Читання на SATA, якщо вони в RAID сидять, це все досить швидко.
- Не обмежені ліцензією, тобто 3 петабайти даних у 60 серверів (20 серверів – це одна репліка) та 6 трильйонів записів у фактах та агрегатах. Нічого подібного до Vertica дозволити собі не могли.
Зараз я переходжу до практичних речей у цьому прикладі.
- Перше – це ефективна схема. Від схеми залежить дуже багато.
- Друге – це створення ефективного SQL.
Типовий OLAP-запит – це select. Частина колонок йде у group by, частина колонок йде в агрегатні функції. Є де, яку можна представити як зріз куба. Весь group можна представити як проекцію. І тому це називається багатовимірним аналізом даних.
І часто це моделюється у вигляді star-схеми, коли є центральний факт і характеристики цього факту на всі боки, на променях.
І з погляду фізичного дизайну, того, як це лягає на таблицю, зазвичай роблять нормалізоване уявлення. Можете денормалізувати, але це дорого диском і не дуже ефективно за запитами. Тому зазвичай роблять нормалізоване уявлення, тобто таблиця фактів і багато таблиць вимірів.
Але в ClickHouse це працює погано. Є дві причини:
- Перша - це тому, що в ClickHouse не дуже хороші джойни (join), тобто джойни (join) є, але вони погані. Поки що погані.
- Друга – те, що таблиці не оновлюються. Зазвичай у цих табличках, які довкола star-схеми, потрібно щось міняти. Наприклад, назва клієнта, назва компанії та інше. І це не працює.
І вихід із цього в ClickHouse є. навіть цілих два:
- Перший – це використання словників. External Dictionaries - це те, що допомагає на 99% вирішити проблему зі star-схемою, з апдейтами та іншим.
- Другий – це використання масивів. Масиви теж допомагають позбутися джойни (join) і проблем з нормалізацією.
- Не потрібний джойни (join).
- Поновлювані. З березня 2018 року з'явилася недокументована можливість (у документації ви про це не знайдете) оновлювати словники частково, тобто ті записи, які змінилися. Фактично – це як таблиця.
- Завжди в пам'яті, тому джойни зі словником працюють швидше, ніж, якби це була таблиця, яка лежить на диску і ще не факт, що вона в кеші, швидше за все, що ні.
- Теж не потрібний джойни (join).
- Це компактне уявлення 1 до багатьох.
- І на мій погляд, масиви зроблені для гіків. Це лямбда-функції та інше.
Це не для червоного слівця. Це дуже потужна функціональність, яка дозволяє робити багато речей дуже просто та елегантно.
Типові приклади, що допомагають вирішувати масиви. Ці приклади прості та досить наочні:
- Пошук за тегами. Якщо у вас є хештеги і ви хочете знайти якісь записи по хештегу.
- Пошук по key-value парам. Також є якісь атрибути із значенням.
- Зберігання списків ключів, які потрібно перекласти в щось інше.
Усі ці завдання можна вирішити без масивів. Теги можна в якийсь рядок покласти і регулярним виразом вибирати або в окрему таблицю, але тоді доведеться робити джойни (join).
А в ClickHouse нічого не потрібно робити, достатньо описати масив string для хештегов або зробити вкладену структуру для систем типу key-value.
Вкладена структура - це, можливо, не найвдаліша назва. Це два масиви, які мають загальну частину в назві та деякі пов'язані характеристики.
І за тегом шукати дуже просто. Є функція hasяка перевіряє, що в масиві є елемент. Всі знайшли всі записи, які відносяться до нашої конференції.
Пошук по subid трохи складніше. Треба нам спочатку знайти індекс ключа, а потім уже взяти елемент із цим індексом і перевірити, що це значення таке, яке нам потрібно. Проте дуже просто і компактно.
Регулярний вираз, який ви захотіли б написати, якби ви все це зберігали в одному рядку, він був би, по-перше, корявим. А по-друге, працювало набагато довше, ніж два масиви.
Інший приклад. У вас є масив, де ви зберігаєте ID. І ви можете перевести їх на імена. Функція arrayMap. Це типова лямбда-функція. Ви передаєте туди лямбда-вирази. І вона кожному ID зі словника витягує значення імені.
Аналогічним чином можна зробити пошук. Передається функція предикат, яка перевіряє, чому відповідають елементи.
Ось ці речі сильно спрощують схему та вирішують купу проблем.
Але наступна проблема, з якою ми зіткнулися і яку я хотів би згадати, це ефективні запити.
- У ClickHouse немає планувальника запитів. Взагалі ні.
- Але складні запити все одно планувати треба. В яких випадках?
- Якщо у запиті є кілька джойни, які ви завертаєте в підселекти. І порядок, у якому вони виконуються, має значення.
- І друге – якщо запит розподілено. Тому що в розподіленому запиті тільки внутрішній підселект виконується розподілено, а все інше передається на один сервер, до якого ви підключилися і виконується там. Тому якщо у вас розподілені запити з багатьма джойнами (join), то потрібно вибирати порядок.
І навіть у простіших випадках теж іноді слід виконувати роботу планувальника і запити трохи переписувати.
Ось приклад. У лівій частині запит, який показує топ-5 країн. І він виконується 2,5 секунди, на мою думку. А в правій частині той самий запит, але трохи переписаний. Ми замість того, щоб групувати рядком, стали групувати за ключом (int). І це швидше. А потім ми до результату підключили словник. Замість 2,5 секунди запит виконується 1,5 секунди. Це добре.
Схожий приклад із переписуванням фільтрів. Тут запит по Росії. Він виконується 5 секунд. Якщо ми його перепишемо таким чином, що порівнюватимемо знову не рядок, а числа з якимось сетом тих ключів, які відносяться до Росії, то це буде набагато швидше.
Таких трюків багато. І вони дозволяють суттєво прискорити запити, які вам здається, що вже працюють швидко, або, навпаки, працюють повільно. Їх можна зробити ще швидше.
- Максимум роботи у розподіленому режимі.
- Сортування за мінімальними типами, як я це робив по інтах.
- Якщо є якісь джойни (join), словники, то їх краще робити в останню чергу, коли у вас дані хоча б частково згруповані, тоді операція джойни (join) або виклик словника буде менше разів викликатися і це буде швидше.
- Заміна фільтрів.
Є ще інші техніки, а не лише ті, які я продемонстрував. І всі вони дозволяють іноді суттєво прискорити виконання запитів.
Переходимо до такого прикладу. Компанія Х із США. Що вона робить?
Було завдання:
- Офлайн-зв'язування транзакцій реклами.
- Моделювання різних моделей зв'язування.
У чому полягає сценарій?
Звичайний відвідувач заходить на сайт, наприклад, 20 разів на місяць з різних оголошень або просто так іноді приходить без будь-яких оголошень, тому що пам'ятає цей сайт. Дивиться якісь продукти, кладе їх у кошик, виймає їх із кошика. І, зрештою, щось купує.
Резонні питання: "Кому треба заплатити за рекламу, якщо треба?" та «Яка реклама на нього вплинула, якщо вплинула?». Т. е. чому він купив і як зробити так, щоб люди, схожі на цю людину, теж купували?
Щоб це завдання вирішити, потрібно пов'язувати події, які відбуваються на веб-сайті правильним чином, тобто якось між ними вибудовувати зв'язок. Потім їх передавати для аналізу DWH. І на підставі цього аналізу будувати моделі, кому та яку рекламу показувати.
Рекламна транзакція - це набір пов'язаних подій користувача, які починаються від показу оголошення, далі щось відбувається, потім, можливо, покупка, а потім можуть бути покупки в покупці. Наприклад, якщо ця мобільна програма або мобільна гра, то зазвичай установка програми безкоштовно відбувається, а якщо там щось далі робиться, то на це можуть знадобитися гроші. І чим більше людина витратить у додатку, тим вона цінніша. Але для цього треба все пов'язати.
Є багато моделей зв'язування.
Найпопулярніші – це:
- Last Interaction, де interaction – це чи клік, чи показ.
- First Interaction, тобто перше, що привело людину на сайт.
- Лінійна комбінація – всім порівну.
- Згасання.
- Та інше.
І як це все працювало спочатку? Був Runtime та Cassandra. Cassandra використовувалася як transaction storage, т. е. у ній зберігалися всі пов'язані транзакції. І коли приходить якась подія в Runtime, наприклад, показ якоїсь сторінки чи ще щось, то робився запит у Cassandra – є така людина чи ні. Потім діставалися транзакції, які до нього належать. І проводилося зв'язування.
І якщо пощастило, що у запиті є transaction id, це легко. Але зазвичай не щастить. Тому треба було знайти останню транзакцію чи транзакцію з останнім кліком тощо.
І це все добре працювало, поки зв'язування було до останнього кліку. Тому що кліків, скажімо, 10 мільйонів на день, 300 мільйонів на місяць, якщо на місяць ставити вікно. І оскільки в Cassandra це має бути все в пам'яті для того, щоб працювало швидко, тому що потрібно Runtime відповісти швидко, потрібно приблизно 10-15 серверів.
А коли захотіли до показу прив'язувати транзакцію, то одразу вийшло не так весело. А чому? Видно, що у 30 разів більше подій треба зберігати. І, відповідно, потрібно у 30 разів більше серверів. І виходить, що це якась астрономічна цифра. Тримати до 500 серверів для того, щоб робити зв'язування, при тому, що в Runtime серверів істотно менше, це якась неправильна цифра. І почали думати, що робити.
І вийшли на ClickHouse. А як це робити на ClickHouse? На перший погляд здається, що це набір антипатернів.
- Транзакція зростає, ми до неї підчіплюємо все нові і нові івенти, тобто вона mutable, а ClickHouse не дуже добре працює з mutable-об'єктами.
- Коли до нас приходить відвідувач, то нам потрібно витягнути його транзакції по ключу, його visit id. Це теж point query, у ClickHouse так не роблять. Зазвичай у ClickHouse великі …скани, а тут нам потрібно дістати кілька записів. Теж антипаттерн.
- Крім того, транзакція була в json, але переписувати не хотіли, тому хотіли зберігати json не структуровано, а якщо треба, то щось витягувати з нього. І це також антипаттерн.
Т. е. набір антипаттернів.
Проте вдалося створити систему, яка дуже добре працювала.
Що було зроблено? З'явився ClickHouse, у якому закидалися логи, розбиті на записи. З'явився атрибутний сервіс, який отримував з ClickHouse логі. Після цього для кожного запису visit id отримував транзакції, які могли бути ще не дооброблені і плюс снапшоти, тобто транзакції вже пов'язані, а саме результат попередньої роботи. З них уже робив логіку, вибирав правильну транзакцію, приєднував нові події. Знову записував у балку. Лог йшов назад у ClickHouse, тобто це постійно циклічна система. І крім того, йшов у DWH, щоб там це аналізувати.
Саме у такому вигляді це працювало не дуже добре. І щоб ClickHouse було простіше, коли йшов запит по visit id, групували ці запити в блоки по 1 000-2 000 visit id і витягували для 1 000-2 000 чоловік усі транзакції. І тоді все це запрацювало.
Якщо подивитися всередину ClickHouse, то там всього три основні таблиці, які все це обслуговують.
Перша таблиця, у яку заливаються логи, причому логи заливаються майже обробки.
Друга таблиця. Через матеріальний вигляд з цих ліг викушувалися, які ще не поширювалися івенти, тобто не пов'язані. І через materialized view з цих ліг витягувалися транзакції для побудови снапшота. Т. е. спеціальним materialized view будував снапшот, а саме останній накопичений стан транзакції.
Ось тут написано текст на SQL. Я хотів би прокоментувати в ньому кілька важливих речей.
Перша важлива річ – це можливість у ClickHouse з json витягувати колонки, поля. Т. е. в ClickHouse є деякі методи для роботи з json. Вони дуже примітивні.
visitParamExtractInt дозволяє з json витягувати атрибути, тобто перше влучення спрацьовує. І в такий спосіб можна витягнути transaction id або visit id. Це вкотре.
Друге – тут використано хитре materialized поле. Що це означає? Це означає, що ви в таблицю вставити не можете, тобто воно не вставляється, воно обчислюється і зберігається при вставці. При вставці ClickHouse робить за вас роботу. І вже витягується з json те, що вам потім знадобиться.
В даному випадку materialized view – це для необроблених рядків. І саме використовується перша таблиця з практично сирими логами. І що робить? По-перше, змінює сортування, тобто сортування тепер йде visit id, тому що нам потрібно швидко витягувати саме по конкретній людині його транзакцію.
Друга важлива річ – index_granularity. Якщо ви бачили MergeTree, то зазвичай по дефолту 8 стоїть index_granularity. Що це таке? Це параметр розрідженості індексу. У ClickHouse індекс розріджений, він ніколи не індексує кожен запис. Він це робить через кожні 192. І це добре, коли потрібно багато даних підрахувати, але погано, коли трошки, тому що великий overhead. І якщо зменшувати index granularity, то ми зменшуємо overhead. Зменшити до одиниці не можна, тому що пам'яті не вистачить. Індекс завжди зберігається в пам'яті.
А снапшот використовує ще деякі цікаві функції ClickHouse.
По-перше, це AggregatingMergeTree. І в AggregatingMergeTree зберігається argMax, тобто це стан транзакції, що відповідає останньому timestamp. Транзакції постійно генеруються для даного відвідувача. І в останній стан цієї транзакції ми додали івент і у нас з'явився новий стан. Воно знову потрапило до ClickHouse. І через argMax у цьому матеріалізованому уявленні ми можемо отримати актуальний стан.
- Зв'язування відв'язане від Runtime.
- Зберігається та обробляється до 3 мільярдів транзакцій на місяць. Це значно більше, ніж було в Cassandra, тобто у типовій транзакційній системі.
- Кластер 2х5 серверів ClickHouse. 5 серверів, і кожен сервер має репліку. Це навіть менше, ніж було в Cassandra для того, щоб зробити click based атрибуцію, а тут у нас impression based. Т. е. замість того, щоб збільшувати кількість серверів у 30 разів, їх вдалося зменшити.
І останній приклад – це фінансова компанія Y, яка аналізувала кореляцію змін котирувань акцій.
І завдання стояло таке:
- Є приблизно 5 акцій.
- Котирування кожні 100 мілісекунди відомі.
- Дані нагромадилися за 10 років. Мабуть, для деяких компаній більше, для деяких менше.
- Усього приблизно 100 мільярдів рядків.
І треба було порахувати кореляцію змін.
Тут є дві акції та їх котирування. Якщо одна йде вгору, і друга йде вгору, це позитивна кореляція, т. е. одна росте, і друга росте. Якщо одна йде вгору, як наприкінці графіка, а друга вниз, це негативна кореляція, т. е. коли одна росте, інша падає.
Аналізуючи ці взаємні зміни, можна робити передбачення на фінансовому ринку.
Але завдання складне. Що для цього робиться? У нас є 100 мільярдів записів, у яких є час, акція та ціна. Нам потрібно порахувати спочатку 100 мільярдів разів, що регулюютьвідмінність від алгоритму ціни. RunningDifference - це функція в ClickHouse, яка різницю між двома рядками послідовно обчислює.
А після цього треба порахувати кореляцію, причому кореляцію треба порахувати кожної пари. Для 5 акцій пар 000 мільйонів. І це багато, тобто 12,5 разів треба обчислювати таку функцію кореляції.
І якщо хтось забув, то X і Y – це мат. очікування на вибірку. Т. е. потрібно не тільки коріння та суми порахувати, а ще всередині цих сум ще одні суми. Купу-купу обчислень потрібно зробити 12,5 мільйонів разів, та ще й згрупувати за годинами треба. А годинників у нас теж чимало. І встигнути треба за 60 секунд. Це жарт.
Треба було встигнути хоч якось, тому що все це працювало дуже повільно, перш ніж прийшов ClickHouse.
Вони намагалися на Hadoop це порахувати, на Spark, на Greenplum. І все це було дуже повільно чи дорого. Т. е. можна було якось порахувати, але потім це було дорого.
А потім прийшов ClickHouse і все стало набагато краще.
Нагадую, проблема у нас із локальністю даних, тому кореляції не можна локалізувати. Ми не можемо скласти частину даних на один сервер, частину на інший і порахувати, у нас мають бути всі дані скрізь.
Що вони зробили? Спочатку дані локалізовані. На кожному із серверів зберігаються дані щодо прайсингу певного набору акцій. І вони не перетинаються. Тому можна паралельно і незалежно порахувати logReturn, все це відбувається поки що паралельно і розподілено.
Далі вирішили ці дані зменшити, не втративши виразності. Зменшити за допомогою масивів, тобто для кожного відрізку часу зробити масив акцій та масив цін. Таким чином, це займає набагато менше місця дані. І з ними дещо зручніше працювати. Це майже паралельні операції, тобто ми паралельно частково рахуємо і потім записуємо на сервер.
Після цього це можна среплікувати. Літера "r" означає, що ці дані ми среплікували. Т. е. у нас на всіх трьох серверах однакові дані - ось ці масиви.
І далі спеціальним скриптом із цього набору 12,5 мільйонів кореляцій, які треба порахувати, можна зробити пакети. Т. е. 2 500 завдань по 5 000 пар кореляцій. І це завдання обчислювати на конкретному ClickHouse-сервері. Всі дані у нього є, тому що дані однакові і він може їх послідовно обчислювати.
Ще раз, як це виглядає. Спочатку у нас усі дані є у такій структурі: час, акції, ціна. Потім ми порахували logReturn, тобто дані тієї ж структури, тільки замість ціни у нас вже logReturn. Потім їх переробили, тобто у нас вийшли час і groupArray за акціями та прайсами. Среплікували. І після цього згенерували купу завдань і згодували ClickHouse, щоб він їх рахував. І це працює.
На proof of concept завдання – це було підзавдання, тобто взяли менше даних. І лише на трьох серверах.
Перші ці два етапи: обчислення Log_return і загортання в масиви зайняли приблизно годину.
А обчислення кореляції десь 50 годин. Але 50 годин – це мало, бо раніше вони це працювали тижнями. То справді був великий успіх. І якщо порахувати, то 70 разів на секунду на цьому кластері все вважалося.
Але найголовніше, що ця система практично без вузьких місць, тобто вона масштабується практично лінійно. І вони це перевірили. Успішно її відмасштабували.
- Правильна схема – половина успіху. І правильна схема – це використання всіх необхідних технологій ClickHouse.
- Summing/AggregatingMergeTrees – це технології, які дозволяють агрегувати або вважати снапшот state як окремий випадок. І це суттєво спрощує багато речей.
- Materialized Views дозволяють обійти обмеження в один індекс. Можливо, я це не дуже чітко промовив, але коли ми завантажували логи, то сирі логи були в таблиці з одним індексом, а на attribute логи були в таблиці, тобто ті самі дані, тільки відфільтровані, але індекс був абсолютно іншим. Начебто одні й ті самі дані, але різне сортування. І Materialized Views дозволяє, якщо вам це потрібно, обійти таке обмеження ClickHouse.
- Зменшуйте гранулярність індексу для точкових запитів.
- І розподіляйте дані розумно, намагайтеся максимально локалізувати дані всередині сервера. І намагайтеся, щоб запити також використовували локалізацію там, де це можливо максимально.
І резюмуючи цей невеликий виступ, можна сказати, що ClickHouse зараз твердо зайняв територію і комерційних баз даних, і Open Source баз даних, тобто саме для аналітики. Він чудово вписався у цей ландшафт. І більше того, він потихеньку починає інших витісняти, тому що, коли є ClickHouse, то вам не потрібен InfiniDB. Вертика, можливо, скоро буде непотрібна, якщо вони зроблять нормальну підтримку SQL. Користуйтесь!
-Дякую за доповідь! Дуже цікаво! Чи були порівняння з Apache Phoenix?
-Ні, я не чув, щоб хтось порівнював. Ми і Яндекс намагаємось відстежувати всі порівняння ClickHouse з різними базами даних. Тому що якщо раптом щось виявляється швидше за ClickHouse, то Льоша Міловидов не може спати ночами і починає швиденько його прискорювати. Я не чув про таке порівняння.
-
(Олексій Міловидов) Apache Phoenix - це SQL-движок на Hbase. Hbase переважно призначений для сценарію робіт типу key-value. Там у кожному рядку може бути довільна кількість стовпців із довільними іменами. Це можна сказати про такі системи як Hbase, Cassandra. І на них саме важкі аналітичні запити нормально не працюватимуть. Або ви можете подумати, що вони працюють нормально, якщо у вас не було жодного досвіду роботи з ClickHouse.
-
Дякуємо
-
Добридень! Я вже чимало цікавлюся цією темою, тому що в мене підсистема аналітична. Але коли я дивлюся на ClickHouse, у мене виникає відчуття, що ClickHouse дуже добре підходить для аналізу івентів, mutable. І якщо мені потрібно аналізувати багато бізнес даних з купою великих таблиць, то ClickHouse, наскільки я розумію, мені не дуже підходить? Особливо якщо вони змінюються. Правильно це чи є приклади, які можуть спростувати це?
-
Це правильно. І це правда про більшість спеціалізованих аналітичних баз даних. Вони заточені під те, що є одна або кілька великих таблиць, які є mutable, і під багато маленьких, які повільно змінюються. Т. е. ClickHouse не як Oracle, куди можна покласти все і будувати якісь дуже складні запити. Для того, щоб ClickHouse ефективно використовувати, треба схему вибудовувати тим чином, який у ClickHouse добре працює. Т. е. уникати зайвої нормалізації, використовувати словники, намагатися робити менше довгих зв'язків. І якщо схему таким чином вибудувати, то тоді аналогічні бізнес-завдання на ClickHouse можуть бути вирішені набагато ефективніше, ніж традиційна реляційна база даних.
-
Дякую за доповідь! У мене питання щодо останнього фінансового кейсу. Вони мали аналітику. Потрібно було порівняти, як йдуть вгору-вниз. І я так розумію, що ви систему збудували саме під цю аналітику? Якщо їм завтра, припустимо, знадобиться якийсь інший звіт за цими даними, чи потрібно заново схему будувати і завантажувати дані? Т. е. робити якусь передобробку, щоб отримати запит?
Звичайно, це використання ClickHouse для цілком конкретного завдання. Вона більш традиційно могла бути вирішена в рамках Hadoop. Для Hadoop це ідеальне завдання. Але на Hadoop це дуже повільно. І моя мета - продемонструвати те, що на ClickHouse можна вирішувати завдання, які зазвичай вирішуються зовсім іншими засобами, але при цьому зробити набагато ефективніше. Це під конкретне завдання уточнено. Зрозуміло, що якщо є завдання чимось схоже, то його можна схожим чином вирішувати.
Зрозуміло. Ви сказали, що 50 годин обробляли. Це з самого початку, коли завантажили дані або отримали результати?
Так Так.
Добре спасибі велике.
Це на 3-х серверному кластері.
Вітаю! Дякую за доповідь! Все дуже цікаво. Я трохи не про функціонал спитаю, а про використання ClickHouse з точки зору стабільності. Т. е. чи траплялися у вас якісь, чи доводилося відновлювати? Як при цьому поводиться ClickHouse? І чи траплялося так, що у вас вилітала і репліка навіть? Ми, скажімо, у ClickHouse стикалися з проблемою, коли він вилазить все-таки за свій ліміт і падає.
Звісно, ідеальних систем немає. І ClickHouse теж має свої проблеми. Але чи ви чули про те, щоб Яндекс.Метрика довго не працювала? Напевно ні. Вона працює надійно десь із 2012-2013-го року на ClickHouse. Про мій досвід я також можу сказати. У нас ніколи не було повних відмов. Якісь часткові речі могли траплятися, але вони ніколи не були такими критичними, щоб серйозно вплинути на бізнес. Ніколи такого не було. ClickHouse - досить надійний і не падає випадковим чином. Можна про це не перейматися. Це не сира річ. Це підтверджено багатьма компаніями.
Вітаю! Ви сказали, що потрібно одразу добре продумати схему даних. А якщо це сталося? У мене дані ллються-ллються. Минає півроку, і я розумію, що так жити не можна, мені треба перезаливати дані та щось із ними робити.
Це, звичайно, залежить від вашої системи. Є кілька способів зробити це майже без зупинки. Наприклад, ви можете створити Materialized View, в якому можна зробити іншу структуру даних, якщо її можна однозначно змапувати. Т. е. якщо вона допускає мапірування засобами ClickHouse, тобто extract якихось речей, поміняти primary key, поміняти партиціонування, то можна зробити Materialized View. Туди ваші старі дані переписати, нові будуть писати автоматично. А потім просто перейти на використання Materialized View, потім переключити запис і стару таблицю вбити. Це взагалі без зупинки спосіб.
Спасибо.
Джерело: habr.com