Carlmartin' Blog

In me the tiger sniffs the rose.

发表于 更新于 分类于 本文字数： 3.5k 阅读时长 ≈ 3 分钟

本文代码截图, 基于2021-07-19的master版本

DataPart存储

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
CREATE TABLE default.lineorder_local
(
    `LO_ORDERKEY` UInt32,
    `LO_LINENUMBER` UInt8,
    `LO_CUSTKEY` UInt32,
    `LO_PARTKEY` UInt32,
    `LO_SUPPKEY` UInt32,
    `LO_ORDERDATE` Date,
    `LO_ORDERPRIORITY` LowCardinality(String),
    `LO_SHIPPRIORITY` UInt8,
    `LO_QUANTITY` UInt8,
    `LO_EXTENDEDPRICE` UInt32,
    `LO_ORDTOTALPRICE` UInt32,
    `LO_DISCOUNT` UInt8,
    `LO_REVENUE` UInt32,
    `LO_SUPPLYCOST` UInt32,
    `LO_TAX` UInt8,
    `LO_COMMITDATE` Date,
    `LO_SHIPMODE` LowCardinality(String)
)
ENGINE = MergeTree
PARTITION BY toYear(LO_ORDERDATE)
ORDER BY (LO_ORDERDATE, LO_ORDERKEY)
SETTINGS index_granularity = 8192;

选了Clickhouse社区官方的SSB测试套的lineorder表为例, 他以toYear(LO_ORDERDATE)为分区键, 此时插入一些数据, 在Clickhouse DataPart级别的目录下, 会出现以下文件

image-20210719104902873

其中跟分区相关的有两个: partition.dat和minmax_LO_ORDERDATE.idx

partition.dat存储的是Partition的具体数值, 对应Clickhouse的源码

1
2
3
4
5
6
7
struct MergeTreePartition
{
    Row value;
  public:
    void load(const MergeTreeData & storage, const DiskPtr & disk, const String & part_path);
    void store(const MergeTreeData & storage, const DiskPtr & disk, const String & part_path, MergeTreeDataPartChecksums & checksums) const;
}

就是我们在system.parts表中看到的partition数值, 其中value的类型是Row, 对应表达式计算后的结果.

阅读全文 »

发表于 更新于 分类于 本文字数： 2.5k 阅读时长 ≈ 2 分钟

什么是存算分离

从字面意思理解就是, 存储计算是解耦的, 当需要增加存储资源的时候, 不需要对应的增加计算部分的资源.

Clickhouse的架构是典型的存储计算在一起的方式, 现在我们公司CK的算力紧缺, 存储却相对较低, 可是要扩容的时候, 存储也对应的增加起来, 形成了一定浪费.

存算分离架构的流行主要得益于云服务的兴起, 按需和弹性的资源推向了企业用户, 目前大多数的云上数据库都开始支持存算分离架构.

传统公司的服务器一般采用预算制, 部门一般能申请就会尽量去申请, 高峰时期能有充足的资源预备是他们首要的目标, 低峰期间的资源浪费是可以忍受的.

云上存算分离架构的设计目标有如下几个:

  1. 数据一般存储在统一的数据服务中, 且数据服务不绑定单个服务; 典型的做法就是放到S3型存储服务离

  2. 计算能够弹性, 扩缩容时间尽量短(某些服务是不支持缩容的);机型大多数要求同构, 少部分支持异构

  3. 网络带宽不是首要考虑的点, 云上内网带宽能够足够的大

  4. 性能衰减不能太严重, 某些场景需要优于单机水平, 方便对外宣传

上面4个设计点, 1和2比较好解决, 例如Spark + HDFS构成的OLAP服务是一个典型的存算分离架构, Spark和HDFS可以分布在不同的集群上, 计算和存储的扩缩容都可以分开处理.

但第3点在传统公司是难以解决的, 因为机房的带宽非常有限, 一旦跨机房, 性能将直线下降. 所以会将这两个服务部署在一起, 导致部署上依然是存算不分离的.

阅读全文 »

发表于 更新于 分类于 本文字数： 1.2k 阅读时长 ≈ 1 分钟

书接上文, 上一篇文章提到reHash方案的缺点在于: 停写和数据拷贝.

那么能不能通过数据迁移而不是数据拷贝的方式来处理reHash呢?

这个时候, 就需要用到一致性Hash算法

jumpConsistentHash算法

jumpConsistentHash是一个一致性hash函数, Clickhouse本身已经实现该算法

假设value的取值范围是[0,1023), 如果shard的个数为3, 那么表达式jumpConsistentHash(value, 3), 能够将1024个字符, 均衡的分配到3个桶内.

