lz4

每个Kudu 表必须设置Pimary Key(unique), 另外Kudu表不能设置secondary index, 经过实际性能测试, 本文给出了选择Kudu主键的几个策略, 测试结果纠正了我之前的习惯认知. 简单介绍测试场景: 表中有一个unqiue字段Id, 另外还有一个日期维度字段histdate, 有三种设置kudu PK的方法, 分别是: 表设计方案1 (histdate, id)作为联合主键, 日期字段放在前. 表设计方案2 (id,histdate)作为联合主键, 日期字段放在后. 表设计方案3 (id)作为单字段主键. 先给出测试数据: 结论: 1. 选择性强的字段(比如 id 字段) 应该放在PK清单最前面, 这个规则对查询性能影响最大. 2. PK清单中只加必要的字段, 越少越好. 3. 如果查询针对PK中所有字段都加了条件, 其性能是最优的. 但只要有一个PK字段未加上条件, 就完全用不上PK索引,性能就很差. 4. where条件中各个字段条件的先后顺序并不关键. 5. Kudu表使用Java API Insert的速度还是很好的, 单线程达到了1万笔/秒多. Kudu Update 效率也很高, 实测对一个窄表做全字段update, 其速度达到了Insert速度的88%, 而vertica的update效率比insert差很多. 在测试之前的误区:

Unity 3-7 AssetBundle从入门到掌握 任务1&2&3：课程介绍 AssetBundle -- 用于资源的更新 为了之后的xLua (Lua热更新的框架)打下基础 任务4&5：AssetBundle的定义和作用 AssetBundle的学习 -- 一手学习资源：UnityManual -> AssetBundles -> 教程式的文档 AssetBundle是一个压缩包(也可以认为是一个文件夹) 　　包含模型Model、贴图Texture、预制体Prefab、声音AudioClip、甚至整个场景 　　在游戏运行的时候可以被加载 这个压缩包被打包出来存在硬盘中，里面包含的文件可以分为两类：serialized file和resource files 　　serialized file：资源，如模型、预制体，被打碎放在一个对象中，最后统一被写进 一个单独的文件 　　resource file：某些二进制资源，如图片、声音，被单独保存，方便快速加载 　　　　-- 一个单独的图片或声音就会被打包成一个.resource文件 压缩包可以使用LZMA和LZ4压缩算法，便于更快的进行网络传输 -- 区别见任务13 为什么会用到网络传输呢？ 　　1. 把一些可以下载的资源放在AssetBundle中，而不放在app中，而在需要的时候从网上直接加载资源 　　　　-- 减少安装包的大小

上一篇 说了一个案例是为了说明如何去考量一个Kafka集群的部署，算是一个参考吧，毕竟大家在不同的公司工作肯定也会有自己的一套实施方案。 这次我们再回到原理性的问题，这次会延续 第一篇 的风格，带领大家把图一步一步画出来。 Kafka的Producer原理 首先我们得先有个集群吧，然后集群中有若干台服务器，每个服务器我们管它叫Broker，其实就是一个个Kafka进程。 如果大家还记得 第一篇 的内容，就不难猜出来，接下来肯定会有一个controller和多个follower，还有个ZooKeeper集群，一开始我们的Broker都会注册到我们的ZooKeeper集群上面。 然后controller也会监听ZooKeeper集群的变化，在集群产生变化时更改自己的元数据信息。并且follower也会去它们的老大controller那里去同步元数据信息，所以一个Kafka集群中所有服务器上的元数据信息都是一致的。 上述准备完成后，我们正式开始我们生产者的内容。 名词1——ProducerRecord 生产者需要往集群发送消息前，要先把每一条消息封装成ProducerRecord对象，这是生产者内部完成的。之后会经历一个序列化的过程。之前好几篇专栏也是有提到过了，需要经过网络传输的数据都是二进制的一些字节数据，需要进行序列化才能传输。 此时就会有一个问题

项目名称： JuiceFS 项目作者： Juicedata 开源许可协议： AGPL-3.0 项目地址： https://gitee.com/juicedata/JuiceFS 项目简介 JuiceFS 是一个建立在 Redis 和 S3 等对象存储之上的开源 POSIX 文件系统。它是为云原生环境设计，通过把元数据和数据分别持久化到 Redis 和对象存储中，它相当于一个无状态的中间件，帮助各种应用通过标准的文件系统接口来共享数据。 项目特性 完整 POSIX 兼容：已有应用可以无缝对接； 极致的性能：毫秒级的延迟，近乎无限的吞吐量（取决于对象存储规模）； 云原生：完全弹性，很容易实现存储和计算分离架构； 共享：可以被多个客户端同时读写； 文件锁：支持 BSD 锁（flock）及 POSIX 锁（fcntl）； 数据压缩：默认使用 LZ4 压缩数据，节省存储空间。 项目架构 JuiceFS 使用 Redis 来存储文件系统的元数据。Redis 是一个开源的内存数据库，可以保障元数据的高性能访问。所有文件的数据会通过客户端存储到对象存储中，以下是它的架构图： JuiceFS 中的文件格式，如下图所示。一个文件首先被拆分成固定大小的 "Chunk"，默认 64 MiB。每个 Chunk 可以由一个或者多个 "Slice" 组成，它们是变长的。对于每一个 Slice

