Tag: zookeeper

ClickHouse 自家做的 benchmark 比較

在「Show HN: A benchmark for analytical databases (Snowflake, Druid, Redshift) (clickhouse.com)」這邊看到 ClickHouse 自家做的 benchmark 比較，網站在「ClickBench — a Benchmark For Analytical DBMS」這邊。

這種 benchmark 基本上是拿來當作清單來看，另外 Hacker News 上的討論一定得看，尤其是沒被列上 benchmark 的...

講到 ClickHouse，先前是有朋友跑來說他有個需求是需要跑分析，但遇到用 PostgreSQL 時發現寫入速度不夠快的問題，看看有沒有什麼方法可以解。問了多一點以後發現他的需求是 OLAP 類而不是 OLTP 類，就先跟他講要去找 OLAP engine 來解決。

然後就聊到維基百科上「Comparison of OLAP servers」這個條目，裡面列出來的 open source 軟體是不少，但 Apache 家基本上大家都知道是回收場，裡面就剩下 ClickHouse 比較常在 Hacker News 以及其他地方被提到，但我有跟他講我連玩都沒玩過，我們家自己反而是用 Cassandra 與 Trino 搭出來的，當時沒有花太多時間研究市場上的方案，就挑了一個自己熟悉的方案趕快先解決。

但過了兩天後他就說用 ClickHouse 解決了，反而讓我對 ClickHouse 有興趣起來，反正記憶體當時裝了一堆沒用到。

拉了一下「Summary of the 1.1 Billion Taxi Rides Benchmarks」這邊的資料看，這個作者常常會測各種資料庫，算是一個可以參考的資料來源，可以看到 2019 年測的「1.1 Billion Taxi Rides: 108-core ClickHouse Cluster」其實就相當不錯了？

基本上先照「Usage Recommendations」這邊看一輪，基本的要求不低，但剛好機器是 32GB RAM：

If your system has less than 16 GB of RAM, you may experience various memory exceptions because default settings do not match this amount of memory. The recommended amount of RAM is 32 GB or more. You can use ClickHouse in a system with a small amount of RAM, even with 2 GB of RAM, but it requires additional tuning and can ingest at a low rate.

如果要跑 cluster 模式的話會需要 ZooKeeper 或是替代品 ClickHouse Keeper。

然後除了使用官方的 clickhouse-client 連線以外，也可以用 MySQL 或是 PostgreSQL 的 client 連，裡面操作其實蠻簡單的，好像值得投資看看？

Kafka 拔掉 ZooKeeper 的進展已經進到 trunk

差不多一年前提到了 Kafka 打算拔掉 ZooKeeper 的計畫 (在「Kafka 拔掉 ZooKeeper 的計畫」這邊有提到)，昨天 Confluent 發了一篇進展：「Apache Kafka Made Simple: A First Glimpse of a Kafka Without ZooKeeper」。

這件事情可以在「KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum」這邊看到說明，另外在 Jira 上面則是在 KAFKA-9119 這邊追蹤。

目前的好消息就是 KIP-500 的程式碼都已經推進 trunk，目標在 2.8 釋出時就可以用：

So we’re very pleased to say that the early access of the KIP-500 code has been committed to trunk and is expected to be included in the upcoming 2.8 release.

文件裡面會用「Kafka Raft Metadata mode」或是「KRaft」稱呼這種模式：

For the first time, you can run Kafka without ZooKeeper. We call this the Kafka Raft Metadata mode, typically shortened to KRaft (pronounced like craft) mode.

然後有缺一些功能，另外就是常態性宣導這是測試版，建議不要在 production 環境用：

Beware, there are some features that are not available in this early-access release. We do not yet support the use of ACLs and other security features or transactions. Also, both partition reassignment and JBOD are unsupported in KRaft mode (these are anticipated to be available in an Apache Kafka release later in the year). Hence, consider the quorum controller experimental software—we don’t advise subjecting it to production workloads. If you do try out the software, however, you’ll find a host of new advantages: It’s simpler to deploy and operate, you can run Kafka in its entirety as a single process, and it can accommodate significantly more partitions per cluster (see measurements below).

目前丟出來的測試數據可以看到有大幅改善，但仔細看居然是停機與恢復時間：

不知道實際的效能上有多少影響 (正面或是負面)，還是得等了...

C++ 版本的 Kafka

在 Hacker News 首頁上看到的東西，看起來是 C++ 版本的 Apache Kafka 替代品 Redpanda，要注意的是這不是 open source license 軟體：「Redpanda – A Kafka-compatible streaming platform for mission-critical workloads (vectorized.io)」。

目前網站上可以看到，最主要的特點是不需要 Apache ZooKeeper，不過這點在 Kafka 這邊也正在進行了 (之前在「Kafka 拔掉 ZooKeeper 的計畫」這篇有提到)，雖然進度有點慢...

另外目前完全沒有 benchmark 資料，只有宣稱 10x 更快，官方在 Hacker News 上的回應是說十二月會有公開的測試報告，這樣我會把 10x 當廣告詞看了，應該會更快，但大概是某種特殊情境下才會達到...

Kafka 拔掉 ZooKeeper 的計畫