而如果此时shard个数升级为4, 我们再次计算表达式jumpConsistentHash(value, 4), 就按照4个节点分区, 而一致性hash算法能够保证, 只会抽取前面3个节点的某些值, 放入第四个节点, 而不是在前3个节点之间, 搞数据交换.

就给我们不停服切换提供了能力.

虚拟节点

阅读全文 »

发表于 更新于 分类于 本文字数： 2.8k 阅读时长 ≈ 3 分钟

前言

转到Clickhouse已经3个月, 在了解CK原理和公司内部使用后发现:

  • 用户在功能端的需求不是很强烈, 除了实时去重和String类型求UV之外, 开源社区的功能基本满足了用户的所有的述求
  • 运维方面问题不断, 除了计算隔离等Server类型常见的运维问题, 还有一些DDL一致性问题都通过治理手段处理了, 但是对于集群扩容目前却没啥特别好的方案

这篇博客将来讨论一下CK扩容的难点以及应对方案, 由于这些方案还没有被组内采纳, 因此可以外网记录一下思考的成果.

扩容问题的讨论, 将分为3篇文章:

  1. 第一篇文章, 将探讨一下reHash问题, 这是扩容最大的难点, 在该文章将提供一个简单的处理方案
  2. 第二篇文章, 将探讨一下虚拟shard的实现, 用以解决第一个方案的缺点
  3. 第三篇文章, 将探讨一下存储计算分离的架构, 实现简便的容错式的扩缩容方案.

数据视图

image-20210712151634570

Clickhouse目前是按照机器节点进行物理隔离的, 一个集群对应一个专属的业务部门, 而非整一个大的集群给所有业务方使用.

阅读全文 »

发表于 更新于 分类于 本文字数： 6.4k 阅读时长 ≈ 6 分钟

部署

系统里面默认是没有安装mpi-operator, 因此需要自行安装.

1
2
3
wget https://github.com/kubeflow/mpi-operator/blob/master/deploy/mpi-operator.yaml
# 修改镜像地址
kubectl create -f mpi-operator.yaml

在国内永远有镜像替换的烦恼, 在mpi-operator之中需要自行替换这两个镜像

1
2
mpioperator/mpi-operator:latest
mpioperator/kubectl-delivery:latest

你可以直接在DockerHub上找到这两个镜像或者自行编译: operator地址 delivery地址

根据以下命令查看是否安装成功(crd已经创建 && pod为running)

1
2
3
4
5
# kubectl get crd|grep mpi
mpijobs.kubeflow.org                   2019-09-18T07:44:48Z

# kubectl get pod -n mpi-operator|grep mpi
mpi-operator-584466c4f6-frw4x          1/1       Running     1          3d
阅读全文 »

发表于 更新于 分类于 本文字数： 2.7k 阅读时长 ≈ 2 分钟

KNative目前的一些介绍文章:

  1. 官网
  2. ServiceMesher介绍
  3. 蚂蚁金服的布道师
  4. 华为云介绍系列

缘起

第一次关注到KNative这个项目是在Info上Kubernetes 上领先的开源 Serverless 解决方案有哪些的文章上, 文章里面对比了常见的Serverless框架, KNative是其中的一个, 又由于这个项目是Google推出的, 因此当时觉得这个项目应该是最有希望的.

参考Service Mesh之争, 2018年年中的时候, 还有一些框架例如Istio和Linkred再竞争, 但是到2019年中基础上Istio已经变成事实标准了. 具体可以看这盘文章

目前KNative已经迭代到0.8版本, 按照google对版本命名的方式, 应该离正式版本近了.

这次随着KFServing依赖KNative组件, 因此安装了一下KNative体验了一下, 就顺便记录一下吧.

KNative介绍

KNative是Google在2018年7月份发布的, 定位为基于 Kubernetes 的 Serverless 解决方案，旨在标准化 Serverless，简化其学习成本.

Serverless 大体上可以分为两种类型：“Backend as a Service” 和 “Functions as a Service”

阅读全文 »

发表于 更新于 分类于 本文字数： 1.9k 阅读时长 ≈ 2 分钟

文章出在此处, 这篇文章就像文章摘要一样, 里面的结论也无法保证正确, 需要等后续实践之中来验证.

今后还会收集其他的一些文章补充这篇文章的内容

最近项目之中, 再选型关系型数据库的类型, 之前团队里一直都是用MySQL + MyBatis的方案, 但是其他项目组选型了PostgreSQL, 现在正在考虑是否要迁移数据库系统.

