各位小伙伴们大家好，我们又见面啦~
上一期的《你问我答》中
我们的专家解答了大伙对于腾讯大数据团队的开源项目，以及技术实践等方面的一些疑问
与此同时，我们在后台收到了更多的问题
所涉及的话题和专业领域也更加广泛
遗憾的是，由于篇幅限制
我们每期只能挑选5个问题进行答复
没有被选上的小伙伴也不要灰心
本栏目将继续进行下去
大家有任何关于ABCD（人工智能、大数据、云计算、数据库）领域的疑问
或者在工作中遇到了难以解决的相关技术问题
尽管在文章下方留言
您的问题越难，就越有可能得到专家的答复哦！
（当然，如何维护世界和平这种程度的难题除外）
小朋友，你是否有很多问号
有的话就请尽情向我们砸过来吧！
以下就是本期的精选回答了
快来看看有没有你感兴趣的问题吧！
01
@好，好，好好地：
现在市面上有不少的MQ产品，如RabbitMQ、RocketMQ、Kafka等等，TubeMQ在其中的定位是什么？
张国成
腾讯大数据TubeMQ项目负责人，Apache TubeMQ项目的PPMC成员。
回答
TubeMQ是基于服务端管控的以SAAS模式对外服务的高稳定、高性能、低延迟、低成本的分布式消息中间件。
相比于Kafka、RocketMQ、RabbitMQ、Pulsar等MQ，TubeMQ是基于大数据场景研发的拥有上万亿量级数据沉淀的分布式消息中间件，系统不需要上T大内存，不需要SSD盘存储就可以做到很高的性能指标；系统资源消耗上，我们基于数据尽可能不丢的运营思路，即使同样采用单副本存储模式，TubeMQ使用的资源也可以比其他的MQ低50%左右的机器资源；同时，系统基于SAAS而非PAAS实践思路设计，在系统管控上要比其他MQ更完善和可控；目前系统已走上了社区开放治理之路，TubeMQ会在继续深耕性能这块的能力，同时，通过社区力量完善TubeMQ的覆盖面，使其应用的场景更广泛。
如下是TubeMQ 0.3.0版本内部测试情况：
1、顺序消费时，在“1000个topic，每个Topic 2个存储实例，每个实例配置5个分区，每条消息1K字节，1份生产2份消费”前提下，单Broker可以达到如下指标：
机器配置 | 生产 | 消费 | 入流量 | 出流量 |
|---|---|---|---|---|
64G内存，2核共24个逻辑CPU | 166841/s | 167048/s | 1.78Gb/s | 3.21Gb/s |
256G内存，2核共96个逻辑CPU | 354233/s | 354728/s | 3.97Gb/s | 6.85Gb/s |
2、过滤消费时，在“2~3个topic，入流量维持1G，每个topic过滤生产3000个tid，每个tid 20个字节；1份正常消费，其余过滤消费，每份过滤消费组消费20个tid”前提下，单Broker可以达到的指标情况：
机器配置 | 过滤份数 | 生产 | 消费 | 入流量 | 出流量 |
|---|---|---|---|---|---|
64G内存，2核共24个逻辑CPU | 50份 | 103395/s | 141776/s | 1.078Gb/s | 1.37Gb/s |
256G内存，2核共96个逻辑CPU | 180份 | 85686/s | 194024/s | 1.04Gb/s | 1.9Gb/s |
02
@李猛GP ES：
Tbase跟Greenplum有啥对比吗？
谢灿扬
腾讯数据大数据TBase团队工程师。ACM Reginoal CCPC银奖获得者。主要负责腾讯云Postgresql RDS，TBase数据库研发。
回答
TBase是HTAP数据库，目前有两个版本，行存版本专注OLTP 轻量OLAP，列存专注OLAP性能 轻量OLTP。
GreenPlum是列存数据库，对标的是我们的列存版本。
TBase相比GreenPlum有延迟物化，JIT，向量计算等性能优化加持。并且支持同一个库中行存列存表混合，隔离OLTP负载与OLAP负载等技术。在易用性方面，相比GP的长时间的停机扩容，TBase能够做到高速且在线的扩容，对业务的影响降到最小。
在OLTP场景，TPCC测试集，Tbase优于GP，可以超过300万TPMTotal。
在OLAP场景，TPC-DS测试集，103个sql中，86%以上的sql均快于GP，甚至26%的sql上性能是GP的两倍以上。
我们TBase将会持续打磨性能，提高可靠性与易用性，打造一个更好，更快的数据库。
03
@{{username}}：
Oceanus为什么选择基于Flink搭建，而不是Storm？
施晓罡
腾讯大数据实时计算项目负责人。毕业于北京大学，获得博士学位。Apache Flink项目Committer。担任KDD，DASFAA等国际顶级会议的程序委员会委员。
回答
之前腾讯实时计算团队曾基于Apache Storm构建了早期的实时计算平台。但在长期的维护过程中，Apache Storm一些设计和实现上的缺陷逐渐暴露出来。Apache Flink出现之后，其在计算接口、计算性能和可靠性上的优异表现，让我们决定使用Apache Flink作为新一代实时计算平台的计算引擎。
相比于Storm和其他一些流计算框架，Flink具有以下几点优势：
更友好的编程接口。Storm提供的API偏底层且过于简单，用户需要大量的开发工作来完成业务需求。另外，用户在开发Storm程序时的学习成本也较高，需要熟悉框架原理和在分布式环境下的执行细节。Flink除了提供Table API和SQL这些高级的声明式编程语言之外，还对window这些流计算中常见的算子进行了封装，帮助用户处理流计算中数据乱序到达等问题，极大的降低了流计算应用的开发成本并减少了不必要的重复开发。
有效的状态管理支持。大部分的计算程序都是有状态的，即计算结果不仅仅决定于输入，还依赖于计算程序当前的状态。但Storm对程序状态的支持十分有限。一般情况下，用户常常需要将状态数据保存在MySQL和HBase这样的外部存储中，自己负责这些状态数据的访问。这些对外部存储的访问常常成为Storm程序的性能瓶颈。大多数情况下，用户只能设计复杂的本地cache来提升性能。Spark Streaming直到最近才提供了有限的状态管理支持，但受限于其实现机制，需要一定的远程访问和数据迁移工作，因此状态数据的访问效率并不高。Flink则对计算程序的状态存储提供了有效支持。用户可以通过提供的接口方便地存储和访问程序状态。由于这些状态数据存放在本地，因此用户可以得到较高的访问性能。在发生故障时，Flink的状态管理会配合容错机制进行状态数据的重建，保证用户程序的正确性。而当用户需要修改程序并发度时，Flink也可以自动地将状态数据分发到新的计算节点上。
Flink提供了丰富的容错语义。由于Storm缺少对程序状态的有效支持，其对容错的支持也较弱，很难保证在发生故障的情况下，每条输入数据恰好被处理一次。而Flink则依靠分布式系统中经典的Chandy-Lamport算法，能够对用户程序的输入和状态生成满足一致性的程序快照。在发生异常的情况下通过快照回滚，Flink可以保证EXACTLY-ONCE的容错语义。而利用异步checkpoint和增量checkpoint技术，Flink能够在以较低的成本对用户程序进行快照。在开启快照时，用户程序的性能几乎不受影响。
Flink拥有出色的执行性能。Flink基于事件触发的执行模式对数据流进行处理，相比于Spark Streaming采取mini batch的执行模式，能够大量减少程序执行时的调度开销。此外，Flink对网络层进行了大量优化，通过细粒度封锁和高效内存访问提高数据传输性能，并通过反压机制和流量控制有效降低流量拥塞导致的性能下降。加上Flink能够避免状态数据的远程访问，Flink在实践中表现出比其他流计算系统更出色的执行性能，具有更低的处理延迟和更高的吞吐能力。
04
@卓越：
Tbase具体应用在哪些领域？实际应用是什么？
谢灿扬
腾讯数据大数据TBase团队工程师。ACM Reginoal CCPC银奖获得者。主要负责腾讯云Postgresql RDS，TBase数据库研发。
回答
TBase目前的应用领域有金融，保险，税务，公安，政务等。
金融领域的应用有微信支付，当前已经超过200T 数据量，TBase支持全局ACID事务级别，满足金融行业对数据实时读写一致性要求，当前其他分布式数据库大多数只能做到节点级读写一致性；保险涉及核心车险、非车险、互联网保险、理赔等全链条业务系统，保险业务复杂，需要多表关联查询，tbase功能丰富，复杂SQL运算性能更好，目前运行实例超过200 ；公安涉及业务人口库业务、人口轨迹大数据等业务系统，目前应用规模超过300 节点。
政务系统也是Tbase落地项目最多的领域之一，Tbase三权分立为政务民生提供强有力的保驾护航能力，著名“粤省事”是我国首个集成民生服务微信小程序，数据存储服务就是TBase，在2020新型冠状病毒肺炎疫情期间，Tbase也承担了多地疫情小程序建设和疫情大数据分析工作。
小编注：所谓的“三权分立”，是指把数据库DBA分解为三个相互独立的角色：安全管理员，审计管理员，数据管理员。安全管理员专门用来制定安全/权限规则，审计管理员就是对数据库的操作动态做一个追踪，数据管理员就是对数据库运维的角色。这个三个角色之间相互制约，消除出系统中的上帝权限。从系统角色设计上了解决了数据安全问题。
05
@答案：
数据湖相对于数仓，能帮助企业解决什么类型的痛点问题？
邵赛赛
腾讯大数据数据湖团队负责人，Apache Member, Apache Spark项目的PMC成员和committer，Apache Livy项目的PPMC成员。
回答
人们对于数据的探索和数据价值挖掘是无止境的。当数据规模较小时，数据库就可以满足业务的需求，数据库的核心是满足快速的增删改查，应对联机事务。但是随着库里的数据越来越多，不光要支持联机业务，还需要分析其价值。这个时候传统数据库虽然可以满足频繁、快速读写需求，但是不适合读取大量数据的分析业务。因此数仓就应运而生。
数仓的关键环节是“ETL”，抽取（Extract），转换（Transform）和Load（加载），通过这些步骤将数据加载到数仓中。这个“仓库”的核心功能是为了数据分析用途，如BI，报表、经营分析等等。
数据库和数仓虽然应用场景不同，但是它们都是结构化数据。在相当长一段时间里，它们联合起来，共同满足企业的实时“交易”型业务和联机“分析”型业务需求。但是随着数据分析的发展，数据的类型越来越多（结构化、半结构化、非结构化），对于数据分析的需求（OLAP、ML、DL，BI）也越来越复杂。这时候，就需要挖个大坑，把数据都“填”到坑里去，这就是数据湖。
恭喜以上5位小伙伴
你们将获得“腾讯视频VIP月卡”一张
请在后台私信小编
小编会将礼物发给你们~
以上就是《你问我答》第二期的全部内容了
欢迎大家就自己关心的技术问题
在文章下方以“#你问我答# 提问内容”的形式留言
专家和小编在这里静候你的提问喔！
