[.com原稿]经过多年发展，从大数据1.0的BI/Datawarehouse时代到Web/App过渡期大数据2.0，然后进入物联网大数据3.0时代，随之而来的是数据架构的变革。2018年5月18-19日，由主办方主办的全球软件与运维技术峰会在北京召开。在“大数据处理技术”环节，易观智库CTO郭伟先生为我们做了主题演讲《Lambda架构已死，新一代的去ELT化IOTA架构》。他从Lambda和Kappa架构的发展历程和优缺点入手，分享了IOTA大数据架构的思路、优缺点，以及易观在IOTA架构领域的实践经验。IOTA架构背景首先介绍一下我们遇到的各种数据问题以及提出IOTA架构的背景。我们的数据来自手机的SDK。上图是易观目前的数据规模。现在月活跃用户数已达5.5亿，其中包括超过20亿的用户画像（Profiles），并在各个维度被“贴上标签”。那么面对如此多维度的数据量和层出不穷的新数据，如何支撑各种数据的运行呢？我们先来了解一下IOTA架构的背景。上图右侧是易观这两年搭建的大数据架构，底层是SDK收集各种数据的过程。由于每天有数百亿的数据，我们在SDK上采用“云+端”的管控策略，避免底层SDK成为导流层。目前我们最多使用6GB的接收带宽。当并发数据传输到我们的接收端时，可能会出现几GB以上的流量爆炸，所以我们必须避免这种类似DDoS的情况。在底层，我们基于Kafka定制了各种内部队列和分发。同时我们实现了多方HDFS查询，并在此基础上构建了Hive进行批量查询。对于各种前端产品，我们使用Greenplum来实现Ad-hoc查询。同时，我们使用Presto来满足内部分析师的各种查询需求。图中右侧是一些内部数据治理服务，包括源数据的管理、数据口径和质量的检测，以及左侧绿色的各种调度服务。以上是我们这两年搭建的内部大数据结构。当然，我们也遇到了以下问题：现在物联网时代已经到来，各种智能硬件设备也相继问世，包括智能手环、医用糖尿病筛查设备、智能WiFi、BCON和智能摄像头等。随着数据越来越复杂，简单的移动客户端已经不能满足我们收集和分析数据的需求。随着物联网设备的出现，产生的海量数据，其采集频率远高于人工点击，这给整个架构带来了更大的挑战。数据格式不统一。例如，云摄像机的数据格式可能与其他制造商的物联网摄像机的数据格式不同。更改数据格式将导致业务查询频繁更改。我们在Analysys的70多位分析师每天都需要不同类型的数据。需要实时查询数据。以转化查询为例：某公司想查询其前一小时的广告投放效果，以及双十一促销期间价格波动对用户最佳购买的影响。这些都是临时查询。Lambda架构让我们回顾一下Lambda架构。今天80%到90%的企业都在用Lambda架构做自己的大数据分析，包括我们自己从Lambda架构转型过来的。如图所示，所有数据采集均从最左侧进入架构。根据不同的SDK，各种数据源采集的数据格式会有所不同。他们在这里汇聚到我们的云端大数据平台。我们用两条线来保证数据的实时性和有效性：通过传统的ETL，我们将数据做成批任务——BatchData，每晚运行一次，第二天早上查看相关数据结果。为了保证采集的实时性，比如需要根据销量做出智能推荐决策，或者查看当天的PV/UV，那么我们就会“跑”一些DataStreaming（数据流）。上面两行的结果最终都放入了一个ResultDatabase（结果数据库，比如某一个MySQL），方便我们前端应用通过这个数据库查询后端数据。但是这种架构存在以下问题：1.业务端会发现第二天看到的数据比昨晚看到的少。原因是：当数据放入ResultDatabase时，有两行计算：一行是ETL按照一定的口径“跑”，得到更准确的批处理结果；另一行是“通过Streaming”Run”过来，依赖HadoopHive或者其他算法的实时结果。当然牺牲了一些精度。可以看出批处理和实时这两种数据结果是不兼容的，所以大家觉得很迷茫。2.每一个实时分析需求，都需要用DataStreaming重新开发。无论你使用Storm、SparkStreaming还是Flink，只要你想查看某个结果，就必须开发流式计算。也就是说，我们要按需做各种ETL开发，显然效率不高。3、我们数据清洗的目的是为了得到更好的数据格式，然后放到大数据平台上。但是由于平台需要通过处理来适应不同的采集格式，我们无法快速呈现不同领域的实时数据。KAPPAArchitecture后来LinkedIn提出了一个新的架构：KAPPA。它的思路是：既然大家都觉得batchdata和real-timedata不匹配是个问题，就直接去掉batchdata；并直接通过队列放入实时数据。比如：把所有的数据直接放到原来的Kafka里面，然后用Kafka的Streaming直接面对***查询结果。当然这个架构也存在一些问题：1.不能及时查询和训练。举个例子：我们的分析师想通过一条SQL查询前五秒的状态数据。这对于KAPPA架构来说很难实现。2、面对各种需求，也逃不过每次都需要重新做DataStreaming。也就是说，它不能实现Ad-hocquery，我们必须针对某种需求提前做好准备，才能进行数据分析。3.新数据源的结构问题。比如：增加一个新的智能硬件设备，我们需要重新开发它对应的适配格式，负责采集的SDK，SDK的接收端等等，也就是要重新进行整体开发。因此，尽管KAPPA架构比Lambda更好，不需要对ETL数据进行两次实时处理，但它仍然存在结构问题。IOTA架构至此，我们提出了IOTA架构。在命名方面，它是根据希腊字母的顺序，即：从IOTA，到KAPPA，再到Lambda。我们先来看看IOTA架构的基本思路。由于大家不仅要支持实时数据、Ad-hoc查询，还要支持各种数据的适配，所以这个架构中肯定有一些“约束”。第一个约束：我们应该提前确定公共数据模型（CommonDataModel）。例如：我们在分析用户行为时，可以用一个“主谓宾”模型来描述：“谁做了什么，做了什么”。其余修饰符可用作其他列和参数。基于这种模式，所有的数据都不是集中处理，而是在初始SDK端进行操作。这里可以引入边缘计算的概念，即不再在云端处理数据，而是将所有数据分散到数据生成到最终存储的整个过程中。另外，由于一般公司的业务不会每天都在变化，我们可以抽象出一套完整的业务模型，然后在边缘而不是在云端实现数据统一。上图中提到的通用数据模型示例。我们可以使用“主-谓-宾”模型，即“X用户-事件1-页面A（2018/4/1120:00）”进行抽象。当然，我们也可以根据不同的业务需求，采用“产品-事件”或者“地点-时间”的模式。第二个约束：对于同一个硬件设备，我们完全可以将“X用户的MAC地址-外观-A层（2018/4/1118:00）”模型与前面提到的“主谓-Bin”模型统一起来换句话说，无论是App小程序、网页、摄像头，还是IoT智能WiFi，只要数据模型统一，就可以在数据生成端统一整体的数据格式。第三个约束条件：由于云端的数据只负责存储和查询，不再负责处理，因此在IOTA架构中，主要有以下几个组件：RealTimeDataCache，针对海量的实时数据，我们将存储在云端，但是直接导入数据库会有延迟，所以我们需要使用Hbase或者像Kudu这样的Components来实现简单的列式存储HistoricalData针对大量历史数据的底层存储.我们可以在云端使用HDFS.r的原因实时数据不直接连接到HDFS是为了避免产生大量的碎片文件，影响最终的查询效率。Dumper，该程序实现连接从RealTimeDataCache到数据的存储。我们可以把RealTimeDataCache按照既定的规则（每五分钟一次，或者百万条数据时）“落”到HDFS文件中。同时我们也可以添加相关的索引，为后面的QueryEngine做准备。QueryEngine，它可以使用的计算引擎包括：Spark、Presto、Impala等。通过QueryEngine，我们不仅可以查询存储在HDFS中的底层数据，还可以查询几分钟前的实时数据。此外，通过两者的结合，分析师还可以实现智能分析。因此，基本流程是：底层SDK先统一数据的格式，然后先存入Cache，再放入HistoricalData。在查询的时候，我们可以对外暴露一个SQL接口（比如Presto或者SparkSQL），供分析人员直接查看几秒前的各种数据状态。例如：我们可以使用QueryEngine来查询：用户最终是如何从登录页面点击到购买页面的，他们经历的智能路径以及触发的事件等等，这一系列上下文相关的数据都可以展示出来实时，甚至包括一些临时查询。综上所述，我们回顾一下上面提到的重要方面：公共数据模型非常重要，它贯穿于整个业务，从SDK的生成到最终的入库和按需查询。当然如果model本身不能固定，我们可以先在SDK中使用Protobuf定义一个model。在协议架构的基础上，如果后面的需求是固定的，我们只要从底层到顶层维护一个统一的模型，修改起来会很方便，甚至不会涉及到云存储的变化.数据缓冲区主要用于减少索引延迟和历史数据的碎片化。历史数据浸没区主要用于Ad-hoc查询，包括建立各种相关索引实现秒级结果返回。SDK，以前我们只是让SDK简单的埋点和采集点，现在，我们在SDK中加入了一些简单的计算，让数据在生成端进行转换。如果生产端（比如摄像头）的性能不够，我们可以添加一台专门为其转换的EdgeAIServer服务器，从而实现上述“主-谓-宾”模型的格式输出。当然对于App和H5页面，由于没有计算量，只需要嵌入格式即可。根据以上对IOTA模型的介绍，我们对原有的大数据体系进行了相应的调整。具体情况如下：我们的数据查询不再需要ETL，而是使用QueryEngine来实现数据留存、转换、营销、分析等各种操作。对于查询服务，我们基于Presto进行了二次开发，搭建了“秒算平台”。对应上面提到的“主谓宾”模型，我们制定了两种主要的数据存储结构：“用户/事件”，即：“谁发生??在哪里”。为了保证缓存中的数据能够成功“填充”到历史数据对应的存储区中，我们配置了DumpMR服务模块。对于“注入”的数据会被分成很多文件，比如每十分钟生成一个文件，我们配置了MergerMR服务模块，可以将这些零散的多个文件合并成一个大的存储块。此外，我们重新索引了数据以方便实时计算。在“秒算平台”上，我们使用Hbase缓存实时数据，使用HDFS存储历史数据。由于我们使用Presto作为查询服务引擎，为了让它能够连接HDFS和Hbase，我们自己开发了一些Connector。通过我们的二次开发，可以支持MySQL、Redis、MongoDB等各种第三方数据库的查询。我们直接将收集到的用户大数据，按照前面提到的“用户/事件”和“主谓宾”模型，放到SDK中进行相关计算。众所周知，任何一种软件只有经历过开源代码，才能不断推动自身的完善和发展。虽然我们的系统还是内部版本，但我们计划在今年年底之前开源上述基于IOTA架构模型的“秒算平台”，供大家使用。有了这样的平台，你可以基于它的存储引擎快速进行二次开发，而不用自己写HDFS、Connector、DumpMR、MergerMR，以及一大堆profile相关的代码。我们会提前帮您“填好”这些“坑”，您可以直接将其用于用户层面的数据分析。目前，易观大数据混合云在数据规模和性能上，已经可以根据我们分析师的各种Ad-hoc数据查询需求实现秒级返回结果。同时，我们内部的秒算服务引擎也可以支持并提供各种分析结果的分析报告。郭伟，现任易观CTO，负责易观整体技术架构和分析产品线。北京大学计算系本科生、硕士研究生，先后在Teradata、IBM、中金公司负责大数据架构师或研发总监，后任万达电商数据部总经理，联想研究院大数据总监。拥有电子商务、移动互联网、商业地产、百货、移动通信、零售、影院等多个业务领域的大数据团队搭建、系统构建、领域分析和算法经验。【原创稿件，合作网站转载请注明原作者和出处为.com】