MySQL的优势项

  1. 流行度高, 因此相应的第三方工具会更加齐全
  2. 回滚更好, PG需要定时触发VACUUM, 否则数据可能膨胀
  3. Windows支持好
  4. 线程模式, 相比PG资源利用率高
  5. 用户权限更加完善, PG只有表级权限, 而MySQL支持列权限
  6. 存储引擎插件化, innodb适合事务处理场景外, myisam适合静态数据的查询场景
  7. 24*7小时运行
  8. 支持堆表和索引表, PG只支持堆表

PostgreSQL的优势项

  1. Json和Array格式支持, MySQL5.7版本之后, 也支持JSon, 但是能力略为落后
  2. GIS支持, 一般都用PG
  3. PostgREST提供API能力
  4. 支持树状结构, 例如R-Tree
  5. SQL编程, 使用各种语言来编程, 对标的是MySQL的存储过程
  6. 支持外部数据源, 这儿估计一堆的限制
  7. Text没有长度限制, MySQL需要区分small text, middle text, large text, 但实际上我觉得程序员定义这个长度是比较好的, 就像int和long类型一个意思
  8. 支持图结构数据存储
  9. 支持窗口函数, OVER语句, 没想到MySQL竟然没有支持这个, SparkSQL都实现了
  10. 更多索引类型,
  11. 集群支持更好, 这个点需要存疑, 因为mysql的分布式中间件那么多, 感觉有点不对
  12. 事务隔离做的更好
  13. 对于字符支持更好一些
  14. 对表连接支持较完整, 真的很难相信MySQL不支持HashJoin和SortMergeJoin, 之前数据库确实用的太简单了
  15. 存储方式支持更大的数据量
  16. 时间精度更高
  17. 优化器的功能较完整
  18. 序列支持更好
  19. 对子查询支持更好
  20. 增加列更加简单

两者选择规则

  1. 如果是非常简单的场景, 直接使用MySQL
  2. 如果涉及到数据完整性和可靠性的时候, 使用PG
  3. 如果是地理数据, 使用PG
  4. 如果有嵌入式SQL场景, 使用PG
  5. 如果你想学习一个经典的关系型数据库, 使用PG吧

MyBatis兼容PG和MySQL

阅读全文 »

发表于 更新于 分类于 本文字数： 2.7k 阅读时长 ≈ 2 分钟

之前调研了TensorFlow Serving的功能, 这周又抽出来一点时间, 调研一下KubeFlow Serving

KFServing的定位

之前在Kubeflow的介绍文章有提过, Kubeflow支持Training和Serving, 但是如果仔细看Serving的官网会发现, 目前这个Serving似乎只是把这种各样的Serving镜像给安装部署起来就好了, 感觉游离在系统之外的.

所以TFServing的目标就是设计一套接口, 将各个Serving模块抽象化, 变成一套系统.

但是, 目前TFServing虽然提交活跃度挺高, 但是还没有挂在官网介绍文章之中, 版本非常新, 目前才v0.2版本, 未来接口可能会有很大变化

KFServing架构

从架构图上可以看出, KFServing在非常高的位置之上, 它底层的服务能力依赖于KNative(主要是KNative的Serving模块), 上层支持的框架有:

  1. TensorFlow: 镜像由于TensorFlow官网提供
  2. PyTorch: 镜像由KFServing制作, 代码逻辑位于此
  3. SKLearn: 同上
  4. XGBoost: 同上
  5. TensorRT: 镜像由NVIDIA提供
阅读全文 »

发表于 更新于 分类于 本文字数： 408 阅读时长 ≈ 1 分钟

开发工具

  1. Visual Code应该是最好用的代码编辑器了
  2. Typora是Markdown编辑器
  3. notepadqqWindows上Notepad++的替代者, 没那么好用
  4. GithubDestop图像化管理GitRepository库
  5. Idea intellij全家桶
  6. snapUbuntu上的homebrew, 不过挺难用的
  7. PostMan 图形化API发送工具
  8. MiniCondaPython的环境管理工具
  9. Zeal查看SDK的工具, MacOS上Dash的替代品

办公工具

  1. WPS: 国产的Office工具
  2. Shadowsocks: 翻墙工具
  3. 坚果云: 个人云盘, 有2G免费空间
  4. Chrome: Google浏览器
  5. 360浏览器: 确实没想到360竟然也有linux浏览器
  6. XMind: 思维导图工具
  7. Shutter截图工具
  8. VisualBox偶尔可以切换一下Windows
  9. TeamViewer可以控制远程的桌面

娱乐工具

  1. 网易云音乐: 官网链接找不到了, 只有其他的安装文档
阅读全文 »
0%