大数据正在如何改变数据库格局
提及“数据库”,大多数人会想到拥有30多年风光历史的RDBMS。然而,这可能很快就会发生改变。
一大批新的竞争者都在争夺这一块重要市场,他们的方法是多种多样的,却都有一个共同点:极其专注于大数据。推动新的数据迭代衍生品大部分都是基于底层大数据的3V特征:数量,速度和种类。本质上来讲,今天的数据比以往任何时候都要传输更快,体积更大,同时更加多样化。这是一个新的数据世界,换言之,传统的关系数据库管理系统并没有真正为此而设计。“基本上,他们不能扩展到大量,或快速,或不同种类的数据。”一位数据分析、数据科学咨询机构的总裁格雷戈里认为。这就是哈特汉克斯最近发现。截至到2013年左右,营销服务机构使用不同的数据库,包括MicrosoftSQLServer和Oracle真正应用集群(RAC)的组合。“我们注意到,数据随着时间的增长,我们的系统不能足够快速的处理信息”一位科技发展公司的负责人肖恩说到。“如果你不断地购买服务器,你只能继续走到这幺远,我们希望确保自己有向外扩展的平台。”最小化中断是一个重要的目标,Iannuzzi说到,因逗首此“我们不能只是切换到Hadoop。”相反,却选择了拼接机器,基本上把完整的SQL数据库放到目前流行的Hadoop大数据平台之上,并允许现有的应用程序能够与它连接,他认为。哈特汉克斯现在是在执行的初期阶段,但它已经看到了好处,Iannuzzi说,包括提高容错性,高可用性,冗余性,稳定性和“性能全面提升”。一种完美风暴推动了新的数据库技术的出现,IDC公司研究副总裁CarlOlofson说到。首先,“我们正在使用的设备与过去对比,处理大数据集更加快速,灵活性更强”Olofson说。在过去,这样的集合“几乎必须放在旋转磁盘上”,而且数据必须以特定的方式来结构化,他解释说。现在有64位寻址,使得能够设置更大的存储空间以及更快的网络,并能够串联多台计算器充当单个大型数据库。“这些东西在不可用之前开辟了可能性”Olofson说。与此同时,工作负载也发生了变化。10年前的网站主要是静态的,例如,今天我们享受到的网络服务环境和互动式购物体验。反过来,需要新的可扩展性,他说。公司正在利用新的方式来使用数据。虽然传统上我们大部分的精力都放在了对事务处理_销售总额的记录,比如,数据存储在可以用来分析的地方_现在我们做的更多。应用状态管理就是一个例子假设你正在玩一个网络游戏。该技术会记录你与系统的每个会话并连接在一起,以呈现出连续的体验,即使你切换设备或各种移动,不同的服务器都会进行处理,Olofson解释说。数据必须保持连续性,这样企业才可以分析问题,例如“为什么从来没有人穿过水晶厅”。在网络购物方面,为什么对方点击配坦选择颜色后大多数人不会购买某个特殊品牌的鞋子。“以前,我们并没试图解决这些问题,或者我们试图扔进盒子也不太合适”Olofson说。Hadoop是当今新的竞争者中一个重量级的产品。虽然他本身不是一个数据库,它的成长为企业解决大数据扮演关键角色。从本质上讲,Hadoop是一个运行高度并行应用程序的数据中心平台,它有很强的可扩展性。通过允许企业扩展“走出去”的分布方式,而不是通过额外昂贵的服务器“向上”扩展,“它使得我们可以低成本地把一个大的数据集汇总,然后进行分析研究成果”Olofson说。其他新的RDBMS的替代品如NoSQL家族产品,其中包括MongoDB-目前第四大流行数据库管理系统,比照DB引擎山卖数和MarkLogic非结构化数据存储服务。“关系型数据库一直是一项伟大的技术持续了30年,但它是建立在不同的时代有不同的技术限制和不同的市场需求,”MarkLogic的执行副总裁乔·产品帕卡说。大数据是不均匀的,他说。许多传统的技术,这仍然是一个基本要求。“想象一下,你的笔记本电脑上唯一的程序是Excel”帕卡说。“设想一下,你要和你的朋友利用网络保持联系_或者你正在写一个合约却不适合放进行和列中。”拼接数据集是特别棘手的“关系型,你把所有这些数据集中在一起前,必须先决定如何去组织所有的列,”他补充说。“我们可以采取任何形式或结构,并立即开始使用它。”NoSQL数据库没有使用关系数据模型,并且它们通常不具有SQL接口。尽管许多的NoSQL存储折中支持速度等其他因素,MarkLogic为企业定身量做,提供更为周全的选择。NoSQL储存市场有相当大的增长,据市场研究媒体,不是每个人都认为这是正确的做法-至少,不是在所有情况下。NoSQL系统“解决了许多问题,他们横向扩展架构,但他们却抛出了SQL,”一位CEO-MonteZweben说。这反过来,又为现有的代码构成问题。SpliceMachine是一家基于Hadoop的实时大数据技术公司,支持SQL事务处理,并针对OLAP和OLAP应用进行实时优化处理。它被称为替代NewSQL的一个例子,另一类预期会在未来几年强劲增长。“我们的理念是保持SQL,但横向扩展架构”Zweben说。“这是新事物,但我们正在努力试图使它让人们不必重写自己的东西。”深度信息科学选择并坚持使用SQL,但需要另一种方法。公司的DeepSQL数据库使用相同的应用程序编程接口(API)和关系模型如MySQL,意味着没有应用变化的需求而使用它。但它以不同的方式处理数据,使用机器学习。DeepSQL可以自动适应使用任何工作负载组合的物理,虚拟或云主机,该公司表示,从而省去了手动优化数据库的需要。该公司的首席战略官ChadJones表示,在业绩大幅增加的同时,也有能力将“规模化”为上千亿的行。一种来自Algebraix数据完全不同的方式,表示已经开发了数据的第一个真正的数学化基础。而计算器硬件需在数学建模前建成,这不是在软件的情况下,Algebraix首席执行官查尔斯银说。“软件,尤其是数据,从未建立在数学的基础上”他说,“软件在很大程度上是语言学的问题。”经过五年的研发,Algebraix创造了所谓的“数据的代数”集合论,“数据的通用语言”Silver说。“大数据肮脏的小秘密是数据仍然放在不与其他数据小仓融合的地方”Silver解释说。“我们已经证明,它都可以用数学方法来表示所有的集成。”配备一个基础的平台,Algebraix现在为企业提供业务分析作为一种服务。改进的性能,容量和速度都符合预期的承诺。时间会告诉我们哪些新的竞争者取得成功,哪些没有,但在此期间,长期的领导者如Oracle不会完全停滞不前。“软件是一个非常时尚行业”安德鲁·门德尔松,甲骨文执行副总裁数据库服务器技术说。“事情经常去从流行到不受欢迎,回再次到流行。”今天的许多创业公司“带回炒冷饭少许抛光或旋转就可以了”他说。“这是一个新一代孩子走出学校和重塑的东西。”SQL是“唯一的语言,可以让业务分析师提出问题并得到答案,他们没有程序员,”门德尔松说。“大市场将始终是关系型。”至于新的数据类型,关系型数据库产品早在上世纪90年代发展为支持非结构化数据,他说。在2013年,甲骨文的同名数据库版本12C增加了支持jsON(javaScript对象符号)。与其说需要一个不同类型的数据库,它更是一种商业模式的转变,门德尔松说。“云,若是每个人都去,这将破坏这些小家伙”他说。“大家都在云上了,所以在这里有没有地方来放这些小家伙?“他们会去亚马逊的云与亚马逊竞争?”他补充说。“这将是困难的。”甲骨文有“最广泛的云服务”门德尔松说。“在现在的位置,我们感觉良好。”Gartner公司的研究主任里克·格林沃尔德,倾向于采取了类似的观点。“对比传统强大的RDBMS,新的替代品并非功能齐全”格林沃尔德说。“一些使用案例可以与新的竞争者来解决,但不是全部,并非一种技术”。展望未来,格林沃尔德预计,传统的RDBMS供货商感到价格压力越来越大,并为他们的产品增加新的功能。“有些人会自由地带来新的竞争者进入管理自己的整个数据生态系统”他说。至于新的产品,有几个会生存下来,他预测“许多人将被收购或资金耗尽”。今天的新技术并不代表传统的RDBMS的结束,“正在迅速发展自己”IDC的Olofson。赞成这种说法,“RDBMS是需要明确定义的数据_总是会有这样一个角色。”但也会有一些新的竞争者的角色,他说,特别是物联网技术和新兴技术如非易失性内存芯片模块(NVDIMM)占据上风。Ⅱ SQLSERVER大数据库解决方案
在微软的大数据解决方案中,数据管理是最底层和最基础的一环。
灵活的数据管理层,可以支持所有数据类型,包括结构化、半结构化和非结构化的静态或动态数据。
在数据管理层中主要包括三款产品:SQLServer、SQLServer并行数据仓库和
Hadoop on Windows。
针对不同的数据类型,微软提供了不同的解决方案。
具体来说,针对结构化数据可以使用SQLServer和SQLServer并行数据仓库处理。
非结构化数据可以使用Windows Azure和WindowsServer上基于Hadoop的发行版本处理;而流数据可以使用SQLServerStreamInsight管理,并提供接近实时的分析。
1、SQLServer。去年发布的SQLServer2012针对大数据做了很多改进,其中最重要的就是全面支持Hadoop,这也是SQLServer2012与SQLServer2008最重要的区别之一。今年年底即将正式发布的SQLServer2014中,SQLServer进一步针对大数据加入内存数据库功能,从硬件角度加速数据的处理,也被看为是针对大数据的改进。
2、SQLServer并行数据仓库。并行数据仓库(Parallel Data Warehouse Appliance,简称PDW)是在SQLServer2008 R2中推出的新产品,目前已经成为微软主要的数据仓库产品,并将于今年发布基于SQLServer2012的新款并行数据仓库一体机。SQLServer并行数据仓库采取的是大规模并行处理(MPP)架构,与传统的单机版SQLServer存在着根本上的不同,它将多种先进的数据存储与处理技术结合为一体,是微软大数据战略的重要组成部分。
3、Hadoop on Windows。微软同时在Windows Azure平台和WindowsServer上提供Hadoop,把Hadoop的高性能、高可扩展与微软产品易用、易部署的传统优势融合到一起,形成完整的大数据解决方案。微软大数据解决方案还通过简单的部署以及与Active Directory和System Center等组件的集成,为Hadoop提供了Windows的易用性和可管理性。凭借Windows Azure上基于Hadoop的服务,微软为其大数据解决方案在云端提供了灵活性。
Ⅲ 技术干货:SQL on Hadoop在快手大数据平台的实践与优化
快手大数据架构工程师钟靓近日在 A2M 人工智能与机器学习创新峰会分享了题为《SQL on Hadoop 在快手大数据平台的实践与优化》的演讲,主要从 SQL on Hadoop 介绍、快手 SQL on Hadoop 平台概述、SQL on Hadoop 在快手的使用经验和改进分析、快手 SQL on Hadoop 的未来计划四方面介绍了 SQL on Hadoop 架构。
SQL on Hadoop,顾名思义它是基于 Hadoop 生态的一个 SQL 引擎架构,我们其实常常听到 Hive、SparkSQL、Presto、Impala 架构。接下来,我会简单的描述一下常用的架构情况。
HIVE,一个数据仓库系统。它将数据结构映射到存储的数据中,通过 SQL 对大规模的分布式存储数据进行读、写、管理。
根据定义的数据模式,以及输出 Storage,它会对输入的 SQL 经过编译、优化,生成对应引擎的任务,然后调度执行生成的任务。
HIVE 当前支持的引擎类型有:MR、SPARK、TEZ。
基于 HIVE 本身的架构,还有一些额外的服务提供方式,比如 HiveServer2 与 MetaStoreServer 都是 Thrift 架构。
此外,HiveServer2 提供远程客户端提交 SQL 任务的功能,MetaStoreServer 则提供远程客户端操作元数据的功能。
Spark,一个快速、易用,以 DAG 作为执行模式的大规模数据处理的统一分析引擎,主要模块分为 SQL 引擎、流式处理 、机器学习、图处理。
SPARKSQL 基于 SPARK 的计算引擎,做到了统一数据访问,集成 Hive,支持标准 JDBC 连接。SPARKSQL 常用于数据交互分析的场景。
SPARKSQL 的主要执行逻辑,首先是将 SQL 解析为语法树,然后语义分析生成逻辑执行计划,接着与元数据交互,进行逻辑执行计划的优化,最后,将逻辑执行翻译为物理执行计划,即 RDD lineage,并执行任务。
PRESTO,一个交互式分析查询的开源分布式 SQL 查询引擎。
因为基于内存计算,PRESTO 的计算性能大于有大量 IO 操作的 MR 和 SPARK 引擎。它有易于弹性扩展,支持可插拔连接的特点。
业内的使用案例很多,包括 FaceBook、AirBnb、美团等都有大规模的使用。
我们看到这么多的 SQL on Hadoop 架构,它侧面地说明了这种架构比较实用且成熟。利用 SQL on Hadoop 架构,我们可以实现支持海量数据处理的需求。
查询平台每日 SQL 总量在 70 万左右,DQL 的总量在 18 万左右。AdHoc 集群主要用于交互分析及机器查询,DQL 平均耗时为 300s;AdHoc 在内部有 Loacl 任务及加速引擎应用,所以查询要求耗时较低。
ETL 集群主要用于 ETL 处理以及报表的生成。DQL 平均耗时为 1000s,DQL P50 耗时为 100s,DQL P90 耗时为 4000s,除上述两大集群外,其它小的集群主要用于提供给单独的业务来使用。
服务层是对上层进行应用的。在上层有四个模块,这其中包括同步服务、ETL 平台、AdHoc 平台以及用户程序。在调度上层,同样也有四方面的数据,例如服务端日志,对它进行处理后,它会直接接入到 HDFS 里,我们后续会再对它进行清洗处理;服务打点的数据以及数据库信息,则会通过同步服务入到对应的数据源里,且我们会将元数据信息存在后端元数据系统中。
网页爬取的数据会存入 hbase,后续也会进行清洗与处理。
HUE、NoteBook 主要提供的是交互式查询的系统。报表系统、BI 系统主要是 ETL 处理以及常见的报表生成,额外的元数据系统是对外进行服务的。快手现在的引擎支持 MR、Presto 及 Spark。
管理系统主要用于管理我们当前的集群。HiveServer2 集群路由系统,主要用于引擎的选择。监控系统以及运维系统,主要是对于 HiveServer2 引擎进行运维。
我们在使用 HiveServer2 过程中,遇到过很多问题。接下来,我会详细的为大家阐述快手是如何进行优化及实践的。
当前有多个 HiveServer2 集群,分别是 AdHoc 与 ETL 两大集群,以及其他小集群。不同集群有对应的连接 ZK,客户端可通过 ZK 连接 HiveServer2 集群。
为了保证核心任务的稳定性,将 ETL 集群进行了分级,分为核心集群和一般集群。在客户端连接 HS2 的时候,我们会对任务优先级判定,高优先级的任务会被路由到核心集群,低优先级的任务会被路由到一般集群。
BeaconServer 服务为后端 Hook Server 服务,配合 HS2 中的 Hook,在 HS2 服务之外实现了所需的功能。当前支持的模块包括路由、审计、SQL 重写、任务控制、错误分析、优化建议等。
•无状态,BeaconServer 服务支持水平扩展。基于请求量的大小,可弹性调整服务的规模。
•配置动态加载,BeaconServer 服务支持动态配置加载。各个模块支持开关,服务可动态加载配置实现上下线。比如路由模块,可根据后端加速引擎集群资源情况,进行路由比率调整甚至熔断。
•无缝升级,BeaconServer 服务的后端模块可单独进行下线升级操作,不会影响 Hook 端 HS2 服务。
•Hive 支持 SPARK 与 TEZ 引擎,但不适用于生产环境。
•SQL on Hadoop 的 SQL 引擎各有优缺点,用户学习和使用的门槛较高。
•不同 SQL 引擎之间的语法和功能支持上存在差异,需要大量的测试和兼容工作,完全兼容的成本较高。
•不同 SQL 引擎各自提供服务会给数仓的血缘管理、权限控制、运维管理、资源利用都带来不便。
•在 Hive 中,自定义实现引擎。
•自动路由功能,不需要设置引擎,自动选择适合的加速引擎。
•根绝规则匹配 SQL,只将兼容的 SQL 推给加速引擎。
•复用 HiveServer2 集群架构。
基于 HiveServer2,有两种实现方式。JDBC 方式是通过 JDBC 接口,将 SQL 发送至后端加速引擎启动的集群上。PROXY 方式是将 SQL 下推给本地的加速引擎启动的 Client。
JDBC 方式启动的后端集群,均是基于 YARN,可以实现资源的分时复用。比如 AdHoc 集群的资源在夜间会自动回收,作为报表系统的资源进行复用。
路由方案基于 HS2 的 Hook 架构,在 HS2 端实现对应 Hook,用于引擎切换;后端 BeaconServer 服务中实现路由 服务,用于 SQL 的路由规则的匹配处理。不同集群可配置不同的路由规则。
为了保证后算路由服务的稳定性,团队还设计了 Rewrite Hook,用于重写 AdHoc 集群中的 SQL,自动添加 LIMIT 上限,防止大数据量的 SCAN。
•易于集成,当前主流的 SQL 引擎都可以方便的实现 JDBC 与 PROXY 方式。再通过配置,能简单的集成新的查询引擎,比如 impala、drill 等。
•自动选择引擎,减少了用户的引擎使用成本,同时也让迁移变得更简单。并且在加速引擎过载 的情况下,可以动态调整比例,防止因过载 对加速性能的影响。
•自动降级,保证了运行的可靠性。SQL 路由支持 failback 模块,可以根据配置选择是否再路由引擎执行失败后,回滚到 MR 运行。
•模块复用,对于新增的引擎,都可以复用 HiveServer2 定制的血缘采集、权限认证、并发锁控制等方案,大大降低了使用成本。
•资源复用,对于 adhoc 查询占用资源可以分时动态调整,有效保证集群资源的利用率。
当查询完成后,本地会轮询结果文件,一直获取到 LIMIT 大小,然后返回。这种情况下,当有大量的小文件存在,而大文件在后端的时候,会导致 Bad Case,不停与 HDFS 交互,获取文件信息以及文件数据,大大拉长运行时间。
在 Fetch 之前,对结果文件的大小进行预排序,可以有数百倍的性能提升。
示例:当前有 200 个文件。199 个小文件一条记录 a,1 个大文件混合记录 a 与 test 共 200 条,大文件名 index 在小文件之后。
Hive 中有一个 SimpleFetchOptimizer 优化器,会直接生成 FetchTask,减小资源申请时间与调度时间。但这个优化会出现瓶颈。如果数据量小,但是文件数多,需要返回的条数多,存在能大量筛掉结果数据的 Filter 条件。这时候串行读取输入文件,导致查询延迟大,反而没起到加速效果。
在 SimpleFetchOptimizer 优化器中,新增文件数的判断条件,最后将任务提交到集群环境,通过提高并发来实现加速。
示例:读取当前 500 个文件的分区。优化后的文件数阈值为 100。
一个表有大量的子分区,它的 DESC 过程会与元数据交互,获取所有的分区。但最后返回的结果,只有跟表相关的信息。
与元数据交互的时候,延迟了整个 DESC 的查询,当元数据压力大的时候甚至无法返回结果。
针对于 TABLE 的 DESC 过程,直接去掉了跟元数据交互获取分区的过程,加速时间跟子分区数量成正比。
示例:desc 十万分区的大表。
•复用 split 计算的数据,跳过 rece 估算重复统计输入过程。输入数据量大的任务,调度速率提升 50%。
•parquetSerde init 加速,跳过同一表的重复列剪枝优化,防止 map task op init 时间超时。
•新增 LazyOutputFormat,有 record 输出再创建文件,避免空文件的产生,导致下游读取大量空文件消耗时间。
•statsTask 支持多线程聚合统计信息,防止中间文件过多导致聚合过慢,增大运行时间。
•AdHoc 需要打开并行编译,防止 SQL 串行编译导致整体延迟时间增大的问题。
HS2 启动时会对物化视图功能进行初始化,轮询整个元数据库,导致 HS2 的启动时间非常长,从下线状态到重新上线间隔过大,可用性很差。
将物化视图功能修改为延迟懒加载,单独线程加载,不影响 HS2 的服务启动。物化视图支持加载中获取已缓存信息,保证功能的可用性。
HS2 启动时间从 5min+提升至<5s。
HS2 本身上下线成本较高,需要保证服务上的任务全部执行完成才能进行操作。配置的修改可作为较高频率的操作,且需要做到热加载。
在 HS2 的 ThriftServer 层我们增加了接口,与运维系统打通后,配置下推更新的时候自动调用,可实现配置的热加载生效。
HiveServer2 的 scratchdir 主要用于运行过程中的临时文件存储。当 HS2 中的会话创建时,便会创建 scratchdir。在 HDFS 压力大的时候,大量的会话会阻塞在创建 scratchdir 过程,导致连接数堆积至上限,最终 HS2 服务无法再连入新连接,影响服务可用性。
对此,我们先分离了一般查询与 create temporay table 查询的 scratch 目录,并支持 create temporay table 查询的 scratch 的懒创建。当 create temporay table 大量创建临时文件,便会影响 HDFS NameNode 延迟时间的时候,一般查询的 scratchdir HDFS NameNode 可以正常响应。
此外,HS2 还支持配置多 scratch,不同的 scratch 能设置加载比率,从而实现 HDFS 的均衡负载。
Hive 调度其中存在两个问题。
一、子 Task 非执行状态为完成情况的时候,若有多轮父 Task 包含子 Task,导致子 Task 被重复加入调度队列。这种 Case,需要将非执行状态修改成初始化状态。
二、当判断子 Task 是否可执行的过程中,会因为状态检测异常,无法正常加入需要调度的子 Task,从而致使查询丢失 Stage。而这种 Case,我们的做法是在执行完成后,加入一轮 Stage 的执行结果状态检查,一旦发现有下游 Stage 没有完成,直接抛出错误,实现查询结果状态的完备性检查。
•HS2 实现了接口终止查询 SQL。利用这个功能,可以及时终止异常 SQL。
•metastore JDOQuery 查询优化,关键字异常跳过,防止元数据长时间卡顿或者部分异常查询影响元数据。
•增加开关控制,强制覆盖外表目录,解决 insert overwrite 外表,文件 rename 报错的问题。
•hive parquet 下推增加关闭配置,避免 parquet 异常地下推 OR 条件,导致结果不正确。
•executeForArray 函数 join 超大字符串导致 OOM,增加限制优化。
•增加根据 table 的 schema 读取分区数据的功能,避免未级联修改分区 schema 导致读取数据异常。
•部分用户并没有开发经验,无法处理处理引擎返回的报错。
•有些错误的报错信息不明确,用户无法正确了解错误原因。
•失败的任务排查成本高,需要对 Hadoop 整套系统非常熟悉。
•用户的错误 SQL、以及需要优化的 SQL,大量具有共通性。人力维护成本高,但系统分析成本低。
SQL 专家系统基于 HS2 的 Hook 架构,在 BeaconServer 后端实现了三个主要的模块,分别是 SQL 规则控制模块、SQL 错误分析模块,与 SQL 优化建议模块。SQL 专家系统的知识库,包含关键字、原因说明、处理方案等几项主要信息,存于后端数据库中,并一直积累。
通过 SQL 专家系统,后端可以进行查询 SQL 的异常控制,避免异常 SQL 的资源浪费或者影响集群稳定。用户在遇到问题时,能直接获取问题的处理方案,减少了使用成本。
示例:空分区查询控制。
SQL 专家系统能解决一部分 HS2 的任务执行的错误诊断需求,但是比如作业 健康 度、任务执行异常等问题原因的判断,需要专门的系统来解决,为此我们设计了作业诊断系统。
作业诊断系统在 YARN 的层面,针对不同的执行引擎,对搜集的 Counter 和配置进行分析。在执行层面,提出相关的优化建议。
作业诊断系统的数据也能通过 API 提供给 SQL 专家系统,补充用于分析的问题原因。
作业诊断系统提供了查询页面来查询运行的任务。以下是命中 map 输入过多规则的任务查询过程:
Ⅳ 求大数据分析技术
列一大堆没用的。。。
大数据分析技术两种理解: 一种是 大数据处理涉及到技术, 一种专是 数据挖掘技术
第一种就属是数据处理流程: 也就是 数据采集 数据清洗 数据存储 数据挖掘 结果可视化展示 技术。
第二种就是具体的数据挖掘算法: 主要是 回归 分类 关联规则 聚类 异常检测 这几种
看你需要哪种?
Ⅳ 请教,怎么将mysql里的大数据同步到 sqlserver2008里
您好,很高兴为您解答。
下载安装SQLyog v10.51,确保本机安装了Mysql和Sql server 2008 r2。
使用SQLyog连上本地mysql数据库
点数据库>导入>导入外部数据 进入SQLyog外部数据导入向导,选择“开始新的工作”,点“下一步”
在数据源类型中只有access、excel、csv、任何odbc数据源。使用前面三个中间数据格式转换方式都可以导入不过就麻烦了。这里我们选择任何ODBC数据源
再点击“建立新的DSN”,弹出窗口“创建新数据源”,我们选择“系统数据源”并进入下一步
选择数据源驱动“SQL Server”,进入下一步点“完成”
设置一个数据源名称,并填写你的SQL服务器IP,如果是本地服务器可以直接下拉框选择。
输入登录账号密码(看你的SQL服务器是哪种登录验证方式),填写好了就下一步、下一步、完成。
弹出配置信息窗口后就可以点“测试数据源”,看是否连接到服务器
再回到导入向导,选下一步。
设置要导入的本地目标数据库之后下一步,再选择“拷贝数据到本地”下一步,勾选你要导入的数据表,后面还可以相应设置每个表要拷贝到本地那个数据表名称,然后下一步就开始拷贝数据至本地MYSQL。
如若满意,请点击右侧【采纳回答】,如若还有问题,请点击【追问】
希望我的回答对您有所帮助,望采纳!
~ O(∩_∩)O~
Ⅵ 如何使用Big SQL访问大数据使用详解
使用 JDBC/ODBC 程序访问 Big SQL
我们可以使用 JDBC/ODBC 程序来访问 Big SQL,我们以 JDBC 程序为例,详细介绍了使用 JDBC 访问 Big SQL 的具体方法。
首先,我们需要在 CLASSPATH 环境变量中增加 bigsql-jdbc-driver.jar 文件,如下所示:
清单 8. 增加 CLASSPATH 环境变量
biadmin@imtebi1:/opt/ibm/biginsights/bigsql/samples/queries>
export CLASSPATH=$CLASSPATH:/opt/ibm/biginsights/bigsql/samples/queries/bigsql-jdbc-driver.jar
并创建 countbrand.java 程序,如下所示:
清单 9. countbrand.java 程序
countbrand.java
import java.io.*;
import java.sql.*;
import java.util.*;
class countbrand {
public static void main(String args[]) throws SQLException,Exception {
try {
//load the driver class
Class.forName("com.ibm.biginsights.bigsql.jdbc.BigSQLDriver");
} catch (ClassNotFoundException e) {
System.out.print(e); }
try {
//set connection properties
String user="biadmin";
String password="password";
Connection con = DriverManager.getConnection("jdbc:bigsql://172.16.42.202:7052/gosalesdw",
user,password);
Statement st = con.createStatement();
//query execution
ResultSet rs = st.executeQuery("SELECT count(*) FROM GOSALESDW.GO_BRANCH_DIM AS BD,
GOSALESDW.DIST_INVENTORY_FACT AS IF WHERE IF.BRANCH_KEY = BD.BRANCH_KEY /*+ joinMethod = 'mapSideHash',
buildTable = 'bd' +*/ AND BD.BRANCH_CODE > 20");
while(rs.next()) {
System.out.println(rs.getString(1));
}
} catch(SQLException sqle)
{ System.out.print(sqle); }
}
}
我们可以使用如下命令编译并运行 countbrand.java 程序,如下所示:
清单 10. 编译并运行 countbrand.java 程序
biadmin@imtebi1:/opt/ibm/biginsights/bigsql/samples/queries> javac countbrand.java
biadmin@imtebi1:/opt/ibm/biginsights/bigsql/samples/queries> java countbrand
33318
创建、加载表
同关系数据库一样,Big SQL 也存在模式。模式是指一组对象的集合,我们可以通过创建不同的模式来组织 Big SQL 中的数据对象。如下所示,我们创建 gosalesdw 模式来组织我们需要创建的 Hive 及 HBase 表。
清单 11. 创建 gosalesdw 模式
biadmin@imtebi1:/opt/> $BIGSQL_HOME/bin/jsqsh -U biadmin -P password
JSqsh Release 1.5-ibm, Copyright (C) 2007-2013, Scott C. Gray
Type \help for available help topics. Using JLine.
[localhost][biadmin] 1> create schema if not exists gosalesdw;
0 rows affected (total: 1m4.56s)
[localhost][biadmin] 1> quit;
biadmin@imtebi1:/opt/$HADOOP_HOME/bin/hadoop fs -ls /biginsights/hive/warehouse
drwxr-xr-x - biadmin biadmgrp
0 2013-12-21 21:20 /biginsights/hive/warehouse/gosalesdw.db
在 Big SQL 中,我们创建的模式会在 DFS 分布式文件系统中创建一个相应的目录,该目录可以在创建模式时指定,如果没有指定目录,会在 Hive 的默认目录 /biginsights/hive/warehouse/ 下创建。我们可以通过修改 $HIVE_HOME/conf/hive-site.xml 文件中的 hive.metastore.warehouse.dir 属性值来修改 Hive 的默认存储路径,如下所示:
清单 12. 修改 hive-site.xml
biadmin@imtebi1:/opt/> $BIGSQL_HOME/bin/jsqsh -U biadmin -P password
JSqsh Release 1.5-ibm, Copyright (C) 2007-2013, Scott C. Gray
Type \help for available help topics. Using JLine.
[localhost][biadmin] 1> create schema if not exists gosalesdw1 location
'/usr/biadmin/gosalesdw1.db';
0 rows affected (total: 0.87s)
[localhost][biadmin] 1> quit
biadmin@imtebi1:/opt/> $HADOOP_HOME/bin/hadoop fs -ls /usr/biadmin
Found 1 items
drwxr-xr-x - biadmin supergroup 0 2013-12-21 21:26 /usr/biadmin/gosalesdw1.db
more $HIVE_HOME/conf/hive-site.xml
hive.metastore.warehouse.dir
/biginsights/hive/warehouse
Ⅶ 如何优化大数据高并发量的系统的SQL语句提高效率
1、HTML静态化
效率最高、消耗最小的就是纯静态化的html页面,所以尽可能使网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站,无法全部手动去挨个实现,于是出现了常见的信息发布系统CMS,像常访问的各个门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理、权限管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。
2、图片服务器分离
对于Web服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是有必要将图片与页面进行分离,这是基本上大型网站都会采用的策略,他们都有独立的图片服务器,甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不会因为图片问题而崩溃,在应用服务器和图片服务器上,可以进行不同的配置优化,比如apache在配置ContentType的时候可以尽量少支持,尽可能少的LoadMole,保证更高的系统消耗和执行效率。 这一实现起来是比较容易的一现,如果服务器集群操作起来更方便,如果是独立的服务器,新手可能出现上传图片只能在服务器本地的情况下,可以在令一台服务器设置的IIS采用网络路径来实现图片服务器,即不用改变程序,又能提高性能,但对于服务器本身的IO处理性能是没有任何的改变。
3、数据库集群和库表散列
大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是需要使用数据库集群或者库表散列。
4、缓存
缓存一词搞技术的都接触过,很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。架构方面的缓存,对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块,也可以使用外加的Squid模块进行缓存,这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存,Linux上提供的Memory Cache是常用的缓存接口,可以在web开发中使用,比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享,一些大型社区使用了这样的架构。另外,在使用web语言开发的时候,各种语言基本都有自己的缓存模块和方法,PHP有Pear的Cache模块,Java就更多了,.net不是很熟悉,相信也肯定有。