Apache HBase

前言 本来已经实施的OKR计划因为突如其来的疫情打乱了节奏，现在团队已经没人能够记得自己的OKR是什么了。 目前国内疫情早就趋于平稳，是时候找回节奏了。在这里更新团队OKR 强化自组织，持续优化和开放透明的团队文化 第三四季度彻底执行OKR 覆盖全员 月度评审 季度复盘 实现五分钟启动并演示 团队内任意成员在研项目可在5分钟内启动并演示本周期功能 9月前新人进入后10分钟内完成开发环境的生成 扩大服务器集群规模，至少保证12个开发节点的规模 技术进阶集团内第一梯队，公司内领先一代 10月前实现在研项目镜像化比例高于70% UMP除4G平台服务外的全镜像化 ISS全镜像化 实现JGDQ全镜像化 年底前云原生技术实现实用化进阶 自建服务器集群扩大到10台 九月前自建的Paas集群投入项目实际使用 九月前公有云的服务使用 年底前团队中至少2人掌握低代码平台，具备搭建实际软件的能力 低/无代码平台的调研 demo项目的开发和演示 成为ToB领域第一梯队的解决方案团队 年底前具备大数据领域平台开发能力 9月前具备基础的PB级大数据管理平台开发能力,hadoop+hbase 12月前具备大数据处理平台开发能力,MR->Spark->flink 完成团队业绩指标 100%按照预期完成 纯软产值>80万/人 利润>40万/人 具备排除技术型宕机问题或单点故障的能力，具备搭建99.9

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

故障和问题是系统设计与开发的指示灯。 引言 俗话说：好的战士，是从枪林弹雨中打出来的。好的工程师，是从沼泥坑洞中踩出来的。 在平常的开发中，人很难主动去思考深入的东西。故障，层出不穷的问题，是开发人员想要回避的却始终难以回避的事情。从正面的角度来看，错误是人类进步的阶梯。故而，每一个显现的故障和问题，也能引导人更加深入地理解系统的运行，思考一些平时很少思考的东西，是很有益的礼物。在有赞的四年里，我踩过不少坑，总结出来，期望对后来者有所启发。 导图 坑位及启示 踩坑不是目标，从踩过的坑中汲取足够的经验教训才划算。如何分析一个坑位呢 ？首先，应当从逻辑上严密地论证为什么会出现这个问题，其严密性如 1+1=2 一样无疑议；其次，带来的启示和指导是怎样的，如何去防范类似的问题。 名字覆盖出错 或许出于对同行的莫可名状的“不满”情绪，程序猿看到不太顺眼的地方，总有一种想要改掉它的冲动。但人在采取行动之前，又容易缺乏思考。因此，冲动常常招致小小的惩罚。 譬如说，我刚接手订单导出。看到报表文件名是：kdt_8fb888f9c9fad7840190d9d1531dddfc.csv 。 心想，这后面一串可真难看，商家也看不懂。为啥不改成更友好的形式呢 ？ 于是，我修改成了 kdt_2020-05-02-13-49-12.csv 。 猜猜看，发生了什么 ？ 不同商家的报表发生了覆盖

故障和问题是系统设计与开发的指示灯。 引言 俗话说：好的战士，是从枪林弹雨中打出来的。好的工程师，是从沼泥坑洞中踩出来的。 在平常的开发中，人很难主动去思考深入的东西。故障，层出不穷的问题，是开发人员想要回避的却始终难以回避的事情。从正面的角度来看，错误是人类进步的阶梯。故而，每一个显现的故障和问题，也能引导人更加深入地理解系统的运行，思考一些平时很少思考的东西，是很有益的礼物。在有赞的四年里，我踩过不少坑，总结出来，期望对后来者有所启发。 导图 坑位及启示 踩坑不是目标，从踩过的坑中汲取足够的经验教训才划算。如何分析一个坑位呢 ？首先，应当从逻辑上严密地论证为什么会出现这个问题，其严密性如 1+1=2 一样无疑议；其次，带来的启示和指导是怎样的，如何去防范类似的问题。 名字覆盖出错 或许出于对同行的莫可名状的“不满”情绪，程序猿看到不太顺眼的地方，总有一种想要改掉它的冲动。但人在采取行动之前，又容易缺乏思考。因此，冲动常常招致小小的惩罚。 譬如说，我刚接手订单导出。看到报表文件名是：kdt_8fb888f9c9fad7840190d9d1531dddfc.csv 。 心想，这后面一串可真难看，商家也看不懂。为啥不改成更友好的形式呢 ？ 于是，我修改成了 kdt_2020-05-02-13-49-12.csv 。 猜猜看，发生了什么 ？ 不同商家的报表发生了覆盖

