本文翻译自Azure architecture-center的data-partitioning,部分有删改
Kafka producer工作机制及性能监控
最近在做Kafka 1.0.0版本压测的时候,遇到了producer生产效率不稳定的情况。具体表现为当对6个以上有3个同步副本的TopicPartition进行生产时,producer每隔不定时长生产会被阻塞一段时间,控制台报出大量的batch expiring错误,整体吞吐量因此大打折扣。
虽然0.11.x版本之后的client性能测试脚本新增了许多metrics输出,以帮助用户监控和troubleshooting,然而在不了解producer背后运作机制的情况下,仅凭metrics字面意义是难以利用好这些数据的。因此,我决定花一个周末的时间来梳理一下Kafka producer端的架构及工作原理,特别是其中的延迟保证机制,另外整理下producer各项metrics背后的含义。
流式计算的windowing
作为对流式数据流进行stateful统计的基础,window函数是各流式计算框架必不可少的特性。然而目前业界并没有对windowing作出标准的定义和分类,不同计算框架提供的windowing方法各有不同,同一术语在不同框架的含义也不一致,这给流式计算造成了不必要的学习成本。因此本文试图从工作积累出发并结合个人理解,总结出较为全面的windowing概念以及常见策略。
Kylin实战(八):查询优化技术
Kylin的查询实现分为查询引擎和存储引擎两大模块。查询引擎负责逻辑层服务,提供SQL解析和路由功能,实现上依赖于Apache Calcite;存储引擎负责物理层服务,提供服务原语的底层实现,存储引擎的实现默认为HBase,可以通过实现IStorage
接口拓展为其他数据库。
由于查询效率是数据库最为关键的性能指标,Kylin开发团队在查询优化上做了大量工作,其中最重要一点就是将OLAP查询模式结合Kylin Cube的存储模型,细分需求并抽象出通用的查询优化技术。
浅析区块链
随着比特币过去一年的暴涨,区块链这项沉寂了数年的技术重新回到公众视野,代替AI成为了当下投资人最喜爱的概念。先不谈市场上各种靠谱或离谱的蹭热度行为,区块链技术作为一个P2P的分布式数据库无疑是一项革命性的发明。
关于Learned Indexes的思考
Learned Indexes 论文前两周被发表在arXiv上,引起了业界的广泛关注。作为一种全新的索引模型,Learned Indexes 或将有希望取代目前DBMS的传统索引。其核心思想是将数据查找视为以key为输入的数据地址预测问题,从而可以利用机器学习在预测问题上的研究沉淀来优化数据查找。简单来说,Learned Indexes 是一种结合机器学习的索引模型,能根据数据分布来优化索引结构和查找效率。
Spark源码学习笔记(三):Spark-on-YARN调度器初始化
作为提交Spark应用的高级接口,SparkContext封装了分布式计算的绝大部分底层逻辑,API简单易用对用户十分友好。然而在简单的一行new SparkContext()
命令背后,Spark为执行用户代码做了大量的准备,包括启动BlockManager、HeartbeatReceiver、MetricsSystem等等。不过最为关键的一点还是启动Spark调度器,这点从Spark应用的applicationId取自TaskScheduler的applicationId便可看出。
Kylin实战(七):实现维度分桶
数据分析实战中经常有对数值类型的维度进行分桶统计的需求,比如将游戏玩家角色等级按照10级一个区间分桶并计算充值金额。对于这种涉及衍生维度的查询需求,Kylin官方给出的解决方案是在ETL阶段生成这个维度。比如加一个名为”等级区间”的维度,在ETL时计算出该记录对应的值(像”0-10”、”10-20),然后在Kylin建模时就可以使用这个列。
这个方案的问题在于太过死板,如果用户突然又想以20为区间分桶,修改成本就很高。所以我研究了两种out of the box的解决方案,可以在查询的级别上实现分桶,不需要修改Kylin模型。
再见,老白
补完《绝命毒师》第五季,结局在意料之中却依然给观众留下很大的震撼和反思。警笛声渐近,众叛亲离的老白终于在被捕前死在了制毒实验室。没有大桶的美金,没有愿意和他讲话的亲人,甚至连出生入死的同伙小粉都背弃他。但比起成为一个“为什么好人却得了癌症”的虚弱得只能躺在病床吸光家庭经济和等待学校社区救济的高中化学教师,这样的结果没有令老白后悔,因为他至少真正地lived once。
Kylin实战(六):上传Kylin MR依赖
Kylin构建cube的MR任务建立在同一个Hadoop集群的所有节点一致的前提下,通常来说这也是分布式系统的一个良好规范,确保了服务不会和物理机器耦合。 然而很多情况下现实并没有那么美好, 集群节点常常存在异构问题,比如有些节点有安装HBase/Hive,有些则没有。如果在这样的集群上构建cube,很可能会因为ClassNotFoundException而失败。更加令人头疼的是企业中可能只有Hadoop管理员有权登陆机器,作为普通用户是没有办法为剩下的节点安装依赖的。