简介

前几天在朋友圈中看到一个富士康面试题，题目是9个球放入4个袋子，如何保证每个袋子都有球且每个袋子中的球是单数。正好这几天又巩固下基础算法，想到个题不是可以用回溯和动态规划去解决吗？其实算法一个非常重要的东西就是建模，如果将现实中的东西抽象成模型，这个问题我们可以将其模型抽象成一个二维数据，一维代表背包的个数，二维代表一个包的所放的球数，对于不同算法，这个模型也有着不同含义，比如对于动态规划，同样使用二维数组去建模，动态规划二维数组代码的确实现在包中一共放了多少个球，另外数组加链表也是一种常用的建模工具，类似HashMap就使用了数组加链表来存储hash冲突的数据，在计算图相邻顶点时我们也会使用这种数据结构，数组下标代表的是当前点，数组中又加了一个链表来存储这个顶点相邻的点。

简介

需求是这样：客户公司对我们开发了一台FTP服务器以供我们上传数据回流给客户，但是客户为了安全原因只对我们开放了固定一台服务器才能进行FTP登录，由于想偷懒，也为了加快该功能的上线使用，所以思考时候能将FTP类似像NFS一样挂载在linux的本地，然后再在我们的服务器上开放一个FTP服务往挂载的客户FTP的目录上写入文件，这里使用的是Centos 7.5

简介

在实践中最常使用的就是查询，而Elasticsearch又提供了丰富的HTTP接口供人们调用（JAVA的高级API其实也差不多），这里借用kibana提供的开发者工具，使用HTTP API对遇到过的常用查询进行总结。

简介

前文只是简单的介绍了ES的使用，但是实际使用中会涉及到一些设计和服务器上参数的调整，这里对其做个简介

JVM

• 内存：Xms和Xmx设置一样，避免堆Resize引发的停顿，Xmx设置不要超过物理内存的百分50,最大不超过32G，JVM在内存小于32G时会对内存进行指针压缩，如果大于32G可能会导致性能下降
• JVM使用Service模式
• 关闭JVM Swapping

硬件

内存

内存的大小需要根据Node所需要的数据来估算

• 搜索类的比例1:16

• 日志类的比例 1:48 -1:96之间

Mapping

ES的Mapping分为动态的Mapping和手动设置的Mapping，所谓动态就是在创建索引时不指定字段的类型，由ES在插入数据时，自动生成对应的类型，比如一下是一个ES自动生成的Mapping，其为content和title自动创建了文本类型，并且为其创建了keyword类型的子字段为了精确匹配，这样导致了资源的浪费，或者在索引效率等问题，所以一般情况下我们会选择手动创建Mapping和关闭自动创建索引功能

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

{
  "news" : {
    "mappings" : {
      "properties" : {
        "content" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "title" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        }
      }
    }
  }
}

如果

写操作优化

对ES的写优化前先大致了解一下ES的写策略,总体ES的写入策略和KAFKA类似(WAL)，分为Refresh和Flush。ES的数据分片的最小单元成员Segment，ES中只有文档变成了生成了Segment才能被检索到，那么文档生成Segment的实效决定了写入了数据多长时间能被检索到，而ES写入的策略是先将数据写在内存的缓冲区，当达到一定条件后将数据生成Segment，这个过程就叫Refresh。我们知道文件系统中存在缓存区，Linux系统中需要调用fsync才能将数据由文件缓存区写入到磁盘，在Refresh时，ES并没有调用fsync，只有当ES在Flush阶段在调用fsync，数据才真正写入磁盘，为了避免数据在Refresh和Flush的阶段中丢失，ES也引入了WAL，在数据写入时写入磁盘日志，来避免数据丢失，那么这里优化的方法其实和kafka没有太大区别，就是优化缓存数据和日志刷新到硬盘的策略。

简介

之前一直有计划学习Elasticsearch，刚好最近趁着项目空档期学习了Elasticsearch 7，且也打消了Elasticsearch和Hadoop MapReduce的使用情景有疑问，因为之前认为这两个框架都是对海量数据进行分析，且Elasticsearch的实时性更好为那么Hadoop的使用场景在哪？这是因为Elasticsearch对于精确复杂的统计分析并不支持，其更多是解决全文搜索而生，而MapReduce更多是为了精确分析而生，具体可看维护篇中关于索引的部分。

简介

基于领域驱动设计(DDD)开发的项目，它具有代码层次分明，业务更好的贴合业务，使代码的可维护性和可读性大大提高等优点，而MAVEN和Spring天生就是为模块化而设计开发的，最近结合之前的DDD使用经验，结合使用MAVEN和Spring对项目的模块化进行一次实践。

简介

