Apache HBase

在 Spark AI Summit 的第一天会议中，数砖重磅发布了 Delta Engine。这个引擎 100% 兼容 Apache Spark 的向量化查询引擎，并且利用了现代化的 CPU 架构，优化了 Spark 3.0 的查询优化器和缓存功能。这些特性显著提高了 Delta Lake 的查询性能。当然，这个引擎目前只能在 Databricks Runtime 7.0 中使用。 文章目录 1 数砖研发 Delta Engine 的目的 2 Delta Engine：高性能的查询引擎 3 Photon：原生向量化执行引擎 3.1 String 优化 数砖研发 Delta Engine 的目的 过去十年，存储的速度从 50MB/s（HDD）提升到 16GB/s（NvMe）；网络的速度从 1Gbps 提升到 100Gbps；但是 CPU 的主频从 2010 年的 3GHz 到现在基本不变。 如果想及时了解Spark、Hadoop或者HBase相关的文章，欢迎关注微信公众号： iteblog_hadoop NVM Express（NVMe），或称非易失性内存主机控制器接口规范（英语：Non-Volatile Memory Host Controller Interface Specification，缩写：NVMHCIS），是一个逻辑设备接口规范。它是与 AHCI 类似的

背景 之前做过一个项目，数据库存储采用的是mysql。当时面临着业务指数级的增长，存储容量不足。当时采用的措施是 1>短期解决容量的问题 mysql从5.6升级5.7，因为数据核心且重要，数据库主从同步采用的是全同步， 利用5.7并行复制新特性，减少了主从同步的延迟，提高了吞吐量。 当时业务量高峰是2000TPS，5.6时可承受的最大TPS是3000，升级到5.7压测可承受的最大TPD是5000. 2>流量拆分，从根本上解决容量问题 首先进行容量评估，通过对于业务开展规划、活动预估，年底的容量会翻5倍。由于目前指数级增长的特性，数据库要预留至少4倍的冗余。 要对数据库进行扩容，因为我们已经使用的是最顶配的SSD物理机了，就算可以在linux内核层面对numa进行绑核和非绑核等测试调参优化性能，提升容量也很有限。注意：一般的业务系统numa绑核会提高性能，但是mysql等数据库系统是相反的。 所以垂直扩容不成功，就看看是否可以拆分流量。mysql流量拆分方式有x轴拆分(水平拆分)、y轴拆分(垂直拆分)、z轴拆分。 其中y轴拆分(垂直拆分)就是目前都在说做垂直领域，就是在一个细分领域里做深入的意思。由此可以很容易的记住垂直拆分的意思就是按照业务领域进行拆分，专库专用。实际上能按领域拆分是最理想的，因为这种拆分业务清晰；拆分规则明确；系统之间整合或扩展容易。但是因为当时的业务已经很简单

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 既然 HTAP 有了分析的能力，它是不是将取代大数据系统呢？大数据的下一站是什么？ 因为侧重点的不同，传统的数据库可以分为交易型的 OLTP 系统和分析型的 OLAP 系统。随着互联网的发展，数据量出现了指数型的增长，单机的数据库已经不能满足业务的需求。特别是在分析领域，一个查询就可能需要处理很大一部分甚至全量数据，海量数据带来的压力变得尤为迫切。这促成了过去十多年来以 Hadoop 技术开始的大数据革命，解决了海量数据分析的需求。与此同时，数据库领域也出现了一批分布式数据库产品来应对 OLTP 场景数据量的增长。 为了对 OLTP 系统里的数据进行分析，标准的做法是把里面的数据定期（比如说每天）同步到一个 OLAP 系统中。这种架构通过两套系统保证了分析型查询不会影响线上的交易。但是定期同步导致了分析的结果并不是基于最新数据，这种延迟让我们失去了做出更及时的商业决策的机会。为了解决这个问题，近几年出现了 HTAP 的架构，这种架构允许我们对 OLTP 数据库里的数据直接进行分析，从而保证了分析的时效性。分析不再是传统的 OLAP 系统或者大数据系统特有的能力，一个很自然的问题是：既然 HTAP 有了分析的能力，它是不是将取代大数据系统呢？大数据的下一站是什么？ 背 景

