《 “简单整理一下OLAP数据库的发展历程” 》 有 5 条评论

1. 京东李海波：OLAP关键技术演进思考
   https://mp.weixin.qq.com/s/ORPob1cGRjKCMeupb-bgDw
   `
   在众多的OLAP引擎中如何选型，我这里挑选几个典型问题，大家可以带着问题去阅读：

   ① 查询的数据规模有多大，百万级、亿级还是百亿级

   ② 是T+1的数据，还是分钟级实时写入需求

   ③ 数据表的维度和指标是否存在频繁变更的需求

   ④ 是否存在某条数据需要被更新需求

   ⑤ 是否有对历史数据重新计算的需求

   ⑥ 公司在OLAP上的投入有多大如人力或服务器资源

   # 未来趋势：简化与融合

   OLAP以支持实时、支持Schema演进，具有高吞吐写入和低延时查询能力，近几年获得了爆发式的发展，证明了OLAP面对复杂多变、快速演化的数据分析需求有强大的适应性。

   但应该看到，**目前尚没有一个开源的OLAP组件能够适应各种场景，能够兼顾实时性、性能、灵活性、高可用性、可扩展性、弹性、和可维护性等方方面面**，这样就使得一家公司会存在多个OLAP组件，同时列存设计也导致部分OLAP引擎存在高频更新和点查能力中存在短板。

   同时，经过10多年的发展，现在的大数据生态日趋成熟，各类组件层出不穷，某个组件能解决特定领域的问题，在OLAP领域，上游需要对接各种数据源、数据管道和计算引擎，下游需要对接各种查询器、报表和分析产品，处在一个数据流的中心关键环节。**但是形成一个完整的数据分析解决方案时，需要各种组件的搭配，存在组件多复杂、使用门槛高、稳定性不足等问题。**

   如果从用户的角度去思考，他们对数据分析的诉求可能是，把数据写进去并能查询出来，同时支持各种优化和演进，最好数据也能被其他服务如算法引擎也能使用。**用户迫切需要一个简单、高性能和稳定的数据解决方案，但实际上现有的技术做不到，现有技术能力约束了现有的架构门槛高、架构复杂、TCO成本高。**

   如果乐观的看待以上的问题，**技术的发展总是要和用户的需求相匹配**，我认为大致上有三类趋势：

   ① 联邦查询，指利用一款OLAP引擎的查询引擎能力，去查询和关联异构组件的数据源，比如在中ClickHouse或Doris中，可以查询MySQL、Hive以及ElasticSearch中的数据，这种方式可以把OLAP的高性能和各个组件存储优势结合，对外提供统一的查询服务。

   ② 混合存储，联邦查询发展的另一种形式是，在OLAP中内嵌其他存储引擎，做到无缝集成，比如在一款OLAP引擎中内嵌ElasticSearch的搜索引擎能力，或者内置KV存储或事务数据库行存。同时，利用多副本保证数据安全性，上层统一的SQL引擎，协调器把查询调度各种数据节点。

   ③ 湖仓一体，数据湖阶段是解决Hadoop僵化的缺陷，湖仓一体阶段就应当解决各种写入吞吐、各种计算负载的更大范围场景的问题，把数据湖的开放性、兼容性和数仓（指数仓引擎如OLAP）的高性能和灵活性相结合，湖仓一体化存储可以同时支持BI和AI两大类场景，支持即席分析、低延时查询和点查询等各种场景。

   OLAP提供了软硬件一体化的极致性能，但云原生极致弹性能力是云数仓必备的能力，在电商大促或红包活动中也需要快速扩缩容，这是未来的一个趋势是通用型能力。

   我们可以看到，OLAP走过了内聚性发展的阶段，比拼性能和功能的上半场已经结束，下半场开始逐步外延到其他领域。用户需求正推动着数据分析系统不断走向简化，数据库和大数据两大技术在OLAP领域互相借鉴中走向融合，开发者也在致力于提供一个简单灵活、高效可靠的分析系统而努力，我相信OLAP领域的未来会越来越美好。
   `

   Hadoop: https://www.edureka.co/blog/hadoop-ecosystem

   Druid: https://anskarl.github.io/post/2019/druid-part-1/

   Kyligens: https://kylin.apache.org/cn/

   ES: https://www.elastic.co/cn/pdf/architecture-best-practices.pdf

   Doris: https://doris.apache.org/

   Impala: https://impala.apache.org/

   AWS: https://aws.amazon.com/cn/blogs/china/build-intelligent-lake-warehouse-on-amazon-cloud-technology/

   大数据技术架构: https://baijiahao.baidu.com/s?id=1725750501708712603&wfr=spider&for=pc

   列存: https://draveness.me/whys-the-design-olap-column-oriented/

   Google Mesa: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/42851.pdf

   向量和编译执行: https://www.vldb.org/pvldb/vol11/p2209-kersten.pdf

   浅谈OLAP系统核心技术点: https://zhuanlan.zhihu.com/p/163236128

   回复

