为Linux 挂载新硬盘
最近新购入一块3T硬盘，准备划给Linux 系统2T，用来玩数据分析。开始新硬盘的挂载之旅
1.fdisk -l 查找新硬盘
1 | [root@sloong sloong]# fdisk -l |
可以看到新磁盘为 /dev/sda, 3000G, 扇区 0.5k/4k ,IO大小 4k/4k
Linux 挂载新硬盘
Hadoop Shell
Hadoop_Shell
1 | hdfs文件的相关操作主要使用hadoop fs、hadoop dfs、hdfs dfs 命令，以下对最常用的相关命令进行简要说明。 |
Presto 主动Kill 机制
Presto 主动Kill 机制
背景：用户界面中，为了改善用户使用体验，移除了 查询时点击按钮的操作，变更为只要检测到查询条件的修改都会自动触发计算。而实际使用过程中，用户在最终条件确定前，所有条件变更导致的查询计算均是计算资源的浪费
目的：为了避免自动触发的计算导致Presto 计算资源的浪费
如图所示，左侧指标、细分维度、公共过滤条件以及 日期范围、日期粒度、人群的变化都会导致分析查询的调用
方案:
Hbase rowKey 设计原则
Hbase RowKey 设计
一、引言
HBase由于其存储和读写的高性能，在OLAP即时分析中越来越发挥重要的作用，在易观精细化运营产品–易观方舟也有广泛的应用。作为Nosql数据库的一员，HBase查询只能通过其Rowkey来查询(Rowkey用来表示唯一一行记录)，Rowkey设计的优劣直接影响读写性能。HBase中的数据是按照Rowkey的ASCII字典顺序进行全局排序的,有伙伴可能对ASCII字典序印象不够深刻，下面举例说明：
假如有5个Rowkey：”012”, “0”, “123”, “234”, “3”，按ASCII字典排序后的结果为：”0”, “012”, “123”, “234”, “3”。（注：文末附常用ASCII码表）
Rowkey排序时会先比对两个Rowkey的第一个字节，如果相同，然后会比对第二个字节，依次类推… 对比到第X个字节时，已经超出了其中一个Rowkey的长度，短的Rowkey排在前面。
由于HBase是通过Rowkey查询的，一般Rowkey上都会存一些比较关键的检索信息，我们需要提前想好数据具体需要如何查询，根据查询方式进行数据存储格式的设计，要避免做全表扫描，因为效率特别低。
大数据分析的下一代架构--IOTA架构设计实践
大数据分析的下一代架构–IOTA架构设计实践
基于 易观CTO 郭炜 文章 Lambda架构已死，去ETL化的IOTA才是未来 和 易观方舟IOTA架构实践整理而成
IOTA架构提出背景
在过去，Lambda数据架构成为每一个公司大数据平台必备的架构，它解决了一个公司大数据批量离线处理和实时数据处理的需求。一个典型的Lambda架构如下：
数据从底层的数据源开始，经过各种各样的格式进入大数据平台，在大数据平台中经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算。一条线是进入流式计算平台（例如 Storm、Flink或者Spark Streaming），去计算实时的一些指标；另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔日才能看见。
数据分析中可视化图表缓存策略
数据分析中可视化图表缓存策略
每一次ad-hoc查询，均是会占用有限的计算资源，而OLAP 系统在现有技术下，并不能支撑很高的查询并发，为了有效改善这个问题，在查询时间范围内数据未发生变化或者变化量小，有效运用缓存可以有效提高查询效率和用户体验
1. 问题
单纯的N小时缓存失效的机制，会导致数据刷新不及时，造成数据理解上的偏差：
现象：在相同指标在不同图表数据不一致，尤其是在同一个DashBoard内时，让人难以理解；
原因：图表在不同时间创建和缓存的，在时间差内，相关的数据发生了变更
数据可视化_企业级BI工具Superset简介
简介
- 企业级BI工具
- Superset 是一个数据探索和可视化平台，设计用来提供直观的，可视化的，交互式的分析体验
最初由Airbnb开源，后面进入Apache 软件基金会孵化项目
特性：
- 开源, Apache 孵化项目，迭代进度正常，star数量 2w+
- 可视化方面非常出色，静态的日报、报表，Superset表现力很好
- 图表类型丰富，有时间序列、GEO地理位置、词汇云、等近50种图表类型
- 支持数据源丰富，包括Apache Kylin、Clickhouse、Hive
- 支持数据切片、SQL-Lab
- 数据能力取决于数据源
项目地址：