物化视图作为一种预计算的优化方式，广泛应用于传统数据库中，如Oracle，MSSQL Server等。随着大数据技术的普及，各类数仓及查询引擎在业务中扮演着越来越重要的数据分析角色，而物化视图作为数据查询的加速器，将极大增强用户在数据分析工作中的使用体验。本文将基于 Spark SQL（2.4.4） + Hive （2.3.6）， 介绍物化视图在 Spark SQL中的实现及应用。 文章目录 1 什么是物化视图 2 物化视图现状及实践目标 2.1 SparkSQL目前有哪些预计算相关的优化呢？ 3 物化视图设计详解 3.1 SparkSQL + Hive 整合 3.1.1 为什么选择Hive2.3 4 Plan Rewrite 设计 4.1 设计概览 4.2 优化步骤简介 4.3 优化过程中的问题 4.3.1 列相等问题 4.3.2 条件匹配问题 4.3.3 表达式匹配问题 4.3.4 多表查询问题 4.3.5 聚合函数问题 4.3.6 多个物化视图匹配问题 5 物化视图实战 5.1 测试用的查询 5.2 测试用的物化视图 5.3 逻辑计划比较 5.4 Spark UI统计比较 5.5 性能数据比较 6 物化视图 VS Kylin 6.1 Kylin on HBase 6.2 Kylin on Parquet 7 总结 8 参考资料 什么是物化视图

作者介绍：朱志友，中通快递大数据架构师。 中通快递背景介绍 中通快递业务的规模目前是世界第一，是第一个达成年百亿业务量的快递企业，在 2019 年的双十一更是完成了订单量超过 2 亿的佳绩。中通科技是中通快递旗下的互联网物流科技平台，拥有一支千余人规模的研发团队，秉承着“互联网+物流”的理念，与公司的战略、业务紧密的衔接，为中通生态圈的业务打造全场景全链路的数字化平台服务。 上图展示了快递物流的生命周期，简单举个例子，大家如果在某宝上下了一个订单，从付款结束开始，到商家打单，大家的包裹基本上就开启了一个快递的旅程。简单的介绍可以分为五个字，收发到派签，整个物流的全链路中可以拆解成以下的关键节点，客户下单之后快递员的揽收，揽收网点的建包，建包之后会把快递交到中心，至此快递就开启了转运和运输的过程，最终负责派件的末端网点会根据三段码的解析去末端的中心把快递拉到末端的快递网点进行分拣，分拣之后会指派到指定的快递员，进行派件，快递小哥会把快递送到客户的手里，客户完成签收，在我们看来这一票件就完成了快递的全链路的生命周期。在每个环节中会产生大量的数据，对每个环节的每一个数据我们都会进行相关的分析，包括时效的监控。 2017 年的时候，我们就已经开始关注 TiDB ，那时候的关注点主要在解决一些分库分表的问题上，从 2018 年底开始调研测试大数据，我们主要想去解决存储和计算的问题，2019

环境篇：数据同步工具DataX 1 概述 https://github.com/alibaba/DataX DataX是什么？ DataX 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台，实现包括 MySQL、SQL Server、Oracle、PostgreSQL、HDFS、Hive、HBase、OTS、ODPS 等各种异构数据源之间高效的数据同步功能。 设计理念 为了解决异构数据源同步问题，DataX将复杂的网状的同步链路变成了星型数据链路，DataX作为中间传输载体负责连接各种数据源。当需要接入一个新的数据源的时候，只需要将此数据源对接到DataX，便能跟已有的数据源做到无缝数据同步。 当前使用现状 DataX在阿里巴巴集团内被广泛使用，承担了所有大数据的离线同步业务，并已持续稳定运行了6年之久。目前每天完成同步8w多道作业，每日传输数据量超过300TB。 2 支持数据 类型 数据源 Reader(读) Writer(写) 文档 RDBMS 关系型数据库 MySQL √ √ 读 、 写 Oracle √ √ 读 、 写 SQLServer √ √ 读 、 写 PostgreSQL √ √ 读 、 写 DRDS √ √ 读 、 写 达梦 √ √ 读 、 写 通用RDBMS(支持所有关系型数据库) √ √ 读 、 写 阿里云数仓数据存储 ODPS √ √ 读 、 写 ADS

