种子搜索网站开发,万维网 网站到期,qq网页版一键登录,基础建设的意义简介#xff1a; 随着互联网技术的日渐发展、数据规模的扩大与复杂的需求场景的产生#xff0c;传统的大数据架构无法承载。 作者 | 志羽 来源 | 阿里技术公众号 一 前言 传统的大数据技术起源于 Google 三架马车 GFS、MapReduce、Bigtable#xff0c;以及其衍生的开源分布…简介 随着互联网技术的日渐发展、数据规模的扩大与复杂的需求场景的产生传统的大数据架构无法承载。 作者 | 志羽 来源 | 阿里技术公众号 一 前言 传统的大数据技术起源于 Google 三架马车 GFS、MapReduce、Bigtable以及其衍生的开源分布式文件系统 HDFS分布式计算引擎 MapReduce以及分布式数据库 HBase。最初的大数据技术与需求往往集中在超大规模数据存储、数据处理、在线查询等。在这个阶段很多公司会选择自建机房部署 Hadoop 的方式大数据技术与需求集中在离线计算与大规模存储上常见的体现方式有 T1 报表大规模数据在线查询等。 随着互联网技术的日渐发展、数据规模的扩大与复杂的需求场景的产生传统的大数据架构无法承载。大数据架构在近些年的演进主要体现下以下几方面 规模化这里的规模化主要体现在大数据技术的使用规模上和数据规模的增长。大数据技术的使用规模增长代表越来越多的复杂需求产生而数据规模的增长决定了传统的准大数据技术如 MySQL无法解决所有问题。因此拿存储组件举例来说通常会划分到不同的数据分层面向规模、成本、查询和分析性能等不同维度的优化偏向以满足多样性的需求。实时化传统的 T1 的离线大数据技术无法满足推荐、监控类近实时的需求整个大数据生态和技术架构在过去十年发生了很大的升级换代。就存储上来说传统的 HDFS 文件存储、Hive 数仓无法满足低成本可更新迭代的需求因此滋生出 Hudi 等数据方案。就计算上来说传统的 MapReduce 批处理的能力无法做到秒级的数据处理先后出现 Storm 较原始的实时处理和 Spark Streaming 的微批处理目前由 Flink 基于 Dataflow 模型的实时计算框架在实时计算领域占据绝对主导地位。云原生化传统的公司往往会选择自建机房或者在云上购买机器部署实例这种云托管的形式但这种架构存在低谷期利用率低存储计算不分离导致的存储和计算弹性差以及升级灵活度低等各种问题。云原生大数据架构就是所谓的数据湖其本质就是充分利用云上的弹性资源来实现一个统一管理、统一存储、弹性计算的大数据架构变革了传统大数据架构基于物理集群和本地磁盘的计算存储架构。其主要技术特征是存储和计算分离和 Serverless。在云原生大数据架构中每一层架构都在往服务化的趋势演进存储服务化、计算服务化、元数据管理服务化等。每个组件都被要求拆分成不同的单元具备独立扩展的能力更开放、更灵活、更弹性。 本篇文章将基于云原生大数据架构的场景详细讨论实时计算中的维表和结果表的架构选型。 二 大数据架构中的实时计算 1 实时计算场景 大数据的高速发展已经超过 10 年大数据也正在从计算规模化向更加实时化的趋势演进。实时计算场景主要有以下几种最常见的场景 实时数仓实时数仓主要应用在网站 PV / UV 统计、交易数据统计、商品销量统计等各类交易型数据场景中。在这种场景下实时计算任务通过订阅业务实时数据源将信息实时秒级分析最终呈现在业务大屏中给决策者使用方便判断企业运营状况和活动促销的情况。实时推荐实时推荐主要是基于 AI 技术根据用户喜好进行个性化推荐。常见于短视频场景、内容资讯场景、电商购物等场景。在这种场景下通过用户的历史点击情况实时判断用户喜好从而进行针对性推荐以达到增加用户粘性的效果。数据 ETL实时的 ETL 场景常见于数据同步任务中。比如数据库中不同表的同步、转化或者是不同数据库的同步或者是进行数据聚合预处理等操作最终将结果写入数据仓库或者数据湖进行归档沉淀。这种场景主要是为后续的业务深度分析进行前期准备工作。实时诊断这种常见于金融类或者是交易类业务场景。在这些场景中针对行业的独特性需要有反作弊监管根据实时短时间之内的行为判定用户是否为作弊用户做到及时止损。该场景对时效性要求极高通过实时计算任务对异常数据检测实时发现异常并进行及时止损。 2 Flink SQL 实时计算 实时计算需要后台有一套极其强大的大数据计算能力Apache Flink 作为一款开源大数据实时计算技术应运而生。由于传统的 Hadoop、Spark 等计算引擎本质上是批计算引擎通过对有限的数据集进行数据处理其处理时效性是不能保证的。而 Apache Flink 从设计之初就以定位为流式计算引擎它可以实时订阅实时产生的流式数据对数据进行实时分析处理并产生结果让数据在第一时间发挥价值。 Flink 选择了 SQL 这种声明式语言作为顶层 API方便用户使用也符合云原生大数据架构的趋势 大数据普惠规模生产Flink SQL 能够根据查询语句自动优化生成最优的物理执行计划屏蔽大数据计算中的复杂性大幅降低用户使用门槛以达到大数据普惠的效果。流批一体Flink SQL 具备流批统一的特性无论是流任务还是批处理任务都给用户提供相同的语义和统一的开发体验方便业务离线任务转实时。屏蔽底层存储差异Flink 通过提供 SQL 统一查询语言屏蔽底层数据存储的差异方便业务在多样性的大数据存储中进行灵活切换对云上大数据架构进行更开放、灵活的调整。上图是 Flink SQL 的一些基本操作。可以看到 SQL 的语法和标准 SQL 非常类似示例中包括了基本的 SELECT、FILTER 操作可以使用内置函数如日期的格式化也可以在注册函数后使用自定义函数。 Flink SQL 将实时计算拆分成源表结果表和维表三种将这三种表的 DDL 语句比如 CREATE TABLE注册各类输入、输出的数据源通过 SQL 的 DML比如 INSERT INTO表示实时计算任务的拓扑关系以达到通过 SQL 完成实时计算任务开发的效果。 源表主要代表消息系统类的输入比如 KafkaMQMessage Queue或者 CDCChange Data Capture例如将 MySQL binlog 转换成实时流输入。结果表主要代表 Flink 将每条实时处理完的数据写入的目标存储如 MySQLHBase 等数据库。维表主要代表存储数据维度信息的数据源。在实时计算中因为数据采集端采集到的数据往往比较有限在做数据分析之前就要先将所需的维度信息补全而维表就是代表存储数据维度信息的数据源。常见的用户维表有 MySQLRedis 等。 下图是一个完整的实时计算示例示例中的 Flink SQL 任务这个任务的目标是计算每分钟不同商品分类的 GMV (Gross Merchandise Volume即商品交易总额)。在这个任务中Flink 实时消费用户订单数据的 Kafka 源表通过 Redis 维表将商品 id 关联起来获取到商品分类按照 1 分钟间隔的滚动窗口按商品分类将总计的交易金额计算出来将最后的结果写入 RDSRelational Database Service如 MySQL 结果表中。 # 源表 - 用户订单数据代表某个用户user_id在 timestamp 时按 price 的价格购买了商品item_id CREATE TEMPORARY TABLE user_action_source (timestamp BIGINT,user_id BIGINT,item_id BIGINT,price DOUBLE,SQs ) WITH (connector kafka,topic your_topic,properties.bootstrap.servers your_kafka_server:9092,properties.group.id your_consumer_groupformat json,scan.startup.mode latest-offset );# 维表 - 物品详情 CREATE TEMPORARY TABLE item_detail_dim (id STRING,catagory STRING,PRIMARY KEY (id) NOT ENFORCED ) WITH (connector redis,host your_redis_host,port your_redis_port,password your_redis_password,dbNum your_db_num );# 结果表 - 按时间分钟和分类的 GMV 输出 CREATE TEMPORARY TABLE gmv_output (time_minute STRING,catagory STRING,gmv DOUBLE,PRIMARY KEY (time_minute, catagory) ) WITH (typerds,urlyour_jdbc_mysql_url_with_database,tableNameyour_table,userNameyour_mysql_database_username,passwordyour_mysql_database_password );# 处理过程 INSERT INTO gmv_output SELECT TUMBLE_START(s.timestamp, INTERVAL 1 MINUTES) as time_minute,d.catagory,SUM(d.price) as gmv FROMuser_action_source sJOIN item_detail_dim FOR SYSTEM_TIME AS OF PROCTIME() as dON s.item_id d.id GROUP BY TUMBLE(s.timestamp, INTERVAL 1 MINUTES), d.catagory; 这是一个很常见的实时计算的处理链路。后续章节中我们将针对实时计算的维表和结果表的关键能力进行展开分析并分别进行架构选型的讨论。 三 实时计算维表 1 关键需求 在数据仓库的建设中一般都会围绕着星型模型和雪花模型来设计表关系或者结构。实时计算也不例外一种常见的需求就是为数据流补齐字段。因为数据采集端采集到的数据往往比较有限在做数据分析之前就要先将所需的维度信息补全。比如采集到的交易日志中只记录了商品 id但是在做业务时需要根据店铺维度或者行业纬度进行聚合这就需要先将交易日志与商品维表进行关联补全所需的维度信息。这里所说的维表与数据仓库中的概念类似是维度属性的集合比如商品维度、用户度、地点维度等等。 作为保存用户维度信息的数据存储需要应对实时计算场景下的海量低延时访问。根据这样的定位我们总结下对结构化大数据存储的几个关键需求 1. 高吞吐与低延时的读取能力 首当其冲在不考虑开源引擎 Flink 自身维表的优化外维表必须能承担实时计算场景下的海量上万 QPS的数据访问也能在极低毫秒级别的延时下返回查询数据。 2. 与计算引擎的高整合能力 在维表自身的能力之外出于性能、稳定性和成本的考虑计算引擎自身往往也会有些流量卸载的能力在一些情况下无需每次请求都需要去访问下游维表。例如Flink 在维表场景下支持 Async IO 和缓存策略等优化特性。一个比较好的维表需要和开源计算引擎有着较高程度的对接一方面可以提升计算层的性能一方面也可以有效的卸载部分流量保障维表不被过多访问击穿并降低维表的计算成本。 3. 轻存储下的计算能力的弹性 维表通常是一张共享表存储维度属性等元数据信息访问规模往往较大而存储规模往往不会特别大。对维表的访问规模极大地依赖实时数据流的数据量。比如如果实时流的数据规模扩大了数十倍此时对维表的访问次数会大大提升又比如如果新增了多个实时计算任务访问该维表该维表的查询压力会激增。在这些场景下存储规模往往不会显著增加。 所以计算最好是按需的是弹性的。无论是新增或者下线实时计算任务或者增加访问流量都不会影响访问性能。同时计算和存储是应该分离的不会单纯因为访问计算量的激增就增加存储成本。 2 架构选型 MySQL 大数据和实时计算技术起步之初互联网早期大量流行 LAMP Linux Apache MySQL PHP架构快速开发站点。因此由于业务历史数据已经存在 MySQL 中在最初的实时计算维表选型中大量使用 MySQL 作为维表。 随着大数据架构的更新MySQL 云上架构也在不断改进但在维表的应用场景下仍然存在以下问题 存储侧扩展灵活性差扩展成本较高MySQL 在存储侧的扩展需要进行数据复制迁移扩展周期长且灵活性差。同时 MySQL 的分库分表每次扩展需要双倍资源扩展成本较高。存储成本高关系数据库是结构化数据存储单位成本最高的存储系统所以对于大数据场景来说关系型数据库存储成本较高。 以上这些限制使 MySQL 在大数据维表场景下存在性能瓶颈成本也比较高。但总体来说MySQL 是非常优秀的数据库产品在数据规模不怎么大的场景下MySQL 绝对是个不错的选择。 Redis 在云上应用架构中由于 MySQL 难以承载不断增加的业务负载往往会使用 Redis 作为 MySQL 的查询结果集缓存帮助 MySQL 来抵御大部分的查询流量。 在这种架构中MySQL 作为主存储服务器Redis 作为辅助存储MySQL 到 Redis 的同步可以通过 binlog 实时同步或者 MySQL UDF 触发器的方式实现。在这种架构中Redis 可以用来缓存提高查询性能同时降低 MySQL 被击穿的风险。 由于在 Redis 中缓存了一份弱一致性的用户数据Redis 也常常用来作为实时计算的维表。相比于 MySQL 作为维表Redis 有着独特的优势 查询性能极高数据高速缓存在内存中可以通过高速 Key-Value 形式进行结果数据查询非常符合维表高性能查询的需求。存储层扩展灵活性高Redis 可以非常方便的扩展分片集群进行横向扩展支持数据多副本的持久化。 Redis 有其突出的优点但也有一个不可忽视的缺陷虽然 Redis 有着不错的扩展方案但由于高速缓存的数据存在内存中成本较高如果遇到业务数据的维度属性较大比如用户维度、商品维度时使用 Redis 作为维表存储时成本极高。 Tablestore Tablestore是阿里云自研的结构化大数据存储产品具体产品介绍可以参考官网以及权威指南。在大数据维表的场景下Tablestore 有着独特的优势 高吞吐访问Tablestore 采用了存储计算分离架构可以弹性扩展计算资源支持高吞吐下的数据查询。低延时查询Tablestore 按照 LSM 存储引擎实现支持 Block Cache 加速查询用户也通过配置丰富的索引优化业务查询。低成本存储和弹性计算成本在存储成本上Tablestore 属于结构化 NoSQL 存储类型数据存储成本比起关系型数据库或者高速缓存要低很多在计算成本上Tablestore 采用了存储计算架构可以按需弹性扩展计算资源。与 Flink 维表优化的高度对接Tablestore 支持 Flink 维表优化的所有策略包括 Async IO 和不同缓存策略。 方案对比 上面是前文提到的几个维表方案在各个维度的对比。接下来将举几个具体的场景细致对比下成本 1.高存储高计算维表需要存 100 亿条订单维度的数据总计存储量需要 1T尽管业务在 Flink 任务端配置了缓存策略但仍然有较高的 KV 查询下沉到维表到维表的 QPS 峰值 10 万均值 2.5 万。不同维表所需的配置要求和购买成本如下 2.低存储低计算维表需要存 100 万条地域维度的数据总计存储量需要 10M业务端在 Flink 任务中的维表配置了 LRU 缓存策略抵御了绝大部分的流量到维表的 QPS 峰值 1000 均值 250。不同维表所需的配置要求和购买成本如下 3.高存储低计算维表需要存 100 亿条订单维度的数据总计存储量需要 1T业务端在 Flink 任务中的维表配置了 LRU 缓存策略抵御了绝大部分的流量到维表的 QPS 峰值 1000 均值 250。不同维表所需的配置要求和购买成本如下 4.低存储高计算Redis 作为内存数据库具有超高频的数据 KV 查询能力仅 4 核 8G 内存的 Redis集群即可支持 16 万 QPS的并发访问成本预计 1600 元 / 月在低存储高计算场景有着鲜明的成本优势。 从上面的成本对比报告中可见 1MySQL 由于缺乏存储和计算的弹性以及关系型数据库固有的缺点在不同程度的存储和计算规模下成本均较高。 2Redis 作为内存数据库在低存储约 128G 以下高计算场景有着鲜明的成本优势但由于内存存储成本很高、缺乏弹性随着数据规模的提升成本呈指数增长。 3Tablestore 基于云原生架构可以按量对存储和计算进行弹性在数据存储和访问规模不大时成本较低。 4Tablestore 作为 NoSQL 数据库存储成本很低在高存储128G 以上场景下有着鲜明的成本优势。 四 实时计算结果表 1 需求分析 结果表作为实时计算完成后数据导入的存储系统主要可分为关系数据库、搜索引擎、结构化大数据离线存储、结构化大数据在线存储几种分类具体差异通过以下表格进行了归纳。 对于这几种数据产品在各自场景下各有优势起源的先后也各有不同。为了方便探究我们将问题域缩小仅仅考虑实时计算的场景下一个更好的结果表存储需要承担什么样的角色。 上文提到了实时计算的主要几个场景中实时数仓实时推荐实时监控三个场景需要考虑结果表的选型。我们一一分析。 实时数仓实时数仓主要应用在网站实时 PV / UV 统计、交易数据统计等实时分析场景。实时分析即OLAP场景分为预聚合、搜索引擎和 MPPMassively Parallel Processing即大规模并行处理三种 OLAP 模型。对于预聚合模型来说可以通过 Flink 计算层进行数据聚合写入结果表也可以全量写入结果表中通过结果表自身的预聚合能力进行数据存储在这种形态中极大地依赖结果表数据查询与分析能力的支撑。对于搜索引擎模型来说数据将全量写入结果表中通过搜索引擎的倒排索引和列存特性进行数据分析在这种形态中需要结果表有高吞吐的数据写入能力和大规模数据存储能力。MPP 模型是计算引擎如果访问的是列式存储可以更好地发挥分析查询特性。实时 OLAP 存储和计算引擎众多在一个完整的数据系统架构下需要有多个存储组件并存。并且根据对查询和分析能力的不同要求需要数据派生派生能力在必要时扩展到其他类型存储。另外实时数仓中随着业务规模的扩大存储量会大幅增长相较来说数据查询等计算规模变化一般不会特别明显所以结果表需要做到存储和计算成本分离极大地控制资源成本。实时推荐实时推荐主要是根据用户喜好进行个性化推荐在常见的用户商品个性化推荐场景下一种常见的做法是将用户的特征写入结构化大数据存储如 HBase 中而该存储将作为维表另一条用户点击消费行为数据进行关联提取出用户特征与行为关联输入作为推荐算法的输入。这里的存储既需要作为结果表提供高吞吐的数据写入能力也需要作为维表提供高吞吐低延时的数据在线查询能力。实时监控应用的实时监控常见于金融类或者是交易类业务场景该场景对时效性要求极高通过对异常数据检测可以实时发现异常情况而做出一个止损的行为。在这种场景下无论是通过阈值进行判断还是通过异常检测算法都需要实时低延时的数据聚合查询能力。 2 关键能力 通过以上的需求分析我们可以总结出几项实时大数据结果表的关键能力 1.大规模数据存储 结果表存储的定位是集中式的大规模存储作为在线数据库的汇总或者是实时计算或者是离线的输入和输出必须要能支撑 PB 级规模数据存储。 2.丰富的数据查询与聚合分析能力 结果表需要拥有丰富的数据查询与聚合分析能力需要为支撑高效在线查询做优化。常见的查询优化包括高速缓存、高并发低延迟的随机查询、复杂的任意字段条件组合查询以及数据检索。这些查询优化的技术手段就是缓存和索引其中索引的支持是多元化的面向不同的查询场景提供不同类型的索引。例如面向固定组合查询的基于 Btree 的二级索引面向地理位置查询的基于 R-tree 或 BKD-tree 的空间索引或者是面向多条件组合查询和全文检索的倒排索引。 3.高吞吐写入能力 实时计算的数据表需要能承受大数据计算引擎的海量结果数据集导出。所以必须能支撑高吞吐的数据写入通常会采用一个为写入而优化的存储引擎。 4.数据派生能力 一个完整的数据系统架构下需要有多个存储组件并存。并且根据对查询和分析能力的不同要求需要在数据派生体系下对存储进行动态扩展。所以对于大数据存储来说也需要有能扩展存储的派生能力来扩展数据处理能力。而判断一个存储组件是否具备更好的数据派生能力就看是否具备成熟的 CDC 技术。 5.云原生架构存储与计算成本分离 在云原生大数据架构中每一层架构都在往服务化的趋势演进存储服务化、计算服务化、元数据管理服务化等。每个组件都被要求拆分成不同的单元作为结果表也不例外需要具备独立扩展的能力更开放、更灵活、更弹性。 单就从结果表来说只有符合云原生架构的组件即基于存储计算分离架构实现的产品才能做到存储和计算成本的分离以及独立扩展。存储和计算分离的优势在大数据系统下会更加明显。举一个简单的例子结构化大数据存储的存储量会随着数据的积累越来越大但是数据写入量是相对平稳的。所以存储需要不断的扩大但是为了支撑数据写入或临时的数据分析而所需的计算资源则相对来说比较固定是按需的。 3 架构选型 MySQL 和维表一样大数据和实时计算技术起步之初MySQL 是一个万能存储几乎所有需求都可以通过 MySQL 来完成因此应用规模非常广结果表也不例外。随着数据规模的不断扩展和需求场景的日渐复杂MySQL 有点难以承载就结果表的场景下主要存在以下问题 大数据存储成本高这个在之前讨论维表时已经提到关系数据库单位存储成本非常高。单一存储系统提供的查询能力有限随着数据规模的扩大MySQL 读写性能的不足问题逐渐显现了出来。另外随着分析类 AP 需求的产生更适合 TP 场景的 MySQL 查询能力比较有限。高吞吐数据写入能力较差作为 TP 类的关系型数据库并不是特别擅长高吞吐的数据写入。扩展性差扩展成本较高这个在之前讨论维表时已经提到MySQL 在存储侧的扩展需要进行数据复制迁移且需要双倍资源因此扩展灵活性差成本也比较高。 以上这些限制使 MySQL 在大数据结果表场景下存在性能瓶颈成本也比较高但作为关系型数据库不是特别适合作为大数据的结果表使用。 HBase 由于关系型数据库的天然瓶颈基于 BigTable 概念的分布式 NoSQL 结构化数据库应运而生。目前开源界比较知名的结构化大数据存储是 Cassandra 和 HBaseCassandra 是 WideColumn 模型 NoSQL 类别下排名 Top-1 的产品在国外应用比较广泛。这篇文章中我们重点提下在国内应用更多的 HBase。 HBase 是基于 HDFS 的存储计算分离架构的 WideColumn 模型数据库拥有非常好的扩展性能支撑大规模数据存储它的优点为 大数据规模存储支持高吞吐写入基于 LSM 实现的存储引擎支持大规模数据存储并为写入优化设计能提供高吞吐的数据写入。存储计算分离架构底层基于 HDFS分离的架构可以按需对存存储和计算分别进行弹性扩展。开发者生态成熟与其他开源生态整合较好作为发展多年的开源产品在国内也有比较多的应用开发者社区很成熟与其他开源生态如 HadoopSpark 整合较好。 HBase有其突出的优点但也有几大不可忽视的缺陷 查询能力弱几乎不支持数据分析提供高效的单行随机查询以及范围扫描复杂的组合条件查询必须使用 Scan Filter 的方式稍不注意就是全表扫描效率极低。HBase 的 Phoenix 提供了二级索引来优化查询但和 MySQL 的二级索引一样只有符合最左匹配的查询条件才能做索引优化可被优化的查询条件非常有限。数据派生能力弱前面章节提到 CDC 技术是支撑数据派生体系的核心技术HBase 不具备 CDC 技术。非云原生 Serverless 服务模式成本高前面提到结构化大数据存储的关键需求之一是存储与计算的成本分离HBase 的成本取决于计算所需 CPU 核数成本以及磁盘的存储成本基于固定配比物理资源的部署模式下 CPU 和存储永远会有一个无法降低的最小比例关系。即随着存储空间的增大CPU 核数成本也会相应变大而不是按实际所需计算资源来计算成本。因此只有云原生的 Serverless 服务模式才要达到完全的存储与计算成本分离。运维复杂HBase 是标准的 Hadoop 组件最核心依赖是 Zookeeper 和 HDFS没有专业的运维团队几乎无法运维。 国内的高级玩家大多会基于 HBase 做二次开发基本都是在做各种方案来弥补 HBase 查询能力弱的问题根据自身业务查询特色研发自己的索引方案例如自研二级索引方案、对接 Solr 做全文索引或者是针对区分度小的数据集的 bitmap 索引方案等等。总的来说HBase 是一个优秀的开源产品有很多优秀的设计思路值得借鉴。 HBase Elasticsearch 为了解决 HBase 查询能力弱的问题国内很多公司通过 Elasticsearch 来加速数据检索按照 HBase Elasticsearch 的方案实现他们的架构。其中HBase 用于做大数据存储和历史冷数据查询Elasticsearch 用于数据检索其中由于 HBase 不具备 CDC 技术所以需要业务方应用层双写 HBase 和 Elasticsearch或者启动数据同步任务将 HBase 同步至 Elasticsearch。 这个方案能通过 Elasticsearch 极大地补足 HBase 查询能力弱的问题但由于 HBase 和 Elasticsearch 本身的一些能力不足会存在以下几个问题 开发成本高运维更加复杂客户要维护至少两套集群以及需要完成 HBase 到 Elasticsearch 的数据同步。如果要保证 HBase 和 Elasticsearch 的一致性需要通过前文提到的应用层多写的方式这不是解耦的架构扩展起来比较复杂。另外整体架构比较复杂涉及的模块和技术较多运维成本也很高。成本很高客户需要购买两套集群以及维护 HBase 和 Elasticsearch 的数据同步资源成本很高。仍没有数据派生能力这套架构中只是将数据分别写入 HBase 和 Elasticsearch 中而 HBase 和 Elasticsearch 均没有 CDC 技术仍然无法灵活的将数据派生到其他系统中。 Tablestore Tablestore 是阿里云自研的结构化大数据存储产品具体产品介绍可以参考官网以及权威指南。Tablestore 的设计理念很大程度上顾及了数据系统内对结构化大数据存储的需求并且基于派生数据体系这个设计理念专门设计和实现了一些特色的功能。简单概括下 Tablestore 的技术理念 大规模数据存储支持高吞吐写入LSM 和 B tree 是主流的两个存储引擎实现其中 Tablestore 基于 LSM 实现支持大规模数据存储专为高吞吐数据写入优化。通过多元化索引提供丰富的查询能力LSM 引擎特性决定了查询能力的短板需要索引来优化查询。而不同的查询场景需要不同类型的索引所以 Tablestore 提供多元化的索引来满足不同类型场景下的数据查询需求。支持 CDC 技术提供数据派生能力Tablestore 的 CDC 技术名为 Tunnel Service支持全量和增量的实时数据订阅并且能无缝对接 Flink 流计算引擎来实现表内数据的实时流计算。存储计算分离架构采用存储计算分离架构底层基于飞天盘古分布式文件系统这是实现存储计算成本分离的基础。云原生架构Serverless 产品形态免运维云原生架构的最关键因素是存储计算分离和 Serverless 服务化只有存储计算分离和 Serverless 服务才能实现一个统一管理、统一存储、弹性计算的云原生架构。由于是 Serverless 产品形态业务方无需部署和维护 Tablestore极大地降低用户的运维成本。 方案对比 举一个具体的场景结果表需要存千亿级别的电商订单交易数据总计存储量需要 1T用户需要对于这类数据进行查询与灵活的分析。日常订单查询与数据检索频率为 1000 次/秒数据分析约每分钟查询 10 次左右。 以下是不同架构达到要求所需的配置以及在阿里云上的购买成本 五 总结 本篇文章谈了云原生大数据架构下的实时计算维表和结果表场景下的架构设计与选型。其中阿里云 Tablestore 在这些场景下有一些特色功能希望能通过本篇文章对我们有一个更深刻的了解。后续我们会推出从零构建 Flink on Tablestore 系列文章并针对维表和结果表场景推出最佳实践文章。 原文链接 本文为阿里云原创内容未经允许不得转载。