#onenote# sbt

快速参考 常用命令 actions – 显示这个项目中可用的动作 update – 下载依赖 compile – 编译源文件 test – 运行测试 package – 创建一个可发布的jar文件 publish-local – 在本地ivy缓存中安装构建好的jar包 publish – 将你的jar推到一个远程库中(如果配置了的话) 更多命令 test-failed – 运行所有失败的规格测试 test-quick – 运行任何失败的和/或依赖更新的规格 clean-cache – 删除SBT缓存各种的东西。就像sbt的clean命令 clean-lib – 删除lib_managed下的一切       Sample SBT认为project/build目录中的Scala文件是项目定义。添加以下内容到这个文件中project/build/SampleProject.scala import sbt._ class SampleProject(info: ProjectInfo) extends DefaultProject(info) { val jackson = “org.codehaus.jackson” % “jackson-core-asl”… Continue reading #onenote# sbt

#onenote# JPA

1. A JPA entity must have some Id defined. But a JPA Id does not necessarily have to be mapped on the table primary key, use @EmbeddedId for composite key   @Entity @Table(name=”entity_property”) public class EntityProperty { @EmbeddedId private EntityPropertyPK id; @Column(name = “value”) private String value; … }   AttributeOverride @Entity public class Office {   @TableGenerator(name =… Continue reading #onenote# JPA

#onenote# Big data Architect

Lambda vs Kappa Over the past few years, there have been many discussions about how to design a good real-time data processing architecture. A good real-time data processing architecture needs to be fault-tolerant and scalable; it needs to support batch and incremental updates, and must be extensible. One important milestone in these discussions was Nathan… Continue reading #onenote# Big data Architect

#onenote# – paxos, gossip

分布式基础通信协议:paxos,totem和gossip 背景: 在分布式中,最难解决的一个问题就是多个节点间数据同步问题。为了解决这样的问题,涌现出了各种奇思妙想。只有在解决了如何进行信息同步的基础之上才衍生出形形色色的应用。这里开始介绍几种分布式通信协议。 简单即有效——totem协议: totem协议也许你还比较陌生,但是corosync就是totem协议的一个开源实现。比较火的HA软件pacemaker就是基于corosync来提供各种服务的。说起totem协议,最简单的形象就是,他将多个节点组成一个令牌环。多个节点手拉手形成一个圈,大家依次的传递token。只有获取到token的节点才有发送消息的权利。简单有效的解决了在分布式系统中各个节点的同步问题,因为只有一个节点会在一个时刻发送消息,不会出现冲突。当然,如果有节点发生意外时,令牌环就会断掉,此时大家不能够通信,而是重新组建出一个新的令牌环。 进化的二段提交——paxos协议: 说起paxos,需要稍微提提二段提交。简单来说,二阶段提交就是1.一个节点询问其他节点,我是不是可以进行消息提交。2.如果收到所有人的同意,则告诉大家,开始提交吧。这个协议在实际中并不能很好的解决分布式中信息同步问题。例如只要有节点失效,就会发生得不到所有人同意的结果,在超时后,这一次提交失败,等一系列问题。但是paxos在对二段提交进行了优化后,得到了一个比较好的解决办法。 paxos协议引入了多数派,以及消息编号的概念。在1准备时,询问2/n+1的参与者,要求他们保证不会接受小于编号n的提交。 2.如果得到了2/n+1的回复,则可以开始告诉2/n+1的参与者进行消息的提交。 可以明显的看出,这就是对二段提交的一个优化版。就是这么一个比较巧妙的思想,解决了一些二阶段提交带来的问题。 顺便说一句,这个协议的作者Leslie Lamport。他刚刚获得2013年图灵奖。 奇思妙想——gossip协议: gossip协议是一个神奇的协议。它常用于P2P的通信协议,这个协议就是模拟人类中传播谣言的行为而来。简单的描述下这个协议,首先要传播谣言就要有种子节点。种子节点每秒都会随机向其他节点发送自己所拥有的节点列表,以及需要传播的消息。任何新加入的节点,就在这种传播方式下很快地被全网所知道。这个协议的神奇就在于它从设计开始就没想到信息一定要传递给所有的节点,但是随着时间的增长,在最终的某一时刻,全网会得到相同的信息。当然这个时刻可能仅仅存在于理论,永远不可达。 基础协议的对比: 简单的介绍了这几种协议,下面我们来看看他们的对比: 基础协议 paxos totem gossip 数据同步 第一阶段:   proposer 选择一个提案编号 n 并将 prepare 请求发送给acceptors 中的一个多数派;acceptor 收到 prepare 消息后,如果提案的编号大于它已经回复的所有 prepare 消息,则 acceptor 将自己上次的批准回复给 proposer并承诺不再批准小于 n 的提案。 第二阶段: 当一个 proposor 收到了多数 acceptors 对 prepare 的回复后,就进入批准阶段。它要向回复 prepare 请求的acceptors 发送 accept 请求,包括编号 n 和根据… Continue reading #onenote# – paxos, gossip

#onenote# Conceptual, Logical and Physical Data Models

What are Conceptual, Logical and Physical Data Models? Like all good data architects, I want to define the terms I use on this blog, speaking engagements, and on my projects.  And like most data professionals, I’ve discovered that the industry has multiple, often conflicting, definitions of data modeling terms, which I find sadly ironic.  My… Continue reading #onenote# Conceptual, Logical and Physical Data Models