一、需求说明 将源表（T_USER）中的用户信息同步到Hadoop中，然后再抽取Hadoop文件中数据到文本文件中。 二、启动kettle 双击 Spoon.bat 就能启动 kettle 。 三、创建转换 1.Hadoop集群配置说明 首先需要从hadoop集群中（/../hadoop-3.1.2/etc/hadoop）复制core-site.xml，hdfs-site.xml，yarn-site.xml，mapred-site.xml文件到shim文件夹中(..\data-integration\plugins\pentaho-big-data-plugin\hadoop-configurations\cdh514)，替换已有的文件。 注意要修改这些配置文件。比如hadoop节点的地址是不是正确等。由于core-site. xml 里面用的 hostname 连接的，而我们配置的时候用的 ip，所以需要修改core-site.xml为ip,然后重启Spoon。 由于Hadoop权限管理是弱管理，此处用户名和密码可以缺省。不过往Hadoop创建文件需要进行权限鉴证，所以此处修改Hadoop中的core-site.xml文件如下所示，表示不经过任何验证，所有用户拥有全部权限。(修改此配置需要重启hadoop)： <property> <name>hadoop.security

多年以来，社区一直在努力改进 Spark SQL 的查询优化器和规划器，以生成高质量的查询执行计划。最大的改进之一是基于成本的优化（CBO，cost-based optimization）框架，该框架收集并利用各种数据统计信息（如行数，不同值的数量，NULL 值，最大/最小值等）来帮助 Spark 选择更好的计划。这些基于成本的优化技术很好的例子就是选择正确的 Join 类型（broadcast hash join vs. sort merge join），在 hash join 的时候选择正确的连接顺序，或在多个 join 中调整 join 顺序。然而，过时的统计信息和不完善的基数估计可能导致次优查询计划。即将发布的 Apache Spark TM 3.0 版本中新增了自适应查询执行（Adaptive Query Execution）是的新功能，并且已在 Databricks Runtime 7.0 beta 中提供。它希望根据查询执行过程中收集的运行时统计信息，通过重新优化和调整查询计划来解决这些问题。 文章目录 1 自适应查询执行框架 2 动态合并 shuffle 的分区 3 动态调整 Join 策略 4 动态优化数据倾斜的 Join 5 AQE 的 TPC-DS 表现 6 启用 AQE 自适应查询执行框架 自适应查询执行最重要的问题之一是何时进行重新优化。Spark

前言： 本文详细介绍了 HBase FamilyFilter 过滤器 Java&Shell API 的使用，并贴出了相关示例代码以供参考。FamilyFilter 基于列族进行过滤，在工作中涉及到需要通过HBase 列族进行数据过滤时可以考虑使用它。比较器细节及原理请参照之前的更文： HBase Filter 过滤器之比较器 Comparator 原理及源码学习 一。Java Api 头部代码 public class FamilyFilterDemo { private static boolean isok = false; private static String tableName = "test"; private static String[] cfs = new String[]{"f1","f2"}; private static String[] data = new String[]{"row-1:f1:c1:v1", "row-2:f1:c2:v2", "row-3:f2:c3:v3", "row-4:f2:c4:v4"}; public static void main(String[] args) throws IOException { MyBase myBase = new MyBase(); Connection connection =

一、Kettle的集群原理 完全分布式即是在该集群环境中所有的kettle服务都是部署在不同的机器上，互相之间没有影响。此处以一个真实环境为例，来介绍kettle完全分布式环境的开发使用。生产环境中kettle服务器都是部署在linux服务器上，在windows本地开发好kettle任务，然后在linux集群环境上运行。 二、完全分布式集群搭建 1.环境规划 该环境模拟一台主服务器，两台从服务器的方式。 2.环境准备 首先需要先准备三台linux服务器，并且分别在三台机器上安装好jdk和kettle。 (1)JDK安装 此处不做详细介绍，可参考网上安装文档。 (2)Kettle安装 创建一个目，将下载好的kettle解压后放在该文件夹下。 测试安装是否成功 在kettle的data-integration目录中执行kitchen.sh文件，若出现帮助信息，证明安装成功 3.环境配置 和windows环境一样修改kettle配置文件，打开kettle的安装目录，进入到data-integration->pwd目录，找到carte-config-master-8080.xml文件。该文件主要是进行master主机配置，name、hostname、port依次配置名称、主机IP和端口号（如果已经使用可以修改）。 注意：username和password并不是指主机的登陆账号和密码