白癜风检查到中科 https://mjbk.familydoctor.com.cn/bjbdfyy/白癜风检查到中科 https://mjbk.familydoctor.com.cn/bjbdfyy/9月10日晚,七牛云主办的「云加数据,智驱未来」数据科学系列论坛如期举行。在直播中,PingCAP联合创始人兼CTO黄东旭为我们带来了主题为《TiDB在实时数据分析中的最佳实践》的精彩分享。以下内容根据演讲整理。MySQL作为单机数据库,当数据量增加时必然涉及到分库分表等操作去换取水平扩展能力,这时候的复杂度将会呈现几何倍的上升。TiDB五年前的初心是想设计一个替换MySQL分库分表的方案,因此TiDB最早的目的是想做一个既能够像单机数据库一样使用,同时又拥有水平扩展能力的OLTP分布式数据库。但是,当用户使用TiDB存储数据量越来越多后,有一个新类型的需求冒出来:用户会想我能不能直接在TiDB去做一些离线,甚至是准在线的数据分析,而不是把数据转移到Hadoop上。我认为有很大一部分比例OLAP的需求不用做很重的ETL,比如电商用户,就想看一下现在卖出去多少东西,或者算一下今天赚了多少钱这种报表。但是过去的TransactionDatabase并不是为了这种比较复杂的分析而设计的。所以这两年有一个新概念叫HTAP,尽可能模糊了OLTP与OLAP的概念。过去因为技术、数据结构、硬件、网络等条件都不成熟,因此这两套设计水火不容,所以在技术上强行划分出了OLTP和OLAP。我认为在未来这些技术细节或者底层差异会越来越模糊,包括Gartner在一个报告中也提到,未来只会有一种Database。所以在HTAP的新概念之下会有很多更新的Workload诞生出来。HTAP的技术演进过程在HTAP之前,互联网公司是按照下图所示的一个传统架构去做在线业务和离线业务。在业务侧,OLTP的数据可能有很多MySQL或者分库分表,这些通过Binlog打到Kafka作为消息队列,传送到一个近实时的系统。比如用HBase去做一些数据的归拢,然后再把这个数据在Hadoop上用hive或者Spark这样的技术去做大数据分析和ETL,或者再去把ETL产生的数据回写到另外的一些MySQL,或者在另外的一些在线数据库上对外提供服务。这是一个传统的大数据处理架构,但这种架构的一个问题就是:在线和离线的业务是分得很开的,中间都要通过ETL的过程和数据的传输层来去串联整个系统。这就为什么有很多公司只能看到前一天的数据,因为可能要一批一批地去加载。所以我认为HTAP这个技术的方向对于用户来说,就像智能手机对于传统手机一样,有了智能手机我就不再需要GPS、单反相机、移动电话,一个iPhone就够了,极大地降低了业务和架构的复杂度。另外,原来可能要维护很多套系统、很多个团队,如果HTAP真的存在了,对于绝大多数业务而言只需要维护一套系统。从领导者的角度来说,运维成本和团队人员成本都会降低。最后一点,我认为对于业务而言意义更大。从前我们很多决策依托的是老数据,但现在可以考虑依托实时数据。比如在一个线下商店,只要用户进入商店,就能通过人脸识别或者会员卡马上知道他接下来会想要去消费什么东西,对什么东西感兴趣,从而快速做出决策。这种情况下,如果系统不是实时的就没有意义,可能用户看一看就流失了。所以在这些基础之上叠加起来,可以对整个业务的迭代和敏捷程度有一个很大的提升。我认为HTAP是一种新的数据库物种,它不是传统OLTP和OLAP的改良。仍然以电商为例,如上图所示:左边是偏交易的,右边是偏分析的。我们把电商平台内部系统切分成订单管理、账单的历史明细、推荐、联合仓储实时查询库存、实时大屏、促销调价、历史报表。线上最左端是订单管理,包括在线交易的部分,所以从最左端是靠近OLTP的,最右端是靠近OLAP的。我们可以发现,像销售历史报表这种是纯离线场景,及时性要求不强的,我可以明天或者下个月看到这个月的报表都不受影响。但是,实时的促销调价、实时大屏、仓储查询都是偏实时的,需要根据线上订单情况、用户访问情况、实时交易情况以及其他渠道的推广情况实时去做计算。这些场景里,过去要实现一个这种系统需要用到Flink、Sparkstreaming、Kafka等技术以及很多实时数据同步工具才能实现。这是一个很复杂的问题,会面临很多技术挑战:第一个挑战是OLTP数据库的水平扩展性,对于OLTP数据库来说,拓展方案上只能用分库分表或者在业务层面做切分。第二个挑战是OLTP系统需要同时兼具OLAP的能力,且同时支持行存列存。一般的OLTP系统都是用行存去作为底层的存储模型,而OLAP是使用列存,在查询的效率大概差了上百倍,业务人员很难放心的在一个OLTP系统上去跑复杂查询,背后是有一些风险的。因此不仅需要打消用户的担心,而且还需要在去跑OLAP端的时候能跑得快,必须得支持列存。第三个挑战是需要两者有机统一而仅仅是两套分离的系统。如果分离就会面临互联互通的问题,比如在OLTP里边的数据怎么同步到OLAP系统里,同步的时延大概是多少,这些都是技术挑战。TiDB4.0:一个真正的HTAP系统TiDB最新的版本是4.0。在我心中TiDB4.0之前和TiDB4.0之后是两个完全不一样的产品。4.0之前它是一个交易型数据库,是MySQL分库分表的很好替换,能支持海量数据的MySQL协议的在线业务,但它并不是一个好的数据仓库,也不是一个好的实时分析的产品,因为它是一个行存的数据库,虽然用起来很方便。而TiDB4.0可以说是一个真正的HTAP系统:首先TiDB4.0引入了列存的存储引擎,说明在与其它AP系统相比时,本质上是没有劣势的。第二,TiDB4.0里,计算引擎是根据列存来做向量化的,相当于利用一些CPU批量计算的指令集,去在比较紧凑的数据结构格式上去做很高性能计算的一种技术,这是在OLAP数据库里面经常使用的一个技术。还有一点,在传统的OLAP数据库里面几乎没法做的一个事情就是:有一些数据是在行存里是更好的,比如一个随机的带索引的点查,要去大海捞针式的查询,可能是在OLTP端是很好的,就可以直接找到数据。而列存是比较适合比如说我一张大表全部要扫描一遍,批量的扫描、批量的聚合。在TiDB4.0里面,我们用了一些技术可以把这两种不同的存储领域的优势合并在一起,我们最近有一篇关于HTAP的论文入选VLDB,大家有兴趣可以仔细看看。简单来说,整个TiDB的存储和计算是完全分开的。如果大家熟悉HBase就会知道它里面有region,每一块数据是一块小分片,在TiDB里每一个region其实是一个Raft的复制小组。相当于我们对每一小块数据的Raft复制小组里面引入了一块列存的副本,由于计算层跟存储层是分开的,所以我们的计算层可以根据SQL来确定请求,OLAP的请求就发到OLAP的副本上,OLTP的请求就发到OLTP的副本上。因为底层数据的同步,一直是通过Raft化整为零的同步。第二就是说在workload上,你的OLTP业务永远是在TiKV这种节点上去执行,OLAP业务其实是在TiFlash的节点上执行,在原理上它是完全分开的,就硬件软件是分开的,你就不用担心说在这边跑一个复杂查询会不会阻塞这边,而且数据的同步是完全实时的。所以底层的核心要点在于本身TiKV这边提供了一个很好的数据弹性伸缩机制,我们叫Multi-Raft。实际上把我们所有的data拆成了无数个Raft的复制小组,我只需要清楚怎么去支撑支持这种异构的数据源,只需要给我的Raft的小组里边多一份异构的数据副本,这就很漂亮的嵌入到了原来的Multi-Raft的体系里。而且在这一点上,它与其他的基于Binlog、Kafka的数据同步相比,有一个天然的优势,就是不需要其他的Kafka。想象一下,如果我是两套不同的系统,左边是MySQL,右边是Hadoop,中间通过Kafka去同步,如果左右两边的数据吞吐量都特别大,Kafka变成数据同步的过程,就会变成你的瓶颈。所以在这一点上,TiDB复制模式的漂亮之处在于它的数据同步的拓展是随着数据本身的拓展是一起的,相当于把整个数据的同步过程化整为零,拆到了每一块数据分片里面。在前述HTAP场景下,简单就是说一句SQL开启一个表的列传模式,后OLTP业务完全不用做任何修改,但同时又能直接能在数据库上做OLAP的分析,这样整体的架构的复杂度,运维的成本,业务的实质性与业务的敏捷性就有很大的提升。所以从传统的交易分析的架构简化成为一个大的中央的thesourceoftruth的架构,同时提供APP的server以及这种事实分析的商业智能的服务。同时,你也可以去结合现有数仓把TiDB作为一个数据的中间层,当然我并不是说他一定会去替换掉原来的这种Hadoop,或者说这种database的这种模型。因为确实有一些非实时的查询,避免不了ETL,但是可以使用TiDB架在Hadoop之上提升整个数据扭转的一个实时性。TiDB是整体架构中的实时层的很好补充,这就是我今天的一个分享,谢谢大家。数据科学系列论坛第二期预告10月20日,七牛云主办的「云加数据,智驱未来」数据科学系列论坛第二期将邀请七牛云数据科学家周暐、支流科技CEO温铭、eBaySpark
转载请注明：http://www.aierlanlan.com/rzdk/5989.html
