数据库分库分表（二）Twitter-Snowflake（64位分布式ID算法）分析与JAVA实现

Twitter-Snowflake算法产生的背景相当简单，为了满足Twitter每秒上万条消息的请求，每条消息都必须分配一条唯一的id，这些id还需要一些大致的顺序（方便客户端排序），并且在分布式系统中不同机器产生的id必须不同。各种主键ID生成策略对比，见 常见分布式主键ID生成策略

把 41位的时间前缀 ， 10位的节点标识 ， 12位的sequence 组合在一起。

除了最高位bit标记为不可用以外，其余三组bit占位均可浮动，看具体的业务需求而定。 默认情况下41bit的时间戳，1970年算起可以支持该算法使用到2038年，10bit的工作机器id可以支持1024台机器，序列号支持1毫秒产生4096个自增序列id 。

Snowflake是Twitter在2010年用Scala语言写的一套主键生成策略，用Thrift对外发布主键生成服务，其中依赖了Twitter内部的Infrastructure，后来Twitter用 Twitter-server 代替了Snowflake，自2012年起就未更新。见 Twitter-Snowflake项目地址（Tags:snowflake-2010）

之前写了一个Java的实现，改自网上一个版本: Twitter的分布式自增ID算法Snowflake实现分析及其Java、Php和Python版 。后来看到当当网的 Sharding-JDBC 分库分表中间件已实现了此算法。就直接在其中添加了一些新特性，已merge。( 具体实现 , 说明文档 )

添加3种IdGenerator实现。

用笔记本（i7-3632QM 2.2GHz 四核八线程）测试了下，每秒生成409万（理论上的峰值），CPU占用率18.5%。

编译：诚历，阿里巴巴计算平台事业部 EMR 技术专家，Apache Sentry PMC，Apache Commons Committer，目前从事开源大数据存储和优化方面的工作。

像公有云数据湖和 Delta Lake 这样的平台指出了一个中央数据枢纽的趋势，用来支持决策和AI驱动的自动化决策。

数据仓库是否再次加入这股浪潮呢，或者会逐渐消亡？

如果你不清楚这个问题的答案也很正常。数据仓库在一方面目前仍处于热门阶段。笔者作为一个长期的行业观察者，看到了在不断创新和创业活动浪潮下行业的快速发展。

这种趋势基本上始于十年前标准设备进入数据仓库主流，然后随着市场向新一代云数仓转移逐渐获得了新动力。在过去几年中，一个云数仓供应商（Snowflake） 在市场上获得了非常多的支持。

但在另一方面，数据仓库也不断被行业中的新事物所冲击，例如大数据、机器学习和人工智能。这种趋势造成了数据仓库在企业IT优先级下降的印象，但事实上大多数组织至少有一个或者多个数据仓库服务于各种下游应用程序。

数据仓库一直作为企业核心工作服务，是几年前我觉得数据仓库远未消亡的原因，这也可能解释了为什么其他观察者认为他们必须重新定义数据仓库的概念，以使其在数据湖和云计算时代保持相关性。

许多人认为“数据湖”正在迅速发展成为下一代数据仓库。对于那些不熟悉这个概念的人来说，数据湖是多结构数据的系统或存储库，它们以原始格式和模式存储，通常作为对象“blob”或文件存储。

数据湖通常用作所有企业数据的单个存储，包括源系统数据的原始副本和用于生成报告，可视化，数据分析和机器学习等任务的转换数据。它们包含分布式文件或对象存储，机器学习模型库以及高度并行化的处理和存储资源集群。并且，数据库通常在读取时使用模式，并使用统计模型从中提取有意义的相关性和模式，而不是对它们存储的对象强制执行通用模式和语义。

这些都与Inmon和Kimball核心概念不一致，这些概念为大多数专业人员的数据仓库方法提供了信息。从根本上说，一个数据仓库主要用来聚合，保留和管理官方认可的“单一版本的真实”数据记录。此概念与所管理数据的特定应用程序域以及使用它的特定用例无关。

如果你怀疑我在那个分数上说的话，请看看Bill Inmon对数据仓库的定义以及Inmon和Ralph Kimball框架的比较。数据仓库通常都是关于数据驱动的决策支持，这使得它可以很好地扩展到AI驱动的推理的新世界。

在过去的一年中，一些备受瞩目的行业公告标志着数据仓库角色的转变。尽管决策支持（也称为商业智能，报告和在线分析处理）仍然是大多数数据仓库的核心用例，但我们看到了其向决策自动化的稳步转变。换句话说，数据仓库现在正支持着数据科学管道，为数据驱动的推理构建了机器学习应用程序。

新一代数据仓库实际上是数据湖，对那些用于构建和训练机器学习模型的清洗，整合和验证的数据进行管理。例如，去年秋天在Amazon re：Invent 大会上，亚马逊网络服务公布了AWS Lake Formation。这种新的托管服务的明确目的是简化和加速安全数据湖的设置。然而，AWS Lake Formation 拥有云数据仓库的所有特点，尽管AWS并没有这样称呼它，实际上已经提供了一个面向决策支持应用程序的经典数据仓库。

AWS Lake Formation的架构和功能类似于数据仓库。实际上，AWS以这种方式来描述它：“数据湖是一个集中的，策划的和安全的存储库，它以原始形式存储所有数据并为分析做好准备。通过数据湖，您可以分解数据孤岛并组合不同类型的分析，以获商业洞察力并指导更好的业务决策。“

另一个例子是 Databricks 最近宣布的 Delta Lake开源项目。 Delta Lake的明确目的（现在可以在Apache 2.0许可下使用）类似于AWS Lake格式：通过对数据湖中维护的数据集的聚合，清洗，管理和治理，以支持机器学习。

Delta Lake 位于现有的内部部署或云数据存储平台之上，可以从Apache Spark访问，例如HDFS，Amazon S3或Microsoft Azure blob存储。 Delta Lake将数据存储在Parquet中，以提供Databricks所称的“事务存储层”.Parquet是一种开源的列式存储格式，无论数据处理框架的选择如何，都可用于Hadoop生态系统中的任何项目。它通过乐观并发可串行化，快照隔离，数据版本控制，回滚和模式实施来支持ACID事务。

Delta Lake和AWS Lake Formation之间的一个关键区别是 Delta Lake 处理该管道中的批量和流数据。另一个是Delta Lake支持所有数据的ACID事务，允许数百个应用程序同时进行多次写入和读取。此外，开发人员可以访问每个Delta Lake的早期版本，以进行审计，回滚或重现其MLFlow机器学习实验的结果。

在最广泛的层面上，Delta Lake似乎与使用最广泛的开源数据仓库项目 Apache Hive 竞争，尽管 Hive 完全依赖基于 HDFS 的存储，并且直到最近才解决对ACID交易的支持。Hive 3一年前被宣布终于为基于Hadoop的数据仓库提供ACID支持。 Hive 3使用delta文件为事务CRUD（创建读取更新删除）表提供 *** 作的原子性和快照隔离。

这些最近的行业公告 - AWS Lake Formation，Delta Lake和Hive 3预测是数据湖成为所有决策支持和决策自动化应用以及所有交易数据应用的治理中心的日子。为了加速这些趋势，Hive 3和Delta Lake等开源项目需要在供应商和用户之间获得更广泛的吸引力。

“数据仓库”这一术语可能主要指的是商业智能结构化数据的受管理的多域存储。但是，底层数据平台将继续发展，为基于云的人工智能管道提供核心数据治理基础。

AI而非BI正在推动企业数据仓库的发展。

作者：EMR

---