环境篇：Atlas2.0.0兼容CDH6.2.0部署 Atlas 是什么? Atlas是一组可扩展和可扩展的核心基础治理服务，使企业能够有效地满足Hadoop中的合规性要求，并允许与整个企业数据生态系统集成。 Apache Atlas为组织提供了开放的元数据管理和治理功能，以建立其数据资产的目录，对这些资产进行分类和治理，并为数据科学家，分析师和数据治理团队提供围绕这些数据资产的协作功能。 如果没有Atlas 大数据表依赖问题不好解决，元数据管理需要自行开发，如：hive血缘依赖图 对于表依赖问题，没有一个可以查询的工具，不方便错误定位，即业务sql开发 官网： http://atlas.apache.org 表与表之间的血缘依赖 字段与字段之间的血缘依赖 1 Atlas 架构原理 2 Atlas 安装及使用 安装需要组件，HDFS、Yarn、Zookeeper、Kafka、Hbase、Solr、Hive，Python2.7环境 需要Maven3.5.0以上，jdk_151以上，python2.7。 2.1 下载源码包2.0.0，IDEA打开 2.2 修改相关版本与CDH版本对应 <hadoop.version>3.0.0</hadoop.version> <hbase.version>2.1.0</hbase.version> <kafka.version>2.1.0<

1、控制table某些行数不显示 　　下载附件的需求，有些行有附件，有些没有，所以需要过滤，重点是：Array.filter()使用 <el-card :body-style= " { padding: '20px 10px' } " > <h5>附件列表</h5> <el-table :data= " quesObj.filter(item => item.attach) " > <el-table-column label= " 附件名称 " align= " center " > <template slot-scope= " scope " > <a :download= " scope.row.attach " :href= " '/api/hbase/readFile?fileName=' + scope.row.attach " >{{scope.row.attach}}</a> </template> </el-table-column> </el-table> </el-card> 2、elementUI的table自定义合计方法 // 1、table上添加summary-method自定义计算方法 <el- table class = " orderStyle " :show -summary = " userInfo && userInfo.roleName

简介 Aerospike 是一个分布式、可扩展的数据库，其架构有三个关键目标: 为 web 规模的应用程序创建一个灵活的、可扩展的平台 提供传统数据库所期望的健壮性和可靠性(如 ACID) 以最少的人工参与提供操作效率 T级别大数据高并发的结构化数据存储解决方案，读写操作达微妙级，99%的响应可在1毫秒内实现，99.9%的响应可在5毫秒内实现。 采用混合架构，索引存储在 RAM 中，而数据存储在闪存/固态硬盘(SSD) 上，自动感知集群，可以随意增加节点线性扩容，无需分片，无需人工干预（性能与节点成正比上升），支持多语言集成；与redis相比不太会遇到性能瓶颈 大部分的源代码是用 c 语言编写的，符合 ANSI C99标准。 为什么要用AS K-V类型的数据库必须要提的就是redis，redis数据完全存储在内存虽然保证了查询性能，但是成本太高。AS最大的卖点就是可以存储在SSD上，并且保证和redis相同的查询性能。 AS内部在访问SSD屏蔽了文件系统层级，直接访问地址，保证了数据的读取速度。 AS同时支持二级索引与聚合，支持简单的sql操作，相比于其他nosql数据库，有一定优势。 Namespaces(库) AS数据存储的最高层级，类比于传统的数据库的库层级，一个namespace包含记录（records），索引（indexes ）及策略（policies）。