FreeBSD ZFS https://www.cnblogs.com/hadex/p/6068476.html 参考資料 http://docs.oracle.com/cd/E37934_01/html/E36658/toc.html https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/zfs.html 内核支持 方式一：ZFS 静态編译进内核 # 确保内核启用如下三项支持 options ZFS #/usr/src/sys/amd64/conf/MyKernel options NFSD #krpc options UFS_ACL #acl 方式二：ZFS 做为模块开机加载 # 确保如下两个文件同时存在 # /boot/kernel/zfs.ko # /boot/kernel/opensolaris.ko # 必須的两个模块与内核同步編译 MODULES_OVERRIDE= zfs opensolaris krpc acl_posix1e #/etc/make.conf # 设置开机启动 zfs_enable="YES" #/etc/rc.conf.local # 确保 zfs 模块开机加载 zfs_load="YES" #/boot/loader.conf 特性 ZFS 不通过常规的操作系统工具进行管理，如

​导读 本文介绍eBay广告数据平台的基本情况，并对比分析了ClickHouse与Druid的使用特点。基于ClickHouse表现出的良好性能和扩展能力，本文介绍了如何将eBay广告系统从Druid迁移至ClickHouse，希望能为同业人员带来一定的启发。 背景 eBay广告数据平台为eBay第一方广告主（使用Promoted Listing服务的卖家）提供了广告流量、用户行为和效果数据分析功能。广告卖家通过卖家中心（Seller Hub）的营销标签页、效果标签页和公开API，有效掌控和对比店铺的营销活动和推广商品的流量、销量的实时和历史数据，并通过网页或者API 下载数据分析报告。 这一系统上线之初使用了自研的分布式SQL引擎，构建在对象存储系统之上。3年前随着广告流量增加，我们把数据引擎切换到Druid上。 这一平台的主要挑战如下： 数据量大 ： 每日的插入数据记录有数百亿条，每秒的插入峰值接近一百万条； 离线数据摄入 ：在不影响实时数据摄入的情况下，每天需要对前1-2天的数据进行在线替换。根据上游数据团队发布清洗过的每日数据，广告数据平台需要在不影响查询的情况下每日替换实时数据，数据切换要求实现跨节点的全局原子操作； 完整性和一致性 ：面向卖家的财务数据，离线更新后的数据要求不能有遗漏和重复；实时数据要求端对端的延迟在十秒内。 Druid VS. ClickHouse

背景 通常而言，服务发布平台的构建部署的流程（镜像部署除外）会经过 构建 （同步代码 -> 编译 -> 打包 -> 上传）、 部署 （下载包 -> 解压到目标机器 -> 重启服务）等步骤。以美团内部的发布平台 Plus 为例，最近我们发现一些发布项在构建产物打包压缩的过程中耗时比较久。如下图所示的 pack 步骤，一共消耗了1分23秒。 而在平常为用户解答运维问题的时候我们也发现，很多用户会习惯将一些较大的机器学习或者 NLP 相关的数据放入到仓库中，这部分数据往往占据几百兆，甚至占据几个GB的磁盘空间，十分影响打包的速度。 Java 项目也是如此，由于 Java 服务框架繁多，依赖也多，通常这些服务打包后也要占据百兆级别的空间，耗时也会达到十多秒。下图是我们的 pack 步骤的中位数，基本上大部分的 Java 服务和 Node.js 服务都至少要消耗 13s 左右的时间来做压缩打包 。 pack 作为几乎所有需要部署的服务必需步骤，它目前的耗时基本上仅低于编译和构建镜像，因此，为了提高整体构建的效率，我们准备对 pack 打包压缩的步骤进行一轮优化工作。 方案对比 准备场景数据 发布项的包大小分析 为了尽可能地模拟构建部署中的应用场景，我们将 2020 年的部分 构建包数据 进行了整理分析，其中压缩后的包大小如下图所示，钟形曲线说明了整体的包体积呈正态分布

1. 概述 DolphinDB Database 是一款高性能混合列式数据库和数据分析系统，尤其擅长处理时间序列数据。Aliyun HybridDB for PostgreSQL（以下简称HybridDB）是由阿里巴巴提供的基于开源Greenplum定制的MPP架构企业级通用数据仓库产品。 2. 测试环境 DolphinDB部署在5个ecs.r5.large节点上，每个节点基本配置如下： 操作系统：Ubuntu 16.04 处理器：Intel Xeon Platinum 8163 (2 Cores) 内存：16 GB 硬盘：150 GB SSD HybridDB采用2C SSD配置，拥有4个计算节点，每个节点基本配置如下： 处理器：2 Cores 内存：16 GB 硬盘：160 GB SSD DolphinDB采用1个主节点，4个计算节点，配置8个worker和2个local executor，每个计算节点限制使用12 GB内存。 HybridDB直接使用，不做任何进一步的配置，每个计算节点2个段数据库。经过测试开启Pivotal Query Optimizer时HybridDB表现更差，因此本报告中所有测试都默认只使用Legacy Query Optimizer。 压缩为gzip的CSV数据存放在阿里云OSS服务器上。DolphinDB通过内网获得OSS上的数据后解压并加载