Apache HBase

HBase一个令人惋惜的地方，就是不支持二级索引。因此，社区有了很多补充方案来填补HBase的二级索引能力的缺陷。 今天，我们就来看看有哪些二级索引方案，通过对比各个方案的优缺点，并结合我们的具体场景做出二级索引方案选型。 1.为什么需要二级索引 HBase系统单纯从解决大数据实时读写问题角度出发，重点关注于分布式存储的扩展性、容错性、读写性能等方面，为此也牺牲了很多传统关系型数据库的功能，比如事务，SQL表达与分析等。 实际上，这是NoSQL最初的含义，以解决大数据的实时存取为首要目标，提供简单的Get，Put，Scan接口，解决用户的大数据量存储的需求。因此，HBase完全是一个非常优秀的大数据实时存取引擎，解决了传统数据库的容量问题。 就目前官方的HBase系统来说，并不支持二级索引，只有rowkey作为一级索引， 如果要对库里的非rowkey字段进行数据检索和查询， 往往要通过MapReduce/Spark等分布式计算框架进行，硬件资源消耗和时间延迟都会比较高。 为了HBase的数据查询更高效、适应更多的场景， 诸如使用非rowkey字段检索也能做到秒级响应，或者支持各个字段进行模糊查询和多字段组合查询等， 因此需要在原生HBase基础上构建二级索引， 以满足现实中更复杂多样的业务需求。一般有以下三类方案： 基于HBase的Coprocessor的方案

本文为阿里巴巴技术专家余根茂在社区发的一篇文章。 Structured Streaming 最初是在 Apache Spark 2.0 中引入的，它已被证明是构建分布式流处理应用程序的最佳平台。SQL/Dataset/DataFrame API 和 Spark 的内置函数的统一使得开发人员可以轻松实现复杂的需求，比如支持流聚合、流-流 Join 和窗口。自从 Structured Streaming 发布以来，社区的开发人员经常要求需要更好的方法来管理他们的流作业，就像我们在 Spark Streaming 中所做的那样。为此，Apache Spark 3.0 为 Structured Streaming 开发了一套全新的 UI。 新的 Structured Streaming UI 通过有用的信息和统计信息提供了一种简单的方法来监控所有流作业，从而使开发调试期间的故障排除变得更容易，在生产环境下通过实时度量更好的理解我们的作业瓶颈。新的 UI 提供了两组统计信息： 流查询作业的聚合信息； 流查询的详细统计信息，包括输入速率（Input Rate）、处理速率（Process Rate）、输入行数（Input Rows）、批处理持续时间（Batch Duration,）、操作持续时间等（Operation Duration）。 文章目录 1 流查询作业的聚合信息 2 详细统计信息 3

Kafka Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。 1.介绍 消息队列的性能好坏，其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。下面将从Kafka文件存储机制和物理结构角度，分析Kafka是如何实现高效文件存储，及实际应用效果。 1.1 Kafka的特性: 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。 可扩展性：kafka集群支持热扩展 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败） 高并发：支持数千个客户端同时读写 1.2 Kafka的使用场景： 日志收集：一个公司可以用Kafka可以收集各种服务的log

在开发好用户标签以后，如何将标签应用到实际其实是一个很重要的问题。只有做好产品的设计才能让标签发挥真正的价值，本文将介绍用户画像的产品化过程。 一、标签展示 首先是标签展示功能，这个主要供业务人员和研发人员使用，是为了更直观的看见整个的用户标签体系。 不同的标签体系会有不同的层级，那么这个页面的设计就需要我们展示成树状的结构，方便以后的扩展。 在最后一个层级，比如自然性别，可以设计一个统计页面，在进入页面后，可以展示相应的数据统计情况， 可以更直观看见标签中值得比例，也可以为业务提供好的建议，另外可以对标签的具体描述进行展示，起到一个说明的作用，还可以展示标签按天的波动情况，观察标签的变化情况。 这一部分的数据来源呢？之前也提到过，这些标签的元数据信息都存在mysql中，方便我们查询。 所以树状图和标签描述信息需要去mysql中获取，而比例等图表数据则是从Hbase，Hive中查询获取的，当然也有直接通过ES获取的。但是每天的标签历史波动情况，还是要通过每天跑完标签后存在mysql中作为历史记录进行展示。 二 、标签查询 这一功能可以提供给研发人员和业务人员使用。 标签查询功能其实就是对用户进行全局画像的过程，对于一个用户的全量标签信息，我们是需要对其进行展示的。 输入用户id后，可以查看该用户的属性信息、行为信息、风控属性等信息。从多方位了解一个具体的用户特征。

