本文主要展示“如何在分析数据仓库中实现读写分离”。内容简单易懂，条理清晰。希望能帮你解开疑惑。让边肖带领大家学习学习《分析数据仓库中如何实现读写分离》一文。
与以MySQL为代表的传统事务型数据库相比，数据仓库有一个很大的特点，那就是主要针对批量写入和查询进行优化，不能支持更新和事务等高级功能。一些商业数据仓库分析系统，如Vertica，已经能够在几秒钟内导入和查询数千亿个数据。
厕神数据一直致力于帮助企业建设数据仓库，实现数据的二级响应，积累数据资产。本文主要通过对厕神数据的技术探索和实践，探讨如何利用现有的开源组件实现分析数据仓库中的读写分离。
为什么要进行读写分离
分析数据仓库一般具有以下特点：
(1)面对复杂的多维分析需求，可以任意维度上滚下钻。
(2)存储数据维度多，表宽，一般稀疏。
(3)数据量大，一次写入，多次查询。
针对这一特点，分析型数据库一般选择列存储数据格式，如Parquet等。优点是统计分析效率高，稀疏宽表的存储压缩率高。因此，我们可以认为列存储格式是为读取而优化的存储格式，我们称之为ReadOptized Store(ROS)。
但是列存储格式也有一个缺点：一旦生成这种格式的数据，就很难修改，也很难在现有的数据文件中插入新的数据，只能添加新的数据文件。像MySQL这样的传统数据库使用适合修改和插入的行存储文件格式。我们可以认为这种行存储格式是一种写优化的存储格式，称为写优化存储(WOS)。
综上所述，要实现一个几秒钟就能导入查询的分析型数据库，如果只使用ROS，很难支持大数据量的二级导入。如果只用WOS，很难实现任意维度的二级查询，需要读写分开。
读写分离的实现原理
WOS和ROS都需要存在于数据仓库中，这样我们就可以为所有的写操作生成WOS文件；同时，所有的读取操作主要依赖于ROS文件，但也要查询少量的WOS文件。总体示意图如下：
图1读写分离示意图
如图所示，WOS文件需要定期转换成ROS文件。同时，由于ROS一般存在于数据仓库的多个Partition中，一个WOS可能转化为多个ROS。转换过程需要是原子操作，因为对于上层查询引擎，同一时间只能有一个相同数据的副本。
开源方案的操作
前面简要介绍了读写分离方案的原理。在具体的工程实践过程中，厕神数据的工程师们在方案选择和实践中仍然面临着许多困难。让我们简单介绍一下厕神数据在构建数据仓库的实践中啃过的“硬骨头”。
ROS的选择相对简单。我们的工程师选择了Parquet Impala的查询方案，同时结合我们的业务特点进行了大量的代码级优化。WOS可能有很多选择。我们可以选择常用的HDFS线存储文件格式，如TextFile、SequenceFile、Avro等。
以SequenceFile为例。当我们定义自己的Impala表时，可以将一个特殊partition文件的存储格式指定为SequenceFile，将其他Partition按日期指定为分区的普通数据，将格式指定为Parquet。这种方法的优点是总是只有一个表。
后来基于查询效率和未来架构升级的考虑，我们最终选择了Kudu作为WOS，架构实现示意图如下：
图2读写分离实现图
如图所示，我们将创建三个物理表，其中两个Kudu表作为WOS，一个Parquet表作为ROS。的所有写入操作都会在摄取状态下写入库都表。当摄取表被写入到某个大小时，它将自动转换为分段状态。
此时，一方面，我们生成一个新的Kudu表作为摄取表，另一方面，我们开始从WOS到ROS的转换，并通过一个名为Mover的任务执行该操作。将库都表中处于暂存状态的所有数据转换为分区对应的拼花表。
当Staging状态下的表转换完成，摄取状态下的表已满时，会触发切表操作，需要更新元数据告诉Impala使用新数据进行查询，整个切表操作是原子的。而且，转换后的Staging表需要保存一段时间，以免切割表前发起的查询操作没有及时执行。
完成。
对于查询请求来说，我们会建立一个包含 Staging 表、Ingesting 表和 ROS 表的虚拟表，即一个 View。用户的查询始终指向一个 View，但是下面的物理表会经常发生变化。这样就兼顾查询数据的不断更新及查询性能的优化两方面了。
在实现的过程中还有很多具体的工作，例如如何对表进行加列操作，保证各个表的结构一致；Parquet 表中碎文件较多影响查询效率，如何定期合并等。限于篇幅，这里不再具体介绍。
神策数据最终的技术架构如下图：
以上是“分析型数据仓库中如何实现读写分离”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注行业资讯频道！
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/112491.html