【ITPUB名人堂访谈】大型金融机构数据架构师刘盛带你体验大数据的冰与火

arron刘 · 发表于 2013-8-23 15:43

大家好，ITPUB名人堂又和大家见面啦！今天我们邀请的是Hadoop与分布式数据处理版版主、ACOUG核心成员、Oracle~OCM——刘盛 ID:Leonarding，他现任某央企大型金融机构数据架构师，负责金融项目基础架构与建模具有丰富Oracle运维管理经验和项目实施经验，擅长大型数据库架构设计与建模、性能调优、故障诊断及高可用实现。目前专注于数据库整体自动运维管理，基于大数据解决方案。曾获2012年度ITPUB最佳技术原创精华奖，技术博客blog: www.leonarding.com 新浪微博:@itpub_leonarding

arron刘：
您先自我介绍一下? 分享一下您的职业经历? 您目前从事的工作?
Leonarding:
大家好，我是刘盛，网名ID是leonarding，现在是ITPUB Hadoop与分布式数据处理版版主 ACOUG核心成员我的blog：www.leonarding.com
大家在圈里习惯叫我“盛哥”，在此非常感谢大家对我的爱护与支持。我的职业经历到目前为止主要有三个阶段，大学实习去了中软融鑫做技术支持属于实习生，说白了就是天天跟着项目经理满城跑（革命一块砖，哪里需要哪里搬）在实习的过程中我才真正接触到Oracle，之前在学校根本没有接触过。毕业之后直接去了天津联通负责“分组网信令检测系统”的项目管理与跟进，当时这个系统是属于大数据级别的（大约20T）由于当时部门没有专职DBA而公司又确实需要这方面的人才，让我萌生了转职DBA的想法，后来顺理成章的考取了OCP->OCM，这才真正的干起了DBA的工作。我目前就职于某央企大型金融机构，从事数据架构工作，负责金融项目基础架构、建模、设备选型、技术解决方案，同时也做一些运维和培训的工作。

arron刘：
ORACLE最近发布了12C版本，相信您已经尝鲜试用过了吧，能不能分享一下12C的新特性，谈谈12C给我们带来了哪些不一样？
Leonarding:
Oracle Open World上个月在上海举办，我相信很多朋友都去参加了这个盛会，其中最大亮点就是Oracle发布了最新版12C，相信广大Oracle DBA都会心动不已，我也跟风的beta了一下，下面说说12C带给我们哪些新特性
（1）在线重命名和重新定位活跃数据文件
这个新特性给迁移数据带来了革命性的方便，甚至可以支持跨存储设备的迁移，例如从非ASM迁移至ASM，反之亦然。可以使用ALTER DATABASE MOVE DATAFILE语句对数据文件进行在线重命名和迁移。
（2）12C支持在同一列上创建多个索引
12C允许在同一列上创建不同类型的索引，有人可能不明白这样做的目的，事实上多重索引的字段在做性能优化时非常的方便，例如一个字段上即可以创建B-tree也可以创建Bitmap索引，但同一时间只有一种索引可用。
多重索引包括：B-tree，Bitmap，Local，Global
（3）RMAN中执行SQL语句
12C中可以在RMAN里直接执行任何SQL和PL/SQL语句，包括DML、DDL、查询v$动态性能视图，数据字典等
（4）RMAN支持表级恢复
这是初级DBA的福音，在12C之前如果要想恢复表只能使用逻辑备份，由于刚入门DBA对Oracle逻辑与物理体系结构缺乏深入了解，在恢复数据的时候往往希望只恢复被损坏的表，这种需求在生产环境中是常常需要的，12C可以支持直接从物理备份中来恢复损坏的表。

arron刘：
现在云计算和大数据是时代的宠儿，ORACLE也不能置身世外Oracle 12c这个C是不是代表着云计算呢？新的数据库版本在云计算中有哪些应用呢？
Leonarding:
云计算是当今社会出镜率较高的词语，Oracle作为世界级大佬当然也不甘落后，看这次的12C就剑指云计算。
Oracle CEO拉里•埃里森童靴在2012年就发布了与云息息相关的四项产品与服务
（1）Oracle IaaS（基础设施服务）
（2）Oracle 私有云
（3）升级版Exadata数据云服务器X3
（4）云数据库Oracle 12c。
而在新版本数据库中最核心的技术创新"多租户架构（Multitenant Architecture)"，正是Oracle为云计算做出的重要变革。它是通过一个插拔式数据库（Pluggable Database）的功能实现的。
这次Oracle推出新版本的同时又给了我们一个信号。Oracle数据库产品，将整合到微软的两个产品中：虚拟机产品ServerHyper-V和云计算WindowsAzure。这意味着客户将来无需购买Oracle数据库，就可以在微软云平台上在线租用。
目前可以看出甲骨文云合作将覆盖云计算的全部层面包括基础设施、平台、应用。

