❶ 数据仓库与数据库的区别
简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。
数据库一般存储在线交易数据闷孝，数据仓库存储的一般是历史数据。
数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。
数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。
单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月扰孙发生多少交易，该分行当前存款余额是多少。如果存款又多，蚂李稿消费交易又多，那么该地区就有必要设立ATM了。
显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。
数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。
“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。
“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。
“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。
数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。
补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。
1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。
2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。
3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。
❷ 技术干货：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 输入过多规则的任务查询过程：
❸ 零基础能成为数据分析师吗
不少人后台问我，如何转行做数据分析师，或毕业生怎样入行。我之前的文章都是围绕硬技能来写，这次以我知乎上的一篇答案为基础谈一下软技能。权当做杂谈。
我进入互联网行业完全是零基础，不是数据分析零基础，是样样能力零基础。
零基础到什么样子？我找工作花了三到四个月时间，最后以运营身份入职。
我从来不是数理强人，大学虽学习过高数、统计学、SQL和C语言，均是低空略过，考试还借助了小伙伴的力量。现在回头看，当时应该多学些。
最开始我不会vlookup，也没人教我，Excel只能做基础的操作。那时要关联多张报表，我仗着手速快，一个个搜索复制黏贴的…数据量一多肯定哭。后来我想这可不是办法啊。于是借助万能的网络：
“Excel怎么匹配多张表的数据。”
然后第一次看到vlookup函数。我也没有一次学会，每次用都要先看一遍网上的样例。后续我教组员的时候，他们学得比我快多了。
Excel一步一个脚印，学习都是依赖搜索和琢磨，抽空用工作中的内容练习分析：比如什么样的用户愿意用我们APP，用户哪些指标特别好。
即使在此期间，我也不会数据透视表。
记得15年初，老板给了我一个任务：网上收集数据，大约需要几万条，我不可能全部复制黏贴下来啊，便继续查询：
如何快速下载网页上的数据。
于是知道了爬虫，知道了Python，但我并不会。最后靠第三方爬虫工具，按照教程学习。早期已经学习过HTML+CSS，然后再了解网页结构，学习Get／Post，学习正则。花了一周时间加班，才下载下来。
可没有结束，数据是脏数据，我还需要清洗。再花一周时间学习Excel的find,right,mid,replace,trim等文本处理函数。那时候不知道这叫数据清洗，但是学会了很多技巧，即使我尽可能快速省力，还是花费数天。
当我现在写Python爬虫的时候，效率快速很多。包括文本清洗，用Levenshtein速度杠杠的。加起来一晚上就搞定。
任何学习都不是无用的，很多知识相通。我因为爬虫学习了HTML+CSS，后续便触理旁通地了解了网站结构和网站分析。
后续知道布置网络统计，知道JS，学习网页端的各类指标，了解访问路径、漏斗转化、跳出率退出率等。这些知识不止能用在网站上。也能用在APP分析、用户行为上。
我们把学习当成一个点，学完这本书就看下本书，其实这样发挥不出学习的效率。任何知识都具有关联性，A知识可以应用在B知识上，知识技能树应该是呈网状发散的。
上面链条是我基于前置知识掌握新知识的关系谱。数据分析涉及的领域很宽广，除了本身扎实的业务背景，还需要瑞士军刀般的技能树，属于T型能力（一专多才）。
比如你看到某个页面跳出率较高。除了常规的分析外，还要检查网络速度，用户弱网环境，是不是HTML页面加载过多，是否使用了缓存，网络DNS如何等。这些知识不会有人教你，但它左右业务结果。
看到这里别怕，虽然要学的多，但是随着学习的加深，很多知识是共通的。就像转化率来源于网站分析，却能用于产品路径，既能升华为桑基图，又能做用户分层。越学到后面，越容易一法通万法通。
驱动力
其实零基础学习数据分析，最难的门槛不是技能，而是学习动力。我从零培养过数据分析师，从零教过Excel、从零教过SQL、从零教过分析思维、从零教过Python。难点从不在于这些知识，而是你真的想不想学。
不是下载了十几G的资料就是学习，不是关注了很多公众号就是学习。因为十几G的资料最终不会打开，很多公众号最后都是未读。这能说明想学习？零基础太容易无从下手，难以坚持，浅尝则止了。
无从下手，这是不知道学什么，我说过数据分析是一门比较宽广的学科。它既有传统商业分析的方法论，也有数据时代的统计和编程。可它又偏偏是任何岗位任何职业都能用到的技能，绕不过。
学习是很主观的事情，我们从小学开始读到大学，数十年的学生生涯，最缺漏的能力是主动学习。中考高考打磨那么多年，很大情况是环境因素逼迫人去学习，本身没有任何学习的驱动力和习惯。大学四年再一度过，可能学习性就消磨殆尽了。
之所以说我们习惯被动学习，是大家都有一道题目做一道题目，只知道公式应用，不需要知晓原理。教材辅导题海战术，内容也不会超纲。整个大的学习环境都是为被动打造。
现在学习数据分析，拿起书籍、打开PDF资料、关注公众号。不会有老师纠正你辅导你，不会有作业鞭策你训练你。也不知道工作中哪个会经常用到，没有练手的数据题目，甚至连网络上的知识质量都难以辨别。
无从下手，对吧，可这才是主动学习。
心态要转变。
零基础学习数据分析，最大的老师只能是自己，不会有任何一篇文章一夜教人成为数据分析师。我带过愿意学习并且成长很快的实习生，也教导过有兴趣但依旧带不出节奏的同事。前者是主动学习，后者是止于兴趣的被动学习。
因为是零基础，所以才更需要主动性。数据分析本事是发展很快的行业，几年前会SQL就行，现在得了解些MR和HIVE，过几年SparkSQL也许就是必备，如果想在这一行做的好一些。持续的学习是必须的能力。或者基础不如其他人，至少学习性别输吧。
我也给出我的建议，学习应该是具体为解决某一个问题而设立目标，说透彻点，实战为王。不论是何种职业，一定或多或少能接触数据。先别去分析，而是想，能用这些数据干什么，做一个简单的假设。
我是HR，我的假设就是最近招人越来越困难啦，
我是市场，我的假设就是现在营销成本太高，又没有什么效果。
我是运营或者产品，更好办了，假设某指标的数据因为ABC等原因而无法提升。
哪怕是学生，也能假设在学校商圈赚钱是容易还是困难。
数据围绕假设去收集、生成、组合、利用、论证和分析。这是麦肯锡式的思维方法，也可以作为学数据的方法。新人容易陷入数据的迷途：我没有数据，有了数据也不知道干啥，知道干啥又不知道方法。想的太多，远不如有方向好用。
基于假设的好处是，我首先有了一个方向，别管它对不对，至少能按照方向做分析。
HR认为招人越来越困难，则可以拿出历史数据，以前我招人需要下载几份简历，打几个电话，发出几个Offer最终入职。现在呢？我还可以拿各个环节的数据观察，这不就是转化率嘛？时间维度放得宽一点，看看去年这时候招人困难不，是不是年底都难招，这样就了解折线图概念。
市场专员做分析，可以拿更多的数据作参考，假设营销成本太高，现在高到什么地步了，什么时候开始高的，找出时间点分析一下。效果不好，是什么时候效果不好，那时市场环境有什么变化吗？我假设市场环境有了变化，这又是一个新的假设，可以继续拎出一堆深入研究。
虽然各人分析效率和成果肯定不同，但是思路都能以这样训练出来。不是有了数据才有了分析，而是有了分析的方向才能收集分析数据。我的学习从来都是以解决问题为主，不是突然灵光一闪就会了。
如果把数据分析的学习旅程想成一条很长道路的话，我们不是一路开到终点，这没人能行。而是把这条道路分割成一段段，每段上面摆一个旗帜作目标，以旗帜为前行方向，不是以几十公里外的终点站作为目标。
好奇心
除了学习驱动力外，想成为数据分析师，还需要一颗好奇心。
好奇心就是问问题，想问题，琢磨问题，解决问题。如果你是一个天生八卦的人，那么将它用在数据分析上绝对是天选分析师，良材美玉。
很多人喜欢追求数据分析的工具、知识、要点、窍门。但是从来很少提到好奇心。
好奇心是解决问题的核心能力，编程可以锻炼，统计可以学习，这些最终都不是瓶颈。你学全了十八般武艺，临敌对战，最终需要的什么？是求胜心。数据的求胜心就是好奇。
知识决定解决问题的下限，好奇心决定解决问题的上限。好的数据分析师一定会有好奇心，会提问，会想问题，也能去解决问题。
我们最早期推的所有活动，都没有监控体系，整个运营也缺乏数据指导。对当时的我来说，很多运营的运作是黑箱。我不知道发什么了什么，怎么发生，只有一个结果输出。
别人若问我问什么，我只能做出假设，有可能一二三点。是否是这样，我也不知道。
运营活跃数上升，原因是什么？不知道。
短信推送后效果怎么样？不知道。
新注册用户来源有哪些？不知道。
那时随着公司业务线的拓展、用户数量提升。我用Excel做关联越来越吃力。我再一次向研发提数据需求时，CTO对我说：要不给你开个数据库权限，你自己查吧。
我告别了Excel，学习和了解数据库。从几张表的接触扩展到几百张表。
知道left join 和 inner join的区别。知道group by，知道数据结构，知道index。
那时期需要建立用户数据体系，包括留存、活跃、回流、分层等指标。我网上一边查运营指标的应用和解释，一边查SQL的实现。
和研发解释、沟通，因为了解数据库，很多需求以更合理的要求实现。这是我第一次开始接触、了解和建立以业务为核心的数据体系。
举一个例子：用户用过APP很长一段时间，我们管他叫忠诚用户，后来突然他连续几周不用，那么我们会通过SQL找出这类用户，分析他行为，电话访谈为什么不用，尝试唤回他。其他运营都是同理。
这时候，我才可以说我了解了活跃数，知道它为什么上升，为什么下降。
我们给不同用户推短信，借助SQL我能查询到数据的好坏，但是有没有更明确的指标？比如多少用户因为短信打开APP，短信打开率是多少？
当时短链用了url scheme，可以自动跳转到app，为了监控，我们也在短链中埋了参数。通过推送数据，观察这条短信会有多少人打开。
这是衡量一个文案的标准，好文案一定能触动用户打开。我们经常拿文案作为AB测试。举一个例子，我们会用短信营销，运营是和礼品挂钩的，当时有不少用户线上注册完并不下载APP，我们有那么一条针对此类的短信文案：
丨我们已经为您准备好了专属心意，XXXXX，请打开APP领取。
这条短信的打开率约在10%左右。但是还有优化空间，于是我不断修改文案，后续修改为：
丨既然您已经注册，为什么不来领取属于您的专属心意呢，XXXXX，请打开APP领取（中间内容不变）。
打开率被优化到18%。因为它用了营销心理，已经注册，契合了沉默成本的暗示：我做都做了，为什么不继续，不然白注册了。这种心理常见于旅游景点，景点很坑爹，但绝大多数人还是会说：既然来都来了，就是一种共通的心理。
后续短信又采取个性化方案，最终优化到25%。比最早期的文案效果好三倍左右。如果不好奇短信效果，如果不收集数据监控指标，那么优化无从谈起。我们可能凭感觉写出好文案，但你不知道具体效果，而数据能。
再来个例子，最开始我们借助微信朋友圈进行用户拉新，起初有多个渠道，但是我不知道哪个渠道效果好。然后我的好奇症又犯了，哪个渠道效果好？邀请转化率还能不能优化？渠道拉新成本是多少？
依旧是推动和落地数据分析的执行，因为微信的网页分享，会自动带from=timeline等参数，通过参数我能过滤出微信端浏览和访问的数据。后来又拜托研发针对不同渠道设置参数。通过参数统计转化率，并且给新用户打渠道来源标签。
期间发现一个渠道的转化率过低。我们大概分两类渠道，一个是落地页直接邀请用户注册，附加有礼品信息。一个是让用户先挑选礼品样式，最后领取步骤中跳到注册。通过转化率分析，后者的流失较为严重。因为步骤太冗余了，还有快递地址要填写，选取礼品的吸引力不足以支持用户走完流程。
于是便更改第二个渠道流程。不同注册渠道的用户来源，因为有标签，所以在后续新用户的运营中，可以有针对性地做措施。这也是短信通过个性化达到25%打开率的原因之一。
好奇是为了解决问题而服务的。通过不断的想问题，解决问题，数据分析相关的能力自然会提升。
幸运的是，好奇心能够后天锻炼，就是多问问题多想问题，锻炼难度不高。
非数据
零基础学习还会有另外一个问题，就是轻视业务的重要性。
实际上，想成为数据分析师，难点不在于Excel、SQL、统计等知识欠缺。而是业务知识的匮乏。
一个人懂业务不懂数据，另一个懂数据不懂业务，前者更有可能解决实际的问题。因为数据分析师始终是为业务而服务。
我曾向产品提出（没请吃饭）布置APP和Web埋点，通过用户的路径了解用户，也弥补网络统计的缺点。
当时通过Hadoop存储数据，使用Hive建立离线的脚本清洗、分区、加工。用户浏览产品的页面、使用的功能、停留的时间都能构成用户画像的基础。
我曾经很好奇什么是用户画像，因为网络上说用户的性别、地域、年龄、婚姻、财务、兴趣、偏好是构成用户画像的基础。但是我们的业务获取不到那么多数据。而我认为，用户画像是为了业务服务的，它不该有严格统一的标准。只要在业务上好用，就是好的用户画像。
就像在线视频的用户画像会收集电影的演员、上映时间、产地、语言、类型。还会细分到用户是否快进，是否拖拽。这些都是以业务为导向。甚至视频网站的分析师们本身就得阅片无数，才能根据业务分析。不然那么多电影类目和类型，如何细分各类指标？能通过拖拽快进去判断用户是否有兴趣，自身也得用过类似行为才能理解。
零基础怎么学习行业和业务知识？如果本身和业务接触，只是想做数据分析，难度小不少。如果像当初的我一样，既没有义务知识又不懂数据，也是可以的。
数据如果是假设性思维学习的话，那么业务应该是系统性思维学习。业务知识也需要一个目的和方向，但是和数据分析不同。业务注重的是系统性，系统性不是大而全，而是上而下的结构知识。先瞄准一个方向钻取深度，广度会随着深度的挖掘逐渐拓展。
比如你是一个外行，想学用户运营体系的分析，不要先考虑啥是用户运营，这问题太大。而是瞄准一个方向，例如活跃度，了解它的定义和含义，再想怎么应用。线下商场的活跃度如何定义，医院患者的活跃度如何定义，某个学校社团的活跃度如何？拿身边例子去思考活跃度。商场的活跃，可以是走来走去的人流，可以是进行消费购物的客流，可以是大包小包的土豪。什么因素会影响活跃？促销还是打折，节假日还是地理。等这些问题想通了，上手用户运营会很快。
再通过同样的思维去想留存、去想拉新。就会知道，如果商场的人流下次继续来消费，就是留存，有新客人来，就是拉新。这又有哪些因素互相影响？最后的知识思维一定是金字塔结构的。上层是用户运营，中间是拉新、活跃、留存。下层是各个要点和要素。
数据分析的学习注重演绎和推理，业务的学习注重关联和适用，学以致用就是说的这种情况。期间也会用到好奇心和假设，这两点都是加速学习的途径之一。
实际上说了这么多，对于零基础想当数据分析师的同学来说，可能仍旧有一些云山雾罩吧。这些软技能也不会助人一步登天的，其实的七周成为数据分析师，从最开始我也说过是入门的大纲。重要的是自己是否真的想学和学好，师傅领进门，修行靠个人，其他一切都是虚的。
想起很久以前看的一句鸡汤话，当你想要前行时，一切都会为你让路。我想这比我说的一切都更有力。
所以你问我零基础能成为数据分析师吗？我的回答是能。
文章其实有一些赶，最后祝大家圣诞快乐。
❹ 2019数据架构选型必读：1月数据库产品技术解析
本期目录
DB-Engines数据库排行榜
新闻快讯
一、RDBMS家族
二、NoSQL家族
三、NewSQL家族
四、时间序列
五、大数据生态圈
六、国产数据库概览
七、云数据库
八、推出dbaplus Newsletter的想法
九、感谢名单
为方便阅读、重点呈现，本期Newsletter（2019年1月）将对各个板块的内容进行精简。需要阅读全文的同学可点击文末 【阅读原文】 或登录https://pan..com/s/13BgipbaHeMfvm0YPtiYviA
DB-Engines数据库排行榜
以下取自2019年1月的数据，具体信息可以参考http://db-engines.com/en/ranking/，数据仅供参考。
DB-Engines排名的数据依据5个不同的因素：
新闻快讯
1、2018年9月24日，微软公布了SQL Server2019预览版，SQL Server 2019将结合Spark创建统一数据平台。
2、2018年10月5日，ElasticSearch在美国纽约证券交易所上市。
3、亚马逊放弃甲骨文数据库软件，导致最大仓库之一在黄金时段宕机。受此消息影响，亚马逊盘前股价小幅跳水，跌超2%。
4、2018年10月31日，Percona发布了Percona Server 8.0 RC版本，发布对MongoDB 4.0的支持，发布对XtraBackup测试第二个版本。
5、2018年10月31日，Gartner陆续发布了2018年的数据库系列报告，包括《数据库魔力象限》、《数据库核心能力》以及《数据库推荐报告》。
今年的总上榜数据库产品达到了5家，分别来自：阿里云，华为，巨杉数据库，腾讯云，星环 科技 。其中阿里云和巨杉数据库已经连续两年入选。
6、2018年11月初，Neo4j宣布完成E轮8000万美元融资。11月15日，Neo4j宣布企业版彻底闭源：
7、2019年1月8日，阿里巴巴以1.033亿美元（9000万欧元）的价格收购了Apache Flink商业公司DataArtisans。
8、2019年1月11日早间消息，亚马逊宣布推出云数据库软件，亚马逊和MongoDB将会直接竞争。
RDBMS家族
Oracle 发布18.3版本
2018年7月，Oracle Database 18.3通用版开始提供下载。我们可以将Oracle Database 18c视为采用之前发布模式的Oracle Database 12c第2版的第一个补丁集。未来，客户将不再需要等待多年才能用上最新版Oracle数据库，而是每年都可以期待新数据库特性和增强。Database 19c将于2019年Q1率先在Oracle cloud上发布云版本。
Oracle Database 18c及19c部分关键功能：
1、性能
2、多租户，大量功能增强及改进，大幅节省成本和提高敏捷性
3、高可用
4、数据仓库和大数据
MySQL发布8.0.13版本
1、账户管理
经过配置，修改密码时，必须带上原密码。在之前的版本，用户登录之后，就可以修改自己的密码。这种方式存在一定安全风险。比如用户登录上数据库后，中途离开一段时间，那么非法用户可能会修改密码。由参数password_require_current控制。
2、配置
Innodb表必须有主键。在用户没有指定主键时，系统会生成一个默认的主键。但是在主从复制的场景下，默认的主键，会对丛库应用速度带来致命的影响。如果设置sql_require_primary_key，那么数据库会强制用户在创建表、修改表时，加上主键。
3、字段默认值
BLOB、TEXT、GEOMETRY和JSON字段可以指定默认值了。
4、优化器
1）Skip Scan
非前缀索引也可以用了。
之前的版本，任何没有带上f1字段的查询，都没法使用索引。在新的版本中，它可以忽略前面的字段，让这个查询使用到索引。其实现原理就是把(f1 = 1 AND f2 > 40) 和(f1 = 2 AND f2 > 40)的查询结果合并。
2）函数索引
之前版本只能基于某个列或者多个列加索引，但是不允许在上面做计算，如今这个限制消除了。
5、SQL语法
GROUP BY ASC和GROUP BY DESC语法已经被废弃，要想达到类似的效果，请使用GROUP BY ORDER BY ASC和GROUP BY ORDER BY DESC。
6、功能变化
1）设置用户变量，请使用SET语句
如下类型语句将要被废弃SELECT @var, @var:=@var+1。
2）新增innodb_fsync_threshold
该变量是控制文件刷新到磁盘的速率，防止磁盘在短时间内饱和。
3）新增会话级临时表空间
在以往的版本中，当执行SQL时，产生的临时表都在全局表空间ibtmp1中，及时执行结束，临时表被释放，空间不会被回收。新版本中，会为session从临时表空间池中分配一个临时表空间，当连接断开时，临时表空间的磁盘空间被回收。
4）在线切换Group Replication的状态
5）新增了group_replication_member_expel_timeout
之前，如果某个节点被怀疑有问题，在5秒检测期结束之后，那么就直接被驱逐出这个集群。即使该节点恢复正常时，也不会再被加入集群。那么，瞬时的故障，会把某些节点驱逐出集群。
group_replication_member_expel_timeout让管理员能更好的依据自身的场景，做出最合适的配置（建议配置时间小于一个小时）。
MariaDB 10.3版本功能展示
1、MariaDB 10.3支持update多表ORDER BY and LIMIT
1）update连表更新，limit语句
update t1 join t2 on t1.id=t2.id set t1.name='hechunyang' limit 3;
MySQL 8.0直接报错
MariaDB 10.3更新成功
2）update连表更新，ORDER BY and LIMIT语句
update t1 join t2 on t1.id=t2.id set t1.name='HEchunyang' order by t1.id DESC limit 3;
MySQL 8.0直接报错
MariaDB 10.3更新成功
参考：
https://jira.mariadb.org/browse/MDEV-13911
2、MariaDB10.3增补AliSQL补丁——安全执行Online DDL
Online DDL从名字上看很容易误导新手，以为不论什么情况，修改表结构都不会锁表，理想很丰满，现实很骨感，注意这个坑！
有以下两种情况执行DDL操作会锁表的，Waiting for table metadata lock（元数据表锁）：
针对第二种情况，MariaDB10.3增补AliSQL补丁-DDL FAST FAIL，让其DDL操作快速失败。
例：
如果线上有某个慢SQL对该表进行操作，可以使用WAIT n（以秒为单位设置等待）或NOWAIT在语句中显式设置锁等待超时，在这种情况下，如果无法获取锁，语句将立即失败。 WAIT 0相当于NOWAIT。
参考：
https://jira.mariadb.org/browse/MDEV-11388
3、MariaDB Window Functions窗口函数分组取TOP N记录
窗口函数在MariaDB10.2版本里实现，其简化了复杂SQL的撰写，提高了可读性。
参考：
https://mariadb.com/kb/en/library/window-functions-overview/
Percona Server发布8.0 GA版本
2018年12月21日，Percona发布了Percona Server 8.0 GA版本。
在支持MySQL8.0社区的基础版上，Percona Server for MySQL 8.0版本中带来了许多新功能：
1、安全性和合规性
2、性能和可扩展性
3、可观察性和可用性
Percona Server for MySQL 8.0中将要被废用功能：
Percona Server for MySQL 8.0中删除的功能：
RocksDB发布V5.17.2版本
2018年10月24日，RocksDB发布V5.17.2版本。
RocksDB是Facebook在LevelDB基础上用C++写的高效内嵌式K/V存储引擎。相比LevelDB，RocksDB提供了Column-Family，TTL，Transaction，Merge等方面的支持。目前MyRocks，TiKV等底层的存储都是基于RocksDB来构建。
PostgreSQL发布11版本
2018年10月18日，PostgreSQL 11发布。
1、PostgreSQL 11的重大增强
2、PostgreSQL 插件动态
1）分布式插件citus发布 8.1
citus是PostgreSQL的一款sharding插件，目前国内苏宁、铁总、探探有较大量使用案例。
https://github.com/citusdata/citus
2）地理信息插件postgis发布2.5.1
PostGIS是专业的时空数据库插件，在测绘、航天、气象、地震、国土资源、地图等时空专业领域应用广泛。同时在互联网行业也得到了对GIS有性能、功能深度要求的客户青睐，比如共享出行、外卖等客户。
http://postgis.net/
3）时序插件timescale发布1.1.1
timescale是PostgreSQL的一款时序数据库插件，在IoT行业中有非常好的应用。github star数目前有5000多，是一个非常火爆的插件。
https://github.com/timescale/timescaledb
4）流计算插件 pipelinedb 正式插件化
Pipelinedb是PostgreSQL的一款流计算插件，使用这个创建可以对高速写入的数据进行实时根据定义的聚合规则进行聚合（支持概率计算），实时根据定义的规则触发事件（支持事件处理函数的自定义）。可用于IoT，监控，FEED实时计算等场景。
https://github.com/pipelinedb/pipelinedb
3、PostgreSQL衍生开源产品动态
1）agensgraph发布 2.0.0版本
agensgraph是兼容PostgreSQL、opencypher的专业图数据库，适合图式关系的管理。
https://github.com/bitnine-oss/agensgraph
2）gpdb发布5.15
gpdb是兼容PostgreSQL的mpp数据库，适合OLAP场景。近两年，gpdb一直在追赶PostgreSQL的社区版本，预计很快会追上10的PostgreSQL，在TP方面的性能也会得到显着提升。
https://github.com/greenplum-db/gpdb
3）antdb发布3.2
antdb是以Postgres-XC为基础开发的一款PostgreSQL sharding数据库，亚信主导开发，开源，目前主要服务于亚信自有客户。
https://github.com/ADBSQL/AntDB
4）迁移工具MTK发布52版本
MTK是EDB提供的可以将Oracle、PostgreSQL、MySQL、MSSQL、Sybase数据库迁移到PostgreSQL, PPAS的产品，迁移速度可以达到100万行/s以上。
https://github.com/digoal/blog/blob/master/201812/20181226_01.md
DB2发布 11.1.4.4版本
DB2最新发布Mod Pack 4 and Fix Pack 4，包含以下几方面的改动及增强：
1、性能
2、高可用
3、管理视图
4、应用开发方面
5、联邦功能
6、pureScale
NoSQL家族
Redis发布5.0.3版本
MongoDB升级更新MongoDB Mobile和MongoDB Stitch
2018年11月21日，MongoDB升级更新MongoDB Mobile和MongoDB Stitch，助力开发人员提升工作效率。
MongoDB 公司日前发布了多项新产品功能，旨在更好地帮助开发人员在世界各地管理数据。通过利用存储在移动设备和后台数据库的数据之间的实时、自动的同步特性，MongoDB Mobile通用版本助力开发人员构建更快捷、反应更迅速的应用程序。此前，这只能通过在移动应用内部安装一个可供选择或限定功能的数据库来实现。
MongoDB Mobile在为客户提供随处运行的自由度方面更进了一步。用户在iOS和安卓终端设备上可拥有MongoDB所有功能，将网络边界扩展到其物联网资产范畴。应用系统还可以使用MongoDB Stitch的软件开发包访问移动客户端或后台数据，帮助开发人员通过他们希望的任意方式查询移动终端数据和物联网数据，包括本地读写、本地JSON存储、索引和聚合。通过Stitch移动同步功能(现可提供beta版)，用户可以自动对保存在本地的数据以及后台数据库的数据进行同步。
本期新秀：Cassandra发布3.11.3版本
2018年8月11日，Cassandra发布正式版3.11.3。
Apache Cassandra是一款开源分布式NoSQL数据库系统，使用了基于Google BigTable的数据模型，与面向行(row)的传统关系型数据库或键值存储key-value数据库不同，Cassandra使用的是宽列存储模型(Wide Column Stores)。与BigTable和其模仿者HBase不同，数据并不存储在分布式文件系统如GFS或HDFS中，而是直接存于本地。
Cassandra的系统架构与Amazon DynamoDB类似，是基于一致性哈希的完全P2P架构，每行数据通过哈希来决定应该存在哪个或哪些节点中。集群没有master的概念，所有节点都是同样的角色，彻底避免了整个系统的单点问题导致的不稳定性，集群间的状态同步通过Gossip协议来进行P2P的通信。
3.11.3版本的一些bug fix和改进：
NewSQL家族
TiDB 发布2.1.2版本
2018 年 12 月 22 日，TiDB 发布 2.1.2 版，TiDB-Ansible 相应发布 2.1.2 版本。该版本在 2.1.1 版的基础上，对系统兼容性、稳定性做出了改进。
TiDB 是一款定位于在线事务处理/在线分析处理（ HTAP: Hybrid Transactional/Analytical Processing）的融合型数据库产品。除了底层的 RocksDB 存储引擎之外，分布式SQL层、分布式KV存储引擎（TiKV）完全自主设计和研发。
TiDB 完全开源，兼容MySQL协议和语法，可以简单理解为一个可以无限水平扩展的MySQL，并且提供分布式事务、跨节点 JOIN、吞吐和存储容量水平扩展、故障自恢复、高可用等优异的特性；对业务没有任何侵入性，简化开发，利于维护和平滑迁移。
TiDB：
PD：
TiKV：
Tools：
1）TiDB-Lightning
2）TiDB-Binlog
EsgynDB发布R2.5版本
2018年12月22日，EsgynDB R2.5版本正式发布。
作为企业级产品，EsgynDB 2.5向前迈进了一大步，它拥有以下功能和改进：
CockroachDB发布2.1版本
2018年10月30日，CockroachDB正式发布2.1版本，其新增特性如下：
新增企业级特性：
新增SQL特性：
新增内核特性：
Admin UI增强：
时间序列
本期新秀：TimescaleDB发布1.0版本
10月底，TimescaleDB 1.0宣布正式推出，官方表示该版本已可用于生产环境，支持完整SQL和扩展。
TimescaleDB是基于PostgreSQL数据库开发的一款时序数据库，以插件化的形式打包提供，随着PostgreSQL的版本升级而升级，不会因为另立分支带来麻烦。
TimescaleDB架构：
数据自动按时间和空间分片(chunk)
更新亮点：
https://github.com/timescale/timescaledb/releases/tag/1.0.0
大数据生态圈
Hadoop发布2.9.2版本
2018年11月中旬，Hadoop在2.9分支上发布了新的2.9.2版本，该版本进行了204个大大小小的变更，主要变更如下：
Greenplum 发布5.15版本
Greenplum最新的5.15版本中发布了流式数据加载工具。
该版本中的Greenplum Streem Server组件已经集成了Kafka流式加载功能，并通过了Confluent官方的集成认证，其支持的主要功能如下：
国产数据库概览
K-DB发布数据库一体机版
2018年11月7日，K-DB发布了数据库一体机版。该版本更新情况如下：
OceanBase迁移服务发布1.0版本
1月4日，OceanBase 正式发布OMS迁移服务1.0版本。
以下内容包含 OceanBase 迁移服务的重要特性和功能：
SequoiaDB发布3.0.1新版本
1、架构
1）完整计算存储分离架构，兼容MySQL协议、语法
计算存储分离体系以松耦合的方式将计算与存储层分别部署，通过标准接口或插件对各个模块和组件进行无缝替换，在计算层与存储层均可实现自由的弹性伸缩。
SequoiaDB巨杉数据库“计算-存储分离”架构详细示意
用户可以根据自身业务特征选择面向交易的SQL解析器（例如MySQL或PGSQL）或面向统计分析的执行引擎（例如SparkSQL）。众所周知，使用不同的SQL优化与执行方式，数据库的访问性能可能会存在上千上万倍的差距。计算存储分离的核心思想便是在数据存储层面进行一体化存储，在计算层面则利用每种执行引擎的特点针对不同业务场景进行选择和优化，用户可以在存储层进行逻辑与物理的隔离，将面向高频交易的前端业务与面向高吞吐量的统计分析使用不同的硬件进行存储，确保在多类型数据访问时互不干扰，以真正达到生产环境可用的多租户与HTAP能力。
2、其他更新信息
1）接口变更：
2）主要特性：
云数据库
本期新秀：腾讯发布数据库CynosDB，开启公测
1、News
1）腾讯云数据库MySQL2018年重大更新：
2）腾讯云数据库MongoDB2018年重大更新：
3）腾讯云数据库Redis/CKV+2018年重大更新：
4）腾讯云数据库CTSDB2018年重大更新：
2、Redis 4.0集群版商业化上线
2018年10月，腾讯云数据库Redis 4.0集群版完成邀测、公测、商业化三个迭代，在广州、上海、北京正式全量商业化上线。
产品特性：
使用场景：
官网文档：
https://cloud.tencent.com/document/proct/239/18336
3、腾讯自研数据库CynosDB发布，开启公测
2018年11月22日，腾讯云召开新一代自研数据库CynosDB发布会，业界第一款全面兼容市面上两大最主流的开源数据库MySQL和PostgreSQL的高性能企业级分布式云数据库。
本期新秀：京东云DRDS发布1.0版本
12月24日，京东云分布式关系型数据库DRDS正式发布1.0版本。
DRDS是京东云精心自研的数据库中间件产品，获得了2018年 ”可信云技术创新奖”。DRDS可实现海量数据下的自动分库分表，具有高性能，分布式，弹性升级，兼容MySQL等优点，适用于高并发、大规模数据的在线交易， 历史 数据查询，自动数据分片等业务场景，历经多次618，双十一的考验，已经在京东集团内大规模使用。
京东云DRDS产品有以下主要特性
1）自动分库分表
通过简单的定义即可自动实现分库分表，将数据实际存放在多个MySQL实例的数据库中，但呈现给应用程序的依旧是一张表，对业务透明，应用程序几乎无需改动，实现了对数据库存储和处理能力的水平扩展。
2）分布式架构
基于分布式架构的集群方案，多个对等节点同时对外提供服务，不但可有效规避服务的单点故障，而且更加容易扩展。
3）超强性能
具有极高的处理能力，双节点即可支持数万QPS，满足用户超大规模处理能力的需求。
4）兼容MySQL
兼容绝大部分MySQL语法，包括MySQL语法、数据类型、索引、常用函数、排序、关联等DDL，DML语句，使用成本低。
参考链接：
https://www.jdcloud.com/cn/procts/drds
RadonDB发布1.0.3版本
2018年12月26日，MyNewSQL领域的RadonDB云数据库发布1.0.3版本。
推出dbaplus Newsletter的想法
dbaplus Newsletter旨在向广大技术爱好者提供数据库行业的最新技术发展趋势，为社区的技术发展提供一个统一的发声平台。为此，我们策划了RDBMS、NoSQL、NewSQL、时间序列、大数据生态圈、国产数据库、云数据库等几个版块。
我们不以商业宣传为目的，不接受任何商业广告宣传，严格审查信息源的可信度和准确性，力争为大家提供一个纯净的技术学习环境，欢迎大家监督指正。
至于Newsletter发布的周期，目前计划是每三个月左右会做一次跟进， 下期计划时间是2019年4月14日~4月25日， 如果有相关的信息提供请发送至邮箱：[email protected]
感谢名单
最后要感谢那些提供宝贵信息和建议的专家朋友，排名不分先后。
往期回顾：
↓↓别忘了点这里下载 2019年1月 完整版Newsletter 哦~
❺ 基于spark地震数据分析的目的
从速度的角度看，Spark从流行的MapRece模型继承而来，可以更有效地支持多种类型的计算，如交互式查询和流处理。速度在大数据集的处理中非常重要，它可以决定用户可以交互式地处理数据，还是等几分钟甚至几小时。Spark为速度提供的一个重要特性是其可以在内存中运行计算，即使对基于磁盘的复杂应用，Spark依然比MapRece更有效。
从通用性来物老说，Spark可以处理之前需要多个独立的分布式系统来处理的任务，这些任务包括批处理应用、交互式算法、交互式查询和数据流。通过用同一个引擎支持这些任务，Spark使得合并不同的处理类型变得简单，而合并操作在生产数据分析中频繁使用。而且，Spark降低了维护不同工具的管理负担。
Spark被设计的高度易访问，用Python、Java、Scala和SQL提供简单的API，而且提供丰富的内建库。Spark也与其他大数据工具进行了集成。特别地，Spark可以运行在Hadoop的集群上，可以访问任何Hadoop的数据源，包括Cassandra。
Spark 核心组件
Spark核心组件包含Spark的基本功能，有任务调度组件、内存管理组件、容错恢复组件、与存储系统交互的组件等。Spark核心组件提供了定义弹性分布式数据集(resilient distributed datasets，RDDs)的API，这组API是Spark主要的编程抽象。RDDs表示分布在多个不同机器节点上，可以被并行处理的数据集合。Spark核心组件提供许多API来创建和操作这些集合。
Spark SQLSpark SQL是Spark用来处理结构化数据的包。它使得可以像Hive查询语言(Hive Query Language, HQL)一样通过SQL语句来查询数据，支持多种数据源，包括Hive表、Parquet和JSON。除了为Spark提供一个SQL接口外，Spark SQL允许开发人员将SQL查询和由RDDs通过Python、Java和Scala支持的数据编程操作混合进一个单一的应用中，进而将SQL与复杂的分析结合。与计算密集型环境紧密集成使得Spark SQL不同于任何其他开源的数据仓库工具。Spark SQL在Spark 1.0版本中引入Spark。
Shark是一个较老的由加利福尼亚大学和伯克利大学开发的Spark上的SQL项目，通过修裂芹改Hive而运行在Spark上。现在已经被Spark SQL取代，以提供与Spark引擎和API更好的集成。
Spark流(Spark Streaming)Spark流作为Spark的一个组件，可以处理实时流数据。流数据的例子有生产环境的Web服务器生成的日志文件，用户向一个Web服务请求包含状态更新的消息。Spark流提供一个和Spark核心RDD API非常匹配的操作数据流的API，使得编程人员可以更容易地了解项目，并且可以在操作内存数据、磁盘数据、实时数据的应用之间快速切换。Spark流被设计为和Spark核心组件提供相同级别的容错性，吞吐量和可伸缩性。
MLlibSpark包含一个叫做MLlib的关于机器学习的库。MLlib提供多种类型的机器学习算法，包括分类、回归、聚类和协同过滤，并支持模型评估和数据导入功能。MLlib也提供一个低层的机器学习原语，包括一个通用的梯度下降优化算法。所有这些方法都可以应用到一个集群上。
GraphXGraphX是一个操作图(如社交网络的好友图)和执行基于图的并行计算的库。与Spark流和Spark SQL类似，GraphX扩展了Spark RDD API，允许我们用和每个罩源升节点和边绑定的任意属性来创建一个有向图。GraphX也提供了各种各样的操作图的操作符，以及关于通用图算法的一个库。
集群管理器Cluster Managers在底层，Spark可以有效地从一个计算节点扩展到成百上千个节点。为了在最大化灵活性的同时达到这个目标，Spark可以运行在多个集群管理器上，包括Hadoop YARN，Apache Mesos和一个包含在Spark中的叫做独立调度器的简易的集群管理器。如果你在一个空的机器群上安装Spark，独立调度器提供一个简单的方式;如果你已经有一个Hadoop YARN或Mesos集群，Spark支持你的应用允许在这些集群管理器上。第七章给出了不同的选择，以及如何选择正确的集群管理器。
谁使用Spark?用Spark做什么?
由于Spark是一个面向集群计算的通用框架，可用于许多不同的应用。使用者主要有两种：数据科学家和数据工程师。我们仔细地分析一下这两种人和他们使用Spark的方式。明显地，典型的使用案例是不同的，但我们可以将他们粗略地分为两类，数据科学和数据应用。
数据科学的任务数据科学，近几年出现的一门学科，专注于分析数据。尽管没有一个标准的定义，我们认为一个数据科学家的主要工作是分析和建模数据。数据科学家可能会SQL，统计学，预测模型(机器学习)，用Python、MATLAB或R编程。数据科学家能将数据格式化，用于进一步的分析。
数据科学家为了回答一个问题或进行深入研究，会使用相关的技术分析数据。通常，他们的工作包含特殊的分析，所以他们使用交互式shell，以使得他们能在最短的时间内看到查询结果和代码片段。Spark的速度和简单的API接口很好地符合这个目标，它的内建库意味着很多算法可以随时使用。
Spark通过若干组件支持不同的数据科学任务。Spark shell使得用Python或Scala进行交互式数据分析变得简单。Spark SQL也有一个独立的SQL shell，已经为大家精心准备了大数据的系统学习资料，从Linux-Hadoop-spark-......，需要的小伙伴可以点击它可以用SQL进行数据分析，也可以在Spark程序中或Spark shell中使用Spark SQL。MLlib库支持机器学习和数据分析。而且，支持调用外部的MATLAB或R语言编写的程序。Spark使得数据科学家可以用R或Pandas等工具处理包含大量数据的问题。
❻ 以道教育大数据课程都讲什么
1、web开发基础
2、javase课程
3、主流的框架
4、关系型数据库/MySQL/NoSQL
5、操作系统/Linux、云架构仿备橡
6、Hadoop生态滚肢系统
7、Spark生态系统
8、Storm生态系备旁统
9、项目实操阶段
❼ 大数据培训课程安排有哪些，深圳大数据培训哪家好
首先我们要了解Java语言和Linux操作系统，这两个是学习大数据的基础，学习的顺序不分前后。
大数据
Java ：只要了解一些基础即可，做大数据不需要很深的Java 技术，学java SE 就相当于有学习大数据基础。
Linux：因为大数据相关软件都是在Linux上运行的，所以Linux要学习的扎实一些，学好Linux对你快速掌握大数据相关技术会有很大的帮助，能让你更好的理解hadoop、hive、hbase、spark等大数据软件的运行环境和网络环境配置，能少踩很多坑，学会shell就能看懂脚本这样能更容易理解和配置大数据集群。还能让你对以后新出的大数据技术学习起来更快。
Hadoop：这是现在流行的大数据处理平台几乎已经成为大数据的代名词，所以这个是必学的。Hadoop里面包括几个组件HDFS、MapRece和YARN，HDFS是存储数据的地方就像我们电脑的硬盘一样文件都存储在这个上面，MapRece是对数据进行处理计算的，它有个特点就是不管多大的数据只要给它时间它就能把数据跑完，但是时间可能不是很快所以它叫数据的批处理。
Zookeeper：这是个万金油，安装Hadoop的HA的时候就会用到它，以后的Hbase也会用到它。它一般用来存放一些相互协作的信息，这些信息比较小一般不会超过1M，都是使用它的软件对它有依赖，对于我们个人来讲只需要把它安装正确，让它正常的run起来就可以了。
Mysql：我们学习完大数据的处理了，接下来学习学习小数据的处理工具mysql数据库，因为一会装hive的时候要用到，mysql需要掌握到什么层度那?你能在Linux上把它安装好，运行起来，会配置简单的权限，修改root的密码，创建数据库。这里主要的是学习SQL的语法，因为hive的语法和这个非常相似。
Sqoop：这个是用于把Mysql里的数据导入到Hadoop里的。当然你也可以不用这个，直接把Mysql数据表导出成文件再放到HDFS上也是一样的，当然生产环境中使用要注意Mysql的压力。
Hive：这个东西对于会SQL语法的来说就是神器，它能让你处理大数据变的很简单，不会再费劲的编写MapRece程序。有的人说Pig那?它和Pig差不多掌握一个就可以了。
Oozie：既然学会Hive了，我相信你一定需要这个东西，它可以帮你管理你的Hive或者MapRece、Spark脚本，还能检查你的程序是否执行正确，出错了给你发报警并能帮你重试程序，最重要的是还能帮你配置任务的依赖关系。我相信你一定会喜欢上它的，不然你看着那一大堆脚本，和密密麻麻的crond是不是有种想屎的感觉。
Hbase：这是Hadoop生态体系中的NOSQL数据库，他的数据是按照key和value的形式存储的并且key是唯一的，所以它能用来做数据的排重，它与MYSQL相比能存储的数据量大很多。所以他常被用于大数据处理完成之后的存储目的地。
Kafka：这是个比较好用的队列工具，队列是干吗的?排队买票你知道不?数据多了同样也需要排队处理，这样与你协作的其它同学不会叫起来，你干吗给我这么多的数据(比如好几百G的文件)我怎么处理得过来，你别怪他因为他不是搞大数据的，你可以跟他讲我把数据放在队列里你使用的时候一个个拿，这样他就不在抱怨了马上灰流流的去优化他的程序去了，因为处理不过来就是他的事情。而不是你给的问题。当然我们也可以利用这个工具来做线上实时数据的入库或入HDFS，这时你可以与一个叫Flume的工具配合使用，它是专门用来提供对数据进行简单处理，并写到各种数据接受方(比如Kafka)的。
Spark：它是用来弥补基于MapRece处理数据速度上的缺点，它的特点是把数据装载到内存中计算而不是去读慢的要死进化还特别慢的硬盘。特别适合做迭代运算，所以算法流们特别稀饭它。它是用scala编写的。Java语言或者Scala都可以操作它，因为它们都是用JVM的。
❽ Spark RDD，DataFrame和DataSet的区别
RDD、DataFrame和DataSet是容易产生混淆的概念，必须对其相互之间对比，才可以知道其中异同。
RDD和DataFrame
RDD-DataFrame
上图直观地体现了DataFrame和RDD的区别。左侧的RDD[Person]虽然以Person为类型参数，但Spark框架本身不了解
Person类的内部结构。而右侧的DataFrame却提供了详细的结构信息，使得Spark
SQL可以清楚地知道该数据集中包含哪些列，每列的名称和类型各是什么。DataFrame多了数据的结构信息，即schema。RDD是分布式的
Java对象的集合。DataFrame是分布式的Row对象的集合。DataFrame除了提供了比RDD更丰富的算子以外，更重要的特点是提升执行效
率、减少数据读取以及执行计划的优化，比如filter下推、裁剪等。
提升执行效率
RDD
API是函数式的，强调不变性，在大部分场景下倾向于创建新对象而不是修改老对象。这一特点虽然带来了干净整洁的API，却也使得Spark应用程序在运
行期倾向于创建大量临时对象，对GC造成压力。在现有RDD
API的基础之上，我们固然可以利用mapPartitions方法来重载RDD单个分片内的数据创建方式，用复用可变对象的方式来减小对象分配和GC的
开销，但这牺牲了代码的可读性，而且要求开发者对Spark运行时机制有一定的了解，门槛较高。另一方面，Spark
SQL在框架内部已经在各种可能的情况下尽量重用对象，这样做虽然在内部会打破了不变性，但在将数据返回给用户时，还会重新转为不可变数据。利用
DataFrame API进行开发，可以免费地享受到这些优化效果。
减少数据读取
分析大数据，最快的方法就是 ——忽略它。这里的“忽略”并不是熟视无睹，而是根据查询条件进行恰当的剪枝。
上文讨论分区表时提到的分区剪 枝便是其中一种——当查询的过滤条件中涉及到分区列时，我们可以根据查询条件剪掉肯定不包含目标数据的分区目录，从而减少IO。
对于一些“智能”数据格 式，Spark
SQL还可以根据数据文件中附带的统计信息来进行剪枝。简单来说，在这类数据格式中，数据是分段保存的，每段数据都带有最大值、最小值、null值数量等
一些基本的统计信息。当统计信息表名某一数据段肯定不包括符合查询条件的目标数据时，该数据段就可以直接跳过(例如某整数列a某段的最大值为100，而查
询条件要求a > 200)。
此外，Spark SQL也可以充分利用RCFile、ORC、Parquet等列式存储格式的优势，仅扫描查询真正涉及的列，忽略其余列的数据。
执行优化
人口数据分析示例
为了说明查询优化，我们来看上图展示的人口数据分析的示例。图中构造了两个DataFrame，将它们join之后又做了一次filter操作。如
果原封不动地执行这个执行计划，最终的执行效率是不高的。因为join是一个代价较大的操作，也可能会产生一个较大的数据集。如果我们能将filter
下推到 join下方，先对DataFrame进行过滤，再join过滤后的较小的结果集，便可以有效缩短执行时间。而Spark
SQL的查询优化器正是这样做的。简而言之，逻辑查询计划优化就是一个利用基于关系代数的等价变换，将高成本的操作替换为低成本操作的过程。
得到的优化执行计划在转换成物 理执行计划的过程中，还可以根据具体的数据源的特性将过滤条件下推至数据源内。最右侧的物理执行计划中Filter之所以消失不见，就是因为溶入了用于执行最终的读取操作的表扫描节点内。
对于普通开发者而言，查询优化 器的意义在于，即便是经验并不丰富的程序员写出的次优的查询，也可以被尽量转换为高效的形式予以执行。
RDD和DataSet
DataSet以Catalyst逻辑执行计划表示，并且数据以编码的二进制形式被存储，不需要反序列化就可以执行sorting、shuffle等操作。
DataSet创立需要一个显式的Encoder，把对象序列化为二进制，可以把对象的scheme映射为SparkSQl类型，然而RDD依赖于运行时反射机制。
通过上面两点，DataSet的性能比RDD的要好很多。
DataFrame和DataSet
Dataset可以认为是DataFrame的一个特例，主要区别是Dataset每一个record存储的是一个强类型值而不是一个Row。因此具有如下三个特点：
DataSet可以在编译时检查类型
并且是面向对象的编程接口。用wordcount举例：
//DataFrame
// Load a text file and interpret each line as a java.lang.String
val ds = sqlContext.read.text("/home/spark/1.6/lines").as[String]
val result = ds
.flatMap(_.split(" ")) // Split on whitespace
.filter(_ != "") // Filter empty words
.toDF() // Convert to DataFrame to perform aggregation / sorting
.groupBy($"value") // Count number of occurences of each word
.agg(count("*") as "numOccurances")
.orderBy($"numOccurances" desc) // Show most common words first
后面版本DataFrame会继承DataSet，DataFrame是面向Spark SQL的接口。
//DataSet,完全使用scala编程，不要切换到DataFrame
val wordCount =
ds.flatMap(_.split(" "))
.filter(_ != "")
.groupBy(_.toLowerCase()) // Instead of grouping on a column expression (i.e. $"value") we pass a lambda function
.count()
DataFrame和DataSet可以相互转化， df.as[ElementType] 这样可以把DataFrame转化为DataSet， ds.toDF() 这样可以把DataSet转化为DataFrame。
❾ 技术选型 - OLAP大数据技术哪家强
Lambda架构的核心理念是“流批一体化”，因为随着机器性能和数据框架的不断完善，用户其实不关心底层是如何运行的，批处理也好，流式处理也罢，能按照统一的模型返回结果就可以了，这就是Lambda架构诞生的原因。现在很多应用，例如Spark和Flink，都支持这种结构，也就是数据进入平台后，可以选择批处理运行，也可以选择流式处理运行，但不管怎样，一致性都是相同的。
Kylin
Kylin的主要特点是预计算，提前计算好各个cube，这样的优点是查询快速，秒级延迟；缺点也非常明显，灵活性不足，无法做一些 探索 式的，关联性的数据分析。
适合的场景也是比较固定的，场景清晰的地方。
ClickHouse
Clickhouse由俄罗斯yandex公司开发。专为在线数据分析而设计。
Clickhouse最大的特点首先是快 ，为了快采用了列式储存，列式储存更好的支持压缩，压缩后的数据传输量变小，所以更快；同时支持分片，支持分布式执行，支持SQL。
ClickHouse很轻量级，支持数据压缩和最终数据一致性，其数据量级在PB级别。
另外Clickhouse不是为关联分析而生，所以多表关联支持的不太好。
同样Clickhouse不能修改或者删除数据，仅能用于批量删除或修改。没有完整的事务支持，不支持二级索引等等，缺点也非常明显。
与Kylin相比ClickHouse更加的灵活，sql支持的更好，但是相比Kylin，ClickHouse不支持大并发，也就是不能很多访问同时在线。
总之ClickHouse用于在线数据分析，支持功能简单。CPU 利用率高，速度极快。最好的场景用于行为统计分析。
Hive
Hive这个工具，大家一定很熟悉，大数据仓库的首选工具。可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能。
主要功能是可以将sql语句转换为相对应的MapRece任务进行运行，这样可能处理海量的数据批量，
Hive与HDFS结合紧密，在大数据开始初期，提供一种直接使用sql就能访问HDFS的方案，摆脱了写MapRece任务的方式，极大的降低了大数据的门槛。
当然Hive的缺点非常明显，定义的是分钟级别的查询延迟，估计都是在比较理想的情况。 但是作为数据仓库的每日批量工具，的确是一个稳定合格的产品。
Presto
Presto极大的改进了Hive的查询速度，而且Presto 本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询，支持包括复杂查询、聚合、连接等等。
Presto没有使用MapRece，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。
Presto由于是基于内存的，缺点可能是多张大表关联操作时易引起内存溢出错误。
另外Presto不支持OLTP的场景，所以不要把Presto当做数据库来使用。
Presto相比ClickHouse优点主要是多表join效果好。相比ClickHouse的支持功能简单，场景支持单一，Presto支持复杂的查询，应用范围更广。
Impala
Impala是Cloudera 公司推出，提供对 HDFS、Hbase 数据的高性能、低延迟的交互式 SQL 查询功能。
Impala 使用 Hive的元数据, 完全在内存中计算。是CDH 平台首选的 PB 级大数据实时查询分析引擎。
Impala 的缺点也很明显，首先严重依赖Hive，而且稳定性也稍差，元数据需要单独的mysql/pgsql来存储，对数据源的支持比较少，很多nosql是不支持的。但是，估计是cloudera的国内市场推广做的不错，Impala在国内的市场不错。
SparkSQL
SparkSQL的前身是Shark，它将 SQL 查询与 Spark 程序无缝集成，可以将结构化数据作为 Spark 的 RDD 进行查询。
SparkSQL后续不再受限于Hive，只是兼容Hive。
SparkSQL提供了sql访问和API访问的接口。
支持访问各式各样的数据源，包括Hive, Avro, Parquet, ORC, JSON, and JDBC。
Drill
Drill好像国内使用的很少，根据定义，Drill是一个低延迟的分布式海量数据交互式查询引擎，支持多种数据源，包括hadoop，NoSQL存储等等。
除了支持多种的数据源，Drill跟BI工具集成比较好。
Druid
Druid是专为海量数据集上的做高性能 OLAP而设计的数据存储和分析系统。
Druid 的架构是 Lambda 架构，分成实时层和批处理层。
Druid的核心设计结合了数据仓库，时间序列数据库和搜索系统的思想，以创建一个统一的系统，用于针对各种用例的实时分析。Druid将这三个系统中每个系统的关键特征合并到其接收层，存储格式，查询层和核心体系结构中。
目前 Druid 的去重都是非精确的，Druid 适合处理星型模型的数据，不支持关联操作。也不支持数据的更新。
Druid最大的优点还是支持实时与查询功能，解约了很多开发工作。
Ku
ku是一套完全独立的分布式存储引擎，很多设计概念上借鉴了HBase，但是又跟HBase不同，不需要HDFS，通过raft做数据复制；分片策略支持keyrange和hash等多种。
数据格式在parquet基础上做了些修改，支持二级索引，更像一个列式存储，而不是HBase schema-free的kv方式。
ku也是cloudera主导的项目，跟Impala结合比较好，通过impala可以支持update操作。
ku相对于原有parquet和ORC格式主要还是做增量更新的。
Hbase
Hbase使用的很广,更多的是作为一个KV数据库来使用，查询的速度很快。
Hawq
Hawq是一个Hadoop原生大规模并行SQL分析引擎，Hawq采用 MPP 架构，改进了针对 Hadoop 的基于成本的查询优化器。
除了能高效处理本身的内部数据，还可通过 PXF 访问 HDFS、Hive、HBase、JSON 等外部数据源。HAWQ全面兼容 SQL 标准，还可用 SQL 完成简单的数据挖掘和机器学习。无论是功能特性，还是性能表现，HAWQ 都比较适用于构建 Hadoop 分析型数据仓库应用。