儘管現在幾乎到處都有大量數據，但分析數據庫仍然很奇特。 它們鮮為人知，更糟糕的是無法有效地使用它們。 許多人繼續用專為其他場景設計的 MySQL 或 PostgreSQL “吃仙人掌”，用 NoSQL 吃虧，或者為商業解決方案多付錢。 ClickHouse 改變了遊戲規則，顯著降低了進入分析型 DBMS 世界的門檻。
來自 BackEnd Conf 2018 的報告，經演講者許可發布。
我是誰，我為什麼要談論 ClickHouse？ 我是 LifeStreet 的開發總監，該公司使用 ClickHouse。 另外，我是 Altinity 的創始人。 是推廣ClickHouse的Yandex合作夥伴，幫助Yandex讓ClickHouse更加成功。 也準備分享有關 ClickHouse 的知識。
而且我不是 Petya Zaitsev 的兄弟。 我經常被問到這個問題。 不，我們不是兄弟。
“每個人都知道”ClickHouse：
- 非常快，
- 非常舒服
- 在 Yandex 中使用。
對哪些公司以及如何使用它知之甚少。
我會告訴你為什麼、在哪里以及如何使用 ClickHouse，除了 Yandex。
我會告訴你在不同的公司如何借助 ClickHouse 解決具體的任務，你的任務可以使用哪些 ClickHouse 工具，以及它們在不同的公司是如何使用的。
我選擇了三個從不同角度展示 ClickHouse 的示例。 我認為這會很有趣。
第一個問題是：“為什麼我們需要 ClickHouse？”。 這似乎是一個相當明顯的問題，但有不止一個答案。
- 第一個答案是性能。 ClickHouse 非常快。 ClickHouse 上的分析也非常快。 它通常可以用在其他東西非常慢或非常糟糕的地方。
- 第二個答案是成本。 首先，擴展成本。 例如，Vertica 是一個非常棒的數據庫。 如果您沒有大量的 TB 數據，它會很好地工作。 但是當涉及到數百 TB 或 PB 時，許可和支持的成本就相當可觀了。 而且很貴。 ClickHouse 是免費的。
- 第三個答案是運營成本。 這是一種略有不同的方法。 RedShift 是一個很好的模擬。 在 RedShift 上，您可以非常快速地做出決定。 它會運作良好，但與此同時，每小時、每天和每月，您都會向亞馬遜支付相當高的費用，因為這是一項非常昂貴的服務。 谷歌 BigQuery 也是。 如果有人使用它，那麼他就會知道您可以在那裡運行多個請求並突然收到數百美元的賬單。
ClickHouse 不存在這些問題。
ClickHouse現在用在什麼地方？ 除了 Yandex 之外，ClickHouse 還用於許多不同的企業和公司。
- 首先，這是 Web 應用程序分析，即這是來自 Yandex 的用例。
- 許多 AdTech 公司使用 ClickHouse。
- 許多公司需要分析來自不同來源的事務日誌。
- 一些公司使用 ClickHouse 來監控安全日誌。 他們將它們上傳到 ClickHouse，製作報告，並獲得他們需要的結果。
- 公司開始將其用於財務分析，即大企業也逐漸接近 ClickHouse。
- 雲耀斑。 如果有人關注 ClickHouse，那麼他們很可能聽說過這家公司的名字。 這是來自社區的重要貢獻者之一。 他們有一個非常認真的 ClickHouse 安裝。 例如，他們為 ClickHouse 製作了 Kafka Engine。
- 電信公司開始使用。 一些公司使用 ClickHouse 作為概念驗證或已經投入生產。
- 一家公司使用 ClickHouse 來監控生產流程。 他們測試微電路，註銷一堆參數，大約有 2 個特徵。 然後他們分析遊戲是好是壞。
- 區塊鏈分析。 有一家俄羅斯公司，如 Bloxy.info。 這是對以太坊網絡的分析。 他們也在 ClickHouse 上這樣做了。
而且大小無關緊要。 有許多公司使用一台小型服務器。 他允許他們解決他們的問題。 甚至更多的公司使用由許多服務器或數十台服務器組成的大型集群。
如果你查看記錄，那麼：
- Yandex：500 多台服務器，他們每天在那裡存儲 25 億條記錄。
- LifeStreet：60 台服務器，每天大約 75 億條記錄。 與 Yandex 相比，服務器更少，記錄更多。
- CloudFlare：36台服務器，他們每天保存200億條記錄。 他們擁有更少的服務器並存儲更多的數據。
- Bloomberg：102 台服務器，每天大約有 XNUMX 萬億個條目。 紀錄保持者。
從地理上講，這也很多。 此處的這張地圖顯示了世界上使用 ClickHouse 的地方的熱圖。 俄羅斯、中國、美國在這裡非常突出。 歐洲國家很少。 並且有4個集群。
這是比較分析，不需要找絕對數字。 這是對在 Altinity 網站上閱讀英文材料的訪問者的分析，因為那裡沒有俄語材料。 而俄羅斯、烏克蘭、白俄羅斯，即社區中講俄語的部分，這些是最多的用戶。 然後是美國和加拿大。 中國正在迎頭趕上。 六個月前那裡幾乎沒有中國，現在中國已經超過歐洲並繼續增長。 老歐洲也不甘落後，奇怪的是，法國是 ClickHouse 使用的領導者。
我為什麼要說這一切？ 表明ClickHouse正在成為大數據分析的標準方案，並且已經在很多地方得到應用。 如果你使用它，你就處於正確的趨勢中。 如果您還沒有使用它，那麼您不必擔心自己會孤單，沒有人會幫助您，因為很多人已經在這樣做了。
這些是幾家公司實際使用 ClickHouse 的例子。
- 第一個例子是廣告網絡：從 Vertica 遷移到 ClickHouse。 我知道一些公司已經從 Vertica 轉型或正在轉型。
- 第二個例子是 ClickHouse 上的事務存儲。 這是一個建立在反模式之上的例子。 根據開發人員的建議，不應在 ClickHouse 中完成的所有操作都在這裡完成。 而且它做得如此有效以至於它起作用了。 而且它比典型的交易解決方案效果更好。
- 第三個例子是ClickHouse上的分佈式計算。 有一個問題是如何將 ClickHouse 集成到 Hadoop 生態系統中。 我將展示一個公司如何在 ClickHouse 上做類似於 map reduce 容器的事情，跟踪數據本地化等，以計算一個非常重要的任務。
- LifeStreet 是一家廣告技術公司，擁有廣告網絡附帶的所有技術。
- 她從事廣告優化、程序化競價。
- 大量數據：每天約有 10 億個事件。 同時，賽事又可以分為若干個子賽事。
- 這些數據有很多客戶，這些客戶不僅是人，還有更多 - 這些是參與程序化競價的各種算法。
公司走過了一條漫長而充滿荊棘的道路。 我在 HighLoad 上談到了它。 首先，LifeStreet 從 MySQL（短暫停留在 Oracle）遷移到 Vertica。 你可以找到一個關於它的故事。
一切都很好，但很快就發現數據在增長，而 Vertica 很昂貴。 因此，尋求各種替代方案。 其中一些列在這裡。 事實上，我們對從第 13 年到第 16 年市場上幾乎所有可用的數據庫進行了概念驗證或有時性能測試，並且在功能方面大致合適。 我還在 HighLoad 上談到了其中的一些。
任務首先是從 Vertica 遷移，因為數據在增長。 多年來，它們呈指數級增長。 然後他們上架了，但仍然如此。 並且預測這種增長，需要進行某種分析的數據量的業務需求，很明顯很快就會討論 PB 級。 為 PB 支付費用已經非常昂貴，因此我們正在尋找替代方案。
去哪兒？ 很長一段時間都不清楚去哪裡，因為一方面有商業數據庫，它們似乎運作良好。 有些幾乎和 Vertica 一樣好，有些更差。 但它們都很貴，找不到更便宜更好的了。
另一方面，有開源解決方案，數量不是很多，即對於分析，它們可以在手指上計算。 它們免費或便宜，但速度慢。 而且它們通常缺乏必要和有用的功能。
並且沒有什麼可以將商業數據庫中的優點與開源中的所有免費結合起來。
直到，Yandex 出乎意料地把 ClickHouse 拉了出來，就像戴帽子的魔術師，像兔子一樣。 這是一個出乎意料的決定，他們仍然會問這個問題：“為什麼？”，但是儘管如此。
就在 2016 年夏天，我們開始研究什麼是 ClickHouse。 事實證明，有時它可以比 Vertica 更快。 我們針對不同的請求測試了不同的場景。 而如果查詢只使用一張表，即沒有任何連接（join），那麼 ClickHouse 的速度是 Vertica 的兩倍。
我不太懶惰，前幾天看了 Yandex 測試。 那裡也一樣：ClickHouse 的速度是 Vertica 的兩倍，因此他們經常談論它。
但是如果查詢中有連接，那麼一切都不是很明確。 而且 ClickHouse 的速度可能是 Vertica 的兩倍。 如果您稍微更正請求並重寫它，那麼它們大致相等。 不錯。 並且免費。
LifeStreet 收到測試結果並從不同角度進行了審視後，選擇了 ClickHouse。
這是第 16 個年頭，我提醒你。 這就像一個關於老鼠的笑話，它們哭泣並刺傷自己，但繼續吃仙人掌。 並且對此進行了詳細描述，有關於此的視頻等。
所以，我就不詳細講了，只講結果和當時沒講的幾件有趣的事。
結果是：
- 成功遷移和一年多的系統已經在生產中運行。
- 生產率和靈活性有所提高。 在我們每天可以存儲 10 億條記錄並存儲很短時間的情況下，LifeStreet 現在每天存儲 75 億條記錄，並且可以存儲 3 個月或更長時間。 如果按峰值計算，那麼這高達每秒 XNUMX 萬個事件。 每天有超過一百萬個 SQL 查詢到達該系統，大部分來自不同的機器人。
- 儘管 ClickHouse 使用的服務器多於 Vertica，但它們也節省了硬件，因為 Vertica 使用了相當昂貴的 SAS 磁盤。 ClickHouse 使用 SATA。 為什麼？ 因為在 Vertica 中插入是同步的。 而同步要求磁盤不要減慢太多，網絡也不要減慢太多，這是一個相當昂貴的操作。 而在 ClickHouse 中插入是異步的。 此外，您始終可以在本地編寫所有內容，這不會產生額外費用，因此即使在較慢的驅動器上，也可以比 Vertika 更快地將數據插入 ClickHouse。 閱讀也差不多。 在 SATA 上讀取，如果它們在 RAID 中，那麼這一切都足夠快。
- 不受許可證限制，即 3 台服務器中的 60 PB 數據（20 台服務器是一個副本）和事實和聚合中的 6 萬億條記錄。 Vertica 無法提供這樣的服務。
在這個例子中，我現在轉向實際的事情。
- 首先是高效的方案。 很大程度上取決於架構。
- 二是高效的SQL生成。
典型的 OLAP 查詢是選擇。 一些列用於分組，一些列用於聚合函數。 有一個地方，可以表示為立方體的一部分。 整個 group by 可以被認為是一個投影。 這就是為什麼它被稱為多元數據分析。
通常這是以星圖的形式建模的，當沿著光線的兩側有一個中心事實和這個事實的特徵時。
就物理設計而言，它如何適合桌面，他們通常會進行標準化表示。 您可以進行非規範化，但它在磁盤上的開銷很大，而且查詢效率不高。 因此，他們通常會做一個規範化的表示，即一個事實表和很多很多維表。
但它在 ClickHouse 中效果不佳。 原因有二：
- 第一個是因為 ClickHouse 沒有很好的連接，即有連接，但它們很糟糕。 雖然不好。
- 第二個是表沒有更新。 通常在星形電路周圍的這些板中，需要進行一些更改。 例如，客戶名稱、公司名稱等。 它不起作用。
在 ClickHouse 中有一個解決這個問題的方法。 甚至兩個：
- 首先是字典的使用。 外部詞典可以幫助 99% 解決星型模式、更新等問題。
- 二是數組的使用。 數組還有助於擺脫連接和規範化問題。
- 無需加入。
- 可升級。 自 2018 年 XNUMX 月以來，出現了一個未記錄的機會（您不會在文檔中找到它）來部分更新字典，即那些已更改的條目。 實際上，它就像一張桌子。
- 總是在內存中，所以與字典的連接比它是磁盤上的表更快，而且它還不是在緩存中的事實，很可能不是。
- 你也不需要加入。
- 這是一個緊湊的一對多表示。
- 在我看來，數組是為極客設計的。 這些是 lambda 函數等等。
這不是紅色的字眼。 這是一個非常強大的功能，允許您以非常簡單和優雅的方式做很多事情。
有助於求解數組的典型示例。 這些示例足夠簡單明了：
- 按標籤搜索。 如果您在那裡有主題標籤並且想通過主題標籤查找一些帖子。
- 按鍵值對搜索。 還有一些具有值的屬性。
- 存儲需要轉換成其他內容的密鑰列表。
所有這些任務都可以在沒有數組的情況下解決。 標籤可以放在某行中並使用正則表達式或在單獨的表中選擇，但是您必須進行連接。
而在 ClickHouse 中，你不需要做任何事情，為 hashtags 描述字符串數組或者為鍵值系統做一個嵌套結構就足夠了。
嵌套結構可能不是最好的名字。 這兩個數組在名稱和一些相關特徵上具有共同部分。
而且很容易按標籤搜索。 有功能 has，它檢查數組是否包含一個元素。 每個人，找到與我們會議相關的所有條目。
按 subid 搜索有點複雜。 我們需要先找到key的索引，然後取出有這個索引的元素，檢查這個值是不是我們需要的。 但是，它非常簡單緊湊。
如果將所有內容都放在一行中，您想要編寫的正則表達式首先會很笨拙。 其次，它的工作時間比兩個陣列長得多。
另一個例子。 您有一個存儲 ID 的數組。 你可以把它們翻譯成名字。 功能 arrayMap. 這是一個典型的 lambda 函數。 你在那里傳遞 lambda 表達式。 然後她從字典中提取每個 ID 的名稱值。
可以用同樣的方式進行搜索。 傳遞一個謂詞函數來檢查元素匹配的內容。
這些東西大大簡化了電路，解決了一堆問題。
但我們面臨的下一個問題是高效查詢，我想提一下。
- ClickHouse 沒有查詢規劃器。 絕對不。
- 儘管如此，仍然需要計劃複雜的查詢。 在哪些情況下？
- 如果查詢中有多個連接，則將它們包裝在子選擇中。 它們的執行順序很重要。
- 第二個 - 如果請求已分發。 因為在分佈式查詢中，只有最裡面的 subselect 被分佈式執行，其他所有內容都傳遞給您連接到的一台服務器並在那裡執行。 因此，如果你有很多連接（join）的分佈式查詢，那麼你需要選擇順序。
甚至在更簡單的情況下，有時也需要做調度程序的工作並稍微重寫查詢。
這是一個例子。 左側是顯示前 5 個國家/地區的查詢。 在我看來，這需要 2,5 秒。 在右側，相同的查詢，但略有重寫。 我們不再按字符串分組，而是開始按鍵 (int) 分組。 而且速度更快。 然後我們將字典連接到結果。 該請求需要 2,5 秒，而不是 1,5 秒。 這很好。
重寫過濾器的類似示例。 這是對俄羅斯的要求。 它運行 5 秒。 如果我們以這樣一種方式重寫它，我們再次比較的不是字符串，而是與俄羅斯相關的一組鍵的數字，那麼它會快得多。
有很多這樣的技巧。 它們允許您顯著加快您認為已經運行得很快，或者相反，運行緩慢的查詢。 它們可以做得更快。
- 分佈式模式下的最大工作量。
- 按最小類型排序，就像我按整數排序一樣。
- 如果有任何連接（join），字典，那麼最好將它們作為最後的手段，當你已經有至少部分分組的數據時，連接操作或字典調用將被調用更少的次數並且會更快.
- 更換過濾器。
還有其他技術，而不僅僅是我已經演示過的技術。 所有這些有時都可以顯著加快查詢的執行速度。
讓我們繼續下一個例子。 來自美國的X公司。 她在做什麼？
有一個任務：
- 廣告交易的離線鏈接。
- 對不同的綁定模型進行建模。
場景是什麼？
例如，普通訪問者每月通過不同的廣告訪問該網站 20 次，或者有時沒有任何廣告，因為他記得該網站。 查看一些產品，將它們放入籃子中，然後將它們從籃子中取出。 而且，最後，有些東西買了。
合理的問題：“如果有必要，誰應該支付廣告費用？” 和“什麼廣告影響了他，如果有的話？”。 也就是說，他為什麼要買，如何讓像這個人這樣的人也買？
為了解決這個問題，您需要以正確的方式將網站上發生的事件聯繫起來，即以某種方式在它們之間建立聯繫。 然後將它們發送到 DWH 進行分析。 並基於此分析，構建要展示誰和展示什麼廣告的模型。
廣告交易是一組相關的用戶事件，從顯示廣告開始，然後發生某些事情，然後可能是購買，然後可能在購買中進行購買。 例如，如果這是一個移動應用程序或一個移動遊戲，那麼應用程序的安裝通常是免費的，如果在那裡做了一些事情，那麼這可能需要錢。 一個人在應用程序中花費的越多，它就越有價值。 但是為此，您需要連接所有東西。
有許多綁定模型。
最受歡迎的是：
- 最後一次互動，其中互動是點擊或展示。
- 第一次互動，即把人帶到網站的第一件事。
- 線性組合 - 都相等。
- 衰減。
- 等等。
這一切最初是如何運作的？ 有 Runtime 和 Cassandra。 Cassandra 被用作交易存儲，即所有相關交易都存儲在其中。 當運行時發生某些事件時，例如，顯示某個頁面或其他內容，然後向 Cassandra 發出請求 - 是否有這樣的人。 然後獲得了與之相關的交易。 並建立了聯繫。
如果幸運的是請求有一個事務 id，那就很容易了。 但通常沒有運氣。 因此，需要找到最後一筆交易或最後一次點擊的交易等。
只要綁定到最後一次點擊，這一切都非常有效。 因為如果我們設置一個窗口為一個月，那麼每天有 10 萬次點擊，每月有 300 億次點擊。 而且由於在 Cassandra 中它必須全部在內存中才能快速運行，因為 Runtime 需要快速響應，因此大約需要 10-15 個服務器。
當他們想將交易鏈接到顯示時，結果立即變得不那麼有趣。 為什麼？ 可以看出需要存儲30倍以上的事件。 因此，您需要多出 30 倍的服務器。 事實證明，這是某種天文數字。 為了進行鏈接而保留多達 500 個服務器，儘管運行時中的服務器明顯較少，但這是某種錯誤的數字。 他們開始考慮該怎麼做。
我們去了 ClickHouse。 以及如何在 ClickHouse 上進行？ 乍一看，這似乎是一組反模式。
- 事務增長，我們將越來越多的事件連接到它，即它是可變的，而 ClickHouse 不能很好地處理可變對象。
- 當訪客來找我們時，我們需要通過他的訪問 ID 通過密鑰提取他的交易。 這也是一個點查詢，他們不會在 ClickHouse 中這樣做。 通常 ClickHouse 有大...掃描，但這裡我們需要獲取一些記錄。 也是一種反模式。
- 另外，交易是json的，但是他們不想重寫，所以想把json非結構化的存儲起來，如果有必要，再從裡面拉出一些東西來。 這也是一種反模式。
即，一組反模式。
但儘管如此，事實證明它是一個運行良好的系統。
做了什麼？ ClickHouse 出現了，日誌被扔進裡面，分成記錄。 出現了一個屬性服務，它從 ClickHouse 接收日誌。 之後，對於每個條目，通過訪問 ID，我收到可能尚未處理的交易以及快照，即已經連接的交易，即先前工作的結果。 我已經從中得出邏輯，選擇了正確的交易，連接了新事件。 再次登錄。 日誌返回到 ClickHouse，即它是一個不斷循環的系統。 此外，我去了 DWH 在那裡進行分析。
正是在這種形式下，它並沒有很好地發揮作用。 為了讓 ClickHouse 更容易，當有訪問 ID 請求時，他們將這些請求分組為 1-000 個訪問 ID 的塊，並提取 2-000 人的所有交易。 然後一切都奏效了。
如果您查看 ClickHouse 內部，那麼只有 3 個主表提供所有這些服務。
第一個上傳日誌的表，日誌幾乎不做任何處理就上傳了。
第二張桌子。 通過物化視圖，從這些日誌中，尚未歸因的事件，即不相關的事件，被咬掉了。 並通過物化視圖，從這些日誌中提取事務以構建快照。 也就是說，一個特殊的物化視圖構建了一個快照，即事務的最後累積狀態。
這是用 SQL 編寫的文本。 我想評論其中的一些重要內容。
第一個重要的是能夠從 ClickHouse 中的 json 中提取列和字段。 也就是說，ClickHouse 有一些處理 json 的方法。 他們非常非常原始。
visitParamExtractInt 允許您從 json 中提取屬性，即第一個命中有效。 通過這種方式，您可以提取交易 ID 或訪問 ID。 這次。
其次，這裡使用了一個棘手的物化場。 這是什麼意思？ 這意味著你不能將它插入到表中，即它沒有被插入，它是在插入時計算和存儲的。 粘貼時，ClickHouse 會為您完成工作。 而你後面需要的已經從json中拉出來了。
在這種情況下，實體化視圖用於原始行。 並且剛剛使用了第一個包含實際原始日誌的表。 他做什麼？ 首先，它改變了排序，即現在按訪問 id 排序，因為我們需要快速提取特定人的交易。
第二個重要的事情是 index_granularity。 如果你看過 MergeTree，默認情況下它通常是 8 index_granularity。 這是什麼？ 這是索引稀疏參數。 在 ClickHouse 中，索引是稀疏的，它從不索引每個條目。 它每 192 次執行一次。當需要計算大量數據時，這樣做很好，但如果需要計算的數據很少，則不好，因為開銷很大。 如果我們降低索引粒度，那麼我們就減少了開銷。 它不能減少到一個，因為可能內存不夠。 索引始終存儲在內存中。
Snapshot 還使用了一些其他有趣的 ClickHouse 功能。
首先，它是 AggregatingMergeTree。 而 AggregatingMergeTree 存儲 argMax，即這是與最後一個時間戳對應的交易狀態。 對於給定的訪問者，交易一直在生成。 在這個交易的最後一個狀態中，我們添加了一個事件，我們有了一個新狀態。 它再次擊中了 ClickHouse。 而通過這個物化視圖中的argMax，我們總能得到當前狀態。
- 綁定與運行時“解耦”。
- 每月存儲和處理多達 3 億筆交易。 這比在 Cassandra 中，即在典型的事務系統中，多了一個數量級。
- 2x5 ClickHouse 服務器集群。 5台服務器，每台服務器有一個副本。 這甚至比在 Cassandra 中進行基於點擊的歸因還要少，而這裡我們使用的是基於印象的歸因。 也就是說，他們沒有將服務器數量增加 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 個任務。 而這個任務是要在特定的ClickHouse服務器上計算的。 他有所有的數據，因為數據是一樣的，他可以依次計算。
再一次，這就是它的樣子。 首先，我們擁有此結構中的所有數據：時間、股票、價格。 然後我們計算 logReturn，即相同結構的數據，但我們已經有 logReturn 而不是價格。 然後他們被重做，即我們得到了時間和 groupArray 的股票和價格。 複製。 之後，我們生成了一堆任務並將它們提供給 ClickHouse，以便它對它們進行計數。 它有效。
在概念驗證中，該任務是一個子任務，即使用的數據較少。 而且只有三台服務器。
前兩個階段：計算 Log_return 和包裝在數組中大約需要一個小時。
而相關性的計算大約需要50個小時。 但 50 小時是不夠的，因為他們過去常常工作數週。 這是一個巨大的成功。 如果你數一數，那麼每秒 70 次所有東西都被計算在這個集群上。
但最重要的是這個系統幾乎沒有瓶頸，即它幾乎是線性擴展的。 他們檢查過了。 成功擴大規模。
- 正確的方案是成功的一半。 正確的方案是使用所有必要的 ClickHouse 技術。
- Summing/AggregatingMergeTrees 是允許您聚合或將狀態快照視為特例的技術。 它極大地簡化了很多事情。
- 物化視圖允許您繞過一個索引限制。 可能我沒說的很清楚，但是我們加載日誌的時候，原始日誌在一個索引的表中，屬性日誌在表中，即相同的數據，只是過濾，但是索引是完整的其他的。 好像是一樣的數據，只是排序不同。 如果需要，實體化視圖允許您繞過此類 ClickHouse 限制。
- 降低點查詢的索引粒度。
- 並巧妙地分發數據，盡量將數據本地化在服務器內部。 並儘量確保請求也盡可能使用本地化。
總結一下這個簡短的演講，我們可以說ClickHouse現在已經牢牢佔據了商業數據庫和開源數據庫的領地，即專門用於分析。 他非常適合這片風景。 而且，它慢慢地開始排擠其他人，因為當您擁有 ClickHouse 時，您就不需要 InfiniDB。 如果 Vertika 提供正常的 SQL 支持，可能很快就不需要它們了。 享受！
- 感謝您的報告！ 很有意思！ 與 Apache Phoenix 有什麼比較嗎？
不，我還沒有聽到有人比較過。 我們和 Yandex 試圖跟踪所有 ClickHouse 與不同數據庫的比較。 因為如果突然發現某些東西比 ClickHouse 更快，那麼 Lesha Milovidov 晚上睡不著覺並開始快速加速。 我沒有聽說過這樣的比較。
-
(Aleksey Milovidov) Apache Phoenix 是一個基於 Hbase 的 SQL 引擎。 Hbase主要針對key-value工作場景。 在每一行中，可以有任意數量的具有任意名稱的列。 對於 Hbase、Cassandra 等系統，可以這樣說。 正是繁重的分析查詢對他們來說無法正常工作。 或者，如果您沒有任何使用 ClickHouse 的經驗，您可能會認為它們工作正常。
-
謝謝
-
下午好我已經對這個話題很感興趣了，因為我有一個分析子系統。 但是看了ClickHouse，感覺ClickHouse很適合做事件分析，mutable。 而如果我需要用一堆大表來分析大量的業務數據，那麼ClickHouse，據我了解是不是很適合我？ 特別是如果他們改變了。 這是正確的還是有可以反駁這一點的例子？
-
這是對的。 大多數專業分析數據庫都是如此。 它們是為一個或多個可變的大表以及許多變化緩慢的小表而量身定制的。 也就是說，ClickHouse 不像 Oracle，您可以在其中放置所有內容並構建一些非常複雜的查詢。 為了有效地使用 ClickHouse，您需要以在 ClickHouse 中運行良好的方式構建方案。 即避免過度歸一化，使用詞典，盡量少做長鏈接。 而如果按照這種方式構建方案，那麼類似的業務任務在 ClickHouse 上可以比在傳統的關係數據庫上更高效地解決。
-
感謝您的報告！ 我有一個關於最新財務案例的問題。 他們有分析。 有必要比較一下它們是如何上升和下降的。 我知道你專門為這個分析構建了系統？ 例如，如果明天他們需要關於此數據的一些其他報告，他們是否需要重新構建模式並上傳數據？ 也就是說，做某種預處理來獲取請求？
當然，這是將 ClickHouse 用於一個非常具體的任務。 它可以更傳統地在 Hadoop 中解決。 對於 Hadoop，這是一項理想的任務。 但是在 Hadoop 上它非常慢。 我的目標是證明 ClickHouse 可以解決通常通過完全不同的方式解決的任務，但同時更有效地完成它。 這是為特定任務量身定制的。 很明顯，如果類似的東西有問題，那麼可以用類似的方法解決。
天氣晴朗。 你說處理了 50 個小時。 是從一開始，你什麼時候加載數據或者得到結果？
是的是的。
好的，非常感謝。
這是在一個 3 服務器集群上。
問候！ 感謝您的報告！ 一切都很有趣。 我不會問一點功能，而是在穩定性方面使用ClickHouse。 也就是說，你有沒有，你必須恢復嗎？ 在這種情況下，ClickHouse 的行為如何？ 碰巧你也有一個複製品嗎？ 例如，我們遇到了 ClickHouse 仍然超出其限制並下降的問題。
當然，沒有理想的系統。 而ClickHouse也有自己的問題。 但是您是否聽說過 Yandex.Metrica 長時間無法使用？ 可能不是。 自 2012-2013 年以來，它一直在 ClickHouse 上可靠地工作。 我可以對我的經歷說同樣的話。 我們從未有過徹底的失敗。 一些部分的事情可能會發生，但它們永遠不會嚴重到嚴重影響業務的程度。 它從未發生過。 ClickHouse 非常可靠，不會隨機崩潰。 你不必擔心。 這不是一個原始的東西。 這已被許多公司證明。
你好！ 您說您需要立即考慮數據模式。 如果它發生了怎麼辦？ 我的數據不斷湧入。 六個月過去了，我明白這樣生活是不可能的，我需要重新上傳數據並對它們做點什麼。
這當然取決於您的系統。 有幾種方法可以幾乎不間斷地做到這一點。 例如，您可以創建一個實體化視圖，如果可以唯一映射的話，可以在其中創建不同的數據結構。 也就是說，如果它允許使用 ClickHouse 進行映射，即提取一些東西，更改主鍵，更改分區，那麼您可以製作物化視圖。 在那裡覆蓋舊數據，新數據將自動寫入。 然後切換到使用物化視圖，然後切換記錄並殺死舊表。 這通常是一種不間斷的方法。
謝謝。
來源： www.habr.com