arron刘：
根据您多年的Oracle管理经验，在Oracle数据库性能优化方面您有什么建议和经验？
Leonarding:
从我接触Oracle到现在，我感受最深的就是数据量极度膨胀，随着项目的建设，新项目总是比老项目功能多，采集的数据量大，数据类型多样化，数据聚合操作复杂化。例如我们的金融项目，当用户填入一个指标数据后，后台自动把相关联的指标数据计算出来并反填在输入框中，防止手工计算导致数据报送错误。在这种海量数据并伴随着复杂计算的环境下，单台数据库的优化已经捉襟见肘了，这时候如果你还在研究数据块的内部结构、存储格式、优化器的代价计算、变量窥视等技术，那么可能对系统性能的提升起不了多大的帮助。就算你的SQL写的再完美在大数据量的冲击下也会变成屌丝一枚。现在的你应该把眼界提升到系统架构层面来看待，当单台数据库无力支撑起访问压力时，你该从架构的角度集群的角度来解决遇到的难题。
如图所示

生产数据库为总中心，备用数据库为各个分中心，生产库只负责写入数据，备用库只负责读取数据，这样就实现了业务层面的读写分离，把访问压力减小5倍，从而用集群的方式解决了高压力访问问题。
在这里我只是给大家一个海量数据下的优化思路，这个思路的核心思想就是从架构层面考虑遇到的问题，这也体现了老话“不畏浮云遮望眼，自缘身在最高层”。

arron刘：
做为一名优秀的DBA，能不能谈谈系统升级所带来的思考，聊聊您在工作中解决问题的思路？
Leonarding:
（1）系统升级之思考
使用成熟稳定的软件产品。一个刚刚推出的新产品在没有完善测试的情况下不应急于用在生产环境，冒进在生产系统上使用新版本未必是一件好事。
升级前在测试环境下进行稳定性安全性性能压力等各种变态测试，因为用户行为总会有突发奇想，而你要做的就是比用户想的更多，但也不能代表所有用户的想法。
   如果使用开源产品请先做好bug方案，以便遇到问题能够快速解决，稳定运维团队，不要人走了系统也就没人管了或者不能平滑交接。
   灾备演练不可少。常规方案中灾备很常见，对于不差钱需要7*24小时提供服务的企业来讲，就更需要实事求是地落实、保质保量地进行灾备演练而不是走过场，要保证在任何时候任何环境下都有足够的人力物力财力去支持。

（2）解决问题之思路
   一寸光阴一寸金，寸金难买寸光阴，在系统遇到问题需要解决的时候遇到的往往不是技术上的瓶颈而是流程上的瓶颈，所谓流程，就是遇到问题，需要一层一层上报（关键还不能越级）等报到能够拍板的人时，甚至可能会遭遇领导在开会、领导在出差、领导在午休、领导在宴请、领导在陪领导、领导在XXX系列事件，这也是在大型企业中常常遇到的执行力拖延症。制定可行性的应急方案，让专业的人做专业的事并把权限下放，在短时间内可以有人来接手是解决此类问题的关键。
广大技术工作者从事的领域各有不同，但是通常都有这样一个共性：不善言辞，遇到问题就自己闷头解决，生怕他人认为自己能力不足。对于这一点，我在这里还是想说要相信团队的力量，要常常和大家一起交流方案，遇到问题要与团队一起想办法解决，因为一个人通常不能想的非常全面，有可能问题影响的层面不单单是数据库，还可能会影响到应用，这时你就要拉着你的小伙伴们一起攻坚完美的完成任务。

arron刘：
现在数据库技术更新换代的速度越来越快了，您觉得从业者该怎么选择自己的学习方向？比如说应该学习什么数据库之类的问题。
Leonarding:
这个问题问的很好，现在互联网的飞速发展带来了大数据时代，各行各业都呈现出信息井喷的状态，每天每时每刻我们的电脑、手机、ipad、移动PDA都会收到各种各样信息了解着世界每个地方发生的人和事。在这个时代下解决大数据问题是企业面临的新课题，从而催生出了各种数据库技术。我们作为从业者更能亲身感受到数据库技术正在以迅雷不及掩耳之势进入战国时代，现在主流的两大阵营主要是“关系型”VS“非关系”。我觉的当下DBA已经不能仅仅停留在研究Oracle、Mysql、DB2等关系型数据库上，在一些“高访问负载”“实时数据分析”“非结构化数据”“分布式存储”场景下非关系型数据库有着得天独厚的优势，因此我从去年就开始关注“Hadoop”“MongoDB”“Cassandra”“Neo4j”等NOSQL数据库。因为我发现当下企业需求的解决方案呈多样化的趋势，企业慢慢意识到资源整合的重要性，因此在技术选型方面都倾向于具有小成本、轻量级、高效化、易维护特点的产品，说白了就是用最专业的产品做最专业的事。如果你掌握更多的知识和技能，那么在系统规划、架构设计、设备选型等方面就会得心应手。领导也会让你参与更多的项目来发挥你的特长，自然你的发展空间也会“特长”。

arron刘：
感谢刘盛的精彩分享，谢谢他给我们带来大数据时代如何选择自己的方向和解决问题的思路，同时也期盼着大师的处女作早日完成，最后欢迎大家积极回帖讨论，交流自己的心得。