testing-04

简单生活

  • 这是一个记录。虽然微软的文档已经非常完善和友好了,但是涉及到一些软件版本等相关问题,配置并不畅通。

    安装

    本地环境是macOS Big Sur 11.4版本,使用的是Python 3.8.2版本。

    zzx@localhost % python3
    Python 3.8.2 (default, Apr  8 2021, 23:19:18)
    [Clang 12.0.5 (clang-1205.0.22.9)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>>

    需要安装pyodbc、unixodbc、msodbcsql17、mssql-tools等工具(详细参考):

    pip3 install pyodbc
    brew install unixodbc

    测试脚本

    主要参考微软文档:Proof of concept connecting to SQL using pyodbc。测试连接脚本如下:

    import pyodbc
    # Some other example server values are
    # server = 'localhost\sqlexpress' # for a named instance
    # server = 'myserver,port' # to specify an alternate port
    server = 'x.x.x.x'
    # server = 'tcp:x.x.x.x,1433'
    database = 'xxx'
    username = 'xxx'
    password = 'xxx'
    cnxn = pyodbc.connect('DRIVER={ODBC Driver 17 for SQL Server};SERVER='+server+';DATABASE='+database+';UID='+username+';PWD='+ password)
    cursor = cnxn.cursor()
    
    #Sample select query
    cursor.execute("SELECT @@version;")
    row = cursor.fetchone()
    while row:
        print(row[0])
        row = cursor.fetchone()

    一下子就跑通了? 有经验的开发者都知道,那当然不能这么顺利,是吧。首先,遇到如下报错:

    Traceback (most recent call last):
      File "mssqlremotessh.py", line 10, in <module>
        cnxn = pyodbc.connect('DRIVER={ODBC Driver 17 for SQL Server};SERVER='+server+';DATABASE='+database+';UID='+username+';PWD='+ password)
    pyodbc.OperationalError: ('08001', '[08001] [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection (0) (SQLDriverConnect)')

    是哪个环节的问题?

    老实说,这个报错真的很不友好,无法看出来是什么地方的问题。首先,根据Github上一个issue建议首先通过isql命令(应该是unixODBC的工具)尝试连接一下SQL Server,果然有了新的发现:

    # 注意:下面命令的IP和密码都被修改了
    isql -v -k 'Driver={ODBC Driver 17 for SQL Server};Server=tcp:18.336.80.202,1433;Database=9zcloud;Uid=zzx;Pwd=********;'
    
    
    [08001][Microsoft][ODBC Driver 17 for SQL Server]SSL Provider: [OpenSSL library could not be loaded, make sure OpenSSL 1.0 or 1.1 is installed]
    [08001][Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection
    [ISQL]ERROR: Could not SQLDriverConnect

    解决openssl版本依赖问题

    看起来似乎是ODBC依赖OpenSSL 1.0或者1.1,而查看了本地默认安装的应该是v3版本,查看如下:

    $ cd /usr/local/Cellar/ && ls
    $ cd openssl@3/3.0.1/bin
    $ ./openssl version
    $ OpenSSL 3.0.1 14 Dec 2021 (Library: OpenSSL 3.0.1 14 Dec 2021)

    自此,已经找到了问题的症结(也可能是问题的症结之一,是吧):似乎是ODBC只认这两个版本的openssl,沿着此线索搜索,发现,这个问题在Github的 issue 59@microsoft/homebrew-mssql-release 中讨论得比较多,而且,在下面的回答中也有一些办法可以尝试解决:在系统中,额外在安装openssl 1.1,并把链接库目录的软连接从3.0版本更换到1.1版本。(这么做,还是有点担心其他的软件运行有问题的,但是先这么做吧,把问题解决了),详细回答参考如下:

    具体的操作如下:

    zzx@localhost ~ % ls -lah /usr/local/opt/openssl
    lrwxr-xr-x  1 zzx  admin    25B 12 28 10:21 /usr/local/opt/openssl -> ../Cellar/openssl@3/3.0.1
    
    unlink /usr/local/opt/openssl
    
    # 这里要注意,你所安装的openssl版本和目录可能和以上截图中是不同的,所以要根据实际情况进行连接,例如我这里是1.1.1m版本,而不是截图中的1.1.1l版本。
    ln -s /usr/local/Cellar/openssl@1.1/1.1.1m /usr/local/opt/openssl

    Finnally,it works!!

    zzx@localhost ~ % ln -s /usr/local/Cellar/openssl@1.1/1.1.1m /usr/local/opt/openssl
    zzx@localhost ~ % isql -v -k 'Driver={ODBC Driver 17 for SQL Server};Server=tcp:19.36.80.2,1433;Database=9zcloud;Uid=zzx;Pwd=******;'
    +---------------------------------------+
    | Connected!                            |
    |                                       |
    | sql-statement                         |
    | help [tablename]                      |
    | quit                                  |
    |                                       |
    +---------------------------------------+
    SQL> select * from dbo.t_1;
    +------------+---------------------------------+-----------+
    | id         | nick                            | birthday  |
    +------------+---------------------------------+-----------+
    | 1          |                                 |           |
    | 2          | zzx                             |           |
    | 3          | yzs                             | 2008-09-23|
    +------------+---------------------------------+-----------+

    在回头去运行,最前面的示例脚本,也可以正常连接SQL Server,至此,剧终。所以,回头来看,今天的解决问题的堆栈如下:

    • unixODBC关于openssl版本兼容性的问题
    • 安装unixODBC & mssql-tools
    • 尝试python连接SQL Server
    • 尝试通过ssh tunnel连接SQL Server

    相关阅读

    • 更多关于什么是unixODBC,什么事isql,可以参考:unixODBC
    • Install the Microsoft ODBC driver for SQL Server (macOS):参考

  • 注:这是一篇阿里云数据库ACP认证的软文,但是还是非常非常推荐阅读。因为这个认证很可能会成为国内数据库领域最重要的认证,对很多数据库极其相关技术人员都会有很大的影响。

    概述

    TLDR版本:阿里云数据库ACP认证填补了云时代与传统数据架构时代之间数据库专业认证的空白。无论是不是写软文,笔者都是非常推荐云数据库从业者或者与数据库相关度比较高的开发者,都去拿下这个认证的。另外,也提醒一下,这个认证是刚刚推出,无论是试题还是流程都还有一些小的磕盼,也可以考虑等半年之后再去拿证,都时候应该会更加成熟一些。也预警一下:这个证书要花费一些费用,考试难度还是比较大的,所以通过考试并不容易,笔者考试过程整整鏖战两小时,83分,涉险过关(80分通过)。

    什么是阿里云数据库ACP认证

    我从阿里云出来已经几个月了,恍如隔世…,出来之前也曾是阿里云数据库认证体系建设的负责人,在整个事业部的支持下,设计并上线了阿里云数据库的ACA认证(参考)。在上周,阿里云数据库推出ACP认证,是一个更高级别的认证,认证一上线,我就便迫不及待的上线去考下了这个证书。据说,可能是全球第一个获得阿里云数据库ACP认证的人员(烦请内部同学再帮确认一下)。

    数据库ACP认证是整个阿里云面向开发者的认证体系的一部分(参考),与初级的”数据库ACA”认证组成了数据库垂直领域的初步认证体系。ACP全称是专业工程师(Alibaba Cloud Certified Professional),也是*当前*云数据库最高端的认证(也许未来会推出ACE)。主要面向,云数据库相关从业者,包括DBA、云系统管理员、与数据库相关度比较高的开发者等。要求上,需要参与认证的人,对通用数据库基础有非常好的了解,同时,对于云数据库相关技术也非常详细的了解。数据库的ACP认证分了两个方向:关系型数据库、数据仓库,可以根据自己的专业背景选择其中一个方向去挑战。

    数据库领域的”各种认证”

    在计算机发展之初,一个重要的应用就是数据的存储与计算。数据库在过去60年的发展中,一直都是计算机技术最重要的分支技术之一。在现代数字化企业架构中,数据架构的设计、数据技术选型都是重大的挑战,无论是在基于本地IDC的架构,还是基于现代的云计算架构,这一点都没有发生变化。而且,在当前各行各业数字化转型的过程中,数据架构在企业中的地位也越来越重要。

    数据库技术人员也一直是构建企业数据架构的核心人员。在数据库技术发展的过去的半个世纪,各个数据库厂商,为了培养各个不同类型的数据库的专业人才,推出了各个垂直方向的认证,例如,Oracle的OCP、OCM认证,微软早期的MCSA、MCSE、MongoDB Developer/Database Administrator、TiDB的Associate/professional、OceanBase的OBCA/OBCA/OBCE等。

    这些认证中,其中Oracle认证一度最为成功。从认证的设计上,非常完善,OCA/OCP/OCM三级认证,层层递进,很好的帮助学习逐步了解Oracle数据库的各个方面。另外,更重要的,也因为Oracle认证的权威性,企业人员在招聘时有了一个不错的参考,也让想进入这个领域的从业者,有了一个非常好的入门途径(参考)。

    云时代数据库从业者的新要求

    云计算已经改变了企业和开发者使用数据库的方式,现代企业是以数字化为基础的,数据架构也是企业架构的核心部分,企业在数据架构选型上,两个趋势已经是事实了:一个是”云化”,选择以云计算技术为基础的架构,利用云计算的平台与产品优势,提升企业的业务研发效率;一个是”多种数据库”并行,随着数字化在业务场景中不断深化,各类的数据场景都呈现出了不一样的数据存储、查询、分析的要求,一两个数据库就解决所有的企业存储要求,已经不可能了。可以看到,在传统关系型数据库基础上,图数据库、时序数据库、文档数据库等都在快速发展。

    随着云计算的逐渐渗透,各家云厂商争相发布的各个数据库全托管服务(如RDS),使得企业内部已经不再需要单独的人去做很多基础的工作了,例如数据库的安装部署、备份管理、监控配置等;另一方面,随着数据存储场景的增加,数据库种类的增多,如何选择最合适的数据库存储引擎支撑业务快速发展与决策,成为了更重要的命题;另外,随着云厂商的积极投入(“juan”,第三声),如何选择最适合企业的云数据架构,也是企业的基本诉求。

    这对企业数据库架构师、数据库管理员就提出了完全不同的要求,无论是技能上,还是职业发展上,都发生了很大的变化。这也是为什么传统的认证,已经不再适应当前的时代,细心的数据库从业者应该已经注意到了这一点,一方面传统的认证参与人员变少了,另一方面各个数据库厂商自己认证也在变化(例如Oracle将废弃老的OCA,微软也重点推Azure相关的认证)。

    在多个云厂商并驾齐驱的时代,在数据库存储引擎百花齐放的时代,云数据库的认证就成为当前的最佳选择,云数据库认证将在众多的数据库认证中崛起。这也是云时代,对数据库从业者的新要求:熟悉多种数据库引擎、熟悉多个云平台上的数据库特点,基于此构建现代企业的数字化架构,帮助企业提升业务效率与决策支持。

    云厂商数据库认证的优势与缺点

    相比单个数据库认证,云数据库厂商的认证则更加丰富,更加立体,不是简单拘泥于某个数据库的技术细节,更加在意数据库的通用技术,例如阿里云数据库ACP认证就覆盖了MySQL、PostgreSQL、数据复制工具等产品。当然,”私心”也很明显,例如,就包含了大量的PolarDB、AliSQL等相关内容。当然,阿里云作为重要的数据库厂商,PolarDB又是最重要的产品,多去了解一下,也是非常有必要的。

    谁应该考ACP

    数据库的ACP认证难度系数是比较高的,并不适合所有的技术人员都去考。有几类人是建议获取这个认证的:

    • 所有的DBA、数据架构师
    • 构建数据相关应用的开发人员
    • 基于云架构的系统管理员
    • 想深入了解云数据库技术的技术人员

    考试的形式与内容

    这部分,在官网上有比较详细的说明:参考。这里简单说一下感受,目前,学习资料还不是很丰富,有一个200页的ppt,内容大致方向都涵盖了,但是实际考试试题是远超出ppt本身的内容的,ACP考试配套的还有一个视频学习课程,如果想顺利通过考试,认真学习视频是非常有必要的。另外,除了考试之外,还有一系列的动手试验,目前,这部分设计的都还比较简单,也都有step by step的引导,难度还不算高。

    完成动手实验,通过考试,就可以获得正式的ACP证书了。

    最后,也晒一下,据悉是全球第一个阿里云数据库ACP的证书,如下:

    参考文档

    1. Database@Wikiedia https://en.wikipedia.org/wiki/Database#History
    2. 阿里云数据库ACA认证: https://edu.aliyun.com/certification/aca09
    3. 阿里云数据库ACP认证:https://edu.aliyun.com/certification/acp17
    4. 阿里云认证: https://edu.aliyun.com/certification
    5. Oracle数据库认证: https://education.oracle.com/en/oracle-certification-path/pFamily_32
    6. PingCAP认证: https://learn.pingcap.com/learner/certification-center
  • 最近,Gartner正式发布了2021年云数据库魔力象限。阿里云继续保持在全球领导者象限,华为继续在第三象限,位置也有不错的提升,腾讯竟意外落选。国际厂商,微软凭借强大的云战略,横纵坐标全面超越Oracle,AWS和微软则齐头并进。

    去年,笔者也深度参与阿里云数据库冲击Gartner Leader象限的项目,整体上,Gartner在产品评估上已经是非常专业与细致的,评估的维度也比较立体,涵盖了产品能力、市场理解、技术创新、未来规划、市场份额、客户反馈等多个方面,可以作为企业软件选择的重要参考。

    数据库厂商在魔力象限上的“战争”

    我们一起来回顾一下,自魔力象限发布以来总计九次魔力象限的厂商分布​。

    2020年,Gartner将魔力象限从Operational Database更名为Cloud Database,Amazon和所有的云厂商,也获得了更多的认可。前面十年是微软和Oracle争夺老大的地位,未来,将是Amazon和微软争夺。从2020年MQ来看,Oracle已经在纵坐标上落后于海外的三家云计算厂商Amazon、微软和Google了,在今年,随着Oracle云战略的进展,位置也有了一些进展。整体上,这四家公司,也组成了整个象限的第一“集团”。

    从2013年到2019年,Oracle和微软一直是前两名,并且保持着统治性的领先。Oracle凭借着强大的数据库能力和几十年的积累,在各个行业的头部大型企业中占据了绝对领先的位置,构建了难以超越的数据库能力;微软则凭借SQL Server和强大且封闭的Windows开发生态,在中小企业占据了领先。在云计算逐渐兴起的过去十年,两家厂商都在all-in云计算。微软通过强大的开发者生态以及对大量企业客户的深耕,同时在云计算上坚决的投入,已经在云计算领域已经成为了三分天下的一方霸主。Oracle的云计算战略则比较坎坷(技术与人员上),目前,还在持续迎头赶上的阶段,目前,市场份额还比较小。


    Snowflake和Databricks两个“欢喜冤家”也分别从挑战者、远见者象限进入了领导者象限。前者市值已经接近1000亿美元,后者在最近一次融资中估值达到了380亿美元。数据库领域,已经从存储价值扩展到了通过数据分析与洞察实现了直接的业务价值。另外,两者也分别是多云原生和开源分析产品的典型方向的代表,可以看到后续会有更多厂商加入到这些领域进行创新。

    Amazon凭借云计算领域的绝对优势,改变了企业的软硬件架构,从而也彻底改变企业使用数据库方式,AWS的创新产品DynamoDB、Aurora也给开发者带来非常大的数据存储与处理的便利。Amazon自从2016年进入MQ以来,就一直是在Leader象限,而且位置也在逐年向前。

    阿里云数据库,自2018年首次进入数据库魔力象限,到2020年成功进入全球领导者象限,确实是中国数据库在世界范围内的一次重大突破。阿里巴巴过去的二十年,在数据库方向投入都非常大,每个阶段都有非常强的团队和领导者,包括汪海、陈吉平、冯春培、阳振坤、周宝方、张瑞、周光辉、余锋、曹伟、杨冰、杨传辉,到现在的李飞飞,团队规模之大,人员能力(一个参考是人员级别)之强,是国内公司独一无二的。2018年,李飞飞的加入,也让阿里云数据库的影响力,逐步的扩展到了海外。到现在,已经基本在领导者象限站稳脚跟,继续突破则是要正面与国外厂商在产品能力、市场、战略、人才等多角度​竞争。

    不在乎的Gartner的MongoDB 自2013年其就在MQ当中,2015年进入Leaders象限,2016年跌入Challengers象限,2017年在MQ的“大裁剪”中不再出现。但是,MongoDB在开发者群体中依旧非常受欢迎,在2021年StackOverflow的开发者年度调研中,MongoDB为排名第四的数据库;在资本市场,MongoDB自2017年上市以来,每股30美元增至到现在的超500美元(对应市值约350亿美元),应该是数据库领域非常耀眼的明星了,但似乎一直不怎么受Gartner MQ的“待见”。

    一直默默向前的MariaDB,今年第一次入选MQ。MariaDB凭借在多云部署、混合分析能力、容量评估与性能诊断等综合能力受到​认可。MariaDB这些年一直在苦苦与MySQL竞争,但是MySQL依旧凭借着最近十几年积累的生态与品牌优势,暂时领先。也许,现在是时候考虑,用MariaDB替换部分的MySQL​了。

    ​最后

    Gartner对于市场份额考量非常重,相对来说,对于较小的、垂直的数据库厂商不是那么的友好。另外,市场占有率有时候也比较难评估,各家厂商的最真实的数据,也不会直接透露给Gartner,实际透露给Gartner都会从结果的角度考虑,做一些调整。

    Gartner对于使用场景考虑是有一定缺陷的。比如,SAP、InterSystems等厂商,数据库主要是用于自家的应用系统,收入也都来自这些地方,这就让收入数值调整的空间比较大。另外,这样的评价,对于企业进行数据库架构选型并没有太大的参考意义。而,这应该是Gartner MQ的重要作用之一。

  • 在前段时间微软Ignite前后,Azure的SQL Server托管服务(Azure SQL Managed Instance)发布一个基于”Always On”技术的新的“Link”特性。可以帮助用户在云端实例和其他环境实例建立一条同步链路,将其他环境的数据同步到Azure云端。该功能当前处于邀请测试阶段(limited public preview),支持SQL Server 2019(需要CU13),长期计划支持2016及其以后的版本。

    从感受上来说,国外三家云厂商,Azure应该是更新最快速的,可以说是最努力的那朵云,相比AWS虽然起步晚,但是跑得非常快。从这个功能来看,微软在尝试通过产品化的方式帮助用户将本地的数据,快速、低成本的迁移到Azure。

    这里简单介绍一下该功能。使用该功能,可以实现如下能力:

    • 将本地或者其他云上的SQL Server数据”近实时”地同步到Azure云的SQL Server
    • 可以实现本地环境SQL Server的读扩展,可以将部分可以接受延迟的读服务切换到Azure上
    • 可以利用Azure上的一些分析产品能力,包括Synapse、MI、PBI等
    • 可以通过多个Link通路,将多个实例数据同步一个Azure实例上用于聚合分析
    • 利用Azure在全球众多区域部署,使用Link同步通路,可以让业务快速具备就近访问的能力
    • 可以帮助用户更加无缝的实现,从其他环境迁移到Azure上,使用Link特性是一个很好地过渡
    • 如果需要建设SQL Server数据库的容灾能力,这也是一个非常简单快速的方式

    参考链接:

    • Managed Instance link – connecting SQL Server to Azure reimagined:链接
    • Link feature for Azure SQL Managed Instance (limited preview):链接
    • Distributed availability groups:链接
  • 云数据库行业动态@20211201

    ·

    行业头条

    • 2022 IEEE Fellow 新晋名单出炉,阿里云数据库李飞飞入选。

    非常了不起,简单来说,叫”李飞飞”大概都非常牛逼,无论男女。不过话说,这次还没有看到阿里云开始宣传,难道还憋了更大的招?

    • Aurora开始支持MySQL 8.0:参考。AWS上版本号为3.01.0版本,基于MySQL 8.0.23版本。
    • Neptune开始支持ARM架构的实例:参考
    • DocumentDB开始支持Graviton 2实例,性能号称提升30%:参考

    今天是AWS年度大会re:Invent第一天,最近一个月AWS都在密集的发个各种功能。MySQL 8.0于2018年4月正式GA,三年半之后,Aurora正式支持8.0版本,看到,Aurora对于内核改造/定制是非常大的,导致一个大版本发布后的改造量非常大,跟紧社区的成本很高,当然,这大概也和官方8.0版本的代码一直以来变化比较大有一些关系。

    另外,AWS一直在加大Graviton2(ARM-Based)实例的支持与宣传,随着,云原生架构的标准化,IaaS层性价比将是各个云厂商的”基本内功”,在Graviton2上的投入,就相当于AWS在提前的偷偷修炼内功了,这与苹果做M1是一样的道理。

    • 火山引擎成为字节跳动的独立BU,云计算战略呼之欲出:参考

    期望看到更加繁荣的云计算市场,不过云计算是一个技术、资金投入都非常大的方向,字节加油!

    (more…)
  • 你一定要了解的Terraform

    ·

    HashiCorp正在筹备IPO,预计市值超100亿美金(参考)。创始人(参考)2011年大学毕业,2012年创建HashiCorp,2021年上市,又将是一个科技传奇。HashiCorp在Github上最受欢迎的项目就是Terraform,已经可以断定,Terraform会是未来资源编排服务的事实标准。

    Terraform在国内的使用还不是很多,讨论也不太多。这里就聊一下为什么开发者会选择Terraform,为什么企业应该选择Terraform作为资源编排的标准:

    1. Terraform目前已经支持了众多云厂商及其其他资源厂商,也可以反过来说,各个厂商都已经支持了terraform,对于各类云资源的管理,Terraform已经成为了IaC的事实标准。广泛的支持,让开发者不需要重复去学习和编写各个云厂商的API脚本,而是通过开源的方式,大家共用共建的Terraform内核能力,然后直接使用Terraform的描述性语言完成工作,直接复用了由开源社区构建的底层能力。

    2. 虽然各个云产生也都有自己的资源管理服务,例如AWS的CloudFormation、Azure的Azure Resource Manager、阿里云的ROS等。但对一家中/大型企业来说,通常都是使用了多云的资源,那么选择第三方的服务才是最简洁、效率最高的方式。无需重复适配各家厂商自己定义的规范和API。

    3. Terraform让基于云环境的Devops理念渗透到了底层资源上。通过tf脚本定义资源,创建资源后,后续流程可以根据tfstate状态文件,自动化的开始后续应用部署流程,无需人为介入,可以实现自动化的环境与资源部署,自动化与下游系统通信与衔接。

    4. 对于开发者来说,即便是在一家小企业,使用Terraform也是最合理的选择,一方面为未来的多云扩展做好了准备。另一方面,对于开发者自己,掌握了Terraform,应该是在市场上更加有竞争力的一种技能,可以应对更大规模、更复杂环境下的资源管理。

    5. 通过脚本语言定义资源,更加清晰,如果一个应用要在多个环境,部署很多的不同资源,还需要跨团队的协作,使用Terraform,就实现了用”代码描述资源”,也就是大家常说的IaC(Infrastuctur as Code),更加清晰,更加容易保障多环境部署资源的一致性,也有很好的传承性,新人进来也不需要用文档或者口口相传去解释环境应该如何部署。在传统架构下是这样,在多云时代,这个优势又被放大了。

    最后,关于HashiCorp和云厂商的关系,大家可以结合前两天Bluedavy那篇《国内云计算市场格局将走向何方》中的”惊悚建议”一起来看,应该更有意思。在开源厂商与云厂商的”竞合”中,可以说,开源厂商再下一城,未来更多的PaaS层会以各种方式去重塑云计算的市场格局。

    下面是一个简单的例子,可以简单直观的理解一下什么是Terrafrom。

    这时官方文档中国一个关于定义一个AWS EC2实例的代码(参考),这里省略了前面的安装和配置过程(注:需要配置一个Access Key用以授权)

    provider "aws" {
      profile = "default"
      region  = "us-west-2"
    }
    resource "aws_instance" "app_server" {
      ami           = "ami-830c94e3"
      instance_type = "t2.micro"
      tags = {
        Name = "ExampleAppServerInstance"
      }
    }

    当然,实际的过程中,”resource”中通常还会提供更多的参数来自定义你需要的实例,例如VPC网络配置、安全组等。

    之后,只需要使用如下执行命令,就可以完成资源的创建和创建后资源信息的查询:

    terraform init    // 初始化环境与版本
    terraform apply   // 实际创建资源
    terraform show    // 查看资源创建状态