2. 从传统数据库痛点看分布式数据库选型问题
   https://open.oceanbase.com/blog/1549948672
   `
   # 引言
   近年来，随着互联网大厂掀起分布式数据库的技术浪潮，中小型互联网企业也在不同业务场景下纷纷试水分布式数据库，电信、金融、银行、保险等传统领域的大型企业也逐渐转向分布式数据库，这也成为DBA这个小圈子中热议的话题。 确实，从现实需求上看，各行各行业的数据量与日俱增，在这样的背景下，我们需要“随波逐流”布局分布式数据库吗？以下为个人浅显的思考，供大家简单参考、水平有限如有错误烦请指正。

   # 传统数据库痛点

   特性1：高可用问题。

   MySQL本身是不具备高可用能力的，它的高可用能力通过外部工具协助达成（MySQL高可用方案随着复制的改进有漫长的演化历史）。众所周知，高可用工具往往只能最大限度解决数据一致性的问题，而不能解决HA切换后应用访问的问题，通常一个完整的高可用系统是要HA工具+Proxy联动+ClientDriver连接池合理配置共同实现的。遗憾的是，时至今日不少中小公司并没有丝滑解决HA切换的问题，主要原因是HA工具+Proxy深度定制能力欠缺，篇幅原因不做展开。

   特性2：数据一致性问题。

   数据复制是存在时差的，造成读一致性问题，但这通常不是太大的问题，通过Proxy bindmaster操作都能解决，不过，master压力可能会同样面临性能瓶颈。

   特性3：容量、性能扩展、结构变更。

   这是传统单机数据库的三宗罪。存储的扩展在一定程度内可以通过堆硬件（垂直扩容）的方式来解决，但堆硬件也是有限度的，出于可运维、易运维的角度，通常DBA都不会让单实例或者单表太大。可能对于一个冷的日志表存储超过1TB DBA可能就会比较紧张了，毕竟DDL一次可能要以天计算，而对于一个读写高频的订单表超过500GB，估计DBA维护就会如履薄冰瑟瑟发抖了！这时棘手的问题就来了：给够你硬件你都不敢用。

   通过堆硬件能在一定程度上缓解存储容量上限的问题，但性能问题是无法靠堆硬件完全解决的。还以订单表为例，如果是日订单百万甚至千万级别，无论怎么折腾单表都会出现严重的读写性能问题，此时通过扩容硬件的方式不能解决问题。一方面是因为数据库本身会由于热点表的高频读写造成严重的锁放大问题，另一方面数据库本身并不能充分使用硬件资源，尤其MySQL 5.6之前的版本由于诸多子线程未从Master主程上拆分，造成CPU使用不充分，这在MySQL 5.7版本后有了很大的改观。尽管如此，还是会受到网卡、磁盘IOPS上限因素的影响，注定单机构成的数据库集群存在性能上限。因此不幸的是：给你足够的资源你都用不到。

   不敢用、用不到都很痛苦！为此就诞生了“拆”的想法，根据不同的“拆”法诞生了不同形态的分布式数据库。值得一提的是今天做数据库拆分的初衷并不是为了解决性能瓶颈而是数据存储达到单机上限，更直白一点地说，拆的关键是解决大表运维困境。

   特性4：HTAP。

   新时代赋予数据处理新的诉求，目前解决方案还是通过数据流（ETL）的方式将数据写到其他分析型数据库中。不管是链路维护复杂性还是应用健壮性（低延迟、高稳定性）都有不小的麻烦。因此，希望能通过一套数据库搞定所有问题。

   特性5：容灾能力。

   近几年企业对容灾的要求越来越高，作为DBA也应当确保极端情况下（机房限电、被炸等）数据库具备逃逸能力。单机数据库通过主从（异地部署）方式也能实现，虽然维护较为复杂但也能用。

   # 分布式数据库形态划分
   1、分布式中间件
   2、存储计算分离
   3、原生分布式

   # 对比总结

   # 选型技术之外的考量因素

   即使通过上述简单的对比，选择依据似乎还不够。还要从如下几个方面进行考虑。

   1. 成熟度。

   一款数据库成熟度怎么样可以从历史版本发布情况来简单分析，如果频繁的大版本发布及小版本修复各种致命bug、缺陷等，显然不能被一般外部用户接受。以MySQL为例，2005 年 MySQL 5.0发布到今天MySQL 8.0成熟经历了17年，其中MySQL 8.0从2016年发布到今天一个版本的稳定打磨就经历了7年！数据库注定是要十年磨一剑的。

   2. 标杆应用。

   在业内是否被大规模验证过了，或者有标志性的成功案例。很多国产数据库目前整体还是闭塞的虽然号称在金融、电信、银行、保险等领域上线了，但实际情况怎么样完全不得而知，尤其互联网公司崇尚的是开源这一类的数据库很难被接受。

   3. 技术底蕴&靠山

   所谓大厂出品必属精品，随便一个什么公司搞一个数据库是很难被接受的。大家普遍认可业内顶尖的一流公司做背书的产品，甚至在深入了解一下开发这款数据库的团队靠谱吗？毕竟数据库的复杂度堪比操作系统，要求非常高，甚至团队规模怎么样，不要指望百十人的团队能写出靠谱的数据库（KPI产品例外）。当然中间件方案的分布式例外，毕竟核心是做Proxy，复杂度远不在一个数量级上。

   4. 生态。

   生态主要看技术、人才、文档、服务这四方面。

   技术方面，业务接入的改造是否低成本，或者说是否能复用成熟的生态(比如TiDB和OceanBase都是完整支持MySQL协议的)，是否足够开放让社区或者相关从业人员尽可能参与进来？比如TiDB这方面做的就很好。周边生态工具是否齐全，比如业务研发高频使用的IDE工具，DBA更加关心的一些技术接口或者现成的实用运维工具等。

   人才方面，市场是否有足够数量的从业人员如DBA。

   文档方面，此前国产数据库整体上文档完整性比较弱，现在好很多了，不过整体文档水平跟MySQL这样的开文档比还有差距，很明显的感受是：告诉你怎么用，很少告诉你为什么或者原理性的东西比较少，可能是写文档的同学不是内核研发。

   服务方面，国产数据库的诞生有现实的需求，但整体相比传统商业数据库成熟度还不够，因此需要更好的售后服务及支撑体系才能弥补整体的不足。分布式数据库未来上云是个大方向，毕竟对绝大部公司而言是很难有人力跟能力去驾驭一个复杂的、成熟度有待打磨的产品。

   5. ROI

   主要看引入分布式要解决什么问题，如果是成本，很不幸小范围引入分布式数据库可能成本会更高！毕竟相比单机数据库，分布式数据库普遍对硬件成本要求非常高，比如TiDB和OceanBase都有很高的硬件要求（OceanBase4.0小型化后改观很多）。如果是性能优化那更不幸，通常benchmark可能跑不过单机数据库！分布式数据库的整体收益只能在达到一定规模后才能发挥出成本、性能优势。因此，如果只是某个单一场景引入分布式来解决可能不是太好的选择。据说携程是做了大规模MySQ/Oracle升级OceanBase，相信他们应该有相关的数据可供参考。

   关于ROI可以简单的比喻：分布式是卡车，拉的多跑的慢，单机数据库是轿车拉的少跑的快，因此要有个平衡。最后引用一句话:“过早的优化是万恶之源”。

   6. 兼容性验证

   虽然很多数据库都号称100%兼容MySQL等协议，但还是要以自己的实际验证结果为准（99.99%的兼容跟100%的兼容对结果的影响是巨大的）。起码你要有SQL流量回放能力来验证执行计划跟执行效率的差异吧。此外，对于能否平滑迁移，成熟的产品往往有一套完整的解决方案，要考虑上线后你真的能驾驭它吗。
   `

   回复