1、读取Mysql数据 object JdbcRddDemo { def getConn() = { Class.forName( "com.mysql.jdbc.Driver" ).newInstance() DriverManager.getConnection( "jdbc:mysql://hadoop000:3306/hive", "root", "root" ) } def main(args: Array[String]): Unit = { val sparkConf = new SparkConf().setAppName("jdbcRdd").setMaster("local[*]" ) val sc = new SparkContext(sparkConf) val jdbcRDD = new JdbcRDD( sc, getConn, "select * from TBLS where TBL_ID >= ? and TBL_ID <= ?" , 1 , 10 , 2 , rs => { val id = rs.getInt(1 ) val name = rs.getString(2 ) val age = rs.getInt(3 ) (id,name,age) } ) jdbcRDD.collect().toBuffer } } 来源： oschina 链接

作者 | Hongqi 阿里云高级技术专家 本文整理自《Serverless 技术公开课》，关注“ Serverless ”公众号，回复 入门 ，即可获取 Serverless 系列文章 PPT。 什么是 Serverless 架构？按照 CNCF 对 Serverless 计算的定义，Serverless 架构应该是采用 FaaS（函数即服务）和 BaaS（后端服务）服务来解决问题的一种设计。这个定义让我们对 Serverless 的理解稍显清晰，同时可能也造成了一些困扰和争论。 随着需求和技术的发展，业界出现了一些 FaaS 以外的其它形态的 Serverless 计算服务，比如 Google Cloud Run，阿里云推出的面向应用的 Serverless 应用引擎服务以及 Serverless K8s，这些服务也提供了弹性伸缩能力和按使用计费的收费模式，具备 Serverless 服务的形态，可以说进一步扩大了 Serverless 计算的阵营； 为了消除冷启动影响，FaaS 类服务如阿里云的函数计算和 AWS 的 Lambda 相继推出了预留功能，变得不那么“按使用付费”了； 一些基于服务器（Serverful）的后端服务也推出了 Serverless 形态产品，比如 AWS Serverless Aurora，阿里云 Serverless HBase 服务。 这样看来

近年来，随着IT技术与大数据、机器学习、算法方向的不断发展，越来越多的企业都意识到了数据存在的价值，将数据作为自身宝贵的资产进行管理，利用大数据和机器学习能力去挖掘、识别、利用数据资产。 如果缺乏有效的数据整体架构设计或者部分能力缺失，会导致业务层难以直接利用大数据大数据，大数据和业务产生了巨大的鸿沟，这道鸿沟的出现导致企业在使用大数据的过程中出现数据不可知、需求难实现、数据难共享等一系列问题，本文介绍了一些数据平台设计思路来帮助业务减少数据开发中的痛点和难点 一大数据技术栈 大数据整体流程涉及很多模块，每一个模块都比较复杂，下图列出这些模块和组件以及他们的功能特性，后续会有专题去详细介绍相关模块领域知识，例如数据采集、数据传输、实时计算、离线计算、大数据储存等相关模块。 二、lambda架构和kappa架构 目前基本上所有的大数据架构都是基于lambda和kappa架构，不同公司在这两个架构模式上设计出符合该公司的数据体系架构。lambda 架构使开发人员能够构建大规模分布式数据处理系统。 它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性，关于lambda架构可以在网上搜到很多相关文章。而kappa架构解决了lambda架构存在的两套数据加工体系，从而带来的各种成本问题，这也是目前流批一体化研究方向，很多企业已经开始使用这种更为先进的架构。 Lambda架构

