Há duas regras que eu procuro respeitar nos meus posts: não publico nada que eu mesmo não gostaria de ler e nunca repito algo que já foi publicado por aí. Entretanto, em alguns casos o assunto que já foi publicado é tão relevante, e está tão bem escrito, que eu me sinto na obrigação de dividir meu achado, e este é o caso do post de hoje.
Eu havia planejado dois posts sobre o conceito de Data Lake, tal qual eu fiz com Data Discovery. Ao começar a pesquisa eu topei com um artigo do Gartner falando justamente sobre esse assunto: Gartner Says Beware of the Data Lake Fallacy. Eles colocaram o problema de uma forma tão simples, clara e lúcida que se meter a querer fazer algo melhor seria uma pretensão muito maior que o meu normal – e olhe que eu sou um cara pretensioso pra chuchu! Devo ser o cara mais pretensioso mundo, mas felizmente minha modéstia também é enorme, o que me salva.
:-DEntão, ao invés de refazer o trabalho eu vou apresentar o artigo do Gartner.
A Questão
Em 2010, James Dixon publicou um post num blog Pentaho apresentando a motivação e o conceito de um Data Lake:
Motivação
James Dixon conversou com várias empresas que usam Hadoop e descobriu que cerca de 80-90% deles usam dados estruturados ou semi-estruturados, mas não “desestruturados”, sendo que a fonte desses dados é quase sempre um só sistema transacional. Mesmo assim nem tudo é dado transacional, e apesar de várias perguntas sobre esses dados serem conhecidas, muitas mais – desconhecidas – podem vir a ser formuladas no futuro. Em geral existe mais que uma ou algumas comunidades de usuários interessados nestes dados, que são gerados ou processados em um passo muito superior ao que um SGBDR aguenta.
Definição
Se você pensar que um data mart como um armazém de água engarrafada, que foi limpa e empacotada para consumo, um Lago de Dados (aka Data Lake) é o corpo de água em um estado mais natural. O conteúdo dos sistemas de origem fluem para dentro do Data Lake, e vários usuários do lago podem vir examiná-lo, mergulhar nele ou levar amostras.
Francamente, para mim é o mesmo que dizer que você pode comprar farinha pronta no supermercado, mas ir até a fazenda comprar grãos direto do armazém. Enfim, adiante.
A partir daí o hype tomou conta do debate, e tudo passou pelo processo de “binguificação corporativa”, que é aquele mecanismo em que os chavões da hora vão parar em tudo que é reunião de estratégia, documento de intenções, briefings, pings para manter as coisas in the loop blá bláh blah yadda yadda yadda.
Resultado? Em 2016 não se acham Data Lakes “na natureza”, nos grandes espaços selvagens do mundo corporativo. Traduzindo: ninguém ainda veio a público dizer que implementou um e que resultados está tirando deles.
Mais ou menos a mesma coisa pela qual passou Mobile BI, Business Discoveryt/Data Discovery, e em boa parcela o mesmo pelo qual BigData ainda passa. Mas BigData é outro assunto, para outro dia, outro post.
Fiat Lux!
E aí vem o artigo do Gartner. Não quero repetir palavra por palavra, do contrário eu prestaria a vocês um serviço melhor só informando o link ao invés de escrever meu próprio post. Vou colocar as minhas críticas e depois o que o artigo do Gartner fala, e então bater os dois.
Seis por Cinco e Meio
Meu primeiro cisma com DL (Data Lake) é o fato de que ele não trazer algo de realmente novo: muitos outros projetos fazem cópias simples dos dados de um sistema para outro repositório. Na verdade, é a abordagem de praticamente todos que assumem um projeto de DW sem estudar o assunto antes. Como não sabem o que vão fazer, começam fazendo o óbvio: copiam tudo, e geram os produtos de dados a partir deste dump.
Vejam o que o Gartner coloca:
Nick Heudecker, research director at Gartner(…) “The idea is simple: instead of placing data in a purpose-built data store, you move it into a data lake in its original format. This eliminates the upfront costs of data ingestion, like transformation. Once data is placed into the lake, it’s available for analysis by everyone in the organization.”
However, while the marketing hype suggests audiences throughout an enterprise will leverage data lakes, this positioning assumes that all those audiences are highly skilled at data manipulation and analysis, as data lakes lack semantic consistency and governed metadata.
Em Português é mais ou menos isso:
Nick Heudecker, diretor de pesquisa no Gartner: “A idéia é simples: ao invés de colocar os dados em uma estrutura construída com especificamente para arquivar os dados, você move-os para dentro do Data Lake em seu formato original. Isso elimina os custos iniciais de ingestão e processamento dos dados de origem. Uma vez que esteja no lago, o dado fica disponível para todos na organização.”
Entretanto, se o hype dá a entender que as comunidades de usuários por toda empresa vão aproveitar um DL, então ele está sugerindo que todas essas comunidades são altamente habilidosas com manipulação de dados e análise, já que um DL não traz consistência, uniformidade e gestão dos metadados.
E nós sabemos que isso não é verdade. Eles vão adiante na questão e terminam (resumindo:)
Um DL tenta resolver dois problemas, um velho e outro novo. O velho é acabar com silos de dados: ao invés de ter várias fontes controladas de dados, jogamos tudo num só repositório, sem modificações. A consolidação, teoricamente, traria um maior uso dos dados enquanto reduz custos com licenças e servidores.
O novo tem mais a ver com BigData: pela própria disparidade das fontes, nem sempre dá para catalogar o dado na chegada e acomodá-lo em um SGBDR pode limitar futuras análises.
Atacar esses dois problemas com certeza beneficia a TI no curto prazo, no sentido de que reduz o trabalho para acomodar os dados, segundo o Sr. White. Porém, achar valor nestes dados permace tarefa do usuário final. Mas por mais que a aplicação de ferramentas ajude nisso, sem um mínimo de gestão tudo que conseguiremos é um monte de dados desconexos arquivados no mesmo lugar.
Bingo! E logo em seguida ele fala dos riscos de transforma um DL em um pântano se não houver um mínimo de gestão sobre ele. Ou seja, ao trocar um DW normal por um Data Lake arriscamos perder mais que ganhar. Arriscamos? Não, nós vamos perder, se não houver um mínimo de governança em cima desta infra-estrutura.
O Barato Sai Caro
Qualquer um que já passou pela frustrante experiência de manter um projeto de DW baseado em dumps sabe que a promessa de economia de tempo e recursos desse formato nunca se realiza. Fazer um dump pode até ser mais rápido que, por exemplo, desenhar um Data Mart e seu ETL. Porém, mais tarde, esses projetos batem com problemas que desperdiçam muito mais tempo que o rápido início economizou.
Um destes problemas é justamente racionalizar o uso dos recursos para poupar carregar o banco inteiro a cada atualização. A solução que sempre encontram é capturar um “delta”: comparar o sistema de origem com o dump no “DW” e trazer apenas as diferenças.
Mesmo assim há um custo em hardware e tempo inevitável. À esse custo os adeptos do DL respondem com a velocidade de carga do Hadoop, invariavelmente o miolo de DLs.
Outro problema é que a cada demanda do usuário por uma análise ou relatório, um novo ETL pós-dump precisa ser produzido. Até aí tudo bem, porque qualquer projeto de DW enfrenta isso. O problema é que qualquer alteração na origem “quebra” tudo que depende do dump e do nada surge uma montanha de retrabalho.
Ao que os seguidores do DL contrapõe outro argumento: self-service! Só que explorar um Data Lake não é para qualquer por dois motivos:
- A pilha (stack) de tecnologia necessário é imensa. Um profissional especializado teria dificuldades, imagine um cara do Marketing?!
- É preciso entender os dados e como eles “funcionam” para poder extrair valor deles. Nem mesmo todos os DBAs de uma empresa costumam saber tudo sobre os dados, quanto mais um leigo… do departamento de Marketing!!!
Entender muito de uma coisa faz com que tendamos a entender menos de outras. Marketing é uma ciência que se aproxima da arte, assim como muitas outras funções em uma empresa, e o custo de saber tanto do negócio da empresa é a tendência a saber menos de coisas como TI e BI. Não tenho nada contra “o Marketing”, só acho um bom exemplo do conflito entre a necessidade da informação e a capacidade de manuseio das ferramentas.
Viram o tanto que eu gastei de letras para explicar a idéia? Olhem e aprendam com quem sabe o que faz:
“The fundamental issue with the data lake is that it makes certain assumptions about the users of information,” said Mr. Heudecker. “It assumes that users recognize or understand the contextual bias of how data is captured, that they know how to merge and reconcile different data sources without ‘a priori knowledge’ and that they understand the incomplete nature of datasets, regardless of structure.”
While these assumptions may be true for users working with data, such as data scientists, the majority of business users lack this level of sophistication or support from operational information governance routines. Developing or acquiring these skills or obtaining such support on an individual basis, is both time-consuming and expensive, or impossible.
Sintético, completo, preciso! Elegante! Em tradução livre:
“A questão fundamental que um DL traz é que partimos de certos pressupostos sobre os usuários da informação”, disse o Sr. Heudecker. “Assume-se que os usuários reconhecem ou entendem o viés contextual de como os dados são capturados, que eles sabem como juntar esses dados e reconciliar diferentes fontes de dados sem um conhecimento prévio e que eles compreendem a natureza de incompletude dos conjuntos de dados, independentemente da estrutura.”
Ainda que esses pressupostos possam ser verdade para usuários que trabalham com dados, como cientistas de dados, a maioria dos usuários de negócios não possui esse nível de sofisticação ou apoio dos procedimentos de governança de informações operacionais. Desenvolver ou adquirir essas habilidades ou obter tal suporte em uma base individual e caro e demorado, ou impossível.
Eles vão no miolo da questão: propor um Data Lake presume que os usuários são de um tipo que quase não existe, e que transformar um usuário comum nesta figura de super-usuário é caro, se não impossível.
Outros Casos
O artigo segue adiante para discutir outros aspectos e riscos presentes em uma iniciativa de DL, mas o fulcro é sempre o mesmo: a falta de gestão do repositório, e a excessiva dependência do usuário final para geração de valor.
A certa altura vem este comentário (tradução livre:)
DL normalmente começa com repositórios de dados sem “governo”. Atender as necessidades de uma audiência mais ampla requer repositórios organizados, controlados, consistentes e com controle de acesso – elementos já disponíveis em um DW.
Conclusão
E o que tiramos disso tudo? O Gartner é bem simpático (tradução livre:)
White: Sempre há valor a ser encontrado nos dados, mas a questão que sua organização deve atacar é esta: “nós permitimos e até encorajamos análises que ocorrem uma única vez, autônomas, de dados que estão em silos ou em um Data Lake, unindo esses dados para aquela análise apenas, ou nós formalizamos esse esforço até certo ponto, e tentamos sustentar as habilidades que geram valor?” Se vamos endossar o herói, o agente solitário, um Data Lake com certeza possui um grande apelo. Se estamos mais tendentes à alternativa, um uso mais formalizado, então é melhor deixar o DL para trás e seguir para adotar uma estratégia baseada em DW.
Eu, bom, eu sou mais marrento mesmo, então as conclusões a que eu chego são:
- Data Lake parece mais um conceito experimental que um produto ou serviço concreto e acabado;
- Ainda não existe um caso de uso claro, ou mesmo nublado, que sirva para uma organização decidir-se pela adoção de um DL;
- O conjunto de riscos e dificuldades associados a um DL supera de longe quaisquer prováveis benefícios.
Eu sempre digo que BI é uma disciplina, mais que ferramentas ou técnicas. Sempre que aparece uma tendência de mercado como o Data Lake (e Data Discovery, Cientista de Dados etc. etc. etc.), eu fico com o pé atrás, pois parece muito mais um tipo de Marketing do que uma tecnologia nova.
Talvez um dia evolua e torne-se uma peça valiosa do arsenal de BI. Mas por enquanto, por mais que adore a Pentaho e o Pentaho (e eu gosto muito dos dois, por enquanto), eu não vejo motivo para investir em um DL. Na verdade, eu vejo um alto risco de um projeto de DL acabar em problemas caros, ou até mesmo fracasso total.
Geek BI 