3. 聊聊 HTAP 的前世今生
   https://zhuanlan.zhihu.com/p/608829987
   https://xie.infoq.cn/article/77c4366f13b3fcba53bdce7c4
   `
   随着现代社会大型实时分析应用的逐渐流行，关系型数据库已经难以处理高并发的事务请求。商业层面上，当全球进入数字化时代，数字化技术渗透到各行各业，同时产生了海量数据，数据的存储和应用是企业决策的重要依据之一，业务需要实时根据TP的落地数据进行C端快速反馈，比如实时风控，交易历史明细查询，欺诈监测等等。技术上，由于传统的数仓ETL链路长，延迟大，很难满足业务快速多变的诉求，业务场景的变化也掀起了一股 HTAP 浪潮。

   一、HTAP 诞生的背景

   在二十世纪六十年代，商业部门的计算机开始用于工资单交易。联机事务处理OLTP（On-Line Transaction Processing） 得到进一步发展，导致 OLTP 在政府和商业部门信息系统中的广泛使用。OLAP （On-Line Analytical Processing) 是在 OLTP 术语上修改而创建的。在 HTAP 概念之前，业务类型大致可以分成两大类：联机事务处理 OLTP、联机分析处理 OLAP。

   OLTP 是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
   OLAP 是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观的查询结果，例如业务销售报表。
   （一）传统 OLTP 与 OLAP 分离架构
   在同一组织中，通常 OLTP 和 OLAP 系统并存，且 OLAP 数据来源于 OLTP 系统，系统架构大致可分为 ETL 数据同步和数据库 LOG 同步两种，以下的两种架构都各有优缺点。

   （二）分析型需求崛起推动技术架构演进
   1990 年代以前, 日常处理相关的动态业务以 OLTP 需求为主，OLAP 并未独立；随着数据量不断增多、场景逐渐丰富，分析型需求开始普及，1990s MPP 架构的 OLAP 产品开始出现； 2010s，物联网等技术的发展，使得企业对实时数据分析的需求提升，且OLAP、大数据技术栈不断分化也给企业实际运维管理多套系统带来挑战，HTAP 混合事务分析处理数据库的概念也应运而生。

   二、HTAP 数据库的核心技术

   目前HTAP的相关技术包括：事务处理 (TP) 技术、分析处理（AP）技术、数据同步 (DS) 技术、查询优化技术、资源调度技术。这些关键技术被 HTAP 数据库采用。然而，它们在各种指标上各有利弊，例如效率、可扩展性和新鲜度。

   （一）事务处理 (TP) 技术
   （二）分析处理（AP）技术
   （三）数据同步 (DS) 技术
   （四）查询优化技术
   （五）资源调度技术

   三、中国 HTAP 数据库发展现状

   四、HTAP 数据库的挑战与机遇
   `

   回复

