作者：马超
“兵之道，运用之妙，存乎一心”。不久前PingCAP公司举办了线上发布会，正式发布了TiDB5.0版本。
现在数据库方面有两大流派，一个是非关系型（NoSQL）数据库，这是一种专门用来存储海量数据的Key-Value型数据库，主要用于用户画像、业务报表等海量数据的挖掘工作；另外一个是关系型（SQL）数据库，其针对个别记录增、删、改、查的速度很快，但很少做全表级别的大型关联计算，因此一般用于联机交易场景。简而言之，SQL处理速度快，NoSQL处理数据量级高。
之前SQL与NoSQL的应用场景两不重叠，井水不犯河水，但像直播带货这样的新场景不断涌现，由于在直播中的交易既要更新商家的库存和买家的帐户余额，又要根据客户行为进行实时分析、精确营销，类似这种综合SQL与NoSQL需求的业务场景不断涌现，使得混合负载HTAP数据库成为IT界所急需要解决的关键性技术，而这次的TiDB5.0打破了SQL与NoSQL两种场景之间的鸿沟。
如果用一句话概括本次TiDB5.0升级的精髓，笔者认为是“基于RAFTLog的行列混存，与MPP统筹的计算任务加速”。虽然看起来MPP、RAFT、行列存储等单独来看都平淡无奇，但把这些技术有机结合，就实属重剑无锋，大巧藏拙的设计了。
处理时效与灾备建设，数据库天空中的两朵乌云
权威咨询机构IDC对于大数据的定义是现有技术难以处理的数据。从历史来看，在谷歌提出大数据三驾马车的论文时，当时的关系型数据库技术就已处于难以处理大规模数据的状态。而在当下各行各业不断上云的大背景下，数据的量级必然还将不断创出新高，从笔者了解到的情况来看，整个IT行业存储的数据量级正在以年化80%左右的速度增长，传统SQL的数据库很难处理这样的数据量。
在TiDB5.0的发布会上，PingCAPCTO黄东旭分享了这样一段经历，他发现一个客户用TiDB跑一段大表关联的查询任务，效率非常低要半小时才能出结果，而这如果在TeraData的数据仓库平台上跑估计1秒钟就出结果了，他就问这个客户为什么要用TiDB跑这个任务，客户说如果把数据从TiDB上倒到数据仓库里需要半天，因此总体算下来，还是在TiDB上直接跑合算。其实这个例子也深刻说明了目前大数据技术栈所面临的窘境，各个数据库都是数据孤岛，打破孤岛之间的边界简直比登天还难。
以笔者所在的银行为例，目前一般在商业银行都使用Oracle数据库作为核心系统，但Oracle只能处理流程性的交易数据，不能做数据挖掘，要想把数据价值做二次表达，要每天做ETL、跑批作业、存到数据仓库中，然后在数据仓库中建模、挖掘、数据集市、ODS，一层一层地构建起数据仓库报表。
如果还回答不出非线性问题这样更细节更隐含的问题，就要把数据复制到SAS中做机器学习，再做统计的指标体系，以便做进一步的挖掘。数据要在这里搬动三次，复制三份冗余，还要管理数据一致性，每天数据中心运维的大量工作在做数据搬家。而数据在这种低效的转运迁移过程当中，很多价值也就白白耗散了，同时带来了处理时效和灾备建设这两个巨大的问题。
在处理时效问题上，正如我们前文所说，SQL与NoSQL两种产品底层构建模型并不相同，彼此兼容性不佳。这首先就会催生出数据处理的时效性问题，还是以笔者所在的银行为例，分析数据在交易核心数据库中跑批处理，再ODS抽取ETL分析到数仓，再进一步训练流式计算，最后再入湖，整个数据手动的过程至少需要一天。
而且Hadoop和数据湖的开源生态中很多组件并不兼容，日常运维已捉襟见肘，想提速也无从下手，但业务对于转瞬即逝的营销机会又如此渴求，T+1分钟可能都会嫌慢。对于处理时效的要求可能是大数据工程师与产品经理之间永远无法达成的协议。
灾备规划也经常被公司管理人员所忽略，大多数初创公司不会提前规划灾备体系。一般来说在两地三中心的灾备体系中，生产与同城中心是对称双活的，可以快速接管业务，异地中心一般是数据延迟同步，以应对一些删库、删表类的误操作。具体如下：
主中心：正常情况下全面提供业务服务；同城中心：一般与主中心处在同一省份，主中心使用同步复制的方式来向同城灾备中心传输数据，保证同城中心数据复本为最新，随时可以接管业务，以保证RTO的指标。但是同城中心无法应对此类删库事件；异地中心：一般使用延时异步复制（延时时间一般为30分钟左右）的方式向异地灾备中心传输数据，其中同步复制的好处是一旦主中心被人工破坏，那么不会立刻涉及异地中心，如此便可保证RPO的指标。总结来说，灾备体系的最佳实践就是两地三中心。同城保证业务连续性，优先负责用户体验;异地保证数据连续性，确保企业生存底线。上云后的灾备规划也一定要纳入设计范围，一旦没有提前的规划，后续的补齐填坑的工作非常麻烦。但正如前文所说SQL与NOSQL两套体系的组件兼容性很差，能让两者协同工作已属不易，再考虑灾备真是难上加难。
行列混存的打开方式
从上面的介绍想必大家也能看出来，目前各个数据中心都迫切的找到一个一栈式解决方案，屏蔽底层组件的差别，打造“AllDataInOne”的解决方案，只有如此才能提高效率，低成本运维。而TiDB5.0一个产品内弥合SQL与NoSQL的鸿沟，在这方面做出了相应探索。
数据访问是受局部性原理所支配的，现代硬盘、内存工作原理是当用户读某一区域的数据时，其邻接的数据也会被调入上一级高速缓存，读1k数据和连续的64M数据代价基本相同，用户在读取连续的磁盘或者内存信息时，其速度往往比随机读取快一个数量级。
因此行存储大多用在SQL的OLTP场景，而列存储基本用在NOSQL的OLAP场景。这背后的原因也很简单，还是以我们银行业的情况为例，联机交易的TP场景下比如当客户取款时，会校验我的用户、账号、密码、余额等等信息，这些信息都是以行为单位存储的，联机交易中数据是经常是以行为单位访问的。
但是在统计、分析营业报表，进行数据挖掘等AP场景下，往往只需要
转载请注明：http://www.0431gb208.com/sjslczl/3758.html