程序员最讨厌的事情之一就是写文档,特别是word文档,写好word文档是并不是一件简单的事,以个人经验来看如果有人提供了一份word文档给我阅读,往往阅读效率是很低下的,于是催生出了类似于Markdown或者AsciiDoc这种以编程方式来写文档的工具,通过这些工具的语法,我们可以不需要学习各种排版样式而写入清新的文档,提到rest文档,不可绕开的就是Swagger,目前项目中全部使用了Swagger,但是使用Swagger的优缺点都很明显,优点:方便的工具让前端联调接口更简单,缺点:入侵式的注解让代码看起来杂乱无章,且文档不够直观等,在这些原因的驱使下让我去寻找一款更加清晰的文档工具,本人发现了2款文档工具 1:smart-doc 它是一款非入侵似的文档框架,采用类似java doc的标准注释来生成文档,这也强迫用户必须写注释,但是缺点是由于采用了注释,很多情况下不够灵活,第二个就是Spring Rest doc,来自Spring官方的Spring res doc, 生成的文档样式可以参考Spring的官方文档,其采用AsciiDoc作为编写文档的工具,美观,且更加灵活,并且其于单元测试强制绑定,也驱使我们培养出写单元测试的良好习惯,所以我这里采用Sprng rest doc来编写文档

效果图

简介

项目中使用的CAS后续需要外部系统的接入，这里需要解决两个问题，1：单点登出问题，之前的文章中提到各个接入cas的应用在验证st时会获取到用户信息，然后将用户信息做缓存，下次再次访问这个子应用时就不需要再向cas去获取是否登录，那么这就存在一个问题，CAS已经退出登录，但是各个子应用仍然保存着登录状态，这就导致了用户仍然可以访问子应用。第二个问题，由于在验证st时，cas会返回用户信息，但是cas默认返回的信息有并不能满足项目需求，有些是多余的，还有一些自定义的用户信息并没有返回，这里也需要对信息做重新定制.

简介

之前的文章中概述了如何建设数仓的变化维度，这里对建设变化维度进行实践，本文建设了全国的地市维度，由于地市归属区域有时会变化，这里采用了最常用的类型2来处理，也就是俗称的拉链表.

简介

在之前的项目中采用HDFS和Hive来搭建数据仓库。但是使用HDFS和hive来搭建数据仓库无法做到数据的实时查询,因为hive的本质是mapreduce运算，map和reduce的过程都存储在磁盘，存储在磁盘避免不了磁盘的i/o，随机i/o又是磁盘的主要瓶颈(固态硬盘可从无视)，所以这边对使用hbase搭建数仓库，hbase也是基于hdfs上建设的nosql数据库，之所以它能够做到数据的实时查询是因为它以列去存储数据，并且在数据写入到磁盘时已经将数据排序完成，尽量避免了磁盘的随机i/o而磁盘的顺序读取速度又非常的快，几乎可达到内存的速度，其实我目前除了auto sharding以外，个人比较喜欢hbase可以保留不同版本数据的这个功能，在看过我之前的关于数据建立维度里面就提到，数仓的好坏的难点就是在维度的建设方面，而维度最麻烦的就是处理维度的变化，如果相同的维度数据可以保留多个历史版本，这样就完美解决维度变化这个问题，可是目前我在phoenix并没有看到可以查找到历史数据这个功能，但是在网上查询到有人通过对phoenix修改后达到这个目的。相比关系型数据库其能存储海，这是依托由其auto sharding功能，这使nosql在数据存储扩展方面具有得天独厚的优势，在关系型数据库中对数据进行扩展往往意味着对数据分片或分库的重建，如甚于关系型数据库开发的greenplum就必须在搭建时提前考虑好数据的增长量，如果后序增加节点是非常复杂的事，如果你使用的是诸如mongo或hbase来搭建数据仓库的话就完全不要考虑这方面问题，但Hbase也有自己的缺点其时实查询的功能高度依赖rowkey,并且无法创建索引对列中的具体值进行查找(虽然可从使用api提供的过滤器去查找数据)，所以我们在设计hbase的rowkey时需要尽可能将查询信息都包含在rowkey中。为了解决这个问题，这里尝试使用Phoenix来当作数仓工具来构建数仓，它将传统的Sql语句转换成hbase的api进行查询，并且支持二级索引和联表统计，和自定义函数等功能，hbase相比hive的另一个优势就是可以完美解决小文件的问题，我们都知道hdfs将数据的元数据都存储在namenode的内存中，因此namenode的内存大小限制了文件的数量，因为即使文件再小都要占用固定的元数据大小的空间，所有hdfs的长处是存储大文件，如果我们的数据是许多小文件构成，那么namenode的内存使用效率就地，我们需要定期自己将小文件合并成块，但是hbase就不需要关系这一点，他可以自动的对数据文件进行合并和拆分，然后再存储到hdfs中。