4. 数据模型及其发展历程
   https://www.jos.org.cn/jos/article/pdf/5649
   `
   数据库是数据管理的技术，是计算机学科的重要分支。经过近半个世纪的发展，数据库技术形成了坚实的理论基础、成熟的商业产品和广泛的应用领域。

   数据模型描述了数据库中数据的存储方式和操作方式。从数据组织形式，可以将数据模型分为结构化模型、半结构化模型、OLAP 分析模型和大数据模型。

   20 世纪 60 年代中后期到 90 年代初，结构化模型最早被提出，其主要包括层次模型、网状模型、关系模型和面向对象模型等。
   20 世纪 90 年代末期，随着互联网应用和科学计算等复杂应用的快速发展，开始出现半结构化模型，包括XML模型、JSON模型和图模型等。
   21 世纪，随着电子商务、商业智能等应用的不断发展，数据分析模型成为研究热点，主要包括关系型 ROLAP 和多维型 MOLAP。
   2010 年以来，随着大数据工业应用的快速发展，以 NoSQL 和 NewSQL 数据库系统为代表的大数据模型成为新的研究热点。

   对上述数据模型进行了综述，并选取每个模型的典型数据库系统进行了性能的分析。

   关键词: 数据模型;结构化模型;半结构化模型;OLAP 分析模型;大数据模型
   `

   大数据四大阵营之OLTP阵营（上）
   https://mp.weixin.qq.com/s/opD-0m4TVbdgnnHCRxtSEg
   `
   大数据的四大阵营是什么?
   依据不同的实现理念、方式以及应对不同的业务及应用场景，可以把大数据解决方案划分为四大类!

   · OLTP（在线事务、交易处理）：
   RDBMS、NoSQL、NewSQL

   · OLAP（在线分析处理）：
   MapReduce、Hadoop、Spark等

   · MPP（大规模并行处理）：
   Greenplum、Teradata Aster等

   · 流数据管理：
   CEP/Esper、Storm、Spark Stream、Flume等

   OLTP阵营可以分为，传统的关系型数据库、NoSQL和NewSQL，这三类不同的解决方案。在本篇文章中，我们主要针对NoSQL与NewSQL进行讨论。

   以下再对颇具代表性的MongoDB（文档型）、Cassandra（宽表型）、Redis（键值型）和Neo4j（图数据库）解决方案进行介绍。
   `
   大数据四大阵营之OLTP阵营（下）
   https://mp.weixin.qq.com/s/Xenpqa39dapX5kq3Nuq9lQ

   回复

