互联网大数据架构最佳实践.docx

互联网大数据架构最佳实践DBAplus社群微信号 dbaplus功能介绍 围绕数据库、大数据、PaaS云，顶级大咖、技术干货，运营几个月受众过十万！成为运维圈最专注围绕“数据”的学习交流和专业社群！欢迎投稿，加入探讨。主题简介：数据平台技术选型用户交互实践大数据团队能力建设现如今大数据一块有很多的开源项目，因此首先搭建平台的难点其实在于如何选择一个合适的技术来做整个平台的架构，第二，因为有业务数据，用了平台之后的话，如何用平台把数据分析出来让用户有很好的交互性的体验。第三个层面就是理工科喜欢建模，而在这整个过程当中，我们会形成一种非数据建模，而主要是我们如何分不同层面的人员搭配，进而做成这样一个大数据团队。一、数据平台技术选型1、整体框架这个框架应该是一种大路货，或者更认为是一种比较常见的架构。前面也就是从数据源到消息队列到数据的清理、数据呈现等这些大家容易想到的东西，而在这样一个大帽子下面，所不一样的东西是具体选用什么样的组件来填这个空，在不同的场景下，每个人的选择是不大相同的。像消息队列这一层，我们选用了Kafka，这是目前大家普遍用到的，因为它有高吞吐量，采用Push和Pull结合的方式，消费端主动拉取数据。ETL这块，目前大家都希望采用一种可以自定义的方式，一般来说比较流行的是用LinkedIn提供的Camus来做从Kafka到HDFS的数据同步。这应该是一种较为流行的架构。那么放到HDFS上面的数据，基本上是为了批处理做准备的，那么在批处理分析的时候，我们选择一个什么样的分析引擎，可能就是一个值得争议的焦点，也就是说，也许在这个分析引擎的下面，有Hive，有Spark，有Presto，有Impala，还有其它的东西。 在这些引擎当中的选择或者实践，需要结合具体使用场景。下面讲讲为什么会选择Presto而不是其它。假设在座的各位有Presto使用经验的话，会发觉Presto它是一个CLI的用户界面，并没有好的一种Web UI，对一般用户来说，CLI的使用会有难度，不管这是感觉上的还是实际上的，所以需要有个好的Web UI来增加易用性。当前在GitHub上面能找到的Presto webui的就是Airbnb提供的AirPal，但根据我们的使用经验，不怎么友好，特别在UTC的时间设置上，同时它的社区维护已停滞在两年前，这一块我们做了适配，然后用Presto的StatementClient做了Web UI。前端采用的是jquery的easyui, 像刚才讲的批处理这一条线，就是用在了批处理这一块上。下面这一条线就是说有些数据可能是希望立马存储，立即被搜索到，或者做简要的分析。作为搜索引擎，社区这一块，大家耳熟能详的应该是Elasticsearch，Elasticsearch的社区非常活跃，而且它的推广速度，应用型上面易都很好。但是Elasticsearch的难点在于如何对它进行好的维护，后面我会讲到它可能存在的维护痛点。那么，Elasticsearch有非常强大的搜索能力，响应时间也是非常快的，但是它的用户接口，有自己的一套基于Lucene的搜索语法，当然Lucene的这一套语法本身是非常极客的，很简洁，但是一般的人不愿意去学这个东西，因为对于分析师来讲去学，就意味着以前的武功，几十年功夫白费了。于是我们就采用了一个插件Elastisearch-SQL，这样就可以采用SQL语句对Elasticsearch进行点查询或者范围查询。而且在Elasticsearch的演进路径当中，也会支持SQL，按照之前看到的ES roadmap, 应该在17年最迟不超过18年发布6.×，重要的特性之一是对SQL的支持，大家可以看到如果不支持SQL，就等于是自废武功，或者拒客户于千里之外。?Web UI是人机交互的部分，我们会进行Ad-hoc查询，但在整个部门当中有不少程序希望调用查询，也就是应用的接口，采用SOA的架构，我们自己开发实现了 BigQuery API，可以通过这种调Restful 接口方式，进行取数或者分析。那么我们会自动判别到底是到ES这一侧还是到Presto进行取数。在很多公司的使用当中，数据分析这一块是需要报表的，就是要有很好的Dashboard。2、ETL PipeLine -- Gobblin这个是ETL相对比较细节的一些东西。快速过一下这个图。在ETL的时间当中，比如说为什么不直接用像Spark或者流的方式，最常见的问题就是小文件的问题，到时候需要清理合并小文件，这很麻烦。如果采用Zeus去调度，然后设定一定数目的Partition，就有一个Map Task对应，尽可能的写满一个Block，以64M或者128M为主。在存储的时候我们除了考虑它的大小之外，存储格式的选择也应该是必须考量的范围。从我们当前的选择来看，建议使