目前 Kafka cluster 還是會需要透過 ZooKeeper 處理不少資料，但眾所皆知的，ZooKeeper 實在是不好維護，所以 Kafka 官方從好幾年前就一直在想辦法移除對 ZooKeeper 的相依性。

這篇算是其中一塊：「Kafka Needs No Keeper」。

真的自己架過 Kafka cluster 就會知道其中的 ZooKeeper 很不好維護，尤其是 Apache 官方版本的軟體與文件常常脫勾，設定起來就很痛苦。所以一般都會用 Confluent 出的包裝，裡面的 ZooKeeper 軟體與 Confluent 自己寫的文件至少都被測過，不太會遇到官方文件與軟體之間搭不上的問題。

另外一個常見的痛點是，因為 Kafka 推動拔掉 ZooKeeper 的計畫推很久了 (好幾年了)，但進展不快，所以有時候會發現在 command line 下，有些指令會把 API endpoint 指到 ZooKeeper 伺服器上，但有些指令卻又指到 Kafka broker 上，這點一直在邏輯上困擾很久，直到看到官方的拔除計畫 (但又不快) 才理解為什麼這麼不一致...

給需要的人參考，當初在架設 Kafka cluster 時寫下來的筆記：「Confluent」。

AWS 也把 Kafka 包出來當服務了...

AWS 發表把 Kafka 包起來當服務賣的 Amazon MSK：「Introducing Amazon Managed Streaming for Kafka (Amazon MSK) in Public Preview」。

另外 Kafka 所需的 ZooKeeper 部份已經被包進去了，不需要另外付費：

You do not pay for Apache Zookeeper nodes that Amazon MSK provisions for you, or data transfer that occurs between brokers and nodes within clusters.

目前看起來只提供 us-east-1 區域使用。

zetcd：用 etcd 跑 ZooKeeper 架構

在「zetcd: running ZooKeeper apps without ZooKeeper」這邊介紹了用 etcd 當作 ZooKeeper 伺服器。程式碼在「Serve the Apache Zookeeper API but back it with an etcd cluster」這邊可以看到。

不過可以看到有不少 overhead：

但 etcd 用 Go 寫 (省下 JVM tuning？)，可能是個不錯的誘因...

Netflix 開發的 Delayed Queue

原來這個叫做 Delayed Queue，難怪之前用其他關鍵字都找不到什麼資料... (就不講其他關鍵字了 XD)

Netflix 發表了他們自己所開發的 Delayed Queue：「Distributed delay queues based on Dynomite」。

本來的架構是用 Cassandra + Zookeeper 來做：

Traditionally, we have been using a Cassandra based queue recipe along with Zookeeper for distributed locks, since Cassandra is the de facto storage engine at Netflix.

但可以馬上想到不少問題，就如同 Netflix 提到的：

Using Cassandra for queue like data structure is a known anti-pattern, also using a global lock on queue while polling, limits the amount of concurrency on the consumer side as the lock ensures only one consumer can poll from the queue at a time.

所以就改放到 Netflix 另外開發的 Dynamite 上：

Dynomite, inspired by Dynamo whitepaper, is a thin, distributed dynamo layer for different storage engines and protocols. Currently these include Redis and Memcached. Dynomite supports multi-datacenter replication and is designed for high availability.

後端是 Redis 與 Memcached 的系統，可以對抗整個機房從 internet 上消失的狀態。

在設計上則是「保證會跑一次」，也就是有可能會有多次的情況，用 Dyno Queues 系統的人必需要考慮進去：

4. At-least-once delivery semantics

雖然整篇講的頗輕鬆，但實際看起來還是很厚重... 暫時還是不會用吧 :o

用 Docker 測試 Mesos

照著「Deploy a Mesos Cluster with 7 Commands Using Docker」上面的方法做，遇到一些小狀況，解決後總算是搞定了。

文章作者的目的是利用 Docker 在不弄髒環境下讓人很容易上手測試，不需要處理一堆 Java 以及設定檔的問題。讓沒有用過的人可以感受一下 Mesos 與 Marathon 的界面與操作。

總共會跑起四個 docker instance，分別是 ZooKeeper、Mesos Master、Marathon、Mesos Slave Container。

我遇到的問題是我在 Ubuntu 上面的 UFW 設為 default deny，造成這四隻程式之間溝通不良，最後是針對 docker0 這個 interface 放行：

# ufw allow in on docker0

有些感覺之後就可以看官網看更進階的功能操作。

Pinterest 對 ZooKeeper 的用法

在「ZooKeeper Resilience at Pinterest」這篇文章裡面，Pinterest 的人說明內部是怎麼使用 ZooKeeper，其中對我來說最重要的是這張圖：

程式不直接接觸 ZooKeeper 取得資料，而是透過 daemon 寫到 local disk 的資料取得。這樣當 ZooKeeper 失敗時仍然可以保持一定的服務 (因為 local disk cache)，而避免服務中斷。

當然，這跟資料的性質有關，不是所有的資料型態都可以接受 cache。這種解法常常是在穩定性不是可以自己控制 (這個例子裡是 ZooKeeper)，而且遇到問題時不希望整個服務就爆炸...

但這個思路每次看過每次都會忘記，寫下來不知道會不會比較容易想起來 :o