5. Apache Doris 助力中国联通万亿日志数据分析提速 10 倍
   https://mp.weixin.qq.com/s/ma9jtKD0_fNIre2gnvSRcw
   `
   在数据安全管理体系的背后，离不开对安全日志数据的存储与分析。以终端设备为例，每天会产生海量的设备日志，这些日志数据记录着各种网络时间和系统操作的细节信息，对于保障网络安全、提高系统稳定性和可靠性具有至关重要的作用。为了更好的管理和分析安全日志数据，联通西部创新研究院应集团要求构建一个集中化日志数据分析平台，满足对事件和日志数据自动化采集、存储、管理、分析和可视化的诉求。这要求集中化数据分析平台具备以下能力：

   * 建模分析：基于网络日志数据和告警数据进行规则或智能挖掘，发现潜在的安全事件，例如钓鱼邮件、非法访问等，并进行定向威胁感知。

   * 态势大屏：通过多种维度不同监控指标的组合，例如安全事件 TOP5 等，密切监控当前网络安全态势状况，通过态势大屏呈现攻击威胁的主要分布。

   * 追踪溯源：通过对安全事件的快速研判，还原整个攻击链条进行精准的溯源取证，从而保障网络和数据安全。

   为搭建具备上述能力的集中化日志数据分析平台，在正式搭建之前，结合日志数据的特性及业务要求，我们需要综合考虑考虑如何满足以下要求，以确保平台能高效的支持联通日志分析场景的实际应用：

   * 数据接入方面：日志数据具有种类繁多、格式多样化、规模庞大等特点，要求数据平台支持多种日志格式数据的导入，并支持高性能的数据写入。

   * 实时性要求方面：为及时监控和了解系统运营情况和存在的问题，高实时性对于数据平台非常关键。这要求平台要实时进行数据同步，保障数据的一致性，并支持数据实时查询，以便获取最新的系统和业务状态。

   * 可扩展要求方面：数据平台需要具备计算与存储的拓展能力，以便满足集团及分公司不断增长的数据处理分析需求。

   基于 Hive 的离线数据仓库
   (新)系统选型及落地
   基于 Doris 的实时数据仓库
   新架构的应用实践
   * 日增百亿数据，稳定快速导入
   * 存储资源合理配置，成本节约 50%
   * 数据规模分级查询，查询速度提升 10+ 倍
   `

   回复