本文来源于公众号【胖滚猪学编程】，转载请注明出处！ 关于数据中台的概念和架构，我们在 大白话 六问数据中台 和 数据中台全景架构及模块解析！一文入门中台架构师！ 两篇文章中都说明白了。从这一篇文章开始分享中台落地实战。 其实无论是数据中台还是数据平台，数据无疑都是核心中的核心，所以闭着眼睛想都知道数据汇聚是数据中台/平台的入口。纵观众多中台架构图，数据采集与汇聚都是打头阵的： 本文将从以下几个方面分享数据采集的方方面面： 一、企业数据来源 二、数据采集概念和价值 三、数据采集常用工具 四、数据采集系统设计原则 五、数据采集模块生产落地分享 有来源才能谈采集，因此我们先来归纳下企业中数据来源。 数据来源 企业中的数据来源极其多，但大都都离不开这几个方面： 数据库，日志，前端埋点，爬虫系统等。 数据库我们不用多说，例如通常用mysql作为业务库，存储业务一些关键指标，比如用户信息、订单信息。也会用到一些Nosql数据库，一般用于存储一些不那么重要的数据。 日志也是重要数据来源，因为日志记录了程序各种执行情况，其中也包括用户的业务处理轨迹，根据日志我们可以分析出程序的异常情况，也可以统计关键业务指标比如PV,UV。 前端埋点同样是非常重要的来源，用户很多前端请求并不会产生后端请求，比如点击，但这些对分析用户行为具有重要的价值，例如分析用户流失率，是在哪个界面，哪个环节用户流失了

在前面两篇中，我们从基本概念理解了canal是一个什么项目，能应用于什么场景，然后通过一个demo体验，有了基本的体感和认识。 从这一篇开始，我们将从源码入手，深入学习canal的实现方式。了解canal相关功能的实现方式，其中有很多机制是非常值得深入了解的，从代码角度实现角度去学习实时数据订阅与同步的实现与核心技术点。当然，如果要在生产中使用这个开源项目，了解源码更是必不可少，是解决问题和新特性定制的前提条件。 本文使用的版本是1.1.4，这也是笔者写这篇博客时的最新稳定版。 1.准备工作 下载源码 git clone https: //github.com/alibaba/canal.git 切换到1.1.4这个tag git checkout canal-1 .1 .4 或者可以关注我的源码注释版本(正在不断更新中) https: / /github.com/saigu /JavaKnowledgeGraph/tree /master/code _reading/canal 2.canal项目模块介绍 canal项目是基于maven构建的，将不同的功能模块划分了不同的子模块。 我们可以简单执行可执行模块deployer，也可以将模块通过maven依赖的方式，将你需要的子模块引入到你自己的项目中进行使用开发。 简单介绍下核心模块的功能： deployer模块：独立部署模块

前面，我们已经打下了很多关于HBase的理论基础，今天，我们主要聊聊在实际开发使用HBase中，需要关注的一些最佳实践经验。 1.Schema设计七大原则 1）每个region的大小应该控制在10G到50G之间； 2）一个表最好保持在 50到100个 region的规模； 3）每个cell最大不应该超过10MB，如果超过，应该有些考虑业务拆分，如果实在无法拆分，那就只能使用mob； 4）跟传统的关系型数据库不同，一个HBase的表中列族最多不超过3个，列族中的列可以动态添加的，不要设计过多列族； 5）列族名必须尽量短，因为我们知道在存储的时候，每个keyvalue都会包含列族名； 6）如果一个表存在一个以上的列族，那么必须要注意，不同列族之间行数相差不要太大。例如列族A有10万行，而列族B有1亿行，那么rowkey就有1亿行，而region是按照行键进行切分的，因此列族A可能会被打散为很多很多小region，这会导致在扫描列族A时会引发较多IO，效率低下。 7）列族可以设置TTL时间，HBase在超过设定时间后，会自动删除数据。 设置方法有两种： 建表时设置,TTL单位为秒，此例中列簇'f1'的数据保留1天（86400秒） hbase(main):002:0>create 'table', {NAME => 'f1', TTL => 86400} 通过修改表设置 hbase