01淘宝交易订单系统介绍 天猫和淘宝每天发生的实物和虚拟商品的交易达到亿级别。考虑到一次成功交易的整个链路，会涉及到会员信息验证，商品库信息查询，订单创建，库存扣减，优惠扣减，订单支付，物流信息更新，确认支付等。 链路中的每一环都涉及到数据库中记录的创建和状态的更新，一次成功的交易可能对应到后台信息系统上数百次数据库事务操作，支撑交易系统的整个数据库集群则会承担每日高达数百亿的事务读写。这除了给数据库系统带来巨大的性能挑战之外，每日递增的海量数据也带来巨大的存储成本压力。 交易订单作为其中最为关键的信息，由于可能涉及交易纠纷处理，需要随时提供用户查询，必须永久的记录在数据库中。淘宝成立至今近17年，所有与订单相关的数据库记录总量达到了万亿级别，其所占用的磁盘空间也早已超过PB级。 在一个这样大体量的数据集上，需要能够满足用户随时查询的低延时需求，同时需要达到极低的存储成本，在技术上是一个非常大的挑战。 用户的历史订单记录数据量巨大且不能丢失 02淘宝交易订单库的架构演进历史 淘宝从2003年成立至今近17年的时间，随着流量不断上涨，交易订单数据库的架构也经历过数次演进。 第一阶段，开始由于流量较小，使用了一套Oracle数据存储了所有的订单信息，新订单创建和历史订单查询都在同一套数据库进行。 第二阶段，由于历史订单量数据量越来越大，单一一套库已经不能满足同时满足性能和容量的问题

django是一套开发成本低、迭代周期快的python web框架，而如mysql等关系数据库则是网站的必备组件，django通过设计一套python对象与数据库表的映射系统ORM，使得开发者不用写一行SQL语句就能实现极其复杂的关系数据库操作，特别是关联多张表的SQL操作。这让开发者的精力可以放在业务的迭代实现中，忽略SQL细节，同时提供了还不错的SQL语句性能。本文主要分析该ORM系统的实现原理及其设计思路，顺带描述python 元类 这个“黑魔法”。接下来，我们首先描述django model的一般用法，再说明ORM系统的结构，以及为何如此设计。 关系数据库相对于hbase等面向海量数据的列式存储数据库而言，大多为 行式存储 数据库。所以这里我们主要关注表、行，django的ORM系统中，允许让应用开发者定义一个继承django.db.models.Model（事实上是django.db.models.base.Model）的类对应着表，而该类的实例对应着行的方式操作关系数据库。其中， 类中的静态成员对应着列名称，而实例中的同名成员则对应着一行数据中的列 。例如： 这里的Article代表着表，Article.title是列名。若有实例article=Article()，此时article.title则表示一行中的title列的数据。所以

谈到分布式系统，就不得不提Google的三驾马车:Google fs[1],Mapreduce[2],Bigtable[3]。 虽然Google没有公布这三个产品的源码，但是他发布了这三个产品的详细设计论文。而且，Yahoo资助的Hadoop也有按照这三篇论文的开源Java实现:Hadoop对应Mapreduce, Hadoop Distributed File System (HDFS)对应Google fs,Hbase对应Bigtable。不过在性能上Hadoop比Google要差很多，参见表1。 Experiment HBase20070916 BigTable random reads 272 1212 random reads (mem) Not implemented 10811 random writes 1460 8850 sequential reads 267 4425 sequential writes 1278 8547 Scans 3692 15385 表1。Hbase和BigTable性能比较(来源于http://wiki.apache.org/lucene-hadoop/Hbase/PerformanceEvaluation) 以下分别介绍这三个产品： Google fs GFS是一个可扩展的分布式文件系统，用于大型的、分布式的